Gendex GXS700

From Nucwiki
Jump to: navigation, search

GXS700 FOSS toolkit

Sold as:

My understanding is that Gendex and Dexis are both held by the same company. The sensors seem to actually be made by Fairchild Imaging (now BAE). So I'm not sure what to actually call them. Gendex gave them a real model number (GXS700) so I rolled with that.

TODO: add some external device pictures, especially comparing small and large


Quick facts

  • Linear pixel size: very roughly 18.2 um
  • 1850 x 1344 (large) => 1.324 x 0.962"
  • 14 bit

General theory of operation based on protocol reverse engineering.

Sensor waits for a certain radiation level (ctr_thresh) before triggering a capture. This presumably is to make a higher quality image by not accumulating noise while the x-ray is coming. It probably also smooths out some boundary conditions as the x-ray head begins to fire. Sensors can also be force triggered by sending a USB command. There is a related trigger parameter (bin_thresh) of unknown function. I have not seen changing it effect the capture in any way.

Once triggered, the sensor integrates for the given number of milliseconds (default 700). Next, a size specific transfer method is used to suck data to the host. Finally, the image is decoded and, optionally, corrected on the host.

Sensors come in two sizes: size 1 (small) and size 2 (large). Think Dexis only makes size 2 sensors.

Sensors come in two brands: Gendex and Dexis. They are packaged differently but otherwise internally identical. There are some software tweaks, notably serial number range.

Internally the major components are:

  • FX2 MCU
  • EEPROM (for FX2)
  • Actel FPGA
  • 16 bit sensor
  • Flash

Bare sensors

Some of these were sold at defcon 22. Look something like this:

Mcmaster gendex gxs700 box2.jpg

Mcmaster gendex gxs700 sensor1.jpg


Mcmaster gendex gxs700 split.jpg

Gendex gxs700 bond wires.jpg

Gendex gxs700 no touchy.jpg

Bond wires are exposed! Be very very careful handing these! Seen at upper part of sensor above


JM 2015-11-24: gave away my possibly working bare sensors (3x) and kept 2x definitely broken. Still have 2x encased units


Mcmaster gendex gxs700 pcb top.jpg

Mcmaster gendex gxs700 pcb btm.jpg


"128 Megabit CMOS 3.0 Volt Flash Memory with 104-MHz SPI (Serial Peripheral Interface) Bus"

 12699003 C
 (C) 06





 QNG132 1140

FX2 USB controller

"CY7C68 Series 16 kb RAM EZ-USB FX2LP USB Microcontroller"


MT unknown




USB connector

Gendex gxs700 usb flex.jpg

5 pin ribbon cable

  • 1: +5V
  • 2: GND
  • 3: D+
  • 4: D-
  • 5: N/C?
  • Goes to unpopulated capacitor or something


No maker's mark observed on die. There are some foundry marks but that probably won't be very helpful even if the foundry is identified

CNC machine

DIY XY scanner



From anonymous source:

  • "I wanted to know how to read a calibration file, and he gave me some advice. I noticed in your python script, your resolution values were larger then what is outputted in the actual x-ray files.. so I used those proportions on a dexis, and finally got the resolution, and removed 4 bytes and enabled endian in ImageJ, and I was finally able to see the calibration file. "
  • "Apparently Dexis or Schein won't allow the creation of a calibration file onsite"
  • Schein?
  • "Dexis had a lot of older sensors calibration files on a server, and it crashed..."
  • "There are 3 files in a calibration files. 2 are 4MB size. Those are the dark and flats. The third file is around 276kb or so, and.. as far as I can tell.. this file helps the dexis or gendex gx-picture software to know which sensor it is dealing with. I am told that file can be reused, per sensor. It is a dfm file extension if I recall. So it can be reused on a Dexis, but only Dexis. the dfm for a Gendex size 2 should be reused only on gendex size 2 sensors."
  • "For a Dexis, use ImageJ to open the flat and dark calibration files. Open it as raw, check mark the endian box, and remove 4 bytes of data option. Input the resolution in the screenshot."
  • "For a Gendex calibration file, you will need to use the resolution you used in your python script."
  • "Dexis sensors were calibrated with a machine that could do 16 sensors at a time..."
  • "They had a bug in the cypress sdk, and that caused the eeprom to go blank in some cases."

Calibration files

Note: uvscada can more or less decode these. We have enough information at this point to possibly generate them

Some people get these with their sensors to use with the original software (if you have it)

Sample file names:

  • 2123456789_dark.flf: dark frame (x-ray off w/ force trigger)
  • 2123456789_flat.flf: flat field (x-ray on w/ uniform beam)
  • 2123456789_dfm.dfm :some sort of design for manufacturability improvements?

These are just little endian encoded raw sensor data.with a 4 byte header. The dark/flat field corrections appear to be applied host side. Its unclear how the DFM file is used.


Gendex GXS700 Dump

Pattern generator

I've discovered 3 test pattern generators in the small sensors, probably exist in the large sensor as well. These might be useful for diagnosing broken sensors

Mcmaster gendex gxs700 mode 1 sm.png

Mcmaster gendex gxs700 mode 3 sm.png

Mcmaster gendex gxs700 mode 5 sm.png


I get a lot of e-mails about broken sensors. If you find out anything about why yours is broken or how you fixed it I'd be interested.

If you are commercial / have budget, you might consider contacting someone specializing in these sensors (example). But if you are a determined hobbyist on a budget, read on.

Note: a lot of questionable / broken sensors have shown up on eBay. These range from completely broken to working fine. A lot of them seem to have imaging defects that are acceptable for hobbyists but too severe for commercial use. Most of these do not come with calibration files.

Following assumes you have uvscada software setup. Please at a minimum send me, if possible:

  1. Vendor and model of the sensor you have (ex: Dexis Platinum, Gendex size 2, etc)
  2. Diagnostic dump output (in dump directory)
  3. Dark frame ( -f -e)
    1. Please send histogram equalized version (-e above) unless otherwise requested

Procedure might be something like this:

  1. Does lsusb detect sensor?
    1. No: broken cable. Check for fray, etc
  2. Do a diagnostic dump ( Did it succeed?
    1. No, same lsusb ID: FX2 failed to renumerate. Severe error
    2. No, but something else: hard to tell. I haven't worked with many broken sensors
  3. Capture a dark frame ( -f -e), ie force trigger w/o x-rays. Did it complete without error?
    1. No: maybe sensor is broken. Possibly FPGA
  4. Does the frame look typical?
    1. No: misc sensors defects. Probably not repairable. But broken bond wires may be
  5. Capture a flat field ( -e), ie using a real x-ray source and no object. Does it work normally?
    1. Never triggered: meh
  6. Your sensor is good I guess?

General notes:

  • Exposed bond wires are very fragile. If you got a bare sensor they are very easy to destroy. This requires relatively specialized equipment (wire bonding machine) to fix

Some issues I've seen:

  • Corrupt EEPROM
  • lsusb shows as an FX2 dev kit
  • Repair using your backup, or a backup from another sensor
  • Triggers immediately without force trigger or x-ray
  • A sensor was doing this
  • I think I fixed it with an EEPROM restore so possibly messed up some parameter
  • Blotches
  • Manufacturing defect?
  • Broken sensor bond wires
  • Only encountered on bare sensors
  • Broken USB cable
  • Relatively easy to fix, especially if fix does not have to be watertight

Image: typical good 1

Gendex gxs700 good line.png

Above (equalized): for the most part this works, although it has a bad line down the middle

Image: typical good 2

Gendex gxs700 good2 dark.png Gendex gxs700 good2 darke.png

Above: dark field raw and histogram equalized

Gendex gxs700 good2 flat.png Gendex gxs700 good2 flate.png

Above: flat field raw and histogram equalized

Image: uniformly noisy field

Gendex gxs700 bad uniform noise.png

Above: histogram equalized

Unknown issue, reported by a user to me 2017-12-19

Raw data looks like maybe some data and/or address lines are bad

 00000000  00 00 20 00 28 00 10 00  08 00 14 00 04 00 0c 00  |.. .(...........|
 00000010  14 00 08 00 00 00 08 00  08 00 00 00 04 00 04 00  |................|
 00000020  0c 00 10 00 00 00 00 00  0c 00 00 00 00 00 10 00  |................|
 00000030  04 00 00 00 14 00 08 00  00 00 14 00 04 00 00 00  |................|
 00000040  08 00 14 00 00 00 14 00  00 00 00 00 04 00 08 00  |................|
 00000050  08 00 08 00 0c 00 04 00  00 00 10 00 00 00 00 00  |................|
 00000060  00 00 08 00 10 00 04 00  00 00 1c 00 00 00 00 00  |................|
 00000070  00 00 14 00 00 00 00 00  0c 00 00 00 0c 00 0c 00  |................|
 00000080  08 00 00 00 14 00 00 00  00 00 0c 00 00 00 10 00  |................|
 00000090  04 00 00 00 10 00 04 00  00 00 0c 00 0c 00 08 00  |................|

Got something similar from someone else:

Gendex gxs700 markus bad capture 000 e.png

At least two sensors which exhibited uniformly noisy image output were confirmed to have damaged bond wires, even while they appeared functional otherwise- enclosure not damaged, enumerates over USB, loads FX2 firmware, reads both flash and EEPROM, serial numbers match, capture can be forced and capture does not start when not forced.

Extent of the bond wire damage can be seen in the following pictures:

Gendex GSX-700 bond wire corrosion 1.jpg
Gendex GXS-700 PCB missing pads.jpg

John's comment:

Yeah unfortunately I get a lot of e-mails about bad sensors which is a lot of the cheap units you'll find on eBay (say $60 each). Unfortunately once bond wires and/or pads are destroyed general wisdom seems to be to scrap them

Image: choppy field

Gendex gxs700 uvscada type1 bad.png

This was caused by a uvscada bug on type 1 sensors. Using a recent version should fix this

Bad read w/ issue

For some reason the EEPROM S/N wasn't able to be fetched. The sensor image was noisy, turned out to be due to corroded wires between the sensor and PCB. ie sensor disconnected


The case may be ultrasonically welded together

The beige compound comes off in acetone + ultrasound. However, there is a clear protective film over it that significantly slows down the process if it remains on

The sensor appears to be bonded to the PCB with silicone. Acetone slightly weakens it but not enough for bulk removal. Heat gun (400F IIRC) weakened it enough to remove relatively easily. Also tried lighter fluid and mineral spirits but didn't come off. Suggested to try professional silicone remover...will try soon.

MCP maybe came off with acetone ultrasound