Gendex GXS700

Open source driver quick start

Sold as:

• Gendex GXS700 (Gendex (GX) S-700 => GX S-700 => GXS-700)
• Dexis Platinum
• "PerfectSize™ Sensor—One Size Fits All"

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.

2017-09-26: small sensor support added!

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

Overview

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:

WARNING WARNING WARNING

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

WARNING WARNING WARNING

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

PCB

Flash

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

 SPANSION
 FL128PIF
 12699003 C
 THAILAND
 (C) 06

FPGA

Sticker:

 001-
 00015

Package:

 Actel
 ProASIC3
 A3P250
 QNG132 1140
 ZA637115

FX2 USB controller

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

 CY7C68
 13A4S65
 1131
 642364

MT unknown

 9WA47
 PW6B7
 
 01Z9
 
 MT

274

 274
 036
 .VY

USB connector

5 pin ribbon cable

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

Die

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

xy-ray

Misc

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.

Dumps

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

Troubleshooting

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 (capture.py -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 (dump_dev.py). 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 (capture.py -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 (capture.py -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

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

Image: typical good 2

Above: dark field raw and histogram equalized

Above: flat field raw and histogram equalized

Image: uniformly noisy field

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:

Image: choppy field

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

Bad read w/ issue

https://twitter.com/FauthNiklas/status/976402053181341697

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

References

• Patent