Quick start guide to getting the sensor working. Basically, follow sections below to:

  1. Install software
  2. Force a capture to verify the sensor works
  3. Fire x-rays at sensor to test full functionality

driver here

Sensor info


x-rays are dangerous…make sure you know what you are doing. Not responsible for death, injury etc

Supported devices

Image Vendor Product Works? Notes
Gendex GXS700 small (type 1) Yes* Linux VM problematic from Windows VMWare and VirtualBox
Gendex GXS700 large (type 2) Yes Primary device I develop for
Dexis Platinum Probably Test failed but DUT was likely broken
Dexis Plus 690 Probably Test failed but DUT was likely broken

I don't know if any other vendors (ex: schick) use the same hardware



  • Linux
    • Tested on Ubuntu 12.04 x64, Ubuntu 16.04 x64
    • WARNING for VM users: only size 2 works
      • You must use native linux for size 1, see below
  • USB port (duh)
  • A supported sensor
  • x-ray source: not needed for initial setup
  • You DO NOT need calibration files
    • See below for details

“$ cmd” means type “cmd” into a terminal

Do (I'll improve this as people run into problems):

  1. $ sudo apt-get install -y git python-pip
    • Also maybe: sudo apt-get install -y python-serial python-numpy python-PIL
  2. $ sudo pip install libusb1
  3. $ cd uvscada
  4. $ ln -s $PWD/uvscada gxs700/
  5. $ ./gxs700/udev.sh
  6. Plug in your sensor to the USB port
    • Re-plug it if its already plugged in
  7. $ python gxs700/dump_dev.py
    • Optional (highly recommended): backup sensor data
  8. $ python gxs700/capture.py -f -e
    • Optional: test sensor by forcing a capture

Force capture

This step tests the sensor without actually firing x-rays at it. This is also useful for calibrating sensor defects


  1. $ python gxs700/capture.py -f
  2. Check which you got:
    • Waiting for image: expected response. Continue below
    • “Exception: Failed to find a device”: plugged in? Did you run permission script?
  3. It should have written capture_000.png and capture_000.bin to the current directory
  4. Above will be very dark. Enhance contrast by doing histogram equalization: python gxs700/decode.py -e capture_000.bin capture_000e.png
  5. You should see an image roughly resembling the reference above. If you do, your sensor probably works

X-ray capture


Suggest you force a capture first to verify your sensor is working

  1. $ python gxs700/capture.py
  2. Verify it says “Waiting for image”. It will spit out some dots to indicate its still polling
  3. Fire your x-ray source
  4. It should notice the x-rays and begin downloading an image
  5. It should have written capture_000.png to the current directory
    1. Currently also writes capture_000.bin but will probably remove this soon
  6. You have your first x-ray!

Diagnostic dump

Please do this and send me the result. This helps me understand the sensors better to provide better support

  1. $ python gxs700/dump_dev.py

Send me the directory “dump” that it creates. If you are going to send me data from multiple sensors, please move the directory before re-running as it will overwrite.

Reference dumps



  • Couldn't find device
    • Did you run the udev permission script?
    • Try re-plugging it in and/or restarting Linux system
    • VM: did you connect USB to the guest?
  • Didn't detect x-rays
    • Can you turn up current higher?
      • Only recently added mA monitoring…don't know approx current I was imaging at
    • Too high or low kVp?
      • 60 kVp is a good place to start

Known issues:

  • Multiple sensors are not supported
    • Would slightly increase software complexity and no use case today for that
    • The small sensor is not supported
    • Dexis untested
    • Really, only tested against my one sensor
    • Usually can be interrupted but sometimes will fail init if it is
      • Workaround: re-plug the USB port


  • USB speed limits frame rate to something like 0.3 FPS…don't expect this to work like a video camera
  • Currently doesn't use fxload but maybe should
  • .bin file is raw output. .png is lossless compressed .bin equivalent (you can make the .bin from the .png) so .bin will probably get dropped
  • Image decoding can probably be made much faster but usually I don't care
    • For long runs (ex: CBCT) I'm waiting for sensor to cool anyway

See also: GXS700 general troubleshooting

Size 1 corruption

Update: originally this was though to be a visualization issue. Now its believed to be a USB controller issue

TLDR: 2017-10-10 size 1 test results:

  • VMWare: transfers very slowly, yielding a corrupt image
  • VirtualBox: freezes the *host*

Above: good capture on one machine. Capture took about 3 seconds

Above: same sensor on a different native Linux machine. Capture took about 30 seconds

So if you have a size 1 sensor, unfortunately you may need to use native Linux.

Details: Size 1 sensors use USB interrupt transfers while size 2 sensors use USB bulk transfers. Unfortunately, interrupt transfers seem to be relatively poorly supported aside from HID (keyboard/mice). This may be partially due to them doing large interrupt transfers while HID does very small transfers.

Parallels has not been tested. Would be interested in feedback.

Size Machine USB controller OS Virtualization OS native Result By Notes
1 Thinkpad Carbon X1 Intel Sunrise Point-LP USB 3.0 xHCI Controller (rev 21) Ubuntu 14.04 x64 Native N/A Works JM .
1 JM desktop Intel ICH10 Ubuntu 14.04 x64? VMWare Windows 7 Pro x64 Fail JM Slow capture / corrupted
Has USB2 and 3. Which did I try?
1 User1 desktop ? Ubuntu 14.04 x64? VMWare Windows 7? Fail User1 Slow capture / corrupted
1 User1 desktop ? Ubuntu 14.04 x64? Virtual Box Windows 7? Fail User1 System freeze
1 User1 desktop ? Ubuntu 14.04 x64? Native N/A Fail User1 System freeze
1 Thinkpad T61P Intel 82801H Ubuntu 12.04 x64 Native N/A Fail JM
1 Thinkpad T61P ExpressCard (Renesas uPD720202 USB 3.0) Ubuntu 12.04 x64 Native N/A Works JM Link
1 Thinkpad W520 NEC uPD720200 USB 3.0 Ubuntu 14.04 x64 Native N/A Works JM USB3 port
1 Thinkpad W520 Intel 6 Series/C200 Ubuntu 14.04 x64 Native N/A Fail JM USB2 port
Kernel panic!
1 JM server Intel C600/X79 USB 2 Ubuntu 12.04.5 x64 Native N/A Fail JM Timeout
1 JM server TODO: try USB3 card?

Above: kernel panic W520 USB 2 port


decode.py has a “-e” option to do histogram equalization. This often brings out additional detail by re-mapping from 16 bit grayscale to shifted 8 bit grayscale. This works because humans can see 8 bits much easier than 16. TOOD: could we display usable 16 bit images by using two colors?


$ python decode.py -e capture_004.bin capture_004e.png

NOTE: future revisions may require .png input instead of .bin

x-ray trigger

I haven't messed with the default trigger settings but I suspect you could do very low x-ray triggering if desirable

x-ray fire

I use a Gendex GE-100 x-ray head. I've found these readily available for <$75 on both eBay and Craigslist. This accepts near line level AC inputs for both HV and filament making this easy to control from commodity variacs.

I control the setup via a DLI WPS7. When wired correctly:

  • Outlet 1: HV
  • Outlet 2: filament

do something like:

$ WPS7_HOST=wpsip WPS7_PASS=mypassword python fire.py

to fire an x-ray (ie when the sensor is armed. wpsip is something like

Note: you can also set these environment variables in files like .bashrc so you don't have to type them for each command

I recommend you use a hard wired ethernet line and have a way to cut power to the switch remotely if it fails. I do this by running an extension cord across the room so that it can be be pulled in event of WPS7 failure (stuck switch, etc).

TODO: use WPS7 scripting capability to make switch throws atomic


Takes raw, uncalibrated images. I've been asked a few times if I could provide calibration files for the Windows driver or could even use their calibration files on my driver. However, I'm not really interested in supporting their proprietary format. If someone submits a patch though I'll probably merge it in.

That said, I'm not against coming up with an independent calibration scheme. I know how to take dark frames (see API) which is the key component. Uncalibrated images have been generally good enough for me so I haven't put work into this. If you are interested though shoot me a line.


I haven't played around too much with trying to maximize quality. One thing that's clear though is that the sensor should be as close as possible to the object to be x-rayed. The tube to sample distance doesn't seem to matter as much


stitch.sh has an example workflow using pr0ntools (panotools). At the core its using mask.py to generate transparency masked images to use the full, albeit irregular, sensor area.

uvscada/gxs700.txt · Last modified: 2017/12/05 12:27 by mcmaster
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution 4.0 International
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki