RECESSIM - User contributions [en]

GE Medical Flashpad Digital Xray Detector

2026-06-12T15:09:45Z

Gamerpaddy: /* Teardown / Internal Pictures / Hardware analysis */ typo

==Overview==
{{Note|UNFINISHED Project, it was not yet possible to retrieve a exposure or dark frame in my testing, further investigation needed. any help is appreciated on recessim discord.}}

The '''GE Flashpad''' is a Digital Radiography image sensor from approximately 2010, originally used in the '''GE Optima 220AMX''' mobile X-ray unit. It was designed to replace analog film in radiology, dramatically reducing image acquisition time from hours to seconds.
[[File:GE Flashpad.jpg|thumb|Flashpad with Anti-Scatter grid (left), manual and recovery dvd for 220amx and tether cord (right)]]
Due to its high original cost and specialized application, used units occasionally appear on professional B2B marketplaces in the $15,000–$50,000 range. On eBay, prices typically fall between $1,500 and $5,000, though units at this price point are often in poor condition and may fail the built-in self-test or not function at all.

{{Note|All findings on this page are based on a single unit and the time spent working on it. Information is subject to speculation and may not be fully accurate.}}

{{Note|AI assistance was used in writing this page for improved formatting and readability, as well as in the process of finding information, testing, and analyzing firmware dumps and backups.}}

All files used and mentioned are found on the official Optima XR220amx Application Software and Linux OS DVD 5406106-10 Rev3, which i cannot provide due to being copyrighted content.
 
==Purpose and Motivation==

This project documents the reverse engineering of the GE FlashPad wireless
digital radiography detector used with the Optima XR200/220 AMX mobile X-ray
system, with the goal of freeing these detectors for independent use.
[[File:Xray capture pcb.png|thumb|Xray capture of a PCB for Reverse Engineering using a different detector]]
Large numbers of these detectors reach the used market, but each one is bound to its original Optima 220 AMX
console. Once separated from that console, or once the console is
decommissioned, the detector is effectively useless even though the hardware is
fully functional. There is a Windows software but it is not obtainable. The aim of this work is to remove that artificial barrier so
that a standalone FlashPad can be paired, configured, and read out by any host,
without the half million dollar console it was sold with.

The intended beneficiaries are:

*Hobbyists, researchers, and engineers who want a high quality flat panel detector for their own imaging projects. for example studying the fluid movement in plants. https://www.youtube.com/watch?v=j-FHbHoiwNk (Xray timelapse by Ben Krasnow / Applied Science using a GE Flashpad)
*Veterinary practices, which can put surplus human grade detectors to good use at a fraction of the cost of new equipment.
*Clinics and hospitals in countries and regions where a complete commercial system is unaffordable, allowing serviceable detectors to keep providing diagnostic imaging instead of being scrapped.

[[File:Xray current clamp multimeter.png|thumb|xray of a current clamp multimeter using a different detector]]
This is done for human good. Every detector returned to service is one less
piece of working medical hardware sent to landfill, and potentially one more
place that can offer X-ray imaging where it otherwise could not.

All files, findings, protocol documentation, and tools produced by this project
are public and open source, so that anyone can study, reproduce, and build on
the work.

==Technical Specifications==
[[File:Ge flashpad tether cable pinout diagram.png|thumb|Pinout Diagram of the Tether cable]]
[[File:Ge flashpad tether wiring for ethernet cable.jpg|thumb|Professional Tether wiring to attach a Ethernet Cable and 12V socket to it.]]
The Flashpad uses a '''~40 × 40 cm CsI scintillator''' bonded to a [[Thin-film transistor|TFT]] photodetector array mounted on glass. The assembly is highly sensitive to shock and impact damage. See section [[#Reading the Drop and Shock Event Log|drop and shock event log]]

{| class="wikitable"
|-
!Parameter!!Value
|-
|Resolution||2048 × 2048 px
|-
|Bit depth||16-bit per pixel
|-
|Spatial resolution||Up to 5 lp/mm (theoretical)
|-
|Scintillator material||Caesium iodide (CsI)
|-
|Detector type||TFT photodetector array (glass substrate)
|-
|Panel size||~40 × 40 cm
|}

The theoretical 5 lp/mm spatial resolution is primarily limited in practice by the focal spot size of the X-ray source. Use of an anti-scatter grid can improve effective resolution.

===Status of Reverse Engineering===

{| class="wikitable"
|-
!What!!Status
|-
|Connect, beacon, ACK||Works
|-
|PORT_SETUP||Works
|-
|SIGNATURE_REQUEST / serial number readout||Works
|-
|Script download (Scripts 7, 8, 1)||Works
|-
|EXECUTE_SCRIPT||Works
|-
|EXECUTION_COMPLETE (dark acquisition)||Works but without image readout its speculation.
|-
|EXECUTION_COMPLETE (standard acquisition)||Needs real X-ray trigger to test
|-
|Image data on port 6660||Does not work yet, under investigation. Will not send Imagedata...
|}

==Hardware Features==

===Shock logging===
The unit contains an internal accelerometer that logs significant shock events — but only when a battery is inserted. As there is no backup battery, shock events occurring while unpowered are not recorded.

===Wireless connectivity===
Some units include a UWB transmitter for Wireless USB; others may be equipped with a Wi-Fi module instead. The detector can also be operated over the tethered connection alone.

===Ethernet interface===
There is a 100MBit Ethernet interface trough the Tether Cable which can be tapped and used for Communication.
Exposed metal contacts on the bottom connector are isolated via relays by default. Enabling Gigabit Ethernet connectivity requires shorting or driving two specific pins. This has not been investigated further at this time.

==Communication Protocol==

This section documents the URP/PDAP protocol used by the GE Flashpad (codename '''Apollo''' (Or FeiTian, Mammo, Gryphon etc.) to communicate with a host over Ethernet. All findings are based on live capture tests, configuration files, and reverse-engineering of the GE SuperBee software stack.

{{Note|All findings are based on a single unit and may not be fully accurate.}}

===Network Setup===

All findings were over Ethernet only, no UWB or WIFI has been used.
Default detector IP is <code>192.168.1.30</code>. Set your host to a static IP in the same subnet, <code>192.168.1.1</code> works fine.

At first by sending random bytes over Python it answered to port 48879 (0xBEEF), which seems to be either the default port or set by Python.
After SYSTEM_SETUP it got set to 5550.

{| class="wikitable"
|-
!Role!!IP!!Port!!Direction
|-
|All commands: host -> detector||192.168.1.30||'''8100''' (UDP)||Host sends here
|-
|Discovery beacons: detector -> host||-||'''4500''' (UDP)||Detector sends here initially
|-
|Protocol replies: detector -> host||-||'''5550''' (UDP)||Detector sends here after setup
|-
|Image pixel data: detector -> host||-||'''6660''' (UDP)||Detector streams frames here
|}

In practice you can listen on port '''5550''' for everything (beacons and replies) by advertising that port in both <code>SYSTEM_STARTUP</code> and <code>PORT_SETUP</code>. The detector sends to whichever port was most recently configured.

===Protocol Layers===

Two layers, carried over UDP:

;URP (Unified Registration Protocol)
:8-byte wrapper on every packet. Handles sequencing and acknowledgement.

;PDAP (Proprietary Detector Access Protocol)
:The actual command layer, present inside URP packets when <code>CmdFlag = 0</code>.

Every UDP packet starts with a URP header:

<pre>
[SeqId : 4 bytes LE] [CmdFlag : 4 bytes LE]
</pre>

*<code>CmdFlag = 0</code> -- data packet, PDAP command follows.
*<code>CmdFlag = 1</code> -- bare ACK, no PDAP body. SeqId echoes the packet being acknowledged.

Both sides must ACK every data packet immediately. The detector silently drops packets with a SeqId it has already seen, so always increment SeqId for each new command.

When CmdFlag is 0, the PDAP header follows immediately:

<pre>
[cmd_type : 4 bytes LE] [payload_len : 4 bytes LE] [payload ...]
</pre>

===Connecting to the Detector===

The connection sequence is:

#Broadcast <code>SYSTEM_STARTUP</code> to tell the detector where to reply.
#The detector sends a <code>BEACON</code> back -- ACK it and sync your sequence counter.
#Send <code>PORT_SETUP</code> to configure the reply and image ports.
#Send <code>SIGNATURE_REQUEST</code> to read the detector identity (serial number, model, firmware, MAC).

====Step 1: SYSTEM_STARTUP====

Broadcast UDP to <code>192.168.1.255:8100</code>. Always uses <code>SeqId = 0</code>.

<pre>
URP : [00 00 00 00] SeqId = 0
[00 00 00 00] CmdFlag = 0
PDAP: [01 00 00 00] cmd_type = 1
[06 00 00 00] payload_len = 6
[15 AE] host reply port = 5550 (big-endian)
[C0 A8 01 01] host IP = 192.168.1.1 (network byte order)
</pre>

<syntaxhighlight lang="python">
import socket, struct

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
sock.bind(("0.0.0.0", 5550))

HOST_IP = "192.168.1.1"
DET_IP = "192.168.1.30"
HOST_PORT = 5550
IMG_PORT = 6660

def make_urp_packet(seq_id, pdap_bytes):
return struct.pack("<II", seq_id, 0) + pdap_bytes

pdap = struct.pack("<II", 1, 6) + struct.pack(">H", HOST_PORT) + socket.inet_aton(HOST_IP)
sock.sendto(make_urp_packet(0, pdap), ("192.168.1.255", 8100))
</syntaxhighlight>

====Step 2: Receiving the BEACON and ACKing====

The detector broadcasts a <code>BEACON</code> (cmd_type=1) roughly every 2 seconds. After sending SYSTEM_STARTUP you should get one quickly. Parse the detector SeqId from the URP header and ACK it:

<syntaxhighlight lang="python">
data, addr = sock.recvfrom(4096)
det_seq = struct.unpack_from("<I", data, 0)[0]

# send bare ACK
ack = struct.pack("<II", det_seq, 1)
sock.sendto(ack, (DET_IP, 8100))

# all subsequent commands start from here
host_seq = det_seq + 1
</syntaxhighlight>

====Step 3: PORT_SETUP====

Tells the detector which host ports to use for replies and image data.

<pre>
PDAP: [02 00 00 00] cmd_type = 2
[04 00 00 00] payload_len = 4
[15 AE] host cmd port = 5550 (big-endian)
[1A 04] host image port = 6660 (big-endian)
</pre>

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 2, 4) + struct.pack(">HH", HOST_PORT, IMG_PORT)
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1
# expect bare ACK from detector
</syntaxhighlight>

====Step 4: Reading the Serial Number (SIGNATURE_REQUEST)====

Empty command, the detector replies with a 54-byte payload containing its identity.

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 3, 0) # cmd_type=3, payload_len=0
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1

# reply is 70 bytes total: 8 URP + 8 PDAP header + 54 payload
data, _ = sock.recvfrom(4096)
payload = data[16:] # skip URP (8) + PDAP header (8)

mac = payload[0:6]
serial = payload[22:34].rstrip(b'\x00 ').decode()
model = payload[34:46].rstrip(b'\x00 ').decode()
fw_bytes = payload[46:54]
firmware = ".".join(str(b) for b in fw_bytes)

print(f"MAC: {':'.join(f'{b:02X}' for b in mac)}")
print(f"Serial: {serial}")
print(f"Model: {model}")
print(f"Firmware: {firmware}")
</syntaxhighlight>

Expected output:
<pre>
MAC: 40:F4:A0:00:78:4D
Serial: UA45829-7
Model: 5340000-7
Firmware: 1.6.0.4.2.0.1.3
</pre>

===Running an Acquisition===

After the connection sequence above, download scripts to the detector and then execute them.

====ROE Initialisation (Script 7)====

Always run this first. It initialises the readout electronics and takes about 4-5 seconds. The detector sends host event ID 17 when done.

====Dark / Offset Acquisition (Script 1)====

No X-ray source required. Runs a dark-field exposure for offset calibration. Use this to verify the acquisition pipeline without a generator.

====Standard Acquisition (Script 0)====

Requires an actual X-ray exposure. <code>EXECUTION_COMPLETE</code> will '''not''' arrive without a real X-ray trigger.

====Sequence Overview====

<pre>
HOST DETECTOR
| |
|-- SYSTEM_STARTUP (broadcast) ----------->|
|<- bare ACK -------------------------------|
|<- BEACON (cmd_type=1) --------------------|
|-- bare ACK ------------------------------>|
| |
|-- PORT_SETUP (cmd_type=2) -------------->|
|<- bare ACK -------------------------------|
| |
|-- SIGNATURE_REQUEST (cmd_type=3) ------->|
|<- SIGNATURE_REPLY (54 bytes) -------------|
|-- bare ACK ------------------------------>|
| |
|-- GENERIC_SCRIPT Script7 (ROE init) ---->|
|<- bare ACK or SCRIPT_DOWNLOAD_REPLY ------|
| |
|-- GENERIC_SCRIPT Script1 (dark acq) ---->|
|<- bare ACK -------------------------------|
| |
|-- EXECUTE_SCRIPT (cmd_type=6) ---------->|
|<- bare ACK -------------------------------|
|<- EXECUTE_SCRIPT_REPLY (~230ms) ----------|
|-- bare ACK ------------------------------>|
|<- DETECTOR_STATE_NOTIFY (~890ms) ---------| state_id=17
|-- bare ACK ------------------------------>|
| |
|<- EXECUTION_COMPLETE (0x10000) -----------|
|-- bare ACK ------------------------------>|
| |
|<- IMAGE_XFER_STATUS_QUERY (0x30000) ------|
|-- bare ACK ------------------------------>|
|-- IMAGE_XFER_STATUS_REPLY (cmd_type=9) ->| numMissed=0
|<- bare ACK -------------------------------|
</pre>

===Sequence Counter Rules===

*<code>SYSTEM_STARTUP</code> always uses <code>SeqId = 0</code>.
*After the first beacon, set host SeqId to beacon_SeqId + 1.
*Increment SeqId by 1 for every new data packet (CmdFlag=0).
*Bare ACKs echo the SeqId of the packet being acknowledged and do not consume a SeqId.
*The detector silently drops any packet with a SeqId it has already processed, so never reuse one.

==Script Download==

The detector does not have fixed acquisition commands. Instead the host
downloads small programs, called scripts, that the detector stores by ID and
then runs on command. A script is a sequence of primitive operations: program
the ROE (readout electronics) registers, wait, acquire an image, signal an
event. The acquisition behavior of the panel is defined entirely by these
downloaded scripts, which are taken from the application mode XML files (for
example IDC_URP_SE_2200.xml for single energy, 2048 by 2048).

===The GENERIC_SCRIPT command===

A script is sent to the detector with the GENERIC_SCRIPT command, cmd_type 5.
The wire format is:

[cmd_type : 4 LE] = 5
[length : 4 LE] = 8 + sum(command sizes) + 2
[script header : 8 bytes]
[packed command 1]
[packed command 2]
...
[terminator : 2 bytes] = 00 00

The 8 byte script header is:

{| class="wikitable"
!Offset!!Size!!Field!!Meaning
|-
|0||2 LE||scriptID||the slot the script is stored in
|-
|2||2 LE||repeatCount||0 = run once, 65535 = loop forever
|-
|4||4 LE||repeatEvent||event ID that breaks an infinite loop (0 if unused)
|}

Note: the application mode XML lists a fourth header value, ROEdata. This is a
substitution source for the script's commands, not a field on the wire. The wire
header is exactly 8 bytes.

===Packed command primitives===

Each command inside the script starts with a one byte DETECTORCODE that selects
its type and length:

{| class="wikitable"
!DETECTORCODE!!Command!!Size!!Layout (after the code byte)
|-
|1||Acquisition||17||typeMode:1, imageId:1, noScrubs:1, scrubDuration:4 LE, maxExposeTime:4 LE, tailTime:4 LE, transferMode:1
|-
|2||ROE command||14||responseFlag:1, timerValue:4 LE, roeCmd:4 LE, roeData:4 LE
|-
|3||Send host event||5||eventId:4 LE
|-
|4||Wait for host event||9||eventId:4 LE, timeout:4 LE
|-
|5||Delay||5||delayMicroseconds:4 LE
|}

For example, a ROE command sets a readout register (roeCmd, roeData) and an
Acquisition command triggers the actual exposure window and image readout.

===Download sequence===

#The host sends the GENERIC_SCRIPT packet for a given scriptID.
#The detector replies with a bare acknowledgement carrying the same sequence ID. (It may also send a GENERIC_SCRIPT status reply with a status byte; status 0 means accepted.)
#The host repeats this for each script it wants resident on the detector.
#When ready, the host sends EXECUTE_SCRIPT, cmd_type 6, which runs the stored scripts. During and after execution the detector sends status notifications, and finally EXECUTION_COMPLETE, cmd_type 0x10000.

Scripts are persistent for the session: once downloaded they can be executed
without resending.

===The standard script set===

The single energy mode downloads four scripts in order. The scriptID in the
header is the slot; the XML refers to them by a separate DETECTOR_SCRIPT_ID.

{| class="wikitable"
!scriptID!!Purpose!!Notes
|-
|7||ROE initialization||Scan setup plus a sequence of zero pulses, ends by sending host event 17
|-
|8||Standby loop||repeatCount 65535, broken by event 41; keeps the panel idle between acquisitions
|-
|0||Standard acquisition||Requires a real X-ray exposure to complete
|-
|1||Dark / offset acquisition||Completes with no X-ray; used to test the full flow
|}

For a no X-ray test, download script 7 then script 1 and execute. The detector
runs the ROE init, performs the dark acquisition, and reports
EXECUTION_COMPLETE in a few seconds.

===Inspecting the encoded scripts===
See [[#Main test py script: Usage and Parameters|Main test py script]]
The exact wire bytes of every built script can be printed without touching the
detector:

python flashpad_acquire.py --dump-scripts

This shows the full GENERIC_SCRIPT encoding (header, packed commands, and
terminator) as hex, which is useful for verifying the format against the XML.

==Sensor Readout and Host Registration==

This section documents the reverse engineered sensor telemetry interface and the
host registration (pairing) mechanism of the GE Optima XR200/220 AMX FlashPad
(URP detector, SuperBee, FW 1.6.0.4.2.0.1.3). All commands are PDAP over UDP to
the detector at port 8100; replies return to the host command port.

===Sensor Readout===

The detector exposes an analog sensor interface (the DEM, Detector Environment
Monitor) that is independent of the image transfer path and works regardless of
acquisition state.

====Commands====

{| class="wikitable"
!cmd_type!!Meaning!!Request payload!!Reply payload
|-
|0x7900||Raw sensor read||[sensorId:4 LE]||[value:4 LE] (12 bit ADC count)
|-
|0x7902||Converted sensor read||[sensorId:4 LE]||[value:4 LE] (engineering units, signed)
|-
|0x7904||Detailed / radio||[selector:4 LE]||[value:4 LE]
|}

Note: cmd 0x7902 IS supported on this firmware and returns calibrated
engineering units (millivolts for the supply rails, signed; 0.1 degree C for
temperatures). Earlier documentation that marked 0x7902 as unsupported is
incorrect. The host side conversion coefficients are not required; the detector
performs the conversion internally.

The full sensor map (name, sensorId) was recovered from the detector's own
[Sensor] configuration table, read back over the upload interface (see the
Registration section for the read protocol).

====Power rails (live readings)====

All supply rails read correctly via 0x7902 and are within normal range for a
flat panel detector. Representative readings:

{| class="wikitable"
!Sensor!!sensorId!!Converted!!Value
|-
|DCIN_RAW||10||12100 mV||+12.10 V (main DC input)
|-
|LCORE_UNREG||11||1724 mV||+1.72 V
|-
|LPANA_UNREG||12||5776 mV||+5.78 V
|-
|LNANA_UNREG||13||-5801 mV||-5.80 V
|-
|SCAN_VCC||14||5086 mV||+5.09 V (gate driver)
|-
|P5V_REF||16||5025 mV||+5.03 V (5 V reference)
|-
|V_ON||17||11085 mV||+11.09 V (TFT gate on)
|-
|V_OFF||18||-12378 mV||-12.38 V (TFT gate off)
|-
|V_COMMON||19||-9385 mV||-9.39 V
|-
|3V3||29||3177 mV||+3.18 V (3.3 V logic)
|-
|VCC_UNREG||37||3399 mV||+3.40 V
|-
|PARCPREG||38||3768 mV||+3.77 V (ARC preamp +)
|-
|NARCPREG||39||-3732 mV||-3.73 V (ARC preamp -)
|-
|PANA_UNREG||45||18352 mV||+18.35 V (photodiode bias +)
|-
|NANA_UNREG||46||-19251 mV||-19.25 V (photodiode bias -)
|}

Switched rails that are inactive while the panel is idle (PARCVA_U,
P5VA_SW, N5VA_SW, FGATE_NVC_L, FGATE_PVC_L, etc.) read at or near zero.

====Known limitations====

*'''Temperatures''' (Temp_Surface, sensorId 336; Temp_Panel, sensorId 352): the raw 0x7900 read rails at 0x3FF (1023, the ADC maximum), indicating an open thermistor path while the panel is idle. This is a hardware/state condition, not a command problem, and the temperature is not readable from the host in this state.
*'''Unimplemented sensors''': sensorIds 70 (Accelerator), 78 (Gravity), and 256 to 259 (Battery status, name, life, capacity), and 272 (Grid status) are not implemented on this DEM. The detector returns the leftover conversion register contents (a duplicate of a previously read sensor) rather than a real value, so these rows must be discarded.
*'''Accelerometer''': functional through a separate addressing scheme using raw cmd 0x7900 with selectors 0x42 (X), 0x43 (Y), 0x44 (Z), returning 12 bit per axis counts.

===Host Registration (Pairing)===

URP stands for Unified Registration Protocol. The detector maintains a host
list in its internal NOR flash. Image data is delivered only to a registered
primary host, so registration is a prerequisite for image transfer.

====Host identity (MAC and HostId)====

Each host is identified by a 16 character HostId derived deterministically from
the host's eth0 MAC address. The derivation (from the vendor generateHostId
script) is:

#Take the eth0 MAC, remove the colon separators, convert to upper case (12 hex characters).
#Prepend the last 4 characters to the full 12 characters.
#The result is 16 hex characters.

Example: MAC 00:6f:00:01:0a:3a becomes 006F00010A3A, then the last four (0A3A)
are prepended, giving HostId 0A3A006F00010A3A.

====HostList structure====

The host list is stored in flash at offset 0x940000 and can be read back over
the upload interface as data category 0x71. Layout:

Offset Size Field
0x00 16 DetectorDeviceId (ASCII)
0x10 16 ConnectionSecretKey (ASCII; "XXXXXXXXXXXXXXXX" when unset)
0x20 16 DetectorName (ASCII)
0x30 16 DetectorCode (ASCII)
0x40 2 CurrentNumberOfHosts (uint16 LE)
0x42 2 IndexToPrimaryHost (uint16 LE; 0xFFFF = none)
0x44 144*N Host entries, 144 bytes each:
+0x00 16 HostId (ASCII)
+0x10 .. host name / department string
+0x50 .. location string
... 4 CRC (big endian; see below)

====HostList from the unit under test====

Detector: MAC 40:F4:A0:00:78:4D, serial UA45829-7, model 5340000-7,
firmware 1.6.0.4.2.0.1.3. DetectorName starShape_green. ConnectionSecretKey
unset. CurrentNumberOfHosts = 3, IndexToPrimaryHost = 0xFFFF (no primary host).

{| class="wikitable"
!Index!!HostId!!Derived MAC!!Name
|-
|0||2C6400045FB42C64||00:04:5F:B4:2C:64||Haus 207 / ITS
|-
|1||B044E8393512B044||E8:39:35:12:B0:44||Not Initialized
|-
|2||5CF800045FB15CF8||00:04:5F:B1:5C:F8||Not_Initialized
|}

The unit is therefore not factory fresh; it carries registrations from a prior
deployment, but no primary host is currently designated.

====Checksum (CRC)====

The HostList (and other flash data blobs) are protected by a 4 byte trailing
CRC. Parameters:

*Polynomial: 0x04C11DB7
*Initial value: 0
*MSB first, augmented message style (the data bit is shifted into the LSB; no input or output reflection; no final XOR)
*Stored big endian

To generate: compute the CRC over the data followed by four zero bytes, then
append the result big endian. Verification: the CRC over (data plus stored CRC)
equals zero.

def crc(data, poly=0x04C11DB7, init=0):
c = init
for byte in data:
for bit in (0x80,0x40,0x20,0x10,0x08,0x04,0x02,0x01):
msb = c & 0x80000000
c = (c << 1) & 0xFFFFFFFF
if byte & bit: c |= 1
if msb: c ^= poly
return c
# trailer = crc(data + b"\x00\x00\x00\x00"), stored big endian

====Read and write transport====

Data blobs (including the HostList) are moved with a configure / buffer /
finalize sequence.

Read (upload, detector to host), non destructive:

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x13||[uploadId:4 LE]||[status:1][totalSize:4 LE]
|-
|Buffer||0x14||[bufId:4 LE][numBytes:4 LE]||[bufId:4 LE][numBytes:4 LE][data]
|}

Write (download, host to detector), persistent (writes flash):

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x0E||[downloadId:4 LE][totalSize:4 LE]||[status:1]
|-
|Buffer||0x0F||[bufId:4 LE][numBytes:4 LE][data]||[status:1][reserved:4]
|-
|Commit||0x10||(empty)||[status:1]
|}

bufId is a zero based chunk index. The HostList uses id 0x71 for both read and
write. The commit command (0x10) reuses the firmware flash path, so a malformed
download can corrupt flash; the operation is irreversible on this hardware.

====Registering a new host====

To register a host and make it the image destination, read the current HostList
(0x71), append a 144 byte entry carrying the new HostId, increment
CurrentNumberOfHosts, set IndexToPrimaryHost to the new entry's index,
recompute the trailing CRC, and write the blob back via the download sequence
(0x0E / 0x0F / 0x10).

===Reading the Drop and Shock Event Log===

The detector contains an accelerometer based shock watchdog that records drop
and impact events into non volatile memory. This log is useful when evaluating a
used unit, since it reveals how many serious shocks the panel has survived and
when. The same data is held both in the main flash (read over the network) and
in the small onboard EEPROM on the detector PCB.

====How to read it====

The shock log is exposed as data category 0x72 on the upload (read) interface.
It is retrieved with the standard non destructive configure and buffer sequence
(cmd 0x13 to configure, cmd 0x14 to pull the chunks). On the unit under test the
blob is 3001 bytes of plain text in the GE .dyn configuration format, so no
decoding is required beyond reading it as ASCII.

The same records are mirrored in binary form in the onboard 24LC256 EEPROM
(32 KB I2C part) for anyone reading the hardware directly.

====Example output====

The following is the actual log read from detector serial UA45829-7. The file
has two parts: a list of individual events (DetectorShockEvents) and a summary
block (DetectorShockData). Each event carries a record key, a severity, a
timestamp, and the peak acceleration on each axis. Two representative records:

<DetectorShockEvents>
[149266438700135]
Severity.Type = String
Severity.Val = Serious
TimeStamp.Type = String
TimeStamp.Val = 2017-4-20,6:59:47
ValidTime.Type = Number
ValidTime.Val = 0
VibrationX.Type = Number
VibrationX.Val = 0
VibrationY.Type = Number
VibrationY.Val = 0
VibrationZ.Type = Number
VibrationZ.Val = 135

[1592113924-1720-113]
Severity.Val = Serious
TimeStamp.Val = 2020-6-14,7:52:4
VibrationX.Val = -172
VibrationY.Val = 0
VibrationZ.Val = -113

The summary block at the end lists the totals and an index of all event keys:

[DetectorShockData]
LastKnownGoodTime.Val = 2024-4-4,6:53:59
NumberOfL3Events.Val = 0
NumberOfL5Events.Val = 7
ShockDataTimeList.Val = { 1643260890-1320-119, 163626503500-123,
160818190500-101, 160524243000170, 1592113924-1720-113,
157804584600183, 149266438700135 }

====Interpreting the records====

The record key encodes the event time and the peak axis values (an epoch style
timestamp followed by the concatenated vibration readings), so it is unique per
event. The VibrationX, VibrationY, and VibrationZ values are signed peak
acceleration counts on each axis. Severity is reported as Serious for all
logged events on this unit, which corresponds to the L5 (highest) severity class
counted in the summary.

The seven recorded events for this detector:

{| class="wikitable"
!Date and time!!VibrationX!!VibrationY!!VibrationZ
|-
|2017-04-20 06:59:47||0||0||135
|-
|2020-01-03 11:04:06||0||0||183
|-
|2020-06-14 07:52:04||-172||0||-113
|-
|2020-11-13 05:40:30||0||0||170
|-
|2020-12-17 06:11:45||0||0||-101
|-
|2021-11-07 07:03:55||0||0||-123
|-
|2022-01-27 06:21:30||-132||0||-119
|}

====Reading the summary fields====

{| class="wikitable"
!Field!!Meaning
|-
|LastKnownGoodTime||Timestamp of the last successful self check (here 2024-04-04), the most recent point at which the detector was known to be operating normally
|-
|NumberOfL3Events||Count of lower severity (L3) shock events; zero on this unit
|-
|NumberOfL5Events||Count of high severity (L5) shock events; seven on this unit, matching the seven records above
|-
|ShockDataTimeList||Index of all stored event keys, newest first
|}

On this example the panel logged seven serious impacts over roughly five years
of field use and last reported a good self check in April 2024.

==FlashPad Detector: Internal Flash Dump and Data Files==

This section documents how the full contents of the detector's internal flash
were extracted over the network and what each recovered file contains. The
detector under test is a GE Optima XR200/220 AMX FlashPad (URP detector,
serial UA45829-7, MAC 40:F4:A0:00:78:4D, firmware 1.6.0.4.2.0.1.3).

===Background===

The detector's main storage is a Spansion/Cypress S29GL512P (marked
GL512P10FFCR2), a 512 Mbit (64 MB) parallel NOR flash. A direct chip read
requires bus access or desoldering and a programmer. However, the detector
firmware exposes its stored data blobs, including a full image of the flash,
through the read (upload) side of the data transport protocol. This makes a
complete, byte exact dump possible over UDP with no physical access.

===Extraction method===

The upload interface is the read counterpart of the firmware download path and
is non destructive (it only reports and returns data; nothing is written).
Each data category is identified by an 8 bit upload ID:

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x13||[uploadId:4 LE]||[status:1][totalSize:4 LE]
|-
|Buffer||0x14||[bufId:4 LE][numBytes:4 LE]||[bufId:4 LE][numBytes:4 LE][data]
|}

A configure request returns status 0 and a total size for a valid ID, or a non
zero status for an unsupported ID. The dump tool sweeps all IDs from 0x00 to
0xFF, and for every readable ID it pulls the full blob in fixed size chunks
(bufId is a zero based chunk index) and writes it to a file. The 64 MB flash
image transfers as 65536 chunks of 1024 bytes.

===Recovered files===

A sweep of the unit returned 18 readable blobs:

{| class="wikitable"
!Upload ID!!Size (bytes)!!Contents
|-
|0xFD||67108864||Full 64 MB NOR flash image
|-
|0xFF||16777216||16 MB region (firmware / FPGA mirror or image buffer)
|-
|0xFE||524288||Bootloader (512 KB; SPI loader, Nios reset code)
|-
|0x10||6815783||Calibration map, dose level 1
|-
|0x11||6815783||Calibration map, dose level 2
|-
|0x12||6815783||Calibration map, dose level 3
|-
|0x06||49254||Table referencing conditioner/generator serial UA2010-8U005
|-
|0x50||19938||Per mode calibration coefficients
|-
|0x51||19582||Per mode calibration coefficients
|-
|0x07||12187||Sensor conversion table (text; see Sensor Readout)
|-
|0x72||3001||Shock / drop event log (text)
|-
|0x0E||624||Panel geometry / configuration (binary)
|-
|0x71||504||Host list / registration record (see Host Registration)
|-
|0x0F||233||Host to detector compatibility table (text)
|-
|0x08||62||Serial and model strings
|-
|0x0A||48||Manufacturing codes
|-
|0x52||30||Serial string
|-
|0x0B||24||Small marker / identifier
|}

===Flash image layout (upload ID 0xFD)===

A block scan of the 64 MB image shows the following regions:

{| class="wikitable"
!Range!!Contents
|-
|0x000000 to 0x800000||Firmware and FPGA configuration
|-
|0x800000 to 0x940000||Sparse configuration area
|-
|0x940000||Host list / registration record (matches upload ID 0x71)
|-
|0x1000000 to 0x2800000||Calibration and image data (16 to 40 MB)
|-
|0x2800000 to 0x4000000||Erased / unused (40 to 64 MB)
|}

The host list strings (the DetectorName starShape_green, the registered host
name Haus 207 / ITS, and the unset ConnectionSecretKey placeholder) appear at
0x940000, confirming that the 504 byte 0x71 read maps to this flash region.

===Notes on individual files===

*'''0x07 (sensor table)''': plain text, header DetectorSerialNumber = UA45829-7, revision 1.2. Lists every sensor by name, command (0x7902), and sensorId. Also carries panel geometry in its [Common] section: 16 bit depth, 2048 by 2048 pixels, active area from (12, 12) to (2035, 2035), pixel pitch 0.2 mm, corner radius 1416.8, panel saturation 150.
*'''0x10, 0x11, 0x12 (calibration maps)''': three distinct blobs of identical size, corresponding to the low, medium, and high dose calibration sets. Each begins with the firmware version and serial (header bytes 01 06 00 04 02 00 01 03 followed by the serial). Required to apply gain and offset correction to raw images.
*'''0xFE (bootloader)''': contains the strings spi_load.S and ../../boot and Nios II reset vector code.
*'''0x72 (shock log)''': text records of drop / vibration events with timestamps and per axis values; the same data is mirrored in the detector's small onboard EEPROM.
*'''0x06''': references a different serial, UA2010-8U005, likely the conditioner or generator board rather than the panel.

===Significance===

The complete flash image and all calibration data are recoverable over the
network without opening the detector, providing a full byte exact backup of the
unit before any write operation. The calibration maps are needed for image
correction, and the firmware image (the live, deployed build) is more complete
than the partial firmware files shipped on the recovery media.

==Teardown / Internal Pictures / Hardware analysis==

<gallery mode="packed" heights="200">
File:GE Flashpad under the hood.jpg|the Carbon fiber sleeve is held by 9 screws and can taken off without force.
File:Ge flashpad powersupply pcb in handle.jpg|Power supply PCB
File:Ge flashpad uwb board pcb.jpg|UWB PCB for Wireless USB using a RTU7105
File:Ge flashpad uwb pcb backside.jpg|Backside of UWB PCB
File:Ge flashpad power supply pcb backside.jpg|Backside of Power supply PCB
File:Ge flashpad main pcb closeup1.jpg|Main area of the PCB with its Altera Cyclone 3 FPGA
File:Ge flashpad main pcb closeup2.jpg|AD7892 is a 600ksps 12bit ADC, SN74LVC8T245 a 8bit bus transceiver and DG9408EDN a 8ch MUX
File:Ge flashpad bottom connector ethernet isolation pcb.jpg|Isolation PCB for bottom connector
File:Ge flashpad main pcb powersupply section.jpg|Powersupply section for FPGA and ROIC
File:Ge flashpad main pcb closeup 3.jpg|AD9764AR 14-Bit, 125 MSPS DAC and DS1682 integrated elapsed-time recorder
File:Ge flashpad main pcb closeup 4.jpg|Accelerometer is a 834-0500 500G 3 Axis unit, and TJ500AE SPDT gigabit LAN switch
File:Ge flashpad bottom connector.jpg|bottom connector for docking stand
File:Ge flashpad main pcb closeup 5.jpg|Ethernet transformers and ADM34 RS-485/RS-422 Transceiver
File:Ge flashpad main pcb closeup 6.jpg|Altera EPM570f100c5n CPLD
File:Ge flashpad main pcb closeup 7.jpg|Spansion GL512P10FF1R1 512 Mbit NOR flash IC holding everything
File:Ge flashpad main pcb closeup 8.jpg|24LC256I 32k EEPROM for storing the accelerometer events
</gallery>

==Main test py script: Usage and Parameters==

current iteration found here: https://pastebin.com/vEfAresk

flashpad_acquire.py is a single file Python 3 tool that speaks the FlashPad
URP/PDAP protocol over UDP. It implements discovery, the control handshake,
script download and execution, sensor readout, full data backup, and the host
registration (pairing) write. It requires only the Python standard library.

===Default network configuration===

These defaults match the values in ConnectionPoint.cfg and can be overridden on
the command line.

{| class="wikitable"
!Setting!!Default!!Meaning
|-
|Detector IP||192.168.1.30||the panel; listens for all commands on UDP 8100
|-
|Host IP||192.168.1.1||this machine, announced in SYSTEM_STARTUP
|-
|Detector port||8100||where commands are sent
|-
|Host command port||5550||where the detector returns protocol replies
|-
|Host image port||6660||where pixel data would stream
|-
|Discovery port||4500||where the detector sends its beacons
|}

===Connection and general options===

{| class="wikitable"
!Option!!Default!!Effect
|-
| --detector-ip IP||192.168.1.30||detector address
|-
| --host-ip IP||192.168.1.1||host address sent in SYSTEM_STARTUP
|-
| --output-dir DIR||.||where raw images are written
|-
| --timeout SECONDS||5.0||UDP receive timeout
|-
| --exec-timeout SECONDS||60||how long to wait for EXECUTION_COMPLETE
|-
| --skip-discovery||off||send SYSTEM_STARTUP once and proceed, skipping the discovery loop
|-
| --quiet||off||suppress the verbose per packet log
|}

===Read and diagnostic modes (non destructive)===

These only read from the detector. None of them write anything.

{| class="wikitable"
!Option!!What it does!!What to expect
|-
| --sensors||Reads the full 32 entry sensor table using cmd 0x7902 (converted) and 0x7900 (raw), side by side.||A decoded table of supply rails in volts. Temperatures show as railed. Unimplemented sensors (accelerometer DEM id, battery, grid) are flagged as stale.
|-
| --no-roe-init||With --sensors, skips the Script7 ROE init before reading.||Slightly faster sensor read, marginally less reliable.
|-
| --probe-data||Reads DetectorInfo, the HostList (registration state), and cal results via the upload protocol (cmd 0x13/0x14).||A hexdump and text decode of each. Shows whether any host is registered and which HostId the detector expects.
|-
| --backup [DIR]||Sweeps all upload IDs 0x00 to 0xFF and saves every readable blob to DIR/detector_backup_timestamp/.||A manifest plus one .bin per readable ID, including the full 64 MB flash image and the calibration maps. Do this before any write. Large blobs take a few minutes each.
|-
| --backup-range LO-HI||Limits the --backup sweep, for example 0x40-0xA0.||Faster, partial backup.
|-
| --dump-scripts||Prints the wire bytes of all built scripts as hex and exits.||No network activity; useful for inspecting the script encoding.
|-
| --listen||Passively listens on the host command port for 30 seconds.||Prints any packets the detector sends; useful for watching beacons.
|}

===Acquisition modes===

The default invocation (no mode flag) runs a standard acquisition, which
requires an actual X-ray exposure to complete.

{| class="wikitable"
!Option!!What it does!!What to expect
|-
|(no flag)||Standard acquisition (Script 0).||Needs an X-ray exposure to reach EXECUTION_COMPLETE.
|-
| --dark||Runs the dark/offset acquisition (Script 1) before the standard one.||Two acquisitions; the dark one needs no X-ray.
|-
| --dark-only||Runs only the dark acquisition (Script 1).||Completes in a few seconds with no X-ray. The detector acquires and holds an 8 buffer image. Best way to test the full flow.
|-
| --no-standby||Omits the Script 8 standby loop.||Use if the standby loop blocks acquisition.
|-
| --two-exec||Executes Script 7 alone, waits, then Script 1. Only with --dark-only.||Tests the two stage execution hypothesis.
|-
| --parallel||Answers the detector status query (0x30000) with the cmd 0x99 ParallelImageTransfer reply instead of cmd 9.||Experiment to see if the parallel reply triggers a pixel push. (Result so far: it does not.)
|-
| --sweep-acq||Sweeps the dark acquisition across type_mode and transfer_mode values, watching for a 0x0F pixel push.||Non destructive experiment; reports which combination, if any, makes the detector stream.
|-
| --preview||Single dark acquisition on the preview path (transfer_mode 2, 4 buffer image). Watches port 6660 for a push.||One clean connection; run a packet capture on the detector address in parallel.
|}

Note: at present the detector acquires and holds an image but does not push the
0x0F pixel frames. The acquisition modes complete the handshake and acquisition,
but image streaming is still being investigated.

===Registration and write operations===

These can write to the detector's flash. Every write is a dry run by default and
only takes effect when --commit is added. Always run --backup first.

{| class="wikitable"
!Option!!What it does
|-
| --register-self||Adds this host to the detector HostList and sets it as the primary host, so the detector should stream images to it. Appends an entry, sets IndexToPrimaryHost, recomputes the CRC, and writes via id 0x71. Dry run unless --commit.
|-
| --host-mac MAC||The MAC of the interface talking to the detector, used to derive this host's HostId for --register-self. Default 00:6f:00:01:0a:3a.
|-
| --smoke-test-write||Reads the HostList and writes back the identical bytes to validate the write and commit path without changing anything. Dry run unless --commit.
|-
| --restore-hostlist FILE||Writes a saved HostList blob (for example detector_backup_*/upload_0x71_504.bin) back to the detector. This is the undo button. Dry run unless --commit.
|-
| --commit||Arms the actual flash write for the operations above. Without it they only print what they would do. This writes the detector's flash and is irreversible at the chip level, although the HostList region can be restored from a backup.
|}

===Typical workflow===

#Read the current state: <code>python flashpad_acquire.py --probe-data</code>
#Make a full backup: <code>python flashpad_acquire.py --backup</code>
#Check sensors and power rails: <code>python flashpad_acquire.py --sensors</code>
#Dry run the registration: <code>python flashpad_acquire.py --register-self --host-mac YOUR:MAC</code>
#When satisfied, commit it: add <code>--commit</code>
#If needed, undo: <code>python flashpad_acquire.py --restore-hostlist detector_backup_*/upload_0x71_504.bin --commit</code>

==Known Dead Ends==

Things that were tried and did not work or led nowhere:

;0xBEEF (48879) as reply port
:This was a bug in early test scripts. The port has no meaning in the protocol. Use 5550.

;CmdFlag=1 as data packet flag
:Early scripts had the URP fields swapped, setting CmdFlag=1 on data packets. The detector ignores all PDAP content in these packets. Power cycle the detector if this happened, it may retain stale port state.

;Image data on alternate ports
:Tried listening on 48879, 6660, 5550, 8100, 1050, 6661, 9999, 4444, 7000, 7001, 9001. Nothing arrived on any of them.

;PORT_SETUP byte order (big-endian)
:Current implementation sends port fields as big-endian. If the detector reads them as little-endian it computes port 44565 and 1050 instead of 5550 and 6660, which would explain why no image data arrives. Not yet confirmed.

;Image data streaming automatically after EXECUTE_SCRIPT
:Frames may not push during execution at all. The detector may require an explicit IMAGE_RETRIVAL_REQUEST (cmd_type=0x41) and IMAGE_RETRIVAL (cmd_type=0x98) after the 0x30000 notification before it streams anything. Not yet tested.

User:Gamerpaddy

2026-06-11T12:40:36Z

Gamerpaddy: /* GE Medical Flashpad Digital X-ray Detector changes*/

==About==

'''YouTube''': [https://www.youtube.com/gamerpaddy gamerpaddy YouTube Channel] 
'''Email''': gamerpaddyschannel at gmail dot com 
'''OSHW Repository''': [https://oshwlab.com/gamerpaddy gamerpaddy open source hardware lab]

===Biography===

I grew up in germany where every once in a while people would put their broken and unused household electronics on the streets for disposal. I picked up whatever I could, took it apart and tried to understand how it worked.

Over the years that turned from just taking things apart into actually fixing and reverse engineering them. I built myself an electronics workshop and gathered knowledge from whatever I had on hand or access to, learning by doing and from the resources available on the internet. That eventually led to designing and manufacturing things myself, a few of which ended up helping other people too.

I am a full supporter of the right to repair movement and contribute through work, knowledge and helping others where I can.

===Projects===

====Yamaha EBike Battery Dongle====

Starting in 2016 I worked on an emulator module to use third-party lithium-ion batteries on Yamaha powered e-bikes. The module emulates the datastream of a healthy battery and sends it to the Yamaha PW series engine, allowing any power source in the 10-cell lithium-ion voltage range (27-42V) to be used in place of the original battery.

Through this work most of the Yamaha battery communication protocol was figured out, which let people extend their range with DIY batteries and repair their failed originals, which made up 30-50% of the cost of a new e-bike. Discussion and findings were shared in the german pedelec forums [https://www.pedelecforum.de/forum/index.php?threads/yamaha-reverse-engineering.39480/].

More information on the [[Yamaha EBike Battery Dongle]] wiki page.

====Topping PA5 Amplifier D01 Replacement Module====

In 2023 I worked on a replacement module to help people repair their failed Topping PA5 Class-D Amplifiers, as documented in the audiosciencereview forums [https://www.audiosciencereview.com/forum/index.php?threads/topping-pa5-fix-d01-module-replacement-for-everyone.44219/#post-1572910].

The original units had a manufacturing flaw where potting compound used to protect the pre-amplifier module from being copied would expand and contract during thermal cycling, eventually cracking solder joints and taking the whole amplifier with it. I depotted the original module, reverse engineered it, and rebuilt it with a more efficient layout for cheaper manufacturing. It has since been built and used by people all over the world with none of the replacements failing so far. In some countries warranty claims were not a viable option due to the product being shipped from overseas, making a DIY fix the only practical solution.

More information on the [[Topping PA5]] wiki page.

====GE Medical Flashpad Digital X-ray Detector====

I got hold of a GE Flashpad, a 2048x2048 digital radiography image sensor originally used in GE Optima 220AMX mobile X-ray units. These show up on the used market mostly in unknown or broken condition.

I tore it down, documented the hardware and spent time reverse engineering the URP/PDAP communication protocol it uses over Ethernet. I got to the point where the detector can be fully identified over the network, scripts can be downloaded and executed, and a acquisition run can be driven from a custom host implementation without any GE software involved.

More information on the [[GE Medical Flashpad Digital Xray Detector]] wiki page.

User:Gamerpaddy

2026-06-11T12:38:33Z

Gamerpaddy: added ge flashpad project

== About ==

'''YouTube''': [https://www.youtube.com/gamerpaddy gamerpaddy YouTube Channel] 
'''Email''': gamerpaddyschannel at gmail dot com 
'''OSHW Repository''': [https://oshwlab.com/gamerpaddy gamerpaddy open source hardware lab]

=== Biography ===

I grew up in germany where every once in a while people would put their broken and unused household electronics on the streets for disposal. I picked up whatever I could, took it apart and tried to understand how it worked.

Over the years that turned from just taking things apart into actually fixing and reverse engineering them. I built myself an electronics workshop and gathered knowledge from whatever I had on hand or access to, learning by doing and from the resources available on the internet. That eventually led to designing and manufacturing things myself, a few of which ended up helping other people too.

I am a full supporter of the right to repair movement and contribute through work, knowledge and helping others where I can.

=== Projects ===

==== Yamaha EBike Battery Dongle ====

Starting in 2016 I worked on an emulator module to use third-party lithium-ion batteries on Yamaha powered e-bikes. The module emulates the datastream of a healthy battery and sends it to the Yamaha PW series engine, allowing any power source in the 10-cell lithium-ion voltage range (27-42V) to be used in place of the original battery.

Through this work most of the Yamaha battery communication protocol was figured out, which let people extend their range with DIY batteries and repair their failed originals, which made up 30-50% of the cost of a new e-bike. Discussion and findings were shared in the german pedelec forums [https://www.pedelecforum.de/forum/index.php?threads/yamaha-reverse-engineering.39480/].

More information on the [[Yamaha EBike Battery Dongle]] wiki page.

==== Topping PA5 Amplifier D01 Replacement Module ====

In 2023 I worked on a replacement module to help people repair their failed Topping PA5 Class-D Amplifiers, as documented in the audiosciencereview forums [https://www.audiosciencereview.com/forum/index.php?threads/topping-pa5-fix-d01-module-replacement-for-everyone.44219/#post-1572910].

The original units had a manufacturing flaw where potting compound used to protect the pre-amplifier module from being copied would expand and contract during thermal cycling, eventually cracking solder joints and taking the whole amplifier with it. I depotted the original module, reverse engineered it, and rebuilt it with a more efficient layout for cheaper manufacturing. It has since been built and used by people all over the world with none of the replacements failing so far. In some countries warranty claims were not a viable option due to the product being shipped from overseas, making a DIY fix the only practical solution.

More information on the [[Topping PA5]] wiki page.

==== GE Medical Flashpad Digital X-ray Detector ====

I got hold of a GE Flashpad, a 2048x2048 digital radiography image sensor originally used in GE Optima 220AMX mobile X-ray units. These show up on the used market mostly in unknown or broken condition.

I tore it down, documented the hardware and spent time reverse engineering the URP/PDAP communication protocol it uses over Gigabit Ethernet. I got to the point where the detector can be fully identified over the network, scripts can be downloaded and executed, and a complete dark acquisition run can be driven from a custom host implementation without any GE software involved.

More information on the [[GE Medical Flashpad Digital Xray Detector]] wiki page.

GE Medical Flashpad Digital Xray Detector

2026-06-11T12:29:00Z

Gamerpaddy: /* Overview */

==Overview==
{{Note|UNFINISHED Project, it was not yet possible to retrieve a exposure or dark frame in my testing, further investigation needed. any help is appreciated on recessim discord.}}

The '''GE Flashpad''' is a Digital Radiography image sensor from approximately 2010, originally used in the '''GE Optima 220AMX''' mobile X-ray unit. It was designed to replace analog film in radiology, dramatically reducing image acquisition time from hours to seconds.
[[File:GE Flashpad.jpg|thumb|Flashpad with Anti-Scatter grid (left), manual and recovery dvd for 220amx and tether cord (right)]]
Due to its high original cost and specialized application, used units occasionally appear on professional B2B marketplaces in the $15,000–$50,000 range. On eBay, prices typically fall between $1,500 and $5,000, though units at this price point are often in poor condition and may fail the built-in self-test or not function at all.

{{Note|All findings on this page are based on a single unit and the time spent working on it. Information is subject to speculation and may not be fully accurate.}}

{{Note|AI assistance was used in writing this page for improved formatting and readability, as well as in the process of finding information, testing, and analyzing firmware dumps and backups.}}

All files used and mentioned are found on the official Optima XR220amx Application Software and Linux OS DVD 5406106-10 Rev3, which i cannot provide due to being copyrighted content.
 
==Purpose and Motivation==

This project documents the reverse engineering of the GE FlashPad wireless
digital radiography detector used with the Optima XR200/220 AMX mobile X-ray
system, with the goal of freeing these detectors for independent use.
[[File:Xray capture pcb.png|thumb|Xray capture of a PCB for Reverse Engineering using a different detector]]
Large numbers of these detectors reach the used market, but each one is bound to its original Optima 220 AMX
console. Once separated from that console, or once the console is
decommissioned, the detector is effectively useless even though the hardware is
fully functional. There is a Windows software but it is not obtainable. The aim of this work is to remove that artificial barrier so
that a standalone FlashPad can be paired, configured, and read out by any host,
without the half million dollar console it was sold with.

The intended beneficiaries are:

*Hobbyists, researchers, and engineers who want a high quality flat panel detector for their own imaging projects. for example studying the fluid movement in plants. https://www.youtube.com/watch?v=j-FHbHoiwNk (Xray timelapse by Ben Krasnow / Applied Science using a GE Flashpad)
*Veterinary practices, which can put surplus human grade detectors to good use at a fraction of the cost of new equipment.
*Clinics and hospitals in countries and regions where a complete commercial system is unaffordable, allowing serviceable detectors to keep providing diagnostic imaging instead of being scrapped.

[[File:Xray current clamp multimeter.png|thumb|xray of a current clamp multimeter using a different detector]]
This is done for human good. Every detector returned to service is one less
piece of working medical hardware sent to landfill, and potentially one more
place that can offer X-ray imaging where it otherwise could not.

All files, findings, protocol documentation, and tools produced by this project
are public and open source, so that anyone can study, reproduce, and build on
the work.

==Technical Specifications==
[[File:Ge flashpad tether cable pinout diagram.png|thumb|Pinout Diagram of the Tether cable]]
[[File:Ge flashpad tether wiring for ethernet cable.jpg|thumb|Professional Tether wiring to attach a Ethernet Cable and 12V socket to it.]]
The Flashpad uses a '''~40 × 40 cm CsI scintillator''' bonded to a [[Thin-film transistor|TFT]] photodetector array mounted on glass. The assembly is highly sensitive to shock and impact damage. See section [[#Reading the Drop and Shock Event Log|drop and shock event log]]

{| class="wikitable"
|-
!Parameter!!Value
|-
|Resolution||2048 × 2048 px
|-
|Bit depth||16-bit per pixel
|-
|Spatial resolution||Up to 5 lp/mm (theoretical)
|-
|Scintillator material||Caesium iodide (CsI)
|-
|Detector type||TFT photodetector array (glass substrate)
|-
|Panel size||~40 × 40 cm
|}

The theoretical 5 lp/mm spatial resolution is primarily limited in practice by the focal spot size of the X-ray source. Use of an anti-scatter grid can improve effective resolution.

===Status of Reverse Engineering===

{| class="wikitable"
|-
!What!!Status
|-
|Connect, beacon, ACK||Works
|-
|PORT_SETUP||Works
|-
|SIGNATURE_REQUEST / serial number readout||Works
|-
|Script download (Scripts 7, 8, 1)||Works
|-
|EXECUTE_SCRIPT||Works
|-
|EXECUTION_COMPLETE (dark acquisition)||Works but without image readout its speculation.
|-
|EXECUTION_COMPLETE (standard acquisition)||Needs real X-ray trigger to test
|-
|Image data on port 6660||Does not work yet, under investigation. Will not send Imagedata...
|}

==Hardware Features==

===Shock logging===
The unit contains an internal accelerometer that logs significant shock events — but only when a battery is inserted. As there is no backup battery, shock events occurring while unpowered are not recorded.

===Wireless connectivity===
Some units include a UWB transmitter for Wireless USB; others may be equipped with a Wi-Fi module instead. The detector can also be operated over the tethered connection alone.

===Ethernet interface===
There is a 100MBit Ethernet interface trough the Tether Cable which can be tapped and used for Communication.
Exposed metal contacts on the bottom connector are isolated via relays by default. Enabling Gigabit Ethernet connectivity requires shorting or driving two specific pins. This has not been investigated further at this time.

==Communication Protocol==

This section documents the URP/PDAP protocol used by the GE Flashpad (codename '''Apollo''' (Or FeiTian, Mammo, Gryphon etc.) to communicate with a host over Ethernet. All findings are based on live capture tests, configuration files, and reverse-engineering of the GE SuperBee software stack.

{{Note|All findings are based on a single unit and may not be fully accurate.}}

===Network Setup===

All findings were over Ethernet only, no UWB or WIFI has been used.
Default detector IP is <code>192.168.1.30</code>. Set your host to a static IP in the same subnet, <code>192.168.1.1</code> works fine.

At first by sending random bytes over Python it answered to port 48879 (0xBEEF), which seems to be either the default port or set by Python.
After SYSTEM_SETUP it got set to 5550.

{| class="wikitable"
|-
!Role!!IP!!Port!!Direction
|-
|All commands: host -> detector||192.168.1.30||'''8100''' (UDP)||Host sends here
|-
|Discovery beacons: detector -> host||-||'''4500''' (UDP)||Detector sends here initially
|-
|Protocol replies: detector -> host||-||'''5550''' (UDP)||Detector sends here after setup
|-
|Image pixel data: detector -> host||-||'''6660''' (UDP)||Detector streams frames here
|}

In practice you can listen on port '''5550''' for everything (beacons and replies) by advertising that port in both <code>SYSTEM_STARTUP</code> and <code>PORT_SETUP</code>. The detector sends to whichever port was most recently configured.

===Protocol Layers===

Two layers, carried over UDP:

;URP (Unified Registration Protocol)
:8-byte wrapper on every packet. Handles sequencing and acknowledgement.

;PDAP (Proprietary Detector Access Protocol)
:The actual command layer, present inside URP packets when <code>CmdFlag = 0</code>.

Every UDP packet starts with a URP header:

<pre>
[SeqId : 4 bytes LE] [CmdFlag : 4 bytes LE]
</pre>

*<code>CmdFlag = 0</code> -- data packet, PDAP command follows.
*<code>CmdFlag = 1</code> -- bare ACK, no PDAP body. SeqId echoes the packet being acknowledged.

Both sides must ACK every data packet immediately. The detector silently drops packets with a SeqId it has already seen, so always increment SeqId for each new command.

When CmdFlag is 0, the PDAP header follows immediately:

<pre>
[cmd_type : 4 bytes LE] [payload_len : 4 bytes LE] [payload ...]
</pre>

===Connecting to the Detector===

The connection sequence is:

#Broadcast <code>SYSTEM_STARTUP</code> to tell the detector where to reply.
#The detector sends a <code>BEACON</code> back -- ACK it and sync your sequence counter.
#Send <code>PORT_SETUP</code> to configure the reply and image ports.
#Send <code>SIGNATURE_REQUEST</code> to read the detector identity (serial number, model, firmware, MAC).

====Step 1: SYSTEM_STARTUP====

Broadcast UDP to <code>192.168.1.255:8100</code>. Always uses <code>SeqId = 0</code>.

<pre>
URP : [00 00 00 00] SeqId = 0
[00 00 00 00] CmdFlag = 0
PDAP: [01 00 00 00] cmd_type = 1
[06 00 00 00] payload_len = 6
[15 AE] host reply port = 5550 (big-endian)
[C0 A8 01 01] host IP = 192.168.1.1 (network byte order)
</pre>

<syntaxhighlight lang="python">
import socket, struct

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
sock.bind(("0.0.0.0", 5550))

HOST_IP = "192.168.1.1"
DET_IP = "192.168.1.30"
HOST_PORT = 5550
IMG_PORT = 6660

def make_urp_packet(seq_id, pdap_bytes):
return struct.pack("<II", seq_id, 0) + pdap_bytes

pdap = struct.pack("<II", 1, 6) + struct.pack(">H", HOST_PORT) + socket.inet_aton(HOST_IP)
sock.sendto(make_urp_packet(0, pdap), ("192.168.1.255", 8100))
</syntaxhighlight>

====Step 2: Receiving the BEACON and ACKing====

The detector broadcasts a <code>BEACON</code> (cmd_type=1) roughly every 2 seconds. After sending SYSTEM_STARTUP you should get one quickly. Parse the detector SeqId from the URP header and ACK it:

<syntaxhighlight lang="python">
data, addr = sock.recvfrom(4096)
det_seq = struct.unpack_from("<I", data, 0)[0]

# send bare ACK
ack = struct.pack("<II", det_seq, 1)
sock.sendto(ack, (DET_IP, 8100))

# all subsequent commands start from here
host_seq = det_seq + 1
</syntaxhighlight>

====Step 3: PORT_SETUP====

Tells the detector which host ports to use for replies and image data.

<pre>
PDAP: [02 00 00 00] cmd_type = 2
[04 00 00 00] payload_len = 4
[15 AE] host cmd port = 5550 (big-endian)
[1A 04] host image port = 6660 (big-endian)
</pre>

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 2, 4) + struct.pack(">HH", HOST_PORT, IMG_PORT)
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1
# expect bare ACK from detector
</syntaxhighlight>

====Step 4: Reading the Serial Number (SIGNATURE_REQUEST)====

Empty command, the detector replies with a 54-byte payload containing its identity.

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 3, 0) # cmd_type=3, payload_len=0
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1

# reply is 70 bytes total: 8 URP + 8 PDAP header + 54 payload
data, _ = sock.recvfrom(4096)
payload = data[16:] # skip URP (8) + PDAP header (8)

mac = payload[0:6]
serial = payload[22:34].rstrip(b'\x00 ').decode()
model = payload[34:46].rstrip(b'\x00 ').decode()
fw_bytes = payload[46:54]
firmware = ".".join(str(b) for b in fw_bytes)

print(f"MAC: {':'.join(f'{b:02X}' for b in mac)}")
print(f"Serial: {serial}")
print(f"Model: {model}")
print(f"Firmware: {firmware}")
</syntaxhighlight>

Expected output:
<pre>
MAC: 40:F4:A0:00:78:4D
Serial: UA45829-7
Model: 5340000-7
Firmware: 1.6.0.4.2.0.1.3
</pre>

===Running an Acquisition===

After the connection sequence above, download scripts to the detector and then execute them.

====ROE Initialisation (Script 7)====

Always run this first. It initialises the readout electronics and takes about 4-5 seconds. The detector sends host event ID 17 when done.

====Dark / Offset Acquisition (Script 1)====

No X-ray source required. Runs a dark-field exposure for offset calibration. Use this to verify the acquisition pipeline without a generator.

====Standard Acquisition (Script 0)====

Requires an actual X-ray exposure. <code>EXECUTION_COMPLETE</code> will '''not''' arrive without a real X-ray trigger.

====Sequence Overview====

<pre>
HOST DETECTOR
| |
|-- SYSTEM_STARTUP (broadcast) ----------->|
|<- bare ACK -------------------------------|
|<- BEACON (cmd_type=1) --------------------|
|-- bare ACK ------------------------------>|
| |
|-- PORT_SETUP (cmd_type=2) -------------->|
|<- bare ACK -------------------------------|
| |
|-- SIGNATURE_REQUEST (cmd_type=3) ------->|
|<- SIGNATURE_REPLY (54 bytes) -------------|
|-- bare ACK ------------------------------>|
| |
|-- GENERIC_SCRIPT Script7 (ROE init) ---->|
|<- bare ACK or SCRIPT_DOWNLOAD_REPLY ------|
| |
|-- GENERIC_SCRIPT Script1 (dark acq) ---->|
|<- bare ACK -------------------------------|
| |
|-- EXECUTE_SCRIPT (cmd_type=6) ---------->|
|<- bare ACK -------------------------------|
|<- EXECUTE_SCRIPT_REPLY (~230ms) ----------|
|-- bare ACK ------------------------------>|
|<- DETECTOR_STATE_NOTIFY (~890ms) ---------| state_id=17
|-- bare ACK ------------------------------>|
| |
|<- EXECUTION_COMPLETE (0x10000) -----------|
|-- bare ACK ------------------------------>|
| |
|<- IMAGE_XFER_STATUS_QUERY (0x30000) ------|
|-- bare ACK ------------------------------>|
|-- IMAGE_XFER_STATUS_REPLY (cmd_type=9) ->| numMissed=0
|<- bare ACK -------------------------------|
</pre>

===Sequence Counter Rules===

*<code>SYSTEM_STARTUP</code> always uses <code>SeqId = 0</code>.
*After the first beacon, set host SeqId to beacon_SeqId + 1.
*Increment SeqId by 1 for every new data packet (CmdFlag=0).
*Bare ACKs echo the SeqId of the packet being acknowledged and do not consume a SeqId.
*The detector silently drops any packet with a SeqId it has already processed, so never reuse one.

==Script Download==

The detector does not have fixed acquisition commands. Instead the host
downloads small programs, called scripts, that the detector stores by ID and
then runs on command. A script is a sequence of primitive operations: program
the ROE (readout electronics) registers, wait, acquire an image, signal an
event. The acquisition behavior of the panel is defined entirely by these
downloaded scripts, which are taken from the application mode XML files (for
example IDC_URP_SE_2200.xml for single energy, 2048 by 2048).

===The GENERIC_SCRIPT command===

A script is sent to the detector with the GENERIC_SCRIPT command, cmd_type 5.
The wire format is:

[cmd_type : 4 LE] = 5
[length : 4 LE] = 8 + sum(command sizes) + 2
[script header : 8 bytes]
[packed command 1]
[packed command 2]
...
[terminator : 2 bytes] = 00 00

The 8 byte script header is:

{| class="wikitable"
!Offset!!Size!!Field!!Meaning
|-
|0||2 LE||scriptID||the slot the script is stored in
|-
|2||2 LE||repeatCount||0 = run once, 65535 = loop forever
|-
|4||4 LE||repeatEvent||event ID that breaks an infinite loop (0 if unused)
|}

Note: the application mode XML lists a fourth header value, ROEdata. This is a
substitution source for the script's commands, not a field on the wire. The wire
header is exactly 8 bytes.

===Packed command primitives===

Each command inside the script starts with a one byte DETECTORCODE that selects
its type and length:

{| class="wikitable"
!DETECTORCODE!!Command!!Size!!Layout (after the code byte)
|-
|1||Acquisition||17||typeMode:1, imageId:1, noScrubs:1, scrubDuration:4 LE, maxExposeTime:4 LE, tailTime:4 LE, transferMode:1
|-
|2||ROE command||14||responseFlag:1, timerValue:4 LE, roeCmd:4 LE, roeData:4 LE
|-
|3||Send host event||5||eventId:4 LE
|-
|4||Wait for host event||9||eventId:4 LE, timeout:4 LE
|-
|5||Delay||5||delayMicroseconds:4 LE
|}

For example, a ROE command sets a readout register (roeCmd, roeData) and an
Acquisition command triggers the actual exposure window and image readout.

===Download sequence===

#The host sends the GENERIC_SCRIPT packet for a given scriptID.
#The detector replies with a bare acknowledgement carrying the same sequence ID. (It may also send a GENERIC_SCRIPT status reply with a status byte; status 0 means accepted.)
#The host repeats this for each script it wants resident on the detector.
#When ready, the host sends EXECUTE_SCRIPT, cmd_type 6, which runs the stored scripts. During and after execution the detector sends status notifications, and finally EXECUTION_COMPLETE, cmd_type 0x10000.

Scripts are persistent for the session: once downloaded they can be executed
without resending.

===The standard script set===

The single energy mode downloads four scripts in order. The scriptID in the
header is the slot; the XML refers to them by a separate DETECTOR_SCRIPT_ID.

{| class="wikitable"
!scriptID!!Purpose!!Notes
|-
|7||ROE initialization||Scan setup plus a sequence of zero pulses, ends by sending host event 17
|-
|8||Standby loop||repeatCount 65535, broken by event 41; keeps the panel idle between acquisitions
|-
|0||Standard acquisition||Requires a real X-ray exposure to complete
|-
|1||Dark / offset acquisition||Completes with no X-ray; used to test the full flow
|}

For a no X-ray test, download script 7 then script 1 and execute. The detector
runs the ROE init, performs the dark acquisition, and reports
EXECUTION_COMPLETE in a few seconds.

===Inspecting the encoded scripts===
See [[#Main test py script: Usage and Parameters|Main test py script]]
The exact wire bytes of every built script can be printed without touching the
detector:

python flashpad_acquire.py --dump-scripts

This shows the full GENERIC_SCRIPT encoding (header, packed commands, and
terminator) as hex, which is useful for verifying the format against the XML.

==Sensor Readout and Host Registration==

This section documents the reverse engineered sensor telemetry interface and the
host registration (pairing) mechanism of the GE Optima XR200/220 AMX FlashPad
(URP detector, SuperBee, FW 1.6.0.4.2.0.1.3). All commands are PDAP over UDP to
the detector at port 8100; replies return to the host command port.

===Sensor Readout===

The detector exposes an analog sensor interface (the DEM, Detector Environment
Monitor) that is independent of the image transfer path and works regardless of
acquisition state.

====Commands====

{| class="wikitable"
!cmd_type!!Meaning!!Request payload!!Reply payload
|-
|0x7900||Raw sensor read||[sensorId:4 LE]||[value:4 LE] (12 bit ADC count)
|-
|0x7902||Converted sensor read||[sensorId:4 LE]||[value:4 LE] (engineering units, signed)
|-
|0x7904||Detailed / radio||[selector:4 LE]||[value:4 LE]
|}

Note: cmd 0x7902 IS supported on this firmware and returns calibrated
engineering units (millivolts for the supply rails, signed; 0.1 degree C for
temperatures). Earlier documentation that marked 0x7902 as unsupported is
incorrect. The host side conversion coefficients are not required; the detector
performs the conversion internally.

The full sensor map (name, sensorId) was recovered from the detector's own
[Sensor] configuration table, read back over the upload interface (see the
Registration section for the read protocol).

====Power rails (live readings)====

All supply rails read correctly via 0x7902 and are within normal range for a
flat panel detector. Representative readings:

{| class="wikitable"
!Sensor!!sensorId!!Converted!!Value
|-
|DCIN_RAW||10||12100 mV||+12.10 V (main DC input)
|-
|LCORE_UNREG||11||1724 mV||+1.72 V
|-
|LPANA_UNREG||12||5776 mV||+5.78 V
|-
|LNANA_UNREG||13||-5801 mV||-5.80 V
|-
|SCAN_VCC||14||5086 mV||+5.09 V (gate driver)
|-
|P5V_REF||16||5025 mV||+5.03 V (5 V reference)
|-
|V_ON||17||11085 mV||+11.09 V (TFT gate on)
|-
|V_OFF||18||-12378 mV||-12.38 V (TFT gate off)
|-
|V_COMMON||19||-9385 mV||-9.39 V
|-
|3V3||29||3177 mV||+3.18 V (3.3 V logic)
|-
|VCC_UNREG||37||3399 mV||+3.40 V
|-
|PARCPREG||38||3768 mV||+3.77 V (ARC preamp +)
|-
|NARCPREG||39||-3732 mV||-3.73 V (ARC preamp -)
|-
|PANA_UNREG||45||18352 mV||+18.35 V (photodiode bias +)
|-
|NANA_UNREG||46||-19251 mV||-19.25 V (photodiode bias -)
|}

Switched rails that are inactive while the panel is idle (PARCVA_U,
P5VA_SW, N5VA_SW, FGATE_NVC_L, FGATE_PVC_L, etc.) read at or near zero.

====Known limitations====

*'''Temperatures''' (Temp_Surface, sensorId 336; Temp_Panel, sensorId 352): the raw 0x7900 read rails at 0x3FF (1023, the ADC maximum), indicating an open thermistor path while the panel is idle. This is a hardware/state condition, not a command problem, and the temperature is not readable from the host in this state.
*'''Unimplemented sensors''': sensorIds 70 (Accelerator), 78 (Gravity), and 256 to 259 (Battery status, name, life, capacity), and 272 (Grid status) are not implemented on this DEM. The detector returns the leftover conversion register contents (a duplicate of a previously read sensor) rather than a real value, so these rows must be discarded.
*'''Accelerometer''': functional through a separate addressing scheme using raw cmd 0x7900 with selectors 0x42 (X), 0x43 (Y), 0x44 (Z), returning 12 bit per axis counts.

===Host Registration (Pairing)===

URP stands for Unified Registration Protocol. The detector maintains a host
list in its internal NOR flash. Image data is delivered only to a registered
primary host, so registration is a prerequisite for image transfer.

====Host identity (MAC and HostId)====

Each host is identified by a 16 character HostId derived deterministically from
the host's eth0 MAC address. The derivation (from the vendor generateHostId
script) is:

#Take the eth0 MAC, remove the colon separators, convert to upper case (12 hex characters).
#Prepend the last 4 characters to the full 12 characters.
#The result is 16 hex characters.

Example: MAC 00:6f:00:01:0a:3a becomes 006F00010A3A, then the last four (0A3A)
are prepended, giving HostId 0A3A006F00010A3A.

====HostList structure====

The host list is stored in flash at offset 0x940000 and can be read back over
the upload interface as data category 0x71. Layout:

Offset Size Field
0x00 16 DetectorDeviceId (ASCII)
0x10 16 ConnectionSecretKey (ASCII; "XXXXXXXXXXXXXXXX" when unset)
0x20 16 DetectorName (ASCII)
0x30 16 DetectorCode (ASCII)
0x40 2 CurrentNumberOfHosts (uint16 LE)
0x42 2 IndexToPrimaryHost (uint16 LE; 0xFFFF = none)
0x44 144*N Host entries, 144 bytes each:
+0x00 16 HostId (ASCII)
+0x10 .. host name / department string
+0x50 .. location string
... 4 CRC (big endian; see below)

====HostList from the unit under test====

Detector: MAC 40:F4:A0:00:78:4D, serial UA45829-7, model 5340000-7,
firmware 1.6.0.4.2.0.1.3. DetectorName starShape_green. ConnectionSecretKey
unset. CurrentNumberOfHosts = 3, IndexToPrimaryHost = 0xFFFF (no primary host).

{| class="wikitable"
!Index!!HostId!!Derived MAC!!Name
|-
|0||2C6400045FB42C64||00:04:5F:B4:2C:64||Haus 207 / ITS
|-
|1||B044E8393512B044||E8:39:35:12:B0:44||Not Initialized
|-
|2||5CF800045FB15CF8||00:04:5F:B1:5C:F8||Not_Initialized
|}

The unit is therefore not factory fresh; it carries registrations from a prior
deployment, but no primary host is currently designated.

====Checksum (CRC)====

The HostList (and other flash data blobs) are protected by a 4 byte trailing
CRC. Parameters:

*Polynomial: 0x04C11DB7
*Initial value: 0
*MSB first, augmented message style (the data bit is shifted into the LSB; no input or output reflection; no final XOR)
*Stored big endian

To generate: compute the CRC over the data followed by four zero bytes, then
append the result big endian. Verification: the CRC over (data plus stored CRC)
equals zero.

def crc(data, poly=0x04C11DB7, init=0):
c = init
for byte in data:
for bit in (0x80,0x40,0x20,0x10,0x08,0x04,0x02,0x01):
msb = c & 0x80000000
c = (c << 1) & 0xFFFFFFFF
if byte & bit: c |= 1
if msb: c ^= poly
return c
# trailer = crc(data + b"\x00\x00\x00\x00"), stored big endian

====Read and write transport====

Data blobs (including the HostList) are moved with a configure / buffer /
finalize sequence.

Read (upload, detector to host), non destructive:

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x13||[uploadId:4 LE]||[status:1][totalSize:4 LE]
|-
|Buffer||0x14||[bufId:4 LE][numBytes:4 LE]||[bufId:4 LE][numBytes:4 LE][data]
|}

Write (download, host to detector), persistent (writes flash):

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x0E||[downloadId:4 LE][totalSize:4 LE]||[status:1]
|-
|Buffer||0x0F||[bufId:4 LE][numBytes:4 LE][data]||[status:1][reserved:4]
|-
|Commit||0x10||(empty)||[status:1]
|}

bufId is a zero based chunk index. The HostList uses id 0x71 for both read and
write. The commit command (0x10) reuses the firmware flash path, so a malformed
download can corrupt flash; the operation is irreversible on this hardware.

====Registering a new host====

To register a host and make it the image destination, read the current HostList
(0x71), append a 144 byte entry carrying the new HostId, increment
CurrentNumberOfHosts, set IndexToPrimaryHost to the new entry's index,
recompute the trailing CRC, and write the blob back via the download sequence
(0x0E / 0x0F / 0x10).

===Reading the Drop and Shock Event Log===

The detector contains an accelerometer based shock watchdog that records drop
and impact events into non volatile memory. This log is useful when evaluating a
used unit, since it reveals how many serious shocks the panel has survived and
when. The same data is held both in the main flash (read over the network) and
in the small onboard EEPROM on the detector PCB.

====How to read it====

The shock log is exposed as data category 0x72 on the upload (read) interface.
It is retrieved with the standard non destructive configure and buffer sequence
(cmd 0x13 to configure, cmd 0x14 to pull the chunks). On the unit under test the
blob is 3001 bytes of plain text in the GE .dyn configuration format, so no
decoding is required beyond reading it as ASCII.

The same records are mirrored in binary form in the onboard 24LC256 EEPROM
(32 KB I2C part) for anyone reading the hardware directly.

====Example output====

The following is the actual log read from detector serial UA45829-7. The file
has two parts: a list of individual events (DetectorShockEvents) and a summary
block (DetectorShockData). Each event carries a record key, a severity, a
timestamp, and the peak acceleration on each axis. Two representative records:

<DetectorShockEvents>
[149266438700135]
Severity.Type = String
Severity.Val = Serious
TimeStamp.Type = String
TimeStamp.Val = 2017-4-20,6:59:47
ValidTime.Type = Number
ValidTime.Val = 0
VibrationX.Type = Number
VibrationX.Val = 0
VibrationY.Type = Number
VibrationY.Val = 0
VibrationZ.Type = Number
VibrationZ.Val = 135

[1592113924-1720-113]
Severity.Val = Serious
TimeStamp.Val = 2020-6-14,7:52:4
VibrationX.Val = -172
VibrationY.Val = 0
VibrationZ.Val = -113

The summary block at the end lists the totals and an index of all event keys:

[DetectorShockData]
LastKnownGoodTime.Val = 2024-4-4,6:53:59
NumberOfL3Events.Val = 0
NumberOfL5Events.Val = 7
ShockDataTimeList.Val = { 1643260890-1320-119, 163626503500-123,
160818190500-101, 160524243000170, 1592113924-1720-113,
157804584600183, 149266438700135 }

====Interpreting the records====

The record key encodes the event time and the peak axis values (an epoch style
timestamp followed by the concatenated vibration readings), so it is unique per
event. The VibrationX, VibrationY, and VibrationZ values are signed peak
acceleration counts on each axis. Severity is reported as Serious for all
logged events on this unit, which corresponds to the L5 (highest) severity class
counted in the summary.

The seven recorded events for this detector:

{| class="wikitable"
!Date and time!!VibrationX!!VibrationY!!VibrationZ
|-
|2017-04-20 06:59:47||0||0||135
|-
|2020-01-03 11:04:06||0||0||183
|-
|2020-06-14 07:52:04||-172||0||-113
|-
|2020-11-13 05:40:30||0||0||170
|-
|2020-12-17 06:11:45||0||0||-101
|-
|2021-11-07 07:03:55||0||0||-123
|-
|2022-01-27 06:21:30||-132||0||-119
|}

====Reading the summary fields====

{| class="wikitable"
!Field!!Meaning
|-
|LastKnownGoodTime||Timestamp of the last successful self check (here 2024-04-04), the most recent point at which the detector was known to be operating normally
|-
|NumberOfL3Events||Count of lower severity (L3) shock events; zero on this unit
|-
|NumberOfL5Events||Count of high severity (L5) shock events; seven on this unit, matching the seven records above
|-
|ShockDataTimeList||Index of all stored event keys, newest first
|}

On this example the panel logged seven serious impacts over roughly five years
of field use and last reported a good self check in April 2024.

==FlashPad Detector: Internal Flash Dump and Data Files==

This section documents how the full contents of the detector's internal flash
were extracted over the network and what each recovered file contains. The
detector under test is a GE Optima XR200/220 AMX FlashPad (URP detector,
serial UA45829-7, MAC 40:F4:A0:00:78:4D, firmware 1.6.0.4.2.0.1.3).

===Background===

The detector's main storage is a Spansion/Cypress S29GL512P (marked
GL512P10FFCR2), a 512 Mbit (64 MB) parallel NOR flash. A direct chip read
requires bus access or desoldering and a programmer. However, the detector
firmware exposes its stored data blobs, including a full image of the flash,
through the read (upload) side of the data transport protocol. This makes a
complete, byte exact dump possible over UDP with no physical access.

===Extraction method===

The upload interface is the read counterpart of the firmware download path and
is non destructive (it only reports and returns data; nothing is written).
Each data category is identified by an 8 bit upload ID:

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x13||[uploadId:4 LE]||[status:1][totalSize:4 LE]
|-
|Buffer||0x14||[bufId:4 LE][numBytes:4 LE]||[bufId:4 LE][numBytes:4 LE][data]
|}

A configure request returns status 0 and a total size for a valid ID, or a non
zero status for an unsupported ID. The dump tool sweeps all IDs from 0x00 to
0xFF, and for every readable ID it pulls the full blob in fixed size chunks
(bufId is a zero based chunk index) and writes it to a file. The 64 MB flash
image transfers as 65536 chunks of 1024 bytes.

===Recovered files===

A sweep of the unit returned 18 readable blobs:

{| class="wikitable"
!Upload ID!!Size (bytes)!!Contents
|-
|0xFD||67108864||Full 64 MB NOR flash image
|-
|0xFF||16777216||16 MB region (firmware / FPGA mirror or image buffer)
|-
|0xFE||524288||Bootloader (512 KB; SPI loader, Nios reset code)
|-
|0x10||6815783||Calibration map, dose level 1
|-
|0x11||6815783||Calibration map, dose level 2
|-
|0x12||6815783||Calibration map, dose level 3
|-
|0x06||49254||Table referencing conditioner/generator serial UA2010-8U005
|-
|0x50||19938||Per mode calibration coefficients
|-
|0x51||19582||Per mode calibration coefficients
|-
|0x07||12187||Sensor conversion table (text; see Sensor Readout)
|-
|0x72||3001||Shock / drop event log (text)
|-
|0x0E||624||Panel geometry / configuration (binary)
|-
|0x71||504||Host list / registration record (see Host Registration)
|-
|0x0F||233||Host to detector compatibility table (text)
|-
|0x08||62||Serial and model strings
|-
|0x0A||48||Manufacturing codes
|-
|0x52||30||Serial string
|-
|0x0B||24||Small marker / identifier
|}

===Flash image layout (upload ID 0xFD)===

A block scan of the 64 MB image shows the following regions:

{| class="wikitable"
!Range!!Contents
|-
|0x000000 to 0x800000||Firmware and FPGA configuration
|-
|0x800000 to 0x940000||Sparse configuration area
|-
|0x940000||Host list / registration record (matches upload ID 0x71)
|-
|0x1000000 to 0x2800000||Calibration and image data (16 to 40 MB)
|-
|0x2800000 to 0x4000000||Erased / unused (40 to 64 MB)
|}

The host list strings (the DetectorName starShape_green, the registered host
name Haus 207 / ITS, and the unset ConnectionSecretKey placeholder) appear at
0x940000, confirming that the 504 byte 0x71 read maps to this flash region.

===Notes on individual files===

*'''0x07 (sensor table)''': plain text, header DetectorSerialNumber = UA45829-7, revision 1.2. Lists every sensor by name, command (0x7902), and sensorId. Also carries panel geometry in its [Common] section: 16 bit depth, 2048 by 2048 pixels, active area from (12, 12) to (2035, 2035), pixel pitch 0.2 mm, corner radius 1416.8, panel saturation 150.
*'''0x10, 0x11, 0x12 (calibration maps)''': three distinct blobs of identical size, corresponding to the low, medium, and high dose calibration sets. Each begins with the firmware version and serial (header bytes 01 06 00 04 02 00 01 03 followed by the serial). Required to apply gain and offset correction to raw images.
*'''0xFE (bootloader)''': contains the strings spi_load.S and ../../boot and Nios II reset vector code.
*'''0x72 (shock log)''': text records of drop / vibration events with timestamps and per axis values; the same data is mirrored in the detector's small onboard EEPROM.
*'''0x06''': references a different serial, UA2010-8U005, likely the conditioner or generator board rather than the panel.

===Significance===

The complete flash image and all calibration data are recoverable over the
network without opening the detector, providing a full byte exact backup of the
unit before any write operation. The calibration maps are needed for image
correction, and the firmware image (the live, deployed build) is more complete
than the partial firmware files shipped on the recovery media.

==Teardown / Internal Pictures / Hardware analysis==

<gallery mode="packed" heights="200">
File:GE Flashpad under the hood.jpg|the Carbon fiber sleeve is held by 9 screws and can taken off without force.
File:Ge flashpad powersupply pcb in handle.jpg|Power supply PCB
File:Ge flashpad uwb board pcb.jpg|UWB PCB for Wireless USB using a RTU2705
File:Ge flashpad uwb pcb backside.jpg|Backside of UWB PCB
File:Ge flashpad power supply pcb backside.jpg|Backside of Power supply PCB
File:Ge flashpad main pcb closeup1.jpg|Main area of the PCB with its Altera Cyclone 3 FPGA
File:Ge flashpad main pcb closeup2.jpg|AD7892 is a 600ksps 12bit ADC, SN74LVC8T245 a 8bit bus transceiver and DG9408EDN a 8ch MUX
File:Ge flashpad bottom connector ethernet isolation pcb.jpg|Isolation PCB for bottom connector
File:Ge flashpad main pcb powersupply section.jpg|Powersupply section for FPGA and ROIC
File:Ge flashpad main pcb closeup 3.jpg|AD9764AR 14-Bit, 125 MSPS DAC and DS1682 integrated elapsed-time recorder
File:Ge flashpad main pcb closeup 4.jpg|Accelerometer is a 834-0500 500G 3 Axis unit, and TJ500AE SPDT gigabit LAN switch
File:Ge flashpad bottom connector.jpg|bottom connector for docking stand
File:Ge flashpad main pcb closeup 5.jpg|Ethernet transformers and ADM34 RS-485/RS-422 Transceiver
File:Ge flashpad main pcb closeup 6.jpg|Altera EPM570f100c5n CPLD
File:Ge flashpad main pcb closeup 7.jpg|Spansion GL512P10FF1R1 512 Mbit NOR flash IC holding everything
File:Ge flashpad main pcb closeup 8.jpg|24LC256I 32k EEPROM for storing the accelerometer events
</gallery>

==Main test py script: Usage and Parameters==

current iteration found here: https://pastebin.com/vEfAresk

flashpad_acquire.py is a single file Python 3 tool that speaks the FlashPad
URP/PDAP protocol over UDP. It implements discovery, the control handshake,
script download and execution, sensor readout, full data backup, and the host
registration (pairing) write. It requires only the Python standard library.

===Default network configuration===

These defaults match the values in ConnectionPoint.cfg and can be overridden on
the command line.

{| class="wikitable"
!Setting!!Default!!Meaning
|-
|Detector IP||192.168.1.30||the panel; listens for all commands on UDP 8100
|-
|Host IP||192.168.1.1||this machine, announced in SYSTEM_STARTUP
|-
|Detector port||8100||where commands are sent
|-
|Host command port||5550||where the detector returns protocol replies
|-
|Host image port||6660||where pixel data would stream
|-
|Discovery port||4500||where the detector sends its beacons
|}

===Connection and general options===

{| class="wikitable"
!Option!!Default!!Effect
|-
| --detector-ip IP||192.168.1.30||detector address
|-
| --host-ip IP||192.168.1.1||host address sent in SYSTEM_STARTUP
|-
| --output-dir DIR||.||where raw images are written
|-
| --timeout SECONDS||5.0||UDP receive timeout
|-
| --exec-timeout SECONDS||60||how long to wait for EXECUTION_COMPLETE
|-
| --skip-discovery||off||send SYSTEM_STARTUP once and proceed, skipping the discovery loop
|-
| --quiet||off||suppress the verbose per packet log
|}

===Read and diagnostic modes (non destructive)===

These only read from the detector. None of them write anything.

{| class="wikitable"
!Option!!What it does!!What to expect
|-
| --sensors||Reads the full 32 entry sensor table using cmd 0x7902 (converted) and 0x7900 (raw), side by side.||A decoded table of supply rails in volts. Temperatures show as railed. Unimplemented sensors (accelerometer DEM id, battery, grid) are flagged as stale.
|-
| --no-roe-init||With --sensors, skips the Script7 ROE init before reading.||Slightly faster sensor read, marginally less reliable.
|-
| --probe-data||Reads DetectorInfo, the HostList (registration state), and cal results via the upload protocol (cmd 0x13/0x14).||A hexdump and text decode of each. Shows whether any host is registered and which HostId the detector expects.
|-
| --backup [DIR]||Sweeps all upload IDs 0x00 to 0xFF and saves every readable blob to DIR/detector_backup_timestamp/.||A manifest plus one .bin per readable ID, including the full 64 MB flash image and the calibration maps. Do this before any write. Large blobs take a few minutes each.
|-
| --backup-range LO-HI||Limits the --backup sweep, for example 0x40-0xA0.||Faster, partial backup.
|-
| --dump-scripts||Prints the wire bytes of all built scripts as hex and exits.||No network activity; useful for inspecting the script encoding.
|-
| --listen||Passively listens on the host command port for 30 seconds.||Prints any packets the detector sends; useful for watching beacons.
|}

===Acquisition modes===

The default invocation (no mode flag) runs a standard acquisition, which
requires an actual X-ray exposure to complete.

{| class="wikitable"
!Option!!What it does!!What to expect
|-
|(no flag)||Standard acquisition (Script 0).||Needs an X-ray exposure to reach EXECUTION_COMPLETE.
|-
| --dark||Runs the dark/offset acquisition (Script 1) before the standard one.||Two acquisitions; the dark one needs no X-ray.
|-
| --dark-only||Runs only the dark acquisition (Script 1).||Completes in a few seconds with no X-ray. The detector acquires and holds an 8 buffer image. Best way to test the full flow.
|-
| --no-standby||Omits the Script 8 standby loop.||Use if the standby loop blocks acquisition.
|-
| --two-exec||Executes Script 7 alone, waits, then Script 1. Only with --dark-only.||Tests the two stage execution hypothesis.
|-
| --parallel||Answers the detector status query (0x30000) with the cmd 0x99 ParallelImageTransfer reply instead of cmd 9.||Experiment to see if the parallel reply triggers a pixel push. (Result so far: it does not.)
|-
| --sweep-acq||Sweeps the dark acquisition across type_mode and transfer_mode values, watching for a 0x0F pixel push.||Non destructive experiment; reports which combination, if any, makes the detector stream.
|-
| --preview||Single dark acquisition on the preview path (transfer_mode 2, 4 buffer image). Watches port 6660 for a push.||One clean connection; run a packet capture on the detector address in parallel.
|}

Note: at present the detector acquires and holds an image but does not push the
0x0F pixel frames. The acquisition modes complete the handshake and acquisition,
but image streaming is still being investigated.

===Registration and write operations===

These can write to the detector's flash. Every write is a dry run by default and
only takes effect when --commit is added. Always run --backup first.

{| class="wikitable"
!Option!!What it does
|-
| --register-self||Adds this host to the detector HostList and sets it as the primary host, so the detector should stream images to it. Appends an entry, sets IndexToPrimaryHost, recomputes the CRC, and writes via id 0x71. Dry run unless --commit.
|-
| --host-mac MAC||The MAC of the interface talking to the detector, used to derive this host's HostId for --register-self. Default 00:6f:00:01:0a:3a.
|-
| --smoke-test-write||Reads the HostList and writes back the identical bytes to validate the write and commit path without changing anything. Dry run unless --commit.
|-
| --restore-hostlist FILE||Writes a saved HostList blob (for example detector_backup_*/upload_0x71_504.bin) back to the detector. This is the undo button. Dry run unless --commit.
|-
| --commit||Arms the actual flash write for the operations above. Without it they only print what they would do. This writes the detector's flash and is irreversible at the chip level, although the HostList region can be restored from a backup.
|}

===Typical workflow===

#Read the current state: <code>python flashpad_acquire.py --probe-data</code>
#Make a full backup: <code>python flashpad_acquire.py --backup</code>
#Check sensors and power rails: <code>python flashpad_acquire.py --sensors</code>
#Dry run the registration: <code>python flashpad_acquire.py --register-self --host-mac YOUR:MAC</code>
#When satisfied, commit it: add <code>--commit</code>
#If needed, undo: <code>python flashpad_acquire.py --restore-hostlist detector_backup_*/upload_0x71_504.bin --commit</code>

==Known Dead Ends==

Things that were tried and did not work or led nowhere:

;0xBEEF (48879) as reply port
:This was a bug in early test scripts. The port has no meaning in the protocol. Use 5550.

;CmdFlag=1 as data packet flag
:Early scripts had the URP fields swapped, setting CmdFlag=1 on data packets. The detector ignores all PDAP content in these packets. Power cycle the detector if this happened, it may retain stale port state.

;Image data on alternate ports
:Tried listening on 48879, 6660, 5550, 8100, 1050, 6661, 9999, 4444, 7000, 7001, 9001. Nothing arrived on any of them.

;PORT_SETUP byte order (big-endian)
:Current implementation sends port fields as big-endian. If the detector reads them as little-endian it computes port 44565 and 1050 instead of 5550 and 6660, which would explain why no image data arrives. Not yet confirmed.

;Image data streaming automatically after EXECUTE_SCRIPT
:Frames may not push during execution at all. The detector may require an explicit IMAGE_RETRIVAL_REQUEST (cmd_type=0x41) and IMAGE_RETRIVAL (cmd_type=0x98) after the 0x30000 notification before it streams anything. Not yet tested.

GE Medical Flashpad Digital Xray Detector

2026-06-11T12:27:12Z

Gamerpaddy: /* Sequence Counter Rules */

==Overview==
{{Note|UNFINISHED Project, it was not yet possible to retrieve a exposure or dark frame in my testing, further investigation needed. any help is appreciated on recessim discord.}}

The '''GE Flashpad''' is a Digital Radiography image sensor from approximately 2010, originally used in the '''GE Optima 220AMX''' mobile X-ray unit. It was designed to replace analog film in radiology, dramatically reducing image acquisition time from hours to seconds.
[[File:GE Flashpad.jpg|thumb|Flashpad with Anti-Scatter grid (left), manual and recovery dvd for 220amx and tether cord (right)]]
Due to its high original cost and specialized application, used units occasionally appear on professional B2B marketplaces in the $15,000–$50,000 range. On eBay, prices typically fall between $1,500 and $5,000, though units at this price point are often in poor condition and may fail the built-in self-test or not function at all.

{{Note|All findings on this page are based on a single unit and the time spent working on it. Information is subject to speculation and may not be fully accurate.}}

{{Note|AI assistance was used in writing this page for improved formatting and readability, as well as in the process of finding information, testing, and analyzing firmware dumps and backups.}}

==Purpose and Motivation==

This project documents the reverse engineering of the GE FlashPad wireless
digital radiography detector used with the Optima XR200/220 AMX mobile X-ray
system, with the goal of freeing these detectors for independent use.
[[File:Xray capture pcb.png|thumb|Xray capture of a PCB for Reverse Engineering using a different detector]]
Large numbers of these detectors reach the used market, but each one is bound to its original Optima 220 AMX
console. Once separated from that console, or once the console is
decommissioned, the detector is effectively useless even though the hardware is
fully functional. There is a Windows software but it is not obtainable. The aim of this work is to remove that artificial barrier so
that a standalone FlashPad can be paired, configured, and read out by any host,
without the half million dollar console it was sold with.

The intended beneficiaries are:

*Hobbyists, researchers, and engineers who want a high quality flat panel detector for their own imaging projects. for example studying the fluid movement in plants. https://www.youtube.com/watch?v=j-FHbHoiwNk (Xray timelapse by Ben Krasnow / Applied Science using a GE Flashpad)
*Veterinary practices, which can put surplus human grade detectors to good use at a fraction of the cost of new equipment.
*Clinics and hospitals in countries and regions where a complete commercial system is unaffordable, allowing serviceable detectors to keep providing diagnostic imaging instead of being scrapped.

[[File:Xray current clamp multimeter.png|thumb|xray of a current clamp multimeter using a different detector]]
This is done for human good. Every detector returned to service is one less
piece of working medical hardware sent to landfill, and potentially one more
place that can offer X-ray imaging where it otherwise could not.

All files, findings, protocol documentation, and tools produced by this project
are public and open source, so that anyone can study, reproduce, and build on
the work.

==Technical Specifications==
[[File:Ge flashpad tether cable pinout diagram.png|thumb|Pinout Diagram of the Tether cable]]
[[File:Ge flashpad tether wiring for ethernet cable.jpg|thumb|Professional Tether wiring to attach a Ethernet Cable and 12V socket to it.]]
The Flashpad uses a '''~40 × 40 cm CsI scintillator''' bonded to a [[Thin-film transistor|TFT]] photodetector array mounted on glass. The assembly is highly sensitive to shock and impact damage. See section [[#Reading the Drop and Shock Event Log|drop and shock event log]]

{| class="wikitable"
|-
!Parameter!!Value
|-
|Resolution||2048 × 2048 px
|-
|Bit depth||16-bit per pixel
|-
|Spatial resolution||Up to 5 lp/mm (theoretical)
|-
|Scintillator material||Caesium iodide (CsI)
|-
|Detector type||TFT photodetector array (glass substrate)
|-
|Panel size||~40 × 40 cm
|}

The theoretical 5 lp/mm spatial resolution is primarily limited in practice by the focal spot size of the X-ray source. Use of an anti-scatter grid can improve effective resolution.

===Status of Reverse Engineering===

{| class="wikitable"
|-
!What!!Status
|-
|Connect, beacon, ACK||Works
|-
|PORT_SETUP||Works
|-
|SIGNATURE_REQUEST / serial number readout||Works
|-
|Script download (Scripts 7, 8, 1)||Works
|-
|EXECUTE_SCRIPT||Works
|-
|EXECUTION_COMPLETE (dark acquisition)||Works but without image readout its speculation.
|-
|EXECUTION_COMPLETE (standard acquisition)||Needs real X-ray trigger to test
|-
|Image data on port 6660||Does not work yet, under investigation. Will not send Imagedata...
|}

==Hardware Features==

===Shock logging===
The unit contains an internal accelerometer that logs significant shock events — but only when a battery is inserted. As there is no backup battery, shock events occurring while unpowered are not recorded.

===Wireless connectivity===
Some units include a UWB transmitter for Wireless USB; others may be equipped with a Wi-Fi module instead. The detector can also be operated over the tethered connection alone.

===Ethernet interface===
There is a 100MBit Ethernet interface trough the Tether Cable which can be tapped and used for Communication.
Exposed metal contacts on the bottom connector are isolated via relays by default. Enabling Gigabit Ethernet connectivity requires shorting or driving two specific pins. This has not been investigated further at this time.

==Communication Protocol==

This section documents the URP/PDAP protocol used by the GE Flashpad (codename '''Apollo''' (Or FeiTian, Mammo, Gryphon etc.) to communicate with a host over Ethernet. All findings are based on live capture tests, configuration files, and reverse-engineering of the GE SuperBee software stack.

{{Note|All findings are based on a single unit and may not be fully accurate.}}

===Network Setup===

All findings were over Ethernet only, no UWB or WIFI has been used.
Default detector IP is <code>192.168.1.30</code>. Set your host to a static IP in the same subnet, <code>192.168.1.1</code> works fine.

At first by sending random bytes over Python it answered to port 48879 (0xBEEF), which seems to be either the default port or set by Python.
After SYSTEM_SETUP it got set to 5550.

{| class="wikitable"
|-
!Role!!IP!!Port!!Direction
|-
|All commands: host -> detector||192.168.1.30||'''8100''' (UDP)||Host sends here
|-
|Discovery beacons: detector -> host||-||'''4500''' (UDP)||Detector sends here initially
|-
|Protocol replies: detector -> host||-||'''5550''' (UDP)||Detector sends here after setup
|-
|Image pixel data: detector -> host||-||'''6660''' (UDP)||Detector streams frames here
|}

In practice you can listen on port '''5550''' for everything (beacons and replies) by advertising that port in both <code>SYSTEM_STARTUP</code> and <code>PORT_SETUP</code>. The detector sends to whichever port was most recently configured.

===Protocol Layers===

Two layers, carried over UDP:

;URP (Unified Registration Protocol)
:8-byte wrapper on every packet. Handles sequencing and acknowledgement.

;PDAP (Proprietary Detector Access Protocol)
:The actual command layer, present inside URP packets when <code>CmdFlag = 0</code>.

Every UDP packet starts with a URP header:

<pre>
[SeqId : 4 bytes LE] [CmdFlag : 4 bytes LE]
</pre>

*<code>CmdFlag = 0</code> -- data packet, PDAP command follows.
*<code>CmdFlag = 1</code> -- bare ACK, no PDAP body. SeqId echoes the packet being acknowledged.

Both sides must ACK every data packet immediately. The detector silently drops packets with a SeqId it has already seen, so always increment SeqId for each new command.

When CmdFlag is 0, the PDAP header follows immediately:

<pre>
[cmd_type : 4 bytes LE] [payload_len : 4 bytes LE] [payload ...]
</pre>

===Connecting to the Detector===

The connection sequence is:

#Broadcast <code>SYSTEM_STARTUP</code> to tell the detector where to reply.
#The detector sends a <code>BEACON</code> back -- ACK it and sync your sequence counter.
#Send <code>PORT_SETUP</code> to configure the reply and image ports.
#Send <code>SIGNATURE_REQUEST</code> to read the detector identity (serial number, model, firmware, MAC).

====Step 1: SYSTEM_STARTUP====

Broadcast UDP to <code>192.168.1.255:8100</code>. Always uses <code>SeqId = 0</code>.

<pre>
URP : [00 00 00 00] SeqId = 0
[00 00 00 00] CmdFlag = 0
PDAP: [01 00 00 00] cmd_type = 1
[06 00 00 00] payload_len = 6
[15 AE] host reply port = 5550 (big-endian)
[C0 A8 01 01] host IP = 192.168.1.1 (network byte order)
</pre>

<syntaxhighlight lang="python">
import socket, struct

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
sock.bind(("0.0.0.0", 5550))

HOST_IP = "192.168.1.1"
DET_IP = "192.168.1.30"
HOST_PORT = 5550
IMG_PORT = 6660

def make_urp_packet(seq_id, pdap_bytes):
return struct.pack("<II", seq_id, 0) + pdap_bytes

pdap = struct.pack("<II", 1, 6) + struct.pack(">H", HOST_PORT) + socket.inet_aton(HOST_IP)
sock.sendto(make_urp_packet(0, pdap), ("192.168.1.255", 8100))
</syntaxhighlight>

====Step 2: Receiving the BEACON and ACKing====

The detector broadcasts a <code>BEACON</code> (cmd_type=1) roughly every 2 seconds. After sending SYSTEM_STARTUP you should get one quickly. Parse the detector SeqId from the URP header and ACK it:

<syntaxhighlight lang="python">
data, addr = sock.recvfrom(4096)
det_seq = struct.unpack_from("<I", data, 0)[0]

# send bare ACK
ack = struct.pack("<II", det_seq, 1)
sock.sendto(ack, (DET_IP, 8100))

# all subsequent commands start from here
host_seq = det_seq + 1
</syntaxhighlight>

====Step 3: PORT_SETUP====

Tells the detector which host ports to use for replies and image data.

<pre>
PDAP: [02 00 00 00] cmd_type = 2
[04 00 00 00] payload_len = 4
[15 AE] host cmd port = 5550 (big-endian)
[1A 04] host image port = 6660 (big-endian)
</pre>

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 2, 4) + struct.pack(">HH", HOST_PORT, IMG_PORT)
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1
# expect bare ACK from detector
</syntaxhighlight>

====Step 4: Reading the Serial Number (SIGNATURE_REQUEST)====

Empty command, the detector replies with a 54-byte payload containing its identity.

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 3, 0) # cmd_type=3, payload_len=0
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1

# reply is 70 bytes total: 8 URP + 8 PDAP header + 54 payload
data, _ = sock.recvfrom(4096)
payload = data[16:] # skip URP (8) + PDAP header (8)

mac = payload[0:6]
serial = payload[22:34].rstrip(b'\x00 ').decode()
model = payload[34:46].rstrip(b'\x00 ').decode()
fw_bytes = payload[46:54]
firmware = ".".join(str(b) for b in fw_bytes)

print(f"MAC: {':'.join(f'{b:02X}' for b in mac)}")
print(f"Serial: {serial}")
print(f"Model: {model}")
print(f"Firmware: {firmware}")
</syntaxhighlight>

Expected output:
<pre>
MAC: 40:F4:A0:00:78:4D
Serial: UA45829-7
Model: 5340000-7
Firmware: 1.6.0.4.2.0.1.3
</pre>

===Running an Acquisition===

After the connection sequence above, download scripts to the detector and then execute them.

====ROE Initialisation (Script 7)====

Always run this first. It initialises the readout electronics and takes about 4-5 seconds. The detector sends host event ID 17 when done.

====Dark / Offset Acquisition (Script 1)====

No X-ray source required. Runs a dark-field exposure for offset calibration. Use this to verify the acquisition pipeline without a generator.

====Standard Acquisition (Script 0)====

Requires an actual X-ray exposure. <code>EXECUTION_COMPLETE</code> will '''not''' arrive without a real X-ray trigger.

====Sequence Overview====

<pre>
HOST DETECTOR
| |
|-- SYSTEM_STARTUP (broadcast) ----------->|
|<- bare ACK -------------------------------|
|<- BEACON (cmd_type=1) --------------------|
|-- bare ACK ------------------------------>|
| |
|-- PORT_SETUP (cmd_type=2) -------------->|
|<- bare ACK -------------------------------|
| |
|-- SIGNATURE_REQUEST (cmd_type=3) ------->|
|<- SIGNATURE_REPLY (54 bytes) -------------|
|-- bare ACK ------------------------------>|
| |
|-- GENERIC_SCRIPT Script7 (ROE init) ---->|
|<- bare ACK or SCRIPT_DOWNLOAD_REPLY ------|
| |
|-- GENERIC_SCRIPT Script1 (dark acq) ---->|
|<- bare ACK -------------------------------|
| |
|-- EXECUTE_SCRIPT (cmd_type=6) ---------->|
|<- bare ACK -------------------------------|
|<- EXECUTE_SCRIPT_REPLY (~230ms) ----------|
|-- bare ACK ------------------------------>|
|<- DETECTOR_STATE_NOTIFY (~890ms) ---------| state_id=17
|-- bare ACK ------------------------------>|
| |
|<- EXECUTION_COMPLETE (0x10000) -----------|
|-- bare ACK ------------------------------>|
| |
|<- IMAGE_XFER_STATUS_QUERY (0x30000) ------|
|-- bare ACK ------------------------------>|
|-- IMAGE_XFER_STATUS_REPLY (cmd_type=9) ->| numMissed=0
|<- bare ACK -------------------------------|
</pre>

===Sequence Counter Rules===

*<code>SYSTEM_STARTUP</code> always uses <code>SeqId = 0</code>.
*After the first beacon, set host SeqId to beacon_SeqId + 1.
*Increment SeqId by 1 for every new data packet (CmdFlag=0).
*Bare ACKs echo the SeqId of the packet being acknowledged and do not consume a SeqId.
*The detector silently drops any packet with a SeqId it has already processed, so never reuse one.

== Script Download ==

The detector does not have fixed acquisition commands. Instead the host
downloads small programs, called scripts, that the detector stores by ID and
then runs on command. A script is a sequence of primitive operations: program
the ROE (readout electronics) registers, wait, acquire an image, signal an
event. The acquisition behavior of the panel is defined entirely by these
downloaded scripts, which are taken from the application mode XML files (for
example IDC_URP_SE_2200.xml for single energy, 2048 by 2048).

=== The GENERIC_SCRIPT command ===

A script is sent to the detector with the GENERIC_SCRIPT command, cmd_type 5.
The wire format is:

[cmd_type : 4 LE] = 5
[length : 4 LE] = 8 + sum(command sizes) + 2
[script header : 8 bytes]
[packed command 1]
[packed command 2]
...
[terminator : 2 bytes] = 00 00

The 8 byte script header is:

{| class="wikitable"
! Offset !! Size !! Field !! Meaning
|-
| 0 || 2 LE || scriptID || the slot the script is stored in
|-
| 2 || 2 LE || repeatCount || 0 = run once, 65535 = loop forever
|-
| 4 || 4 LE || repeatEvent || event ID that breaks an infinite loop (0 if unused)
|}

Note: the application mode XML lists a fourth header value, ROEdata. This is a
substitution source for the script's commands, not a field on the wire. The wire
header is exactly 8 bytes.

=== Packed command primitives ===

Each command inside the script starts with a one byte DETECTORCODE that selects
its type and length:

{| class="wikitable"
! DETECTORCODE !! Command !! Size !! Layout (after the code byte)
|-
| 1 || Acquisition || 17 || typeMode:1, imageId:1, noScrubs:1, scrubDuration:4 LE, maxExposeTime:4 LE, tailTime:4 LE, transferMode:1
|-
| 2 || ROE command || 14 || responseFlag:1, timerValue:4 LE, roeCmd:4 LE, roeData:4 LE
|-
| 3 || Send host event || 5 || eventId:4 LE
|-
| 4 || Wait for host event || 9 || eventId:4 LE, timeout:4 LE
|-
| 5 || Delay || 5 || delayMicroseconds:4 LE
|}

For example, a ROE command sets a readout register (roeCmd, roeData) and an
Acquisition command triggers the actual exposure window and image readout.

=== Download sequence ===

# The host sends the GENERIC_SCRIPT packet for a given scriptID.
# The detector replies with a bare acknowledgement carrying the same sequence ID. (It may also send a GENERIC_SCRIPT status reply with a status byte; status 0 means accepted.)
# The host repeats this for each script it wants resident on the detector.
# When ready, the host sends EXECUTE_SCRIPT, cmd_type 6, which runs the stored scripts. During and after execution the detector sends status notifications, and finally EXECUTION_COMPLETE, cmd_type 0x10000.

Scripts are persistent for the session: once downloaded they can be executed
without resending.

=== The standard script set ===

The single energy mode downloads four scripts in order. The scriptID in the
header is the slot; the XML refers to them by a separate DETECTOR_SCRIPT_ID.

{| class="wikitable"
! scriptID !! Purpose !! Notes
|-
| 7 || ROE initialization || Scan setup plus a sequence of zero pulses, ends by sending host event 17
|-
| 8 || Standby loop || repeatCount 65535, broken by event 41; keeps the panel idle between acquisitions
|-
| 0 || Standard acquisition || Requires a real X-ray exposure to complete
|-
| 1 || Dark / offset acquisition || Completes with no X-ray; used to test the full flow
|}

For a no X-ray test, download script 7 then script 1 and execute. The detector
runs the ROE init, performs the dark acquisition, and reports
EXECUTION_COMPLETE in a few seconds.

=== Inspecting the encoded scripts ===
See [[#Main test py script: Usage and Parameters|Main test py script]]
The exact wire bytes of every built script can be printed without touching the
detector:

python flashpad_acquire.py --dump-scripts

This shows the full GENERIC_SCRIPT encoding (header, packed commands, and
terminator) as hex, which is useful for verifying the format against the XML.

==Sensor Readout and Host Registration==

This section documents the reverse engineered sensor telemetry interface and the
host registration (pairing) mechanism of the GE Optima XR200/220 AMX FlashPad
(URP detector, SuperBee, FW 1.6.0.4.2.0.1.3). All commands are PDAP over UDP to
the detector at port 8100; replies return to the host command port.

===Sensor Readout===

The detector exposes an analog sensor interface (the DEM, Detector Environment
Monitor) that is independent of the image transfer path and works regardless of
acquisition state.

====Commands====

{| class="wikitable"
!cmd_type!!Meaning!!Request payload!!Reply payload
|-
|0x7900||Raw sensor read||[sensorId:4 LE]||[value:4 LE] (12 bit ADC count)
|-
|0x7902||Converted sensor read||[sensorId:4 LE]||[value:4 LE] (engineering units, signed)
|-
|0x7904||Detailed / radio||[selector:4 LE]||[value:4 LE]
|}

Note: cmd 0x7902 IS supported on this firmware and returns calibrated
engineering units (millivolts for the supply rails, signed; 0.1 degree C for
temperatures). Earlier documentation that marked 0x7902 as unsupported is
incorrect. The host side conversion coefficients are not required; the detector
performs the conversion internally.

The full sensor map (name, sensorId) was recovered from the detector's own
[Sensor] configuration table, read back over the upload interface (see the
Registration section for the read protocol).

====Power rails (live readings)====

All supply rails read correctly via 0x7902 and are within normal range for a
flat panel detector. Representative readings:

{| class="wikitable"
!Sensor!!sensorId!!Converted!!Value
|-
|DCIN_RAW||10||12100 mV||+12.10 V (main DC input)
|-
|LCORE_UNREG||11||1724 mV||+1.72 V
|-
|LPANA_UNREG||12||5776 mV||+5.78 V
|-
|LNANA_UNREG||13||-5801 mV||-5.80 V
|-
|SCAN_VCC||14||5086 mV||+5.09 V (gate driver)
|-
|P5V_REF||16||5025 mV||+5.03 V (5 V reference)
|-
|V_ON||17||11085 mV||+11.09 V (TFT gate on)
|-
|V_OFF||18||-12378 mV||-12.38 V (TFT gate off)
|-
|V_COMMON||19||-9385 mV||-9.39 V
|-
|3V3||29||3177 mV||+3.18 V (3.3 V logic)
|-
|VCC_UNREG||37||3399 mV||+3.40 V
|-
|PARCPREG||38||3768 mV||+3.77 V (ARC preamp +)
|-
|NARCPREG||39||-3732 mV||-3.73 V (ARC preamp -)
|-
|PANA_UNREG||45||18352 mV||+18.35 V (photodiode bias +)
|-
|NANA_UNREG||46||-19251 mV||-19.25 V (photodiode bias -)
|}

Switched rails that are inactive while the panel is idle (PARCVA_U,
P5VA_SW, N5VA_SW, FGATE_NVC_L, FGATE_PVC_L, etc.) read at or near zero.

====Known limitations====

*'''Temperatures''' (Temp_Surface, sensorId 336; Temp_Panel, sensorId 352): the raw 0x7900 read rails at 0x3FF (1023, the ADC maximum), indicating an open thermistor path while the panel is idle. This is a hardware/state condition, not a command problem, and the temperature is not readable from the host in this state.
*'''Unimplemented sensors''': sensorIds 70 (Accelerator), 78 (Gravity), and 256 to 259 (Battery status, name, life, capacity), and 272 (Grid status) are not implemented on this DEM. The detector returns the leftover conversion register contents (a duplicate of a previously read sensor) rather than a real value, so these rows must be discarded.
*'''Accelerometer''': functional through a separate addressing scheme using raw cmd 0x7900 with selectors 0x42 (X), 0x43 (Y), 0x44 (Z), returning 12 bit per axis counts.

===Host Registration (Pairing)===

URP stands for Unified Registration Protocol. The detector maintains a host
list in its internal NOR flash. Image data is delivered only to a registered
primary host, so registration is a prerequisite for image transfer.

====Host identity (MAC and HostId)====

Each host is identified by a 16 character HostId derived deterministically from
the host's eth0 MAC address. The derivation (from the vendor generateHostId
script) is:

#Take the eth0 MAC, remove the colon separators, convert to upper case (12 hex characters).
#Prepend the last 4 characters to the full 12 characters.
#The result is 16 hex characters.

Example: MAC 00:6f:00:01:0a:3a becomes 006F00010A3A, then the last four (0A3A)
are prepended, giving HostId 0A3A006F00010A3A.

====HostList structure====

The host list is stored in flash at offset 0x940000 and can be read back over
the upload interface as data category 0x71. Layout:

Offset Size Field
0x00 16 DetectorDeviceId (ASCII)
0x10 16 ConnectionSecretKey (ASCII; "XXXXXXXXXXXXXXXX" when unset)
0x20 16 DetectorName (ASCII)
0x30 16 DetectorCode (ASCII)
0x40 2 CurrentNumberOfHosts (uint16 LE)
0x42 2 IndexToPrimaryHost (uint16 LE; 0xFFFF = none)
0x44 144*N Host entries, 144 bytes each:
+0x00 16 HostId (ASCII)
+0x10 .. host name / department string
+0x50 .. location string
... 4 CRC (big endian; see below)

====HostList from the unit under test====

Detector: MAC 40:F4:A0:00:78:4D, serial UA45829-7, model 5340000-7,
firmware 1.6.0.4.2.0.1.3. DetectorName starShape_green. ConnectionSecretKey
unset. CurrentNumberOfHosts = 3, IndexToPrimaryHost = 0xFFFF (no primary host).

{| class="wikitable"
!Index!!HostId!!Derived MAC!!Name
|-
|0||2C6400045FB42C64||00:04:5F:B4:2C:64||Haus 207 / ITS
|-
|1||B044E8393512B044||E8:39:35:12:B0:44||Not Initialized
|-
|2||5CF800045FB15CF8||00:04:5F:B1:5C:F8||Not_Initialized
|}

The unit is therefore not factory fresh; it carries registrations from a prior
deployment, but no primary host is currently designated.

====Checksum (CRC)====

The HostList (and other flash data blobs) are protected by a 4 byte trailing
CRC. Parameters:

*Polynomial: 0x04C11DB7
*Initial value: 0
*MSB first, augmented message style (the data bit is shifted into the LSB; no input or output reflection; no final XOR)
*Stored big endian

To generate: compute the CRC over the data followed by four zero bytes, then
append the result big endian. Verification: the CRC over (data plus stored CRC)
equals zero.

def crc(data, poly=0x04C11DB7, init=0):
c = init
for byte in data:
for bit in (0x80,0x40,0x20,0x10,0x08,0x04,0x02,0x01):
msb = c & 0x80000000
c = (c << 1) & 0xFFFFFFFF
if byte & bit: c |= 1
if msb: c ^= poly
return c
# trailer = crc(data + b"\x00\x00\x00\x00"), stored big endian

====Read and write transport====

Data blobs (including the HostList) are moved with a configure / buffer /
finalize sequence.

Read (upload, detector to host), non destructive:

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x13||[uploadId:4 LE]||[status:1][totalSize:4 LE]
|-
|Buffer||0x14||[bufId:4 LE][numBytes:4 LE]||[bufId:4 LE][numBytes:4 LE][data]
|}

Write (download, host to detector), persistent (writes flash):

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x0E||[downloadId:4 LE][totalSize:4 LE]||[status:1]
|-
|Buffer||0x0F||[bufId:4 LE][numBytes:4 LE][data]||[status:1][reserved:4]
|-
|Commit||0x10||(empty)||[status:1]
|}

bufId is a zero based chunk index. The HostList uses id 0x71 for both read and
write. The commit command (0x10) reuses the firmware flash path, so a malformed
download can corrupt flash; the operation is irreversible on this hardware.

====Registering a new host====

To register a host and make it the image destination, read the current HostList
(0x71), append a 144 byte entry carrying the new HostId, increment
CurrentNumberOfHosts, set IndexToPrimaryHost to the new entry's index,
recompute the trailing CRC, and write the blob back via the download sequence
(0x0E / 0x0F / 0x10).

===Reading the Drop and Shock Event Log===

The detector contains an accelerometer based shock watchdog that records drop
and impact events into non volatile memory. This log is useful when evaluating a
used unit, since it reveals how many serious shocks the panel has survived and
when. The same data is held both in the main flash (read over the network) and
in the small onboard EEPROM on the detector PCB.

====How to read it====

The shock log is exposed as data category 0x72 on the upload (read) interface.
It is retrieved with the standard non destructive configure and buffer sequence
(cmd 0x13 to configure, cmd 0x14 to pull the chunks). On the unit under test the
blob is 3001 bytes of plain text in the GE .dyn configuration format, so no
decoding is required beyond reading it as ASCII.

The same records are mirrored in binary form in the onboard 24LC256 EEPROM
(32 KB I2C part) for anyone reading the hardware directly.

====Example output====

The following is the actual log read from detector serial UA45829-7. The file
has two parts: a list of individual events (DetectorShockEvents) and a summary
block (DetectorShockData). Each event carries a record key, a severity, a
timestamp, and the peak acceleration on each axis. Two representative records:

<DetectorShockEvents>
[149266438700135]
Severity.Type = String
Severity.Val = Serious
TimeStamp.Type = String
TimeStamp.Val = 2017-4-20,6:59:47
ValidTime.Type = Number
ValidTime.Val = 0
VibrationX.Type = Number
VibrationX.Val = 0
VibrationY.Type = Number
VibrationY.Val = 0
VibrationZ.Type = Number
VibrationZ.Val = 135

[1592113924-1720-113]
Severity.Val = Serious
TimeStamp.Val = 2020-6-14,7:52:4
VibrationX.Val = -172
VibrationY.Val = 0
VibrationZ.Val = -113

The summary block at the end lists the totals and an index of all event keys:

[DetectorShockData]
LastKnownGoodTime.Val = 2024-4-4,6:53:59
NumberOfL3Events.Val = 0
NumberOfL5Events.Val = 7
ShockDataTimeList.Val = { 1643260890-1320-119, 163626503500-123,
160818190500-101, 160524243000170, 1592113924-1720-113,
157804584600183, 149266438700135 }

====Interpreting the records====

The record key encodes the event time and the peak axis values (an epoch style
timestamp followed by the concatenated vibration readings), so it is unique per
event. The VibrationX, VibrationY, and VibrationZ values are signed peak
acceleration counts on each axis. Severity is reported as Serious for all
logged events on this unit, which corresponds to the L5 (highest) severity class
counted in the summary.

The seven recorded events for this detector:

{| class="wikitable"
!Date and time!!VibrationX!!VibrationY!!VibrationZ
|-
|2017-04-20 06:59:47||0||0||135
|-
|2020-01-03 11:04:06||0||0||183
|-
|2020-06-14 07:52:04||-172||0||-113
|-
|2020-11-13 05:40:30||0||0||170
|-
|2020-12-17 06:11:45||0||0||-101
|-
|2021-11-07 07:03:55||0||0||-123
|-
|2022-01-27 06:21:30||-132||0||-119
|}

====Reading the summary fields====

{| class="wikitable"
!Field!!Meaning
|-
|LastKnownGoodTime||Timestamp of the last successful self check (here 2024-04-04), the most recent point at which the detector was known to be operating normally
|-
|NumberOfL3Events||Count of lower severity (L3) shock events; zero on this unit
|-
|NumberOfL5Events||Count of high severity (L5) shock events; seven on this unit, matching the seven records above
|-
|ShockDataTimeList||Index of all stored event keys, newest first
|}

On this example the panel logged seven serious impacts over roughly five years
of field use and last reported a good self check in April 2024.

==FlashPad Detector: Internal Flash Dump and Data Files==

This section documents how the full contents of the detector's internal flash
were extracted over the network and what each recovered file contains. The
detector under test is a GE Optima XR200/220 AMX FlashPad (URP detector,
serial UA45829-7, MAC 40:F4:A0:00:78:4D, firmware 1.6.0.4.2.0.1.3).

===Background===

The detector's main storage is a Spansion/Cypress S29GL512P (marked
GL512P10FFCR2), a 512 Mbit (64 MB) parallel NOR flash. A direct chip read
requires bus access or desoldering and a programmer. However, the detector
firmware exposes its stored data blobs, including a full image of the flash,
through the read (upload) side of the data transport protocol. This makes a
complete, byte exact dump possible over UDP with no physical access.

===Extraction method===

The upload interface is the read counterpart of the firmware download path and
is non destructive (it only reports and returns data; nothing is written).
Each data category is identified by an 8 bit upload ID:

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x13||[uploadId:4 LE]||[status:1][totalSize:4 LE]
|-
|Buffer||0x14||[bufId:4 LE][numBytes:4 LE]||[bufId:4 LE][numBytes:4 LE][data]
|}

A configure request returns status 0 and a total size for a valid ID, or a non
zero status for an unsupported ID. The dump tool sweeps all IDs from 0x00 to
0xFF, and for every readable ID it pulls the full blob in fixed size chunks
(bufId is a zero based chunk index) and writes it to a file. The 64 MB flash
image transfers as 65536 chunks of 1024 bytes.

===Recovered files===

A sweep of the unit returned 18 readable blobs:

{| class="wikitable"
!Upload ID!!Size (bytes)!!Contents
|-
|0xFD||67108864||Full 64 MB NOR flash image
|-
|0xFF||16777216||16 MB region (firmware / FPGA mirror or image buffer)
|-
|0xFE||524288||Bootloader (512 KB; SPI loader, Nios reset code)
|-
|0x10||6815783||Calibration map, dose level 1
|-
|0x11||6815783||Calibration map, dose level 2
|-
|0x12||6815783||Calibration map, dose level 3
|-
|0x06||49254||Table referencing conditioner/generator serial UA2010-8U005
|-
|0x50||19938||Per mode calibration coefficients
|-
|0x51||19582||Per mode calibration coefficients
|-
|0x07||12187||Sensor conversion table (text; see Sensor Readout)
|-
|0x72||3001||Shock / drop event log (text)
|-
|0x0E||624||Panel geometry / configuration (binary)
|-
|0x71||504||Host list / registration record (see Host Registration)
|-
|0x0F||233||Host to detector compatibility table (text)
|-
|0x08||62||Serial and model strings
|-
|0x0A||48||Manufacturing codes
|-
|0x52||30||Serial string
|-
|0x0B||24||Small marker / identifier
|}

===Flash image layout (upload ID 0xFD)===

A block scan of the 64 MB image shows the following regions:

{| class="wikitable"
!Range!!Contents
|-
|0x000000 to 0x800000||Firmware and FPGA configuration
|-
|0x800000 to 0x940000||Sparse configuration area
|-
|0x940000||Host list / registration record (matches upload ID 0x71)
|-
|0x1000000 to 0x2800000||Calibration and image data (16 to 40 MB)
|-
|0x2800000 to 0x4000000||Erased / unused (40 to 64 MB)
|}

The host list strings (the DetectorName starShape_green, the registered host
name Haus 207 / ITS, and the unset ConnectionSecretKey placeholder) appear at
0x940000, confirming that the 504 byte 0x71 read maps to this flash region.

===Notes on individual files===

*'''0x07 (sensor table)''': plain text, header DetectorSerialNumber = UA45829-7, revision 1.2. Lists every sensor by name, command (0x7902), and sensorId. Also carries panel geometry in its [Common] section: 16 bit depth, 2048 by 2048 pixels, active area from (12, 12) to (2035, 2035), pixel pitch 0.2 mm, corner radius 1416.8, panel saturation 150.
*'''0x10, 0x11, 0x12 (calibration maps)''': three distinct blobs of identical size, corresponding to the low, medium, and high dose calibration sets. Each begins with the firmware version and serial (header bytes 01 06 00 04 02 00 01 03 followed by the serial). Required to apply gain and offset correction to raw images.
*'''0xFE (bootloader)''': contains the strings spi_load.S and ../../boot and Nios II reset vector code.
*'''0x72 (shock log)''': text records of drop / vibration events with timestamps and per axis values; the same data is mirrored in the detector's small onboard EEPROM.
*'''0x06''': references a different serial, UA2010-8U005, likely the conditioner or generator board rather than the panel.

===Significance===

The complete flash image and all calibration data are recoverable over the
network without opening the detector, providing a full byte exact backup of the
unit before any write operation. The calibration maps are needed for image
correction, and the firmware image (the live, deployed build) is more complete
than the partial firmware files shipped on the recovery media.

==Teardown / Internal Pictures / Hardware analysis==

<gallery mode="packed" heights="200">
File:GE Flashpad under the hood.jpg|the Carbon fiber sleeve is held by 9 screws and can taken off without force.
File:Ge flashpad powersupply pcb in handle.jpg|Power supply PCB
File:Ge flashpad uwb board pcb.jpg|UWB PCB for Wireless USB using a RTU2705
File:Ge flashpad uwb pcb backside.jpg|Backside of UWB PCB
File:Ge flashpad power supply pcb backside.jpg|Backside of Power supply PCB
File:Ge flashpad main pcb closeup1.jpg|Main area of the PCB with its Altera Cyclone 3 FPGA
File:Ge flashpad main pcb closeup2.jpg|AD7892 is a 600ksps 12bit ADC, SN74LVC8T245 a 8bit bus transceiver and DG9408EDN a 8ch MUX
File:Ge flashpad bottom connector ethernet isolation pcb.jpg|Isolation PCB for bottom connector
File:Ge flashpad main pcb powersupply section.jpg|Powersupply section for FPGA and ROIC
File:Ge flashpad main pcb closeup 3.jpg|AD9764AR 14-Bit, 125 MSPS DAC and DS1682 integrated elapsed-time recorder
File:Ge flashpad main pcb closeup 4.jpg|Accelerometer is a 834-0500 500G 3 Axis unit, and TJ500AE SPDT gigabit LAN switch
File:Ge flashpad bottom connector.jpg|bottom connector for docking stand
File:Ge flashpad main pcb closeup 5.jpg|Ethernet transformers and ADM34 RS-485/RS-422 Transceiver
File:Ge flashpad main pcb closeup 6.jpg|Altera EPM570f100c5n CPLD
File:Ge flashpad main pcb closeup 7.jpg|Spansion GL512P10FF1R1 512 Mbit NOR flash IC holding everything
File:Ge flashpad main pcb closeup 8.jpg|24LC256I 32k EEPROM for storing the accelerometer events
</gallery>

==Main test py script: Usage and Parameters==

current iteration found here: https://pastebin.com/vEfAresk

flashpad_acquire.py is a single file Python 3 tool that speaks the FlashPad
URP/PDAP protocol over UDP. It implements discovery, the control handshake,
script download and execution, sensor readout, full data backup, and the host
registration (pairing) write. It requires only the Python standard library.

===Default network configuration===

These defaults match the values in ConnectionPoint.cfg and can be overridden on
the command line.

{| class="wikitable"
!Setting!!Default!!Meaning
|-
|Detector IP||192.168.1.30||the panel; listens for all commands on UDP 8100
|-
|Host IP||192.168.1.1||this machine, announced in SYSTEM_STARTUP
|-
|Detector port||8100||where commands are sent
|-
|Host command port||5550||where the detector returns protocol replies
|-
|Host image port||6660||where pixel data would stream
|-
|Discovery port||4500||where the detector sends its beacons
|}

===Connection and general options===

{| class="wikitable"
!Option!!Default!!Effect
|-
| --detector-ip IP||192.168.1.30||detector address
|-
| --host-ip IP||192.168.1.1||host address sent in SYSTEM_STARTUP
|-
| --output-dir DIR||.||where raw images are written
|-
| --timeout SECONDS||5.0||UDP receive timeout
|-
| --exec-timeout SECONDS||60||how long to wait for EXECUTION_COMPLETE
|-
| --skip-discovery||off||send SYSTEM_STARTUP once and proceed, skipping the discovery loop
|-
| --quiet||off||suppress the verbose per packet log
|}

===Read and diagnostic modes (non destructive)===

These only read from the detector. None of them write anything.

{| class="wikitable"
!Option!!What it does!!What to expect
|-
| --sensors||Reads the full 32 entry sensor table using cmd 0x7902 (converted) and 0x7900 (raw), side by side.||A decoded table of supply rails in volts. Temperatures show as railed. Unimplemented sensors (accelerometer DEM id, battery, grid) are flagged as stale.
|-
| --no-roe-init||With --sensors, skips the Script7 ROE init before reading.||Slightly faster sensor read, marginally less reliable.
|-
| --probe-data||Reads DetectorInfo, the HostList (registration state), and cal results via the upload protocol (cmd 0x13/0x14).||A hexdump and text decode of each. Shows whether any host is registered and which HostId the detector expects.
|-
| --backup [DIR]||Sweeps all upload IDs 0x00 to 0xFF and saves every readable blob to DIR/detector_backup_timestamp/.||A manifest plus one .bin per readable ID, including the full 64 MB flash image and the calibration maps. Do this before any write. Large blobs take a few minutes each.
|-
| --backup-range LO-HI||Limits the --backup sweep, for example 0x40-0xA0.||Faster, partial backup.
|-
| --dump-scripts||Prints the wire bytes of all built scripts as hex and exits.||No network activity; useful for inspecting the script encoding.
|-
| --listen||Passively listens on the host command port for 30 seconds.||Prints any packets the detector sends; useful for watching beacons.
|}

===Acquisition modes===

The default invocation (no mode flag) runs a standard acquisition, which
requires an actual X-ray exposure to complete.

{| class="wikitable"
!Option!!What it does!!What to expect
|-
|(no flag)||Standard acquisition (Script 0).||Needs an X-ray exposure to reach EXECUTION_COMPLETE.
|-
| --dark||Runs the dark/offset acquisition (Script 1) before the standard one.||Two acquisitions; the dark one needs no X-ray.
|-
| --dark-only||Runs only the dark acquisition (Script 1).||Completes in a few seconds with no X-ray. The detector acquires and holds an 8 buffer image. Best way to test the full flow.
|-
| --no-standby||Omits the Script 8 standby loop.||Use if the standby loop blocks acquisition.
|-
| --two-exec||Executes Script 7 alone, waits, then Script 1. Only with --dark-only.||Tests the two stage execution hypothesis.
|-
| --parallel||Answers the detector status query (0x30000) with the cmd 0x99 ParallelImageTransfer reply instead of cmd 9.||Experiment to see if the parallel reply triggers a pixel push. (Result so far: it does not.)
|-
| --sweep-acq||Sweeps the dark acquisition across type_mode and transfer_mode values, watching for a 0x0F pixel push.||Non destructive experiment; reports which combination, if any, makes the detector stream.
|-
| --preview||Single dark acquisition on the preview path (transfer_mode 2, 4 buffer image). Watches port 6660 for a push.||One clean connection; run a packet capture on the detector address in parallel.
|}

Note: at present the detector acquires and holds an image but does not push the
0x0F pixel frames. The acquisition modes complete the handshake and acquisition,
but image streaming is still being investigated.

===Registration and write operations===

These can write to the detector's flash. Every write is a dry run by default and
only takes effect when --commit is added. Always run --backup first.

{| class="wikitable"
!Option!!What it does
|-
| --register-self||Adds this host to the detector HostList and sets it as the primary host, so the detector should stream images to it. Appends an entry, sets IndexToPrimaryHost, recomputes the CRC, and writes via id 0x71. Dry run unless --commit.
|-
| --host-mac MAC||The MAC of the interface talking to the detector, used to derive this host's HostId for --register-self. Default 00:6f:00:01:0a:3a.
|-
| --smoke-test-write||Reads the HostList and writes back the identical bytes to validate the write and commit path without changing anything. Dry run unless --commit.
|-
| --restore-hostlist FILE||Writes a saved HostList blob (for example detector_backup_*/upload_0x71_504.bin) back to the detector. This is the undo button. Dry run unless --commit.
|-
| --commit||Arms the actual flash write for the operations above. Without it they only print what they would do. This writes the detector's flash and is irreversible at the chip level, although the HostList region can be restored from a backup.
|}

===Typical workflow===

#Read the current state: <code>python flashpad_acquire.py --probe-data</code>
#Make a full backup: <code>python flashpad_acquire.py --backup</code>
#Check sensors and power rails: <code>python flashpad_acquire.py --sensors</code>
#Dry run the registration: <code>python flashpad_acquire.py --register-self --host-mac YOUR:MAC</code>
#When satisfied, commit it: add <code>--commit</code>
#If needed, undo: <code>python flashpad_acquire.py --restore-hostlist detector_backup_*/upload_0x71_504.bin --commit</code>

==Known Dead Ends==

Things that were tried and did not work or led nowhere:

;0xBEEF (48879) as reply port
:This was a bug in early test scripts. The port has no meaning in the protocol. Use 5550.

;CmdFlag=1 as data packet flag
:Early scripts had the URP fields swapped, setting CmdFlag=1 on data packets. The detector ignores all PDAP content in these packets. Power cycle the detector if this happened, it may retain stale port state.

;Image data on alternate ports
:Tried listening on 48879, 6660, 5550, 8100, 1050, 6661, 9999, 4444, 7000, 7001, 9001. Nothing arrived on any of them.

;PORT_SETUP byte order (big-endian)
:Current implementation sends port fields as big-endian. If the detector reads them as little-endian it computes port 44565 and 1050 instead of 5550 and 6660, which would explain why no image data arrives. Not yet confirmed.

;Image data streaming automatically after EXECUTE_SCRIPT
:Frames may not push during execution at all. The detector may require an explicit IMAGE_RETRIVAL_REQUEST (cmd_type=0x41) and IMAGE_RETRIVAL (cmd_type=0x98) after the 0x30000 notification before it streams anything. Not yet tested.

GE Medical Flashpad Digital Xray Detector

2026-06-11T12:23:50Z

Gamerpaddy: /* Communication Protocol */

==Overview==
{{Note|UNFINISHED Project, it was not yet possible to retrieve a exposure or dark frame in my testing, further investigation needed. any help is appreciated on recessim discord.}}

The '''GE Flashpad''' is a Digital Radiography image sensor from approximately 2010, originally used in the '''GE Optima 220AMX''' mobile X-ray unit. It was designed to replace analog film in radiology, dramatically reducing image acquisition time from hours to seconds.
[[File:GE Flashpad.jpg|thumb|Flashpad with Anti-Scatter grid (left), manual and recovery dvd for 220amx and tether cord (right)]]
Due to its high original cost and specialized application, used units occasionally appear on professional B2B marketplaces in the $15,000–$50,000 range. On eBay, prices typically fall between $1,500 and $5,000, though units at this price point are often in poor condition and may fail the built-in self-test or not function at all.

{{Note|All findings on this page are based on a single unit and the time spent working on it. Information is subject to speculation and may not be fully accurate.}}

{{Note|AI assistance was used in writing this page for improved formatting and readability, as well as in the process of finding information, testing, and analyzing firmware dumps and backups.}}

==Purpose and Motivation==

This project documents the reverse engineering of the GE FlashPad wireless
digital radiography detector used with the Optima XR200/220 AMX mobile X-ray
system, with the goal of freeing these detectors for independent use.
[[File:Xray capture pcb.png|thumb|Xray capture of a PCB for Reverse Engineering using a different detector]]
Large numbers of these detectors reach the used market, but each one is bound to its original Optima 220 AMX
console. Once separated from that console, or once the console is
decommissioned, the detector is effectively useless even though the hardware is
fully functional. There is a Windows software but it is not obtainable. The aim of this work is to remove that artificial barrier so
that a standalone FlashPad can be paired, configured, and read out by any host,
without the half million dollar console it was sold with.

The intended beneficiaries are:

*Hobbyists, researchers, and engineers who want a high quality flat panel detector for their own imaging projects. for example studying the fluid movement in plants. https://www.youtube.com/watch?v=j-FHbHoiwNk (Xray timelapse by Ben Krasnow / Applied Science using a GE Flashpad)
*Veterinary practices, which can put surplus human grade detectors to good use at a fraction of the cost of new equipment.
*Clinics and hospitals in countries and regions where a complete commercial system is unaffordable, allowing serviceable detectors to keep providing diagnostic imaging instead of being scrapped.

[[File:Xray current clamp multimeter.png|thumb|xray of a current clamp multimeter using a different detector]]
This is done for human good. Every detector returned to service is one less
piece of working medical hardware sent to landfill, and potentially one more
place that can offer X-ray imaging where it otherwise could not.

All files, findings, protocol documentation, and tools produced by this project
are public and open source, so that anyone can study, reproduce, and build on
the work.

==Technical Specifications==
[[File:Ge flashpad tether cable pinout diagram.png|thumb|Pinout Diagram of the Tether cable]]
[[File:Ge flashpad tether wiring for ethernet cable.jpg|thumb|Professional Tether wiring to attach a Ethernet Cable and 12V socket to it.]]
The Flashpad uses a '''~40 × 40 cm CsI scintillator''' bonded to a [[Thin-film transistor|TFT]] photodetector array mounted on glass. The assembly is highly sensitive to shock and impact damage. See section [[#Reading the Drop and Shock Event Log|drop and shock event log]]

{| class="wikitable"
|-
!Parameter!!Value
|-
|Resolution||2048 × 2048 px
|-
|Bit depth||16-bit per pixel
|-
|Spatial resolution||Up to 5 lp/mm (theoretical)
|-
|Scintillator material||Caesium iodide (CsI)
|-
|Detector type||TFT photodetector array (glass substrate)
|-
|Panel size||~40 × 40 cm
|}

The theoretical 5 lp/mm spatial resolution is primarily limited in practice by the focal spot size of the X-ray source. Use of an anti-scatter grid can improve effective resolution.

===Status of Reverse Engineering===

{| class="wikitable"
|-
!What!!Status
|-
|Connect, beacon, ACK||Works
|-
|PORT_SETUP||Works
|-
|SIGNATURE_REQUEST / serial number readout||Works
|-
|Script download (Scripts 7, 8, 1)||Works
|-
|EXECUTE_SCRIPT||Works
|-
|EXECUTION_COMPLETE (dark acquisition)||Works but without image readout its speculation.
|-
|EXECUTION_COMPLETE (standard acquisition)||Needs real X-ray trigger to test
|-
|Image data on port 6660||Does not work yet, under investigation. Will not send Imagedata...
|}

==Hardware Features==

===Shock logging===
The unit contains an internal accelerometer that logs significant shock events — but only when a battery is inserted. As there is no backup battery, shock events occurring while unpowered are not recorded.

===Wireless connectivity===
Some units include a UWB transmitter for Wireless USB; others may be equipped with a Wi-Fi module instead. The detector can also be operated over the tethered connection alone.

===Ethernet interface===
There is a 100MBit Ethernet interface trough the Tether Cable which can be tapped and used for Communication.
Exposed metal contacts on the bottom connector are isolated via relays by default. Enabling Gigabit Ethernet connectivity requires shorting or driving two specific pins. This has not been investigated further at this time.

==Communication Protocol==

This section documents the URP/PDAP protocol used by the GE Flashpad (codename '''Apollo''' (Or FeiTian, Mammo, Gryphon etc.) to communicate with a host over Ethernet. All findings are based on live capture tests, configuration files, and reverse-engineering of the GE SuperBee software stack.

{{Note|All findings are based on a single unit and may not be fully accurate.}}

===Network Setup===

All findings were over Ethernet only, no UWB or WIFI has been used.
Default detector IP is <code>192.168.1.30</code>. Set your host to a static IP in the same subnet, <code>192.168.1.1</code> works fine.

At first by sending random bytes over Python it answered to port 48879 (0xBEEF), which seems to be either the default port or set by Python.
After SYSTEM_SETUP it got set to 5550.

{| class="wikitable"
|-
!Role!!IP!!Port!!Direction
|-
|All commands: host -> detector||192.168.1.30||'''8100''' (UDP)||Host sends here
|-
|Discovery beacons: detector -> host||-||'''4500''' (UDP)||Detector sends here initially
|-
|Protocol replies: detector -> host||-||'''5550''' (UDP)||Detector sends here after setup
|-
|Image pixel data: detector -> host||-||'''6660''' (UDP)||Detector streams frames here
|}

In practice you can listen on port '''5550''' for everything (beacons and replies) by advertising that port in both <code>SYSTEM_STARTUP</code> and <code>PORT_SETUP</code>. The detector sends to whichever port was most recently configured.

===Protocol Layers===

Two layers, carried over UDP:

;URP (Unified Registration Protocol)
:8-byte wrapper on every packet. Handles sequencing and acknowledgement.

;PDAP (Proprietary Detector Access Protocol)
:The actual command layer, present inside URP packets when <code>CmdFlag = 0</code>.

Every UDP packet starts with a URP header:

<pre>
[SeqId : 4 bytes LE] [CmdFlag : 4 bytes LE]
</pre>

*<code>CmdFlag = 0</code> -- data packet, PDAP command follows.
*<code>CmdFlag = 1</code> -- bare ACK, no PDAP body. SeqId echoes the packet being acknowledged.

Both sides must ACK every data packet immediately. The detector silently drops packets with a SeqId it has already seen, so always increment SeqId for each new command.

When CmdFlag is 0, the PDAP header follows immediately:

<pre>
[cmd_type : 4 bytes LE] [payload_len : 4 bytes LE] [payload ...]
</pre>

===Connecting to the Detector===

The connection sequence is:

#Broadcast <code>SYSTEM_STARTUP</code> to tell the detector where to reply.
#The detector sends a <code>BEACON</code> back -- ACK it and sync your sequence counter.
#Send <code>PORT_SETUP</code> to configure the reply and image ports.
#Send <code>SIGNATURE_REQUEST</code> to read the detector identity (serial number, model, firmware, MAC).

====Step 1: SYSTEM_STARTUP====

Broadcast UDP to <code>192.168.1.255:8100</code>. Always uses <code>SeqId = 0</code>.

<pre>
URP : [00 00 00 00] SeqId = 0
[00 00 00 00] CmdFlag = 0
PDAP: [01 00 00 00] cmd_type = 1
[06 00 00 00] payload_len = 6
[15 AE] host reply port = 5550 (big-endian)
[C0 A8 01 01] host IP = 192.168.1.1 (network byte order)
</pre>

<syntaxhighlight lang="python">
import socket, struct

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
sock.bind(("0.0.0.0", 5550))

HOST_IP = "192.168.1.1"
DET_IP = "192.168.1.30"
HOST_PORT = 5550
IMG_PORT = 6660

def make_urp_packet(seq_id, pdap_bytes):
return struct.pack("<II", seq_id, 0) + pdap_bytes

pdap = struct.pack("<II", 1, 6) + struct.pack(">H", HOST_PORT) + socket.inet_aton(HOST_IP)
sock.sendto(make_urp_packet(0, pdap), ("192.168.1.255", 8100))
</syntaxhighlight>

====Step 2: Receiving the BEACON and ACKing====

The detector broadcasts a <code>BEACON</code> (cmd_type=1) roughly every 2 seconds. After sending SYSTEM_STARTUP you should get one quickly. Parse the detector SeqId from the URP header and ACK it:

<syntaxhighlight lang="python">
data, addr = sock.recvfrom(4096)
det_seq = struct.unpack_from("<I", data, 0)[0]

# send bare ACK
ack = struct.pack("<II", det_seq, 1)
sock.sendto(ack, (DET_IP, 8100))

# all subsequent commands start from here
host_seq = det_seq + 1
</syntaxhighlight>

====Step 3: PORT_SETUP====

Tells the detector which host ports to use for replies and image data.

<pre>
PDAP: [02 00 00 00] cmd_type = 2
[04 00 00 00] payload_len = 4
[15 AE] host cmd port = 5550 (big-endian)
[1A 04] host image port = 6660 (big-endian)
</pre>

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 2, 4) + struct.pack(">HH", HOST_PORT, IMG_PORT)
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1
# expect bare ACK from detector
</syntaxhighlight>

====Step 4: Reading the Serial Number (SIGNATURE_REQUEST)====

Empty command, the detector replies with a 54-byte payload containing its identity.

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 3, 0) # cmd_type=3, payload_len=0
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1

# reply is 70 bytes total: 8 URP + 8 PDAP header + 54 payload
data, _ = sock.recvfrom(4096)
payload = data[16:] # skip URP (8) + PDAP header (8)

mac = payload[0:6]
serial = payload[22:34].rstrip(b'\x00 ').decode()
model = payload[34:46].rstrip(b'\x00 ').decode()
fw_bytes = payload[46:54]
firmware = ".".join(str(b) for b in fw_bytes)

print(f"MAC: {':'.join(f'{b:02X}' for b in mac)}")
print(f"Serial: {serial}")
print(f"Model: {model}")
print(f"Firmware: {firmware}")
</syntaxhighlight>

Expected output:
<pre>
MAC: 40:F4:A0:00:78:4D
Serial: UA45829-7
Model: 5340000-7
Firmware: 1.6.0.4.2.0.1.3
</pre>

===Running an Acquisition===

After the connection sequence above, download scripts to the detector and then execute them.

====ROE Initialisation (Script 7)====

Always run this first. It initialises the readout electronics and takes about 4-5 seconds. The detector sends host event ID 17 when done.

====Dark / Offset Acquisition (Script 1)====

No X-ray source required. Runs a dark-field exposure for offset calibration. Use this to verify the acquisition pipeline without a generator.

====Standard Acquisition (Script 0)====

Requires an actual X-ray exposure. <code>EXECUTION_COMPLETE</code> will '''not''' arrive without a real X-ray trigger.

====Sequence Overview====

<pre>
HOST DETECTOR
| |
|-- SYSTEM_STARTUP (broadcast) ----------->|
|<- bare ACK -------------------------------|
|<- BEACON (cmd_type=1) --------------------|
|-- bare ACK ------------------------------>|
| |
|-- PORT_SETUP (cmd_type=2) -------------->|
|<- bare ACK -------------------------------|
| |
|-- SIGNATURE_REQUEST (cmd_type=3) ------->|
|<- SIGNATURE_REPLY (54 bytes) -------------|
|-- bare ACK ------------------------------>|
| |
|-- GENERIC_SCRIPT Script7 (ROE init) ---->|
|<- bare ACK or SCRIPT_DOWNLOAD_REPLY ------|
| |
|-- GENERIC_SCRIPT Script1 (dark acq) ---->|
|<- bare ACK -------------------------------|
| |
|-- EXECUTE_SCRIPT (cmd_type=6) ---------->|
|<- bare ACK -------------------------------|
|<- EXECUTE_SCRIPT_REPLY (~230ms) ----------|
|-- bare ACK ------------------------------>|
|<- DETECTOR_STATE_NOTIFY (~890ms) ---------| state_id=17
|-- bare ACK ------------------------------>|
| |
|<- EXECUTION_COMPLETE (0x10000) -----------|
|-- bare ACK ------------------------------>|
| |
|<- IMAGE_XFER_STATUS_QUERY (0x30000) ------|
|-- bare ACK ------------------------------>|
|-- IMAGE_XFER_STATUS_REPLY (cmd_type=9) ->| numMissed=0
|<- bare ACK -------------------------------|
</pre>

===Sequence Counter Rules===

*<code>SYSTEM_STARTUP</code> always uses <code>SeqId = 0</code>.
*After the first beacon, set host SeqId to beacon_SeqId + 1.
*Increment SeqId by 1 for every new data packet (CmdFlag=0).
*Bare ACKs echo the SeqId of the packet being acknowledged and do not consume a SeqId.
*The detector silently drops any packet with a SeqId it has already processed, so never reuse one.

==Sensor Readout and Host Registration==

This section documents the reverse engineered sensor telemetry interface and the
host registration (pairing) mechanism of the GE Optima XR200/220 AMX FlashPad
(URP detector, SuperBee, FW 1.6.0.4.2.0.1.3). All commands are PDAP over UDP to
the detector at port 8100; replies return to the host command port.

===Sensor Readout===

The detector exposes an analog sensor interface (the DEM, Detector Environment
Monitor) that is independent of the image transfer path and works regardless of
acquisition state.

====Commands====

{| class="wikitable"
!cmd_type!!Meaning!!Request payload!!Reply payload
|-
|0x7900||Raw sensor read||[sensorId:4 LE]||[value:4 LE] (12 bit ADC count)
|-
|0x7902||Converted sensor read||[sensorId:4 LE]||[value:4 LE] (engineering units, signed)
|-
|0x7904||Detailed / radio||[selector:4 LE]||[value:4 LE]
|}

Note: cmd 0x7902 IS supported on this firmware and returns calibrated
engineering units (millivolts for the supply rails, signed; 0.1 degree C for
temperatures). Earlier documentation that marked 0x7902 as unsupported is
incorrect. The host side conversion coefficients are not required; the detector
performs the conversion internally.

The full sensor map (name, sensorId) was recovered from the detector's own
[Sensor] configuration table, read back over the upload interface (see the
Registration section for the read protocol).

====Power rails (live readings)====

All supply rails read correctly via 0x7902 and are within normal range for a
flat panel detector. Representative readings:

{| class="wikitable"
!Sensor!!sensorId!!Converted!!Value
|-
|DCIN_RAW||10||12100 mV||+12.10 V (main DC input)
|-
|LCORE_UNREG||11||1724 mV||+1.72 V
|-
|LPANA_UNREG||12||5776 mV||+5.78 V
|-
|LNANA_UNREG||13||-5801 mV||-5.80 V
|-
|SCAN_VCC||14||5086 mV||+5.09 V (gate driver)
|-
|P5V_REF||16||5025 mV||+5.03 V (5 V reference)
|-
|V_ON||17||11085 mV||+11.09 V (TFT gate on)
|-
|V_OFF||18||-12378 mV||-12.38 V (TFT gate off)
|-
|V_COMMON||19||-9385 mV||-9.39 V
|-
|3V3||29||3177 mV||+3.18 V (3.3 V logic)
|-
|VCC_UNREG||37||3399 mV||+3.40 V
|-
|PARCPREG||38||3768 mV||+3.77 V (ARC preamp +)
|-
|NARCPREG||39||-3732 mV||-3.73 V (ARC preamp -)
|-
|PANA_UNREG||45||18352 mV||+18.35 V (photodiode bias +)
|-
|NANA_UNREG||46||-19251 mV||-19.25 V (photodiode bias -)
|}

Switched rails that are inactive while the panel is idle (PARCVA_U,
P5VA_SW, N5VA_SW, FGATE_NVC_L, FGATE_PVC_L, etc.) read at or near zero.

====Known limitations====

*'''Temperatures''' (Temp_Surface, sensorId 336; Temp_Panel, sensorId 352): the raw 0x7900 read rails at 0x3FF (1023, the ADC maximum), indicating an open thermistor path while the panel is idle. This is a hardware/state condition, not a command problem, and the temperature is not readable from the host in this state.
*'''Unimplemented sensors''': sensorIds 70 (Accelerator), 78 (Gravity), and 256 to 259 (Battery status, name, life, capacity), and 272 (Grid status) are not implemented on this DEM. The detector returns the leftover conversion register contents (a duplicate of a previously read sensor) rather than a real value, so these rows must be discarded.
*'''Accelerometer''': functional through a separate addressing scheme using raw cmd 0x7900 with selectors 0x42 (X), 0x43 (Y), 0x44 (Z), returning 12 bit per axis counts.

===Host Registration (Pairing)===

URP stands for Unified Registration Protocol. The detector maintains a host
list in its internal NOR flash. Image data is delivered only to a registered
primary host, so registration is a prerequisite for image transfer.

====Host identity (MAC and HostId)====

Each host is identified by a 16 character HostId derived deterministically from
the host's eth0 MAC address. The derivation (from the vendor generateHostId
script) is:

#Take the eth0 MAC, remove the colon separators, convert to upper case (12 hex characters).
#Prepend the last 4 characters to the full 12 characters.
#The result is 16 hex characters.

Example: MAC 00:6f:00:01:0a:3a becomes 006F00010A3A, then the last four (0A3A)
are prepended, giving HostId 0A3A006F00010A3A.

====HostList structure====

The host list is stored in flash at offset 0x940000 and can be read back over
the upload interface as data category 0x71. Layout:

Offset Size Field
0x00 16 DetectorDeviceId (ASCII)
0x10 16 ConnectionSecretKey (ASCII; "XXXXXXXXXXXXXXXX" when unset)
0x20 16 DetectorName (ASCII)
0x30 16 DetectorCode (ASCII)
0x40 2 CurrentNumberOfHosts (uint16 LE)
0x42 2 IndexToPrimaryHost (uint16 LE; 0xFFFF = none)
0x44 144*N Host entries, 144 bytes each:
+0x00 16 HostId (ASCII)
+0x10 .. host name / department string
+0x50 .. location string
... 4 CRC (big endian; see below)

====HostList from the unit under test====

Detector: MAC 40:F4:A0:00:78:4D, serial UA45829-7, model 5340000-7,
firmware 1.6.0.4.2.0.1.3. DetectorName starShape_green. ConnectionSecretKey
unset. CurrentNumberOfHosts = 3, IndexToPrimaryHost = 0xFFFF (no primary host).

{| class="wikitable"
!Index!!HostId!!Derived MAC!!Name
|-
|0||2C6400045FB42C64||00:04:5F:B4:2C:64||Haus 207 / ITS
|-
|1||B044E8393512B044||E8:39:35:12:B0:44||Not Initialized
|-
|2||5CF800045FB15CF8||00:04:5F:B1:5C:F8||Not_Initialized
|}

The unit is therefore not factory fresh; it carries registrations from a prior
deployment, but no primary host is currently designated.

====Checksum (CRC)====

The HostList (and other flash data blobs) are protected by a 4 byte trailing
CRC. Parameters:

*Polynomial: 0x04C11DB7
*Initial value: 0
*MSB first, augmented message style (the data bit is shifted into the LSB; no input or output reflection; no final XOR)
*Stored big endian

To generate: compute the CRC over the data followed by four zero bytes, then
append the result big endian. Verification: the CRC over (data plus stored CRC)
equals zero.

def crc(data, poly=0x04C11DB7, init=0):
c = init
for byte in data:
for bit in (0x80,0x40,0x20,0x10,0x08,0x04,0x02,0x01):
msb = c & 0x80000000
c = (c << 1) & 0xFFFFFFFF
if byte & bit: c |= 1
if msb: c ^= poly
return c
# trailer = crc(data + b"\x00\x00\x00\x00"), stored big endian

====Read and write transport====

Data blobs (including the HostList) are moved with a configure / buffer /
finalize sequence.

Read (upload, detector to host), non destructive:

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x13||[uploadId:4 LE]||[status:1][totalSize:4 LE]
|-
|Buffer||0x14||[bufId:4 LE][numBytes:4 LE]||[bufId:4 LE][numBytes:4 LE][data]
|}

Write (download, host to detector), persistent (writes flash):

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x0E||[downloadId:4 LE][totalSize:4 LE]||[status:1]
|-
|Buffer||0x0F||[bufId:4 LE][numBytes:4 LE][data]||[status:1][reserved:4]
|-
|Commit||0x10||(empty)||[status:1]
|}

bufId is a zero based chunk index. The HostList uses id 0x71 for both read and
write. The commit command (0x10) reuses the firmware flash path, so a malformed
download can corrupt flash; the operation is irreversible on this hardware.

====Registering a new host====

To register a host and make it the image destination, read the current HostList
(0x71), append a 144 byte entry carrying the new HostId, increment
CurrentNumberOfHosts, set IndexToPrimaryHost to the new entry's index,
recompute the trailing CRC, and write the blob back via the download sequence
(0x0E / 0x0F / 0x10).

===Reading the Drop and Shock Event Log===

The detector contains an accelerometer based shock watchdog that records drop
and impact events into non volatile memory. This log is useful when evaluating a
used unit, since it reveals how many serious shocks the panel has survived and
when. The same data is held both in the main flash (read over the network) and
in the small onboard EEPROM on the detector PCB.

====How to read it====

The shock log is exposed as data category 0x72 on the upload (read) interface.
It is retrieved with the standard non destructive configure and buffer sequence
(cmd 0x13 to configure, cmd 0x14 to pull the chunks). On the unit under test the
blob is 3001 bytes of plain text in the GE .dyn configuration format, so no
decoding is required beyond reading it as ASCII.

The same records are mirrored in binary form in the onboard 24LC256 EEPROM
(32 KB I2C part) for anyone reading the hardware directly.

====Example output====

The following is the actual log read from detector serial UA45829-7. The file
has two parts: a list of individual events (DetectorShockEvents) and a summary
block (DetectorShockData). Each event carries a record key, a severity, a
timestamp, and the peak acceleration on each axis. Two representative records:

<DetectorShockEvents>
[149266438700135]
Severity.Type = String
Severity.Val = Serious
TimeStamp.Type = String
TimeStamp.Val = 2017-4-20,6:59:47
ValidTime.Type = Number
ValidTime.Val = 0
VibrationX.Type = Number
VibrationX.Val = 0
VibrationY.Type = Number
VibrationY.Val = 0
VibrationZ.Type = Number
VibrationZ.Val = 135

[1592113924-1720-113]
Severity.Val = Serious
TimeStamp.Val = 2020-6-14,7:52:4
VibrationX.Val = -172
VibrationY.Val = 0
VibrationZ.Val = -113

The summary block at the end lists the totals and an index of all event keys:

[DetectorShockData]
LastKnownGoodTime.Val = 2024-4-4,6:53:59
NumberOfL3Events.Val = 0
NumberOfL5Events.Val = 7
ShockDataTimeList.Val = { 1643260890-1320-119, 163626503500-123,
160818190500-101, 160524243000170, 1592113924-1720-113,
157804584600183, 149266438700135 }

====Interpreting the records====

The record key encodes the event time and the peak axis values (an epoch style
timestamp followed by the concatenated vibration readings), so it is unique per
event. The VibrationX, VibrationY, and VibrationZ values are signed peak
acceleration counts on each axis. Severity is reported as Serious for all
logged events on this unit, which corresponds to the L5 (highest) severity class
counted in the summary.

The seven recorded events for this detector:

{| class="wikitable"
!Date and time!!VibrationX!!VibrationY!!VibrationZ
|-
|2017-04-20 06:59:47||0||0||135
|-
|2020-01-03 11:04:06||0||0||183
|-
|2020-06-14 07:52:04||-172||0||-113
|-
|2020-11-13 05:40:30||0||0||170
|-
|2020-12-17 06:11:45||0||0||-101
|-
|2021-11-07 07:03:55||0||0||-123
|-
|2022-01-27 06:21:30||-132||0||-119
|}

====Reading the summary fields====

{| class="wikitable"
!Field!!Meaning
|-
|LastKnownGoodTime||Timestamp of the last successful self check (here 2024-04-04), the most recent point at which the detector was known to be operating normally
|-
|NumberOfL3Events||Count of lower severity (L3) shock events; zero on this unit
|-
|NumberOfL5Events||Count of high severity (L5) shock events; seven on this unit, matching the seven records above
|-
|ShockDataTimeList||Index of all stored event keys, newest first
|}

On this example the panel logged seven serious impacts over roughly five years
of field use and last reported a good self check in April 2024.

==FlashPad Detector: Internal Flash Dump and Data Files==

This section documents how the full contents of the detector's internal flash
were extracted over the network and what each recovered file contains. The
detector under test is a GE Optima XR200/220 AMX FlashPad (URP detector,
serial UA45829-7, MAC 40:F4:A0:00:78:4D, firmware 1.6.0.4.2.0.1.3).

===Background===

The detector's main storage is a Spansion/Cypress S29GL512P (marked
GL512P10FFCR2), a 512 Mbit (64 MB) parallel NOR flash. A direct chip read
requires bus access or desoldering and a programmer. However, the detector
firmware exposes its stored data blobs, including a full image of the flash,
through the read (upload) side of the data transport protocol. This makes a
complete, byte exact dump possible over UDP with no physical access.

===Extraction method===

The upload interface is the read counterpart of the firmware download path and
is non destructive (it only reports and returns data; nothing is written).
Each data category is identified by an 8 bit upload ID:

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x13||[uploadId:4 LE]||[status:1][totalSize:4 LE]
|-
|Buffer||0x14||[bufId:4 LE][numBytes:4 LE]||[bufId:4 LE][numBytes:4 LE][data]
|}

A configure request returns status 0 and a total size for a valid ID, or a non
zero status for an unsupported ID. The dump tool sweeps all IDs from 0x00 to
0xFF, and for every readable ID it pulls the full blob in fixed size chunks
(bufId is a zero based chunk index) and writes it to a file. The 64 MB flash
image transfers as 65536 chunks of 1024 bytes.

===Recovered files===

A sweep of the unit returned 18 readable blobs:

{| class="wikitable"
!Upload ID!!Size (bytes)!!Contents
|-
|0xFD||67108864||Full 64 MB NOR flash image
|-
|0xFF||16777216||16 MB region (firmware / FPGA mirror or image buffer)
|-
|0xFE||524288||Bootloader (512 KB; SPI loader, Nios reset code)
|-
|0x10||6815783||Calibration map, dose level 1
|-
|0x11||6815783||Calibration map, dose level 2
|-
|0x12||6815783||Calibration map, dose level 3
|-
|0x06||49254||Table referencing conditioner/generator serial UA2010-8U005
|-
|0x50||19938||Per mode calibration coefficients
|-
|0x51||19582||Per mode calibration coefficients
|-
|0x07||12187||Sensor conversion table (text; see Sensor Readout)
|-
|0x72||3001||Shock / drop event log (text)
|-
|0x0E||624||Panel geometry / configuration (binary)
|-
|0x71||504||Host list / registration record (see Host Registration)
|-
|0x0F||233||Host to detector compatibility table (text)
|-
|0x08||62||Serial and model strings
|-
|0x0A||48||Manufacturing codes
|-
|0x52||30||Serial string
|-
|0x0B||24||Small marker / identifier
|}

===Flash image layout (upload ID 0xFD)===

A block scan of the 64 MB image shows the following regions:

{| class="wikitable"
!Range!!Contents
|-
|0x000000 to 0x800000||Firmware and FPGA configuration
|-
|0x800000 to 0x940000||Sparse configuration area
|-
|0x940000||Host list / registration record (matches upload ID 0x71)
|-
|0x1000000 to 0x2800000||Calibration and image data (16 to 40 MB)
|-
|0x2800000 to 0x4000000||Erased / unused (40 to 64 MB)
|}

The host list strings (the DetectorName starShape_green, the registered host
name Haus 207 / ITS, and the unset ConnectionSecretKey placeholder) appear at
0x940000, confirming that the 504 byte 0x71 read maps to this flash region.

===Notes on individual files===

*'''0x07 (sensor table)''': plain text, header DetectorSerialNumber = UA45829-7, revision 1.2. Lists every sensor by name, command (0x7902), and sensorId. Also carries panel geometry in its [Common] section: 16 bit depth, 2048 by 2048 pixels, active area from (12, 12) to (2035, 2035), pixel pitch 0.2 mm, corner radius 1416.8, panel saturation 150.
*'''0x10, 0x11, 0x12 (calibration maps)''': three distinct blobs of identical size, corresponding to the low, medium, and high dose calibration sets. Each begins with the firmware version and serial (header bytes 01 06 00 04 02 00 01 03 followed by the serial). Required to apply gain and offset correction to raw images.
*'''0xFE (bootloader)''': contains the strings spi_load.S and ../../boot and Nios II reset vector code.
*'''0x72 (shock log)''': text records of drop / vibration events with timestamps and per axis values; the same data is mirrored in the detector's small onboard EEPROM.
*'''0x06''': references a different serial, UA2010-8U005, likely the conditioner or generator board rather than the panel.

===Significance===

The complete flash image and all calibration data are recoverable over the
network without opening the detector, providing a full byte exact backup of the
unit before any write operation. The calibration maps are needed for image
correction, and the firmware image (the live, deployed build) is more complete
than the partial firmware files shipped on the recovery media.

==Teardown / Internal Pictures / Hardware analysis==

<gallery mode="packed" heights="200">
File:GE Flashpad under the hood.jpg|the Carbon fiber sleeve is held by 9 screws and can taken off without force.
File:Ge flashpad powersupply pcb in handle.jpg|Power supply PCB
File:Ge flashpad uwb board pcb.jpg|UWB PCB for Wireless USB using a RTU2705
File:Ge flashpad uwb pcb backside.jpg|Backside of UWB PCB
File:Ge flashpad power supply pcb backside.jpg|Backside of Power supply PCB
File:Ge flashpad main pcb closeup1.jpg|Main area of the PCB with its Altera Cyclone 3 FPGA
File:Ge flashpad main pcb closeup2.jpg|AD7892 is a 600ksps 12bit ADC, SN74LVC8T245 a 8bit bus transceiver and DG9408EDN a 8ch MUX
File:Ge flashpad bottom connector ethernet isolation pcb.jpg|Isolation PCB for bottom connector
File:Ge flashpad main pcb powersupply section.jpg|Powersupply section for FPGA and ROIC
File:Ge flashpad main pcb closeup 3.jpg|AD9764AR 14-Bit, 125 MSPS DAC and DS1682 integrated elapsed-time recorder
File:Ge flashpad main pcb closeup 4.jpg|Accelerometer is a 834-0500 500G 3 Axis unit, and TJ500AE SPDT gigabit LAN switch
File:Ge flashpad bottom connector.jpg|bottom connector for docking stand
File:Ge flashpad main pcb closeup 5.jpg|Ethernet transformers and ADM34 RS-485/RS-422 Transceiver
File:Ge flashpad main pcb closeup 6.jpg|Altera EPM570f100c5n CPLD
File:Ge flashpad main pcb closeup 7.jpg|Spansion GL512P10FF1R1 512 Mbit NOR flash IC holding everything
File:Ge flashpad main pcb closeup 8.jpg|24LC256I 32k EEPROM for storing the accelerometer events
</gallery>

==Main test py script: Usage and Parameters==

current iteration found here: https://pastebin.com/vEfAresk

flashpad_acquire.py is a single file Python 3 tool that speaks the FlashPad
URP/PDAP protocol over UDP. It implements discovery, the control handshake,
script download and execution, sensor readout, full data backup, and the host
registration (pairing) write. It requires only the Python standard library.

===Default network configuration===

These defaults match the values in ConnectionPoint.cfg and can be overridden on
the command line.

{| class="wikitable"
!Setting!!Default!!Meaning
|-
|Detector IP||192.168.1.30||the panel; listens for all commands on UDP 8100
|-
|Host IP||192.168.1.1||this machine, announced in SYSTEM_STARTUP
|-
|Detector port||8100||where commands are sent
|-
|Host command port||5550||where the detector returns protocol replies
|-
|Host image port||6660||where pixel data would stream
|-
|Discovery port||4500||where the detector sends its beacons
|}

===Connection and general options===

{| class="wikitable"
!Option!!Default!!Effect
|-
| --detector-ip IP||192.168.1.30||detector address
|-
| --host-ip IP||192.168.1.1||host address sent in SYSTEM_STARTUP
|-
| --output-dir DIR||.||where raw images are written
|-
| --timeout SECONDS||5.0||UDP receive timeout
|-
| --exec-timeout SECONDS||60||how long to wait for EXECUTION_COMPLETE
|-
| --skip-discovery||off||send SYSTEM_STARTUP once and proceed, skipping the discovery loop
|-
| --quiet||off||suppress the verbose per packet log
|}

===Read and diagnostic modes (non destructive)===

These only read from the detector. None of them write anything.

{| class="wikitable"
!Option!!What it does!!What to expect
|-
| --sensors||Reads the full 32 entry sensor table using cmd 0x7902 (converted) and 0x7900 (raw), side by side.||A decoded table of supply rails in volts. Temperatures show as railed. Unimplemented sensors (accelerometer DEM id, battery, grid) are flagged as stale.
|-
| --no-roe-init||With --sensors, skips the Script7 ROE init before reading.||Slightly faster sensor read, marginally less reliable.
|-
| --probe-data||Reads DetectorInfo, the HostList (registration state), and cal results via the upload protocol (cmd 0x13/0x14).||A hexdump and text decode of each. Shows whether any host is registered and which HostId the detector expects.
|-
| --backup [DIR]||Sweeps all upload IDs 0x00 to 0xFF and saves every readable blob to DIR/detector_backup_timestamp/.||A manifest plus one .bin per readable ID, including the full 64 MB flash image and the calibration maps. Do this before any write. Large blobs take a few minutes each.
|-
| --backup-range LO-HI||Limits the --backup sweep, for example 0x40-0xA0.||Faster, partial backup.
|-
| --dump-scripts||Prints the wire bytes of all built scripts as hex and exits.||No network activity; useful for inspecting the script encoding.
|-
| --listen||Passively listens on the host command port for 30 seconds.||Prints any packets the detector sends; useful for watching beacons.
|}

===Acquisition modes===

The default invocation (no mode flag) runs a standard acquisition, which
requires an actual X-ray exposure to complete.

{| class="wikitable"
!Option!!What it does!!What to expect
|-
|(no flag)||Standard acquisition (Script 0).||Needs an X-ray exposure to reach EXECUTION_COMPLETE.
|-
| --dark||Runs the dark/offset acquisition (Script 1) before the standard one.||Two acquisitions; the dark one needs no X-ray.
|-
| --dark-only||Runs only the dark acquisition (Script 1).||Completes in a few seconds with no X-ray. The detector acquires and holds an 8 buffer image. Best way to test the full flow.
|-
| --no-standby||Omits the Script 8 standby loop.||Use if the standby loop blocks acquisition.
|-
| --two-exec||Executes Script 7 alone, waits, then Script 1. Only with --dark-only.||Tests the two stage execution hypothesis.
|-
| --parallel||Answers the detector status query (0x30000) with the cmd 0x99 ParallelImageTransfer reply instead of cmd 9.||Experiment to see if the parallel reply triggers a pixel push. (Result so far: it does not.)
|-
| --sweep-acq||Sweeps the dark acquisition across type_mode and transfer_mode values, watching for a 0x0F pixel push.||Non destructive experiment; reports which combination, if any, makes the detector stream.
|-
| --preview||Single dark acquisition on the preview path (transfer_mode 2, 4 buffer image). Watches port 6660 for a push.||One clean connection; run a packet capture on the detector address in parallel.
|}

Note: at present the detector acquires and holds an image but does not push the
0x0F pixel frames. The acquisition modes complete the handshake and acquisition,
but image streaming is still being investigated.

===Registration and write operations===

These can write to the detector's flash. Every write is a dry run by default and
only takes effect when --commit is added. Always run --backup first.

{| class="wikitable"
!Option!!What it does
|-
| --register-self||Adds this host to the detector HostList and sets it as the primary host, so the detector should stream images to it. Appends an entry, sets IndexToPrimaryHost, recomputes the CRC, and writes via id 0x71. Dry run unless --commit.
|-
| --host-mac MAC||The MAC of the interface talking to the detector, used to derive this host's HostId for --register-self. Default 00:6f:00:01:0a:3a.
|-
| --smoke-test-write||Reads the HostList and writes back the identical bytes to validate the write and commit path without changing anything. Dry run unless --commit.
|-
| --restore-hostlist FILE||Writes a saved HostList blob (for example detector_backup_*/upload_0x71_504.bin) back to the detector. This is the undo button. Dry run unless --commit.
|-
| --commit||Arms the actual flash write for the operations above. Without it they only print what they would do. This writes the detector's flash and is irreversible at the chip level, although the HostList region can be restored from a backup.
|}

===Typical workflow===

#Read the current state: <code>python flashpad_acquire.py --probe-data</code>
#Make a full backup: <code>python flashpad_acquire.py --backup</code>
#Check sensors and power rails: <code>python flashpad_acquire.py --sensors</code>
#Dry run the registration: <code>python flashpad_acquire.py --register-self --host-mac YOUR:MAC</code>
#When satisfied, commit it: add <code>--commit</code>
#If needed, undo: <code>python flashpad_acquire.py --restore-hostlist detector_backup_*/upload_0x71_504.bin --commit</code>

==Known Dead Ends==

Things that were tried and did not work or led nowhere:

;0xBEEF (48879) as reply port
:This was a bug in early test scripts. The port has no meaning in the protocol. Use 5550.

;CmdFlag=1 as data packet flag
:Early scripts had the URP fields swapped, setting CmdFlag=1 on data packets. The detector ignores all PDAP content in these packets. Power cycle the detector if this happened, it may retain stale port state.

;Image data on alternate ports
:Tried listening on 48879, 6660, 5550, 8100, 1050, 6661, 9999, 4444, 7000, 7001, 9001. Nothing arrived on any of them.

;PORT_SETUP byte order (big-endian)
:Current implementation sends port fields as big-endian. If the detector reads them as little-endian it computes port 44565 and 1050 instead of 5550 and 6660, which would explain why no image data arrives. Not yet confirmed.

;Image data streaming automatically after EXECUTE_SCRIPT
:Frames may not push during execution at all. The detector may require an explicit IMAGE_RETRIVAL_REQUEST (cmd_type=0x41) and IMAGE_RETRIVAL (cmd_type=0x98) after the 0x30000 notification before it streams anything. Not yet tested.

GE Medical Flashpad Digital Xray Detector

2026-06-11T12:22:07Z

Gamerpaddy:

==Overview==
{{Note|UNFINISHED Project, it was not yet possible to retrieve a exposure or dark frame in my testing, further investigation needed. any help is appreciated on recessim discord.}}

The '''GE Flashpad''' is a Digital Radiography image sensor from approximately 2010, originally used in the '''GE Optima 220AMX''' mobile X-ray unit. It was designed to replace analog film in radiology, dramatically reducing image acquisition time from hours to seconds.
[[File:GE Flashpad.jpg|thumb|Flashpad with Anti-Scatter grid (left), manual and recovery dvd for 220amx and tether cord (right)]]
Due to its high original cost and specialized application, used units occasionally appear on professional B2B marketplaces in the $15,000–$50,000 range. On eBay, prices typically fall between $1,500 and $5,000, though units at this price point are often in poor condition and may fail the built-in self-test or not function at all.

{{Note|All findings on this page are based on a single unit and the time spent working on it. Information is subject to speculation and may not be fully accurate.}}

{{Note|AI assistance was used in writing this page for improved formatting and readability, as well as in the process of finding information, testing, and analyzing firmware dumps and backups.}}

==Purpose and Motivation==

This project documents the reverse engineering of the GE FlashPad wireless
digital radiography detector used with the Optima XR200/220 AMX mobile X-ray
system, with the goal of freeing these detectors for independent use.
[[File:Xray capture pcb.png|thumb|Xray capture of a PCB for Reverse Engineering using a different detector]]
Large numbers of these detectors reach the used market, but each one is bound to its original Optima 220 AMX
console. Once separated from that console, or once the console is
decommissioned, the detector is effectively useless even though the hardware is
fully functional. There is a Windows software but it is not obtainable. The aim of this work is to remove that artificial barrier so
that a standalone FlashPad can be paired, configured, and read out by any host,
without the half million dollar console it was sold with.

The intended beneficiaries are:

*Hobbyists, researchers, and engineers who want a high quality flat panel detector for their own imaging projects. for example studying the fluid movement in plants. https://www.youtube.com/watch?v=j-FHbHoiwNk (Xray timelapse by Ben Krasnow / Applied Science using a GE Flashpad)
*Veterinary practices, which can put surplus human grade detectors to good use at a fraction of the cost of new equipment.
*Clinics and hospitals in countries and regions where a complete commercial system is unaffordable, allowing serviceable detectors to keep providing diagnostic imaging instead of being scrapped.

[[File:Xray current clamp multimeter.png|thumb|xray of a current clamp multimeter using a different detector]]
This is done for human good. Every detector returned to service is one less
piece of working medical hardware sent to landfill, and potentially one more
place that can offer X-ray imaging where it otherwise could not.

All files, findings, protocol documentation, and tools produced by this project
are public and open source, so that anyone can study, reproduce, and build on
the work.

==Technical Specifications==
[[File:Ge flashpad tether cable pinout diagram.png|thumb|Pinout Diagram of the Tether cable]]
[[File:Ge flashpad tether wiring for ethernet cable.jpg|thumb|Professional Tether wiring to attach a Ethernet Cable and 12V socket to it.]]
The Flashpad uses a '''~40 × 40 cm CsI scintillator''' bonded to a [[Thin-film transistor|TFT]] photodetector array mounted on glass. The assembly is highly sensitive to shock and impact damage. See section [[#Reading the Drop and Shock Event Log|drop and shock event log]]

{| class="wikitable"
|-
!Parameter!!Value
|-
|Resolution||2048 × 2048 px
|-
|Bit depth||16-bit per pixel
|-
|Spatial resolution||Up to 5 lp/mm (theoretical)
|-
|Scintillator material||Caesium iodide (CsI)
|-
|Detector type||TFT photodetector array (glass substrate)
|-
|Panel size||~40 × 40 cm
|}

The theoretical 5 lp/mm spatial resolution is primarily limited in practice by the focal spot size of the X-ray source. Use of an anti-scatter grid can improve effective resolution.

===Status of Reverse Engineering===

{| class="wikitable"
|-
!What!!Status
|-
|Connect, beacon, ACK||Works
|-
|PORT_SETUP||Works
|-
|SIGNATURE_REQUEST / serial number readout||Works
|-
|Script download (Scripts 7, 8, 1)||Works
|-
|EXECUTE_SCRIPT||Works
|-
|EXECUTION_COMPLETE (dark acquisition)||Works but without image readout its speculation.
|-
|EXECUTION_COMPLETE (standard acquisition)||Needs real X-ray trigger to test
|-
|Image data on port 6660||Does not work yet, under investigation. Will not send Imagedata...
|}

==Hardware Features==

===Shock logging===
The unit contains an internal accelerometer that logs significant shock events — but only when a battery is inserted. As there is no backup battery, shock events occurring while unpowered are not recorded.

===Wireless connectivity===
Some units include a UWB transmitter for Wireless USB; others may be equipped with a Wi-Fi module instead. The detector can also be operated over the tethered connection alone.

===Ethernet interface===
There is a 100MBit Ethernet interface trough the Tether Cable which can be tapped and used for Communication.
Exposed metal contacts on the bottom connector are isolated via relays by default. Enabling Gigabit Ethernet connectivity requires shorting or driving two specific pins. This has not been investigated further at this time.

==Communication Protocol==

This section documents the URP/PDAP protocol used by the GE Flashpad (codename '''Apollo''') to communicate with a host over Ethernet. All findings are based on live capture tests, configuration files, and reverse-engineering of the GE SuperBee software stack.

{{Note|All findings are based on a single unit and may not be fully accurate.}}

===Network Setup===

All findings were over Ethernet only, no UWB or WIFI has been used.
Default detector IP is <code>192.168.1.30</code>. Set your host to a static IP in the same subnet, <code>192.168.1.1</code> works fine.

At first by sending random bytes over Python it answered to port 48879 (0xBEEF), which seems to be either the default port or set by Python.
After SYSTEM_SETUP it got set to 5550.

{| class="wikitable"
|-
!Role!!IP!!Port!!Direction
|-
|All commands: host -> detector||192.168.1.30||'''8100''' (UDP)||Host sends here
|-
|Discovery beacons: detector -> host||-||'''4500''' (UDP)||Detector sends here initially
|-
|Protocol replies: detector -> host||-||'''5550''' (UDP)||Detector sends here after setup
|-
|Image pixel data: detector -> host||-||'''6660''' (UDP)||Detector streams frames here
|}

In practice you can listen on port '''5550''' for everything (beacons and replies) by advertising that port in both <code>SYSTEM_STARTUP</code> and <code>PORT_SETUP</code>. The detector sends to whichever port was most recently configured.

===Protocol Layers===

Two layers, carried over UDP:

;URP (Unified Registration Protocol)
:8-byte wrapper on every packet. Handles sequencing and acknowledgement.

;PDAP (Proprietary Detector Access Protocol)
:The actual command layer, present inside URP packets when <code>CmdFlag = 0</code>.

Every UDP packet starts with a URP header:

<pre>
[SeqId : 4 bytes LE] [CmdFlag : 4 bytes LE]
</pre>

*<code>CmdFlag = 0</code> -- data packet, PDAP command follows.
*<code>CmdFlag = 1</code> -- bare ACK, no PDAP body. SeqId echoes the packet being acknowledged.

Both sides must ACK every data packet immediately. The detector silently drops packets with a SeqId it has already seen, so always increment SeqId for each new command.

When CmdFlag is 0, the PDAP header follows immediately:

<pre>
[cmd_type : 4 bytes LE] [payload_len : 4 bytes LE] [payload ...]
</pre>

===Connecting to the Detector===

The connection sequence is:

#Broadcast <code>SYSTEM_STARTUP</code> to tell the detector where to reply.
#The detector sends a <code>BEACON</code> back -- ACK it and sync your sequence counter.
#Send <code>PORT_SETUP</code> to configure the reply and image ports.
#Send <code>SIGNATURE_REQUEST</code> to read the detector identity (serial number, model, firmware, MAC).

====Step 1: SYSTEM_STARTUP====

Broadcast UDP to <code>192.168.1.255:8100</code>. Always uses <code>SeqId = 0</code>.

<pre>
URP : [00 00 00 00] SeqId = 0
[00 00 00 00] CmdFlag = 0
PDAP: [01 00 00 00] cmd_type = 1
[06 00 00 00] payload_len = 6
[15 AE] host reply port = 5550 (big-endian)
[C0 A8 01 01] host IP = 192.168.1.1 (network byte order)
</pre>

<syntaxhighlight lang="python">
import socket, struct

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
sock.bind(("0.0.0.0", 5550))

HOST_IP = "192.168.1.1"
DET_IP = "192.168.1.30"
HOST_PORT = 5550
IMG_PORT = 6660

def make_urp_packet(seq_id, pdap_bytes):
return struct.pack("<II", seq_id, 0) + pdap_bytes

pdap = struct.pack("<II", 1, 6) + struct.pack(">H", HOST_PORT) + socket.inet_aton(HOST_IP)
sock.sendto(make_urp_packet(0, pdap), ("192.168.1.255", 8100))
</syntaxhighlight>

====Step 2: Receiving the BEACON and ACKing====

The detector broadcasts a <code>BEACON</code> (cmd_type=1) roughly every 2 seconds. After sending SYSTEM_STARTUP you should get one quickly. Parse the detector SeqId from the URP header and ACK it:

<syntaxhighlight lang="python">
data, addr = sock.recvfrom(4096)
det_seq = struct.unpack_from("<I", data, 0)[0]

# send bare ACK
ack = struct.pack("<II", det_seq, 1)
sock.sendto(ack, (DET_IP, 8100))

# all subsequent commands start from here
host_seq = det_seq + 1
</syntaxhighlight>

====Step 3: PORT_SETUP====

Tells the detector which host ports to use for replies and image data.

<pre>
PDAP: [02 00 00 00] cmd_type = 2
[04 00 00 00] payload_len = 4
[15 AE] host cmd port = 5550 (big-endian)
[1A 04] host image port = 6660 (big-endian)
</pre>

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 2, 4) + struct.pack(">HH", HOST_PORT, IMG_PORT)
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1
# expect bare ACK from detector
</syntaxhighlight>

====Step 4: Reading the Serial Number (SIGNATURE_REQUEST)====

Empty command, the detector replies with a 54-byte payload containing its identity.

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 3, 0) # cmd_type=3, payload_len=0
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1

# reply is 70 bytes total: 8 URP + 8 PDAP header + 54 payload
data, _ = sock.recvfrom(4096)
payload = data[16:] # skip URP (8) + PDAP header (8)

mac = payload[0:6]
serial = payload[22:34].rstrip(b'\x00 ').decode()
model = payload[34:46].rstrip(b'\x00 ').decode()
fw_bytes = payload[46:54]
firmware = ".".join(str(b) for b in fw_bytes)

print(f"MAC: {':'.join(f'{b:02X}' for b in mac)}")
print(f"Serial: {serial}")
print(f"Model: {model}")
print(f"Firmware: {firmware}")
</syntaxhighlight>

Expected output:
<pre>
MAC: 40:F4:A0:00:78:4D
Serial: UA45829-7
Model: 5340000-7
Firmware: 1.6.0.4.2.0.1.3
</pre>

===Running an Acquisition===

After the connection sequence above, download scripts to the detector and then execute them.

====ROE Initialisation (Script 7)====

Always run this first. It initialises the readout electronics and takes about 4-5 seconds. The detector sends host event ID 17 when done.

====Dark / Offset Acquisition (Script 1)====

No X-ray source required. Runs a dark-field exposure for offset calibration. Use this to verify the acquisition pipeline without a generator.

====Standard Acquisition (Script 0)====

Requires an actual X-ray exposure. <code>EXECUTION_COMPLETE</code> will '''not''' arrive without a real X-ray trigger.

====Sequence Overview====

<pre>
HOST DETECTOR
| |
|-- SYSTEM_STARTUP (broadcast) ----------->|
|<- bare ACK -------------------------------|
|<- BEACON (cmd_type=1) --------------------|
|-- bare ACK ------------------------------>|
| |
|-- PORT_SETUP (cmd_type=2) -------------->|
|<- bare ACK -------------------------------|
| |
|-- SIGNATURE_REQUEST (cmd_type=3) ------->|
|<- SIGNATURE_REPLY (54 bytes) -------------|
|-- bare ACK ------------------------------>|
| |
|-- GENERIC_SCRIPT Script7 (ROE init) ---->|
|<- bare ACK or SCRIPT_DOWNLOAD_REPLY ------|
| |
|-- GENERIC_SCRIPT Script1 (dark acq) ---->|
|<- bare ACK -------------------------------|
| |
|-- EXECUTE_SCRIPT (cmd_type=6) ---------->|
|<- bare ACK -------------------------------|
|<- EXECUTE_SCRIPT_REPLY (~230ms) ----------|
|-- bare ACK ------------------------------>|
|<- DETECTOR_STATE_NOTIFY (~890ms) ---------| state_id=17
|-- bare ACK ------------------------------>|
| |
|<- EXECUTION_COMPLETE (0x10000) -----------|
|-- bare ACK ------------------------------>|
| |
|<- IMAGE_XFER_STATUS_QUERY (0x30000) ------|
|-- bare ACK ------------------------------>|
|-- IMAGE_XFER_STATUS_REPLY (cmd_type=9) ->| numMissed=0
|<- bare ACK -------------------------------|
</pre>

===Sequence Counter Rules===

*<code>SYSTEM_STARTUP</code> always uses <code>SeqId = 0</code>.
*After the first beacon, set host SeqId to beacon_SeqId + 1.
*Increment SeqId by 1 for every new data packet (CmdFlag=0).
*Bare ACKs echo the SeqId of the packet being acknowledged and do not consume a SeqId.
*The detector silently drops any packet with a SeqId it has already processed, so never reuse one.

==Sensor Readout and Host Registration==

This section documents the reverse engineered sensor telemetry interface and the
host registration (pairing) mechanism of the GE Optima XR200/220 AMX FlashPad
(URP detector, SuperBee, FW 1.6.0.4.2.0.1.3). All commands are PDAP over UDP to
the detector at port 8100; replies return to the host command port.

===Sensor Readout===

The detector exposes an analog sensor interface (the DEM, Detector Environment
Monitor) that is independent of the image transfer path and works regardless of
acquisition state.

====Commands====

{| class="wikitable"
!cmd_type!!Meaning!!Request payload!!Reply payload
|-
|0x7900||Raw sensor read||[sensorId:4 LE]||[value:4 LE] (12 bit ADC count)
|-
|0x7902||Converted sensor read||[sensorId:4 LE]||[value:4 LE] (engineering units, signed)
|-
|0x7904||Detailed / radio||[selector:4 LE]||[value:4 LE]
|}

Note: cmd 0x7902 IS supported on this firmware and returns calibrated
engineering units (millivolts for the supply rails, signed; 0.1 degree C for
temperatures). Earlier documentation that marked 0x7902 as unsupported is
incorrect. The host side conversion coefficients are not required; the detector
performs the conversion internally.

The full sensor map (name, sensorId) was recovered from the detector's own
[Sensor] configuration table, read back over the upload interface (see the
Registration section for the read protocol).

====Power rails (live readings)====

All supply rails read correctly via 0x7902 and are within normal range for a
flat panel detector. Representative readings:

{| class="wikitable"
!Sensor!!sensorId!!Converted!!Value
|-
|DCIN_RAW||10||12100 mV||+12.10 V (main DC input)
|-
|LCORE_UNREG||11||1724 mV||+1.72 V
|-
|LPANA_UNREG||12||5776 mV||+5.78 V
|-
|LNANA_UNREG||13||-5801 mV||-5.80 V
|-
|SCAN_VCC||14||5086 mV||+5.09 V (gate driver)
|-
|P5V_REF||16||5025 mV||+5.03 V (5 V reference)
|-
|V_ON||17||11085 mV||+11.09 V (TFT gate on)
|-
|V_OFF||18||-12378 mV||-12.38 V (TFT gate off)
|-
|V_COMMON||19||-9385 mV||-9.39 V
|-
|3V3||29||3177 mV||+3.18 V (3.3 V logic)
|-
|VCC_UNREG||37||3399 mV||+3.40 V
|-
|PARCPREG||38||3768 mV||+3.77 V (ARC preamp +)
|-
|NARCPREG||39||-3732 mV||-3.73 V (ARC preamp -)
|-
|PANA_UNREG||45||18352 mV||+18.35 V (photodiode bias +)
|-
|NANA_UNREG||46||-19251 mV||-19.25 V (photodiode bias -)
|}

Switched rails that are inactive while the panel is idle (PARCVA_U,
P5VA_SW, N5VA_SW, FGATE_NVC_L, FGATE_PVC_L, etc.) read at or near zero.

====Known limitations====

*'''Temperatures''' (Temp_Surface, sensorId 336; Temp_Panel, sensorId 352): the raw 0x7900 read rails at 0x3FF (1023, the ADC maximum), indicating an open thermistor path while the panel is idle. This is a hardware/state condition, not a command problem, and the temperature is not readable from the host in this state.
*'''Unimplemented sensors''': sensorIds 70 (Accelerator), 78 (Gravity), and 256 to 259 (Battery status, name, life, capacity), and 272 (Grid status) are not implemented on this DEM. The detector returns the leftover conversion register contents (a duplicate of a previously read sensor) rather than a real value, so these rows must be discarded.
*'''Accelerometer''': functional through a separate addressing scheme using raw cmd 0x7900 with selectors 0x42 (X), 0x43 (Y), 0x44 (Z), returning 12 bit per axis counts.

===Host Registration (Pairing)===

URP stands for Unified Registration Protocol. The detector maintains a host
list in its internal NOR flash. Image data is delivered only to a registered
primary host, so registration is a prerequisite for image transfer.

====Host identity (MAC and HostId)====

Each host is identified by a 16 character HostId derived deterministically from
the host's eth0 MAC address. The derivation (from the vendor generateHostId
script) is:

#Take the eth0 MAC, remove the colon separators, convert to upper case (12 hex characters).
#Prepend the last 4 characters to the full 12 characters.
#The result is 16 hex characters.

Example: MAC 00:6f:00:01:0a:3a becomes 006F00010A3A, then the last four (0A3A)
are prepended, giving HostId 0A3A006F00010A3A.

====HostList structure====

The host list is stored in flash at offset 0x940000 and can be read back over
the upload interface as data category 0x71. Layout:

Offset Size Field
0x00 16 DetectorDeviceId (ASCII)
0x10 16 ConnectionSecretKey (ASCII; "XXXXXXXXXXXXXXXX" when unset)
0x20 16 DetectorName (ASCII)
0x30 16 DetectorCode (ASCII)
0x40 2 CurrentNumberOfHosts (uint16 LE)
0x42 2 IndexToPrimaryHost (uint16 LE; 0xFFFF = none)
0x44 144*N Host entries, 144 bytes each:
+0x00 16 HostId (ASCII)
+0x10 .. host name / department string
+0x50 .. location string
... 4 CRC (big endian; see below)

====HostList from the unit under test====

Detector: MAC 40:F4:A0:00:78:4D, serial UA45829-7, model 5340000-7,
firmware 1.6.0.4.2.0.1.3. DetectorName starShape_green. ConnectionSecretKey
unset. CurrentNumberOfHosts = 3, IndexToPrimaryHost = 0xFFFF (no primary host).

{| class="wikitable"
!Index!!HostId!!Derived MAC!!Name
|-
|0||2C6400045FB42C64||00:04:5F:B4:2C:64||Haus 207 / ITS
|-
|1||B044E8393512B044||E8:39:35:12:B0:44||Not Initialized
|-
|2||5CF800045FB15CF8||00:04:5F:B1:5C:F8||Not_Initialized
|}

The unit is therefore not factory fresh; it carries registrations from a prior
deployment, but no primary host is currently designated.

====Checksum (CRC)====

The HostList (and other flash data blobs) are protected by a 4 byte trailing
CRC. Parameters:

*Polynomial: 0x04C11DB7
*Initial value: 0
*MSB first, augmented message style (the data bit is shifted into the LSB; no input or output reflection; no final XOR)
*Stored big endian

To generate: compute the CRC over the data followed by four zero bytes, then
append the result big endian. Verification: the CRC over (data plus stored CRC)
equals zero.

def crc(data, poly=0x04C11DB7, init=0):
c = init
for byte in data:
for bit in (0x80,0x40,0x20,0x10,0x08,0x04,0x02,0x01):
msb = c & 0x80000000
c = (c << 1) & 0xFFFFFFFF
if byte & bit: c |= 1
if msb: c ^= poly
return c
# trailer = crc(data + b"\x00\x00\x00\x00"), stored big endian

====Read and write transport====

Data blobs (including the HostList) are moved with a configure / buffer /
finalize sequence.

Read (upload, detector to host), non destructive:

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x13||[uploadId:4 LE]||[status:1][totalSize:4 LE]
|-
|Buffer||0x14||[bufId:4 LE][numBytes:4 LE]||[bufId:4 LE][numBytes:4 LE][data]
|}

Write (download, host to detector), persistent (writes flash):

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x0E||[downloadId:4 LE][totalSize:4 LE]||[status:1]
|-
|Buffer||0x0F||[bufId:4 LE][numBytes:4 LE][data]||[status:1][reserved:4]
|-
|Commit||0x10||(empty)||[status:1]
|}

bufId is a zero based chunk index. The HostList uses id 0x71 for both read and
write. The commit command (0x10) reuses the firmware flash path, so a malformed
download can corrupt flash; the operation is irreversible on this hardware.

====Registering a new host====

To register a host and make it the image destination, read the current HostList
(0x71), append a 144 byte entry carrying the new HostId, increment
CurrentNumberOfHosts, set IndexToPrimaryHost to the new entry's index,
recompute the trailing CRC, and write the blob back via the download sequence
(0x0E / 0x0F / 0x10).

===Reading the Drop and Shock Event Log===

The detector contains an accelerometer based shock watchdog that records drop
and impact events into non volatile memory. This log is useful when evaluating a
used unit, since it reveals how many serious shocks the panel has survived and
when. The same data is held both in the main flash (read over the network) and
in the small onboard EEPROM on the detector PCB.

====How to read it====

The shock log is exposed as data category 0x72 on the upload (read) interface.
It is retrieved with the standard non destructive configure and buffer sequence
(cmd 0x13 to configure, cmd 0x14 to pull the chunks). On the unit under test the
blob is 3001 bytes of plain text in the GE .dyn configuration format, so no
decoding is required beyond reading it as ASCII.

The same records are mirrored in binary form in the onboard 24LC256 EEPROM
(32 KB I2C part) for anyone reading the hardware directly.

====Example output====

The following is the actual log read from detector serial UA45829-7. The file
has two parts: a list of individual events (DetectorShockEvents) and a summary
block (DetectorShockData). Each event carries a record key, a severity, a
timestamp, and the peak acceleration on each axis. Two representative records:

<DetectorShockEvents>
[149266438700135]
Severity.Type = String
Severity.Val = Serious
TimeStamp.Type = String
TimeStamp.Val = 2017-4-20,6:59:47
ValidTime.Type = Number
ValidTime.Val = 0
VibrationX.Type = Number
VibrationX.Val = 0
VibrationY.Type = Number
VibrationY.Val = 0
VibrationZ.Type = Number
VibrationZ.Val = 135

[1592113924-1720-113]
Severity.Val = Serious
TimeStamp.Val = 2020-6-14,7:52:4
VibrationX.Val = -172
VibrationY.Val = 0
VibrationZ.Val = -113

The summary block at the end lists the totals and an index of all event keys:

[DetectorShockData]
LastKnownGoodTime.Val = 2024-4-4,6:53:59
NumberOfL3Events.Val = 0
NumberOfL5Events.Val = 7
ShockDataTimeList.Val = { 1643260890-1320-119, 163626503500-123,
160818190500-101, 160524243000170, 1592113924-1720-113,
157804584600183, 149266438700135 }

====Interpreting the records====

The record key encodes the event time and the peak axis values (an epoch style
timestamp followed by the concatenated vibration readings), so it is unique per
event. The VibrationX, VibrationY, and VibrationZ values are signed peak
acceleration counts on each axis. Severity is reported as Serious for all
logged events on this unit, which corresponds to the L5 (highest) severity class
counted in the summary.

The seven recorded events for this detector:

{| class="wikitable"
!Date and time!!VibrationX!!VibrationY!!VibrationZ
|-
|2017-04-20 06:59:47||0||0||135
|-
|2020-01-03 11:04:06||0||0||183
|-
|2020-06-14 07:52:04||-172||0||-113
|-
|2020-11-13 05:40:30||0||0||170
|-
|2020-12-17 06:11:45||0||0||-101
|-
|2021-11-07 07:03:55||0||0||-123
|-
|2022-01-27 06:21:30||-132||0||-119
|}

====Reading the summary fields====

{| class="wikitable"
!Field!!Meaning
|-
|LastKnownGoodTime||Timestamp of the last successful self check (here 2024-04-04), the most recent point at which the detector was known to be operating normally
|-
|NumberOfL3Events||Count of lower severity (L3) shock events; zero on this unit
|-
|NumberOfL5Events||Count of high severity (L5) shock events; seven on this unit, matching the seven records above
|-
|ShockDataTimeList||Index of all stored event keys, newest first
|}

On this example the panel logged seven serious impacts over roughly five years
of field use and last reported a good self check in April 2024.

==FlashPad Detector: Internal Flash Dump and Data Files==

This section documents how the full contents of the detector's internal flash
were extracted over the network and what each recovered file contains. The
detector under test is a GE Optima XR200/220 AMX FlashPad (URP detector,
serial UA45829-7, MAC 40:F4:A0:00:78:4D, firmware 1.6.0.4.2.0.1.3).

===Background===

The detector's main storage is a Spansion/Cypress S29GL512P (marked
GL512P10FFCR2), a 512 Mbit (64 MB) parallel NOR flash. A direct chip read
requires bus access or desoldering and a programmer. However, the detector
firmware exposes its stored data blobs, including a full image of the flash,
through the read (upload) side of the data transport protocol. This makes a
complete, byte exact dump possible over UDP with no physical access.

===Extraction method===

The upload interface is the read counterpart of the firmware download path and
is non destructive (it only reports and returns data; nothing is written).
Each data category is identified by an 8 bit upload ID:

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x13||[uploadId:4 LE]||[status:1][totalSize:4 LE]
|-
|Buffer||0x14||[bufId:4 LE][numBytes:4 LE]||[bufId:4 LE][numBytes:4 LE][data]
|}

A configure request returns status 0 and a total size for a valid ID, or a non
zero status for an unsupported ID. The dump tool sweeps all IDs from 0x00 to
0xFF, and for every readable ID it pulls the full blob in fixed size chunks
(bufId is a zero based chunk index) and writes it to a file. The 64 MB flash
image transfers as 65536 chunks of 1024 bytes.

===Recovered files===

A sweep of the unit returned 18 readable blobs:

{| class="wikitable"
!Upload ID!!Size (bytes)!!Contents
|-
|0xFD||67108864||Full 64 MB NOR flash image
|-
|0xFF||16777216||16 MB region (firmware / FPGA mirror or image buffer)
|-
|0xFE||524288||Bootloader (512 KB; SPI loader, Nios reset code)
|-
|0x10||6815783||Calibration map, dose level 1
|-
|0x11||6815783||Calibration map, dose level 2
|-
|0x12||6815783||Calibration map, dose level 3
|-
|0x06||49254||Table referencing conditioner/generator serial UA2010-8U005
|-
|0x50||19938||Per mode calibration coefficients
|-
|0x51||19582||Per mode calibration coefficients
|-
|0x07||12187||Sensor conversion table (text; see Sensor Readout)
|-
|0x72||3001||Shock / drop event log (text)
|-
|0x0E||624||Panel geometry / configuration (binary)
|-
|0x71||504||Host list / registration record (see Host Registration)
|-
|0x0F||233||Host to detector compatibility table (text)
|-
|0x08||62||Serial and model strings
|-
|0x0A||48||Manufacturing codes
|-
|0x52||30||Serial string
|-
|0x0B||24||Small marker / identifier
|}

===Flash image layout (upload ID 0xFD)===

A block scan of the 64 MB image shows the following regions:

{| class="wikitable"
!Range!!Contents
|-
|0x000000 to 0x800000||Firmware and FPGA configuration
|-
|0x800000 to 0x940000||Sparse configuration area
|-
|0x940000||Host list / registration record (matches upload ID 0x71)
|-
|0x1000000 to 0x2800000||Calibration and image data (16 to 40 MB)
|-
|0x2800000 to 0x4000000||Erased / unused (40 to 64 MB)
|}

The host list strings (the DetectorName starShape_green, the registered host
name Haus 207 / ITS, and the unset ConnectionSecretKey placeholder) appear at
0x940000, confirming that the 504 byte 0x71 read maps to this flash region.

===Notes on individual files===

*'''0x07 (sensor table)''': plain text, header DetectorSerialNumber = UA45829-7, revision 1.2. Lists every sensor by name, command (0x7902), and sensorId. Also carries panel geometry in its [Common] section: 16 bit depth, 2048 by 2048 pixels, active area from (12, 12) to (2035, 2035), pixel pitch 0.2 mm, corner radius 1416.8, panel saturation 150.
*'''0x10, 0x11, 0x12 (calibration maps)''': three distinct blobs of identical size, corresponding to the low, medium, and high dose calibration sets. Each begins with the firmware version and serial (header bytes 01 06 00 04 02 00 01 03 followed by the serial). Required to apply gain and offset correction to raw images.
*'''0xFE (bootloader)''': contains the strings spi_load.S and ../../boot and Nios II reset vector code.
*'''0x72 (shock log)''': text records of drop / vibration events with timestamps and per axis values; the same data is mirrored in the detector's small onboard EEPROM.
*'''0x06''': references a different serial, UA2010-8U005, likely the conditioner or generator board rather than the panel.

===Significance===

The complete flash image and all calibration data are recoverable over the
network without opening the detector, providing a full byte exact backup of the
unit before any write operation. The calibration maps are needed for image
correction, and the firmware image (the live, deployed build) is more complete
than the partial firmware files shipped on the recovery media.

==Teardown / Internal Pictures / Hardware analysis==

<gallery mode="packed" heights="200">
File:GE Flashpad under the hood.jpg|the Carbon fiber sleeve is held by 9 screws and can taken off without force.
File:Ge flashpad powersupply pcb in handle.jpg|Power supply PCB
File:Ge flashpad uwb board pcb.jpg|UWB PCB for Wireless USB using a RTU2705
File:Ge flashpad uwb pcb backside.jpg|Backside of UWB PCB
File:Ge flashpad power supply pcb backside.jpg|Backside of Power supply PCB
File:Ge flashpad main pcb closeup1.jpg|Main area of the PCB with its Altera Cyclone 3 FPGA
File:Ge flashpad main pcb closeup2.jpg|AD7892 is a 600ksps 12bit ADC, SN74LVC8T245 a 8bit bus transceiver and DG9408EDN a 8ch MUX
File:Ge flashpad bottom connector ethernet isolation pcb.jpg|Isolation PCB for bottom connector
File:Ge flashpad main pcb powersupply section.jpg|Powersupply section for FPGA and ROIC
File:Ge flashpad main pcb closeup 3.jpg|AD9764AR 14-Bit, 125 MSPS DAC and DS1682 integrated elapsed-time recorder
File:Ge flashpad main pcb closeup 4.jpg|Accelerometer is a 834-0500 500G 3 Axis unit, and TJ500AE SPDT gigabit LAN switch
File:Ge flashpad bottom connector.jpg|bottom connector for docking stand
File:Ge flashpad main pcb closeup 5.jpg|Ethernet transformers and ADM34 RS-485/RS-422 Transceiver
File:Ge flashpad main pcb closeup 6.jpg|Altera EPM570f100c5n CPLD
File:Ge flashpad main pcb closeup 7.jpg|Spansion GL512P10FF1R1 512 Mbit NOR flash IC holding everything
File:Ge flashpad main pcb closeup 8.jpg|24LC256I 32k EEPROM for storing the accelerometer events
</gallery>

==Main test py script: Usage and Parameters==

current iteration found here: https://pastebin.com/vEfAresk

flashpad_acquire.py is a single file Python 3 tool that speaks the FlashPad
URP/PDAP protocol over UDP. It implements discovery, the control handshake,
script download and execution, sensor readout, full data backup, and the host
registration (pairing) write. It requires only the Python standard library.

===Default network configuration===

These defaults match the values in ConnectionPoint.cfg and can be overridden on
the command line.

{| class="wikitable"
!Setting!!Default!!Meaning
|-
|Detector IP||192.168.1.30||the panel; listens for all commands on UDP 8100
|-
|Host IP||192.168.1.1||this machine, announced in SYSTEM_STARTUP
|-
|Detector port||8100||where commands are sent
|-
|Host command port||5550||where the detector returns protocol replies
|-
|Host image port||6660||where pixel data would stream
|-
|Discovery port||4500||where the detector sends its beacons
|}

===Connection and general options===

{| class="wikitable"
!Option!!Default!!Effect
|-
| --detector-ip IP||192.168.1.30||detector address
|-
| --host-ip IP||192.168.1.1||host address sent in SYSTEM_STARTUP
|-
| --output-dir DIR||.||where raw images are written
|-
| --timeout SECONDS||5.0||UDP receive timeout
|-
| --exec-timeout SECONDS||60||how long to wait for EXECUTION_COMPLETE
|-
| --skip-discovery||off||send SYSTEM_STARTUP once and proceed, skipping the discovery loop
|-
| --quiet||off||suppress the verbose per packet log
|}

===Read and diagnostic modes (non destructive)===

These only read from the detector. None of them write anything.

{| class="wikitable"
!Option!!What it does!!What to expect
|-
| --sensors||Reads the full 32 entry sensor table using cmd 0x7902 (converted) and 0x7900 (raw), side by side.||A decoded table of supply rails in volts. Temperatures show as railed. Unimplemented sensors (accelerometer DEM id, battery, grid) are flagged as stale.
|-
| --no-roe-init||With --sensors, skips the Script7 ROE init before reading.||Slightly faster sensor read, marginally less reliable.
|-
| --probe-data||Reads DetectorInfo, the HostList (registration state), and cal results via the upload protocol (cmd 0x13/0x14).||A hexdump and text decode of each. Shows whether any host is registered and which HostId the detector expects.
|-
| --backup [DIR]||Sweeps all upload IDs 0x00 to 0xFF and saves every readable blob to DIR/detector_backup_timestamp/.||A manifest plus one .bin per readable ID, including the full 64 MB flash image and the calibration maps. Do this before any write. Large blobs take a few minutes each.
|-
| --backup-range LO-HI||Limits the --backup sweep, for example 0x40-0xA0.||Faster, partial backup.
|-
| --dump-scripts||Prints the wire bytes of all built scripts as hex and exits.||No network activity; useful for inspecting the script encoding.
|-
| --listen||Passively listens on the host command port for 30 seconds.||Prints any packets the detector sends; useful for watching beacons.
|}

===Acquisition modes===

The default invocation (no mode flag) runs a standard acquisition, which
requires an actual X-ray exposure to complete.

{| class="wikitable"
!Option!!What it does!!What to expect
|-
|(no flag)||Standard acquisition (Script 0).||Needs an X-ray exposure to reach EXECUTION_COMPLETE.
|-
| --dark||Runs the dark/offset acquisition (Script 1) before the standard one.||Two acquisitions; the dark one needs no X-ray.
|-
| --dark-only||Runs only the dark acquisition (Script 1).||Completes in a few seconds with no X-ray. The detector acquires and holds an 8 buffer image. Best way to test the full flow.
|-
| --no-standby||Omits the Script 8 standby loop.||Use if the standby loop blocks acquisition.
|-
| --two-exec||Executes Script 7 alone, waits, then Script 1. Only with --dark-only.||Tests the two stage execution hypothesis.
|-
| --parallel||Answers the detector status query (0x30000) with the cmd 0x99 ParallelImageTransfer reply instead of cmd 9.||Experiment to see if the parallel reply triggers a pixel push. (Result so far: it does not.)
|-
| --sweep-acq||Sweeps the dark acquisition across type_mode and transfer_mode values, watching for a 0x0F pixel push.||Non destructive experiment; reports which combination, if any, makes the detector stream.
|-
| --preview||Single dark acquisition on the preview path (transfer_mode 2, 4 buffer image). Watches port 6660 for a push.||One clean connection; run a packet capture on the detector address in parallel.
|}

Note: at present the detector acquires and holds an image but does not push the
0x0F pixel frames. The acquisition modes complete the handshake and acquisition,
but image streaming is still being investigated.

===Registration and write operations===

These can write to the detector's flash. Every write is a dry run by default and
only takes effect when --commit is added. Always run --backup first.

{| class="wikitable"
!Option!!What it does
|-
| --register-self||Adds this host to the detector HostList and sets it as the primary host, so the detector should stream images to it. Appends an entry, sets IndexToPrimaryHost, recomputes the CRC, and writes via id 0x71. Dry run unless --commit.
|-
| --host-mac MAC||The MAC of the interface talking to the detector, used to derive this host's HostId for --register-self. Default 00:6f:00:01:0a:3a.
|-
| --smoke-test-write||Reads the HostList and writes back the identical bytes to validate the write and commit path without changing anything. Dry run unless --commit.
|-
| --restore-hostlist FILE||Writes a saved HostList blob (for example detector_backup_*/upload_0x71_504.bin) back to the detector. This is the undo button. Dry run unless --commit.
|-
| --commit||Arms the actual flash write for the operations above. Without it they only print what they would do. This writes the detector's flash and is irreversible at the chip level, although the HostList region can be restored from a backup.
|}

===Typical workflow===

#Read the current state: <code>python flashpad_acquire.py --probe-data</code>
#Make a full backup: <code>python flashpad_acquire.py --backup</code>
#Check sensors and power rails: <code>python flashpad_acquire.py --sensors</code>
#Dry run the registration: <code>python flashpad_acquire.py --register-self --host-mac YOUR:MAC</code>
#When satisfied, commit it: add <code>--commit</code>
#If needed, undo: <code>python flashpad_acquire.py --restore-hostlist detector_backup_*/upload_0x71_504.bin --commit</code>

==Known Dead Ends==

Things that were tried and did not work or led nowhere:

;0xBEEF (48879) as reply port
:This was a bug in early test scripts. The port has no meaning in the protocol. Use 5550.

;CmdFlag=1 as data packet flag
:Early scripts had the URP fields swapped, setting CmdFlag=1 on data packets. The detector ignores all PDAP content in these packets. Power cycle the detector if this happened, it may retain stale port state.

;Image data on alternate ports
:Tried listening on 48879, 6660, 5550, 8100, 1050, 6661, 9999, 4444, 7000, 7001, 9001. Nothing arrived on any of them.

;PORT_SETUP byte order (big-endian)
:Current implementation sends port fields as big-endian. If the detector reads them as little-endian it computes port 44565 and 1050 instead of 5550 and 6660, which would explain why no image data arrives. Not yet confirmed.

;Image data streaming automatically after EXECUTE_SCRIPT
:Frames may not push during execution at all. The detector may require an explicit IMAGE_RETRIVAL_REQUEST (cmd_type=0x41) and IMAGE_RETRIVAL (cmd_type=0x98) after the 0x30000 notification before it streams anything. Not yet tested.

GE Medical Flashpad Digital Xray Detector

2026-06-11T12:21:28Z

Gamerpaddy: /* Purpose and Motivation */

==Overview==
{{Note|UNFINISHED Project, it was not yet possible to retrieve a exposure or dark frame in my testing, further investigation needed. any help is appreciated on recessim discord.}}

The '''GE Flashpad''' is a Digital Radiography image sensor from approximately 2010, originally used in the '''GE Optima 220AMX''' mobile X-ray unit. It was designed to replace analog film in radiology, dramatically reducing image acquisition time from hours to seconds.
[[File:GE Flashpad.jpg|thumb|Flashpad with Anti-Scatter grid (left), manual and recovery dvd for 220amx and tether cord (right)]]
Due to its high original cost and specialized application, used units occasionally appear on professional B2B marketplaces in the $15,000–$50,000 range. On eBay, prices typically fall between $1,500 and $5,000, though units at this price point are often in poor condition and may fail the built-in self-test or not function at all.

{{Note|All findings on this page are based on a single unit and the time spent working on it. Information is subject to speculation and may not be fully accurate.}}

{{Note|AI assistance was used in writing this page for improved formatting and readability, as well as in the process of finding information, testing, and analyzing firmware dumps and backups.}}

==Purpose and Motivation==

This project documents the reverse engineering of the GE FlashPad wireless
digital radiography detector used with the Optima XR200/220 AMX mobile X-ray
system, with the goal of freeing these detectors for independent use.
[[File:Xray capture pcb.png|thumb|Xray capture of a PCB for Reverse Engineering using a different detector]]
Large numbers of these detectors reach the used market, but each one is bound to its original Optima 220 AMX
console. Once separated from that console, or once the console is
decommissioned, the detector is effectively useless even though the hardware is
fully functional. There is a Windows software but it is not obtainable. The aim of this work is to remove that artificial barrier so
that a standalone FlashPad can be paired, configured, and read out by any host,
without the half million dollar console it was sold with.

The intended beneficiaries are:

*Hobbyists, researchers, and engineers who want a high quality flat panel detector for their own imaging projects.
*Veterinary practices, which can put surplus human grade detectors to good use at a fraction of the cost of new equipment.
*Clinics and hospitals in countries and regions where a complete commercial system is unaffordable, allowing serviceable detectors to keep providing diagnostic imaging instead of being scrapped.
*Study an research for example studying the fluid movement in plants. https://www.youtube.com/watch?v=j-FHbHoiwNk (Xray timelapse by Ben Krasnow / Applied Science using a GE Flashpad)

[[File:Xray current clamp multimeter.png|thumb|xray of a current clamp multimeter using a different detector]]
This is done for human good. Every detector returned to service is one less
piece of working medical hardware sent to landfill, and potentially one more
place that can offer X-ray imaging where it otherwise could not.

All files, findings, protocol documentation, and tools produced by this project
are public and open source, so that anyone can study, reproduce, and build on
the work.

==Technical Specifications==
[[File:Ge flashpad tether cable pinout diagram.png|thumb|Pinout Diagram of the Tether cable]]
[[File:Ge flashpad tether wiring for ethernet cable.jpg|thumb|Professional Tether wiring to attach a Ethernet Cable and 12V socket to it.]]
The Flashpad uses a '''~40 × 40 cm CsI scintillator''' bonded to a [[Thin-film transistor|TFT]] photodetector array mounted on glass. The assembly is highly sensitive to shock and impact damage. See section [[#Reading the Drop and Shock Event Log|drop and shock event log]]

{| class="wikitable"
|-
!Parameter!!Value
|-
|Resolution||2048 × 2048 px
|-
|Bit depth||16-bit per pixel
|-
|Spatial resolution||Up to 5 lp/mm (theoretical)
|-
|Scintillator material||Caesium iodide (CsI)
|-
|Detector type||TFT photodetector array (glass substrate)
|-
|Panel size||~40 × 40 cm
|}

The theoretical 5 lp/mm spatial resolution is primarily limited in practice by the focal spot size of the X-ray source. Use of an anti-scatter grid can improve effective resolution.

===Status of Reverse Engineering===

{| class="wikitable"
|-
!What!!Status
|-
|Connect, beacon, ACK||Works
|-
|PORT_SETUP||Works
|-
|SIGNATURE_REQUEST / serial number readout||Works
|-
|Script download (Scripts 7, 8, 1)||Works
|-
|EXECUTE_SCRIPT||Works
|-
|EXECUTION_COMPLETE (dark acquisition)||Works but without image readout its speculation.
|-
|EXECUTION_COMPLETE (standard acquisition)||Needs real X-ray trigger to test
|-
|Image data on port 6660||Does not work yet, under investigation. Will not send Imagedata...
|}

==Hardware Features==

===Shock logging===
The unit contains an internal accelerometer that logs significant shock events — but only when a battery is inserted. As there is no backup battery, shock events occurring while unpowered are not recorded.

===Wireless connectivity===
Some units include a UWB transmitter for Wireless USB; others may be equipped with a Wi-Fi module instead. The detector can also be operated over the tethered connection alone.

===Ethernet interface===
There is a 100MBit Ethernet interface trough the Tether Cable which can be tapped and used for Communication.
Exposed metal contacts on the bottom connector are isolated via relays by default. Enabling Gigabit Ethernet connectivity requires shorting or driving two specific pins. This has not been investigated further at this time.

==Communication Protocol==

This section documents the URP/PDAP protocol used by the GE Flashpad (codename '''Apollo''') to communicate with a host over Ethernet. All findings are based on live capture tests, configuration files, and reverse-engineering of the GE SuperBee software stack.

{{Note|All findings are based on a single unit and may not be fully accurate.}}

===Network Setup===

All findings were over Ethernet only, no UWB or WIFI has been used.
Default detector IP is <code>192.168.1.30</code>. Set your host to a static IP in the same subnet, <code>192.168.1.1</code> works fine.

At first by sending random bytes over Python it answered to port 48879 (0xBEEF), which seems to be either the default port or set by Python.
After SYSTEM_SETUP it got set to 5550.

{| class="wikitable"
|-
!Role!!IP!!Port!!Direction
|-
|All commands: host -> detector||192.168.1.30||'''8100''' (UDP)||Host sends here
|-
|Discovery beacons: detector -> host||-||'''4500''' (UDP)||Detector sends here initially
|-
|Protocol replies: detector -> host||-||'''5550''' (UDP)||Detector sends here after setup
|-
|Image pixel data: detector -> host||-||'''6660''' (UDP)||Detector streams frames here
|}

In practice you can listen on port '''5550''' for everything (beacons and replies) by advertising that port in both <code>SYSTEM_STARTUP</code> and <code>PORT_SETUP</code>. The detector sends to whichever port was most recently configured.

===Protocol Layers===

Two layers, carried over UDP:

;URP (Unified Registration Protocol)
:8-byte wrapper on every packet. Handles sequencing and acknowledgement.

;PDAP (Proprietary Detector Access Protocol)
:The actual command layer, present inside URP packets when <code>CmdFlag = 0</code>.

Every UDP packet starts with a URP header:

<pre>
[SeqId : 4 bytes LE] [CmdFlag : 4 bytes LE]
</pre>

*<code>CmdFlag = 0</code> -- data packet, PDAP command follows.
*<code>CmdFlag = 1</code> -- bare ACK, no PDAP body. SeqId echoes the packet being acknowledged.

Both sides must ACK every data packet immediately. The detector silently drops packets with a SeqId it has already seen, so always increment SeqId for each new command.

When CmdFlag is 0, the PDAP header follows immediately:

<pre>
[cmd_type : 4 bytes LE] [payload_len : 4 bytes LE] [payload ...]
</pre>

===Connecting to the Detector===

The connection sequence is:

#Broadcast <code>SYSTEM_STARTUP</code> to tell the detector where to reply.
#The detector sends a <code>BEACON</code> back -- ACK it and sync your sequence counter.
#Send <code>PORT_SETUP</code> to configure the reply and image ports.
#Send <code>SIGNATURE_REQUEST</code> to read the detector identity (serial number, model, firmware, MAC).

====Step 1: SYSTEM_STARTUP====

Broadcast UDP to <code>192.168.1.255:8100</code>. Always uses <code>SeqId = 0</code>.

<pre>
URP : [00 00 00 00] SeqId = 0
[00 00 00 00] CmdFlag = 0
PDAP: [01 00 00 00] cmd_type = 1
[06 00 00 00] payload_len = 6
[15 AE] host reply port = 5550 (big-endian)
[C0 A8 01 01] host IP = 192.168.1.1 (network byte order)
</pre>

<syntaxhighlight lang="python">
import socket, struct

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
sock.bind(("0.0.0.0", 5550))

HOST_IP = "192.168.1.1"
DET_IP = "192.168.1.30"
HOST_PORT = 5550
IMG_PORT = 6660

def make_urp_packet(seq_id, pdap_bytes):
return struct.pack("<II", seq_id, 0) + pdap_bytes

pdap = struct.pack("<II", 1, 6) + struct.pack(">H", HOST_PORT) + socket.inet_aton(HOST_IP)
sock.sendto(make_urp_packet(0, pdap), ("192.168.1.255", 8100))
</syntaxhighlight>

====Step 2: Receiving the BEACON and ACKing====

The detector broadcasts a <code>BEACON</code> (cmd_type=1) roughly every 2 seconds. After sending SYSTEM_STARTUP you should get one quickly. Parse the detector SeqId from the URP header and ACK it:

<syntaxhighlight lang="python">
data, addr = sock.recvfrom(4096)
det_seq = struct.unpack_from("<I", data, 0)[0]

# send bare ACK
ack = struct.pack("<II", det_seq, 1)
sock.sendto(ack, (DET_IP, 8100))

# all subsequent commands start from here
host_seq = det_seq + 1
</syntaxhighlight>

====Step 3: PORT_SETUP====

Tells the detector which host ports to use for replies and image data.

<pre>
PDAP: [02 00 00 00] cmd_type = 2
[04 00 00 00] payload_len = 4
[15 AE] host cmd port = 5550 (big-endian)
[1A 04] host image port = 6660 (big-endian)
</pre>

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 2, 4) + struct.pack(">HH", HOST_PORT, IMG_PORT)
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1
# expect bare ACK from detector
</syntaxhighlight>

====Step 4: Reading the Serial Number (SIGNATURE_REQUEST)====

Empty command, the detector replies with a 54-byte payload containing its identity.

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 3, 0) # cmd_type=3, payload_len=0
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1

# reply is 70 bytes total: 8 URP + 8 PDAP header + 54 payload
data, _ = sock.recvfrom(4096)
payload = data[16:] # skip URP (8) + PDAP header (8)

mac = payload[0:6]
serial = payload[22:34].rstrip(b'\x00 ').decode()
model = payload[34:46].rstrip(b'\x00 ').decode()
fw_bytes = payload[46:54]
firmware = ".".join(str(b) for b in fw_bytes)

print(f"MAC: {':'.join(f'{b:02X}' for b in mac)}")
print(f"Serial: {serial}")
print(f"Model: {model}")
print(f"Firmware: {firmware}")
</syntaxhighlight>

Expected output:
<pre>
MAC: 40:F4:A0:00:78:4D
Serial: UA45829-7
Model: 5340000-7
Firmware: 1.6.0.4.2.0.1.3
</pre>

===Running an Acquisition===

After the connection sequence above, download scripts to the detector and then execute them.

====ROE Initialisation (Script 7)====

Always run this first. It initialises the readout electronics and takes about 4-5 seconds. The detector sends host event ID 17 when done.

====Dark / Offset Acquisition (Script 1)====

No X-ray source required. Runs a dark-field exposure for offset calibration. Use this to verify the acquisition pipeline without a generator.

====Standard Acquisition (Script 0)====

Requires an actual X-ray exposure. <code>EXECUTION_COMPLETE</code> will '''not''' arrive without a real X-ray trigger.

====Sequence Overview====

<pre>
HOST DETECTOR
| |
|-- SYSTEM_STARTUP (broadcast) ----------->|
|<- bare ACK -------------------------------|
|<- BEACON (cmd_type=1) --------------------|
|-- bare ACK ------------------------------>|
| |
|-- PORT_SETUP (cmd_type=2) -------------->|
|<- bare ACK -------------------------------|
| |
|-- SIGNATURE_REQUEST (cmd_type=3) ------->|
|<- SIGNATURE_REPLY (54 bytes) -------------|
|-- bare ACK ------------------------------>|
| |
|-- GENERIC_SCRIPT Script7 (ROE init) ---->|
|<- bare ACK or SCRIPT_DOWNLOAD_REPLY ------|
| |
|-- GENERIC_SCRIPT Script1 (dark acq) ---->|
|<- bare ACK -------------------------------|
| |
|-- EXECUTE_SCRIPT (cmd_type=6) ---------->|
|<- bare ACK -------------------------------|
|<- EXECUTE_SCRIPT_REPLY (~230ms) ----------|
|-- bare ACK ------------------------------>|
|<- DETECTOR_STATE_NOTIFY (~890ms) ---------| state_id=17
|-- bare ACK ------------------------------>|
| |
|<- EXECUTION_COMPLETE (0x10000) -----------|
|-- bare ACK ------------------------------>|
| |
|<- IMAGE_XFER_STATUS_QUERY (0x30000) ------|
|-- bare ACK ------------------------------>|
|-- IMAGE_XFER_STATUS_REPLY (cmd_type=9) ->| numMissed=0
|<- bare ACK -------------------------------|
</pre>

===Sequence Counter Rules===

*<code>SYSTEM_STARTUP</code> always uses <code>SeqId = 0</code>.
*After the first beacon, set host SeqId to beacon_SeqId + 1.
*Increment SeqId by 1 for every new data packet (CmdFlag=0).
*Bare ACKs echo the SeqId of the packet being acknowledged and do not consume a SeqId.
*The detector silently drops any packet with a SeqId it has already processed, so never reuse one.

==Sensor Readout and Host Registration==

This section documents the reverse engineered sensor telemetry interface and the
host registration (pairing) mechanism of the GE Optima XR200/220 AMX FlashPad
(URP detector, SuperBee, FW 1.6.0.4.2.0.1.3). All commands are PDAP over UDP to
the detector at port 8100; replies return to the host command port.

===Sensor Readout===

The detector exposes an analog sensor interface (the DEM, Detector Environment
Monitor) that is independent of the image transfer path and works regardless of
acquisition state.

====Commands====

{| class="wikitable"
!cmd_type!!Meaning!!Request payload!!Reply payload
|-
|0x7900||Raw sensor read||[sensorId:4 LE]||[value:4 LE] (12 bit ADC count)
|-
|0x7902||Converted sensor read||[sensorId:4 LE]||[value:4 LE] (engineering units, signed)
|-
|0x7904||Detailed / radio||[selector:4 LE]||[value:4 LE]
|}

Note: cmd 0x7902 IS supported on this firmware and returns calibrated
engineering units (millivolts for the supply rails, signed; 0.1 degree C for
temperatures). Earlier documentation that marked 0x7902 as unsupported is
incorrect. The host side conversion coefficients are not required; the detector
performs the conversion internally.

The full sensor map (name, sensorId) was recovered from the detector's own
[Sensor] configuration table, read back over the upload interface (see the
Registration section for the read protocol).

====Power rails (live readings)====

All supply rails read correctly via 0x7902 and are within normal range for a
flat panel detector. Representative readings:

{| class="wikitable"
!Sensor!!sensorId!!Converted!!Value
|-
|DCIN_RAW||10||12100 mV||+12.10 V (main DC input)
|-
|LCORE_UNREG||11||1724 mV||+1.72 V
|-
|LPANA_UNREG||12||5776 mV||+5.78 V
|-
|LNANA_UNREG||13||-5801 mV||-5.80 V
|-
|SCAN_VCC||14||5086 mV||+5.09 V (gate driver)
|-
|P5V_REF||16||5025 mV||+5.03 V (5 V reference)
|-
|V_ON||17||11085 mV||+11.09 V (TFT gate on)
|-
|V_OFF||18||-12378 mV||-12.38 V (TFT gate off)
|-
|V_COMMON||19||-9385 mV||-9.39 V
|-
|3V3||29||3177 mV||+3.18 V (3.3 V logic)
|-
|VCC_UNREG||37||3399 mV||+3.40 V
|-
|PARCPREG||38||3768 mV||+3.77 V (ARC preamp +)
|-
|NARCPREG||39||-3732 mV||-3.73 V (ARC preamp -)
|-
|PANA_UNREG||45||18352 mV||+18.35 V (photodiode bias +)
|-
|NANA_UNREG||46||-19251 mV||-19.25 V (photodiode bias -)
|}

Switched rails that are inactive while the panel is idle (PARCVA_U,
P5VA_SW, N5VA_SW, FGATE_NVC_L, FGATE_PVC_L, etc.) read at or near zero.

====Known limitations====

*'''Temperatures''' (Temp_Surface, sensorId 336; Temp_Panel, sensorId 352): the raw 0x7900 read rails at 0x3FF (1023, the ADC maximum), indicating an open thermistor path while the panel is idle. This is a hardware/state condition, not a command problem, and the temperature is not readable from the host in this state.
*'''Unimplemented sensors''': sensorIds 70 (Accelerator), 78 (Gravity), and 256 to 259 (Battery status, name, life, capacity), and 272 (Grid status) are not implemented on this DEM. The detector returns the leftover conversion register contents (a duplicate of a previously read sensor) rather than a real value, so these rows must be discarded.
*'''Accelerometer''': functional through a separate addressing scheme using raw cmd 0x7900 with selectors 0x42 (X), 0x43 (Y), 0x44 (Z), returning 12 bit per axis counts.

===Host Registration (Pairing)===

URP stands for Unified Registration Protocol. The detector maintains a host
list in its internal NOR flash. Image data is delivered only to a registered
primary host, so registration is a prerequisite for image transfer.

====Host identity (MAC and HostId)====

Each host is identified by a 16 character HostId derived deterministically from
the host's eth0 MAC address. The derivation (from the vendor generateHostId
script) is:

#Take the eth0 MAC, remove the colon separators, convert to upper case (12 hex characters).
#Prepend the last 4 characters to the full 12 characters.
#The result is 16 hex characters.

Example: MAC 00:6f:00:01:0a:3a becomes 006F00010A3A, then the last four (0A3A)
are prepended, giving HostId 0A3A006F00010A3A.

====HostList structure====

The host list is stored in flash at offset 0x940000 and can be read back over
the upload interface as data category 0x71. Layout:

Offset Size Field
0x00 16 DetectorDeviceId (ASCII)
0x10 16 ConnectionSecretKey (ASCII; "XXXXXXXXXXXXXXXX" when unset)
0x20 16 DetectorName (ASCII)
0x30 16 DetectorCode (ASCII)
0x40 2 CurrentNumberOfHosts (uint16 LE)
0x42 2 IndexToPrimaryHost (uint16 LE; 0xFFFF = none)
0x44 144*N Host entries, 144 bytes each:
+0x00 16 HostId (ASCII)
+0x10 .. host name / department string
+0x50 .. location string
... 4 CRC (big endian; see below)

====HostList from the unit under test====

Detector: MAC 40:F4:A0:00:78:4D, serial UA45829-7, model 5340000-7,
firmware 1.6.0.4.2.0.1.3. DetectorName starShape_green. ConnectionSecretKey
unset. CurrentNumberOfHosts = 3, IndexToPrimaryHost = 0xFFFF (no primary host).

{| class="wikitable"
!Index!!HostId!!Derived MAC!!Name
|-
|0||2C6400045FB42C64||00:04:5F:B4:2C:64||Haus 207 / ITS
|-
|1||B044E8393512B044||E8:39:35:12:B0:44||Not Initialized
|-
|2||5CF800045FB15CF8||00:04:5F:B1:5C:F8||Not_Initialized
|}

The unit is therefore not factory fresh; it carries registrations from a prior
deployment, but no primary host is currently designated.

====Checksum (CRC)====

The HostList (and other flash data blobs) are protected by a 4 byte trailing
CRC. Parameters:

*Polynomial: 0x04C11DB7
*Initial value: 0
*MSB first, augmented message style (the data bit is shifted into the LSB; no input or output reflection; no final XOR)
*Stored big endian

To generate: compute the CRC over the data followed by four zero bytes, then
append the result big endian. Verification: the CRC over (data plus stored CRC)
equals zero.

def crc(data, poly=0x04C11DB7, init=0):
c = init
for byte in data:
for bit in (0x80,0x40,0x20,0x10,0x08,0x04,0x02,0x01):
msb = c & 0x80000000
c = (c << 1) & 0xFFFFFFFF
if byte & bit: c |= 1
if msb: c ^= poly
return c
# trailer = crc(data + b"\x00\x00\x00\x00"), stored big endian

====Read and write transport====

Data blobs (including the HostList) are moved with a configure / buffer /
finalize sequence.

Read (upload, detector to host), non destructive:

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x13||[uploadId:4 LE]||[status:1][totalSize:4 LE]
|-
|Buffer||0x14||[bufId:4 LE][numBytes:4 LE]||[bufId:4 LE][numBytes:4 LE][data]
|}

Write (download, host to detector), persistent (writes flash):

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x0E||[downloadId:4 LE][totalSize:4 LE]||[status:1]
|-
|Buffer||0x0F||[bufId:4 LE][numBytes:4 LE][data]||[status:1][reserved:4]
|-
|Commit||0x10||(empty)||[status:1]
|}

bufId is a zero based chunk index. The HostList uses id 0x71 for both read and
write. The commit command (0x10) reuses the firmware flash path, so a malformed
download can corrupt flash; the operation is irreversible on this hardware.

====Registering a new host====

To register a host and make it the image destination, read the current HostList
(0x71), append a 144 byte entry carrying the new HostId, increment
CurrentNumberOfHosts, set IndexToPrimaryHost to the new entry's index,
recompute the trailing CRC, and write the blob back via the download sequence
(0x0E / 0x0F / 0x10).

===Reading the Drop and Shock Event Log===

The detector contains an accelerometer based shock watchdog that records drop
and impact events into non volatile memory. This log is useful when evaluating a
used unit, since it reveals how many serious shocks the panel has survived and
when. The same data is held both in the main flash (read over the network) and
in the small onboard EEPROM on the detector PCB.

====How to read it====

The shock log is exposed as data category 0x72 on the upload (read) interface.
It is retrieved with the standard non destructive configure and buffer sequence
(cmd 0x13 to configure, cmd 0x14 to pull the chunks). On the unit under test the
blob is 3001 bytes of plain text in the GE .dyn configuration format, so no
decoding is required beyond reading it as ASCII.

The same records are mirrored in binary form in the onboard 24LC256 EEPROM
(32 KB I2C part) for anyone reading the hardware directly.

====Example output====

The following is the actual log read from detector serial UA45829-7. The file
has two parts: a list of individual events (DetectorShockEvents) and a summary
block (DetectorShockData). Each event carries a record key, a severity, a
timestamp, and the peak acceleration on each axis. Two representative records:

<DetectorShockEvents>
[149266438700135]
Severity.Type = String
Severity.Val = Serious
TimeStamp.Type = String
TimeStamp.Val = 2017-4-20,6:59:47
ValidTime.Type = Number
ValidTime.Val = 0
VibrationX.Type = Number
VibrationX.Val = 0
VibrationY.Type = Number
VibrationY.Val = 0
VibrationZ.Type = Number
VibrationZ.Val = 135

[1592113924-1720-113]
Severity.Val = Serious
TimeStamp.Val = 2020-6-14,7:52:4
VibrationX.Val = -172
VibrationY.Val = 0
VibrationZ.Val = -113

The summary block at the end lists the totals and an index of all event keys:

[DetectorShockData]
LastKnownGoodTime.Val = 2024-4-4,6:53:59
NumberOfL3Events.Val = 0
NumberOfL5Events.Val = 7
ShockDataTimeList.Val = { 1643260890-1320-119, 163626503500-123,
160818190500-101, 160524243000170, 1592113924-1720-113,
157804584600183, 149266438700135 }

====Interpreting the records====

The record key encodes the event time and the peak axis values (an epoch style
timestamp followed by the concatenated vibration readings), so it is unique per
event. The VibrationX, VibrationY, and VibrationZ values are signed peak
acceleration counts on each axis. Severity is reported as Serious for all
logged events on this unit, which corresponds to the L5 (highest) severity class
counted in the summary.

The seven recorded events for this detector:

{| class="wikitable"
!Date and time!!VibrationX!!VibrationY!!VibrationZ
|-
|2017-04-20 06:59:47||0||0||135
|-
|2020-01-03 11:04:06||0||0||183
|-
|2020-06-14 07:52:04||-172||0||-113
|-
|2020-11-13 05:40:30||0||0||170
|-
|2020-12-17 06:11:45||0||0||-101
|-
|2021-11-07 07:03:55||0||0||-123
|-
|2022-01-27 06:21:30||-132||0||-119
|}

====Reading the summary fields====

{| class="wikitable"
!Field!!Meaning
|-
|LastKnownGoodTime||Timestamp of the last successful self check (here 2024-04-04), the most recent point at which the detector was known to be operating normally
|-
|NumberOfL3Events||Count of lower severity (L3) shock events; zero on this unit
|-
|NumberOfL5Events||Count of high severity (L5) shock events; seven on this unit, matching the seven records above
|-
|ShockDataTimeList||Index of all stored event keys, newest first
|}

On this example the panel logged seven serious impacts over roughly five years
of field use and last reported a good self check in April 2024.

==FlashPad Detector: Internal Flash Dump and Data Files==

This section documents how the full contents of the detector's internal flash
were extracted over the network and what each recovered file contains. The
detector under test is a GE Optima XR200/220 AMX FlashPad (URP detector,
serial UA45829-7, MAC 40:F4:A0:00:78:4D, firmware 1.6.0.4.2.0.1.3).

===Background===

The detector's main storage is a Spansion/Cypress S29GL512P (marked
GL512P10FFCR2), a 512 Mbit (64 MB) parallel NOR flash. A direct chip read
requires bus access or desoldering and a programmer. However, the detector
firmware exposes its stored data blobs, including a full image of the flash,
through the read (upload) side of the data transport protocol. This makes a
complete, byte exact dump possible over UDP with no physical access.

===Extraction method===

The upload interface is the read counterpart of the firmware download path and
is non destructive (it only reports and returns data; nothing is written).
Each data category is identified by an 8 bit upload ID:

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x13||[uploadId:4 LE]||[status:1][totalSize:4 LE]
|-
|Buffer||0x14||[bufId:4 LE][numBytes:4 LE]||[bufId:4 LE][numBytes:4 LE][data]
|}

A configure request returns status 0 and a total size for a valid ID, or a non
zero status for an unsupported ID. The dump tool sweeps all IDs from 0x00 to
0xFF, and for every readable ID it pulls the full blob in fixed size chunks
(bufId is a zero based chunk index) and writes it to a file. The 64 MB flash
image transfers as 65536 chunks of 1024 bytes.

===Recovered files===

A sweep of the unit returned 18 readable blobs:

{| class="wikitable"
!Upload ID!!Size (bytes)!!Contents
|-
|0xFD||67108864||Full 64 MB NOR flash image
|-
|0xFF||16777216||16 MB region (firmware / FPGA mirror or image buffer)
|-
|0xFE||524288||Bootloader (512 KB; SPI loader, Nios reset code)
|-
|0x10||6815783||Calibration map, dose level 1
|-
|0x11||6815783||Calibration map, dose level 2
|-
|0x12||6815783||Calibration map, dose level 3
|-
|0x06||49254||Table referencing conditioner/generator serial UA2010-8U005
|-
|0x50||19938||Per mode calibration coefficients
|-
|0x51||19582||Per mode calibration coefficients
|-
|0x07||12187||Sensor conversion table (text; see Sensor Readout)
|-
|0x72||3001||Shock / drop event log (text)
|-
|0x0E||624||Panel geometry / configuration (binary)
|-
|0x71||504||Host list / registration record (see Host Registration)
|-
|0x0F||233||Host to detector compatibility table (text)
|-
|0x08||62||Serial and model strings
|-
|0x0A||48||Manufacturing codes
|-
|0x52||30||Serial string
|-
|0x0B||24||Small marker / identifier
|}

===Flash image layout (upload ID 0xFD)===

A block scan of the 64 MB image shows the following regions:

{| class="wikitable"
!Range!!Contents
|-
|0x000000 to 0x800000||Firmware and FPGA configuration
|-
|0x800000 to 0x940000||Sparse configuration area
|-
|0x940000||Host list / registration record (matches upload ID 0x71)
|-
|0x1000000 to 0x2800000||Calibration and image data (16 to 40 MB)
|-
|0x2800000 to 0x4000000||Erased / unused (40 to 64 MB)
|}

The host list strings (the DetectorName starShape_green, the registered host
name Haus 207 / ITS, and the unset ConnectionSecretKey placeholder) appear at
0x940000, confirming that the 504 byte 0x71 read maps to this flash region.

===Notes on individual files===

*'''0x07 (sensor table)''': plain text, header DetectorSerialNumber = UA45829-7, revision 1.2. Lists every sensor by name, command (0x7902), and sensorId. Also carries panel geometry in its [Common] section: 16 bit depth, 2048 by 2048 pixels, active area from (12, 12) to (2035, 2035), pixel pitch 0.2 mm, corner radius 1416.8, panel saturation 150.
*'''0x10, 0x11, 0x12 (calibration maps)''': three distinct blobs of identical size, corresponding to the low, medium, and high dose calibration sets. Each begins with the firmware version and serial (header bytes 01 06 00 04 02 00 01 03 followed by the serial). Required to apply gain and offset correction to raw images.
*'''0xFE (bootloader)''': contains the strings spi_load.S and ../../boot and Nios II reset vector code.
*'''0x72 (shock log)''': text records of drop / vibration events with timestamps and per axis values; the same data is mirrored in the detector's small onboard EEPROM.
*'''0x06''': references a different serial, UA2010-8U005, likely the conditioner or generator board rather than the panel.

===Significance===

The complete flash image and all calibration data are recoverable over the
network without opening the detector, providing a full byte exact backup of the
unit before any write operation. The calibration maps are needed for image
correction, and the firmware image (the live, deployed build) is more complete
than the partial firmware files shipped on the recovery media.

==Teardown / Internal Pictures / Hardware analysis==

<gallery mode="packed" heights="200">
File:GE Flashpad under the hood.jpg|the Carbon fiber sleeve is held by 9 screws and can taken off without force.
File:Ge flashpad powersupply pcb in handle.jpg|Power supply PCB
File:Ge flashpad uwb board pcb.jpg|UWB PCB for Wireless USB using a RTU2705
File:Ge flashpad uwb pcb backside.jpg|Backside of UWB PCB
File:Ge flashpad power supply pcb backside.jpg|Backside of Power supply PCB
File:Ge flashpad main pcb closeup1.jpg|Main area of the PCB with its Altera Cyclone 3 FPGA
File:Ge flashpad main pcb closeup2.jpg|AD7892 is a 600ksps 12bit ADC, SN74LVC8T245 a 8bit bus transceiver and DG9408EDN a 8ch MUX
File:Ge flashpad bottom connector ethernet isolation pcb.jpg|Isolation PCB for bottom connector
File:Ge flashpad main pcb powersupply section.jpg|Powersupply section for FPGA and ROIC
File:Ge flashpad main pcb closeup 3.jpg|AD9764AR 14-Bit, 125 MSPS DAC and DS1682 integrated elapsed-time recorder
File:Ge flashpad main pcb closeup 4.jpg|Accelerometer is a 834-0500 500G 3 Axis unit, and TJ500AE SPDT gigabit LAN switch
File:Ge flashpad bottom connector.jpg|bottom connector for docking stand
File:Ge flashpad main pcb closeup 5.jpg|Ethernet transformers and ADM34 RS-485/RS-422 Transceiver
File:Ge flashpad main pcb closeup 6.jpg|Altera EPM570f100c5n CPLD
File:Ge flashpad main pcb closeup 7.jpg|Spansion GL512P10FF1R1 512 Mbit NOR flash IC holding everything
File:Ge flashpad main pcb closeup 8.jpg|24LC256I 32k EEPROM for storing the accelerometer events
</gallery>

==Main test py script: Usage and Parameters==

current iteration found here: https://pastebin.com/vEfAresk

flashpad_acquire.py is a single file Python 3 tool that speaks the FlashPad
URP/PDAP protocol over UDP. It implements discovery, the control handshake,
script download and execution, sensor readout, full data backup, and the host
registration (pairing) write. It requires only the Python standard library.

===Default network configuration===

These defaults match the values in ConnectionPoint.cfg and can be overridden on
the command line.

{| class="wikitable"
!Setting!!Default!!Meaning
|-
|Detector IP||192.168.1.30||the panel; listens for all commands on UDP 8100
|-
|Host IP||192.168.1.1||this machine, announced in SYSTEM_STARTUP
|-
|Detector port||8100||where commands are sent
|-
|Host command port||5550||where the detector returns protocol replies
|-
|Host image port||6660||where pixel data would stream
|-
|Discovery port||4500||where the detector sends its beacons
|}

===Connection and general options===

{| class="wikitable"
!Option!!Default!!Effect
|-
| --detector-ip IP||192.168.1.30||detector address
|-
| --host-ip IP||192.168.1.1||host address sent in SYSTEM_STARTUP
|-
| --output-dir DIR||.||where raw images are written
|-
| --timeout SECONDS||5.0||UDP receive timeout
|-
| --exec-timeout SECONDS||60||how long to wait for EXECUTION_COMPLETE
|-
| --skip-discovery||off||send SYSTEM_STARTUP once and proceed, skipping the discovery loop
|-
| --quiet||off||suppress the verbose per packet log
|}

===Read and diagnostic modes (non destructive)===

These only read from the detector. None of them write anything.

{| class="wikitable"
!Option!!What it does!!What to expect
|-
| --sensors||Reads the full 32 entry sensor table using cmd 0x7902 (converted) and 0x7900 (raw), side by side.||A decoded table of supply rails in volts. Temperatures show as railed. Unimplemented sensors (accelerometer DEM id, battery, grid) are flagged as stale.
|-
| --no-roe-init||With --sensors, skips the Script7 ROE init before reading.||Slightly faster sensor read, marginally less reliable.
|-
| --probe-data||Reads DetectorInfo, the HostList (registration state), and cal results via the upload protocol (cmd 0x13/0x14).||A hexdump and text decode of each. Shows whether any host is registered and which HostId the detector expects.
|-
| --backup [DIR]||Sweeps all upload IDs 0x00 to 0xFF and saves every readable blob to DIR/detector_backup_timestamp/.||A manifest plus one .bin per readable ID, including the full 64 MB flash image and the calibration maps. Do this before any write. Large blobs take a few minutes each.
|-
| --backup-range LO-HI||Limits the --backup sweep, for example 0x40-0xA0.||Faster, partial backup.
|-
| --dump-scripts||Prints the wire bytes of all built scripts as hex and exits.||No network activity; useful for inspecting the script encoding.
|-
| --listen||Passively listens on the host command port for 30 seconds.||Prints any packets the detector sends; useful for watching beacons.
|}

===Acquisition modes===

The default invocation (no mode flag) runs a standard acquisition, which
requires an actual X-ray exposure to complete.

{| class="wikitable"
!Option!!What it does!!What to expect
|-
|(no flag)||Standard acquisition (Script 0).||Needs an X-ray exposure to reach EXECUTION_COMPLETE.
|-
| --dark||Runs the dark/offset acquisition (Script 1) before the standard one.||Two acquisitions; the dark one needs no X-ray.
|-
| --dark-only||Runs only the dark acquisition (Script 1).||Completes in a few seconds with no X-ray. The detector acquires and holds an 8 buffer image. Best way to test the full flow.
|-
| --no-standby||Omits the Script 8 standby loop.||Use if the standby loop blocks acquisition.
|-
| --two-exec||Executes Script 7 alone, waits, then Script 1. Only with --dark-only.||Tests the two stage execution hypothesis.
|-
| --parallel||Answers the detector status query (0x30000) with the cmd 0x99 ParallelImageTransfer reply instead of cmd 9.||Experiment to see if the parallel reply triggers a pixel push. (Result so far: it does not.)
|-
| --sweep-acq||Sweeps the dark acquisition across type_mode and transfer_mode values, watching for a 0x0F pixel push.||Non destructive experiment; reports which combination, if any, makes the detector stream.
|-
| --preview||Single dark acquisition on the preview path (transfer_mode 2, 4 buffer image). Watches port 6660 for a push.||One clean connection; run a packet capture on the detector address in parallel.
|}

Note: at present the detector acquires and holds an image but does not push the
0x0F pixel frames. The acquisition modes complete the handshake and acquisition,
but image streaming is still being investigated.

===Registration and write operations===

These can write to the detector's flash. Every write is a dry run by default and
only takes effect when --commit is added. Always run --backup first.

{| class="wikitable"
!Option!!What it does
|-
| --register-self||Adds this host to the detector HostList and sets it as the primary host, so the detector should stream images to it. Appends an entry, sets IndexToPrimaryHost, recomputes the CRC, and writes via id 0x71. Dry run unless --commit.
|-
| --host-mac MAC||The MAC of the interface talking to the detector, used to derive this host's HostId for --register-self. Default 00:6f:00:01:0a:3a.
|-
| --smoke-test-write||Reads the HostList and writes back the identical bytes to validate the write and commit path without changing anything. Dry run unless --commit.
|-
| --restore-hostlist FILE||Writes a saved HostList blob (for example detector_backup_*/upload_0x71_504.bin) back to the detector. This is the undo button. Dry run unless --commit.
|-
| --commit||Arms the actual flash write for the operations above. Without it they only print what they would do. This writes the detector's flash and is irreversible at the chip level, although the HostList region can be restored from a backup.
|}

===Typical workflow===

#Read the current state: <code>python flashpad_acquire.py --probe-data</code>
#Make a full backup: <code>python flashpad_acquire.py --backup</code>
#Check sensors and power rails: <code>python flashpad_acquire.py --sensors</code>
#Dry run the registration: <code>python flashpad_acquire.py --register-self --host-mac YOUR:MAC</code>
#When satisfied, commit it: add <code>--commit</code>
#If needed, undo: <code>python flashpad_acquire.py --restore-hostlist detector_backup_*/upload_0x71_504.bin --commit</code>

==Known Dead Ends==

Things that were tried and did not work or led nowhere:

;0xBEEF (48879) as reply port
:This was a bug in early test scripts. The port has no meaning in the protocol. Use 5550.

;CmdFlag=1 as data packet flag
:Early scripts had the URP fields swapped, setting CmdFlag=1 on data packets. The detector ignores all PDAP content in these packets. Power cycle the detector if this happened, it may retain stale port state.

;Image data on alternate ports
:Tried listening on 48879, 6660, 5550, 8100, 1050, 6661, 9999, 4444, 7000, 7001, 9001. Nothing arrived on any of them.

;PORT_SETUP byte order (big-endian)
:Current implementation sends port fields as big-endian. If the detector reads them as little-endian it computes port 44565 and 1050 instead of 5550 and 6660, which would explain why no image data arrives. Not yet confirmed.

;Image data streaming automatically after EXECUTE_SCRIPT
:Frames may not push during execution at all. The detector may require an explicit IMAGE_RETRIVAL_REQUEST (cmd_type=0x41) and IMAGE_RETRIVAL (cmd_type=0x98) after the 0x30000 notification before it streams anything. Not yet tested.

GE Medical Flashpad Digital Xray Detector

2026-06-11T12:15:58Z

Gamerpaddy: /* Purpose and Motivation */

==Overview==
{{Note|UNFINISHED Project, it was not yet possible to retrieve a exposure or dark frame in my testing, further investigation needed. any help is appreciated on recessim discord.}}

The '''GE Flashpad''' is a Digital Radiography image sensor from approximately 2010, originally used in the '''GE Optima 220AMX''' mobile X-ray unit. It was designed to replace analog film in radiology, dramatically reducing image acquisition time from hours to seconds.
[[File:GE Flashpad.jpg|thumb|Flashpad with Anti-Scatter grid (left), manual and recovery dvd for 220amx and tether cord (right)]]
Due to its high original cost and specialized application, used units occasionally appear on professional B2B marketplaces in the $15,000–$50,000 range. On eBay, prices typically fall between $1,500 and $5,000, though units at this price point are often in poor condition and may fail the built-in self-test or not function at all.

{{Note|All findings on this page are based on a single unit and the time spent working on it. Information is subject to speculation and may not be fully accurate.}}

{{Note|AI assistance was used in writing this page for improved formatting and readability, as well as in the process of finding information, testing, and analyzing firmware dumps and backups.}}

==Purpose and Motivation==

This project documents the reverse engineering of the GE FlashPad wireless
digital radiography detector used with the Optima XR200/220 AMX mobile X-ray
system, with the goal of freeing these detectors for independent use.
[[File:Xray capture pcb.png|thumb|Xray capture of a PCB for Reverse Engineering using a different detector]]
Large numbers of these detectors reach the used market, but each one is
cryptographically and administratively bound to its original Optima 220 AMX
console. Once separated from that console, or once the console is
decommissioned, the detector is effectively useless even though the hardware is
fully functional. The aim of this work is to remove that artificial barrier so
that a standalone FlashPad can be paired, configured, and read out by any host,
without the half million dollar console it was sold with.

The intended beneficiaries are:

*Hobbyists, researchers, and engineers who want a high quality flat panel detector for their own imaging projects.
*Veterinary practices, which can put surplus human grade detectors to good use at a fraction of the cost of new equipment.
*Clinics and hospitals in countries and regions where a complete commercial system is unaffordable, allowing serviceable detectors to keep providing diagnostic imaging instead of being scrapped.

[[File:Xray current clamp multimeter.png|thumb|xray of a current clamp multimeter using a different detector]]
This is done for human good. Every detector returned to service is one less
piece of working medical hardware sent to landfill, and potentially one more
place that can offer X-ray imaging where it otherwise could not.

All files, findings, protocol documentation, and tools produced by this project
are public and open source, so that anyone can study, reproduce, and build on
the work.

==Technical Specifications==
[[File:Ge flashpad tether cable pinout diagram.png|thumb|Pinout Diagram of the Tether cable]]
[[File:Ge flashpad tether wiring for ethernet cable.jpg|thumb|Professional Tether wiring to attach a Ethernet Cable and 12V socket to it.]]
The Flashpad uses a '''~40 × 40 cm CsI scintillator''' bonded to a [[Thin-film transistor|TFT]] photodetector array mounted on glass. The assembly is highly sensitive to shock and impact damage. See section [[#Reading the Drop and Shock Event Log|drop and shock event log]]

{| class="wikitable"
|-
!Parameter!!Value
|-
|Resolution||2048 × 2048 px
|-
|Bit depth||16-bit per pixel
|-
|Spatial resolution||Up to 5 lp/mm (theoretical)
|-
|Scintillator material||Caesium iodide (CsI)
|-
|Detector type||TFT photodetector array (glass substrate)
|-
|Panel size||~40 × 40 cm
|}

The theoretical 5 lp/mm spatial resolution is primarily limited in practice by the focal spot size of the X-ray source. Use of an anti-scatter grid can improve effective resolution.

===Status of Reverse Engineering===

{| class="wikitable"
|-
!What!!Status
|-
|Connect, beacon, ACK||Works
|-
|PORT_SETUP||Works
|-
|SIGNATURE_REQUEST / serial number readout||Works
|-
|Script download (Scripts 7, 8, 1)||Works
|-
|EXECUTE_SCRIPT||Works
|-
|EXECUTION_COMPLETE (dark acquisition)||Works but without image readout its speculation.
|-
|EXECUTION_COMPLETE (standard acquisition)||Needs real X-ray trigger to test
|-
|Image data on port 6660||Does not work yet, under investigation. Will not send Imagedata...
|}

==Hardware Features==

===Shock logging===
The unit contains an internal accelerometer that logs significant shock events — but only when a battery is inserted. As there is no backup battery, shock events occurring while unpowered are not recorded.

===Wireless connectivity===
Some units include a UWB transmitter for Wireless USB; others may be equipped with a Wi-Fi module instead. The detector can also be operated over the tethered connection alone.

===Ethernet interface===
There is a 100MBit Ethernet interface trough the Tether Cable which can be tapped and used for Communication.
Exposed metal contacts on the bottom connector are isolated via relays by default. Enabling Gigabit Ethernet connectivity requires shorting or driving two specific pins. This has not been investigated further at this time.

==Communication Protocol==

This section documents the URP/PDAP protocol used by the GE Flashpad (codename '''Apollo''') to communicate with a host over Ethernet. All findings are based on live capture tests, configuration files, and reverse-engineering of the GE SuperBee software stack.

{{Note|All findings are based on a single unit and may not be fully accurate.}}

===Network Setup===

All findings were over Ethernet only, no UWB or WIFI has been used.
Default detector IP is <code>192.168.1.30</code>. Set your host to a static IP in the same subnet, <code>192.168.1.1</code> works fine.

At first by sending random bytes over Python it answered to port 48879 (0xBEEF), which seems to be either the default port or set by Python.
After SYSTEM_SETUP it got set to 5550.

{| class="wikitable"
|-
!Role!!IP!!Port!!Direction
|-
|All commands: host -> detector||192.168.1.30||'''8100''' (UDP)||Host sends here
|-
|Discovery beacons: detector -> host||-||'''4500''' (UDP)||Detector sends here initially
|-
|Protocol replies: detector -> host||-||'''5550''' (UDP)||Detector sends here after setup
|-
|Image pixel data: detector -> host||-||'''6660''' (UDP)||Detector streams frames here
|}

In practice you can listen on port '''5550''' for everything (beacons and replies) by advertising that port in both <code>SYSTEM_STARTUP</code> and <code>PORT_SETUP</code>. The detector sends to whichever port was most recently configured.

===Protocol Layers===

Two layers, carried over UDP:

;URP (Unified Registration Protocol)
:8-byte wrapper on every packet. Handles sequencing and acknowledgement.

;PDAP (Proprietary Detector Access Protocol)
:The actual command layer, present inside URP packets when <code>CmdFlag = 0</code>.

Every UDP packet starts with a URP header:

<pre>
[SeqId : 4 bytes LE] [CmdFlag : 4 bytes LE]
</pre>

*<code>CmdFlag = 0</code> -- data packet, PDAP command follows.
*<code>CmdFlag = 1</code> -- bare ACK, no PDAP body. SeqId echoes the packet being acknowledged.

Both sides must ACK every data packet immediately. The detector silently drops packets with a SeqId it has already seen, so always increment SeqId for each new command.

When CmdFlag is 0, the PDAP header follows immediately:

<pre>
[cmd_type : 4 bytes LE] [payload_len : 4 bytes LE] [payload ...]
</pre>

===Connecting to the Detector===

The connection sequence is:

#Broadcast <code>SYSTEM_STARTUP</code> to tell the detector where to reply.
#The detector sends a <code>BEACON</code> back -- ACK it and sync your sequence counter.
#Send <code>PORT_SETUP</code> to configure the reply and image ports.
#Send <code>SIGNATURE_REQUEST</code> to read the detector identity (serial number, model, firmware, MAC).

====Step 1: SYSTEM_STARTUP====

Broadcast UDP to <code>192.168.1.255:8100</code>. Always uses <code>SeqId = 0</code>.

<pre>
URP : [00 00 00 00] SeqId = 0
[00 00 00 00] CmdFlag = 0
PDAP: [01 00 00 00] cmd_type = 1
[06 00 00 00] payload_len = 6
[15 AE] host reply port = 5550 (big-endian)
[C0 A8 01 01] host IP = 192.168.1.1 (network byte order)
</pre>

<syntaxhighlight lang="python">
import socket, struct

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
sock.bind(("0.0.0.0", 5550))

HOST_IP = "192.168.1.1"
DET_IP = "192.168.1.30"
HOST_PORT = 5550
IMG_PORT = 6660

def make_urp_packet(seq_id, pdap_bytes):
return struct.pack("<II", seq_id, 0) + pdap_bytes

pdap = struct.pack("<II", 1, 6) + struct.pack(">H", HOST_PORT) + socket.inet_aton(HOST_IP)
sock.sendto(make_urp_packet(0, pdap), ("192.168.1.255", 8100))
</syntaxhighlight>

====Step 2: Receiving the BEACON and ACKing====

The detector broadcasts a <code>BEACON</code> (cmd_type=1) roughly every 2 seconds. After sending SYSTEM_STARTUP you should get one quickly. Parse the detector SeqId from the URP header and ACK it:

<syntaxhighlight lang="python">
data, addr = sock.recvfrom(4096)
det_seq = struct.unpack_from("<I", data, 0)[0]

# send bare ACK
ack = struct.pack("<II", det_seq, 1)
sock.sendto(ack, (DET_IP, 8100))

# all subsequent commands start from here
host_seq = det_seq + 1
</syntaxhighlight>

====Step 3: PORT_SETUP====

Tells the detector which host ports to use for replies and image data.

<pre>
PDAP: [02 00 00 00] cmd_type = 2
[04 00 00 00] payload_len = 4
[15 AE] host cmd port = 5550 (big-endian)
[1A 04] host image port = 6660 (big-endian)
</pre>

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 2, 4) + struct.pack(">HH", HOST_PORT, IMG_PORT)
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1
# expect bare ACK from detector
</syntaxhighlight>

====Step 4: Reading the Serial Number (SIGNATURE_REQUEST)====

Empty command, the detector replies with a 54-byte payload containing its identity.

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 3, 0) # cmd_type=3, payload_len=0
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1

# reply is 70 bytes total: 8 URP + 8 PDAP header + 54 payload
data, _ = sock.recvfrom(4096)
payload = data[16:] # skip URP (8) + PDAP header (8)

mac = payload[0:6]
serial = payload[22:34].rstrip(b'\x00 ').decode()
model = payload[34:46].rstrip(b'\x00 ').decode()
fw_bytes = payload[46:54]
firmware = ".".join(str(b) for b in fw_bytes)

print(f"MAC: {':'.join(f'{b:02X}' for b in mac)}")
print(f"Serial: {serial}")
print(f"Model: {model}")
print(f"Firmware: {firmware}")
</syntaxhighlight>

Expected output:
<pre>
MAC: 40:F4:A0:00:78:4D
Serial: UA45829-7
Model: 5340000-7
Firmware: 1.6.0.4.2.0.1.3
</pre>

===Running an Acquisition===

After the connection sequence above, download scripts to the detector and then execute them.

====ROE Initialisation (Script 7)====

Always run this first. It initialises the readout electronics and takes about 4-5 seconds. The detector sends host event ID 17 when done.

====Dark / Offset Acquisition (Script 1)====

No X-ray source required. Runs a dark-field exposure for offset calibration. Use this to verify the acquisition pipeline without a generator.

====Standard Acquisition (Script 0)====

Requires an actual X-ray exposure. <code>EXECUTION_COMPLETE</code> will '''not''' arrive without a real X-ray trigger.

====Sequence Overview====

<pre>
HOST DETECTOR
| |
|-- SYSTEM_STARTUP (broadcast) ----------->|
|<- bare ACK -------------------------------|
|<- BEACON (cmd_type=1) --------------------|
|-- bare ACK ------------------------------>|
| |
|-- PORT_SETUP (cmd_type=2) -------------->|
|<- bare ACK -------------------------------|
| |
|-- SIGNATURE_REQUEST (cmd_type=3) ------->|
|<- SIGNATURE_REPLY (54 bytes) -------------|
|-- bare ACK ------------------------------>|
| |
|-- GENERIC_SCRIPT Script7 (ROE init) ---->|
|<- bare ACK or SCRIPT_DOWNLOAD_REPLY ------|
| |
|-- GENERIC_SCRIPT Script1 (dark acq) ---->|
|<- bare ACK -------------------------------|
| |
|-- EXECUTE_SCRIPT (cmd_type=6) ---------->|
|<- bare ACK -------------------------------|
|<- EXECUTE_SCRIPT_REPLY (~230ms) ----------|
|-- bare ACK ------------------------------>|
|<- DETECTOR_STATE_NOTIFY (~890ms) ---------| state_id=17
|-- bare ACK ------------------------------>|
| |
|<- EXECUTION_COMPLETE (0x10000) -----------|
|-- bare ACK ------------------------------>|
| |
|<- IMAGE_XFER_STATUS_QUERY (0x30000) ------|
|-- bare ACK ------------------------------>|
|-- IMAGE_XFER_STATUS_REPLY (cmd_type=9) ->| numMissed=0
|<- bare ACK -------------------------------|
</pre>

===Sequence Counter Rules===

*<code>SYSTEM_STARTUP</code> always uses <code>SeqId = 0</code>.
*After the first beacon, set host SeqId to beacon_SeqId + 1.
*Increment SeqId by 1 for every new data packet (CmdFlag=0).
*Bare ACKs echo the SeqId of the packet being acknowledged and do not consume a SeqId.
*The detector silently drops any packet with a SeqId it has already processed, so never reuse one.

==Sensor Readout and Host Registration==

This section documents the reverse engineered sensor telemetry interface and the
host registration (pairing) mechanism of the GE Optima XR200/220 AMX FlashPad
(URP detector, SuperBee, FW 1.6.0.4.2.0.1.3). All commands are PDAP over UDP to
the detector at port 8100; replies return to the host command port.

===Sensor Readout===

The detector exposes an analog sensor interface (the DEM, Detector Environment
Monitor) that is independent of the image transfer path and works regardless of
acquisition state.

====Commands====

{| class="wikitable"
!cmd_type!!Meaning!!Request payload!!Reply payload
|-
|0x7900||Raw sensor read||[sensorId:4 LE]||[value:4 LE] (12 bit ADC count)
|-
|0x7902||Converted sensor read||[sensorId:4 LE]||[value:4 LE] (engineering units, signed)
|-
|0x7904||Detailed / radio||[selector:4 LE]||[value:4 LE]
|}

Note: cmd 0x7902 IS supported on this firmware and returns calibrated
engineering units (millivolts for the supply rails, signed; 0.1 degree C for
temperatures). Earlier documentation that marked 0x7902 as unsupported is
incorrect. The host side conversion coefficients are not required; the detector
performs the conversion internally.

The full sensor map (name, sensorId) was recovered from the detector's own
[Sensor] configuration table, read back over the upload interface (see the
Registration section for the read protocol).

====Power rails (live readings)====

All supply rails read correctly via 0x7902 and are within normal range for a
flat panel detector. Representative readings:

{| class="wikitable"
!Sensor!!sensorId!!Converted!!Value
|-
|DCIN_RAW||10||12100 mV||+12.10 V (main DC input)
|-
|LCORE_UNREG||11||1724 mV||+1.72 V
|-
|LPANA_UNREG||12||5776 mV||+5.78 V
|-
|LNANA_UNREG||13||-5801 mV||-5.80 V
|-
|SCAN_VCC||14||5086 mV||+5.09 V (gate driver)
|-
|P5V_REF||16||5025 mV||+5.03 V (5 V reference)
|-
|V_ON||17||11085 mV||+11.09 V (TFT gate on)
|-
|V_OFF||18||-12378 mV||-12.38 V (TFT gate off)
|-
|V_COMMON||19||-9385 mV||-9.39 V
|-
|3V3||29||3177 mV||+3.18 V (3.3 V logic)
|-
|VCC_UNREG||37||3399 mV||+3.40 V
|-
|PARCPREG||38||3768 mV||+3.77 V (ARC preamp +)
|-
|NARCPREG||39||-3732 mV||-3.73 V (ARC preamp -)
|-
|PANA_UNREG||45||18352 mV||+18.35 V (photodiode bias +)
|-
|NANA_UNREG||46||-19251 mV||-19.25 V (photodiode bias -)
|}

Switched rails that are inactive while the panel is idle (PARCVA_U,
P5VA_SW, N5VA_SW, FGATE_NVC_L, FGATE_PVC_L, etc.) read at or near zero.

====Known limitations====

*'''Temperatures''' (Temp_Surface, sensorId 336; Temp_Panel, sensorId 352): the raw 0x7900 read rails at 0x3FF (1023, the ADC maximum), indicating an open thermistor path while the panel is idle. This is a hardware/state condition, not a command problem, and the temperature is not readable from the host in this state.
*'''Unimplemented sensors''': sensorIds 70 (Accelerator), 78 (Gravity), and 256 to 259 (Battery status, name, life, capacity), and 272 (Grid status) are not implemented on this DEM. The detector returns the leftover conversion register contents (a duplicate of a previously read sensor) rather than a real value, so these rows must be discarded.
*'''Accelerometer''': functional through a separate addressing scheme using raw cmd 0x7900 with selectors 0x42 (X), 0x43 (Y), 0x44 (Z), returning 12 bit per axis counts.

===Host Registration (Pairing)===

URP stands for Unified Registration Protocol. The detector maintains a host
list in its internal NOR flash. Image data is delivered only to a registered
primary host, so registration is a prerequisite for image transfer.

====Host identity (MAC and HostId)====

Each host is identified by a 16 character HostId derived deterministically from
the host's eth0 MAC address. The derivation (from the vendor generateHostId
script) is:

#Take the eth0 MAC, remove the colon separators, convert to upper case (12 hex characters).
#Prepend the last 4 characters to the full 12 characters.
#The result is 16 hex characters.

Example: MAC 00:6f:00:01:0a:3a becomes 006F00010A3A, then the last four (0A3A)
are prepended, giving HostId 0A3A006F00010A3A.

====HostList structure====

The host list is stored in flash at offset 0x940000 and can be read back over
the upload interface as data category 0x71. Layout:

Offset Size Field
0x00 16 DetectorDeviceId (ASCII)
0x10 16 ConnectionSecretKey (ASCII; "XXXXXXXXXXXXXXXX" when unset)
0x20 16 DetectorName (ASCII)
0x30 16 DetectorCode (ASCII)
0x40 2 CurrentNumberOfHosts (uint16 LE)
0x42 2 IndexToPrimaryHost (uint16 LE; 0xFFFF = none)
0x44 144*N Host entries, 144 bytes each:
+0x00 16 HostId (ASCII)
+0x10 .. host name / department string
+0x50 .. location string
... 4 CRC (big endian; see below)

====HostList from the unit under test====

Detector: MAC 40:F4:A0:00:78:4D, serial UA45829-7, model 5340000-7,
firmware 1.6.0.4.2.0.1.3. DetectorName starShape_green. ConnectionSecretKey
unset. CurrentNumberOfHosts = 3, IndexToPrimaryHost = 0xFFFF (no primary host).

{| class="wikitable"
!Index!!HostId!!Derived MAC!!Name
|-
|0||2C6400045FB42C64||00:04:5F:B4:2C:64||Haus 207 / ITS
|-
|1||B044E8393512B044||E8:39:35:12:B0:44||Not Initialized
|-
|2||5CF800045FB15CF8||00:04:5F:B1:5C:F8||Not_Initialized
|}

The unit is therefore not factory fresh; it carries registrations from a prior
deployment, but no primary host is currently designated.

====Checksum (CRC)====

The HostList (and other flash data blobs) are protected by a 4 byte trailing
CRC. Parameters:

*Polynomial: 0x04C11DB7
*Initial value: 0
*MSB first, augmented message style (the data bit is shifted into the LSB; no input or output reflection; no final XOR)
*Stored big endian

To generate: compute the CRC over the data followed by four zero bytes, then
append the result big endian. Verification: the CRC over (data plus stored CRC)
equals zero.

def crc(data, poly=0x04C11DB7, init=0):
c = init
for byte in data:
for bit in (0x80,0x40,0x20,0x10,0x08,0x04,0x02,0x01):
msb = c & 0x80000000
c = (c << 1) & 0xFFFFFFFF
if byte & bit: c |= 1
if msb: c ^= poly
return c
# trailer = crc(data + b"\x00\x00\x00\x00"), stored big endian

====Read and write transport====

Data blobs (including the HostList) are moved with a configure / buffer /
finalize sequence.

Read (upload, detector to host), non destructive:

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x13||[uploadId:4 LE]||[status:1][totalSize:4 LE]
|-
|Buffer||0x14||[bufId:4 LE][numBytes:4 LE]||[bufId:4 LE][numBytes:4 LE][data]
|}

Write (download, host to detector), persistent (writes flash):

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x0E||[downloadId:4 LE][totalSize:4 LE]||[status:1]
|-
|Buffer||0x0F||[bufId:4 LE][numBytes:4 LE][data]||[status:1][reserved:4]
|-
|Commit||0x10||(empty)||[status:1]
|}

bufId is a zero based chunk index. The HostList uses id 0x71 for both read and
write. The commit command (0x10) reuses the firmware flash path, so a malformed
download can corrupt flash; the operation is irreversible on this hardware.

====Registering a new host====

To register a host and make it the image destination, read the current HostList
(0x71), append a 144 byte entry carrying the new HostId, increment
CurrentNumberOfHosts, set IndexToPrimaryHost to the new entry's index,
recompute the trailing CRC, and write the blob back via the download sequence
(0x0E / 0x0F / 0x10).

===Reading the Drop and Shock Event Log===

The detector contains an accelerometer based shock watchdog that records drop
and impact events into non volatile memory. This log is useful when evaluating a
used unit, since it reveals how many serious shocks the panel has survived and
when. The same data is held both in the main flash (read over the network) and
in the small onboard EEPROM on the detector PCB.

====How to read it====

The shock log is exposed as data category 0x72 on the upload (read) interface.
It is retrieved with the standard non destructive configure and buffer sequence
(cmd 0x13 to configure, cmd 0x14 to pull the chunks). On the unit under test the
blob is 3001 bytes of plain text in the GE .dyn configuration format, so no
decoding is required beyond reading it as ASCII.

The same records are mirrored in binary form in the onboard 24LC256 EEPROM
(32 KB I2C part) for anyone reading the hardware directly.

====Example output====

The following is the actual log read from detector serial UA45829-7. The file
has two parts: a list of individual events (DetectorShockEvents) and a summary
block (DetectorShockData). Each event carries a record key, a severity, a
timestamp, and the peak acceleration on each axis. Two representative records:

<DetectorShockEvents>
[149266438700135]
Severity.Type = String
Severity.Val = Serious
TimeStamp.Type = String
TimeStamp.Val = 2017-4-20,6:59:47
ValidTime.Type = Number
ValidTime.Val = 0
VibrationX.Type = Number
VibrationX.Val = 0
VibrationY.Type = Number
VibrationY.Val = 0
VibrationZ.Type = Number
VibrationZ.Val = 135

[1592113924-1720-113]
Severity.Val = Serious
TimeStamp.Val = 2020-6-14,7:52:4
VibrationX.Val = -172
VibrationY.Val = 0
VibrationZ.Val = -113

The summary block at the end lists the totals and an index of all event keys:

[DetectorShockData]
LastKnownGoodTime.Val = 2024-4-4,6:53:59
NumberOfL3Events.Val = 0
NumberOfL5Events.Val = 7
ShockDataTimeList.Val = { 1643260890-1320-119, 163626503500-123,
160818190500-101, 160524243000170, 1592113924-1720-113,
157804584600183, 149266438700135 }

====Interpreting the records====

The record key encodes the event time and the peak axis values (an epoch style
timestamp followed by the concatenated vibration readings), so it is unique per
event. The VibrationX, VibrationY, and VibrationZ values are signed peak
acceleration counts on each axis. Severity is reported as Serious for all
logged events on this unit, which corresponds to the L5 (highest) severity class
counted in the summary.

The seven recorded events for this detector:

{| class="wikitable"
!Date and time!!VibrationX!!VibrationY!!VibrationZ
|-
|2017-04-20 06:59:47||0||0||135
|-
|2020-01-03 11:04:06||0||0||183
|-
|2020-06-14 07:52:04||-172||0||-113
|-
|2020-11-13 05:40:30||0||0||170
|-
|2020-12-17 06:11:45||0||0||-101
|-
|2021-11-07 07:03:55||0||0||-123
|-
|2022-01-27 06:21:30||-132||0||-119
|}

====Reading the summary fields====

{| class="wikitable"
!Field!!Meaning
|-
|LastKnownGoodTime||Timestamp of the last successful self check (here 2024-04-04), the most recent point at which the detector was known to be operating normally
|-
|NumberOfL3Events||Count of lower severity (L3) shock events; zero on this unit
|-
|NumberOfL5Events||Count of high severity (L5) shock events; seven on this unit, matching the seven records above
|-
|ShockDataTimeList||Index of all stored event keys, newest first
|}

On this example the panel logged seven serious impacts over roughly five years
of field use and last reported a good self check in April 2024.

==FlashPad Detector: Internal Flash Dump and Data Files==

This section documents how the full contents of the detector's internal flash
were extracted over the network and what each recovered file contains. The
detector under test is a GE Optima XR200/220 AMX FlashPad (URP detector,
serial UA45829-7, MAC 40:F4:A0:00:78:4D, firmware 1.6.0.4.2.0.1.3).

===Background===

The detector's main storage is a Spansion/Cypress S29GL512P (marked
GL512P10FFCR2), a 512 Mbit (64 MB) parallel NOR flash. A direct chip read
requires bus access or desoldering and a programmer. However, the detector
firmware exposes its stored data blobs, including a full image of the flash,
through the read (upload) side of the data transport protocol. This makes a
complete, byte exact dump possible over UDP with no physical access.

===Extraction method===

The upload interface is the read counterpart of the firmware download path and
is non destructive (it only reports and returns data; nothing is written).
Each data category is identified by an 8 bit upload ID:

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x13||[uploadId:4 LE]||[status:1][totalSize:4 LE]
|-
|Buffer||0x14||[bufId:4 LE][numBytes:4 LE]||[bufId:4 LE][numBytes:4 LE][data]
|}

A configure request returns status 0 and a total size for a valid ID, or a non
zero status for an unsupported ID. The dump tool sweeps all IDs from 0x00 to
0xFF, and for every readable ID it pulls the full blob in fixed size chunks
(bufId is a zero based chunk index) and writes it to a file. The 64 MB flash
image transfers as 65536 chunks of 1024 bytes.

===Recovered files===

A sweep of the unit returned 18 readable blobs:

{| class="wikitable"
!Upload ID!!Size (bytes)!!Contents
|-
|0xFD||67108864||Full 64 MB NOR flash image
|-
|0xFF||16777216||16 MB region (firmware / FPGA mirror or image buffer)
|-
|0xFE||524288||Bootloader (512 KB; SPI loader, Nios reset code)
|-
|0x10||6815783||Calibration map, dose level 1
|-
|0x11||6815783||Calibration map, dose level 2
|-
|0x12||6815783||Calibration map, dose level 3
|-
|0x06||49254||Table referencing conditioner/generator serial UA2010-8U005
|-
|0x50||19938||Per mode calibration coefficients
|-
|0x51||19582||Per mode calibration coefficients
|-
|0x07||12187||Sensor conversion table (text; see Sensor Readout)
|-
|0x72||3001||Shock / drop event log (text)
|-
|0x0E||624||Panel geometry / configuration (binary)
|-
|0x71||504||Host list / registration record (see Host Registration)
|-
|0x0F||233||Host to detector compatibility table (text)
|-
|0x08||62||Serial and model strings
|-
|0x0A||48||Manufacturing codes
|-
|0x52||30||Serial string
|-
|0x0B||24||Small marker / identifier
|}

===Flash image layout (upload ID 0xFD)===

A block scan of the 64 MB image shows the following regions:

{| class="wikitable"
!Range!!Contents
|-
|0x000000 to 0x800000||Firmware and FPGA configuration
|-
|0x800000 to 0x940000||Sparse configuration area
|-
|0x940000||Host list / registration record (matches upload ID 0x71)
|-
|0x1000000 to 0x2800000||Calibration and image data (16 to 40 MB)
|-
|0x2800000 to 0x4000000||Erased / unused (40 to 64 MB)
|}

The host list strings (the DetectorName starShape_green, the registered host
name Haus 207 / ITS, and the unset ConnectionSecretKey placeholder) appear at
0x940000, confirming that the 504 byte 0x71 read maps to this flash region.

===Notes on individual files===

*'''0x07 (sensor table)''': plain text, header DetectorSerialNumber = UA45829-7, revision 1.2. Lists every sensor by name, command (0x7902), and sensorId. Also carries panel geometry in its [Common] section: 16 bit depth, 2048 by 2048 pixels, active area from (12, 12) to (2035, 2035), pixel pitch 0.2 mm, corner radius 1416.8, panel saturation 150.
*'''0x10, 0x11, 0x12 (calibration maps)''': three distinct blobs of identical size, corresponding to the low, medium, and high dose calibration sets. Each begins with the firmware version and serial (header bytes 01 06 00 04 02 00 01 03 followed by the serial). Required to apply gain and offset correction to raw images.
*'''0xFE (bootloader)''': contains the strings spi_load.S and ../../boot and Nios II reset vector code.
*'''0x72 (shock log)''': text records of drop / vibration events with timestamps and per axis values; the same data is mirrored in the detector's small onboard EEPROM.
*'''0x06''': references a different serial, UA2010-8U005, likely the conditioner or generator board rather than the panel.

===Significance===

The complete flash image and all calibration data are recoverable over the
network without opening the detector, providing a full byte exact backup of the
unit before any write operation. The calibration maps are needed for image
correction, and the firmware image (the live, deployed build) is more complete
than the partial firmware files shipped on the recovery media.

==Teardown / Internal Pictures / Hardware analysis==

<gallery mode="packed" heights="200">
File:GE Flashpad under the hood.jpg|the Carbon fiber sleeve is held by 9 screws and can taken off without force.
File:Ge flashpad powersupply pcb in handle.jpg|Power supply PCB
File:Ge flashpad uwb board pcb.jpg|UWB PCB for Wireless USB using a RTU2705
File:Ge flashpad uwb pcb backside.jpg|Backside of UWB PCB
File:Ge flashpad power supply pcb backside.jpg|Backside of Power supply PCB
File:Ge flashpad main pcb closeup1.jpg|Main area of the PCB with its Altera Cyclone 3 FPGA
File:Ge flashpad main pcb closeup2.jpg|AD7892 is a 600ksps 12bit ADC, SN74LVC8T245 a 8bit bus transceiver and DG9408EDN a 8ch MUX
File:Ge flashpad bottom connector ethernet isolation pcb.jpg|Isolation PCB for bottom connector
File:Ge flashpad main pcb powersupply section.jpg|Powersupply section for FPGA and ROIC
File:Ge flashpad main pcb closeup 3.jpg|AD9764AR 14-Bit, 125 MSPS DAC and DS1682 integrated elapsed-time recorder
File:Ge flashpad main pcb closeup 4.jpg|Accelerometer is a 834-0500 500G 3 Axis unit, and TJ500AE SPDT gigabit LAN switch
File:Ge flashpad bottom connector.jpg|bottom connector for docking stand
File:Ge flashpad main pcb closeup 5.jpg|Ethernet transformers and ADM34 RS-485/RS-422 Transceiver
File:Ge flashpad main pcb closeup 6.jpg|Altera EPM570f100c5n CPLD
File:Ge flashpad main pcb closeup 7.jpg|Spansion GL512P10FF1R1 512 Mbit NOR flash IC holding everything
File:Ge flashpad main pcb closeup 8.jpg|24LC256I 32k EEPROM for storing the accelerometer events
</gallery>

==Main test py script: Usage and Parameters==

current iteration found here: https://pastebin.com/vEfAresk

flashpad_acquire.py is a single file Python 3 tool that speaks the FlashPad
URP/PDAP protocol over UDP. It implements discovery, the control handshake,
script download and execution, sensor readout, full data backup, and the host
registration (pairing) write. It requires only the Python standard library.

===Default network configuration===

These defaults match the values in ConnectionPoint.cfg and can be overridden on
the command line.

{| class="wikitable"
!Setting!!Default!!Meaning
|-
|Detector IP||192.168.1.30||the panel; listens for all commands on UDP 8100
|-
|Host IP||192.168.1.1||this machine, announced in SYSTEM_STARTUP
|-
|Detector port||8100||where commands are sent
|-
|Host command port||5550||where the detector returns protocol replies
|-
|Host image port||6660||where pixel data would stream
|-
|Discovery port||4500||where the detector sends its beacons
|}

===Connection and general options===

{| class="wikitable"
!Option!!Default!!Effect
|-
| --detector-ip IP||192.168.1.30||detector address
|-
| --host-ip IP||192.168.1.1||host address sent in SYSTEM_STARTUP
|-
| --output-dir DIR||.||where raw images are written
|-
| --timeout SECONDS||5.0||UDP receive timeout
|-
| --exec-timeout SECONDS||60||how long to wait for EXECUTION_COMPLETE
|-
| --skip-discovery||off||send SYSTEM_STARTUP once and proceed, skipping the discovery loop
|-
| --quiet||off||suppress the verbose per packet log
|}

===Read and diagnostic modes (non destructive)===

These only read from the detector. None of them write anything.

{| class="wikitable"
!Option!!What it does!!What to expect
|-
| --sensors||Reads the full 32 entry sensor table using cmd 0x7902 (converted) and 0x7900 (raw), side by side.||A decoded table of supply rails in volts. Temperatures show as railed. Unimplemented sensors (accelerometer DEM id, battery, grid) are flagged as stale.
|-
| --no-roe-init||With --sensors, skips the Script7 ROE init before reading.||Slightly faster sensor read, marginally less reliable.
|-
| --probe-data||Reads DetectorInfo, the HostList (registration state), and cal results via the upload protocol (cmd 0x13/0x14).||A hexdump and text decode of each. Shows whether any host is registered and which HostId the detector expects.
|-
| --backup [DIR]||Sweeps all upload IDs 0x00 to 0xFF and saves every readable blob to DIR/detector_backup_timestamp/.||A manifest plus one .bin per readable ID, including the full 64 MB flash image and the calibration maps. Do this before any write. Large blobs take a few minutes each.
|-
| --backup-range LO-HI||Limits the --backup sweep, for example 0x40-0xA0.||Faster, partial backup.
|-
| --dump-scripts||Prints the wire bytes of all built scripts as hex and exits.||No network activity; useful for inspecting the script encoding.
|-
| --listen||Passively listens on the host command port for 30 seconds.||Prints any packets the detector sends; useful for watching beacons.
|}

===Acquisition modes===

The default invocation (no mode flag) runs a standard acquisition, which
requires an actual X-ray exposure to complete.

{| class="wikitable"
!Option!!What it does!!What to expect
|-
|(no flag)||Standard acquisition (Script 0).||Needs an X-ray exposure to reach EXECUTION_COMPLETE.
|-
| --dark||Runs the dark/offset acquisition (Script 1) before the standard one.||Two acquisitions; the dark one needs no X-ray.
|-
| --dark-only||Runs only the dark acquisition (Script 1).||Completes in a few seconds with no X-ray. The detector acquires and holds an 8 buffer image. Best way to test the full flow.
|-
| --no-standby||Omits the Script 8 standby loop.||Use if the standby loop blocks acquisition.
|-
| --two-exec||Executes Script 7 alone, waits, then Script 1. Only with --dark-only.||Tests the two stage execution hypothesis.
|-
| --parallel||Answers the detector status query (0x30000) with the cmd 0x99 ParallelImageTransfer reply instead of cmd 9.||Experiment to see if the parallel reply triggers a pixel push. (Result so far: it does not.)
|-
| --sweep-acq||Sweeps the dark acquisition across type_mode and transfer_mode values, watching for a 0x0F pixel push.||Non destructive experiment; reports which combination, if any, makes the detector stream.
|-
| --preview||Single dark acquisition on the preview path (transfer_mode 2, 4 buffer image). Watches port 6660 for a push.||One clean connection; run a packet capture on the detector address in parallel.
|}

Note: at present the detector acquires and holds an image but does not push the
0x0F pixel frames. The acquisition modes complete the handshake and acquisition,
but image streaming is still being investigated.

===Registration and write operations===

These can write to the detector's flash. Every write is a dry run by default and
only takes effect when --commit is added. Always run --backup first.

{| class="wikitable"
!Option!!What it does
|-
| --register-self||Adds this host to the detector HostList and sets it as the primary host, so the detector should stream images to it. Appends an entry, sets IndexToPrimaryHost, recomputes the CRC, and writes via id 0x71. Dry run unless --commit.
|-
| --host-mac MAC||The MAC of the interface talking to the detector, used to derive this host's HostId for --register-self. Default 00:6f:00:01:0a:3a.
|-
| --smoke-test-write||Reads the HostList and writes back the identical bytes to validate the write and commit path without changing anything. Dry run unless --commit.
|-
| --restore-hostlist FILE||Writes a saved HostList blob (for example detector_backup_*/upload_0x71_504.bin) back to the detector. This is the undo button. Dry run unless --commit.
|-
| --commit||Arms the actual flash write for the operations above. Without it they only print what they would do. This writes the detector's flash and is irreversible at the chip level, although the HostList region can be restored from a backup.
|}

===Typical workflow===

#Read the current state: <code>python flashpad_acquire.py --probe-data</code>
#Make a full backup: <code>python flashpad_acquire.py --backup</code>
#Check sensors and power rails: <code>python flashpad_acquire.py --sensors</code>
#Dry run the registration: <code>python flashpad_acquire.py --register-self --host-mac YOUR:MAC</code>
#When satisfied, commit it: add <code>--commit</code>
#If needed, undo: <code>python flashpad_acquire.py --restore-hostlist detector_backup_*/upload_0x71_504.bin --commit</code>

==Known Dead Ends==

Things that were tried and did not work or led nowhere:

;0xBEEF (48879) as reply port
:This was a bug in early test scripts. The port has no meaning in the protocol. Use 5550.

;CmdFlag=1 as data packet flag
:Early scripts had the URP fields swapped, setting CmdFlag=1 on data packets. The detector ignores all PDAP content in these packets. Power cycle the detector if this happened, it may retain stale port state.

;Image data on alternate ports
:Tried listening on 48879, 6660, 5550, 8100, 1050, 6661, 9999, 4444, 7000, 7001, 9001. Nothing arrived on any of them.

;PORT_SETUP byte order (big-endian)
:Current implementation sends port fields as big-endian. If the detector reads them as little-endian it computes port 44565 and 1050 instead of 5550 and 6660, which would explain why no image data arrives. Not yet confirmed.

;Image data streaming automatically after EXECUTE_SCRIPT
:Frames may not push during execution at all. The detector may require an explicit IMAGE_RETRIVAL_REQUEST (cmd_type=0x41) and IMAGE_RETRIVAL (cmd_type=0x98) after the 0x30000 notification before it streams anything. Not yet tested.

GE Medical Flashpad Digital Xray Detector

2026-06-11T12:13:36Z

Gamerpaddy: added the main script to read & set data

==Overview==
{{Note|UNFINISHED Project, it was not yet possible to retrieve a exposure or dark frame in my testing, further investigation needed. any help is appreciated on recessim discord.}}

The '''GE Flashpad''' is a Digital Radiography image sensor from approximately 2010, originally used in the '''GE Optima 220AMX''' mobile X-ray unit. It was designed to replace analog film in radiology, dramatically reducing image acquisition time from hours to seconds.
[[File:GE Flashpad.jpg|thumb|Flashpad with Anti-Scatter grid (left), manual and recovery dvd for 220amx and tether cord (right)]]
Due to its high original cost and specialized application, used units occasionally appear on professional B2B marketplaces in the $15,000–$50,000 range. On eBay, prices typically fall between $1,500 and $5,000, though units at this price point are often in poor condition and may fail the built-in self-test or not function at all.

{{Note|All findings on this page are based on a single unit and the time spent working on it. Information is subject to speculation and may not be fully accurate.}}

{{Note|AI assistance was used in writing this page for improved formatting and readability, as well as in the process of finding information, testing, and analyzing firmware dumps and backups.}}

==Purpose and Motivation==

This project documents the reverse engineering of the GE FlashPad wireless
digital radiography detector used with the Optima XR200/220 AMX mobile X-ray
system, with the goal of freeing these detectors for independent use.
[[File:Xray capture pcb.png|thumb|Xray capture of a PCB for Reverse Engineering]]
Large numbers of these detectors reach the used market, but each one is
cryptographically and administratively bound to its original Optima 220 AMX
console. Once separated from that console, or once the console is
decommissioned, the detector is effectively useless even though the hardware is
fully functional. The aim of this work is to remove that artificial barrier so
that a standalone FlashPad can be paired, configured, and read out by any host,
without the half million dollar console it was sold with.

The intended beneficiaries are:

*Hobbyists, researchers, and engineers who want a high quality flat panel detector for their own imaging projects.
*Veterinary practices, which can put surplus human grade detectors to good use at a fraction of the cost of new equipment.
*Clinics and hospitals in countries and regions where a complete commercial system is unaffordable, allowing serviceable detectors to keep providing diagnostic imaging instead of being scrapped.

[[File:Xray current clamp multimeter.png|thumb|xray of a current clamp multimeter]]
This is done for human good. Every detector returned to service is one less
piece of working medical hardware sent to landfill, and potentially one more
place that can offer X-ray imaging where it otherwise could not.

All files, findings, protocol documentation, and tools produced by this project
are public and open source, so that anyone can study, reproduce, and build on
the work.

==Technical Specifications==
[[File:Ge flashpad tether cable pinout diagram.png|thumb|Pinout Diagram of the Tether cable]]
[[File:Ge flashpad tether wiring for ethernet cable.jpg|thumb|Professional Tether wiring to attach a Ethernet Cable and 12V socket to it.]]
The Flashpad uses a '''~40 × 40 cm CsI scintillator''' bonded to a [[Thin-film transistor|TFT]] photodetector array mounted on glass. The assembly is highly sensitive to shock and impact damage. See section [[#Reading the Drop and Shock Event Log|drop and shock event log]]

{| class="wikitable"
|-
!Parameter!!Value
|-
|Resolution||2048 × 2048 px
|-
|Bit depth||16-bit per pixel
|-
|Spatial resolution||Up to 5 lp/mm (theoretical)
|-
|Scintillator material||Caesium iodide (CsI)
|-
|Detector type||TFT photodetector array (glass substrate)
|-
|Panel size||~40 × 40 cm
|}

The theoretical 5 lp/mm spatial resolution is primarily limited in practice by the focal spot size of the X-ray source. Use of an anti-scatter grid can improve effective resolution.

===Status of Reverse Engineering===

{| class="wikitable"
|-
!What!!Status
|-
|Connect, beacon, ACK||Works
|-
|PORT_SETUP||Works
|-
|SIGNATURE_REQUEST / serial number readout||Works
|-
|Script download (Scripts 7, 8, 1)||Works
|-
|EXECUTE_SCRIPT||Works
|-
|EXECUTION_COMPLETE (dark acquisition)||Works but without image readout its speculation.
|-
|EXECUTION_COMPLETE (standard acquisition)||Needs real X-ray trigger to test
|-
|Image data on port 6660||Does not work yet, under investigation. Will not send Imagedata...
|}

==Hardware Features==

===Shock logging===
The unit contains an internal accelerometer that logs significant shock events — but only when a battery is inserted. As there is no backup battery, shock events occurring while unpowered are not recorded.

===Wireless connectivity===
Some units include a UWB transmitter for Wireless USB; others may be equipped with a Wi-Fi module instead. The detector can also be operated over the tethered connection alone.

===Ethernet interface===
There is a 100MBit Ethernet interface trough the Tether Cable which can be tapped and used for Communication.
Exposed metal contacts on the bottom connector are isolated via relays by default. Enabling Gigabit Ethernet connectivity requires shorting or driving two specific pins. This has not been investigated further at this time.

==Communication Protocol==

This section documents the URP/PDAP protocol used by the GE Flashpad (codename '''Apollo''') to communicate with a host over Ethernet. All findings are based on live capture tests, configuration files, and reverse-engineering of the GE SuperBee software stack.

{{Note|All findings are based on a single unit and may not be fully accurate.}}

===Network Setup===

All findings were over Ethernet only, no UWB or WIFI has been used.
Default detector IP is <code>192.168.1.30</code>. Set your host to a static IP in the same subnet, <code>192.168.1.1</code> works fine.

At first by sending random bytes over Python it answered to port 48879 (0xBEEF), which seems to be either the default port or set by Python.
After SYSTEM_SETUP it got set to 5550.

{| class="wikitable"
|-
!Role!!IP!!Port!!Direction
|-
|All commands: host -> detector||192.168.1.30||'''8100''' (UDP)||Host sends here
|-
|Discovery beacons: detector -> host||-||'''4500''' (UDP)||Detector sends here initially
|-
|Protocol replies: detector -> host||-||'''5550''' (UDP)||Detector sends here after setup
|-
|Image pixel data: detector -> host||-||'''6660''' (UDP)||Detector streams frames here
|}

In practice you can listen on port '''5550''' for everything (beacons and replies) by advertising that port in both <code>SYSTEM_STARTUP</code> and <code>PORT_SETUP</code>. The detector sends to whichever port was most recently configured.

===Protocol Layers===

Two layers, carried over UDP:

;URP (Unified Registration Protocol)
:8-byte wrapper on every packet. Handles sequencing and acknowledgement.

;PDAP (Proprietary Detector Access Protocol)
:The actual command layer, present inside URP packets when <code>CmdFlag = 0</code>.

Every UDP packet starts with a URP header:

<pre>
[SeqId : 4 bytes LE] [CmdFlag : 4 bytes LE]
</pre>

*<code>CmdFlag = 0</code> -- data packet, PDAP command follows.
*<code>CmdFlag = 1</code> -- bare ACK, no PDAP body. SeqId echoes the packet being acknowledged.

Both sides must ACK every data packet immediately. The detector silently drops packets with a SeqId it has already seen, so always increment SeqId for each new command.

When CmdFlag is 0, the PDAP header follows immediately:

<pre>
[cmd_type : 4 bytes LE] [payload_len : 4 bytes LE] [payload ...]
</pre>

===Connecting to the Detector===

The connection sequence is:

#Broadcast <code>SYSTEM_STARTUP</code> to tell the detector where to reply.
#The detector sends a <code>BEACON</code> back -- ACK it and sync your sequence counter.
#Send <code>PORT_SETUP</code> to configure the reply and image ports.
#Send <code>SIGNATURE_REQUEST</code> to read the detector identity (serial number, model, firmware, MAC).

====Step 1: SYSTEM_STARTUP====

Broadcast UDP to <code>192.168.1.255:8100</code>. Always uses <code>SeqId = 0</code>.

<pre>
URP : [00 00 00 00] SeqId = 0
[00 00 00 00] CmdFlag = 0
PDAP: [01 00 00 00] cmd_type = 1
[06 00 00 00] payload_len = 6
[15 AE] host reply port = 5550 (big-endian)
[C0 A8 01 01] host IP = 192.168.1.1 (network byte order)
</pre>

<syntaxhighlight lang="python">
import socket, struct

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
sock.bind(("0.0.0.0", 5550))

HOST_IP = "192.168.1.1"
DET_IP = "192.168.1.30"
HOST_PORT = 5550
IMG_PORT = 6660

def make_urp_packet(seq_id, pdap_bytes):
return struct.pack("<II", seq_id, 0) + pdap_bytes

pdap = struct.pack("<II", 1, 6) + struct.pack(">H", HOST_PORT) + socket.inet_aton(HOST_IP)
sock.sendto(make_urp_packet(0, pdap), ("192.168.1.255", 8100))
</syntaxhighlight>

====Step 2: Receiving the BEACON and ACKing====

The detector broadcasts a <code>BEACON</code> (cmd_type=1) roughly every 2 seconds. After sending SYSTEM_STARTUP you should get one quickly. Parse the detector SeqId from the URP header and ACK it:

<syntaxhighlight lang="python">
data, addr = sock.recvfrom(4096)
det_seq = struct.unpack_from("<I", data, 0)[0]

# send bare ACK
ack = struct.pack("<II", det_seq, 1)
sock.sendto(ack, (DET_IP, 8100))

# all subsequent commands start from here
host_seq = det_seq + 1
</syntaxhighlight>

====Step 3: PORT_SETUP====

Tells the detector which host ports to use for replies and image data.

<pre>
PDAP: [02 00 00 00] cmd_type = 2
[04 00 00 00] payload_len = 4
[15 AE] host cmd port = 5550 (big-endian)
[1A 04] host image port = 6660 (big-endian)
</pre>

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 2, 4) + struct.pack(">HH", HOST_PORT, IMG_PORT)
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1
# expect bare ACK from detector
</syntaxhighlight>

====Step 4: Reading the Serial Number (SIGNATURE_REQUEST)====

Empty command, the detector replies with a 54-byte payload containing its identity.

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 3, 0) # cmd_type=3, payload_len=0
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1

# reply is 70 bytes total: 8 URP + 8 PDAP header + 54 payload
data, _ = sock.recvfrom(4096)
payload = data[16:] # skip URP (8) + PDAP header (8)

mac = payload[0:6]
serial = payload[22:34].rstrip(b'\x00 ').decode()
model = payload[34:46].rstrip(b'\x00 ').decode()
fw_bytes = payload[46:54]
firmware = ".".join(str(b) for b in fw_bytes)

print(f"MAC: {':'.join(f'{b:02X}' for b in mac)}")
print(f"Serial: {serial}")
print(f"Model: {model}")
print(f"Firmware: {firmware}")
</syntaxhighlight>

Expected output:
<pre>
MAC: 40:F4:A0:00:78:4D
Serial: UA45829-7
Model: 5340000-7
Firmware: 1.6.0.4.2.0.1.3
</pre>

===Running an Acquisition===

After the connection sequence above, download scripts to the detector and then execute them.

====ROE Initialisation (Script 7)====

Always run this first. It initialises the readout electronics and takes about 4-5 seconds. The detector sends host event ID 17 when done.

====Dark / Offset Acquisition (Script 1)====

No X-ray source required. Runs a dark-field exposure for offset calibration. Use this to verify the acquisition pipeline without a generator.

====Standard Acquisition (Script 0)====

Requires an actual X-ray exposure. <code>EXECUTION_COMPLETE</code> will '''not''' arrive without a real X-ray trigger.

====Sequence Overview====

<pre>
HOST DETECTOR
| |
|-- SYSTEM_STARTUP (broadcast) ----------->|
|<- bare ACK -------------------------------|
|<- BEACON (cmd_type=1) --------------------|
|-- bare ACK ------------------------------>|
| |
|-- PORT_SETUP (cmd_type=2) -------------->|
|<- bare ACK -------------------------------|
| |
|-- SIGNATURE_REQUEST (cmd_type=3) ------->|
|<- SIGNATURE_REPLY (54 bytes) -------------|
|-- bare ACK ------------------------------>|
| |
|-- GENERIC_SCRIPT Script7 (ROE init) ---->|
|<- bare ACK or SCRIPT_DOWNLOAD_REPLY ------|
| |
|-- GENERIC_SCRIPT Script1 (dark acq) ---->|
|<- bare ACK -------------------------------|
| |
|-- EXECUTE_SCRIPT (cmd_type=6) ---------->|
|<- bare ACK -------------------------------|
|<- EXECUTE_SCRIPT_REPLY (~230ms) ----------|
|-- bare ACK ------------------------------>|
|<- DETECTOR_STATE_NOTIFY (~890ms) ---------| state_id=17
|-- bare ACK ------------------------------>|
| |
|<- EXECUTION_COMPLETE (0x10000) -----------|
|-- bare ACK ------------------------------>|
| |
|<- IMAGE_XFER_STATUS_QUERY (0x30000) ------|
|-- bare ACK ------------------------------>|
|-- IMAGE_XFER_STATUS_REPLY (cmd_type=9) ->| numMissed=0
|<- bare ACK -------------------------------|
</pre>

===Sequence Counter Rules===

*<code>SYSTEM_STARTUP</code> always uses <code>SeqId = 0</code>.
*After the first beacon, set host SeqId to beacon_SeqId + 1.
*Increment SeqId by 1 for every new data packet (CmdFlag=0).
*Bare ACKs echo the SeqId of the packet being acknowledged and do not consume a SeqId.
*The detector silently drops any packet with a SeqId it has already processed, so never reuse one.

==Sensor Readout and Host Registration==

This section documents the reverse engineered sensor telemetry interface and the
host registration (pairing) mechanism of the GE Optima XR200/220 AMX FlashPad
(URP detector, SuperBee, FW 1.6.0.4.2.0.1.3). All commands are PDAP over UDP to
the detector at port 8100; replies return to the host command port.

===Sensor Readout===

The detector exposes an analog sensor interface (the DEM, Detector Environment
Monitor) that is independent of the image transfer path and works regardless of
acquisition state.

====Commands====

{| class="wikitable"
!cmd_type!!Meaning!!Request payload!!Reply payload
|-
|0x7900||Raw sensor read||[sensorId:4 LE]||[value:4 LE] (12 bit ADC count)
|-
|0x7902||Converted sensor read||[sensorId:4 LE]||[value:4 LE] (engineering units, signed)
|-
|0x7904||Detailed / radio||[selector:4 LE]||[value:4 LE]
|}

Note: cmd 0x7902 IS supported on this firmware and returns calibrated
engineering units (millivolts for the supply rails, signed; 0.1 degree C for
temperatures). Earlier documentation that marked 0x7902 as unsupported is
incorrect. The host side conversion coefficients are not required; the detector
performs the conversion internally.

The full sensor map (name, sensorId) was recovered from the detector's own
[Sensor] configuration table, read back over the upload interface (see the
Registration section for the read protocol).

====Power rails (live readings)====

All supply rails read correctly via 0x7902 and are within normal range for a
flat panel detector. Representative readings:

{| class="wikitable"
!Sensor!!sensorId!!Converted!!Value
|-
|DCIN_RAW||10||12100 mV||+12.10 V (main DC input)
|-
|LCORE_UNREG||11||1724 mV||+1.72 V
|-
|LPANA_UNREG||12||5776 mV||+5.78 V
|-
|LNANA_UNREG||13||-5801 mV||-5.80 V
|-
|SCAN_VCC||14||5086 mV||+5.09 V (gate driver)
|-
|P5V_REF||16||5025 mV||+5.03 V (5 V reference)
|-
|V_ON||17||11085 mV||+11.09 V (TFT gate on)
|-
|V_OFF||18||-12378 mV||-12.38 V (TFT gate off)
|-
|V_COMMON||19||-9385 mV||-9.39 V
|-
|3V3||29||3177 mV||+3.18 V (3.3 V logic)
|-
|VCC_UNREG||37||3399 mV||+3.40 V
|-
|PARCPREG||38||3768 mV||+3.77 V (ARC preamp +)
|-
|NARCPREG||39||-3732 mV||-3.73 V (ARC preamp -)
|-
|PANA_UNREG||45||18352 mV||+18.35 V (photodiode bias +)
|-
|NANA_UNREG||46||-19251 mV||-19.25 V (photodiode bias -)
|}

Switched rails that are inactive while the panel is idle (PARCVA_U,
P5VA_SW, N5VA_SW, FGATE_NVC_L, FGATE_PVC_L, etc.) read at or near zero.

====Known limitations====

*'''Temperatures''' (Temp_Surface, sensorId 336; Temp_Panel, sensorId 352): the raw 0x7900 read rails at 0x3FF (1023, the ADC maximum), indicating an open thermistor path while the panel is idle. This is a hardware/state condition, not a command problem, and the temperature is not readable from the host in this state.
*'''Unimplemented sensors''': sensorIds 70 (Accelerator), 78 (Gravity), and 256 to 259 (Battery status, name, life, capacity), and 272 (Grid status) are not implemented on this DEM. The detector returns the leftover conversion register contents (a duplicate of a previously read sensor) rather than a real value, so these rows must be discarded.
*'''Accelerometer''': functional through a separate addressing scheme using raw cmd 0x7900 with selectors 0x42 (X), 0x43 (Y), 0x44 (Z), returning 12 bit per axis counts.

===Host Registration (Pairing)===

URP stands for Unified Registration Protocol. The detector maintains a host
list in its internal NOR flash. Image data is delivered only to a registered
primary host, so registration is a prerequisite for image transfer.

====Host identity (MAC and HostId)====

Each host is identified by a 16 character HostId derived deterministically from
the host's eth0 MAC address. The derivation (from the vendor generateHostId
script) is:

#Take the eth0 MAC, remove the colon separators, convert to upper case (12 hex characters).
#Prepend the last 4 characters to the full 12 characters.
#The result is 16 hex characters.

Example: MAC 00:6f:00:01:0a:3a becomes 006F00010A3A, then the last four (0A3A)
are prepended, giving HostId 0A3A006F00010A3A.

====HostList structure====

The host list is stored in flash at offset 0x940000 and can be read back over
the upload interface as data category 0x71. Layout:

Offset Size Field
0x00 16 DetectorDeviceId (ASCII)
0x10 16 ConnectionSecretKey (ASCII; "XXXXXXXXXXXXXXXX" when unset)
0x20 16 DetectorName (ASCII)
0x30 16 DetectorCode (ASCII)
0x40 2 CurrentNumberOfHosts (uint16 LE)
0x42 2 IndexToPrimaryHost (uint16 LE; 0xFFFF = none)
0x44 144*N Host entries, 144 bytes each:
+0x00 16 HostId (ASCII)
+0x10 .. host name / department string
+0x50 .. location string
... 4 CRC (big endian; see below)

====HostList from the unit under test====

Detector: MAC 40:F4:A0:00:78:4D, serial UA45829-7, model 5340000-7,
firmware 1.6.0.4.2.0.1.3. DetectorName starShape_green. ConnectionSecretKey
unset. CurrentNumberOfHosts = 3, IndexToPrimaryHost = 0xFFFF (no primary host).

{| class="wikitable"
!Index!!HostId!!Derived MAC!!Name
|-
|0||2C6400045FB42C64||00:04:5F:B4:2C:64||Haus 207 / ITS
|-
|1||B044E8393512B044||E8:39:35:12:B0:44||Not Initialized
|-
|2||5CF800045FB15CF8||00:04:5F:B1:5C:F8||Not_Initialized
|}

The unit is therefore not factory fresh; it carries registrations from a prior
deployment, but no primary host is currently designated.

====Checksum (CRC)====

The HostList (and other flash data blobs) are protected by a 4 byte trailing
CRC. Parameters:

*Polynomial: 0x04C11DB7
*Initial value: 0
*MSB first, augmented message style (the data bit is shifted into the LSB; no input or output reflection; no final XOR)
*Stored big endian

To generate: compute the CRC over the data followed by four zero bytes, then
append the result big endian. Verification: the CRC over (data plus stored CRC)
equals zero.

def crc(data, poly=0x04C11DB7, init=0):
c = init
for byte in data:
for bit in (0x80,0x40,0x20,0x10,0x08,0x04,0x02,0x01):
msb = c & 0x80000000
c = (c << 1) & 0xFFFFFFFF
if byte & bit: c |= 1
if msb: c ^= poly
return c
# trailer = crc(data + b"\x00\x00\x00\x00"), stored big endian

====Read and write transport====

Data blobs (including the HostList) are moved with a configure / buffer /
finalize sequence.

Read (upload, detector to host), non destructive:

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x13||[uploadId:4 LE]||[status:1][totalSize:4 LE]
|-
|Buffer||0x14||[bufId:4 LE][numBytes:4 LE]||[bufId:4 LE][numBytes:4 LE][data]
|}

Write (download, host to detector), persistent (writes flash):

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x0E||[downloadId:4 LE][totalSize:4 LE]||[status:1]
|-
|Buffer||0x0F||[bufId:4 LE][numBytes:4 LE][data]||[status:1][reserved:4]
|-
|Commit||0x10||(empty)||[status:1]
|}

bufId is a zero based chunk index. The HostList uses id 0x71 for both read and
write. The commit command (0x10) reuses the firmware flash path, so a malformed
download can corrupt flash; the operation is irreversible on this hardware.

====Registering a new host====

To register a host and make it the image destination, read the current HostList
(0x71), append a 144 byte entry carrying the new HostId, increment
CurrentNumberOfHosts, set IndexToPrimaryHost to the new entry's index,
recompute the trailing CRC, and write the blob back via the download sequence
(0x0E / 0x0F / 0x10).

===Reading the Drop and Shock Event Log===

The detector contains an accelerometer based shock watchdog that records drop
and impact events into non volatile memory. This log is useful when evaluating a
used unit, since it reveals how many serious shocks the panel has survived and
when. The same data is held both in the main flash (read over the network) and
in the small onboard EEPROM on the detector PCB.

====How to read it====

The shock log is exposed as data category 0x72 on the upload (read) interface.
It is retrieved with the standard non destructive configure and buffer sequence
(cmd 0x13 to configure, cmd 0x14 to pull the chunks). On the unit under test the
blob is 3001 bytes of plain text in the GE .dyn configuration format, so no
decoding is required beyond reading it as ASCII.

The same records are mirrored in binary form in the onboard 24LC256 EEPROM
(32 KB I2C part) for anyone reading the hardware directly.

====Example output====

The following is the actual log read from detector serial UA45829-7. The file
has two parts: a list of individual events (DetectorShockEvents) and a summary
block (DetectorShockData). Each event carries a record key, a severity, a
timestamp, and the peak acceleration on each axis. Two representative records:

<DetectorShockEvents>
[149266438700135]
Severity.Type = String
Severity.Val = Serious
TimeStamp.Type = String
TimeStamp.Val = 2017-4-20,6:59:47
ValidTime.Type = Number
ValidTime.Val = 0
VibrationX.Type = Number
VibrationX.Val = 0
VibrationY.Type = Number
VibrationY.Val = 0
VibrationZ.Type = Number
VibrationZ.Val = 135

[1592113924-1720-113]
Severity.Val = Serious
TimeStamp.Val = 2020-6-14,7:52:4
VibrationX.Val = -172
VibrationY.Val = 0
VibrationZ.Val = -113

The summary block at the end lists the totals and an index of all event keys:

[DetectorShockData]
LastKnownGoodTime.Val = 2024-4-4,6:53:59
NumberOfL3Events.Val = 0
NumberOfL5Events.Val = 7
ShockDataTimeList.Val = { 1643260890-1320-119, 163626503500-123,
160818190500-101, 160524243000170, 1592113924-1720-113,
157804584600183, 149266438700135 }

====Interpreting the records====

The record key encodes the event time and the peak axis values (an epoch style
timestamp followed by the concatenated vibration readings), so it is unique per
event. The VibrationX, VibrationY, and VibrationZ values are signed peak
acceleration counts on each axis. Severity is reported as Serious for all
logged events on this unit, which corresponds to the L5 (highest) severity class
counted in the summary.

The seven recorded events for this detector:

{| class="wikitable"
!Date and time!!VibrationX!!VibrationY!!VibrationZ
|-
|2017-04-20 06:59:47||0||0||135
|-
|2020-01-03 11:04:06||0||0||183
|-
|2020-06-14 07:52:04||-172||0||-113
|-
|2020-11-13 05:40:30||0||0||170
|-
|2020-12-17 06:11:45||0||0||-101
|-
|2021-11-07 07:03:55||0||0||-123
|-
|2022-01-27 06:21:30||-132||0||-119
|}

====Reading the summary fields====

{| class="wikitable"
!Field!!Meaning
|-
|LastKnownGoodTime||Timestamp of the last successful self check (here 2024-04-04), the most recent point at which the detector was known to be operating normally
|-
|NumberOfL3Events||Count of lower severity (L3) shock events; zero on this unit
|-
|NumberOfL5Events||Count of high severity (L5) shock events; seven on this unit, matching the seven records above
|-
|ShockDataTimeList||Index of all stored event keys, newest first
|}

On this example the panel logged seven serious impacts over roughly five years
of field use and last reported a good self check in April 2024.

==FlashPad Detector: Internal Flash Dump and Data Files==

This section documents how the full contents of the detector's internal flash
were extracted over the network and what each recovered file contains. The
detector under test is a GE Optima XR200/220 AMX FlashPad (URP detector,
serial UA45829-7, MAC 40:F4:A0:00:78:4D, firmware 1.6.0.4.2.0.1.3).

===Background===

The detector's main storage is a Spansion/Cypress S29GL512P (marked
GL512P10FFCR2), a 512 Mbit (64 MB) parallel NOR flash. A direct chip read
requires bus access or desoldering and a programmer. However, the detector
firmware exposes its stored data blobs, including a full image of the flash,
through the read (upload) side of the data transport protocol. This makes a
complete, byte exact dump possible over UDP with no physical access.

===Extraction method===

The upload interface is the read counterpart of the firmware download path and
is non destructive (it only reports and returns data; nothing is written).
Each data category is identified by an 8 bit upload ID:

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x13||[uploadId:4 LE]||[status:1][totalSize:4 LE]
|-
|Buffer||0x14||[bufId:4 LE][numBytes:4 LE]||[bufId:4 LE][numBytes:4 LE][data]
|}

A configure request returns status 0 and a total size for a valid ID, or a non
zero status for an unsupported ID. The dump tool sweeps all IDs from 0x00 to
0xFF, and for every readable ID it pulls the full blob in fixed size chunks
(bufId is a zero based chunk index) and writes it to a file. The 64 MB flash
image transfers as 65536 chunks of 1024 bytes.

===Recovered files===

A sweep of the unit returned 18 readable blobs:

{| class="wikitable"
!Upload ID!!Size (bytes)!!Contents
|-
|0xFD||67108864||Full 64 MB NOR flash image
|-
|0xFF||16777216||16 MB region (firmware / FPGA mirror or image buffer)
|-
|0xFE||524288||Bootloader (512 KB; SPI loader, Nios reset code)
|-
|0x10||6815783||Calibration map, dose level 1
|-
|0x11||6815783||Calibration map, dose level 2
|-
|0x12||6815783||Calibration map, dose level 3
|-
|0x06||49254||Table referencing conditioner/generator serial UA2010-8U005
|-
|0x50||19938||Per mode calibration coefficients
|-
|0x51||19582||Per mode calibration coefficients
|-
|0x07||12187||Sensor conversion table (text; see Sensor Readout)
|-
|0x72||3001||Shock / drop event log (text)
|-
|0x0E||624||Panel geometry / configuration (binary)
|-
|0x71||504||Host list / registration record (see Host Registration)
|-
|0x0F||233||Host to detector compatibility table (text)
|-
|0x08||62||Serial and model strings
|-
|0x0A||48||Manufacturing codes
|-
|0x52||30||Serial string
|-
|0x0B||24||Small marker / identifier
|}

===Flash image layout (upload ID 0xFD)===

A block scan of the 64 MB image shows the following regions:

{| class="wikitable"
!Range!!Contents
|-
|0x000000 to 0x800000||Firmware and FPGA configuration
|-
|0x800000 to 0x940000||Sparse configuration area
|-
|0x940000||Host list / registration record (matches upload ID 0x71)
|-
|0x1000000 to 0x2800000||Calibration and image data (16 to 40 MB)
|-
|0x2800000 to 0x4000000||Erased / unused (40 to 64 MB)
|}

The host list strings (the DetectorName starShape_green, the registered host
name Haus 207 / ITS, and the unset ConnectionSecretKey placeholder) appear at
0x940000, confirming that the 504 byte 0x71 read maps to this flash region.

===Notes on individual files===

*'''0x07 (sensor table)''': plain text, header DetectorSerialNumber = UA45829-7, revision 1.2. Lists every sensor by name, command (0x7902), and sensorId. Also carries panel geometry in its [Common] section: 16 bit depth, 2048 by 2048 pixels, active area from (12, 12) to (2035, 2035), pixel pitch 0.2 mm, corner radius 1416.8, panel saturation 150.
*'''0x10, 0x11, 0x12 (calibration maps)''': three distinct blobs of identical size, corresponding to the low, medium, and high dose calibration sets. Each begins with the firmware version and serial (header bytes 01 06 00 04 02 00 01 03 followed by the serial). Required to apply gain and offset correction to raw images.
*'''0xFE (bootloader)''': contains the strings spi_load.S and ../../boot and Nios II reset vector code.
*'''0x72 (shock log)''': text records of drop / vibration events with timestamps and per axis values; the same data is mirrored in the detector's small onboard EEPROM.
*'''0x06''': references a different serial, UA2010-8U005, likely the conditioner or generator board rather than the panel.

===Significance===

The complete flash image and all calibration data are recoverable over the
network without opening the detector, providing a full byte exact backup of the
unit before any write operation. The calibration maps are needed for image
correction, and the firmware image (the live, deployed build) is more complete
than the partial firmware files shipped on the recovery media.

== Teardown / Internal Pictures / Hardware analysis ==

<gallery mode="packed" heights="200">
File:GE Flashpad under the hood.jpg|the Carbon fiber sleeve is held by 9 screws and can taken off without force.
File:Ge flashpad powersupply pcb in handle.jpg|Power supply PCB
File:Ge flashpad uwb board pcb.jpg|UWB PCB for Wireless USB using a RTU2705
File:Ge flashpad uwb pcb backside.jpg|Backside of UWB PCB
File:Ge flashpad power supply pcb backside.jpg|Backside of Power supply PCB
File:Ge flashpad main pcb closeup1.jpg|Main area of the PCB with its Altera Cyclone 3 FPGA
File:Ge flashpad main pcb closeup2.jpg|AD7892 is a 600ksps 12bit ADC, SN74LVC8T245 a 8bit bus transceiver and DG9408EDN a 8ch MUX
File:Ge flashpad bottom connector ethernet isolation pcb.jpg|Isolation PCB for bottom connector
File:Ge flashpad main pcb powersupply section.jpg|Powersupply section for FPGA and ROIC
File:Ge_flashpad_main_pcb_closeup_3.jpg|AD9764AR 14-Bit, 125 MSPS DAC and DS1682 integrated elapsed-time recorder
File:Ge flashpad main pcb closeup 4.jpg|Accelerometer is a 834-0500 500G 3 Axis unit, and TJ500AE SPDT gigabit LAN switch
File:Ge flashpad bottom connector.jpg|bottom connector for docking stand
File:Ge flashpad main pcb closeup 5.jpg|Ethernet transformers and ADM34 RS-485/RS-422 Transceiver
File:Ge flashpad main pcb closeup 6.jpg|Altera EPM570f100c5n CPLD
File:Ge flashpad main pcb closeup 7.jpg|Spansion GL512P10FF1R1 512 Mbit NOR flash IC holding everything
File:Ge flashpad main pcb closeup 8.jpg|24LC256I 32k EEPROM for storing the accelerometer events
</gallery>

== Main test py script: Usage and Parameters ==

current iteration found here: https://pastebin.com/vEfAresk

flashpad_acquire.py is a single file Python 3 tool that speaks the FlashPad
URP/PDAP protocol over UDP. It implements discovery, the control handshake,
script download and execution, sensor readout, full data backup, and the host
registration (pairing) write. It requires only the Python standard library.

=== Default network configuration ===

These defaults match the values in ConnectionPoint.cfg and can be overridden on
the command line.

{| class="wikitable"
! Setting !! Default !! Meaning
|-
| Detector IP || 192.168.1.30 || the panel; listens for all commands on UDP 8100
|-
| Host IP || 192.168.1.1 || this machine, announced in SYSTEM_STARTUP
|-
| Detector port || 8100 || where commands are sent
|-
| Host command port || 5550 || where the detector returns protocol replies
|-
| Host image port || 6660 || where pixel data would stream
|-
| Discovery port || 4500 || where the detector sends its beacons
|}

=== Connection and general options ===

{| class="wikitable"
! Option !! Default !! Effect
|-
| --detector-ip IP || 192.168.1.30 || detector address
|-
| --host-ip IP || 192.168.1.1 || host address sent in SYSTEM_STARTUP
|-
| --output-dir DIR || . || where raw images are written
|-
| --timeout SECONDS || 5.0 || UDP receive timeout
|-
| --exec-timeout SECONDS || 60 || how long to wait for EXECUTION_COMPLETE
|-
| --skip-discovery || off || send SYSTEM_STARTUP once and proceed, skipping the discovery loop
|-
| --quiet || off || suppress the verbose per packet log
|}

=== Read and diagnostic modes (non destructive) ===

These only read from the detector. None of them write anything.

{| class="wikitable"
! Option !! What it does !! What to expect
|-
| --sensors || Reads the full 32 entry sensor table using cmd 0x7902 (converted) and 0x7900 (raw), side by side. || A decoded table of supply rails in volts. Temperatures show as railed. Unimplemented sensors (accelerometer DEM id, battery, grid) are flagged as stale.
|-
| --no-roe-init || With --sensors, skips the Script7 ROE init before reading. || Slightly faster sensor read, marginally less reliable.
|-
| --probe-data || Reads DetectorInfo, the HostList (registration state), and cal results via the upload protocol (cmd 0x13/0x14). || A hexdump and text decode of each. Shows whether any host is registered and which HostId the detector expects.
|-
| --backup [DIR] || Sweeps all upload IDs 0x00 to 0xFF and saves every readable blob to DIR/detector_backup_timestamp/. || A manifest plus one .bin per readable ID, including the full 64 MB flash image and the calibration maps. Do this before any write. Large blobs take a few minutes each.
|-
| --backup-range LO-HI || Limits the --backup sweep, for example 0x40-0xA0. || Faster, partial backup.
|-
| --dump-scripts || Prints the wire bytes of all built scripts as hex and exits. || No network activity; useful for inspecting the script encoding.
|-
| --listen || Passively listens on the host command port for 30 seconds. || Prints any packets the detector sends; useful for watching beacons.
|}

=== Acquisition modes ===

The default invocation (no mode flag) runs a standard acquisition, which
requires an actual X-ray exposure to complete.

{| class="wikitable"
! Option !! What it does !! What to expect
|-
| (no flag) || Standard acquisition (Script 0). || Needs an X-ray exposure to reach EXECUTION_COMPLETE.
|-
| --dark || Runs the dark/offset acquisition (Script 1) before the standard one. || Two acquisitions; the dark one needs no X-ray.
|-
| --dark-only || Runs only the dark acquisition (Script 1). || Completes in a few seconds with no X-ray. The detector acquires and holds an 8 buffer image. Best way to test the full flow.
|-
| --no-standby || Omits the Script 8 standby loop. || Use if the standby loop blocks acquisition.
|-
| --two-exec || Executes Script 7 alone, waits, then Script 1. Only with --dark-only. || Tests the two stage execution hypothesis.
|-
| --parallel || Answers the detector status query (0x30000) with the cmd 0x99 ParallelImageTransfer reply instead of cmd 9. || Experiment to see if the parallel reply triggers a pixel push. (Result so far: it does not.)
|-
| --sweep-acq || Sweeps the dark acquisition across type_mode and transfer_mode values, watching for a 0x0F pixel push. || Non destructive experiment; reports which combination, if any, makes the detector stream.
|-
| --preview || Single dark acquisition on the preview path (transfer_mode 2, 4 buffer image). Watches port 6660 for a push. || One clean connection; run a packet capture on the detector address in parallel.
|}

Note: at present the detector acquires and holds an image but does not push the
0x0F pixel frames. The acquisition modes complete the handshake and acquisition,
but image streaming is still being investigated.

=== Registration and write operations ===

These can write to the detector's flash. Every write is a dry run by default and
only takes effect when --commit is added. Always run --backup first.

{| class="wikitable"
! Option !! What it does
|-
| --register-self || Adds this host to the detector HostList and sets it as the primary host, so the detector should stream images to it. Appends an entry, sets IndexToPrimaryHost, recomputes the CRC, and writes via id 0x71. Dry run unless --commit.
|-
| --host-mac MAC || The MAC of the interface talking to the detector, used to derive this host's HostId for --register-self. Default 00:6f:00:01:0a:3a.
|-
| --smoke-test-write || Reads the HostList and writes back the identical bytes to validate the write and commit path without changing anything. Dry run unless --commit.
|-
| --restore-hostlist FILE || Writes a saved HostList blob (for example detector_backup_*/upload_0x71_504.bin) back to the detector. This is the undo button. Dry run unless --commit.
|-
| --commit || Arms the actual flash write for the operations above. Without it they only print what they would do. This writes the detector's flash and is irreversible at the chip level, although the HostList region can be restored from a backup.
|}

=== Typical workflow ===

# Read the current state: <code>python flashpad_acquire.py --probe-data</code>
# Make a full backup: <code>python flashpad_acquire.py --backup</code>
# Check sensors and power rails: <code>python flashpad_acquire.py --sensors</code>
# Dry run the registration: <code>python flashpad_acquire.py --register-self --host-mac YOUR:MAC</code>
# When satisfied, commit it: add <code>--commit</code>
# If needed, undo: <code>python flashpad_acquire.py --restore-hostlist detector_backup_*/upload_0x71_504.bin --commit</code>

== Known Dead Ends ==

Things that were tried and did not work or led nowhere:

;0xBEEF (48879) as reply port
:This was a bug in early test scripts. The port has no meaning in the protocol. Use 5550.

;CmdFlag=1 as data packet flag
:Early scripts had the URP fields swapped, setting CmdFlag=1 on data packets. The detector ignores all PDAP content in these packets. Power cycle the detector if this happened, it may retain stale port state.

;Image data on alternate ports
:Tried listening on 48879, 6660, 5550, 8100, 1050, 6661, 9999, 4444, 7000, 7001, 9001. Nothing arrived on any of them.

;PORT_SETUP byte order (big-endian)
:Current implementation sends port fields as big-endian. If the detector reads them as little-endian it computes port 44565 and 1050 instead of 5550 and 6660, which would explain why no image data arrives. Not yet confirmed.

;Image data streaming automatically after EXECUTE_SCRIPT
:Frames may not push during execution at all. The detector may require an explicit IMAGE_RETRIVAL_REQUEST (cmd_type=0x41) and IMAGE_RETRIVAL (cmd_type=0x98) after the 0x30000 notification before it streams anything. Not yet tested.

GE Medical Flashpad Digital Xray Detector

2026-06-11T12:00:53Z

Gamerpaddy: /* FlashPad Detector: Internal Flash Dump and Data Files */

==Overview==

The '''GE Flashpad''' is a Digital Radiography image sensor from approximately 2010, originally used in the '''GE Optima 220AMX''' mobile X-ray unit. It was designed to replace analog film in radiology, dramatically reducing image acquisition time from hours to seconds.
[[File:GE Flashpad.jpg|thumb|Flashpad with Anti-Scatter grid (left), manual and recovery dvd for 220amx and tether cord (right)]]
Due to its high original cost and specialized application, used units occasionally appear on professional B2B marketplaces in the $15,000–$50,000 range. On eBay, prices typically fall between $1,500 and $5,000, though units at this price point are often in poor condition and may fail the built-in self-test or not function at all.

{{Note|All findings on this page are based on a single unit and the time spent working on it. Information is subject to speculation and may not be fully accurate.}}

{{Note|[[Artificial intelligence|AI]] assistance was used in writing this page for improved formatting and readability, as well as in the process of finding information, testing, and analyzing firmware dumps and backups.}}

==Purpose and Motivation==

This project documents the reverse engineering of the GE FlashPad wireless
digital radiography detector used with the Optima XR200/220 AMX mobile X-ray
system, with the goal of freeing these detectors for independent use.
[[File:Xray capture pcb.png|thumb|Xray capture of a PCB for Reverse Engineering]]
Large numbers of these detectors reach the used market, but each one is
cryptographically and administratively bound to its original Optima 220 AMX
console. Once separated from that console, or once the console is
decommissioned, the detector is effectively useless even though the hardware is
fully functional. The aim of this work is to remove that artificial barrier so
that a standalone FlashPad can be paired, configured, and read out by any host,
without the half million dollar console it was sold with.

The intended beneficiaries are:

*Hobbyists, researchers, and engineers who want a high quality flat panel detector for their own imaging projects.
*Veterinary practices, which can put surplus human grade detectors to good use at a fraction of the cost of new equipment.
*Clinics and hospitals in countries and regions where a complete commercial system is unaffordable, allowing serviceable detectors to keep providing diagnostic imaging instead of being scrapped.

[[File:Xray current clamp multimeter.png|thumb|xray of a current clamp multimeter]]
This is done for human good. Every detector returned to service is one less
piece of working medical hardware sent to landfill, and potentially one more
place that can offer X-ray imaging where it otherwise could not.

All files, findings, protocol documentation, and tools produced by this project
are public and open source, so that anyone can study, reproduce, and build on
the work.

==Technical Specifications==
[[File:Ge flashpad tether cable pinout diagram.png|thumb|Pinout Diagram of the Tether cable]]
[[File:Ge flashpad tether wiring for ethernet cable.jpg|thumb|Professional Tether wiring to attach a Ethernet Cable and 12V socket to it.]]
The Flashpad uses a '''~40 × 40 cm CsI scintillator''' bonded to a [[Thin-film transistor|TFT]] photodetector array mounted on glass. The assembly is highly sensitive to shock and impact damage. See section [[#Reading the Drop and Shock Event Log|drop and shock event log]]

{| class="wikitable"
|-
!Parameter!!Value
|-
|Resolution||2048 × 2048 px
|-
|Bit depth||16-bit per pixel
|-
|Spatial resolution||Up to 5 lp/mm (theoretical)
|-
|Scintillator material||Caesium iodide (CsI)
|-
|Detector type||TFT photodetector array (glass substrate)
|-
|Panel size||~40 × 40 cm
|}

The theoretical 5 lp/mm spatial resolution is primarily limited in practice by the focal spot size of the X-ray source. Use of an anti-scatter grid can improve effective resolution.

===Status of Reverse Engineering===

{| class="wikitable"
|-
!What!!Status
|-
|Connect, beacon, ACK||Works
|-
|PORT_SETUP||Works
|-
|SIGNATURE_REQUEST / serial number readout||Works
|-
|Script download (Scripts 7, 8, 1)||Works
|-
|EXECUTE_SCRIPT||Works
|-
|EXECUTION_COMPLETE (dark acquisition)||Works but without image readout its speculation.
|-
|EXECUTION_COMPLETE (standard acquisition)||Needs real X-ray trigger to test
|-
|Image data on port 6660||Does not work yet, under investigation. Will not send Imagedata...
|}

==Hardware Features==

===Shock logging===
The unit contains an internal accelerometer that logs significant shock events — but only when a battery is inserted. As there is no backup battery, shock events occurring while unpowered are not recorded.

===Wireless connectivity===
Some units include a UWB transmitter for Wireless USB; others may be equipped with a Wi-Fi module instead. The detector can also be operated over the tethered connection alone.

===Ethernet interface===
There is a 100MBit Ethernet interface trough the Tether Cable which can be tapped and used for Communication.
Exposed metal contacts on the bottom connector are isolated via relays by default. Enabling Gigabit Ethernet connectivity requires shorting or driving two specific pins. This has not been investigated further at this time.

==Communication Protocol==

This section documents the URP/PDAP protocol used by the GE Flashpad (codename '''Apollo''') to communicate with a host over Ethernet. All findings are based on live capture tests, configuration files, and reverse-engineering of the GE SuperBee software stack.

{{Note|All findings are based on a single unit and may not be fully accurate.}}

===Network Setup===

All findings were over Ethernet only, no UWB or WIFI has been used.
Default detector IP is <code>192.168.1.30</code>. Set your host to a static IP in the same subnet, <code>192.168.1.1</code> works fine.

At first by sending random bytes over Python it answered to port 48879 (0xBEEF), which seems to be either the default port or set by Python.
After SYSTEM_SETUP it got set to 5550.

{| class="wikitable"
|-
!Role!!IP!!Port!!Direction
|-
|All commands: host -> detector||192.168.1.30||'''8100''' (UDP)||Host sends here
|-
|Discovery beacons: detector -> host||-||'''4500''' (UDP)||Detector sends here initially
|-
|Protocol replies: detector -> host||-||'''5550''' (UDP)||Detector sends here after setup
|-
|Image pixel data: detector -> host||-||'''6660''' (UDP)||Detector streams frames here
|}

In practice you can listen on port '''5550''' for everything (beacons and replies) by advertising that port in both <code>SYSTEM_STARTUP</code> and <code>PORT_SETUP</code>. The detector sends to whichever port was most recently configured.

===Protocol Layers===

Two layers, carried over UDP:

;URP (Unified Registration Protocol)
:8-byte wrapper on every packet. Handles sequencing and acknowledgement.

;PDAP (Proprietary Detector Access Protocol)
:The actual command layer, present inside URP packets when <code>CmdFlag = 0</code>.

Every UDP packet starts with a URP header:

<pre>
[SeqId : 4 bytes LE] [CmdFlag : 4 bytes LE]
</pre>

*<code>CmdFlag = 0</code> -- data packet, PDAP command follows.
*<code>CmdFlag = 1</code> -- bare ACK, no PDAP body. SeqId echoes the packet being acknowledged.

Both sides must ACK every data packet immediately. The detector silently drops packets with a SeqId it has already seen, so always increment SeqId for each new command.

When CmdFlag is 0, the PDAP header follows immediately:

<pre>
[cmd_type : 4 bytes LE] [payload_len : 4 bytes LE] [payload ...]
</pre>

===Connecting to the Detector===

The connection sequence is:

#Broadcast <code>SYSTEM_STARTUP</code> to tell the detector where to reply.
#The detector sends a <code>BEACON</code> back -- ACK it and sync your sequence counter.
#Send <code>PORT_SETUP</code> to configure the reply and image ports.
#Send <code>SIGNATURE_REQUEST</code> to read the detector identity (serial number, model, firmware, MAC).

====Step 1: SYSTEM_STARTUP====

Broadcast UDP to <code>192.168.1.255:8100</code>. Always uses <code>SeqId = 0</code>.

<pre>
URP : [00 00 00 00] SeqId = 0
[00 00 00 00] CmdFlag = 0
PDAP: [01 00 00 00] cmd_type = 1
[06 00 00 00] payload_len = 6
[15 AE] host reply port = 5550 (big-endian)
[C0 A8 01 01] host IP = 192.168.1.1 (network byte order)
</pre>

<syntaxhighlight lang="python">
import socket, struct

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
sock.bind(("0.0.0.0", 5550))

HOST_IP = "192.168.1.1"
DET_IP = "192.168.1.30"
HOST_PORT = 5550
IMG_PORT = 6660

def make_urp_packet(seq_id, pdap_bytes):
return struct.pack("<II", seq_id, 0) + pdap_bytes

pdap = struct.pack("<II", 1, 6) + struct.pack(">H", HOST_PORT) + socket.inet_aton(HOST_IP)
sock.sendto(make_urp_packet(0, pdap), ("192.168.1.255", 8100))
</syntaxhighlight>

====Step 2: Receiving the BEACON and ACKing====

The detector broadcasts a <code>BEACON</code> (cmd_type=1) roughly every 2 seconds. After sending SYSTEM_STARTUP you should get one quickly. Parse the detector SeqId from the URP header and ACK it:

<syntaxhighlight lang="python">
data, addr = sock.recvfrom(4096)
det_seq = struct.unpack_from("<I", data, 0)[0]

# send bare ACK
ack = struct.pack("<II", det_seq, 1)
sock.sendto(ack, (DET_IP, 8100))

# all subsequent commands start from here
host_seq = det_seq + 1
</syntaxhighlight>

====Step 3: PORT_SETUP====

Tells the detector which host ports to use for replies and image data.

<pre>
PDAP: [02 00 00 00] cmd_type = 2
[04 00 00 00] payload_len = 4
[15 AE] host cmd port = 5550 (big-endian)
[1A 04] host image port = 6660 (big-endian)
</pre>

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 2, 4) + struct.pack(">HH", HOST_PORT, IMG_PORT)
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1
# expect bare ACK from detector
</syntaxhighlight>

====Step 4: Reading the Serial Number (SIGNATURE_REQUEST)====

Empty command, the detector replies with a 54-byte payload containing its identity.

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 3, 0) # cmd_type=3, payload_len=0
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1

# reply is 70 bytes total: 8 URP + 8 PDAP header + 54 payload
data, _ = sock.recvfrom(4096)
payload = data[16:] # skip URP (8) + PDAP header (8)

mac = payload[0:6]
serial = payload[22:34].rstrip(b'\x00 ').decode()
model = payload[34:46].rstrip(b'\x00 ').decode()
fw_bytes = payload[46:54]
firmware = ".".join(str(b) for b in fw_bytes)

print(f"MAC: {':'.join(f'{b:02X}' for b in mac)}")
print(f"Serial: {serial}")
print(f"Model: {model}")
print(f"Firmware: {firmware}")
</syntaxhighlight>

Expected output:
<pre>
MAC: 40:F4:A0:00:78:4D
Serial: UA45829-7
Model: 5340000-7
Firmware: 1.6.0.4.2.0.1.3
</pre>

===Running an Acquisition===

After the connection sequence above, download scripts to the detector and then execute them.

====ROE Initialisation (Script 7)====

Always run this first. It initialises the readout electronics and takes about 4-5 seconds. The detector sends host event ID 17 when done.

====Dark / Offset Acquisition (Script 1)====

No X-ray source required. Runs a dark-field exposure for offset calibration. Use this to verify the acquisition pipeline without a generator.

====Standard Acquisition (Script 0)====

Requires an actual X-ray exposure. <code>EXECUTION_COMPLETE</code> will '''not''' arrive without a real X-ray trigger.

====Sequence Overview====

<pre>
HOST DETECTOR
| |
|-- SYSTEM_STARTUP (broadcast) ----------->|
|<- bare ACK -------------------------------|
|<- BEACON (cmd_type=1) --------------------|
|-- bare ACK ------------------------------>|
| |
|-- PORT_SETUP (cmd_type=2) -------------->|
|<- bare ACK -------------------------------|
| |
|-- SIGNATURE_REQUEST (cmd_type=3) ------->|
|<- SIGNATURE_REPLY (54 bytes) -------------|
|-- bare ACK ------------------------------>|
| |
|-- GENERIC_SCRIPT Script7 (ROE init) ---->|
|<- bare ACK or SCRIPT_DOWNLOAD_REPLY ------|
| |
|-- GENERIC_SCRIPT Script1 (dark acq) ---->|
|<- bare ACK -------------------------------|
| |
|-- EXECUTE_SCRIPT (cmd_type=6) ---------->|
|<- bare ACK -------------------------------|
|<- EXECUTE_SCRIPT_REPLY (~230ms) ----------|
|-- bare ACK ------------------------------>|
|<- DETECTOR_STATE_NOTIFY (~890ms) ---------| state_id=17
|-- bare ACK ------------------------------>|
| |
|<- EXECUTION_COMPLETE (0x10000) -----------|
|-- bare ACK ------------------------------>|
| |
|<- IMAGE_XFER_STATUS_QUERY (0x30000) ------|
|-- bare ACK ------------------------------>|
|-- IMAGE_XFER_STATUS_REPLY (cmd_type=9) ->| numMissed=0
|<- bare ACK -------------------------------|
</pre>

===Sequence Counter Rules===

*<code>SYSTEM_STARTUP</code> always uses <code>SeqId = 0</code>.
*After the first beacon, set host SeqId to beacon_SeqId + 1.
*Increment SeqId by 1 for every new data packet (CmdFlag=0).
*Bare ACKs echo the SeqId of the packet being acknowledged and do not consume a SeqId.
*The detector silently drops any packet with a SeqId it has already processed, so never reuse one.

==Sensor Readout and Host Registration==

This section documents the reverse engineered sensor telemetry interface and the
host registration (pairing) mechanism of the GE Optima XR200/220 AMX FlashPad
(URP detector, SuperBee, FW 1.6.0.4.2.0.1.3). All commands are PDAP over UDP to
the detector at port 8100; replies return to the host command port.

===Sensor Readout===

The detector exposes an analog sensor interface (the DEM, Detector Environment
Monitor) that is independent of the image transfer path and works regardless of
acquisition state.

====Commands====

{| class="wikitable"
!cmd_type!!Meaning!!Request payload!!Reply payload
|-
|0x7900||Raw sensor read||[sensorId:4 LE]||[value:4 LE] (12 bit ADC count)
|-
|0x7902||Converted sensor read||[sensorId:4 LE]||[value:4 LE] (engineering units, signed)
|-
|0x7904||Detailed / radio||[selector:4 LE]||[value:4 LE]
|}

Note: cmd 0x7902 IS supported on this firmware and returns calibrated
engineering units (millivolts for the supply rails, signed; 0.1 degree C for
temperatures). Earlier documentation that marked 0x7902 as unsupported is
incorrect. The host side conversion coefficients are not required; the detector
performs the conversion internally.

The full sensor map (name, sensorId) was recovered from the detector's own
[Sensor] configuration table, read back over the upload interface (see the
Registration section for the read protocol).

====Power rails (live readings)====

All supply rails read correctly via 0x7902 and are within normal range for a
flat panel detector. Representative readings:

{| class="wikitable"
!Sensor!!sensorId!!Converted!!Value
|-
|DCIN_RAW||10||12100 mV||+12.10 V (main DC input)
|-
|LCORE_UNREG||11||1724 mV||+1.72 V
|-
|LPANA_UNREG||12||5776 mV||+5.78 V
|-
|LNANA_UNREG||13||-5801 mV||-5.80 V
|-
|SCAN_VCC||14||5086 mV||+5.09 V (gate driver)
|-
|P5V_REF||16||5025 mV||+5.03 V (5 V reference)
|-
|V_ON||17||11085 mV||+11.09 V (TFT gate on)
|-
|V_OFF||18||-12378 mV||-12.38 V (TFT gate off)
|-
|V_COMMON||19||-9385 mV||-9.39 V
|-
|3V3||29||3177 mV||+3.18 V (3.3 V logic)
|-
|VCC_UNREG||37||3399 mV||+3.40 V
|-
|PARCPREG||38||3768 mV||+3.77 V (ARC preamp +)
|-
|NARCPREG||39||-3732 mV||-3.73 V (ARC preamp -)
|-
|PANA_UNREG||45||18352 mV||+18.35 V (photodiode bias +)
|-
|NANA_UNREG||46||-19251 mV||-19.25 V (photodiode bias -)
|}

Switched rails that are inactive while the panel is idle (PARCVA_U,
P5VA_SW, N5VA_SW, FGATE_NVC_L, FGATE_PVC_L, etc.) read at or near zero.

====Known limitations====

*'''Temperatures''' (Temp_Surface, sensorId 336; Temp_Panel, sensorId 352): the raw 0x7900 read rails at 0x3FF (1023, the ADC maximum), indicating an open thermistor path while the panel is idle. This is a hardware/state condition, not a command problem, and the temperature is not readable from the host in this state.
*'''Unimplemented sensors''': sensorIds 70 (Accelerator), 78 (Gravity), and 256 to 259 (Battery status, name, life, capacity), and 272 (Grid status) are not implemented on this DEM. The detector returns the leftover conversion register contents (a duplicate of a previously read sensor) rather than a real value, so these rows must be discarded.
*'''Accelerometer''': functional through a separate addressing scheme using raw cmd 0x7900 with selectors 0x42 (X), 0x43 (Y), 0x44 (Z), returning 12 bit per axis counts.

===Host Registration (Pairing)===

URP stands for Unified Registration Protocol. The detector maintains a host
list in its internal NOR flash. Image data is delivered only to a registered
primary host, so registration is a prerequisite for image transfer.

====Host identity (MAC and HostId)====

Each host is identified by a 16 character HostId derived deterministically from
the host's eth0 MAC address. The derivation (from the vendor generateHostId
script) is:

#Take the eth0 MAC, remove the colon separators, convert to upper case (12 hex characters).
#Prepend the last 4 characters to the full 12 characters.
#The result is 16 hex characters.

Example: MAC 00:6f:00:01:0a:3a becomes 006F00010A3A, then the last four (0A3A)
are prepended, giving HostId 0A3A006F00010A3A.

====HostList structure====

The host list is stored in flash at offset 0x940000 and can be read back over
the upload interface as data category 0x71. Layout:

Offset Size Field
0x00 16 DetectorDeviceId (ASCII)
0x10 16 ConnectionSecretKey (ASCII; "XXXXXXXXXXXXXXXX" when unset)
0x20 16 DetectorName (ASCII)
0x30 16 DetectorCode (ASCII)
0x40 2 CurrentNumberOfHosts (uint16 LE)
0x42 2 IndexToPrimaryHost (uint16 LE; 0xFFFF = none)
0x44 144*N Host entries, 144 bytes each:
+0x00 16 HostId (ASCII)
+0x10 .. host name / department string
+0x50 .. location string
... 4 CRC (big endian; see below)

====HostList from the unit under test====

Detector: MAC 40:F4:A0:00:78:4D, serial UA45829-7, model 5340000-7,
firmware 1.6.0.4.2.0.1.3. DetectorName starShape_green. ConnectionSecretKey
unset. CurrentNumberOfHosts = 3, IndexToPrimaryHost = 0xFFFF (no primary host).

{| class="wikitable"
!Index!!HostId!!Derived MAC!!Name
|-
|0||2C6400045FB42C64||00:04:5F:B4:2C:64||Haus 207 / ITS
|-
|1||B044E8393512B044||E8:39:35:12:B0:44||Not Initialized
|-
|2||5CF800045FB15CF8||00:04:5F:B1:5C:F8||Not_Initialized
|}

The unit is therefore not factory fresh; it carries registrations from a prior
deployment, but no primary host is currently designated.

====Checksum (CRC)====

The HostList (and other flash data blobs) are protected by a 4 byte trailing
CRC. Parameters:

*Polynomial: 0x04C11DB7
*Initial value: 0
*MSB first, augmented message style (the data bit is shifted into the LSB; no input or output reflection; no final XOR)
*Stored big endian

To generate: compute the CRC over the data followed by four zero bytes, then
append the result big endian. Verification: the CRC over (data plus stored CRC)
equals zero.

def crc(data, poly=0x04C11DB7, init=0):
c = init
for byte in data:
for bit in (0x80,0x40,0x20,0x10,0x08,0x04,0x02,0x01):
msb = c & 0x80000000
c = (c << 1) & 0xFFFFFFFF
if byte & bit: c |= 1
if msb: c ^= poly
return c
# trailer = crc(data + b"\x00\x00\x00\x00"), stored big endian

====Read and write transport====

Data blobs (including the HostList) are moved with a configure / buffer /
finalize sequence.

Read (upload, detector to host), non destructive:

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x13||[uploadId:4 LE]||[status:1][totalSize:4 LE]
|-
|Buffer||0x14||[bufId:4 LE][numBytes:4 LE]||[bufId:4 LE][numBytes:4 LE][data]
|}

Write (download, host to detector), persistent (writes flash):

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x0E||[downloadId:4 LE][totalSize:4 LE]||[status:1]
|-
|Buffer||0x0F||[bufId:4 LE][numBytes:4 LE][data]||[status:1][reserved:4]
|-
|Commit||0x10||(empty)||[status:1]
|}

bufId is a zero based chunk index. The HostList uses id 0x71 for both read and
write. The commit command (0x10) reuses the firmware flash path, so a malformed
download can corrupt flash; the operation is irreversible on this hardware.

====Registering a new host====

To register a host and make it the image destination, read the current HostList
(0x71), append a 144 byte entry carrying the new HostId, increment
CurrentNumberOfHosts, set IndexToPrimaryHost to the new entry's index,
recompute the trailing CRC, and write the blob back via the download sequence
(0x0E / 0x0F / 0x10).

==Reading the Drop and Shock Event Log==

The detector contains an accelerometer based shock watchdog that records drop
and impact events into non volatile memory. This log is useful when evaluating a
used unit, since it reveals how many serious shocks the panel has survived and
when. The same data is held both in the main flash (read over the network) and
in the small onboard EEPROM on the detector PCB.

===How to read it===

The shock log is exposed as data category 0x72 on the upload (read) interface.
It is retrieved with the standard non destructive configure and buffer sequence
(cmd 0x13 to configure, cmd 0x14 to pull the chunks). On the unit under test the
blob is 3001 bytes of plain text in the GE .dyn configuration format, so no
decoding is required beyond reading it as ASCII.

The same records are mirrored in binary form in the onboard 24LC256 EEPROM
(32 KB I2C part) for anyone reading the hardware directly.

===Example output===

The following is the actual log read from detector serial UA45829-7. The file
has two parts: a list of individual events (DetectorShockEvents) and a summary
block (DetectorShockData). Each event carries a record key, a severity, a
timestamp, and the peak acceleration on each axis. Two representative records:

<DetectorShockEvents>
[149266438700135]
Severity.Type = String
Severity.Val = Serious
TimeStamp.Type = String
TimeStamp.Val = 2017-4-20,6:59:47
ValidTime.Type = Number
ValidTime.Val = 0
VibrationX.Type = Number
VibrationX.Val = 0
VibrationY.Type = Number
VibrationY.Val = 0
VibrationZ.Type = Number
VibrationZ.Val = 135

[1592113924-1720-113]
Severity.Val = Serious
TimeStamp.Val = 2020-6-14,7:52:4
VibrationX.Val = -172
VibrationY.Val = 0
VibrationZ.Val = -113

The summary block at the end lists the totals and an index of all event keys:

[DetectorShockData]
LastKnownGoodTime.Val = 2024-4-4,6:53:59
NumberOfL3Events.Val = 0
NumberOfL5Events.Val = 7
ShockDataTimeList.Val = { 1643260890-1320-119, 163626503500-123,
160818190500-101, 160524243000170, 1592113924-1720-113,
157804584600183, 149266438700135 }

===Interpreting the records===

The record key encodes the event time and the peak axis values (an epoch style
timestamp followed by the concatenated vibration readings), so it is unique per
event. The VibrationX, VibrationY, and VibrationZ values are signed peak
acceleration counts on each axis. Severity is reported as Serious for all
logged events on this unit, which corresponds to the L5 (highest) severity class
counted in the summary.

The seven recorded events for this detector:

{| class="wikitable"
!Date and time!!VibrationX!!VibrationY!!VibrationZ
|-
|2017-04-20 06:59:47||0||0||135
|-
|2020-01-03 11:04:06||0||0||183
|-
|2020-06-14 07:52:04||-172||0||-113
|-
|2020-11-13 05:40:30||0||0||170
|-
|2020-12-17 06:11:45||0||0||-101
|-
|2021-11-07 07:03:55||0||0||-123
|-
|2022-01-27 06:21:30||-132||0||-119
|}

===Reading the summary fields===

{| class="wikitable"
!Field!!Meaning
|-
|LastKnownGoodTime||Timestamp of the last successful self check (here 2024-04-04), the most recent point at which the detector was known to be operating normally
|-
|NumberOfL3Events||Count of lower severity (L3) shock events; zero on this unit
|-
|NumberOfL5Events||Count of high severity (L5) shock events; seven on this unit, matching the seven records above
|-
|ShockDataTimeList||Index of all stored event keys, newest first
|}

On this example the panel logged seven serious impacts over roughly five years
of field use and last reported a good self check in April 2024.

==FlashPad Detector: Internal Flash Dump and Data Files==

This section documents how the full contents of the detector's internal flash
were extracted over the network and what each recovered file contains. The
detector under test is a GE Optima XR200/220 AMX FlashPad (URP detector,
serial UA45829-7, MAC 40:F4:A0:00:78:4D, firmware 1.6.0.4.2.0.1.3).

===Background===

The detector's main storage is a Spansion/Cypress S29GL512P (marked
GL512P10FFCR2), a 512 Mbit (64 MB) parallel NOR flash. A direct chip read
requires bus access or desoldering and a programmer. However, the detector
firmware exposes its stored data blobs, including a full image of the flash,
through the read (upload) side of the data transport protocol. This makes a
complete, byte exact dump possible over UDP with no physical access.

===Extraction method===

The upload interface is the read counterpart of the firmware download path and
is non destructive (it only reports and returns data; nothing is written).
Each data category is identified by an 8 bit upload ID:

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x13||[uploadId:4 LE]||[status:1][totalSize:4 LE]
|-
|Buffer||0x14||[bufId:4 LE][numBytes:4 LE]||[bufId:4 LE][numBytes:4 LE][data]
|}

A configure request returns status 0 and a total size for a valid ID, or a non
zero status for an unsupported ID. The dump tool sweeps all IDs from 0x00 to
0xFF, and for every readable ID it pulls the full blob in fixed size chunks
(bufId is a zero based chunk index) and writes it to a file. The 64 MB flash
image transfers as 65536 chunks of 1024 bytes.

===Recovered files===

A sweep of the unit returned 18 readable blobs:

{| class="wikitable"
!Upload ID!!Size (bytes)!!Contents
|-
|0xFD||67108864||Full 64 MB NOR flash image
|-
|0xFF||16777216||16 MB region (firmware / FPGA mirror or image buffer)
|-
|0xFE||524288||Bootloader (512 KB; SPI loader, Nios reset code)
|-
|0x10||6815783||Calibration map, dose level 1
|-
|0x11||6815783||Calibration map, dose level 2
|-
|0x12||6815783||Calibration map, dose level 3
|-
|0x06||49254||Table referencing conditioner/generator serial UA2010-8U005
|-
|0x50||19938||Per mode calibration coefficients
|-
|0x51||19582||Per mode calibration coefficients
|-
|0x07||12187||Sensor conversion table (text; see Sensor Readout)
|-
|0x72||3001||Shock / drop event log (text)
|-
|0x0E||624||Panel geometry / configuration (binary)
|-
|0x71||504||Host list / registration record (see Host Registration)
|-
|0x0F||233||Host to detector compatibility table (text)
|-
|0x08||62||Serial and model strings
|-
|0x0A||48||Manufacturing codes
|-
|0x52||30||Serial string
|-
|0x0B||24||Small marker / identifier
|}

===Flash image layout (upload ID 0xFD)===

A block scan of the 64 MB image shows the following regions:

{| class="wikitable"
!Range!!Contents
|-
|0x000000 to 0x800000||Firmware and FPGA configuration
|-
|0x800000 to 0x940000||Sparse configuration area
|-
|0x940000||Host list / registration record (matches upload ID 0x71)
|-
|0x1000000 to 0x2800000||Calibration and image data (16 to 40 MB)
|-
|0x2800000 to 0x4000000||Erased / unused (40 to 64 MB)
|}

The host list strings (the DetectorName starShape_green, the registered host
name Haus 207 / ITS, and the unset ConnectionSecretKey placeholder) appear at
0x940000, confirming that the 504 byte 0x71 read maps to this flash region.

===Notes on individual files===

*'''0x07 (sensor table)''': plain text, header DetectorSerialNumber = UA45829-7, revision 1.2. Lists every sensor by name, command (0x7902), and sensorId. Also carries panel geometry in its [Common] section: 16 bit depth, 2048 by 2048 pixels, active area from (12, 12) to (2035, 2035), pixel pitch 0.2 mm, corner radius 1416.8, panel saturation 150.
*'''0x10, 0x11, 0x12 (calibration maps)''': three distinct blobs of identical size, corresponding to the low, medium, and high dose calibration sets. Each begins with the firmware version and serial (header bytes 01 06 00 04 02 00 01 03 followed by the serial). Required to apply gain and offset correction to raw images.
*'''0xFE (bootloader)''': contains the strings spi_load.S and ../../boot and Nios II reset vector code.
*'''0x72 (shock log)''': text records of drop / vibration events with timestamps and per axis values; the same data is mirrored in the detector's small onboard EEPROM.
*'''0x06''': references a different serial, UA2010-8U005, likely the conditioner or generator board rather than the panel.

===Significance===

The complete flash image and all calibration data are recoverable over the
network without opening the detector, providing a full byte exact backup of the
unit before any write operation. The calibration maps are needed for image
correction, and the firmware image (the live, deployed build) is more complete
than the partial firmware files shipped on the recovery media.

===Known Dead Ends===

Things that were tried and did not work or led nowhere:

;0xBEEF (48879) as reply port
:This was a bug in early test scripts. The port has no meaning in the protocol. Use 5550.

;CmdFlag=1 as data packet flag
:Early scripts had the URP fields swapped, setting CmdFlag=1 on data packets. The detector ignores all PDAP content in these packets. Power cycle the detector if this happened, it may retain stale port state.

;Image data on alternate ports
:Tried listening on 48879, 6660, 5550, 8100, 1050, 6661, 9999, 4444, 7000, 7001, 9001. Nothing arrived on any of them.

;PORT_SETUP byte order (big-endian)
:Current implementation sends port fields as big-endian. If the detector reads them as little-endian it computes port 44565 and 1050 instead of 5550 and 6660, which would explain why no image data arrives. Not yet confirmed.

;Image data streaming automatically after EXECUTE_SCRIPT
:Frames may not push during execution at all. The detector may require an explicit IMAGE_RETRIVAL_REQUEST (cmd_type=0x41) and IMAGE_RETRIVAL (cmd_type=0x98) after the 0x30000 notification before it streams anything. Not yet tested.

==Teardown / Internal Pictures / Hardware analysis==
<div style="float:left; display:flex; gap:8px;">
[[File:GE Flashpad under the hood.jpg|thumb|none|220px|the Carbon fiber sleeve is held by 9 screws and can taken off without force.]]
[[File:Ge flashpad powersupply pcb in handle.jpg|thumb|none|220px|Power supply PCB]]
[[File:Ge flashpad uwb board pcb.jpg|thumb|none|220px|UWB PCB for Wireless USB using a RTU2705]]
[[File:Ge flashpad uwb pcb backside.jpg|thumb|Backside of UWB PCB]]
</div>
<div style="float:left; display:flex; gap:8px;">
[[File:Ge flashpad power supply pcb backside.jpg|thumb|Backside of Power supply PCB]]
[[File:Ge flashpad main pcb closeup1.jpg|thumb|Main area of the PCB with its Altera Cyclone 3 FPGA]]
[[File:Ge flashpad main pcb closeup2.jpg|thumb|AD7892 is a 600ksps 12bit ADC, SN74LVC8T245 a 8bit bus transceiver and DG9408EDN a 8ch MUX]]
[[File:Ge flashpad bottom connector ethernet isolation pcb.jpg|thumb|Isolation PCB for bottom connector]]
</div>
<div style="float:left; display:flex; gap:8px;">
[[File:Ge flashpad main pcb powersupply section.jpg|thumb|Powersupply section for FPGA and ROIC]]
[[File:Ge_flashpad_main_pcb_closeup_3.jpg|thumb|AD9764AR 14-Bit, 125 MSPS DAC and DS1682 integrated elapsed-time recorder]]
[[File:Ge flashpad main pcb closeup 4.jpg|thumb|left|Accelerometer is a 834-0500 500G 3 Axis unit. abd TJ500AE SPDT GIGABIT LAN SWITCH]]
[[File:Ge flashpad bottom connector.jpg|thumb|left|bottom connector for docking stand]]
</div>
<div style="float:left; display:flex; gap:8px;">
[[File:Ge flashpad main pcb closeup 5.jpg|thumb|left|Ethernet transformers and ADM34 RS-485/RS-422 Transceiver]]
[[File:Ge flashpad main pcb closeup 6.jpg|thumb|left|Altera EPM570f100c5n CPLD ]]
[[File:Ge flashpad main pcb closeup 7.jpg|thumb|left|Spansion GL512P10FF1R1 512 Mbit NOR flash IC holding everything.]]
[[File:Ge flashpad main pcb closeup 8.jpg|thumb|left|24LC256I 32k EEPROM for storing the accelerometer events.]]
</div>

GE Medical Flashpad Digital Xray Detector

2026-06-11T11:59:52Z

Gamerpaddy: /* Status of Reverse Engineering */

GE Medical Flashpad Digital Xray Detector

2026-06-11T11:58:19Z

Gamerpaddy: /* Technical Specifications */ linking to shock event log

==Overview==

The '''GE Flashpad''' is a Digital Radiography image sensor from approximately 2010, originally used in the '''GE Optima 220AMX''' mobile X-ray unit. It was designed to replace analog film in radiology, dramatically reducing image acquisition time from hours to seconds.
[[File:GE Flashpad.jpg|thumb|Flashpad with Anti-Scatter grid (left), manual and recovery dvd for 220amx and tether cord (right)]]
Due to its high original cost and specialized application, used units occasionally appear on professional B2B marketplaces in the $15,000–$50,000 range. On eBay, prices typically fall between $1,500 and $5,000, though units at this price point are often in poor condition and may fail the built-in self-test or not function at all.

{{Note|All findings on this page are based on a single unit and the time spent working on it. Information is subject to speculation and may not be fully accurate.}}

{{Note|[[Artificial intelligence|AI]] assistance was used in writing this page for improved formatting and readability, as well as in the process of finding information, testing, and analyzing firmware dumps and backups.}}

==Purpose and Motivation==

This project documents the reverse engineering of the GE FlashPad wireless
digital radiography detector used with the Optima XR200/220 AMX mobile X-ray
system, with the goal of freeing these detectors for independent use.
[[File:Xray capture pcb.png|thumb|Xray capture of a PCB for Reverse Engineering]]
Large numbers of these detectors reach the used market, but each one is
cryptographically and administratively bound to its original Optima 220 AMX
console. Once separated from that console, or once the console is
decommissioned, the detector is effectively useless even though the hardware is
fully functional. The aim of this work is to remove that artificial barrier so
that a standalone FlashPad can be paired, configured, and read out by any host,
without the half million dollar console it was sold with.

The intended beneficiaries are:

*Hobbyists, researchers, and engineers who want a high quality flat panel detector for their own imaging projects.
*Veterinary practices, which can put surplus human grade detectors to good use at a fraction of the cost of new equipment.
*Clinics and hospitals in countries and regions where a complete commercial system is unaffordable, allowing serviceable detectors to keep providing diagnostic imaging instead of being scrapped.

[[File:Xray current clamp multimeter.png|thumb|xray of a current clamp multimeter]]
This is done for human good. Every detector returned to service is one less
piece of working medical hardware sent to landfill, and potentially one more
place that can offer X-ray imaging where it otherwise could not.

All files, findings, protocol documentation, and tools produced by this project
are public and open source, so that anyone can study, reproduce, and build on
the work.

==Technical Specifications==
[[File:Ge flashpad tether cable pinout diagram.png|thumb|Pinout Diagram of the Tether cable]]
[[File:Ge flashpad tether wiring for ethernet cable.jpg|thumb|Professional Tether wiring to attach a Ethernet Cable and 12V socket to it.]]
The Flashpad uses a '''~40 × 40 cm CsI scintillator''' bonded to a [[Thin-film transistor|TFT]] photodetector array mounted on glass. The assembly is highly sensitive to shock and impact damage. See section [[#Reading the Drop and Shock Event Log|drop and shock event log]]

{| class="wikitable"
|-
!Parameter!!Value
|-
|Resolution||2048 × 2048 px
|-
|Bit depth||16-bit per pixel
|-
|Spatial resolution||Up to 5 lp/mm (theoretical)
|-
|Scintillator material||Caesium iodide (CsI)
|-
|Detector type||TFT photodetector array (glass substrate)
|-
|Panel size||~40 × 40 cm
|}

The theoretical 5 lp/mm spatial resolution is primarily limited in practice by the focal spot size of the X-ray source. Use of an anti-scatter grid can improve effective resolution.

===Status of Reverse Engineering===

{| class="wikitable"
|-
!What!!Status
|-
|Connect, beacon, ACK||Works
|-
|PORT_SETUP||Works
|-
|SIGNATURE_REQUEST / serial number readout||Works
|-
|Script download (Scripts 7, 8, 1)||Works
|-
|EXECUTE_SCRIPT||Works
|-
|EXECUTION_COMPLETE (dark acquisition)||Works
|-
|EXECUTION_COMPLETE (standard acquisition)||Needs real X-ray trigger to test
|-
|Image data on port 6660||Does not work yet, under investigation. Will not send Imagedata yet.
|}

==Hardware Features==

===Shock logging===
The unit contains an internal accelerometer that logs significant shock events — but only when a battery is inserted. As there is no backup battery, shock events occurring while unpowered are not recorded.

===Wireless connectivity===
Some units include a UWB transmitter for Wireless USB; others may be equipped with a Wi-Fi module instead. The detector can also be operated over the tethered connection alone.

===Ethernet interface===
There is a 100MBit Ethernet interface trough the Tether Cable which can be tapped and used for Communication.
Exposed metal contacts on the bottom connector are isolated via relays by default. Enabling Gigabit Ethernet connectivity requires shorting or driving two specific pins. This has not been investigated further at this time.

==Communication Protocol==

This section documents the URP/PDAP protocol used by the GE Flashpad (codename '''Apollo''') to communicate with a host over Ethernet. All findings are based on live capture tests, configuration files, and reverse-engineering of the GE SuperBee software stack.

{{Note|All findings are based on a single unit and may not be fully accurate.}}

===Network Setup===

All findings were over Ethernet only, no UWB or WIFI has been used.
Default detector IP is <code>192.168.1.30</code>. Set your host to a static IP in the same subnet, <code>192.168.1.1</code> works fine.

At first by sending random bytes over Python it answered to port 48879 (0xBEEF), which seems to be either the default port or set by Python.
After SYSTEM_SETUP it got set to 5550.

{| class="wikitable"
|-
!Role!!IP!!Port!!Direction
|-
|All commands: host -> detector||192.168.1.30||'''8100''' (UDP)||Host sends here
|-
|Discovery beacons: detector -> host||-||'''4500''' (UDP)||Detector sends here initially
|-
|Protocol replies: detector -> host||-||'''5550''' (UDP)||Detector sends here after setup
|-
|Image pixel data: detector -> host||-||'''6660''' (UDP)||Detector streams frames here
|}

In practice you can listen on port '''5550''' for everything (beacons and replies) by advertising that port in both <code>SYSTEM_STARTUP</code> and <code>PORT_SETUP</code>. The detector sends to whichever port was most recently configured.

===Protocol Layers===

Two layers, carried over UDP:

;URP (Unified Registration Protocol)
:8-byte wrapper on every packet. Handles sequencing and acknowledgement.

;PDAP (Proprietary Detector Access Protocol)
:The actual command layer, present inside URP packets when <code>CmdFlag = 0</code>.

Every UDP packet starts with a URP header:

<pre>
[SeqId : 4 bytes LE] [CmdFlag : 4 bytes LE]
</pre>

*<code>CmdFlag = 0</code> -- data packet, PDAP command follows.
*<code>CmdFlag = 1</code> -- bare ACK, no PDAP body. SeqId echoes the packet being acknowledged.

Both sides must ACK every data packet immediately. The detector silently drops packets with a SeqId it has already seen, so always increment SeqId for each new command.

When CmdFlag is 0, the PDAP header follows immediately:

<pre>
[cmd_type : 4 bytes LE] [payload_len : 4 bytes LE] [payload ...]
</pre>

===Connecting to the Detector===

The connection sequence is:

#Broadcast <code>SYSTEM_STARTUP</code> to tell the detector where to reply.
#The detector sends a <code>BEACON</code> back -- ACK it and sync your sequence counter.
#Send <code>PORT_SETUP</code> to configure the reply and image ports.
#Send <code>SIGNATURE_REQUEST</code> to read the detector identity (serial number, model, firmware, MAC).

====Step 1: SYSTEM_STARTUP====

Broadcast UDP to <code>192.168.1.255:8100</code>. Always uses <code>SeqId = 0</code>.

<pre>
URP : [00 00 00 00] SeqId = 0
[00 00 00 00] CmdFlag = 0
PDAP: [01 00 00 00] cmd_type = 1
[06 00 00 00] payload_len = 6
[15 AE] host reply port = 5550 (big-endian)
[C0 A8 01 01] host IP = 192.168.1.1 (network byte order)
</pre>

<syntaxhighlight lang="python">
import socket, struct

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
sock.bind(("0.0.0.0", 5550))

HOST_IP = "192.168.1.1"
DET_IP = "192.168.1.30"
HOST_PORT = 5550
IMG_PORT = 6660

def make_urp_packet(seq_id, pdap_bytes):
return struct.pack("<II", seq_id, 0) + pdap_bytes

pdap = struct.pack("<II", 1, 6) + struct.pack(">H", HOST_PORT) + socket.inet_aton(HOST_IP)
sock.sendto(make_urp_packet(0, pdap), ("192.168.1.255", 8100))
</syntaxhighlight>

====Step 2: Receiving the BEACON and ACKing====

The detector broadcasts a <code>BEACON</code> (cmd_type=1) roughly every 2 seconds. After sending SYSTEM_STARTUP you should get one quickly. Parse the detector SeqId from the URP header and ACK it:

<syntaxhighlight lang="python">
data, addr = sock.recvfrom(4096)
det_seq = struct.unpack_from("<I", data, 0)[0]

# send bare ACK
ack = struct.pack("<II", det_seq, 1)
sock.sendto(ack, (DET_IP, 8100))

# all subsequent commands start from here
host_seq = det_seq + 1
</syntaxhighlight>

====Step 3: PORT_SETUP====

Tells the detector which host ports to use for replies and image data.

<pre>
PDAP: [02 00 00 00] cmd_type = 2
[04 00 00 00] payload_len = 4
[15 AE] host cmd port = 5550 (big-endian)
[1A 04] host image port = 6660 (big-endian)
</pre>

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 2, 4) + struct.pack(">HH", HOST_PORT, IMG_PORT)
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1
# expect bare ACK from detector
</syntaxhighlight>

====Step 4: Reading the Serial Number (SIGNATURE_REQUEST)====

Empty command, the detector replies with a 54-byte payload containing its identity.

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 3, 0) # cmd_type=3, payload_len=0
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1

# reply is 70 bytes total: 8 URP + 8 PDAP header + 54 payload
data, _ = sock.recvfrom(4096)
payload = data[16:] # skip URP (8) + PDAP header (8)

mac = payload[0:6]
serial = payload[22:34].rstrip(b'\x00 ').decode()
model = payload[34:46].rstrip(b'\x00 ').decode()
fw_bytes = payload[46:54]
firmware = ".".join(str(b) for b in fw_bytes)

print(f"MAC: {':'.join(f'{b:02X}' for b in mac)}")
print(f"Serial: {serial}")
print(f"Model: {model}")
print(f"Firmware: {firmware}")
</syntaxhighlight>

Expected output:
<pre>
MAC: 40:F4:A0:00:78:4D
Serial: UA45829-7
Model: 5340000-7
Firmware: 1.6.0.4.2.0.1.3
</pre>

===Running an Acquisition===

After the connection sequence above, download scripts to the detector and then execute them.

====ROE Initialisation (Script 7)====

Always run this first. It initialises the readout electronics and takes about 4-5 seconds. The detector sends host event ID 17 when done.

====Dark / Offset Acquisition (Script 1)====

No X-ray source required. Runs a dark-field exposure for offset calibration. Use this to verify the acquisition pipeline without a generator.

====Standard Acquisition (Script 0)====

Requires an actual X-ray exposure. <code>EXECUTION_COMPLETE</code> will '''not''' arrive without a real X-ray trigger.

====Sequence Overview====

<pre>
HOST DETECTOR
| |
|-- SYSTEM_STARTUP (broadcast) ----------->|
|<- bare ACK -------------------------------|
|<- BEACON (cmd_type=1) --------------------|
|-- bare ACK ------------------------------>|
| |
|-- PORT_SETUP (cmd_type=2) -------------->|
|<- bare ACK -------------------------------|
| |
|-- SIGNATURE_REQUEST (cmd_type=3) ------->|
|<- SIGNATURE_REPLY (54 bytes) -------------|
|-- bare ACK ------------------------------>|
| |
|-- GENERIC_SCRIPT Script7 (ROE init) ---->|
|<- bare ACK or SCRIPT_DOWNLOAD_REPLY ------|
| |
|-- GENERIC_SCRIPT Script1 (dark acq) ---->|
|<- bare ACK -------------------------------|
| |
|-- EXECUTE_SCRIPT (cmd_type=6) ---------->|
|<- bare ACK -------------------------------|
|<- EXECUTE_SCRIPT_REPLY (~230ms) ----------|
|-- bare ACK ------------------------------>|
|<- DETECTOR_STATE_NOTIFY (~890ms) ---------| state_id=17
|-- bare ACK ------------------------------>|
| |
|<- EXECUTION_COMPLETE (0x10000) -----------|
|-- bare ACK ------------------------------>|
| |
|<- IMAGE_XFER_STATUS_QUERY (0x30000) ------|
|-- bare ACK ------------------------------>|
|-- IMAGE_XFER_STATUS_REPLY (cmd_type=9) ->| numMissed=0
|<- bare ACK -------------------------------|
</pre>

===Sequence Counter Rules===

*<code>SYSTEM_STARTUP</code> always uses <code>SeqId = 0</code>.
*After the first beacon, set host SeqId to beacon_SeqId + 1.
*Increment SeqId by 1 for every new data packet (CmdFlag=0).
*Bare ACKs echo the SeqId of the packet being acknowledged and do not consume a SeqId.
*The detector silently drops any packet with a SeqId it has already processed, so never reuse one.

==Sensor Readout and Host Registration==

This section documents the reverse engineered sensor telemetry interface and the
host registration (pairing) mechanism of the GE Optima XR200/220 AMX FlashPad
(URP detector, SuperBee, FW 1.6.0.4.2.0.1.3). All commands are PDAP over UDP to
the detector at port 8100; replies return to the host command port.

===Sensor Readout===

The detector exposes an analog sensor interface (the DEM, Detector Environment
Monitor) that is independent of the image transfer path and works regardless of
acquisition state.

====Commands====

{| class="wikitable"
!cmd_type!!Meaning!!Request payload!!Reply payload
|-
|0x7900||Raw sensor read||[sensorId:4 LE]||[value:4 LE] (12 bit ADC count)
|-
|0x7902||Converted sensor read||[sensorId:4 LE]||[value:4 LE] (engineering units, signed)
|-
|0x7904||Detailed / radio||[selector:4 LE]||[value:4 LE]
|}

Note: cmd 0x7902 IS supported on this firmware and returns calibrated
engineering units (millivolts for the supply rails, signed; 0.1 degree C for
temperatures). Earlier documentation that marked 0x7902 as unsupported is
incorrect. The host side conversion coefficients are not required; the detector
performs the conversion internally.

The full sensor map (name, sensorId) was recovered from the detector's own
[Sensor] configuration table, read back over the upload interface (see the
Registration section for the read protocol).

====Power rails (live readings)====

All supply rails read correctly via 0x7902 and are within normal range for a
flat panel detector. Representative readings:

{| class="wikitable"
!Sensor!!sensorId!!Converted!!Value
|-
|DCIN_RAW||10||12100 mV||+12.10 V (main DC input)
|-
|LCORE_UNREG||11||1724 mV||+1.72 V
|-
|LPANA_UNREG||12||5776 mV||+5.78 V
|-
|LNANA_UNREG||13||-5801 mV||-5.80 V
|-
|SCAN_VCC||14||5086 mV||+5.09 V (gate driver)
|-
|P5V_REF||16||5025 mV||+5.03 V (5 V reference)
|-
|V_ON||17||11085 mV||+11.09 V (TFT gate on)
|-
|V_OFF||18||-12378 mV||-12.38 V (TFT gate off)
|-
|V_COMMON||19||-9385 mV||-9.39 V
|-
|3V3||29||3177 mV||+3.18 V (3.3 V logic)
|-
|VCC_UNREG||37||3399 mV||+3.40 V
|-
|PARCPREG||38||3768 mV||+3.77 V (ARC preamp +)
|-
|NARCPREG||39||-3732 mV||-3.73 V (ARC preamp -)
|-
|PANA_UNREG||45||18352 mV||+18.35 V (photodiode bias +)
|-
|NANA_UNREG||46||-19251 mV||-19.25 V (photodiode bias -)
|}

Switched rails that are inactive while the panel is idle (PARCVA_U,
P5VA_SW, N5VA_SW, FGATE_NVC_L, FGATE_PVC_L, etc.) read at or near zero.

====Known limitations====

*'''Temperatures''' (Temp_Surface, sensorId 336; Temp_Panel, sensorId 352): the raw 0x7900 read rails at 0x3FF (1023, the ADC maximum), indicating an open thermistor path while the panel is idle. This is a hardware/state condition, not a command problem, and the temperature is not readable from the host in this state.
*'''Unimplemented sensors''': sensorIds 70 (Accelerator), 78 (Gravity), and 256 to 259 (Battery status, name, life, capacity), and 272 (Grid status) are not implemented on this DEM. The detector returns the leftover conversion register contents (a duplicate of a previously read sensor) rather than a real value, so these rows must be discarded.
*'''Accelerometer''': functional through a separate addressing scheme using raw cmd 0x7900 with selectors 0x42 (X), 0x43 (Y), 0x44 (Z), returning 12 bit per axis counts.

===Host Registration (Pairing)===

URP stands for Unified Registration Protocol. The detector maintains a host
list in its internal NOR flash. Image data is delivered only to a registered
primary host, so registration is a prerequisite for image transfer.

====Host identity (MAC and HostId)====

Each host is identified by a 16 character HostId derived deterministically from
the host's eth0 MAC address. The derivation (from the vendor generateHostId
script) is:

#Take the eth0 MAC, remove the colon separators, convert to upper case (12 hex characters).
#Prepend the last 4 characters to the full 12 characters.
#The result is 16 hex characters.

Example: MAC 00:6f:00:01:0a:3a becomes 006F00010A3A, then the last four (0A3A)
are prepended, giving HostId 0A3A006F00010A3A.

====HostList structure====

The host list is stored in flash at offset 0x940000 and can be read back over
the upload interface as data category 0x71. Layout:

Offset Size Field
0x00 16 DetectorDeviceId (ASCII)
0x10 16 ConnectionSecretKey (ASCII; "XXXXXXXXXXXXXXXX" when unset)
0x20 16 DetectorName (ASCII)
0x30 16 DetectorCode (ASCII)
0x40 2 CurrentNumberOfHosts (uint16 LE)
0x42 2 IndexToPrimaryHost (uint16 LE; 0xFFFF = none)
0x44 144*N Host entries, 144 bytes each:
+0x00 16 HostId (ASCII)
+0x10 .. host name / department string
+0x50 .. location string
... 4 CRC (big endian; see below)

====HostList from the unit under test====

Detector: MAC 40:F4:A0:00:78:4D, serial UA45829-7, model 5340000-7,
firmware 1.6.0.4.2.0.1.3. DetectorName starShape_green. ConnectionSecretKey
unset. CurrentNumberOfHosts = 3, IndexToPrimaryHost = 0xFFFF (no primary host).

{| class="wikitable"
!Index!!HostId!!Derived MAC!!Name
|-
|0||2C6400045FB42C64||00:04:5F:B4:2C:64||Haus 207 / ITS
|-
|1||B044E8393512B044||E8:39:35:12:B0:44||Not Initialized
|-
|2||5CF800045FB15CF8||00:04:5F:B1:5C:F8||Not_Initialized
|}

The unit is therefore not factory fresh; it carries registrations from a prior
deployment, but no primary host is currently designated.

====Checksum (CRC)====

The HostList (and other flash data blobs) are protected by a 4 byte trailing
CRC. Parameters:

*Polynomial: 0x04C11DB7
*Initial value: 0
*MSB first, augmented message style (the data bit is shifted into the LSB; no input or output reflection; no final XOR)
*Stored big endian

To generate: compute the CRC over the data followed by four zero bytes, then
append the result big endian. Verification: the CRC over (data plus stored CRC)
equals zero.

def crc(data, poly=0x04C11DB7, init=0):
c = init
for byte in data:
for bit in (0x80,0x40,0x20,0x10,0x08,0x04,0x02,0x01):
msb = c & 0x80000000
c = (c << 1) & 0xFFFFFFFF
if byte & bit: c |= 1
if msb: c ^= poly
return c
# trailer = crc(data + b"\x00\x00\x00\x00"), stored big endian

====Read and write transport====

Data blobs (including the HostList) are moved with a configure / buffer /
finalize sequence.

Read (upload, detector to host), non destructive:

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x13||[uploadId:4 LE]||[status:1][totalSize:4 LE]
|-
|Buffer||0x14||[bufId:4 LE][numBytes:4 LE]||[bufId:4 LE][numBytes:4 LE][data]
|}

Write (download, host to detector), persistent (writes flash):

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x0E||[downloadId:4 LE][totalSize:4 LE]||[status:1]
|-
|Buffer||0x0F||[bufId:4 LE][numBytes:4 LE][data]||[status:1][reserved:4]
|-
|Commit||0x10||(empty)||[status:1]
|}

bufId is a zero based chunk index. The HostList uses id 0x71 for both read and
write. The commit command (0x10) reuses the firmware flash path, so a malformed
download can corrupt flash; the operation is irreversible on this hardware.

====Registering a new host====

To register a host and make it the image destination, read the current HostList
(0x71), append a 144 byte entry carrying the new HostId, increment
CurrentNumberOfHosts, set IndexToPrimaryHost to the new entry's index,
recompute the trailing CRC, and write the blob back via the download sequence
(0x0E / 0x0F / 0x10).

==Reading the Drop and Shock Event Log==

The detector contains an accelerometer based shock watchdog that records drop
and impact events into non volatile memory. This log is useful when evaluating a
used unit, since it reveals how many serious shocks the panel has survived and
when. The same data is held both in the main flash (read over the network) and
in the small onboard EEPROM on the detector PCB.

===How to read it===

The shock log is exposed as data category 0x72 on the upload (read) interface.
It is retrieved with the standard non destructive configure and buffer sequence
(cmd 0x13 to configure, cmd 0x14 to pull the chunks). On the unit under test the
blob is 3001 bytes of plain text in the GE .dyn configuration format, so no
decoding is required beyond reading it as ASCII.

The same records are mirrored in binary form in the onboard 24LC256 EEPROM
(32 KB I2C part) for anyone reading the hardware directly.

===Example output===

The following is the actual log read from detector serial UA45829-7. The file
has two parts: a list of individual events (DetectorShockEvents) and a summary
block (DetectorShockData). Each event carries a record key, a severity, a
timestamp, and the peak acceleration on each axis. Two representative records:

<DetectorShockEvents>
[149266438700135]
Severity.Type = String
Severity.Val = Serious
TimeStamp.Type = String
TimeStamp.Val = 2017-4-20,6:59:47
ValidTime.Type = Number
ValidTime.Val = 0
VibrationX.Type = Number
VibrationX.Val = 0
VibrationY.Type = Number
VibrationY.Val = 0
VibrationZ.Type = Number
VibrationZ.Val = 135

[1592113924-1720-113]
Severity.Val = Serious
TimeStamp.Val = 2020-6-14,7:52:4
VibrationX.Val = -172
VibrationY.Val = 0
VibrationZ.Val = -113

The summary block at the end lists the totals and an index of all event keys:

[DetectorShockData]
LastKnownGoodTime.Val = 2024-4-4,6:53:59
NumberOfL3Events.Val = 0
NumberOfL5Events.Val = 7
ShockDataTimeList.Val = { 1643260890-1320-119, 163626503500-123,
160818190500-101, 160524243000170, 1592113924-1720-113,
157804584600183, 149266438700135 }

===Interpreting the records===

The record key encodes the event time and the peak axis values (an epoch style
timestamp followed by the concatenated vibration readings), so it is unique per
event. The VibrationX, VibrationY, and VibrationZ values are signed peak
acceleration counts on each axis. Severity is reported as Serious for all
logged events on this unit, which corresponds to the L5 (highest) severity class
counted in the summary.

The seven recorded events for this detector:

{| class="wikitable"
!Date and time!!VibrationX!!VibrationY!!VibrationZ
|-
|2017-04-20 06:59:47||0||0||135
|-
|2020-01-03 11:04:06||0||0||183
|-
|2020-06-14 07:52:04||-172||0||-113
|-
|2020-11-13 05:40:30||0||0||170
|-
|2020-12-17 06:11:45||0||0||-101
|-
|2021-11-07 07:03:55||0||0||-123
|-
|2022-01-27 06:21:30||-132||0||-119
|}

===Reading the summary fields===

{| class="wikitable"
!Field!!Meaning
|-
|LastKnownGoodTime||Timestamp of the last successful self check (here 2024-04-04), the most recent point at which the detector was known to be operating normally
|-
|NumberOfL3Events||Count of lower severity (L3) shock events; zero on this unit
|-
|NumberOfL5Events||Count of high severity (L5) shock events; seven on this unit, matching the seven records above
|-
|ShockDataTimeList||Index of all stored event keys, newest first
|}

On this example the panel logged seven serious impacts over roughly five years
of field use and last reported a good self check in April 2024.

==FlashPad Detector: Internal Flash Dump and Data Files==

This section documents how the full contents of the detector's internal flash
were extracted over the network and what each recovered file contains. The
detector under test is a GE Optima XR200/220 AMX FlashPad (URP detector,
serial UA45829-7, MAC 40:F4:A0:00:78:4D, firmware 1.6.0.4.2.0.1.3).

===Background===

The detector's main storage is a Spansion/Cypress S29GL512P (marked
GL512P10FFCR2), a 512 Mbit (64 MB) parallel NOR flash. A direct chip read
requires bus access or desoldering and a programmer. However, the detector
firmware exposes its stored data blobs, including a full image of the flash,
through the read (upload) side of the data transport protocol. This makes a
complete, byte exact dump possible over UDP with no physical access.

===Extraction method===

The upload interface is the read counterpart of the firmware download path and
is non destructive (it only reports and returns data; nothing is written).
Each data category is identified by an 8 bit upload ID:

{| class="wikitable"
!Step!!cmd_type!!host to detector!!detector to host
|-
|Configure||0x13||[uploadId:4 LE]||[status:1][totalSize:4 LE]
|-
|Buffer||0x14||[bufId:4 LE][numBytes:4 LE]||[bufId:4 LE][numBytes:4 LE][data]
|}

A configure request returns status 0 and a total size for a valid ID, or a non
zero status for an unsupported ID. The dump tool sweeps all IDs from 0x00 to
0xFF, and for every readable ID it pulls the full blob in fixed size chunks
(bufId is a zero based chunk index) and writes it to a file. The 64 MB flash
image transfers as 65536 chunks of 1024 bytes.

===Recovered files===

A sweep of the unit returned 18 readable blobs:

{| class="wikitable"
!Upload ID!!Size (bytes)!!Contents
|-
|0xFD||67108864||Full 64 MB NOR flash image
|-
|0xFF||16777216||16 MB region (firmware / FPGA mirror or image buffer)
|-
|0xFE||524288||Bootloader (512 KB; SPI loader, Nios reset code)
|-
|0x10||6815783||Calibration map, dose level 1
|-
|0x11||6815783||Calibration map, dose level 2
|-
|0x12||6815783||Calibration map, dose level 3
|-
|0x06||49254||Table referencing conditioner/generator serial UA2010-8U005
|-
|0x50||19938||Per mode calibration coefficients
|-
|0x51||19582||Per mode calibration coefficients
|-
|0x07||12187||Sensor conversion table (text; see Sensor Readout)
|-
|0x72||3001||Shock / drop event log (text)
|-
|0x0E||624||Panel geometry / configuration (binary)
|-
|0x71||504||Host list / registration record (see Host Registration)
|-
|0x0F||233||Host to detector compatibility table (text)
|-
|0x08||62||Serial and model strings
|-
|0x0A||48||Manufacturing codes
|-
|0x52||30||Serial string
|-
|0x0B||24||Small marker / identifier
|}

===Flash image layout (upload ID 0xFD)===

A block scan of the 64 MB image shows the following regions:

{| class="wikitable"
!Range!!Contents
|-
|0x000000 to 0x800000||Firmware and FPGA configuration
|-
|0x800000 to 0x940000||Sparse configuration area
|-
|0x940000||Host list / registration record (matches upload ID 0x71)
|-
|0x1000000 to 0x2800000||Calibration and image data (16 to 40 MB)
|-
|0x2800000 to 0x4000000||Erased / unused (40 to 64 MB)
|}

The host list strings (the DetectorName starShape_green, the registered host
name Haus 207 / ITS, and the unset ConnectionSecretKey placeholder) appear at
0x940000, confirming that the 504 byte 0x71 read maps to this flash region.

===Notes on individual files===

*'''0x07 (sensor table)''': plain text, header DetectorSerialNumber = UA45829-7, revision 1.2. Lists every sensor by name, command (0x7902), and sensorId. Also carries panel geometry in its [Common] section: 16 bit depth, 2048 by 2048 pixels, active area from (12, 12) to (2035, 2035), pixel pitch 0.2 mm, corner radius 1416.8, panel saturation 150.
*'''0x10, 0x11, 0x12 (calibration maps)''': three distinct blobs of identical size, corresponding to the low, medium, and high dose calibration sets. Each begins with the firmware version and serial (header bytes 01 06 00 04 02 00 01 03 followed by the serial). Required to apply gain and offset correction to raw images.
*'''0xFE (bootloader)''': contains the strings spi_load.S and ../../boot and Nios II reset vector code.
*'''0x72 (shock log)''': text records of drop / vibration events with timestamps and per axis values; the same data is mirrored in the detector's small onboard EEPROM.
*'''0x06''': references a different serial, UA2010-8U005, likely the conditioner or generator board rather than the panel.

===Significance===

The complete flash image and all calibration data are recoverable over the
network without opening the detector, providing a full byte exact backup of the
unit before any write operation. The calibration maps are needed for image
correction, and the firmware image (the live, deployed build) is more complete
than the partial firmware files shipped on the recovery media.

===Known Dead Ends===

Things that were tried and did not work or led nowhere:

;0xBEEF (48879) as reply port
:This was a bug in early test scripts. The port has no meaning in the protocol. Use 5550.

;CmdFlag=1 as data packet flag
:Early scripts had the URP fields swapped, setting CmdFlag=1 on data packets. The detector ignores all PDAP content in these packets. Power cycle the detector if this happened, it may retain stale port state.

;Image data on alternate ports
:Tried listening on 48879, 6660, 5550, 8100, 1050, 6661, 9999, 4444, 7000, 7001, 9001. Nothing arrived on any of them.

;PORT_SETUP byte order (big-endian)
:Current implementation sends port fields as big-endian. If the detector reads them as little-endian it computes port 44565 and 1050 instead of 5550 and 6660, which would explain why no image data arrives. Not yet confirmed.

;Image data streaming automatically after EXECUTE_SCRIPT
:Frames may not push during execution at all. The detector may require an explicit IMAGE_RETRIVAL_REQUEST (cmd_type=0x41) and IMAGE_RETRIVAL (cmd_type=0x98) after the 0x30000 notification before it streams anything. Not yet tested.

==Teardown / Internal Pictures / Hardware analysis==
<div style="float:left; display:flex; gap:8px;">
[[File:GE Flashpad under the hood.jpg|thumb|none|220px|the Carbon fiber sleeve is held by 9 screws and can taken off without force.]]
[[File:Ge flashpad powersupply pcb in handle.jpg|thumb|none|220px|Power supply PCB]]
[[File:Ge flashpad uwb board pcb.jpg|thumb|none|220px|UWB PCB for Wireless USB using a RTU2705]]
[[File:Ge flashpad uwb pcb backside.jpg|thumb|Backside of UWB PCB]]
</div>
<div style="float:left; display:flex; gap:8px;">
[[File:Ge flashpad power supply pcb backside.jpg|thumb|Backside of Power supply PCB]]
[[File:Ge flashpad main pcb closeup1.jpg|thumb|Main area of the PCB with its Altera Cyclone 3 FPGA]]
[[File:Ge flashpad main pcb closeup2.jpg|thumb|AD7892 is a 600ksps 12bit ADC, SN74LVC8T245 a 8bit bus transceiver and DG9408EDN a 8ch MUX]]
[[File:Ge flashpad bottom connector ethernet isolation pcb.jpg|thumb|Isolation PCB for bottom connector]]
</div>
<div style="float:left; display:flex; gap:8px;">
[[File:Ge flashpad main pcb powersupply section.jpg|thumb|Powersupply section for FPGA and ROIC]]
[[File:Ge_flashpad_main_pcb_closeup_3.jpg|thumb|AD9764AR 14-Bit, 125 MSPS DAC and DS1682 integrated elapsed-time recorder]]
[[File:Ge flashpad main pcb closeup 4.jpg|thumb|left|Accelerometer is a 834-0500 500G 3 Axis unit. abd TJ500AE SPDT GIGABIT LAN SWITCH]]
[[File:Ge flashpad bottom connector.jpg|thumb|left|bottom connector for docking stand]]
</div>
<div style="float:left; display:flex; gap:8px;">
[[File:Ge flashpad main pcb closeup 5.jpg|thumb|left|Ethernet transformers and ADM34 RS-485/RS-422 Transceiver]]
[[File:Ge flashpad main pcb closeup 6.jpg|thumb|left|Altera EPM570f100c5n CPLD ]]
[[File:Ge flashpad main pcb closeup 7.jpg|thumb|left|Spansion GL512P10FF1R1 512 Mbit NOR flash IC holding everything.]]
[[File:Ge flashpad main pcb closeup 8.jpg|thumb|left|24LC256I 32k EEPROM for storing the accelerometer events.]]
</div>

GE Medical Flashpad Digital Xray Detector

2026-06-11T11:56:26Z

Gamerpaddy: /* Sensor Readout and Host Registration */

==Overview==

The '''GE Flashpad''' is a Digital Radiography image sensor from approximately 2010, originally used in the '''GE Optima 220AMX''' mobile X-ray unit. It was designed to replace analog film in radiology, dramatically reducing image acquisition time from hours to seconds.
[[File:GE Flashpad.jpg|thumb|Flashpad with Anti-Scatter grid (left), manual and recovery dvd for 220amx and tether cord (right)]]
Due to its high original cost and specialized application, used units occasionally appear on professional B2B marketplaces in the $15,000–$50,000 range. On eBay, prices typically fall between $1,500 and $5,000, though units at this price point are often in poor condition and may fail the built-in self-test or not function at all.

{{Note|All findings on this page are based on a single unit and the time spent working on it. Information is subject to speculation and may not be fully accurate.}}

{{Note|[[Artificial intelligence|AI]] assistance was used in writing this page for improved formatting and readability, as well as in the process of finding information, testing, and analyzing firmware dumps and backups.}}

== Purpose and Motivation ==

This project documents the reverse engineering of the GE FlashPad wireless
digital radiography detector used with the Optima XR200/220 AMX mobile X-ray
system, with the goal of freeing these detectors for independent use.
[[File:Xray capture pcb.png|thumb|Xray capture of a PCB for Reverse Engineering]]
Large numbers of these detectors reach the used market, but each one is
cryptographically and administratively bound to its original Optima 220 AMX
console. Once separated from that console, or once the console is
decommissioned, the detector is effectively useless even though the hardware is
fully functional. The aim of this work is to remove that artificial barrier so
that a standalone FlashPad can be paired, configured, and read out by any host,
without the half million dollar console it was sold with.

The intended beneficiaries are:

* Hobbyists, researchers, and engineers who want a high quality flat panel detector for their own imaging projects.
* Veterinary practices, which can put surplus human grade detectors to good use at a fraction of the cost of new equipment.
* Clinics and hospitals in countries and regions where a complete commercial system is unaffordable, allowing serviceable detectors to keep providing diagnostic imaging instead of being scrapped.
[[File:Xray current clamp multimeter.png|thumb|xray of a current clamp multimeter]]
This is done for human good. Every detector returned to service is one less
piece of working medical hardware sent to landfill, and potentially one more
place that can offer X-ray imaging where it otherwise could not.

All files, findings, protocol documentation, and tools produced by this project
are public and open source, so that anyone can study, reproduce, and build on
the work.

==Technical Specifications==
[[File:Ge flashpad tether cable pinout diagram.png|thumb|Pinout Diagram of the Tether cable]]
[[File:Ge flashpad tether wiring for ethernet cable.jpg|thumb|Professional Tether wiring to attach a Ethernet Cable and 12V socket to it.]]
The Flashpad uses a '''~40 × 40 cm CsI scintillator''' bonded to a [[Thin-film transistor|TFT]] photodetector array mounted on glass. The assembly is highly sensitive to shock and impact damage.

{| class="wikitable"
|-
!Parameter!!Value
|-
|Resolution||2048 × 2048 px
|-
|Bit depth||16-bit per pixel
|-
|Spatial resolution||Up to 5 lp/mm (theoretical)
|-
|Scintillator material||Caesium iodide (CsI)
|-
|Detector type||TFT photodetector array (glass substrate)
|-
|Panel size||~40 × 40 cm
|}

The theoretical 5 lp/mm spatial resolution is primarily limited in practice by the focal spot size of the X-ray source. Use of an anti-scatter grid can improve effective resolution.

=== Status of Reverse Engineering ===

{| class="wikitable"
|-
! What !! Status
|-
| Connect, beacon, ACK || Works
|-
| PORT_SETUP || Works
|-
| SIGNATURE_REQUEST / serial number readout || Works
|-
| Script download (Scripts 7, 8, 1) || Works
|-
| EXECUTE_SCRIPT || Works
|-
| EXECUTION_COMPLETE (dark acquisition) || Works
|-
| EXECUTION_COMPLETE (standard acquisition) || Needs real X-ray trigger to test
|-
| Image data on port 6660 || Does not work yet, under investigation. Will not send Imagedata yet.
|}

==Hardware Features==

===Shock logging===
The unit contains an internal accelerometer that logs significant shock events — but only when a battery is inserted. As there is no backup battery, shock events occurring while unpowered are not recorded.

===Wireless connectivity===
Some units include a UWB transmitter for Wireless USB; others may be equipped with a Wi-Fi module instead. The detector can also be operated over the tethered connection alone.

===Ethernet interface===
There is a 100MBit Ethernet interface trough the Tether Cable which can be tapped and used for Communication.
Exposed metal contacts on the bottom connector are isolated via relays by default. Enabling Gigabit Ethernet connectivity requires shorting or driving two specific pins. This has not been investigated further at this time.

== Communication Protocol ==

This section documents the URP/PDAP protocol used by the GE Flashpad (codename '''Apollo''') to communicate with a host over Ethernet. All findings are based on live capture tests, configuration files, and reverse-engineering of the GE SuperBee software stack.

{{Note|All findings are based on a single unit and may not be fully accurate.}}

=== Network Setup ===

All findings were over Ethernet only, no UWB or WIFI has been used.
Default detector IP is <code>192.168.1.30</code>. Set your host to a static IP in the same subnet, <code>192.168.1.1</code> works fine.

At first by sending random bytes over Python it answered to port 48879 (0xBEEF), which seems to be either the default port or set by Python.
After SYSTEM_SETUP it got set to 5550.

{| class="wikitable"
|-
! Role !! IP !! Port !! Direction
|-
| All commands: host -> detector || 192.168.1.30 || '''8100''' (UDP) || Host sends here
|-
| Discovery beacons: detector -> host || - || '''4500''' (UDP) || Detector sends here initially
|-
| Protocol replies: detector -> host || - || '''5550''' (UDP) || Detector sends here after setup
|-
| Image pixel data: detector -> host || - || '''6660''' (UDP) || Detector streams frames here
|}

In practice you can listen on port '''5550''' for everything (beacons and replies) by advertising that port in both <code>SYSTEM_STARTUP</code> and <code>PORT_SETUP</code>. The detector sends to whichever port was most recently configured.

=== Protocol Layers ===

Two layers, carried over UDP:

; URP (Unified Registration Protocol)
: 8-byte wrapper on every packet. Handles sequencing and acknowledgement.

; PDAP (Proprietary Detector Access Protocol)
: The actual command layer, present inside URP packets when <code>CmdFlag = 0</code>.

Every UDP packet starts with a URP header:

<pre>
[SeqId : 4 bytes LE] [CmdFlag : 4 bytes LE]
</pre>

* <code>CmdFlag = 0</code> -- data packet, PDAP command follows.
* <code>CmdFlag = 1</code> -- bare ACK, no PDAP body. SeqId echoes the packet being acknowledged.

Both sides must ACK every data packet immediately. The detector silently drops packets with a SeqId it has already seen, so always increment SeqId for each new command.

When CmdFlag is 0, the PDAP header follows immediately:

<pre>
[cmd_type : 4 bytes LE] [payload_len : 4 bytes LE] [payload ...]
</pre>

=== Connecting to the Detector ===

The connection sequence is:

# Broadcast <code>SYSTEM_STARTUP</code> to tell the detector where to reply.
# The detector sends a <code>BEACON</code> back -- ACK it and sync your sequence counter.
# Send <code>PORT_SETUP</code> to configure the reply and image ports.
# Send <code>SIGNATURE_REQUEST</code> to read the detector identity (serial number, model, firmware, MAC).

==== Step 1: SYSTEM_STARTUP ====

Broadcast UDP to <code>192.168.1.255:8100</code>. Always uses <code>SeqId = 0</code>.

<pre>
URP : [00 00 00 00] SeqId = 0
[00 00 00 00] CmdFlag = 0
PDAP: [01 00 00 00] cmd_type = 1
[06 00 00 00] payload_len = 6
[15 AE] host reply port = 5550 (big-endian)
[C0 A8 01 01] host IP = 192.168.1.1 (network byte order)
</pre>

<syntaxhighlight lang="python">
import socket, struct

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
sock.bind(("0.0.0.0", 5550))

HOST_IP = "192.168.1.1"
DET_IP = "192.168.1.30"
HOST_PORT = 5550
IMG_PORT = 6660

def make_urp_packet(seq_id, pdap_bytes):
return struct.pack("<II", seq_id, 0) + pdap_bytes

pdap = struct.pack("<II", 1, 6) + struct.pack(">H", HOST_PORT) + socket.inet_aton(HOST_IP)
sock.sendto(make_urp_packet(0, pdap), ("192.168.1.255", 8100))
</syntaxhighlight>

==== Step 2: Receiving the BEACON and ACKing ====

The detector broadcasts a <code>BEACON</code> (cmd_type=1) roughly every 2 seconds. After sending SYSTEM_STARTUP you should get one quickly. Parse the detector SeqId from the URP header and ACK it:

<syntaxhighlight lang="python">
data, addr = sock.recvfrom(4096)
det_seq = struct.unpack_from("<I", data, 0)[0]

# send bare ACK
ack = struct.pack("<II", det_seq, 1)
sock.sendto(ack, (DET_IP, 8100))

# all subsequent commands start from here
host_seq = det_seq + 1
</syntaxhighlight>

==== Step 3: PORT_SETUP ====

Tells the detector which host ports to use for replies and image data.

<pre>
PDAP: [02 00 00 00] cmd_type = 2
[04 00 00 00] payload_len = 4
[15 AE] host cmd port = 5550 (big-endian)
[1A 04] host image port = 6660 (big-endian)
</pre>

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 2, 4) + struct.pack(">HH", HOST_PORT, IMG_PORT)
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1
# expect bare ACK from detector
</syntaxhighlight>

==== Step 4: Reading the Serial Number (SIGNATURE_REQUEST) ====

Empty command, the detector replies with a 54-byte payload containing its identity.

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 3, 0) # cmd_type=3, payload_len=0
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1

# reply is 70 bytes total: 8 URP + 8 PDAP header + 54 payload
data, _ = sock.recvfrom(4096)
payload = data[16:] # skip URP (8) + PDAP header (8)

mac = payload[0:6]
serial = payload[22:34].rstrip(b'\x00 ').decode()
model = payload[34:46].rstrip(b'\x00 ').decode()
fw_bytes = payload[46:54]
firmware = ".".join(str(b) for b in fw_bytes)

print(f"MAC: {':'.join(f'{b:02X}' for b in mac)}")
print(f"Serial: {serial}")
print(f"Model: {model}")
print(f"Firmware: {firmware}")
</syntaxhighlight>

Expected output:
<pre>
MAC: 40:F4:A0:00:78:4D
Serial: UA45829-7
Model: 5340000-7
Firmware: 1.6.0.4.2.0.1.3
</pre>

=== Running an Acquisition ===

After the connection sequence above, download scripts to the detector and then execute them.

==== ROE Initialisation (Script 7) ====

Always run this first. It initialises the readout electronics and takes about 4-5 seconds. The detector sends host event ID 17 when done.

==== Dark / Offset Acquisition (Script 1) ====

No X-ray source required. Runs a dark-field exposure for offset calibration. Use this to verify the acquisition pipeline without a generator.

==== Standard Acquisition (Script 0) ====

Requires an actual X-ray exposure. <code>EXECUTION_COMPLETE</code> will '''not''' arrive without a real X-ray trigger.

==== Sequence Overview ====

<pre>
HOST DETECTOR
| |
|-- SYSTEM_STARTUP (broadcast) ----------->|
|<- bare ACK -------------------------------|
|<- BEACON (cmd_type=1) --------------------|
|-- bare ACK ------------------------------>|
| |
|-- PORT_SETUP (cmd_type=2) -------------->|
|<- bare ACK -------------------------------|
| |
|-- SIGNATURE_REQUEST (cmd_type=3) ------->|
|<- SIGNATURE_REPLY (54 bytes) -------------|
|-- bare ACK ------------------------------>|
| |
|-- GENERIC_SCRIPT Script7 (ROE init) ---->|
|<- bare ACK or SCRIPT_DOWNLOAD_REPLY ------|
| |
|-- GENERIC_SCRIPT Script1 (dark acq) ---->|
|<- bare ACK -------------------------------|
| |
|-- EXECUTE_SCRIPT (cmd_type=6) ---------->|
|<- bare ACK -------------------------------|
|<- EXECUTE_SCRIPT_REPLY (~230ms) ----------|
|-- bare ACK ------------------------------>|
|<- DETECTOR_STATE_NOTIFY (~890ms) ---------| state_id=17
|-- bare ACK ------------------------------>|
| |
|<- EXECUTION_COMPLETE (0x10000) -----------|
|-- bare ACK ------------------------------>|
| |
|<- IMAGE_XFER_STATUS_QUERY (0x30000) ------|
|-- bare ACK ------------------------------>|
|-- IMAGE_XFER_STATUS_REPLY (cmd_type=9) ->| numMissed=0
|<- bare ACK -------------------------------|
</pre>

=== Sequence Counter Rules ===

* <code>SYSTEM_STARTUP</code> always uses <code>SeqId = 0</code>.
* After the first beacon, set host SeqId to beacon_SeqId + 1.
* Increment SeqId by 1 for every new data packet (CmdFlag=0).
* Bare ACKs echo the SeqId of the packet being acknowledged and do not consume a SeqId.
* The detector silently drops any packet with a SeqId it has already processed, so never reuse one.

== Sensor Readout and Host Registration ==

This section documents the reverse engineered sensor telemetry interface and the
host registration (pairing) mechanism of the GE Optima XR200/220 AMX FlashPad
(URP detector, SuperBee, FW 1.6.0.4.2.0.1.3). All commands are PDAP over UDP to
the detector at port 8100; replies return to the host command port.

=== Sensor Readout ===

The detector exposes an analog sensor interface (the DEM, Detector Environment
Monitor) that is independent of the image transfer path and works regardless of
acquisition state.

==== Commands ====

{| class="wikitable"
! cmd_type !! Meaning !! Request payload !! Reply payload
|-
| 0x7900 || Raw sensor read || [sensorId:4 LE] || [value:4 LE] (12 bit ADC count)
|-
| 0x7902 || Converted sensor read || [sensorId:4 LE] || [value:4 LE] (engineering units, signed)
|-
| 0x7904 || Detailed / radio || [selector:4 LE] || [value:4 LE]
|}

Note: cmd 0x7902 IS supported on this firmware and returns calibrated
engineering units (millivolts for the supply rails, signed; 0.1 degree C for
temperatures). Earlier documentation that marked 0x7902 as unsupported is
incorrect. The host side conversion coefficients are not required; the detector
performs the conversion internally.

The full sensor map (name, sensorId) was recovered from the detector's own
[Sensor] configuration table, read back over the upload interface (see the
Registration section for the read protocol).

==== Power rails (live readings) ====

All supply rails read correctly via 0x7902 and are within normal range for a
flat panel detector. Representative readings:

{| class="wikitable"
! Sensor !! sensorId !! Converted !! Value
|-
| DCIN_RAW || 10 || 12100 mV || +12.10 V (main DC input)
|-
| LCORE_UNREG || 11 || 1724 mV || +1.72 V
|-
| LPANA_UNREG || 12 || 5776 mV || +5.78 V
|-
| LNANA_UNREG || 13 || -5801 mV || -5.80 V
|-
| SCAN_VCC || 14 || 5086 mV || +5.09 V (gate driver)
|-
| P5V_REF || 16 || 5025 mV || +5.03 V (5 V reference)
|-
| V_ON || 17 || 11085 mV || +11.09 V (TFT gate on)
|-
| V_OFF || 18 || -12378 mV || -12.38 V (TFT gate off)
|-
| V_COMMON || 19 || -9385 mV || -9.39 V
|-
| 3V3 || 29 || 3177 mV || +3.18 V (3.3 V logic)
|-
| VCC_UNREG || 37 || 3399 mV || +3.40 V
|-
| PARCPREG || 38 || 3768 mV || +3.77 V (ARC preamp +)
|-
| NARCPREG || 39 || -3732 mV || -3.73 V (ARC preamp -)
|-
| PANA_UNREG || 45 || 18352 mV || +18.35 V (photodiode bias +)
|-
| NANA_UNREG || 46 || -19251 mV || -19.25 V (photodiode bias -)
|}

Switched rails that are inactive while the panel is idle (PARCVA_U,
P5VA_SW, N5VA_SW, FGATE_NVC_L, FGATE_PVC_L, etc.) read at or near zero.

==== Known limitations ====

* '''Temperatures''' (Temp_Surface, sensorId 336; Temp_Panel, sensorId 352): the raw 0x7900 read rails at 0x3FF (1023, the ADC maximum), indicating an open thermistor path while the panel is idle. This is a hardware/state condition, not a command problem, and the temperature is not readable from the host in this state.
* '''Unimplemented sensors''': sensorIds 70 (Accelerator), 78 (Gravity), and 256 to 259 (Battery status, name, life, capacity), and 272 (Grid status) are not implemented on this DEM. The detector returns the leftover conversion register contents (a duplicate of a previously read sensor) rather than a real value, so these rows must be discarded.
* '''Accelerometer''': functional through a separate addressing scheme using raw cmd 0x7900 with selectors 0x42 (X), 0x43 (Y), 0x44 (Z), returning 12 bit per axis counts.

=== Host Registration (Pairing) ===

URP stands for Unified Registration Protocol. The detector maintains a host
list in its internal NOR flash. Image data is delivered only to a registered
primary host, so registration is a prerequisite for image transfer.

==== Host identity (MAC and HostId) ====

Each host is identified by a 16 character HostId derived deterministically from
the host's eth0 MAC address. The derivation (from the vendor generateHostId
script) is:

# Take the eth0 MAC, remove the colon separators, convert to upper case (12 hex characters).
# Prepend the last 4 characters to the full 12 characters.
# The result is 16 hex characters.

Example: MAC 00:6f:00:01:0a:3a becomes 006F00010A3A, then the last four (0A3A)
are prepended, giving HostId 0A3A006F00010A3A.

==== HostList structure ====

The host list is stored in flash at offset 0x940000 and can be read back over
the upload interface as data category 0x71. Layout:

Offset Size Field
0x00 16 DetectorDeviceId (ASCII)
0x10 16 ConnectionSecretKey (ASCII; "XXXXXXXXXXXXXXXX" when unset)
0x20 16 DetectorName (ASCII)
0x30 16 DetectorCode (ASCII)
0x40 2 CurrentNumberOfHosts (uint16 LE)
0x42 2 IndexToPrimaryHost (uint16 LE; 0xFFFF = none)
0x44 144*N Host entries, 144 bytes each:
+0x00 16 HostId (ASCII)
+0x10 .. host name / department string
+0x50 .. location string
... 4 CRC (big endian; see below)

==== HostList from the unit under test ====

Detector: MAC 40:F4:A0:00:78:4D, serial UA45829-7, model 5340000-7,
firmware 1.6.0.4.2.0.1.3. DetectorName starShape_green. ConnectionSecretKey
unset. CurrentNumberOfHosts = 3, IndexToPrimaryHost = 0xFFFF (no primary host).

{| class="wikitable"
! Index !! HostId !! Derived MAC !! Name
|-
| 0 || 2C6400045FB42C64 || 00:04:5F:B4:2C:64 || Haus 207 / ITS
|-
| 1 || B044E8393512B044 || E8:39:35:12:B0:44 || Not Initialized
|-
| 2 || 5CF800045FB15CF8 || 00:04:5F:B1:5C:F8 || Not_Initialized
|}

The unit is therefore not factory fresh; it carries registrations from a prior
deployment, but no primary host is currently designated.

==== Checksum (CRC) ====

The HostList (and other flash data blobs) are protected by a 4 byte trailing
CRC. Parameters:

* Polynomial: 0x04C11DB7
* Initial value: 0
* MSB first, augmented message style (the data bit is shifted into the LSB; no input or output reflection; no final XOR)
* Stored big endian

To generate: compute the CRC over the data followed by four zero bytes, then
append the result big endian. Verification: the CRC over (data plus stored CRC)
equals zero.

def crc(data, poly=0x04C11DB7, init=0):
c = init
for byte in data:
for bit in (0x80,0x40,0x20,0x10,0x08,0x04,0x02,0x01):
msb = c & 0x80000000
c = (c << 1) & 0xFFFFFFFF
if byte & bit: c |= 1
if msb: c ^= poly
return c
# trailer = crc(data + b"\x00\x00\x00\x00"), stored big endian

==== Read and write transport ====

Data blobs (including the HostList) are moved with a configure / buffer /
finalize sequence.

Read (upload, detector to host), non destructive:

{| class="wikitable"
! Step !! cmd_type !! host to detector !! detector to host
|-
| Configure || 0x13 || [uploadId:4 LE] || [status:1][totalSize:4 LE]
|-
| Buffer || 0x14 || [bufId:4 LE][numBytes:4 LE] || [bufId:4 LE][numBytes:4 LE][data]
|}

Write (download, host to detector), persistent (writes flash):

{| class="wikitable"
! Step !! cmd_type !! host to detector !! detector to host
|-
| Configure || 0x0E || [downloadId:4 LE][totalSize:4 LE] || [status:1]
|-
| Buffer || 0x0F || [bufId:4 LE][numBytes:4 LE][data] || [status:1][reserved:4]
|-
| Commit || 0x10 || (empty) || [status:1]
|}

bufId is a zero based chunk index. The HostList uses id 0x71 for both read and
write. The commit command (0x10) reuses the firmware flash path, so a malformed
download can corrupt flash; the operation is irreversible on this hardware.

==== Registering a new host ====

To register a host and make it the image destination, read the current HostList
(0x71), append a 144 byte entry carrying the new HostId, increment
CurrentNumberOfHosts, set IndexToPrimaryHost to the new entry's index,
recompute the trailing CRC, and write the blob back via the download sequence
(0x0E / 0x0F / 0x10).

== Reading the Drop and Shock Event Log ==

The detector contains an accelerometer based shock watchdog that records drop
and impact events into non volatile memory. This log is useful when evaluating a
used unit, since it reveals how many serious shocks the panel has survived and
when. The same data is held both in the main flash (read over the network) and
in the small onboard EEPROM on the detector PCB.

=== How to read it ===

The shock log is exposed as data category 0x72 on the upload (read) interface.
It is retrieved with the standard non destructive configure and buffer sequence
(cmd 0x13 to configure, cmd 0x14 to pull the chunks). On the unit under test the
blob is 3001 bytes of plain text in the GE .dyn configuration format, so no
decoding is required beyond reading it as ASCII.

The same records are mirrored in binary form in the onboard 24LC256 EEPROM
(32 KB I2C part) for anyone reading the hardware directly.

=== Example output ===

The following is the actual log read from detector serial UA45829-7. The file
has two parts: a list of individual events (DetectorShockEvents) and a summary
block (DetectorShockData). Each event carries a record key, a severity, a
timestamp, and the peak acceleration on each axis. Two representative records:

<DetectorShockEvents>
[149266438700135]
Severity.Type = String
Severity.Val = Serious
TimeStamp.Type = String
TimeStamp.Val = 2017-4-20,6:59:47
ValidTime.Type = Number
ValidTime.Val = 0
VibrationX.Type = Number
VibrationX.Val = 0
VibrationY.Type = Number
VibrationY.Val = 0
VibrationZ.Type = Number
VibrationZ.Val = 135

[1592113924-1720-113]
Severity.Val = Serious
TimeStamp.Val = 2020-6-14,7:52:4
VibrationX.Val = -172
VibrationY.Val = 0
VibrationZ.Val = -113

The summary block at the end lists the totals and an index of all event keys:

[DetectorShockData]
LastKnownGoodTime.Val = 2024-4-4,6:53:59
NumberOfL3Events.Val = 0
NumberOfL5Events.Val = 7
ShockDataTimeList.Val = { 1643260890-1320-119, 163626503500-123,
160818190500-101, 160524243000170, 1592113924-1720-113,
157804584600183, 149266438700135 }

=== Interpreting the records ===

The record key encodes the event time and the peak axis values (an epoch style
timestamp followed by the concatenated vibration readings), so it is unique per
event. The VibrationX, VibrationY, and VibrationZ values are signed peak
acceleration counts on each axis. Severity is reported as Serious for all
logged events on this unit, which corresponds to the L5 (highest) severity class
counted in the summary.

The seven recorded events for this detector:

{| class="wikitable"
! Date and time !! VibrationX !! VibrationY !! VibrationZ
|-
| 2017-04-20 06:59:47 || 0 || 0 || 135
|-
| 2020-01-03 11:04:06 || 0 || 0 || 183
|-
| 2020-06-14 07:52:04 || -172 || 0 || -113
|-
| 2020-11-13 05:40:30 || 0 || 0 || 170
|-
| 2020-12-17 06:11:45 || 0 || 0 || -101
|-
| 2021-11-07 07:03:55 || 0 || 0 || -123
|-
| 2022-01-27 06:21:30 || -132 || 0 || -119
|}

=== Reading the summary fields ===

{| class="wikitable"
! Field !! Meaning
|-
| LastKnownGoodTime || Timestamp of the last successful self check (here 2024-04-04), the most recent point at which the detector was known to be operating normally
|-
| NumberOfL3Events || Count of lower severity (L3) shock events; zero on this unit
|-
| NumberOfL5Events || Count of high severity (L5) shock events; seven on this unit, matching the seven records above
|-
| ShockDataTimeList || Index of all stored event keys, newest first
|}

On this example the panel logged seven serious impacts over roughly five years
of field use and last reported a good self check in April 2024.

== FlashPad Detector: Internal Flash Dump and Data Files ==

This section documents how the full contents of the detector's internal flash
were extracted over the network and what each recovered file contains. The
detector under test is a GE Optima XR200/220 AMX FlashPad (URP detector,
serial UA45829-7, MAC 40:F4:A0:00:78:4D, firmware 1.6.0.4.2.0.1.3).

=== Background ===

The detector's main storage is a Spansion/Cypress S29GL512P (marked
GL512P10FFCR2), a 512 Mbit (64 MB) parallel NOR flash. A direct chip read
requires bus access or desoldering and a programmer. However, the detector
firmware exposes its stored data blobs, including a full image of the flash,
through the read (upload) side of the data transport protocol. This makes a
complete, byte exact dump possible over UDP with no physical access.

=== Extraction method ===

The upload interface is the read counterpart of the firmware download path and
is non destructive (it only reports and returns data; nothing is written).
Each data category is identified by an 8 bit upload ID:

{| class="wikitable"
! Step !! cmd_type !! host to detector !! detector to host
|-
| Configure || 0x13 || [uploadId:4 LE] || [status:1][totalSize:4 LE]
|-
| Buffer || 0x14 || [bufId:4 LE][numBytes:4 LE] || [bufId:4 LE][numBytes:4 LE][data]
|}

A configure request returns status 0 and a total size for a valid ID, or a non
zero status for an unsupported ID. The dump tool sweeps all IDs from 0x00 to
0xFF, and for every readable ID it pulls the full blob in fixed size chunks
(bufId is a zero based chunk index) and writes it to a file. The 64 MB flash
image transfers as 65536 chunks of 1024 bytes.

=== Recovered files ===

A sweep of the unit returned 18 readable blobs:

{| class="wikitable"
! Upload ID !! Size (bytes) !! Contents
|-
| 0xFD || 67108864 || Full 64 MB NOR flash image
|-
| 0xFF || 16777216 || 16 MB region (firmware / FPGA mirror or image buffer)
|-
| 0xFE || 524288 || Bootloader (512 KB; SPI loader, Nios reset code)
|-
| 0x10 || 6815783 || Calibration map, dose level 1
|-
| 0x11 || 6815783 || Calibration map, dose level 2
|-
| 0x12 || 6815783 || Calibration map, dose level 3
|-
| 0x06 || 49254 || Table referencing conditioner/generator serial UA2010-8U005
|-
| 0x50 || 19938 || Per mode calibration coefficients
|-
| 0x51 || 19582 || Per mode calibration coefficients
|-
| 0x07 || 12187 || Sensor conversion table (text; see Sensor Readout)
|-
| 0x72 || 3001 || Shock / drop event log (text)
|-
| 0x0E || 624 || Panel geometry / configuration (binary)
|-
| 0x71 || 504 || Host list / registration record (see Host Registration)
|-
| 0x0F || 233 || Host to detector compatibility table (text)
|-
| 0x08 || 62 || Serial and model strings
|-
| 0x0A || 48 || Manufacturing codes
|-
| 0x52 || 30 || Serial string
|-
| 0x0B || 24 || Small marker / identifier
|}

=== Flash image layout (upload ID 0xFD) ===

A block scan of the 64 MB image shows the following regions:

{| class="wikitable"
! Range !! Contents
|-
| 0x000000 to 0x800000 || Firmware and FPGA configuration
|-
| 0x800000 to 0x940000 || Sparse configuration area
|-
| 0x940000 || Host list / registration record (matches upload ID 0x71)
|-
| 0x1000000 to 0x2800000 || Calibration and image data (16 to 40 MB)
|-
| 0x2800000 to 0x4000000 || Erased / unused (40 to 64 MB)
|}

The host list strings (the DetectorName starShape_green, the registered host
name Haus 207 / ITS, and the unset ConnectionSecretKey placeholder) appear at
0x940000, confirming that the 504 byte 0x71 read maps to this flash region.

=== Notes on individual files ===

* '''0x07 (sensor table)''': plain text, header DetectorSerialNumber = UA45829-7, revision 1.2. Lists every sensor by name, command (0x7902), and sensorId. Also carries panel geometry in its [Common] section: 16 bit depth, 2048 by 2048 pixels, active area from (12, 12) to (2035, 2035), pixel pitch 0.2 mm, corner radius 1416.8, panel saturation 150.
* '''0x10, 0x11, 0x12 (calibration maps)''': three distinct blobs of identical size, corresponding to the low, medium, and high dose calibration sets. Each begins with the firmware version and serial (header bytes 01 06 00 04 02 00 01 03 followed by the serial). Required to apply gain and offset correction to raw images.
* '''0xFE (bootloader)''': contains the strings spi_load.S and ../../boot and Nios II reset vector code.
* '''0x72 (shock log)''': text records of drop / vibration events with timestamps and per axis values; the same data is mirrored in the detector's small onboard EEPROM.
* '''0x06''': references a different serial, UA2010-8U005, likely the conditioner or generator board rather than the panel.

=== Significance ===

The complete flash image and all calibration data are recoverable over the
network without opening the detector, providing a full byte exact backup of the
unit before any write operation. The calibration maps are needed for image
correction, and the firmware image (the live, deployed build) is more complete
than the partial firmware files shipped on the recovery media.

=== Known Dead Ends ===

Things that were tried and did not work or led nowhere:

; 0xBEEF (48879) as reply port
: This was a bug in early test scripts. The port has no meaning in the protocol. Use 5550.

; CmdFlag=1 as data packet flag
: Early scripts had the URP fields swapped, setting CmdFlag=1 on data packets. The detector ignores all PDAP content in these packets. Power cycle the detector if this happened, it may retain stale port state.

; Image data on alternate ports
: Tried listening on 48879, 6660, 5550, 8100, 1050, 6661, 9999, 4444, 7000, 7001, 9001. Nothing arrived on any of them.

; PORT_SETUP byte order (big-endian)
: Current implementation sends port fields as big-endian. If the detector reads them as little-endian it computes port 44565 and 1050 instead of 5550 and 6660, which would explain why no image data arrives. Not yet confirmed.

; Image data streaming automatically after EXECUTE_SCRIPT
: Frames may not push during execution at all. The detector may require an explicit IMAGE_RETRIVAL_REQUEST (cmd_type=0x41) and IMAGE_RETRIVAL (cmd_type=0x98) after the 0x30000 notification before it streams anything. Not yet tested.

== Teardown / Internal Pictures / Hardware analysis ==
<div style="float:left; display:flex; gap:8px;">
[[File:GE Flashpad under the hood.jpg|thumb|none|220px|the Carbon fiber sleeve is held by 9 screws and can taken off without force.]]
[[File:Ge flashpad powersupply pcb in handle.jpg|thumb|none|220px|Power supply PCB]]
[[File:Ge flashpad uwb board pcb.jpg|thumb|none|220px|UWB PCB for Wireless USB using a RTU2705]]
[[File:Ge flashpad uwb pcb backside.jpg|thumb|Backside of UWB PCB]]
</div>
<div style="float:left; display:flex; gap:8px;">
[[File:Ge flashpad power supply pcb backside.jpg|thumb|Backside of Power supply PCB]]
[[File:Ge flashpad main pcb closeup1.jpg|thumb|Main area of the PCB with its Altera Cyclone 3 FPGA]]
[[File:Ge flashpad main pcb closeup2.jpg|thumb|AD7892 is a 600ksps 12bit ADC, SN74LVC8T245 a 8bit bus transceiver and DG9408EDN a 8ch MUX]]
[[File:Ge flashpad bottom connector ethernet isolation pcb.jpg|thumb|Isolation PCB for bottom connector]]
</div>
<div style="float:left; display:flex; gap:8px;">
[[File:Ge flashpad main pcb powersupply section.jpg|thumb|Powersupply section for FPGA and ROIC]]
[[File:Ge_flashpad_main_pcb_closeup_3.jpg|thumb|AD9764AR 14-Bit, 125 MSPS DAC and DS1682 integrated elapsed-time recorder]]
[[File:Ge flashpad main pcb closeup 4.jpg|thumb|left|Accelerometer is a 834-0500 500G 3 Axis unit. abd TJ500AE SPDT GIGABIT LAN SWITCH]]
[[File:Ge flashpad bottom connector.jpg|thumb|left|bottom connector for docking stand]]
</div>
<div style="float:left; display:flex; gap:8px;">
[[File:Ge flashpad main pcb closeup 5.jpg|thumb|left|Ethernet transformers and ADM34 RS-485/RS-422 Transceiver]]
[[File:Ge flashpad main pcb closeup 6.jpg|thumb|left|Altera EPM570f100c5n CPLD ]]
[[File:Ge flashpad main pcb closeup 7.jpg|thumb|left|Spansion GL512P10FF1R1 512 Mbit NOR flash IC holding everything.]]
[[File:Ge flashpad main pcb closeup 8.jpg|thumb|left|24LC256I 32k EEPROM for storing the accelerometer events.]]
</div>

GE Medical Flashpad Digital Xray Detector

2026-06-11T11:55:30Z

Gamerpaddy: /* Teardown / Internal Pictures / Hardware analysis */

==Overview==

The '''GE Flashpad''' is a Digital Radiography image sensor from approximately 2010, originally used in the '''GE Optima 220AMX''' mobile X-ray unit. It was designed to replace analog film in radiology, dramatically reducing image acquisition time from hours to seconds.
[[File:GE Flashpad.jpg|thumb|Flashpad with Anti-Scatter grid (left), manual and recovery dvd for 220amx and tether cord (right)]]
Due to its high original cost and specialized application, used units occasionally appear on professional B2B marketplaces in the $15,000–$50,000 range. On eBay, prices typically fall between $1,500 and $5,000, though units at this price point are often in poor condition and may fail the built-in self-test or not function at all.

{{Note|All findings on this page are based on a single unit and the time spent working on it. Information is subject to speculation and may not be fully accurate.}}

{{Note|[[Artificial intelligence|AI]] assistance was used in writing this page for improved formatting and readability, as well as in the process of finding information, testing, and analyzing firmware dumps and backups.}}

== Purpose and Motivation ==

This project documents the reverse engineering of the GE FlashPad wireless
digital radiography detector used with the Optima XR200/220 AMX mobile X-ray
system, with the goal of freeing these detectors for independent use.
[[File:Xray capture pcb.png|thumb|Xray capture of a PCB for Reverse Engineering]]
Large numbers of these detectors reach the used market, but each one is
cryptographically and administratively bound to its original Optima 220 AMX
console. Once separated from that console, or once the console is
decommissioned, the detector is effectively useless even though the hardware is
fully functional. The aim of this work is to remove that artificial barrier so
that a standalone FlashPad can be paired, configured, and read out by any host,
without the half million dollar console it was sold with.

The intended beneficiaries are:

* Hobbyists, researchers, and engineers who want a high quality flat panel detector for their own imaging projects.
* Veterinary practices, which can put surplus human grade detectors to good use at a fraction of the cost of new equipment.
* Clinics and hospitals in countries and regions where a complete commercial system is unaffordable, allowing serviceable detectors to keep providing diagnostic imaging instead of being scrapped.
[[File:Xray current clamp multimeter.png|thumb|xray of a current clamp multimeter]]
This is done for human good. Every detector returned to service is one less
piece of working medical hardware sent to landfill, and potentially one more
place that can offer X-ray imaging where it otherwise could not.

All files, findings, protocol documentation, and tools produced by this project
are public and open source, so that anyone can study, reproduce, and build on
the work.

==Technical Specifications==
[[File:Ge flashpad tether cable pinout diagram.png|thumb|Pinout Diagram of the Tether cable]]
[[File:Ge flashpad tether wiring for ethernet cable.jpg|thumb|Professional Tether wiring to attach a Ethernet Cable and 12V socket to it.]]
The Flashpad uses a '''~40 × 40 cm CsI scintillator''' bonded to a [[Thin-film transistor|TFT]] photodetector array mounted on glass. The assembly is highly sensitive to shock and impact damage.

{| class="wikitable"
|-
!Parameter!!Value
|-
|Resolution||2048 × 2048 px
|-
|Bit depth||16-bit per pixel
|-
|Spatial resolution||Up to 5 lp/mm (theoretical)
|-
|Scintillator material||Caesium iodide (CsI)
|-
|Detector type||TFT photodetector array (glass substrate)
|-
|Panel size||~40 × 40 cm
|}

The theoretical 5 lp/mm spatial resolution is primarily limited in practice by the focal spot size of the X-ray source. Use of an anti-scatter grid can improve effective resolution.

=== Status of Reverse Engineering ===

{| class="wikitable"
|-
! What !! Status
|-
| Connect, beacon, ACK || Works
|-
| PORT_SETUP || Works
|-
| SIGNATURE_REQUEST / serial number readout || Works
|-
| Script download (Scripts 7, 8, 1) || Works
|-
| EXECUTE_SCRIPT || Works
|-
| EXECUTION_COMPLETE (dark acquisition) || Works
|-
| EXECUTION_COMPLETE (standard acquisition) || Needs real X-ray trigger to test
|-
| Image data on port 6660 || Does not work yet, under investigation. Will not send Imagedata yet.
|}

==Hardware Features==

===Shock logging===
The unit contains an internal accelerometer that logs significant shock events — but only when a battery is inserted. As there is no backup battery, shock events occurring while unpowered are not recorded.

===Wireless connectivity===
Some units include a UWB transmitter for Wireless USB; others may be equipped with a Wi-Fi module instead. The detector can also be operated over the tethered connection alone.

===Ethernet interface===
There is a 100MBit Ethernet interface trough the Tether Cable which can be tapped and used for Communication.
Exposed metal contacts on the bottom connector are isolated via relays by default. Enabling Gigabit Ethernet connectivity requires shorting or driving two specific pins. This has not been investigated further at this time.

== Communication Protocol ==

This section documents the URP/PDAP protocol used by the GE Flashpad (codename '''Apollo''') to communicate with a host over Ethernet. All findings are based on live capture tests, configuration files, and reverse-engineering of the GE SuperBee software stack.

{{Note|All findings are based on a single unit and may not be fully accurate.}}

=== Network Setup ===

All findings were over Ethernet only, no UWB or WIFI has been used.
Default detector IP is <code>192.168.1.30</code>. Set your host to a static IP in the same subnet, <code>192.168.1.1</code> works fine.

At first by sending random bytes over Python it answered to port 48879 (0xBEEF), which seems to be either the default port or set by Python.
After SYSTEM_SETUP it got set to 5550.

{| class="wikitable"
|-
! Role !! IP !! Port !! Direction
|-
| All commands: host -> detector || 192.168.1.30 || '''8100''' (UDP) || Host sends here
|-
| Discovery beacons: detector -> host || - || '''4500''' (UDP) || Detector sends here initially
|-
| Protocol replies: detector -> host || - || '''5550''' (UDP) || Detector sends here after setup
|-
| Image pixel data: detector -> host || - || '''6660''' (UDP) || Detector streams frames here
|}

In practice you can listen on port '''5550''' for everything (beacons and replies) by advertising that port in both <code>SYSTEM_STARTUP</code> and <code>PORT_SETUP</code>. The detector sends to whichever port was most recently configured.

=== Protocol Layers ===

Two layers, carried over UDP:

; URP (Unified Registration Protocol)
: 8-byte wrapper on every packet. Handles sequencing and acknowledgement.

; PDAP (Proprietary Detector Access Protocol)
: The actual command layer, present inside URP packets when <code>CmdFlag = 0</code>.

Every UDP packet starts with a URP header:

<pre>
[SeqId : 4 bytes LE] [CmdFlag : 4 bytes LE]
</pre>

* <code>CmdFlag = 0</code> -- data packet, PDAP command follows.
* <code>CmdFlag = 1</code> -- bare ACK, no PDAP body. SeqId echoes the packet being acknowledged.

Both sides must ACK every data packet immediately. The detector silently drops packets with a SeqId it has already seen, so always increment SeqId for each new command.

When CmdFlag is 0, the PDAP header follows immediately:

<pre>
[cmd_type : 4 bytes LE] [payload_len : 4 bytes LE] [payload ...]
</pre>

=== Connecting to the Detector ===

The connection sequence is:

# Broadcast <code>SYSTEM_STARTUP</code> to tell the detector where to reply.
# The detector sends a <code>BEACON</code> back -- ACK it and sync your sequence counter.
# Send <code>PORT_SETUP</code> to configure the reply and image ports.
# Send <code>SIGNATURE_REQUEST</code> to read the detector identity (serial number, model, firmware, MAC).

==== Step 1: SYSTEM_STARTUP ====

Broadcast UDP to <code>192.168.1.255:8100</code>. Always uses <code>SeqId = 0</code>.

<pre>
URP : [00 00 00 00] SeqId = 0
[00 00 00 00] CmdFlag = 0
PDAP: [01 00 00 00] cmd_type = 1
[06 00 00 00] payload_len = 6
[15 AE] host reply port = 5550 (big-endian)
[C0 A8 01 01] host IP = 192.168.1.1 (network byte order)
</pre>

<syntaxhighlight lang="python">
import socket, struct

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
sock.bind(("0.0.0.0", 5550))

HOST_IP = "192.168.1.1"
DET_IP = "192.168.1.30"
HOST_PORT = 5550
IMG_PORT = 6660

def make_urp_packet(seq_id, pdap_bytes):
return struct.pack("<II", seq_id, 0) + pdap_bytes

pdap = struct.pack("<II", 1, 6) + struct.pack(">H", HOST_PORT) + socket.inet_aton(HOST_IP)
sock.sendto(make_urp_packet(0, pdap), ("192.168.1.255", 8100))
</syntaxhighlight>

==== Step 2: Receiving the BEACON and ACKing ====

The detector broadcasts a <code>BEACON</code> (cmd_type=1) roughly every 2 seconds. After sending SYSTEM_STARTUP you should get one quickly. Parse the detector SeqId from the URP header and ACK it:

<syntaxhighlight lang="python">
data, addr = sock.recvfrom(4096)
det_seq = struct.unpack_from("<I", data, 0)[0]

# send bare ACK
ack = struct.pack("<II", det_seq, 1)
sock.sendto(ack, (DET_IP, 8100))

# all subsequent commands start from here
host_seq = det_seq + 1
</syntaxhighlight>

==== Step 3: PORT_SETUP ====

Tells the detector which host ports to use for replies and image data.

<pre>
PDAP: [02 00 00 00] cmd_type = 2
[04 00 00 00] payload_len = 4
[15 AE] host cmd port = 5550 (big-endian)
[1A 04] host image port = 6660 (big-endian)
</pre>

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 2, 4) + struct.pack(">HH", HOST_PORT, IMG_PORT)
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1
# expect bare ACK from detector
</syntaxhighlight>

==== Step 4: Reading the Serial Number (SIGNATURE_REQUEST) ====

Empty command, the detector replies with a 54-byte payload containing its identity.

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 3, 0) # cmd_type=3, payload_len=0
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1

# reply is 70 bytes total: 8 URP + 8 PDAP header + 54 payload
data, _ = sock.recvfrom(4096)
payload = data[16:] # skip URP (8) + PDAP header (8)

mac = payload[0:6]
serial = payload[22:34].rstrip(b'\x00 ').decode()
model = payload[34:46].rstrip(b'\x00 ').decode()
fw_bytes = payload[46:54]
firmware = ".".join(str(b) for b in fw_bytes)

print(f"MAC: {':'.join(f'{b:02X}' for b in mac)}")
print(f"Serial: {serial}")
print(f"Model: {model}")
print(f"Firmware: {firmware}")
</syntaxhighlight>

Expected output:
<pre>
MAC: 40:F4:A0:00:78:4D
Serial: UA45829-7
Model: 5340000-7
Firmware: 1.6.0.4.2.0.1.3
</pre>

=== Running an Acquisition ===

After the connection sequence above, download scripts to the detector and then execute them.

==== ROE Initialisation (Script 7) ====

Always run this first. It initialises the readout electronics and takes about 4-5 seconds. The detector sends host event ID 17 when done.

==== Dark / Offset Acquisition (Script 1) ====

No X-ray source required. Runs a dark-field exposure for offset calibration. Use this to verify the acquisition pipeline without a generator.

==== Standard Acquisition (Script 0) ====

Requires an actual X-ray exposure. <code>EXECUTION_COMPLETE</code> will '''not''' arrive without a real X-ray trigger.

==== Sequence Overview ====

<pre>
HOST DETECTOR
| |
|-- SYSTEM_STARTUP (broadcast) ----------->|
|<- bare ACK -------------------------------|
|<- BEACON (cmd_type=1) --------------------|
|-- bare ACK ------------------------------>|
| |
|-- PORT_SETUP (cmd_type=2) -------------->|
|<- bare ACK -------------------------------|
| |
|-- SIGNATURE_REQUEST (cmd_type=3) ------->|
|<- SIGNATURE_REPLY (54 bytes) -------------|
|-- bare ACK ------------------------------>|
| |
|-- GENERIC_SCRIPT Script7 (ROE init) ---->|
|<- bare ACK or SCRIPT_DOWNLOAD_REPLY ------|
| |
|-- GENERIC_SCRIPT Script1 (dark acq) ---->|
|<- bare ACK -------------------------------|
| |
|-- EXECUTE_SCRIPT (cmd_type=6) ---------->|
|<- bare ACK -------------------------------|
|<- EXECUTE_SCRIPT_REPLY (~230ms) ----------|
|-- bare ACK ------------------------------>|
|<- DETECTOR_STATE_NOTIFY (~890ms) ---------| state_id=17
|-- bare ACK ------------------------------>|
| |
|<- EXECUTION_COMPLETE (0x10000) -----------|
|-- bare ACK ------------------------------>|
| |
|<- IMAGE_XFER_STATUS_QUERY (0x30000) ------|
|-- bare ACK ------------------------------>|
|-- IMAGE_XFER_STATUS_REPLY (cmd_type=9) ->| numMissed=0
|<- bare ACK -------------------------------|
</pre>

=== Sequence Counter Rules ===

* <code>SYSTEM_STARTUP</code> always uses <code>SeqId = 0</code>.
* After the first beacon, set host SeqId to beacon_SeqId + 1.
* Increment SeqId by 1 for every new data packet (CmdFlag=0).
* Bare ACKs echo the SeqId of the packet being acknowledged and do not consume a SeqId.
* The detector silently drops any packet with a SeqId it has already processed, so never reuse one.

== Sensor Readout and Host Registration ==

This section documents the reverse engineered sensor telemetry interface and the
host registration (pairing) mechanism of the GE Optima XR200/220 AMX FlashPad
(URP detector, SuperBee, FW 1.6.0.4.2.0.1.3). All commands are PDAP over UDP to
the detector at port 8100; replies return to the host command port.

=== Sensor Readout ===

The detector exposes an analog sensor interface (the DEM, Detector Environment
Monitor) that is independent of the image transfer path and works regardless of
acquisition state.

==== Commands ====

{| class="wikitable"
! cmd_type !! Meaning !! Request payload !! Reply payload
|-
| 0x7900 || Raw sensor read || [sensorId:4 LE] || [value:4 LE] (12 bit ADC count)
|-
| 0x7902 || Converted sensor read || [sensorId:4 LE] || [value:4 LE] (engineering units, signed)
|-
| 0x7904 || Detailed / radio || [selector:4 LE] || [value:4 LE]
|}

Note: cmd 0x7902 IS supported on this firmware and returns calibrated
engineering units (millivolts for the supply rails, signed; 0.1 degree C for
temperatures). Earlier documentation that marked 0x7902 as unsupported is
incorrect. The host side conversion coefficients are not required; the detector
performs the conversion internally.

The full sensor map (name, sensorId) was recovered from the detector's own
[Sensor] configuration table, read back over the upload interface (see the
Registration section for the read protocol).

==== Power rails (live readings) ====

All supply rails read correctly via 0x7902 and are within normal range for a
flat panel detector. Representative readings:

{| class="wikitable"
! Sensor !! sensorId !! Converted !! Value
|-
| DCIN_RAW || 10 || 12100 mV || +12.10 V (main DC input)
|-
| LCORE_UNREG || 11 || 1724 mV || +1.72 V
|-
| LPANA_UNREG || 12 || 5776 mV || +5.78 V
|-
| LNANA_UNREG || 13 || -5801 mV || -5.80 V
|-
| SCAN_VCC || 14 || 5086 mV || +5.09 V (gate driver)
|-
| P5V_REF || 16 || 5025 mV || +5.03 V (5 V reference)
|-
| V_ON || 17 || 11085 mV || +11.09 V (TFT gate on)
|-
| V_OFF || 18 || -12378 mV || -12.38 V (TFT gate off)
|-
| V_COMMON || 19 || -9385 mV || -9.39 V
|-
| 3V3 || 29 || 3177 mV || +3.18 V (3.3 V logic)
|-
| VCC_UNREG || 37 || 3399 mV || +3.40 V
|-
| PARCPREG || 38 || 3768 mV || +3.77 V (ARC preamp +)
|-
| NARCPREG || 39 || -3732 mV || -3.73 V (ARC preamp -)
|-
| PANA_UNREG || 45 || 18352 mV || +18.35 V (photodiode bias +)
|-
| NANA_UNREG || 46 || -19251 mV || -19.25 V (photodiode bias -)
|}

Switched rails that are inactive while the panel is idle (PARCVA_U,
P5VA_SW, N5VA_SW, FGATE_NVC_L, FGATE_PVC_L, etc.) read at or near zero.

==== Known limitations ====

* '''Temperatures''' (Temp_Surface, sensorId 336; Temp_Panel, sensorId 352): the raw 0x7900 read rails at 0x3FF (1023, the ADC maximum), indicating an open thermistor path while the panel is idle. This is a hardware/state condition, not a command problem, and the temperature is not readable from the host in this state.
* '''Unimplemented sensors''': sensorIds 70 (Accelerator), 78 (Gravity), and 256 to 259 (Battery status, name, life, capacity), and 272 (Grid status) are not implemented on this DEM. The detector returns the leftover conversion register contents (a duplicate of a previously read sensor) rather than a real value, so these rows must be discarded.
* '''Accelerometer''': functional through a separate addressing scheme using raw cmd 0x7900 with selectors 0x42 (X), 0x43 (Y), 0x44 (Z), returning 12 bit per axis counts.

=== Host Registration (Pairing) ===

URP stands for Unified Registration Protocol. The detector maintains a host
list in its internal NOR flash. Image data is delivered only to a registered
primary host, so registration is a prerequisite for image transfer.

==== Host identity (MAC and HostId) ====

Each host is identified by a 16 character HostId derived deterministically from
the host's eth0 MAC address. The derivation (from the vendor generateHostId
script) is:

# Take the eth0 MAC, remove the colon separators, convert to upper case (12 hex characters).
# Prepend the last 4 characters to the full 12 characters.
# The result is 16 hex characters.

Example: MAC 00:6f:00:01:0a:3a becomes 006F00010A3A, then the last four (0A3A)
are prepended, giving HostId 0A3A006F00010A3A.

==== HostList structure ====

The host list is stored in flash at offset 0x940000 and can be read back over
the upload interface as data category 0x71. Layout:

Offset Size Field
0x00 16 DetectorDeviceId (ASCII)
0x10 16 ConnectionSecretKey (ASCII; "XXXXXXXXXXXXXXXX" when unset)
0x20 16 DetectorName (ASCII)
0x30 16 DetectorCode (ASCII)
0x40 2 CurrentNumberOfHosts (uint16 LE)
0x42 2 IndexToPrimaryHost (uint16 LE; 0xFFFF = none)
0x44 144*N Host entries, 144 bytes each:
+0x00 16 HostId (ASCII)
+0x10 .. host name / department string
+0x50 .. location string
... 4 CRC (big endian; see below)

==== HostList from the unit under test ====

Detector: MAC 40:F4:A0:00:78:4D, serial UA45829-7, model 5340000-7,
firmware 1.6.0.4.2.0.1.3. DetectorName starShape_green. ConnectionSecretKey
unset. CurrentNumberOfHosts = 3, IndexToPrimaryHost = 0xFFFF (no primary host).

{| class="wikitable"
! Index !! HostId !! Derived MAC !! Name
|-
| 0 || 2C6400045FB42C64 || 00:04:5F:B4:2C:64 || Haus 207 / ITS
|-
| 1 || B044E8393512B044 || E8:39:35:12:B0:44 || Not Initialized
|-
| 2 || 5CF800045FB15CF8 || 00:04:5F:B1:5C:F8 || Not_Initialized
|}

The unit is therefore not factory fresh; it carries registrations from a prior
deployment, but no primary host is currently designated.

==== Checksum (CRC) ====

The HostList (and other flash data blobs) are protected by a 4 byte trailing
CRC. Parameters:

* Polynomial: 0x04C11DB7
* Initial value: 0
* MSB first, augmented message style (the data bit is shifted into the LSB; no input or output reflection; no final XOR)
* Stored big endian

To generate: compute the CRC over the data followed by four zero bytes, then
append the result big endian. Verification: the CRC over (data plus stored CRC)
equals zero.

def crc(data, poly=0x04C11DB7, init=0):
c = init
for byte in data:
for bit in (0x80,0x40,0x20,0x10,0x08,0x04,0x02,0x01):
msb = c & 0x80000000
c = (c << 1) & 0xFFFFFFFF
if byte & bit: c |= 1
if msb: c ^= poly
return c
# trailer = crc(data + b"\x00\x00\x00\x00"), stored big endian

==== Read and write transport ====

Data blobs (including the HostList) are moved with a configure / buffer /
finalize sequence.

Read (upload, detector to host), non destructive:

{| class="wikitable"
! Step !! cmd_type !! host to detector !! detector to host
|-
| Configure || 0x13 || [uploadId:4 LE] || [status:1][totalSize:4 LE]
|-
| Buffer || 0x14 || [bufId:4 LE][numBytes:4 LE] || [bufId:4 LE][numBytes:4 LE][data]
|}

Write (download, host to detector), persistent (writes flash):

{| class="wikitable"
! Step !! cmd_type !! host to detector !! detector to host
|-
| Configure || 0x0E || [downloadId:4 LE][totalSize:4 LE] || [status:1]
|-
| Buffer || 0x0F || [bufId:4 LE][numBytes:4 LE][data] || [status:1][reserved:4]
|-
| Commit || 0x10 || (empty) || [status:1]
|}

bufId is a zero based chunk index. The HostList uses id 0x71 for both read and
write. The commit command (0x10) reuses the firmware flash path, so a malformed
download can corrupt flash; the operation is irreversible on this hardware.

==== Registering a new host ====

To register a host and make it the image destination, read the current HostList
(0x71), append a 144 byte entry carrying the new HostId, increment
CurrentNumberOfHosts, set IndexToPrimaryHost to the new entry's index,
recompute the trailing CRC, and write the blob back via the download sequence
(0x0E / 0x0F / 0x10).

== FlashPad Detector: Internal Flash Dump and Data Files ==

This section documents how the full contents of the detector's internal flash
were extracted over the network and what each recovered file contains. The
detector under test is a GE Optima XR200/220 AMX FlashPad (URP detector,
serial UA45829-7, MAC 40:F4:A0:00:78:4D, firmware 1.6.0.4.2.0.1.3).

=== Background ===

The detector's main storage is a Spansion/Cypress S29GL512P (marked
GL512P10FFCR2), a 512 Mbit (64 MB) parallel NOR flash. A direct chip read
requires bus access or desoldering and a programmer. However, the detector
firmware exposes its stored data blobs, including a full image of the flash,
through the read (upload) side of the data transport protocol. This makes a
complete, byte exact dump possible over UDP with no physical access.

=== Extraction method ===

The upload interface is the read counterpart of the firmware download path and
is non destructive (it only reports and returns data; nothing is written).
Each data category is identified by an 8 bit upload ID:

{| class="wikitable"
! Step !! cmd_type !! host to detector !! detector to host
|-
| Configure || 0x13 || [uploadId:4 LE] || [status:1][totalSize:4 LE]
|-
| Buffer || 0x14 || [bufId:4 LE][numBytes:4 LE] || [bufId:4 LE][numBytes:4 LE][data]
|}

A configure request returns status 0 and a total size for a valid ID, or a non
zero status for an unsupported ID. The dump tool sweeps all IDs from 0x00 to
0xFF, and for every readable ID it pulls the full blob in fixed size chunks
(bufId is a zero based chunk index) and writes it to a file. The 64 MB flash
image transfers as 65536 chunks of 1024 bytes.

=== Recovered files ===

A sweep of the unit returned 18 readable blobs:

{| class="wikitable"
! Upload ID !! Size (bytes) !! Contents
|-
| 0xFD || 67108864 || Full 64 MB NOR flash image
|-
| 0xFF || 16777216 || 16 MB region (firmware / FPGA mirror or image buffer)
|-
| 0xFE || 524288 || Bootloader (512 KB; SPI loader, Nios reset code)
|-
| 0x10 || 6815783 || Calibration map, dose level 1
|-
| 0x11 || 6815783 || Calibration map, dose level 2
|-
| 0x12 || 6815783 || Calibration map, dose level 3
|-
| 0x06 || 49254 || Table referencing conditioner/generator serial UA2010-8U005
|-
| 0x50 || 19938 || Per mode calibration coefficients
|-
| 0x51 || 19582 || Per mode calibration coefficients
|-
| 0x07 || 12187 || Sensor conversion table (text; see Sensor Readout)
|-
| 0x72 || 3001 || Shock / drop event log (text)
|-
| 0x0E || 624 || Panel geometry / configuration (binary)
|-
| 0x71 || 504 || Host list / registration record (see Host Registration)
|-
| 0x0F || 233 || Host to detector compatibility table (text)
|-
| 0x08 || 62 || Serial and model strings
|-
| 0x0A || 48 || Manufacturing codes
|-
| 0x52 || 30 || Serial string
|-
| 0x0B || 24 || Small marker / identifier
|}

=== Flash image layout (upload ID 0xFD) ===

A block scan of the 64 MB image shows the following regions:

{| class="wikitable"
! Range !! Contents
|-
| 0x000000 to 0x800000 || Firmware and FPGA configuration
|-
| 0x800000 to 0x940000 || Sparse configuration area
|-
| 0x940000 || Host list / registration record (matches upload ID 0x71)
|-
| 0x1000000 to 0x2800000 || Calibration and image data (16 to 40 MB)
|-
| 0x2800000 to 0x4000000 || Erased / unused (40 to 64 MB)
|}

The host list strings (the DetectorName starShape_green, the registered host
name Haus 207 / ITS, and the unset ConnectionSecretKey placeholder) appear at
0x940000, confirming that the 504 byte 0x71 read maps to this flash region.

=== Notes on individual files ===

* '''0x07 (sensor table)''': plain text, header DetectorSerialNumber = UA45829-7, revision 1.2. Lists every sensor by name, command (0x7902), and sensorId. Also carries panel geometry in its [Common] section: 16 bit depth, 2048 by 2048 pixels, active area from (12, 12) to (2035, 2035), pixel pitch 0.2 mm, corner radius 1416.8, panel saturation 150.
* '''0x10, 0x11, 0x12 (calibration maps)''': three distinct blobs of identical size, corresponding to the low, medium, and high dose calibration sets. Each begins with the firmware version and serial (header bytes 01 06 00 04 02 00 01 03 followed by the serial). Required to apply gain and offset correction to raw images.
* '''0xFE (bootloader)''': contains the strings spi_load.S and ../../boot and Nios II reset vector code.
* '''0x72 (shock log)''': text records of drop / vibration events with timestamps and per axis values; the same data is mirrored in the detector's small onboard EEPROM.
* '''0x06''': references a different serial, UA2010-8U005, likely the conditioner or generator board rather than the panel.

=== Significance ===

The complete flash image and all calibration data are recoverable over the
network without opening the detector, providing a full byte exact backup of the
unit before any write operation. The calibration maps are needed for image
correction, and the firmware image (the live, deployed build) is more complete
than the partial firmware files shipped on the recovery media.

=== Known Dead Ends ===

Things that were tried and did not work or led nowhere:

; 0xBEEF (48879) as reply port
: This was a bug in early test scripts. The port has no meaning in the protocol. Use 5550.

; CmdFlag=1 as data packet flag
: Early scripts had the URP fields swapped, setting CmdFlag=1 on data packets. The detector ignores all PDAP content in these packets. Power cycle the detector if this happened, it may retain stale port state.

; Image data on alternate ports
: Tried listening on 48879, 6660, 5550, 8100, 1050, 6661, 9999, 4444, 7000, 7001, 9001. Nothing arrived on any of them.

; PORT_SETUP byte order (big-endian)
: Current implementation sends port fields as big-endian. If the detector reads them as little-endian it computes port 44565 and 1050 instead of 5550 and 6660, which would explain why no image data arrives. Not yet confirmed.

; Image data streaming automatically after EXECUTE_SCRIPT
: Frames may not push during execution at all. The detector may require an explicit IMAGE_RETRIVAL_REQUEST (cmd_type=0x41) and IMAGE_RETRIVAL (cmd_type=0x98) after the 0x30000 notification before it streams anything. Not yet tested.

== Teardown / Internal Pictures / Hardware analysis ==
<div style="float:left; display:flex; gap:8px;">
[[File:GE Flashpad under the hood.jpg|thumb|none|220px|the Carbon fiber sleeve is held by 9 screws and can taken off without force.]]
[[File:Ge flashpad powersupply pcb in handle.jpg|thumb|none|220px|Power supply PCB]]
[[File:Ge flashpad uwb board pcb.jpg|thumb|none|220px|UWB PCB for Wireless USB using a RTU2705]]
[[File:Ge flashpad uwb pcb backside.jpg|thumb|Backside of UWB PCB]]
</div>
<div style="float:left; display:flex; gap:8px;">
[[File:Ge flashpad power supply pcb backside.jpg|thumb|Backside of Power supply PCB]]
[[File:Ge flashpad main pcb closeup1.jpg|thumb|Main area of the PCB with its Altera Cyclone 3 FPGA]]
[[File:Ge flashpad main pcb closeup2.jpg|thumb|AD7892 is a 600ksps 12bit ADC, SN74LVC8T245 a 8bit bus transceiver and DG9408EDN a 8ch MUX]]
[[File:Ge flashpad bottom connector ethernet isolation pcb.jpg|thumb|Isolation PCB for bottom connector]]
</div>
<div style="float:left; display:flex; gap:8px;">
[[File:Ge flashpad main pcb powersupply section.jpg|thumb|Powersupply section for FPGA and ROIC]]
[[File:Ge_flashpad_main_pcb_closeup_3.jpg|thumb|AD9764AR 14-Bit, 125 MSPS DAC and DS1682 integrated elapsed-time recorder]]
[[File:Ge flashpad main pcb closeup 4.jpg|thumb|left|Accelerometer is a 834-0500 500G 3 Axis unit. abd TJ500AE SPDT GIGABIT LAN SWITCH]]
[[File:Ge flashpad bottom connector.jpg|thumb|left|bottom connector for docking stand]]
</div>
<div style="float:left; display:flex; gap:8px;">
[[File:Ge flashpad main pcb closeup 5.jpg|thumb|left|Ethernet transformers and ADM34 RS-485/RS-422 Transceiver]]
[[File:Ge flashpad main pcb closeup 6.jpg|thumb|left|Altera EPM570f100c5n CPLD ]]
[[File:Ge flashpad main pcb closeup 7.jpg|thumb|left|Spansion GL512P10FF1R1 512 Mbit NOR flash IC holding everything.]]
[[File:Ge flashpad main pcb closeup 8.jpg|thumb|left|24LC256I 32k EEPROM for storing the accelerometer events.]]
</div>

File:Ge flashpad main pcb closeup 8.jpg

2026-06-11T11:54:40Z

Gamerpaddy:

showing the 24LC256 eeprom

File:Ge flashpad main pcb closeup 7.jpg

2026-06-11T11:53:31Z

Gamerpaddy:

showing the main flash ic

File:Ge flashpad main pcb closeup 6.jpg

2026-06-11T11:52:38Z

Gamerpaddy:

showing the sub fpga altera epm570f100c5n

File:Ge flashpad main pcb closeup 5.jpg

2026-06-11T11:51:14Z

Gamerpaddy:

eth transformers

File:Ge flashpad bottom connector.jpg

2026-06-11T11:50:02Z

Gamerpaddy:

with original humand crud in the crevices

File:Ge flashpad main pcb closeup 4.jpg

2026-06-11T11:48:21Z

Gamerpaddy:

showing the main accelerometer module

GE Medical Flashpad Digital Xray Detector

2026-06-11T11:47:31Z

Gamerpaddy:

==Overview==

The '''GE Flashpad''' is a Digital Radiography image sensor from approximately 2010, originally used in the '''GE Optima 220AMX''' mobile X-ray unit. It was designed to replace analog film in radiology, dramatically reducing image acquisition time from hours to seconds.
[[File:GE Flashpad.jpg|thumb|Flashpad with Anti-Scatter grid (left), manual and recovery dvd for 220amx and tether cord (right)]]
Due to its high original cost and specialized application, used units occasionally appear on professional B2B marketplaces in the $15,000–$50,000 range. On eBay, prices typically fall between $1,500 and $5,000, though units at this price point are often in poor condition and may fail the built-in self-test or not function at all.

{{Note|All findings on this page are based on a single unit and the time spent working on it. Information is subject to speculation and may not be fully accurate.}}

{{Note|[[Artificial intelligence|AI]] assistance was used in writing this page for improved formatting and readability, as well as in the process of finding information, testing, and analyzing firmware dumps and backups.}}

== Purpose and Motivation ==

This project documents the reverse engineering of the GE FlashPad wireless
digital radiography detector used with the Optima XR200/220 AMX mobile X-ray
system, with the goal of freeing these detectors for independent use.
[[File:Xray capture pcb.png|thumb|Xray capture of a PCB for Reverse Engineering]]
Large numbers of these detectors reach the used market, but each one is
cryptographically and administratively bound to its original Optima 220 AMX
console. Once separated from that console, or once the console is
decommissioned, the detector is effectively useless even though the hardware is
fully functional. The aim of this work is to remove that artificial barrier so
that a standalone FlashPad can be paired, configured, and read out by any host,
without the half million dollar console it was sold with.

The intended beneficiaries are:

* Hobbyists, researchers, and engineers who want a high quality flat panel detector for their own imaging projects.
* Veterinary practices, which can put surplus human grade detectors to good use at a fraction of the cost of new equipment.
* Clinics and hospitals in countries and regions where a complete commercial system is unaffordable, allowing serviceable detectors to keep providing diagnostic imaging instead of being scrapped.
[[File:Xray current clamp multimeter.png|thumb|xray of a current clamp multimeter]]
This is done for human good. Every detector returned to service is one less
piece of working medical hardware sent to landfill, and potentially one more
place that can offer X-ray imaging where it otherwise could not.

All files, findings, protocol documentation, and tools produced by this project
are public and open source, so that anyone can study, reproduce, and build on
the work.

==Technical Specifications==
[[File:Ge flashpad tether cable pinout diagram.png|thumb|Pinout Diagram of the Tether cable]]
[[File:Ge flashpad tether wiring for ethernet cable.jpg|thumb|Professional Tether wiring to attach a Ethernet Cable and 12V socket to it.]]
The Flashpad uses a '''~40 × 40 cm CsI scintillator''' bonded to a [[Thin-film transistor|TFT]] photodetector array mounted on glass. The assembly is highly sensitive to shock and impact damage.

{| class="wikitable"
|-
!Parameter!!Value
|-
|Resolution||2048 × 2048 px
|-
|Bit depth||16-bit per pixel
|-
|Spatial resolution||Up to 5 lp/mm (theoretical)
|-
|Scintillator material||Caesium iodide (CsI)
|-
|Detector type||TFT photodetector array (glass substrate)
|-
|Panel size||~40 × 40 cm
|}

The theoretical 5 lp/mm spatial resolution is primarily limited in practice by the focal spot size of the X-ray source. Use of an anti-scatter grid can improve effective resolution.

=== Status of Reverse Engineering ===

{| class="wikitable"
|-
! What !! Status
|-
| Connect, beacon, ACK || Works
|-
| PORT_SETUP || Works
|-
| SIGNATURE_REQUEST / serial number readout || Works
|-
| Script download (Scripts 7, 8, 1) || Works
|-
| EXECUTE_SCRIPT || Works
|-
| EXECUTION_COMPLETE (dark acquisition) || Works
|-
| EXECUTION_COMPLETE (standard acquisition) || Needs real X-ray trigger to test
|-
| Image data on port 6660 || Does not work yet, under investigation. Will not send Imagedata yet.
|}

==Hardware Features==

===Shock logging===
The unit contains an internal accelerometer that logs significant shock events — but only when a battery is inserted. As there is no backup battery, shock events occurring while unpowered are not recorded.

===Wireless connectivity===
Some units include a UWB transmitter for Wireless USB; others may be equipped with a Wi-Fi module instead. The detector can also be operated over the tethered connection alone.

===Ethernet interface===
There is a 100MBit Ethernet interface trough the Tether Cable which can be tapped and used for Communication.
Exposed metal contacts on the bottom connector are isolated via relays by default. Enabling Gigabit Ethernet connectivity requires shorting or driving two specific pins. This has not been investigated further at this time.

== Communication Protocol ==

This section documents the URP/PDAP protocol used by the GE Flashpad (codename '''Apollo''') to communicate with a host over Ethernet. All findings are based on live capture tests, configuration files, and reverse-engineering of the GE SuperBee software stack.

{{Note|All findings are based on a single unit and may not be fully accurate.}}

=== Network Setup ===

All findings were over Ethernet only, no UWB or WIFI has been used.
Default detector IP is <code>192.168.1.30</code>. Set your host to a static IP in the same subnet, <code>192.168.1.1</code> works fine.

At first by sending random bytes over Python it answered to port 48879 (0xBEEF), which seems to be either the default port or set by Python.
After SYSTEM_SETUP it got set to 5550.

{| class="wikitable"
|-
! Role !! IP !! Port !! Direction
|-
| All commands: host -> detector || 192.168.1.30 || '''8100''' (UDP) || Host sends here
|-
| Discovery beacons: detector -> host || - || '''4500''' (UDP) || Detector sends here initially
|-
| Protocol replies: detector -> host || - || '''5550''' (UDP) || Detector sends here after setup
|-
| Image pixel data: detector -> host || - || '''6660''' (UDP) || Detector streams frames here
|}

In practice you can listen on port '''5550''' for everything (beacons and replies) by advertising that port in both <code>SYSTEM_STARTUP</code> and <code>PORT_SETUP</code>. The detector sends to whichever port was most recently configured.

=== Protocol Layers ===

Two layers, carried over UDP:

; URP (Unified Registration Protocol)
: 8-byte wrapper on every packet. Handles sequencing and acknowledgement.

; PDAP (Proprietary Detector Access Protocol)
: The actual command layer, present inside URP packets when <code>CmdFlag = 0</code>.

Every UDP packet starts with a URP header:

<pre>
[SeqId : 4 bytes LE] [CmdFlag : 4 bytes LE]
</pre>

* <code>CmdFlag = 0</code> -- data packet, PDAP command follows.
* <code>CmdFlag = 1</code> -- bare ACK, no PDAP body. SeqId echoes the packet being acknowledged.

Both sides must ACK every data packet immediately. The detector silently drops packets with a SeqId it has already seen, so always increment SeqId for each new command.

When CmdFlag is 0, the PDAP header follows immediately:

<pre>
[cmd_type : 4 bytes LE] [payload_len : 4 bytes LE] [payload ...]
</pre>

=== Connecting to the Detector ===

The connection sequence is:

# Broadcast <code>SYSTEM_STARTUP</code> to tell the detector where to reply.
# The detector sends a <code>BEACON</code> back -- ACK it and sync your sequence counter.
# Send <code>PORT_SETUP</code> to configure the reply and image ports.
# Send <code>SIGNATURE_REQUEST</code> to read the detector identity (serial number, model, firmware, MAC).

==== Step 1: SYSTEM_STARTUP ====

Broadcast UDP to <code>192.168.1.255:8100</code>. Always uses <code>SeqId = 0</code>.

<pre>
URP : [00 00 00 00] SeqId = 0
[00 00 00 00] CmdFlag = 0
PDAP: [01 00 00 00] cmd_type = 1
[06 00 00 00] payload_len = 6
[15 AE] host reply port = 5550 (big-endian)
[C0 A8 01 01] host IP = 192.168.1.1 (network byte order)
</pre>

<syntaxhighlight lang="python">
import socket, struct

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
sock.bind(("0.0.0.0", 5550))

HOST_IP = "192.168.1.1"
DET_IP = "192.168.1.30"
HOST_PORT = 5550
IMG_PORT = 6660

def make_urp_packet(seq_id, pdap_bytes):
return struct.pack("<II", seq_id, 0) + pdap_bytes

pdap = struct.pack("<II", 1, 6) + struct.pack(">H", HOST_PORT) + socket.inet_aton(HOST_IP)
sock.sendto(make_urp_packet(0, pdap), ("192.168.1.255", 8100))
</syntaxhighlight>

==== Step 2: Receiving the BEACON and ACKing ====

The detector broadcasts a <code>BEACON</code> (cmd_type=1) roughly every 2 seconds. After sending SYSTEM_STARTUP you should get one quickly. Parse the detector SeqId from the URP header and ACK it:

<syntaxhighlight lang="python">
data, addr = sock.recvfrom(4096)
det_seq = struct.unpack_from("<I", data, 0)[0]

# send bare ACK
ack = struct.pack("<II", det_seq, 1)
sock.sendto(ack, (DET_IP, 8100))

# all subsequent commands start from here
host_seq = det_seq + 1
</syntaxhighlight>

==== Step 3: PORT_SETUP ====

Tells the detector which host ports to use for replies and image data.

<pre>
PDAP: [02 00 00 00] cmd_type = 2
[04 00 00 00] payload_len = 4
[15 AE] host cmd port = 5550 (big-endian)
[1A 04] host image port = 6660 (big-endian)
</pre>

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 2, 4) + struct.pack(">HH", HOST_PORT, IMG_PORT)
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1
# expect bare ACK from detector
</syntaxhighlight>

==== Step 4: Reading the Serial Number (SIGNATURE_REQUEST) ====

Empty command, the detector replies with a 54-byte payload containing its identity.

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 3, 0) # cmd_type=3, payload_len=0
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1

# reply is 70 bytes total: 8 URP + 8 PDAP header + 54 payload
data, _ = sock.recvfrom(4096)
payload = data[16:] # skip URP (8) + PDAP header (8)

mac = payload[0:6]
serial = payload[22:34].rstrip(b'\x00 ').decode()
model = payload[34:46].rstrip(b'\x00 ').decode()
fw_bytes = payload[46:54]
firmware = ".".join(str(b) for b in fw_bytes)

print(f"MAC: {':'.join(f'{b:02X}' for b in mac)}")
print(f"Serial: {serial}")
print(f"Model: {model}")
print(f"Firmware: {firmware}")
</syntaxhighlight>

Expected output:
<pre>
MAC: 40:F4:A0:00:78:4D
Serial: UA45829-7
Model: 5340000-7
Firmware: 1.6.0.4.2.0.1.3
</pre>

=== Running an Acquisition ===

After the connection sequence above, download scripts to the detector and then execute them.

==== ROE Initialisation (Script 7) ====

Always run this first. It initialises the readout electronics and takes about 4-5 seconds. The detector sends host event ID 17 when done.

==== Dark / Offset Acquisition (Script 1) ====

No X-ray source required. Runs a dark-field exposure for offset calibration. Use this to verify the acquisition pipeline without a generator.

==== Standard Acquisition (Script 0) ====

Requires an actual X-ray exposure. <code>EXECUTION_COMPLETE</code> will '''not''' arrive without a real X-ray trigger.

==== Sequence Overview ====

<pre>
HOST DETECTOR
| |
|-- SYSTEM_STARTUP (broadcast) ----------->|
|<- bare ACK -------------------------------|
|<- BEACON (cmd_type=1) --------------------|
|-- bare ACK ------------------------------>|
| |
|-- PORT_SETUP (cmd_type=2) -------------->|
|<- bare ACK -------------------------------|
| |
|-- SIGNATURE_REQUEST (cmd_type=3) ------->|
|<- SIGNATURE_REPLY (54 bytes) -------------|
|-- bare ACK ------------------------------>|
| |
|-- GENERIC_SCRIPT Script7 (ROE init) ---->|
|<- bare ACK or SCRIPT_DOWNLOAD_REPLY ------|
| |
|-- GENERIC_SCRIPT Script1 (dark acq) ---->|
|<- bare ACK -------------------------------|
| |
|-- EXECUTE_SCRIPT (cmd_type=6) ---------->|
|<- bare ACK -------------------------------|
|<- EXECUTE_SCRIPT_REPLY (~230ms) ----------|
|-- bare ACK ------------------------------>|
|<- DETECTOR_STATE_NOTIFY (~890ms) ---------| state_id=17
|-- bare ACK ------------------------------>|
| |
|<- EXECUTION_COMPLETE (0x10000) -----------|
|-- bare ACK ------------------------------>|
| |
|<- IMAGE_XFER_STATUS_QUERY (0x30000) ------|
|-- bare ACK ------------------------------>|
|-- IMAGE_XFER_STATUS_REPLY (cmd_type=9) ->| numMissed=0
|<- bare ACK -------------------------------|
</pre>

=== Sequence Counter Rules ===

* <code>SYSTEM_STARTUP</code> always uses <code>SeqId = 0</code>.
* After the first beacon, set host SeqId to beacon_SeqId + 1.
* Increment SeqId by 1 for every new data packet (CmdFlag=0).
* Bare ACKs echo the SeqId of the packet being acknowledged and do not consume a SeqId.
* The detector silently drops any packet with a SeqId it has already processed, so never reuse one.

== Sensor Readout and Host Registration ==

This section documents the reverse engineered sensor telemetry interface and the
host registration (pairing) mechanism of the GE Optima XR200/220 AMX FlashPad
(URP detector, SuperBee, FW 1.6.0.4.2.0.1.3). All commands are PDAP over UDP to
the detector at port 8100; replies return to the host command port.

=== Sensor Readout ===

The detector exposes an analog sensor interface (the DEM, Detector Environment
Monitor) that is independent of the image transfer path and works regardless of
acquisition state.

==== Commands ====

{| class="wikitable"
! cmd_type !! Meaning !! Request payload !! Reply payload
|-
| 0x7900 || Raw sensor read || [sensorId:4 LE] || [value:4 LE] (12 bit ADC count)
|-
| 0x7902 || Converted sensor read || [sensorId:4 LE] || [value:4 LE] (engineering units, signed)
|-
| 0x7904 || Detailed / radio || [selector:4 LE] || [value:4 LE]
|}

Note: cmd 0x7902 IS supported on this firmware and returns calibrated
engineering units (millivolts for the supply rails, signed; 0.1 degree C for
temperatures). Earlier documentation that marked 0x7902 as unsupported is
incorrect. The host side conversion coefficients are not required; the detector
performs the conversion internally.

The full sensor map (name, sensorId) was recovered from the detector's own
[Sensor] configuration table, read back over the upload interface (see the
Registration section for the read protocol).

==== Power rails (live readings) ====

All supply rails read correctly via 0x7902 and are within normal range for a
flat panel detector. Representative readings:

{| class="wikitable"
! Sensor !! sensorId !! Converted !! Value
|-
| DCIN_RAW || 10 || 12100 mV || +12.10 V (main DC input)
|-
| LCORE_UNREG || 11 || 1724 mV || +1.72 V
|-
| LPANA_UNREG || 12 || 5776 mV || +5.78 V
|-
| LNANA_UNREG || 13 || -5801 mV || -5.80 V
|-
| SCAN_VCC || 14 || 5086 mV || +5.09 V (gate driver)
|-
| P5V_REF || 16 || 5025 mV || +5.03 V (5 V reference)
|-
| V_ON || 17 || 11085 mV || +11.09 V (TFT gate on)
|-
| V_OFF || 18 || -12378 mV || -12.38 V (TFT gate off)
|-
| V_COMMON || 19 || -9385 mV || -9.39 V
|-
| 3V3 || 29 || 3177 mV || +3.18 V (3.3 V logic)
|-
| VCC_UNREG || 37 || 3399 mV || +3.40 V
|-
| PARCPREG || 38 || 3768 mV || +3.77 V (ARC preamp +)
|-
| NARCPREG || 39 || -3732 mV || -3.73 V (ARC preamp -)
|-
| PANA_UNREG || 45 || 18352 mV || +18.35 V (photodiode bias +)
|-
| NANA_UNREG || 46 || -19251 mV || -19.25 V (photodiode bias -)
|}

Switched rails that are inactive while the panel is idle (PARCVA_U,
P5VA_SW, N5VA_SW, FGATE_NVC_L, FGATE_PVC_L, etc.) read at or near zero.

==== Known limitations ====

* '''Temperatures''' (Temp_Surface, sensorId 336; Temp_Panel, sensorId 352): the raw 0x7900 read rails at 0x3FF (1023, the ADC maximum), indicating an open thermistor path while the panel is idle. This is a hardware/state condition, not a command problem, and the temperature is not readable from the host in this state.
* '''Unimplemented sensors''': sensorIds 70 (Accelerator), 78 (Gravity), and 256 to 259 (Battery status, name, life, capacity), and 272 (Grid status) are not implemented on this DEM. The detector returns the leftover conversion register contents (a duplicate of a previously read sensor) rather than a real value, so these rows must be discarded.
* '''Accelerometer''': functional through a separate addressing scheme using raw cmd 0x7900 with selectors 0x42 (X), 0x43 (Y), 0x44 (Z), returning 12 bit per axis counts.

=== Host Registration (Pairing) ===

URP stands for Unified Registration Protocol. The detector maintains a host
list in its internal NOR flash. Image data is delivered only to a registered
primary host, so registration is a prerequisite for image transfer.

==== Host identity (MAC and HostId) ====

Each host is identified by a 16 character HostId derived deterministically from
the host's eth0 MAC address. The derivation (from the vendor generateHostId
script) is:

# Take the eth0 MAC, remove the colon separators, convert to upper case (12 hex characters).
# Prepend the last 4 characters to the full 12 characters.
# The result is 16 hex characters.

Example: MAC 00:6f:00:01:0a:3a becomes 006F00010A3A, then the last four (0A3A)
are prepended, giving HostId 0A3A006F00010A3A.

==== HostList structure ====

The host list is stored in flash at offset 0x940000 and can be read back over
the upload interface as data category 0x71. Layout:

Offset Size Field
0x00 16 DetectorDeviceId (ASCII)
0x10 16 ConnectionSecretKey (ASCII; "XXXXXXXXXXXXXXXX" when unset)
0x20 16 DetectorName (ASCII)
0x30 16 DetectorCode (ASCII)
0x40 2 CurrentNumberOfHosts (uint16 LE)
0x42 2 IndexToPrimaryHost (uint16 LE; 0xFFFF = none)
0x44 144*N Host entries, 144 bytes each:
+0x00 16 HostId (ASCII)
+0x10 .. host name / department string
+0x50 .. location string
... 4 CRC (big endian; see below)

==== HostList from the unit under test ====

Detector: MAC 40:F4:A0:00:78:4D, serial UA45829-7, model 5340000-7,
firmware 1.6.0.4.2.0.1.3. DetectorName starShape_green. ConnectionSecretKey
unset. CurrentNumberOfHosts = 3, IndexToPrimaryHost = 0xFFFF (no primary host).

{| class="wikitable"
! Index !! HostId !! Derived MAC !! Name
|-
| 0 || 2C6400045FB42C64 || 00:04:5F:B4:2C:64 || Haus 207 / ITS
|-
| 1 || B044E8393512B044 || E8:39:35:12:B0:44 || Not Initialized
|-
| 2 || 5CF800045FB15CF8 || 00:04:5F:B1:5C:F8 || Not_Initialized
|}

The unit is therefore not factory fresh; it carries registrations from a prior
deployment, but no primary host is currently designated.

==== Checksum (CRC) ====

The HostList (and other flash data blobs) are protected by a 4 byte trailing
CRC. Parameters:

* Polynomial: 0x04C11DB7
* Initial value: 0
* MSB first, augmented message style (the data bit is shifted into the LSB; no input or output reflection; no final XOR)
* Stored big endian

To generate: compute the CRC over the data followed by four zero bytes, then
append the result big endian. Verification: the CRC over (data plus stored CRC)
equals zero.

def crc(data, poly=0x04C11DB7, init=0):
c = init
for byte in data:
for bit in (0x80,0x40,0x20,0x10,0x08,0x04,0x02,0x01):
msb = c & 0x80000000
c = (c << 1) & 0xFFFFFFFF
if byte & bit: c |= 1
if msb: c ^= poly
return c
# trailer = crc(data + b"\x00\x00\x00\x00"), stored big endian

==== Read and write transport ====

Data blobs (including the HostList) are moved with a configure / buffer /
finalize sequence.

Read (upload, detector to host), non destructive:

{| class="wikitable"
! Step !! cmd_type !! host to detector !! detector to host
|-
| Configure || 0x13 || [uploadId:4 LE] || [status:1][totalSize:4 LE]
|-
| Buffer || 0x14 || [bufId:4 LE][numBytes:4 LE] || [bufId:4 LE][numBytes:4 LE][data]
|}

Write (download, host to detector), persistent (writes flash):

{| class="wikitable"
! Step !! cmd_type !! host to detector !! detector to host
|-
| Configure || 0x0E || [downloadId:4 LE][totalSize:4 LE] || [status:1]
|-
| Buffer || 0x0F || [bufId:4 LE][numBytes:4 LE][data] || [status:1][reserved:4]
|-
| Commit || 0x10 || (empty) || [status:1]
|}

bufId is a zero based chunk index. The HostList uses id 0x71 for both read and
write. The commit command (0x10) reuses the firmware flash path, so a malformed
download can corrupt flash; the operation is irreversible on this hardware.

==== Registering a new host ====

To register a host and make it the image destination, read the current HostList
(0x71), append a 144 byte entry carrying the new HostId, increment
CurrentNumberOfHosts, set IndexToPrimaryHost to the new entry's index,
recompute the trailing CRC, and write the blob back via the download sequence
(0x0E / 0x0F / 0x10).

== FlashPad Detector: Internal Flash Dump and Data Files ==

This section documents how the full contents of the detector's internal flash
were extracted over the network and what each recovered file contains. The
detector under test is a GE Optima XR200/220 AMX FlashPad (URP detector,
serial UA45829-7, MAC 40:F4:A0:00:78:4D, firmware 1.6.0.4.2.0.1.3).

=== Background ===

The detector's main storage is a Spansion/Cypress S29GL512P (marked
GL512P10FFCR2), a 512 Mbit (64 MB) parallel NOR flash. A direct chip read
requires bus access or desoldering and a programmer. However, the detector
firmware exposes its stored data blobs, including a full image of the flash,
through the read (upload) side of the data transport protocol. This makes a
complete, byte exact dump possible over UDP with no physical access.

=== Extraction method ===

The upload interface is the read counterpart of the firmware download path and
is non destructive (it only reports and returns data; nothing is written).
Each data category is identified by an 8 bit upload ID:

{| class="wikitable"
! Step !! cmd_type !! host to detector !! detector to host
|-
| Configure || 0x13 || [uploadId:4 LE] || [status:1][totalSize:4 LE]
|-
| Buffer || 0x14 || [bufId:4 LE][numBytes:4 LE] || [bufId:4 LE][numBytes:4 LE][data]
|}

A configure request returns status 0 and a total size for a valid ID, or a non
zero status for an unsupported ID. The dump tool sweeps all IDs from 0x00 to
0xFF, and for every readable ID it pulls the full blob in fixed size chunks
(bufId is a zero based chunk index) and writes it to a file. The 64 MB flash
image transfers as 65536 chunks of 1024 bytes.

=== Recovered files ===

A sweep of the unit returned 18 readable blobs:

{| class="wikitable"
! Upload ID !! Size (bytes) !! Contents
|-
| 0xFD || 67108864 || Full 64 MB NOR flash image
|-
| 0xFF || 16777216 || 16 MB region (firmware / FPGA mirror or image buffer)
|-
| 0xFE || 524288 || Bootloader (512 KB; SPI loader, Nios reset code)
|-
| 0x10 || 6815783 || Calibration map, dose level 1
|-
| 0x11 || 6815783 || Calibration map, dose level 2
|-
| 0x12 || 6815783 || Calibration map, dose level 3
|-
| 0x06 || 49254 || Table referencing conditioner/generator serial UA2010-8U005
|-
| 0x50 || 19938 || Per mode calibration coefficients
|-
| 0x51 || 19582 || Per mode calibration coefficients
|-
| 0x07 || 12187 || Sensor conversion table (text; see Sensor Readout)
|-
| 0x72 || 3001 || Shock / drop event log (text)
|-
| 0x0E || 624 || Panel geometry / configuration (binary)
|-
| 0x71 || 504 || Host list / registration record (see Host Registration)
|-
| 0x0F || 233 || Host to detector compatibility table (text)
|-
| 0x08 || 62 || Serial and model strings
|-
| 0x0A || 48 || Manufacturing codes
|-
| 0x52 || 30 || Serial string
|-
| 0x0B || 24 || Small marker / identifier
|}

=== Flash image layout (upload ID 0xFD) ===

A block scan of the 64 MB image shows the following regions:

{| class="wikitable"
! Range !! Contents
|-
| 0x000000 to 0x800000 || Firmware and FPGA configuration
|-
| 0x800000 to 0x940000 || Sparse configuration area
|-
| 0x940000 || Host list / registration record (matches upload ID 0x71)
|-
| 0x1000000 to 0x2800000 || Calibration and image data (16 to 40 MB)
|-
| 0x2800000 to 0x4000000 || Erased / unused (40 to 64 MB)
|}

The host list strings (the DetectorName starShape_green, the registered host
name Haus 207 / ITS, and the unset ConnectionSecretKey placeholder) appear at
0x940000, confirming that the 504 byte 0x71 read maps to this flash region.

=== Notes on individual files ===

* '''0x07 (sensor table)''': plain text, header DetectorSerialNumber = UA45829-7, revision 1.2. Lists every sensor by name, command (0x7902), and sensorId. Also carries panel geometry in its [Common] section: 16 bit depth, 2048 by 2048 pixels, active area from (12, 12) to (2035, 2035), pixel pitch 0.2 mm, corner radius 1416.8, panel saturation 150.
* '''0x10, 0x11, 0x12 (calibration maps)''': three distinct blobs of identical size, corresponding to the low, medium, and high dose calibration sets. Each begins with the firmware version and serial (header bytes 01 06 00 04 02 00 01 03 followed by the serial). Required to apply gain and offset correction to raw images.
* '''0xFE (bootloader)''': contains the strings spi_load.S and ../../boot and Nios II reset vector code.
* '''0x72 (shock log)''': text records of drop / vibration events with timestamps and per axis values; the same data is mirrored in the detector's small onboard EEPROM.
* '''0x06''': references a different serial, UA2010-8U005, likely the conditioner or generator board rather than the panel.

=== Significance ===

The complete flash image and all calibration data are recoverable over the
network without opening the detector, providing a full byte exact backup of the
unit before any write operation. The calibration maps are needed for image
correction, and the firmware image (the live, deployed build) is more complete
than the partial firmware files shipped on the recovery media.

=== Known Dead Ends ===

Things that were tried and did not work or led nowhere:

; 0xBEEF (48879) as reply port
: This was a bug in early test scripts. The port has no meaning in the protocol. Use 5550.

; CmdFlag=1 as data packet flag
: Early scripts had the URP fields swapped, setting CmdFlag=1 on data packets. The detector ignores all PDAP content in these packets. Power cycle the detector if this happened, it may retain stale port state.

; Image data on alternate ports
: Tried listening on 48879, 6660, 5550, 8100, 1050, 6661, 9999, 4444, 7000, 7001, 9001. Nothing arrived on any of them.

; PORT_SETUP byte order (big-endian)
: Current implementation sends port fields as big-endian. If the detector reads them as little-endian it computes port 44565 and 1050 instead of 5550 and 6660, which would explain why no image data arrives. Not yet confirmed.

; Image data streaming automatically after EXECUTE_SCRIPT
: Frames may not push during execution at all. The detector may require an explicit IMAGE_RETRIVAL_REQUEST (cmd_type=0x41) and IMAGE_RETRIVAL (cmd_type=0x98) after the 0x30000 notification before it streams anything. Not yet tested.

== Teardown / Internal Pictures / Hardware analysis ==
<div style="float:right; display:flex; gap:8px;">
[[File:GE Flashpad under the hood.jpg|thumb|none|220px|the Carbon fiber sleeve is held by 9 screws and can taken off without force.]]
[[File:Ge flashpad powersupply pcb in handle.jpg|thumb|none|220px|Power supply PCB]]
[[File:Ge flashpad uwb board pcb.jpg|thumb|none|220px|UWB PCB for Wireless USB using a RTU2705]]
[[File:Ge flashpad uwb pcb backside.jpg|thumb|Backside of UWB PCB]]
</div>
<div style="float:right; display:flex; gap:8px;">
[[File:Ge flashpad power supply pcb backside.jpg|thumb|Backside of Power supply PCB]]
[[File:Ge flashpad main pcb closeup1.jpg|thumb|Main area of the PCB with its Altera Cyclone 3 FPGA]]
[[File:Ge flashpad main pcb closeup2.jpg|thumb|AD7892 is a 600ksps 12bit ADC, SN74LVC8T245 a 8bit bus transceiver and DG9408EDN a 8ch MUX]]
[[File:Ge flashpad bottom connector ethernet isolation pcb.jpg|thumb|Isolation PCB for bottom connector]]
</div>
<div style="float:right; display:flex; gap:8px;">
[[File:Ge flashpad main pcb powersupply section.jpg|thumb|Powersupply section for FPGA and ROIC]]
[[File:Ge_flashpad_main_pcb_closeup_3.jpg|thumb|AD9764AR 14-Bit, 125 MSPS DAC and DS1682 integrated elapsed-time recorder]]

</div>

GE Medical Flashpad Digital Xray Detector

2026-06-11T11:46:32Z

Gamerpaddy: added details about everything

==Overview==

The '''GE Flashpad''' is a Digital Radiography image sensor from approximately 2010, originally used in the '''GE Optima 220AMX''' mobile X-ray unit. It was designed to replace analog film in radiology, dramatically reducing image acquisition time from hours to seconds.
[[File:GE Flashpad.jpg|thumb|Flashpad with Anti-Scatter grid (left), manual and recovery dvd for 220amx and tether cord (right)]]
Due to its high original cost and specialized application, used units occasionally appear on professional B2B marketplaces in the $15,000–$50,000 range. On eBay, prices typically fall between $1,500 and $5,000, though units at this price point are often in poor condition and may fail the built-in self-test or not function at all.

{{Note|All findings on this page are based on a single unit and the time spent working on it. Information is subject to speculation and may not be fully accurate.}}

{{Note|[[Artificial intelligence|AI]] assistance was used in writing this page for improved formatting and readability, as well as in the process of finding information, testing, and analyzing firmware dumps and backups.}}

== Purpose and Motivation ==

This project documents the reverse engineering of the GE FlashPad wireless
digital radiography detector used with the Optima XR200/220 AMX mobile X-ray
system, with the goal of freeing these detectors for independent use.
[[File:Xray capture pcb.png|thumb|Xray capture of a PCB for Reverse Engineering]]
Large numbers of these detectors reach the used market, but each one is
cryptographically and administratively bound to its original Optima 220 AMX
console. Once separated from that console, or once the console is
decommissioned, the detector is effectively useless even though the hardware is
fully functional. The aim of this work is to remove that artificial barrier so
that a standalone FlashPad can be paired, configured, and read out by any host,
without the half million dollar console it was sold with.

The intended beneficiaries are:

* Hobbyists, researchers, and engineers who want a high quality flat panel detector for their own imaging projects.
* Veterinary practices, which can put surplus human grade detectors to good use at a fraction of the cost of new equipment.
* Clinics and hospitals in countries and regions where a complete commercial system is unaffordable, allowing serviceable detectors to keep providing diagnostic imaging instead of being scrapped.
[[File:Xray current clamp multimeter.png|thumb|xray of a current clamp multimeter]]
This is done for human good. Every detector returned to service is one less
piece of working medical hardware sent to landfill, and potentially one more
place that can offer X-ray imaging where it otherwise could not.

All files, findings, protocol documentation, and tools produced by this project
are public and open source, so that anyone can study, reproduce, and build on
the work.

==Technical Specifications==
[[File:Ge flashpad tether cable pinout diagram.png|thumb|Pinout Diagram of the Tether cable]]
[[File:Ge flashpad tether wiring for ethernet cable.jpg|thumb|Professional Tether wiring to attach a Ethernet Cable and 12V socket to it.]]
The Flashpad uses a '''~40 × 40 cm CsI scintillator''' bonded to a [[Thin-film transistor|TFT]] photodetector array mounted on glass. The assembly is highly sensitive to shock and impact damage.

{| class="wikitable"
|-
!Parameter!!Value
|-
|Resolution||2048 × 2048 px
|-
|Bit depth||16-bit per pixel
|-
|Spatial resolution||Up to 5 lp/mm (theoretical)
|-
|Scintillator material||Caesium iodide (CsI)
|-
|Detector type||TFT photodetector array (glass substrate)
|-
|Panel size||~40 × 40 cm
|}

The theoretical 5 lp/mm spatial resolution is primarily limited in practice by the focal spot size of the X-ray source. Use of an anti-scatter grid can improve effective resolution.

=== Status of Reverse Engineering ===

{| class="wikitable"
|-
! What !! Status
|-
| Connect, beacon, ACK || Works
|-
| PORT_SETUP || Works
|-
| SIGNATURE_REQUEST / serial number readout || Works
|-
| Script download (Scripts 7, 8, 1) || Works
|-
| EXECUTE_SCRIPT || Works
|-
| EXECUTION_COMPLETE (dark acquisition) || Works
|-
| EXECUTION_COMPLETE (standard acquisition) || Needs real X-ray trigger to test
|-
| Image data on port 6660 || Does not work yet, under investigation. Will not send Imagedata yet.
|}

==Hardware Features==

===Shock logging===
The unit contains an internal accelerometer that logs significant shock events — but only when a battery is inserted. As there is no backup battery, shock events occurring while unpowered are not recorded.

===Wireless connectivity===
Some units include a UWB transmitter for Wireless USB; others may be equipped with a Wi-Fi module instead. The detector can also be operated over the tethered connection alone.

===Ethernet interface===
There is a 100MBit Ethernet interface trough the Tether Cable which can be tapped and used for Communication.
Exposed metal contacts on the bottom connector are isolated via relays by default. Enabling Gigabit Ethernet connectivity requires shorting or driving two specific pins. This has not been investigated further at this time.

== Communication Protocol ==

This section documents the URP/PDAP protocol used by the GE Flashpad (codename '''Apollo''') to communicate with a host over Ethernet. All findings are based on live capture tests, configuration files, and reverse-engineering of the GE SuperBee software stack.

{{Note|All findings are based on a single unit and may not be fully accurate.}}

=== Network Setup ===

All findings were over Ethernet only, no UWB or WIFI has been used.
Default detector IP is <code>192.168.1.30</code>. Set your host to a static IP in the same subnet, <code>192.168.1.1</code> works fine.

At first by sending random bytes over Python it answered to port 48879 (0xBEEF), which seems to be either the default port or set by Python.
After SYSTEM_SETUP it got set to 5550.

{| class="wikitable"
|-
! Role !! IP !! Port !! Direction
|-
| All commands: host -> detector || 192.168.1.30 || '''8100''' (UDP) || Host sends here
|-
| Discovery beacons: detector -> host || - || '''4500''' (UDP) || Detector sends here initially
|-
| Protocol replies: detector -> host || - || '''5550''' (UDP) || Detector sends here after setup
|-
| Image pixel data: detector -> host || - || '''6660''' (UDP) || Detector streams frames here
|}

In practice you can listen on port '''5550''' for everything (beacons and replies) by advertising that port in both <code>SYSTEM_STARTUP</code> and <code>PORT_SETUP</code>. The detector sends to whichever port was most recently configured.

=== Protocol Layers ===

Two layers, carried over UDP:

; URP (Unified Registration Protocol)
: 8-byte wrapper on every packet. Handles sequencing and acknowledgement.

; PDAP (Proprietary Detector Access Protocol)
: The actual command layer, present inside URP packets when <code>CmdFlag = 0</code>.

Every UDP packet starts with a URP header:

<pre>
[SeqId : 4 bytes LE] [CmdFlag : 4 bytes LE]
</pre>

* <code>CmdFlag = 0</code> -- data packet, PDAP command follows.
* <code>CmdFlag = 1</code> -- bare ACK, no PDAP body. SeqId echoes the packet being acknowledged.

Both sides must ACK every data packet immediately. The detector silently drops packets with a SeqId it has already seen, so always increment SeqId for each new command.

When CmdFlag is 0, the PDAP header follows immediately:

<pre>
[cmd_type : 4 bytes LE] [payload_len : 4 bytes LE] [payload ...]
</pre>

=== Connecting to the Detector ===

The connection sequence is:

# Broadcast <code>SYSTEM_STARTUP</code> to tell the detector where to reply.
# The detector sends a <code>BEACON</code> back -- ACK it and sync your sequence counter.
# Send <code>PORT_SETUP</code> to configure the reply and image ports.
# Send <code>SIGNATURE_REQUEST</code> to read the detector identity (serial number, model, firmware, MAC).

==== Step 1: SYSTEM_STARTUP ====

Broadcast UDP to <code>192.168.1.255:8100</code>. Always uses <code>SeqId = 0</code>.

<pre>
URP : [00 00 00 00] SeqId = 0
[00 00 00 00] CmdFlag = 0
PDAP: [01 00 00 00] cmd_type = 1
[06 00 00 00] payload_len = 6
[15 AE] host reply port = 5550 (big-endian)
[C0 A8 01 01] host IP = 192.168.1.1 (network byte order)
</pre>

<syntaxhighlight lang="python">
import socket, struct

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
sock.bind(("0.0.0.0", 5550))

HOST_IP = "192.168.1.1"
DET_IP = "192.168.1.30"
HOST_PORT = 5550
IMG_PORT = 6660

def make_urp_packet(seq_id, pdap_bytes):
return struct.pack("<II", seq_id, 0) + pdap_bytes

pdap = struct.pack("<II", 1, 6) + struct.pack(">H", HOST_PORT) + socket.inet_aton(HOST_IP)
sock.sendto(make_urp_packet(0, pdap), ("192.168.1.255", 8100))
</syntaxhighlight>

==== Step 2: Receiving the BEACON and ACKing ====

The detector broadcasts a <code>BEACON</code> (cmd_type=1) roughly every 2 seconds. After sending SYSTEM_STARTUP you should get one quickly. Parse the detector SeqId from the URP header and ACK it:

<syntaxhighlight lang="python">
data, addr = sock.recvfrom(4096)
det_seq = struct.unpack_from("<I", data, 0)[0]

# send bare ACK
ack = struct.pack("<II", det_seq, 1)
sock.sendto(ack, (DET_IP, 8100))

# all subsequent commands start from here
host_seq = det_seq + 1
</syntaxhighlight>

==== Step 3: PORT_SETUP ====

Tells the detector which host ports to use for replies and image data.

<pre>
PDAP: [02 00 00 00] cmd_type = 2
[04 00 00 00] payload_len = 4
[15 AE] host cmd port = 5550 (big-endian)
[1A 04] host image port = 6660 (big-endian)
</pre>

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 2, 4) + struct.pack(">HH", HOST_PORT, IMG_PORT)
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1
# expect bare ACK from detector
</syntaxhighlight>

==== Step 4: Reading the Serial Number (SIGNATURE_REQUEST) ====

Empty command, the detector replies with a 54-byte payload containing its identity.

<syntaxhighlight lang="python">
pdap = struct.pack("<II", 3, 0) # cmd_type=3, payload_len=0
sock.sendto(make_urp_packet(host_seq, pdap), (DET_IP, 8100))
host_seq += 1

# reply is 70 bytes total: 8 URP + 8 PDAP header + 54 payload
data, _ = sock.recvfrom(4096)
payload = data[16:] # skip URP (8) + PDAP header (8)

mac = payload[0:6]
serial = payload[22:34].rstrip(b'\x00 ').decode()
model = payload[34:46].rstrip(b'\x00 ').decode()
fw_bytes = payload[46:54]
firmware = ".".join(str(b) for b in fw_bytes)

print(f"MAC: {':'.join(f'{b:02X}' for b in mac)}")
print(f"Serial: {serial}")
print(f"Model: {model}")
print(f"Firmware: {firmware}")
</syntaxhighlight>

Expected output:
<pre>
MAC: 40:F4:A0:00:78:4D
Serial: UA45829-7
Model: 5340000-7
Firmware: 1.6.0.4.2.0.1.3
</pre>

=== Running an Acquisition ===

After the connection sequence above, download scripts to the detector and then execute them.

==== ROE Initialisation (Script 7) ====

Always run this first. It initialises the readout electronics and takes about 4-5 seconds. The detector sends host event ID 17 when done.

==== Dark / Offset Acquisition (Script 1) ====

No X-ray source required. Runs a dark-field exposure for offset calibration. Use this to verify the acquisition pipeline without a generator.

==== Standard Acquisition (Script 0) ====

Requires an actual X-ray exposure. <code>EXECUTION_COMPLETE</code> will '''not''' arrive without a real X-ray trigger.

==== Sequence Overview ====

<pre>
HOST DETECTOR
| |
|-- SYSTEM_STARTUP (broadcast) ----------->|
|<- bare ACK -------------------------------|
|<- BEACON (cmd_type=1) --------------------|
|-- bare ACK ------------------------------>|
| |
|-- PORT_SETUP (cmd_type=2) -------------->|
|<- bare ACK -------------------------------|
| |
|-- SIGNATURE_REQUEST (cmd_type=3) ------->|
|<- SIGNATURE_REPLY (54 bytes) -------------|
|-- bare ACK ------------------------------>|
| |
|-- GENERIC_SCRIPT Script7 (ROE init) ---->|
|<- bare ACK or SCRIPT_DOWNLOAD_REPLY ------|
| |
|-- GENERIC_SCRIPT Script1 (dark acq) ---->|
|<- bare ACK -------------------------------|
| |
|-- EXECUTE_SCRIPT (cmd_type=6) ---------->|
|<- bare ACK -------------------------------|
|<- EXECUTE_SCRIPT_REPLY (~230ms) ----------|
|-- bare ACK ------------------------------>|
|<- DETECTOR_STATE_NOTIFY (~890ms) ---------| state_id=17
|-- bare ACK ------------------------------>|
| |
|<- EXECUTION_COMPLETE (0x10000) -----------|
|-- bare ACK ------------------------------>|
| |
|<- IMAGE_XFER_STATUS_QUERY (0x30000) ------|
|-- bare ACK ------------------------------>|
|-- IMAGE_XFER_STATUS_REPLY (cmd_type=9) ->| numMissed=0
|<- bare ACK -------------------------------|
</pre>

=== Sequence Counter Rules ===

* <code>SYSTEM_STARTUP</code> always uses <code>SeqId = 0</code>.
* After the first beacon, set host SeqId to beacon_SeqId + 1.
* Increment SeqId by 1 for every new data packet (CmdFlag=0).
* Bare ACKs echo the SeqId of the packet being acknowledged and do not consume a SeqId.
* The detector silently drops any packet with a SeqId it has already processed, so never reuse one.

== Sensor Readout and Host Registration ==

This section documents the reverse engineered sensor telemetry interface and the
host registration (pairing) mechanism of the GE Optima XR200/220 AMX FlashPad
(URP detector, SuperBee, FW 1.6.0.4.2.0.1.3). All commands are PDAP over UDP to
the detector at port 8100; replies return to the host command port.

=== Sensor Readout ===

The detector exposes an analog sensor interface (the DEM, Detector Environment
Monitor) that is independent of the image transfer path and works regardless of
acquisition state.

==== Commands ====

{| class="wikitable"
! cmd_type !! Meaning !! Request payload !! Reply payload
|-
| 0x7900 || Raw sensor read || [sensorId:4 LE] || [value:4 LE] (12 bit ADC count)
|-
| 0x7902 || Converted sensor read || [sensorId:4 LE] || [value:4 LE] (engineering units, signed)
|-
| 0x7904 || Detailed / radio || [selector:4 LE] || [value:4 LE]
|}

Note: cmd 0x7902 IS supported on this firmware and returns calibrated
engineering units (millivolts for the supply rails, signed; 0.1 degree C for
temperatures). Earlier documentation that marked 0x7902 as unsupported is
incorrect. The host side conversion coefficients are not required; the detector
performs the conversion internally.

The full sensor map (name, sensorId) was recovered from the detector's own
[Sensor] configuration table, read back over the upload interface (see the
Registration section for the read protocol).

==== Power rails (live readings) ====

All supply rails read correctly via 0x7902 and are within normal range for a
flat panel detector. Representative readings:

{| class="wikitable"
! Sensor !! sensorId !! Converted !! Value
|-
| DCIN_RAW || 10 || 12100 mV || +12.10 V (main DC input)
|-
| LCORE_UNREG || 11 || 1724 mV || +1.72 V
|-
| LPANA_UNREG || 12 || 5776 mV || +5.78 V
|-
| LNANA_UNREG || 13 || -5801 mV || -5.80 V
|-
| SCAN_VCC || 14 || 5086 mV || +5.09 V (gate driver)
|-
| P5V_REF || 16 || 5025 mV || +5.03 V (5 V reference)
|-
| V_ON || 17 || 11085 mV || +11.09 V (TFT gate on)
|-
| V_OFF || 18 || -12378 mV || -12.38 V (TFT gate off)
|-
| V_COMMON || 19 || -9385 mV || -9.39 V
|-
| 3V3 || 29 || 3177 mV || +3.18 V (3.3 V logic)
|-
| VCC_UNREG || 37 || 3399 mV || +3.40 V
|-
| PARCPREG || 38 || 3768 mV || +3.77 V (ARC preamp +)
|-
| NARCPREG || 39 || -3732 mV || -3.73 V (ARC preamp -)
|-
| PANA_UNREG || 45 || 18352 mV || +18.35 V (photodiode bias +)
|-
| NANA_UNREG || 46 || -19251 mV || -19.25 V (photodiode bias -)
|}

Switched rails that are inactive while the panel is idle (PARCVA_U,
P5VA_SW, N5VA_SW, FGATE_NVC_L, FGATE_PVC_L, etc.) read at or near zero.

==== Known limitations ====

* '''Temperatures''' (Temp_Surface, sensorId 336; Temp_Panel, sensorId 352): the raw 0x7900 read rails at 0x3FF (1023, the ADC maximum), indicating an open thermistor path while the panel is idle. This is a hardware/state condition, not a command problem, and the temperature is not readable from the host in this state.
* '''Unimplemented sensors''': sensorIds 70 (Accelerator), 78 (Gravity), and 256 to 259 (Battery status, name, life, capacity), and 272 (Grid status) are not implemented on this DEM. The detector returns the leftover conversion register contents (a duplicate of a previously read sensor) rather than a real value, so these rows must be discarded.
* '''Accelerometer''': functional through a separate addressing scheme using raw cmd 0x7900 with selectors 0x42 (X), 0x43 (Y), 0x44 (Z), returning 12 bit per axis counts.

=== Host Registration (Pairing) ===

URP stands for Unified Registration Protocol. The detector maintains a host
list in its internal NOR flash. Image data is delivered only to a registered
primary host, so registration is a prerequisite for image transfer.

==== Host identity (MAC and HostId) ====

Each host is identified by a 16 character HostId derived deterministically from
the host's eth0 MAC address. The derivation (from the vendor generateHostId
script) is:

# Take the eth0 MAC, remove the colon separators, convert to upper case (12 hex characters).
# Prepend the last 4 characters to the full 12 characters.
# The result is 16 hex characters.

Example: MAC 00:6f:00:01:0a:3a becomes 006F00010A3A, then the last four (0A3A)
are prepended, giving HostId 0A3A006F00010A3A.

==== HostList structure ====

The host list is stored in flash at offset 0x940000 and can be read back over
the upload interface as data category 0x71. Layout:

Offset Size Field
0x00 16 DetectorDeviceId (ASCII)
0x10 16 ConnectionSecretKey (ASCII; "XXXXXXXXXXXXXXXX" when unset)
0x20 16 DetectorName (ASCII)
0x30 16 DetectorCode (ASCII)
0x40 2 CurrentNumberOfHosts (uint16 LE)
0x42 2 IndexToPrimaryHost (uint16 LE; 0xFFFF = none)
0x44 144*N Host entries, 144 bytes each:
+0x00 16 HostId (ASCII)
+0x10 .. host name / department string
+0x50 .. location string
... 4 CRC (big endian; see below)

==== HostList from the unit under test ====

Detector: MAC 40:F4:A0:00:78:4D, serial UA45829-7, model 5340000-7,
firmware 1.6.0.4.2.0.1.3. DetectorName starShape_green. ConnectionSecretKey
unset. CurrentNumberOfHosts = 3, IndexToPrimaryHost = 0xFFFF (no primary host).

{| class="wikitable"
! Index !! HostId !! Derived MAC !! Name
|-
| 0 || 2C6400045FB42C64 || 00:04:5F:B4:2C:64 || Haus 207 / ITS
|-
| 1 || B044E8393512B044 || E8:39:35:12:B0:44 || Not Initialized
|-
| 2 || 5CF800045FB15CF8 || 00:04:5F:B1:5C:F8 || Not_Initialized
|}

The unit is therefore not factory fresh; it carries registrations from a prior
deployment, but no primary host is currently designated.

==== Checksum (CRC) ====

The HostList (and other flash data blobs) are protected by a 4 byte trailing
CRC. Parameters:

* Polynomial: 0x04C11DB7
* Initial value: 0
* MSB first, augmented message style (the data bit is shifted into the LSB; no input or output reflection; no final XOR)
* Stored big endian

To generate: compute the CRC over the data followed by four zero bytes, then
append the result big endian. Verification: the CRC over (data plus stored CRC)
equals zero.

def crc(data, poly=0x04C11DB7, init=0):
c = init
for byte in data:
for bit in (0x80,0x40,0x20,0x10,0x08,0x04,0x02,0x01):
msb = c & 0x80000000
c = (c << 1) & 0xFFFFFFFF
if byte & bit: c |= 1
if msb: c ^= poly
return c
# trailer = crc(data + b"\x00\x00\x00\x00"), stored big endian

==== Read and write transport ====

Data blobs (including the HostList) are moved with a configure / buffer /
finalize sequence.

Read (upload, detector to host), non destructive:

{| class="wikitable"
! Step !! cmd_type !! host to detector !! detector to host
|-
| Configure || 0x13 || [uploadId:4 LE] || [status:1][totalSize:4 LE]
|-
| Buffer || 0x14 || [bufId:4 LE][numBytes:4 LE] || [bufId:4 LE][numBytes:4 LE][data]
|}

Write (download, host to detector), persistent (writes flash):

{| class="wikitable"
! Step !! cmd_type !! host to detector !! detector to host
|-
| Configure || 0x0E || [downloadId:4 LE][totalSize:4 LE] || [status:1]
|-
| Buffer || 0x0F || [bufId:4 LE][numBytes:4 LE][data] || [status:1][reserved:4]
|-
| Commit || 0x10 || (empty) || [status:1]
|}

bufId is a zero based chunk index. The HostList uses id 0x71 for both read and
write. The commit command (0x10) reuses the firmware flash path, so a malformed
download can corrupt flash; the operation is irreversible on this hardware.

==== Registering a new host ====

To register a host and make it the image destination, read the current HostList
(0x71), append a 144 byte entry carrying the new HostId, increment
CurrentNumberOfHosts, set IndexToPrimaryHost to the new entry's index,
recompute the trailing CRC, and write the blob back via the download sequence
(0x0E / 0x0F / 0x10).

== FlashPad Detector: Internal Flash Dump and Data Files ==

This section documents how the full contents of the detector's internal flash
were extracted over the network and what each recovered file contains. The
detector under test is a GE Optima XR200/220 AMX FlashPad (URP detector,
serial UA45829-7, MAC 40:F4:A0:00:78:4D, firmware 1.6.0.4.2.0.1.3).

=== Background ===

The detector's main storage is a Spansion/Cypress S29GL512P (marked
GL512P10FFCR2), a 512 Mbit (64 MB) parallel NOR flash. A direct chip read
requires bus access or desoldering and a programmer. However, the detector
firmware exposes its stored data blobs, including a full image of the flash,
through the read (upload) side of the data transport protocol. This makes a
complete, byte exact dump possible over UDP with no physical access.

=== Extraction method ===

The upload interface is the read counterpart of the firmware download path and
is non destructive (it only reports and returns data; nothing is written).
Each data category is identified by an 8 bit upload ID:

{| class="wikitable"
! Step !! cmd_type !! host to detector !! detector to host
|-
| Configure || 0x13 || [uploadId:4 LE] || [status:1][totalSize:4 LE]
|-
| Buffer || 0x14 || [bufId:4 LE][numBytes:4 LE] || [bufId:4 LE][numBytes:4 LE][data]
|}

A configure request returns status 0 and a total size for a valid ID, or a non
zero status for an unsupported ID. The dump tool sweeps all IDs from 0x00 to
0xFF, and for every readable ID it pulls the full blob in fixed size chunks
(bufId is a zero based chunk index) and writes it to a file. The 64 MB flash
image transfers as 65536 chunks of 1024 bytes.

=== Recovered files ===

A sweep of the unit returned 18 readable blobs:

{| class="wikitable"
! Upload ID !! Size (bytes) !! Contents
|-
| 0xFD || 67108864 || Full 64 MB NOR flash image
|-
| 0xFF || 16777216 || 16 MB region (firmware / FPGA mirror or image buffer)
|-
| 0xFE || 524288 || Bootloader (512 KB; SPI loader, Nios reset code)
|-
| 0x10 || 6815783 || Calibration map, dose level 1
|-
| 0x11 || 6815783 || Calibration map, dose level 2
|-
| 0x12 || 6815783 || Calibration map, dose level 3
|-
| 0x06 || 49254 || Table referencing conditioner/generator serial UA2010-8U005
|-
| 0x50 || 19938 || Per mode calibration coefficients
|-
| 0x51 || 19582 || Per mode calibration coefficients
|-
| 0x07 || 12187 || Sensor conversion table (text; see Sensor Readout)
|-
| 0x72 || 3001 || Shock / drop event log (text)
|-
| 0x0E || 624 || Panel geometry / configuration (binary)
|-
| 0x71 || 504 || Host list / registration record (see Host Registration)
|-
| 0x0F || 233 || Host to detector compatibility table (text)
|-
| 0x08 || 62 || Serial and model strings
|-
| 0x0A || 48 || Manufacturing codes
|-
| 0x52 || 30 || Serial string
|-
| 0x0B || 24 || Small marker / identifier
|}

=== Flash image layout (upload ID 0xFD) ===

A block scan of the 64 MB image shows the following regions:

{| class="wikitable"
! Range !! Contents
|-
| 0x000000 to 0x800000 || Firmware and FPGA configuration
|-
| 0x800000 to 0x940000 || Sparse configuration area
|-
| 0x940000 || Host list / registration record (matches upload ID 0x71)
|-
| 0x1000000 to 0x2800000 || Calibration and image data (16 to 40 MB)
|-
| 0x2800000 to 0x4000000 || Erased / unused (40 to 64 MB)
|}

The host list strings (the DetectorName starShape_green, the registered host
name Haus 207 / ITS, and the unset ConnectionSecretKey placeholder) appear at
0x940000, confirming that the 504 byte 0x71 read maps to this flash region.

=== Notes on individual files ===

* '''0x07 (sensor table)''': plain text, header DetectorSerialNumber = UA45829-7, revision 1.2. Lists every sensor by name, command (0x7902), and sensorId. Also carries panel geometry in its [Common] section: 16 bit depth, 2048 by 2048 pixels, active area from (12, 12) to (2035, 2035), pixel pitch 0.2 mm, corner radius 1416.8, panel saturation 150.
* '''0x10, 0x11, 0x12 (calibration maps)''': three distinct blobs of identical size, corresponding to the low, medium, and high dose calibration sets. Each begins with the firmware version and serial (header bytes 01 06 00 04 02 00 01 03 followed by the serial). Required to apply gain and offset correction to raw images.
* '''0xFE (bootloader)''': contains the strings spi_load.S and ../../boot and Nios II reset vector code.
* '''0x72 (shock log)''': text records of drop / vibration events with timestamps and per axis values; the same data is mirrored in the detector's small onboard EEPROM.
* '''0x06''': references a different serial, UA2010-8U005, likely the conditioner or generator board rather than the panel.

=== Significance ===

The complete flash image and all calibration data are recoverable over the
network without opening the detector, providing a full byte exact backup of the
unit before any write operation. The calibration maps are needed for image
correction, and the firmware image (the live, deployed build) is more complete
than the partial firmware files shipped on the recovery media.

=== Known Dead Ends ===

Things that were tried and did not work or led nowhere:

; 0xBEEF (48879) as reply port
: This was a bug in early test scripts. The port has no meaning in the protocol. Use 5550.

; CmdFlag=1 as data packet flag
: Early scripts had the URP fields swapped, setting CmdFlag=1 on data packets. The detector ignores all PDAP content in these packets. Power cycle the detector if this happened, it may retain stale port state.

; Image data on alternate ports
: Tried listening on 48879, 6660, 5550, 8100, 1050, 6661, 9999, 4444, 7000, 7001, 9001. Nothing arrived on any of them.

; PORT_SETUP byte order (big-endian)
: Current implementation sends port fields as big-endian. If the detector reads them as little-endian it computes port 44565 and 1050 instead of 5550 and 6660, which would explain why no image data arrives. Not yet confirmed.

; Image data streaming automatically after EXECUTE_SCRIPT
: Frames may not push during execution at all. The detector may require an explicit IMAGE_RETRIVAL_REQUEST (cmd_type=0x41) and IMAGE_RETRIVAL (cmd_type=0x98) after the 0x30000 notification before it streams anything. Not yet tested.

== Teardown / Internal Pictures / Hardware analysis ==
<div style="float:right; display:flex; gap:8px;">
[[File:GE Flashpad under the hood.jpg|thumb|none|220px|the Carbon fiber sleeve is held by 9 screws and can taken off without force.]]
[[File:Ge flashpad powersupply pcb in handle.jpg|thumb|none|220px|Power supply PCB]]
[[File:Ge flashpad uwb board pcb.jpg|thumb|none|220px|UWB PCB for Wireless USB using a RTU2705]]
[[File:Ge flashpad uwb pcb backside.jpg|thumb|Backside of UWB PCB]]
[[File:Ge flashpad power supply pcb backside.jpg|thumb|Backside of Power supply PCB]]
[[File:Ge flashpad main pcb closeup1.jpg|thumb|Main area of the PCB with its Altera Cyclone 3 FPGA]]
[[File:Ge flashpad main pcb closeup2.jpg|thumb|AD7892 is a 600ksps 12bit ADC, SN74LVC8T245 a 8bit bus transceiver and DG9408EDN a 8ch MUX]]
[[File:Ge flashpad bottom connector ethernet isolation pcb.jpg|thumb|Isolation PCB for bottom connector]]
[[File:Ge flashpad main pcb powersupply section.jpg|thumb|Powersupply section for FPGA and ROIC]]
[[File:Ge_flashpad_main_pcb_closeup_3.jpg|thumb|AD9764AR 14-Bit, 125 MSPS DAC and DS1682 integrated elapsed-time recorder]]

</div>

File:Ge flashpad main pcb closeup 3.jpg

2026-06-11T11:42:13Z

Gamerpaddy:

closeup of the ad9764 and max4490

File:Ge flashpad main pcb powersupply section.jpg

2026-06-11T11:40:43Z

Gamerpaddy:

powersupply section of main pcb

File:Ge flashpad bottom connector ethernet isolation pcb.jpg

2026-06-11T11:40:07Z

Gamerpaddy:

isolation pcb for bottom interface

File:Ge flashpad main pcb closeup2.jpg

2026-06-11T11:38:09Z

Gamerpaddy:

closeup of area with ad7892 600ks/s ADC

File:Ge flashpad main pcb closeup1.jpg

2026-06-11T11:36:41Z

Gamerpaddy:

Closeup of main pcb with fpga

File:Ge flashpad power supply pcb backside.jpg

2026-06-11T11:35:50Z

Gamerpaddy:

ge flashpad power supply pcb backside

File:Ge flashpad uwb pcb backside.jpg

2026-06-11T11:35:09Z

Gamerpaddy:

ge flashpad uwb pcb backside

File:Ge flashpad uwb board pcb.jpg

2026-06-11T11:33:51Z

Gamerpaddy:

ge flashpad uwb board pcb

File:Ge flashpad powersupply pcb in handle.jpg

2026-06-11T11:31:44Z

Gamerpaddy:

ge flashpad powersupply pcb in handle

File:Ge flashpad tether wiring for ethernet cable.jpg

2026-06-11T11:29:57Z

Gamerpaddy:

ge flashpad tether wiring for ethernet cable

File:Ge flashpad tether cable pinout diagram.png

2026-06-11T11:28:37Z

Gamerpaddy:

ge flashpad tether cable pinout diagram

File:Xray current clamp multimeter.png

2026-06-11T11:27:59Z

Gamerpaddy:

xray of a current clamp multimeter

File:Xray capture pcb.png

2026-06-11T11:26:59Z

Gamerpaddy:

xray capture of a ta caruso main pcb

File:GE Flashpad.jpg

2026-06-11T11:24:47Z

Gamerpaddy:

Device with Anti-Scatter grid (left), Software and Manual ontop and Tether cable Right.

File:GE Flashpad under the hood.jpg

2026-06-11T11:22:27Z

Gamerpaddy:

Teardown picture with the carbon fiber sleeve taken off.

GE Medical Flashpad Digital Xray Detector

2026-06-11T10:54:28Z

Gamerpaddy: removed links of some words

GE Medical Flashpad Digital Xray Detector

2026-06-11T10:51:52Z

Gamerpaddy: Page creation, initial commit.

== Overview ==

The '''GE Flashpad''' is a [[Digital Radiography]] image sensor from approximately 2010, originally used in the '''GE Optima 220AMX''' mobile X-ray unit. It was designed to replace analog film in radiology, dramatically reducing image acquisition time from hours to seconds.

Due to its high original cost and specialized application, used units occasionally appear on professional B2B marketplaces in the $15,000–$50,000 range. On eBay, prices typically fall between $1,500 and $5,000, though units at this price point are often in poor condition and may fail the built-in self-test or not function at all.

{{Note|All findings on this page are based on a single unit and the time spent working on it. Information is subject to speculation and may not be fully accurate.}}

{{Note|[[Artificial intelligence|AI]] assistance was used in writing this page for improved formatting and readability, as well as in the process of finding information, testing, and analyzing firmware dumps and backups.}}

== Technical Specifications ==

The Flashpad uses a '''~40 × 40 cm [[Caesium iodide|CsI]] scintillator''' bonded to a [[Thin-film transistor|TFT]] photodetector array mounted on glass. The assembly is highly sensitive to shock and impact damage.

{| class="wikitable"
|-
! Parameter !! Value
|-
| Resolution || 2048 × 2048 px
|-
| Bit depth || 16-bit per pixel
|-
| Spatial resolution || Up to 5 lp/mm (theoretical)
|-
| Scintillator material || Caesium iodide (CsI)
|-
| Detector type || TFT photodetector array (glass substrate)
|-
| Panel size || ~40 × 40 cm
|}

The theoretical 5 lp/mm spatial resolution is primarily limited in practice by the focal spot size of the X-ray source. Use of an [[anti-scatter grid]] can improve effective resolution.

== Hardware Features ==

=== Shock logging ===
The unit contains an internal [[accelerometer]] that logs significant shock events — but only when a battery is inserted. As there is no backup battery, shock events occurring while unpowered are not recorded.

=== Wireless connectivity ===
Some units include a [[Ultra-wideband|UWB]] transmitter for Wireless USB; others may be equipped with a [[Wi-Fi]] module instead. The detector can also be operated over the tethered connection alone.

=== Ethernet interface ===
Exposed metal contacts on the bottom connector are isolated via relays by default. Enabling [[Gigabit Ethernet]] connectivity requires shorting or driving two specific pins. This has not been investigated further at this time.

Dali D8X3N Thermal Camera

2026-06-03T22:00:39Z

Gamerpaddy: /* Raw Viewer update to rev5*/

=Dali D8X3N Thermal Camera Reverse Engineering=
 

===Introduction===
The [https://www.dali-irtech.com/productinfo/741567.html Dali D8X3N] Thermal Camera module comes in two versions, a 384x288 and 640x480 resolution, utilizing the [http://www.dali-tech.us/products/dld64017m-uncooled-infrared-fpa-detector-86.html DLD Series] of amorphous-Silicon Microbolometers.

They were mainly used in [http://www.dali-tech.us/products/dm60-w--online-body-temperature-thermal-imaging-camera-55.html Dali DM60-W] or WS-1 Body Temperature screening cameras in conjunction with a Black Body radiator set to 37°C to detect infected individuals at the start of the 2020 Covid Pandemic.
[[File:ICI FM320P Innerts.jpg|thumb|Internals. A TP-Link Switch, HikVision Visible Camera and the D8x3N Network thermal camera module]]
[https://infraredcameras.com/ ICI] rebranded these models as FM 320 P and FM 640 P, and distributed them on the local US market, but as the need for such Cameras exploded, those models were built with what was in stock.

So happens, that some of the FM 320 P Models had a DLD640 640x480 instead of a DLD384 384x288 Microbolometer in them, and just got their Firmware modified.

It also could be, because they have excessive amounts of bad pixels outside the 384x288 area, that they were binned to a lower grade.

Discussions about these Cameras started around 2022 in the [https://www.eevblog.com/forum/thermal-imaging/ici-and-dali-thermal-camera-software/ EEVBlog Forums.] when they started to appear secondhand and affordable.

Originally they were priced around US$ 20... 30.000 by ICI, and a unknown amount by Dali Tech.

The Modules specs according to the manufacturer are:

≤50..60mK@F1，300K，50Hz

17 or 25µm pixel pitch

Hisilicon SoC running Linux to provide Onvif and RTSP streams, analysis and a Web UI

 
[[File:Dali D8X3N Module.jpg|thumb|A real 384x288 model with a DLD384 sensor. notice the Productnumber ]]
ICI FM Cameras are found all over Online secondhand marketplaces for scrap Prices, as they are no longer needed.

But you never know, what are you getting. It could be a real DLD384 or the better DLD640 inside. Its a gamble.
 

======640x480 Imagers======
are labeled 22D843 Nxxxx and have a DLD640 sensor in it, they can be upgraded if they run the 384x288 firmware.

======384x288 Imagers======
are labeled 22D883Nxxxx and have a DLD384 sensor in it, they cannot be upgraded

 

==D8X3N Module closer look==
From now on, i will refer to the Thermal Imaging Module as TIM

On the front there is a 2 Element Germanium Lens of a unknown focal length and aperture.

It can be focus-adjusted when unscrewing the clamp around the housing. It can be focussed from infinity down to 10..20cm with some quality loss.
 The outter diameter of the Lens is 42mm with a 1 1/3 inch thread diameter of undetermined pitch.

Dimensions of the germanium elements are 21mm to 3 and 6mm and 14grams in weight.
[[File:Disassembled Thermal Camera Lens.jpg|thumb|Two element Germanium Lens of unknown focal length and aperture]]

The TIM is composed of 6 Stacked PCB modules, 3 of which are for the Web Server functionality. taking them off will give you the basic configuration of a [https://www.dalithermal.com/productinfo/741568.html Dali D8X3C] TIM<gallery>
File:Dali DLD640 Thermal Image Sensor.jpeg|DLD640 Sensor
File:Dali DLD384 Thermal Imaging Sensor.jpeg|DLD384 Sensor
File:Dali D8X3N Board1 Back.jpeg|Network & GPIO Board Back
File:Dali D8X3N Board1 Front.jpeg|Network & GPIO Board Front
File:Dali D8X3N Glue Board Back.jpeg|Board between Logic and IO Back
File:Dali D8X3N Glue Board Front.jpeg|Board between Logic and IO Front
File:Dali D8X3N SoC Board Back.jpeg|SoC Board back
File:Dali D8X3N SoC Board front.jpeg|SoC board front
File:Dali D8X3N FPGA Board Back.jpeg|FPGA Board of the D8X3C Thermal Imager including a PMIC
File:Dali D8X3N FPGA Board Front.jpeg|FPGA Board Front with Video DAC and SPI Flash
File:Dali D8X3N Sensor Power and ADC Board.jpeg|Sensor control and ADC board
File:Dali D8X3N Thermal Core Debug wiring.jpeg|Debug wiring for sniffing SPI and UART
</gallery>

===User Manual===
including pinout diagram and important data

can be found here https://archive.org/details/dali-d-8-x-3-cuser-manualen-v-1.0-1

==Viewing the Video Stream==
[[File:Onvif Device Manager ODM.png|thumb|ODM streaming the Thermal view]]
when first connecting it to power and Ethernet, the camera will have 192.168.1.102 as a Static ip.

If you are running a 192.168.0.x or .178.x net, you need to change it or add a subnet under windows ipv4 settings.

to view it, you can use VLC and the stream URL
rtsp://admin@admin:<camera ip>/ONVIFMedia
there is /ONVIFMedia /ONVIFMediaM and /ONVIFMediaS for different stream Profiles.

VLC is quite slow and delayed, rather use Onvif Device Manager ODM,

it has no delay and auto-detects cameras in the network.

Be sure to log in as user: admin pass: admin in ODM.

in there, you can also set you camera to DHCP under Network settings.

===Web Interface===
[[File:Dali D8X3N web interface.png|thumb|Since browsers cant display RTSP anymore, open in Edge and select IE Compatibility Mode.]]
the web interface can be accessed by opening the camera IP in a browser

login is:
user: admin pass: admin
You can set Temperature markers and areas, but without using the Black Body calibration source, your readings may be way off or not working.

 

====OSD====
there is a debug-login with
user: super pass: 871897
that lets you send Key commands to the Imager to navigate the OSD.

Setting the OSD to english is accomplished with option #11
[[File:Dali D8X3C OSD.png|thumb|OSD in english, if yours is Chinese. go to option #11 and click + or -]]

To acces some locked menus, press
+ - + - + -

The password for the locked System and Main menu is
+-MC+-

Be careful in the UART menu to not change the BAUD rate or Protocol, as your ability to control it via the Web API gets lost.

You need to reflash or solder buttons on the thermal core then.

==Viewing Raw Thermal Data from the Web API==
there is a hidden endpoint in the stream.so file that could be found while decompiling

accessing
[[File:Arduino Nano blink sketch thermal gif.gif|thumb|Arduino Nano running blink sketch while thermally recording it, notice the led and resistor on the right]]
<ip of camera>:5000/stream?Type=JPEG&Source=Jpeg&Mode=TCP
lets you download a JPEG. but there are more options available (not all have been tested)

we are mainly interessted in Raw thermal data.

====Source (Stream Type)====

*<code>Major</code> - Main video stream (channel 0)
*<code>Minor</code> - Sub video stream (channel 1)
*<code>MinorAV</code> - Sub video + audio stream
*<code>MajorAV</code> - Main video + audio stream
*<code>Jpeg</code> - JPEG snapshot stream
*<code>Raw</code> - Raw thermal data stream
*<code>YUV</code> - YUV raw video stream

====Type (Data Format)====

*<code>H264</code> - H.264 video encoding
*<code>JPEG</code> - JPEG image format
*<code>RAW</code> - Raw sensor data
*<code>QBOX</code> - Custom protocol format
*<code>FRAME</code> - Frame-based format

====Mode (Transport Protocol)====

*<code>TCP</code> - TCP streaming (default)
*<code>UDP</code> - UDP streaming
*<code>MUL</code> - Multicast streaming

====Quality Parameters====

*<code>Quality=[1-100]</code> - Video quality level
*<code>Frames=[number]</code> - Number of frames to send
*<code>Interval=[ms]</code> - Frame interval in milliseconds

====Network Parameters====

*<code>IPAddr=[ip]</code> - Client IP address for UDP/multicast
*<code>Port=[port]</code> - Client port for UDP/multicast
*<code>Heart-beat=[Yes/No]</code> - Enable/disable heartbeat

====Snapshot Parameters====

*<code>Snap=[Yes/No]</code> - Enable snapshot mode

 
====Raw Viewer for PC (Python)====
[[File:Dali D8X3N Raw Thermal viewer.png|thumb|Raw Data Viewer in python]]

To view the raw stream, i made a python program that converts the 14bit thermal data to a visible image.

it is low fps tho, due to bad optimizations.

rev1 first working version https://pastebin.com/dyNWDPT3

rev2 with temperature readout https://pastebin.com/u107Q85w

rev3 first web only edition running in javascript on the device.

rev4..5: added CLAHE contrast enhancement, noise reduction, peformance improvement, see blow.

====Raw Viewer for the internal Webserver (recommended)====
It is also possible to use the Raw viewer directly in the browser.

To achieve this, the stream had to be proxied from port 5000 to 80 due to CORS.

luckily the internal lighttpd had the CGI module enabled, so piping it troug (using wget ... i know) worked with very low overhead.

To install, you need '''Terminal access''' to the Camera. see below.

optional for simplicity: '''ftp''' access

[[File:Dali D8X3N Webviewer.png|thumb|Web Raw Viewer with histogram (rev3)]]

Create the files and the code inside.

'''/app/web/webpages/raw.html''' https://pastebin.com/LM3Gmeez

'''/app/web/webpages/raw.js''' https://pastebin.com/n9wAVW63

and

'''/app/web/webpages/cgi-bin/proxy.cgi''' https://pastebin.com/vii1HXcU

then run
chmod +x /app/web/webpages/cgi-bin/proxy.cgi
'''restart''' your camera.

It should be accessible now trough '''http://<camera ip>/raw.html''' in the browser and click Start Stream

'''NOTE''': ''If it does not work'', check the contents of both files. FTP sometimes messes them up.

also run
dos2unix /app/web/webpages/cgi-bin/proxy.cgi
because linux <> windows difficulties that couldnt be resolved in over 30 years.

<blockquote>

performance may need improvement.</blockquote>

==Getting Root Terminal Access==
To access the Terminal you need to solder or plug in a UART connection to Connector J7 on the "Glue" board.

Pinout is (left to right) '''RX TX GND 3.3V Baud 115200 3.3V!'''

But the system will spam with debug messages, making patching the files a hard job unless you use "tftp" or "sed" commands.
 

====Enabling Telnet access to make patching easier====
[[File:Upgrade ici dali firmware updater.png|thumb|ICI Firmware updater software with modified firmware loaded]]

there is a easier way using a modified Firmware updater to enable Telnet temporarily to patch the Files.

Download the '''upgrade_ici.exe''' form [https://archive.org/details/fwupdate here] and run it.

Then you should be able to connect to it via Telnet.

The Login credentials are '''User: roo'''t '''Password: DLroot'''

 

===Patching Device===

===Patching the Web Server===
 

====Enabling Telnet and ftpd permanently====

This only works if you also patch the Thermal Camera module flash!

to permanently enable Telnet, go to '''/etc/init.d''' and edit '''S90app'''
vi S90app
in vi, move your cursor to the '''#''' at '''#telnetd''' and press x<blockquote>optional: enable ftp by removing the '''#''' at '''ftpd''' and adjust the path to / </blockquote>now press ''':''' and type '''wq''' and hit '''enter'''. this should be it.

====Patching the decoder and streamer to 640x480:====
go to /app and edit the mach.cfg

replace DL384 with D640 and edit the resolution to 640 480

(press i in vi to enter edit mode, press ESC to exit edit mode. :wq to write and quit.)

repeat that procedure for the dali.cfg

=====(optional) patching app.sh to prevent it from rebooting=====
edit the app.sh in /app and remove all "reboot" occasions to prevent the camera from rebooting if onvifserver, httpd or daliServer arent running for debugging purposes.

 

====Patching the Thermal Camera module====
To patch it, you need to disassemble everything down to the FPGA Board,

on the bottom there is a SPI SOIC8 Flash.

Use a CH341 EEPROM programmer (be sure to have a fixed or modified version to not put out 5V!, set it to 3.3V) and SOIC8 clamp.

Use NeoProgrammer (i used 2.2.0.10 but there are newer available, use the latest) and click Detect. It should find W25Q128 chips, select the FV one.

Dont forget to download a backup of your flash and save it !

Download the Binary "Dali 640x480 '''actual''' cleared pixelmap.bin" from #3 below and load it into NeoProgrammer,

Click Erase, Program and Verify.

This can take a while.

Your imager should start up right after assembly by hearing the shutter click.

==Hardware Hacking==

===Flash Contents===
On archive, click on show all files to download them.

<nowiki>#</nowiki>1 a Flash dump of the original downgraded D8X3N can be found [https://archive.org/details/dali-d-843n-flash-dump here]

<nowiki>#</nowiki>2 a Flash dump of a original 640x480 model can be found [https://archive.org/details/d-843-n-640x-480 here]

<nowiki>#</nowiki>3 a modified Flash dump of a 640x480 with cleared dead pixel map, flat map etc. can be found [https://archive.org/details/d-843-n-640x-480-cleared-pixelmap here]

a Flash dump of the web server SPI flash W25Q256JV can be found [https://archive.org/details/dm-60-webserver-flash-dump here] in case a bad firmware update caused a bootloop.

 

===Flash Binary Analysis===
The Flash IC is a Winbond 25Q128JV SPI Flash that contains the FPGA Bitstream, Deadpixel and Flatmap, aswell as the Device Settings.

a copy of the SPI Logic Capture at startup can be found [https://archive.org/details/dali-eeprom-capture here], the free software [https://www.dreamsourcelab.com/download/ DSView from DreamSourceLab] is required to view it.
[[File:Dali Thermal Imager SPI Flash capture.png|thumb|SPI Flash access while booting the Thermal Module]]

a approximation of the offsets resulted in this list:<syntaxhighlight lang="vb">
0x000000 - altera cyclone iv stuff
0x200000 - settings
0x280000 - Flat field correction map
0x4C0000 - Bad Pixel correctio nmap
0x580000 - image aswell? 36010 bytes
0x740000 - GUIX?
0x7C0000 - Strings for Gui?
0x800000 - another shorter GUIX
0x880000 - Strings for second gui?
0x8C0000 - GUIX
0x940000 - Strings for gui
0xE00000 - ?
0xE80000 - dzxg? short
0xEC0000 - crosshair.bmp
0xF40000 - 3DTM?
0xF80000 - fake? Bad pixel map BPRP
</syntaxhighlight> 

====Settings offset 0x200000====
The settings are read and written every startup, aswell when you close the OSD, sporadically and when executing the command MSV

these are some of the settings i could figure out by changing and watching the logic capture what changed.
 <syntaxhighlight lang="vb">
offset size Cmd
0x0 1 SAG (0-2) auto gain
0x2 2 SVB (0-16383) saved value is 16383 - SVB
0x4 2 SVC (0-1023) set exposure or gain
0x6 1 SSM image filtering
0x8 1 SEH image enhancement
0xA 1 SWP invert b/w polarity
0x14 1 SMR Flip
0x16 1 SMR Mirror
0x20 1 MENU Cal source 0 IN, 1 OUT
0x3A 1 MENU Enhance value 0-100
0x40 1 MENU Rectify (shutter 0 OFF, 1 L, 2 H)
0x50 1 MENU Language 0 english, 1 chinese, 2 russian
0xA2 - SCO set contrast gain
0xA4 - IBR set brightness
0xAE 2 MENU Fire Threshold
0xAC 1 SPA set color palette
0xE2 1 SMS display "collected 0/80" enabled
0xF8 1 SEM set emissivity
0x110 1 SRT set revise temp
0x116 1 SHD set humidity
0x118 1 SET set ambient temp
0x11A 1 STD set temp range
0x120 2 SLG -500 to 500?
0x124 2 SRD set distance
0x12C 1 SCP ???
0x130 2 SCT ???
</syntaxhighlight> 
[[File:Dali D8X3N Bad Pixel Map Viewer.png|thumb|Bad pixel map of a 640x512 sensor, about 0.56% of dead pixels in this map]]
So i let the AI create a [https://2476424.playcode.io/ Configurator page] that lets you change the Settings in your Flashdump to your liking
 

====Bad Pixel and Flatframe Maps 0x280000 and 0x4C0000====
Thermal cameras require a bad pixel and flat frame map to compensate for manufacturing inconsistencies.

unfourtainly, the maps of the downgraded cameras only contain enough data for a 384 model, not the full 640.

at offset 0xF80000 there is a BPRP which was mistaken at first as the Bad pixel map, it could just be a mask to where to apply the offset maps, as its either 0x0 or 0x1.

The [https://2477569.playcode.io/ Viewer Page] is written in JS and does not require any special dependencies, it can run as a plain html file offline.

''See "Automatic Dead Pixels and Flatmap Correction" below how to create new dead pixel and flatmaps using the system menu.''

[[File:Dali D8X3N Flat Field Map Viewer.png|thumb|Flat Field viewer]]

==Dali Commands==
To control the TIM you can either use Pelco or Dali command set. By default the Dali commandset is used at 38400 BAUD.

Those commands consist of a 0x02 start byte followed by two length Bytes, then the actual command which is allways 3 uppercase Letters in ASCII (eg. KBD for keyboard) followed by a comma and the values.

Some commands take multiple values, some dont. But you allways have to send the comma after the Command.

The camera will answer with the Command and 0, 1 or 2. Sending no value counts as zero.
0 is invalid parameters, too few or out of range

1 is OK, valid command

2 is Invalid command

Commands can be sent trough the Web server using the URL Api endpoint or directly trough the UART port.

(keyboard, C button, causes the shutter to do a calibration)
<camera ip>/cgi-bin/dmcmd?Command=KBD,C
Listening to the answer can be done while being in the Linux shell and typing
cat /dev/ttyAMA2 | strings

By bruteforcing the UART with AAA to ZZZ a list of Commands could be obtained, but some with unknown Parameters or functionality yet. including some from a decompiled DM60comm.so module found in /app/modules folder.<syntaxhighlight lang="vb">
KBD KEY Keyboard (F S M C + -)
SSM 0-1 Image Filtering Off/On
GSM 0 Image filter status
SEH 0-1 Image Enhancement Off/On
GEH 0-1 Image enhancer status
SCO 0-255 Set Gain (locked when SAG auto gain is on)
GCO 0-255 Get gain
INT 15-320 set actual gain? not just contrast sometimes disabled?
IBR 0-255 Set brightness
GBR 0-255 Get brightness
SMR 0-3 Mirror mode bit0=horizontal, bit1=vertical
GMR 0 Get rotation/flip
SDT 0-1 displays temp=44.65°C osd, but webserver sends date/time to the cam there....
GDT 0-1 Get temp display active?
GPT Display temp oft SDT
GNU 0-1 Get Shutter closed/open
SNU 0-1 Shutter close / open
STD 0-1 Set Range 0: -20-180°C 1: 100-600°C
GTD 0-1 Get Range
SET °C Set Ambient temperature
GET °C Get Ambient temperature
SEM 0-100 0-1 set emissivity x100
GEM 0-100 Get Emissivity
SRT °C Set revise temperature -100-100 -10-10°
GRT °C Get revise temperature
SRD 100 Set Distance 4.4m x100
GRD 100 Get Distance
SHD 0-100 Set Humidity
GHD 55 Get Humidity
SWP 0-1 invert s/w polarity image
GWP 1 is inverted?
SPA 0-10? Set color palette
GPA 3 white hot
SMV 0-1 Show temperature 3x3 grid?? in combination with GTV maybe
GMV 0
SMS 0-1 displays "collected 0/<number set by SCT>" by SCP delay "saves the daily number of highest temperatures?"
GMS 0
SCT 1-500 sets the amount of "collected" points for SMS
GCT 80
SCP 5-60 "collected" delay in seconds for SMS
GCP 60
SAG 0-2 Auto brightness / gain
GAG 0
SLR 0-9 ???
GLR 0
SRP 0,0 - 639,479 set crosshair position
GRP 320,240 get crosshair position
DRC 0-1 Show crosshair
SLG -500-500 ??
GLG
SCE text ??
GCE 0
SCB text ??
GCB 0
SVB 0-16383 adc offset, exposure? good at 9650
GVB 6733 value is 16383 minus SVB
SVC 1-1023 set contrast but better
GVC 260
SVF 100-? ?? video freaks out 3400 seems good
SVS 100-? ?? video freaks out 3300 seems good
SOT 0-1 ?? sensor supply, looks weird when off.
SZM 1-4 ?
GZM 1
MSV save settings too eeprom
ASV Saves something aswell?
GCS 0 Get Core status & faults
ALD 0,2? video blanks lots of eeprom activity. reload pixel map??
SAV 0-9999 set Fire threshold
GAV 2100 get Fire Threshold
BAC change uart protocol? careful
CBD Displays Recovery successful?
CBS Displays Saved successfully
LRD Displays Recovery successful?
LRS Displays Saved successfully?
LRE Displays Temperature Repair successful?
CBT Displays Calibration successful?
DBP ??? shutter clicks
DPI Show weird pixels
API Hide weird pixels
CCM ??
ASN 0-4 ??
GAB 4 vals ?? 3,-10,50,150
GAN 1 ??
GAR 11 vals ?? 10,10,5,20,35,50,70,90,120,150,180,,
GCM 6 values ??
GFV prints screen gray value?
GIT 200 ??
GTV Get the collected temp values?
PTS echoes but with extra stuff??
QYA 7170 Query Gray Info (information mode)
QYI 7124 Query Gray Average mode
QYM 7512 Query Gray Minimum mode
VTP 400-4000 ??
MTD U/S,0,0 ?? S answers with bytes, U upload bytes?
MTC U/S? ?? S answers with U,0,0, S doesnt.

return 0 invalid params:
STS ??
STT ??
SAC ??
SAH ??
SAS ??
SAT ??
SCX ?? displays crosshair but invalid params
SCY ?? displays crosshair but invalid params
GAC ??
GAH ??
GAS ??
GAT ??
GME ??
GPC ??
GPI ??
GPM ??
GTA ??
GTC ??
GTI ??
GTM ??
GTS ??
GTT ??

answer only:

BPM 0-1 stream ready? answers with 0 stop, 1 go, 2 when prompted
AVS 0,1
MEH
PWI 0-1 changing palette from wh to fire

unconfirmed (from dm60comm.so):
SDT 2024,03,15,14,30,25 Set Date Time with year,month,day,hour,minute,second
STS 1 Set Temperature Show display (0=off, 1=on)
SVA 2 Set Video Auto mode (0=manual, 2=auto)
SMP 0,1,1,0,100,150,200,250,300,350,90,25 Set Measurement Point (type,index,enable,mode,startX,startY,endX,endY,anchorX,anchorY,threshold,color)
STV Stop Temperature View measurements
SPF 5 Set Profile parameter
SVL -10 Set Video Left pan movement (signed value)
SVU -5 Set Video Up tilt movement (signed value)
SVD 5 Set Video Down tilt movement (signed value)
SSP 17,1,0 Set System Parameter (param_id,value,index) #46 temperature format 0 °C, 1 °F, 2 K
SCP Set Current Preset (save current position)
GCP Get Current Preset
STT 300,350 Set Temperature Threshold (low,high values *10)
SDC 1 Set Display Configuration parameter
GCS Get Current Status
GMM Get Memory Map information
GFV Get Frame Value (grayscale data)
GFZ Get Freeze Status
GSI 1 Get System Information (parameter=1)
GSS Get System Status
GSP 21,0 Get System Parameter (param_21=surround temp, value=0)
GTT Get Temperature Threshold range
GTV 1,3,10 Get Temperature Values (enable,type,count)
GNU Get Network Update status (response command)
FRZ Freeze current display frame
LIV Live mode (unfreeze display)
CAL Calibrate system
CCP 3 Call Current Preset (preset number 0-9)
APF 100 Auto Profile setting
MEH Measure Enhancement
BPT Built-in Test
MTC S,0 Measure Temperature Capture (S=start, 0=sequence)
MTG U,0,1024,<data> Measure Temperature Gray data transfer
MTD U,0,1024,<data> Measure Temperature Data transfer
UFP S,0,2048 Update Firmware Prepare (S=start, 0=offset, 2048=size)
UFD S,0,1024 Update Firmware Data transfer
BAB U Buffer operation (U=update)
TTH S,0 Temperature Threshold operation
IPP 192.168.001.102,255.255.255.000,192.168.001.001,192.168.000.001,9989,9998 IP Parameters (IP,netmask,gateway,DNS,port1,port2)
MAC 00:60:A9:10:00:01 MAC Address setting
SNP Set Network Parameters (response command)
QYI Query Gray Info (information mode)
QYA Query Gray Average mode
QYM Query Gray Minimum mode
GAI Get Alarm Info (response command)
YTC <data> Unknown command with data parameter
HTH
LRS
LRD
GAR
DRC
PTS
SCX
SCY
CBT
LRE
CBD
CBS
XXX
GSP
GTT
QYI
QYA
QYM

</syntaxhighlight>

==Secret Menu Overview==
The secret menus Main and System can be openend with the password '''+-MC+-'''

Its structured like this, not all variables have been figured out yet.

The format is Menu: submenu: submenu:

and for menu entries: Name, default value, command, description or messages that pop up.
 <syntaxhighlight lang="vb">
MAIN & SYSTEM PASS: +-MC+-

entries are NAME VALUE COMMAND DESC or if its a folder its just ":"

System:
System:
Gain 255 SCO
Bright 102 IBR
BenDi 100 ?
BenDiContrase 80 ?
DisMode 0 ?
Frequency 48hz (24,25,48,50)
DigitalOut 8-14bit 14bit, BT656(_P), ?, BT601
AutoFocus N ?
Line 1 ?
Ltemp0 11800 ?
LTemp1 11000 ?
HTemp0 9500 ?
HTemp1 8700 ?
DelayTime 0 ?
Enhance 0-1 ?
Enhanced E1 230 ?
FPA_Gain 12pF ? between 4 and 18 at random.
NUCEn N ?

Area:
SE 2 ASN 0-4 "Partition"
INT 200 INT "Points time"
VS 3161 SVS
VF 2800 SVF
Vtemp 1401 VTP
VtempArea Low ?
VtempBase 13500 ?
VtempStep -1 ?
VsStep 8 ?
DeadPixelModel preset / calculate
DP: Cursor to select dead pixels
X 360 position
Y 288 position
AutoBP: 50 Press C to start automatic dotting
Quit? Number of bad pixels 961& "Blind element replacement in progress"
Undo
R2: Save data? blind pixel replacement in progress
Replace Y N = DPI, Y = API
L: Reading parameters
S: Saving parameters

Debug:
Rectify N
DisplayGary N
TE N SDT
AutoE ? ?
AutoVS Y ?
VSGrayH 8000 ?
VSGrayL 7000 ?
Trends 1 ?
Shelter N ?
MotorCon 3 ?
SaveFactoryPara:
LanTyp EN ? LANGUAGE
DisplayMT N ?
Version:
PRJ D843 DLD640 ImLib, MTlib, Soft, Logic

BackDispose:
GammaEN 1 ?
Gain 1 ?
EnhanceEN 0 ?
Hpf_shift 5 ?
Hpf_thrd 5 ?
Enhance 150 ?
Lthrd 50 ?

Monitor:
Opens normal OSD

Alarm Set:
Alarm Switch Y ?
Alarm Mode No ?
Alarm Temperature -1°C ?
Reference Gray Y ?
Alarm Level 1L ?
Alarm Gray 65535 ?
Alarm PointNum 0 ?
Correct Gray 0 ?

Thermometry:
Data Collection 0 SMS
Interval 60 SCP
Ammount 90 SCT
Environment normal ?
Export:
Displays: Exportin normal temperature MTC data
Correction -1 ?
Emissivity 100 SEM
Calibration:
BlackbodyTemp -10 grabs a val from GAB
Save CBS
Cancel CBD
Correction:
BlackbodyTemp -10 Picks from the list GAR
Grayscale 0 SLG
Confirm LRE
Save LRS
Cancel LRD
Ninepoint measurement SMV

Cursor:
Cur N DRC enable cursor
X 320 SRP set cursor position
Y 240 SRP set cursor position

Main:
Auto 2 SAG Auto gain
G 211 SVC
B 10002 SVB
P 1 SWP polarity
Z X ?
Settings:
Image:
FI Y ?
FIValue 0 ? 0-31
Freeze N Freeze image
VE N SMR Vertical flip
HO N SMR Horizontal flip
AutoCali L same as rectify?
O IN internal or external
COM:
Opens UART menu
AvoidburnSwitch OFF enable anti burn in
ProtectedTime 10S duration
AvoidBurn 16383 threshold to trigger antiburn

</syntaxhighlight>

===Automatic Dead Pixels and Flatmap Correction===

It it possible to generate a new flat and dead pixel map automatically within the camera after flashing the cleared-map binary.
 

=====Dead pixels:=====
In the secret menu "System", navigate to Area - DeadPixelModel and set the AutoBP (sensitivity for auto bad pixel finding) to 50 or so. Then press C Button

This can take a while.
[[File:High emissivity peltier black body.jpg|thumb|A Peltier / TEC coated in Candle sood to give it a high emissivity surface. It can be cooled or heated by swapping the polarity. ]]

Afterwards, navigate to S: and press + to save it.
 

=====Flatfield:=====
In the Debug menu navigate to R2 and press +

now place something '''Cold''' infront of the Camera with a high emissivity. (it needs to fill the whole image)

Press '''+''', wait for it to says High temperature.

Place something '''Hot''' infront and press '''+''' again.

Afterwards, save with '''S:''' again.

Flatfield should now be calibrated
 <blockquote>Note: Not all dead pixels are auto detected or get removed. you can manually select them in the Dead pixel editor but its not known yet how to select and correct them.</blockquote>

 

==Using the Thermal module without Webserver==
[[File:Breakoutboard d8x3c dali v1.1.png|alt=|thumb|Breakout board for D8X3C]]
to use it, you need to interface it directly.

The module will put out a Analog video signal (High-Z, need to buffer when connecting it to 75Ohm Video input)

Also a 8 or 14bit or 8-bit BT656 output.

the header exposes the FPGA JTAG and UART aswell as 6 Hardware Keys to Navigate the OSD.

To interface, you need to have a adapter board with a DF12-50DS-0.5V(86) Docking socket.

A open source project can be found here, it includes pin access to:

*FPGA JTAG
*UART 3.3V with pin compatible FT232 socket
*Power 5V over USB-C
*5 Button inputs
*Buffered video output and socket for USB Videograbber
*Digital 14 bit video out header with hsync vsync and clk.
*

the pcb layout has been tested and seems to work.

<blockquote>Very basic fanout of pins to 2.54mm headers with a socket for a Video grabber and FT232 adapter and buttons. by gamerpaddy
https://oshwlab.com/gamerpaddy/d8x3c-backpack-usb</blockquote><blockquote>Professional adapter with integrated Video grabber and USB/UART bridge built in including a FFC connector for pin fanout and buttons. by TOA-HI / Killy.THI

https://github.com/TOA-HI/Dali-Tech-D8X3C-Thermal-Camera-Backpack</blockquote>

==Sending Serial Commands directly over UART==

Sending Serial commands directly over UART to the core requires some additional bytes.

The packet structure is as follows (Strip spaces, commands are allways uppercase and 3 chars)
<STX> <LENGTH1> <LENGTH2> Command, Value, Checksum <ETX>

Pseudocode to craft a command packet may look like this<syntaxhighlight lang="c">
//cmd is allways 3 byte uppercase chars
//values can be multiple comma seperated like 320,240
function make_packet(cmd, values):
payload = cmd + "," + join(values, ",") + ","
bytes = ascii(payload)
length = len(bytes)
checksum = sum(bytes) mod 256
return [0x02, length&0xFF, length>>8] + bytes + [checksum, 0x03]
</syntaxhighlight>

 

==Sensor Pinout==
[[File:Dali DLD384 Sensor pinout basic.png|thumb|basic pinout of a DLD384]]
the pinout of the thermal sensor havent been analyzed much.

besides some supply and Control voltages, 3 clocks and a analog output have been found.

17.5MHz

14.705KHz

50Hz

Dali D8X3N Thermal Camera

2025-09-14T18:17:16Z

Gamerpaddy: added professional pcb adapter

=Dali D8X3N Thermal Camera Reverse Engineering=
 

===Introduction===
The [https://www.dali-irtech.com/productinfo/741567.html Dali D8X3N] Thermal Camera module comes in two versions, a 384x288 and 640x480 resolution, utilizing the [http://www.dali-tech.us/products/dld64017m-uncooled-infrared-fpa-detector-86.html DLD Series] of amorphous-Silicon Microbolometers.

They were mainly used in [http://www.dali-tech.us/products/dm60-w--online-body-temperature-thermal-imaging-camera-55.html Dali DM60-W] or WS-1 Body Temperature screening cameras in conjunction with a Black Body radiator set to 37°C to detect infected individuals at the start of the 2020 Covid Pandemic.
[[File:ICI FM320P Innerts.jpg|thumb|Internals. A TP-Link Switch, HikVision Visible Camera and the D8x3N Network thermal camera module]]
[https://infraredcameras.com/ ICI] rebranded these models as FM 320 P and FM 640 P, and distributed them on the local US market, but as the need for such Cameras exploded, those models were built with what was in stock.

So happens, that some of the FM 320 P Models had a DLD640 640x480 instead of a DLD384 384x288 Microbolometer in them, and just got their Firmware modified.

It also could be, because they have excessive amounts of bad pixels outside the 384x288 area, that they were binned to a lower grade.

Discussions about these Cameras started around 2022 in the [https://www.eevblog.com/forum/thermal-imaging/ici-and-dali-thermal-camera-software/ EEVBlog Forums.] when they started to appear secondhand and affordable.

Originally they were priced around US$ 20... 30.000 by ICI, and a unknown amount by Dali Tech.

The Modules specs according to the manufacturer are:

≤50..60mK@F1，300K，50Hz

17 or 25µm pixel pitch

Hisilicon SoC running Linux to provide Onvif and RTSP streams, analysis and a Web UI

 
[[File:Dali D8X3N Module.jpg|thumb|A real 384x288 model with a DLD384 sensor. notice the Productnumber ]]
ICI FM Cameras are found all over Online secondhand marketplaces for scrap Prices, as they are no longer needed.

But you never know, what are you getting. It could be a real DLD384 or the better DLD640 inside. Its a gamble.
 

======640x480 Imagers======
are labeled 22D843 Nxxxx and have a DLD640 sensor in it, they can be upgraded if they run the 384x288 firmware.

======384x288 Imagers======
are labeled 22D883Nxxxx and have a DLD384 sensor in it, they cannot be upgraded

 

==D8X3N Module closer look==
From now on, i will refer to the Thermal Imaging Module as TIM

On the front there is a 2 Element Germanium Lens of a unknown focal length and aperture.

It can be focus-adjusted when unscrewing the clamp around the housing. It can be focussed from infinity down to 10..20cm with some quality loss.
 The outter diameter of the Lens is 42mm with a 1 1/3 inch thread diameter of undetermined pitch.

Dimensions of the germanium elements are 21mm to 3 and 6mm and 14grams in weight.
[[File:Disassembled Thermal Camera Lens.jpg|thumb|Two element Germanium Lens of unknown focal length and aperture]]

The TIM is composed of 6 Stacked PCB modules, 3 of which are for the Web Server functionality. taking them off will give you the basic configuration of a [https://www.dalithermal.com/productinfo/741568.html Dali D8X3C] TIM<gallery>
File:Dali DLD640 Thermal Image Sensor.jpeg|DLD640 Sensor
File:Dali DLD384 Thermal Imaging Sensor.jpeg|DLD384 Sensor
File:Dali D8X3N Board1 Back.jpeg|Network & GPIO Board Back
File:Dali D8X3N Board1 Front.jpeg|Network & GPIO Board Front
File:Dali D8X3N Glue Board Back.jpeg|Board between Logic and IO Back
File:Dali D8X3N Glue Board Front.jpeg|Board between Logic and IO Front
File:Dali D8X3N SoC Board Back.jpeg|SoC Board back
File:Dali D8X3N SoC Board front.jpeg|SoC board front
File:Dali D8X3N FPGA Board Back.jpeg|FPGA Board of the D8X3C Thermal Imager including a PMIC
File:Dali D8X3N FPGA Board Front.jpeg|FPGA Board Front with Video DAC and SPI Flash
File:Dali D8X3N Sensor Power and ADC Board.jpeg|Sensor control and ADC board
File:Dali D8X3N Thermal Core Debug wiring.jpeg|Debug wiring for sniffing SPI and UART
</gallery>

===User Manual===
including pinout diagram and important data

can be found here https://archive.org/details/dali-d-8-x-3-cuser-manualen-v-1.0-1

==Viewing the Video Stream==
[[File:Onvif Device Manager ODM.png|thumb|ODM streaming the Thermal view]]
when first connecting it to power and Ethernet, the camera will have 192.168.1.102 as a Static ip.

If you are running a 192.168.0.x or .178.x net, you need to change it or add a subnet under windows ipv4 settings.

to view it, you can use VLC and the stream URL
rtsp://admin@admin:<camera ip>/ONVIFMedia
there is /ONVIFMedia /ONVIFMediaM and /ONVIFMediaS for different stream Profiles.

VLC is quite slow and delayed, rather use Onvif Device Manager ODM,

it has no delay and auto-detects cameras in the network.

Be sure to log in as user: admin pass: admin in ODM.

in there, you can also set you camera to DHCP under Network settings.

===Web Interface===
[[File:Dali D8X3N web interface.png|thumb|Since browsers cant display RTSP anymore, open in Edge and select IE Compatibility Mode.]]
the web interface can be accessed by opening the camera IP in a browser

login is:
user: admin pass: admin
You can set Temperature markers and areas, but without using the Black Body calibration source, your readings may be way off or not working.

 

====OSD====
there is a debug-login with
user: super pass: 871897
that lets you send Key commands to the Imager to navigate the OSD.

Setting the OSD to english is accomplished with option #11
[[File:Dali D8X3C OSD.png|thumb|OSD in english, if yours is Chinese. go to option #11 and click + or -]]

To acces some locked menus, press
+ - + - + -

The password for the locked System and Main menu is
+-MC+-

Be careful in the UART menu to not change the BAUD rate or Protocol, as your ability to control it via the Web API gets lost.

You need to reflash or solder buttons on the thermal core then.

==Viewing Raw Thermal Data from the Web API==
there is a hidden endpoint in the stream.so file that could be found while decompiling

accessing
[[File:Arduino Nano blink sketch thermal gif.gif|thumb|Arduino Nano running blink sketch while thermally recording it, notice the led and resistor on the right]]
<ip of camera>:5000/stream?Type=JPEG&Source=Jpeg&Mode=TCP
lets you download a JPEG. but there are more options available (not all have been tested)

we are mainly interessted in Raw thermal data.

====Source (Stream Type)====

*<code>Major</code> - Main video stream (channel 0)
*<code>Minor</code> - Sub video stream (channel 1)
*<code>MinorAV</code> - Sub video + audio stream
*<code>MajorAV</code> - Main video + audio stream
*<code>Jpeg</code> - JPEG snapshot stream
*<code>Raw</code> - Raw thermal data stream
*<code>YUV</code> - YUV raw video stream

====Type (Data Format)====

*<code>H264</code> - H.264 video encoding
*<code>JPEG</code> - JPEG image format
*<code>RAW</code> - Raw sensor data
*<code>QBOX</code> - Custom protocol format
*<code>FRAME</code> - Frame-based format

====Mode (Transport Protocol)====

*<code>TCP</code> - TCP streaming (default)
*<code>UDP</code> - UDP streaming
*<code>MUL</code> - Multicast streaming

====Quality Parameters====

*<code>Quality=[1-100]</code> - Video quality level
*<code>Frames=[number]</code> - Number of frames to send
*<code>Interval=[ms]</code> - Frame interval in milliseconds

====Network Parameters====

*<code>IPAddr=[ip]</code> - Client IP address for UDP/multicast
*<code>Port=[port]</code> - Client port for UDP/multicast
*<code>Heart-beat=[Yes/No]</code> - Enable/disable heartbeat

====Snapshot Parameters====

*<code>Snap=[Yes/No]</code> - Enable snapshot mode

 
====Raw Viewer for PC (Python)====
[[File:Dali D8X3N Raw Thermal viewer.png|thumb|Raw Data Viewer in python]]

To view the raw stream, i made a python program that converts the 14bit thermal data to a visible image.

it is low fps tho, due to bad optimizations.

rev1 first working version https://pastebin.com/dyNWDPT3

rev2 with temperature readout https://pastebin.com/u107Q85w

rev3 and onward will only be available directly as a Webpage on the Device (see below).

====Raw Viewer for the internal Webserver (recommended)====
It is also possible to use the Raw viewer directly in the browser.

To achieve this, the stream had to be proxied from port 5000 to 80 due to CORS.

luckily the internal lighttpd had the CGI module enabled, so piping it troug (using wget ... i know) worked with very low overhead.

To install, you need '''Terminal access''' to the Camera. see below.

optional for simplicity: '''ftp''' access

[[File:Dali D8X3N Webviewer.png|thumb|Web Raw Viewer with histogram (rev3)]]

Create the files and the code inside.

'''/app/web/webpages/raw.html''' https://pastebin.com/kaiXwAgD

and

'''/app/web/webpages/cgi-bin/proxy.cgi''' https://pastebin.com/vii1HXcU

then run
chmod +x /app/web/webpages/cgi-bin/proxy.cgi
'''restart''' your camera.

It should be accessible now trough '''http://<camera ip>/raw.html''' in the browser and click Start Stream

'''NOTE''': ''If it does not work'', check the contents of both files. FTP sometimes messes them up.

also run
dos2unix /app/web/webpages/cgi-bin/proxy.cgi
because linux <> windows difficulties that couldnt be resolved in over 30 years.

<blockquote>

performance may need improvement.</blockquote>

==Getting Root Terminal Access==
To access the Terminal you need to solder or plug in a UART connection to Connector J7 on the "Glue" board.

Pinout is (left to right) '''RX TX GND 3.3V Baud 115200 3.3V!'''

But the system will spam with debug messages, making patching the files a hard job unless you use "tftp" or "sed" commands.
 

====Enabling Telnet access to make patching easier====
[[File:Upgrade ici dali firmware updater.png|thumb|ICI Firmware updater software with modified firmware loaded]]

there is a easier way using a modified Firmware updater to enable Telnet temporarily to patch the Files.

Download the '''upgrade_ici.exe''' form [https://archive.org/details/fwupdate here] and run it.

Then you should be able to connect to it via Telnet.

The Login credentials are '''User: roo'''t '''Password: DLroot'''

 

===Patching Device===

===Patching the Web Server===
 

====Enabling Telnet and ftpd permanently====

This only works if you also patch the Thermal Camera module flash!

to permanently enable Telnet, go to '''/etc/init.d''' and edit '''S90app'''
vi S90app
in vi, move your cursor to the '''#''' at '''#telnetd''' and press x<blockquote>optional: enable ftp by removing the '''#''' at '''ftpd''' and adjust the path to / </blockquote>now press ''':''' and type '''wq''' and hit '''enter'''. this should be it.

====Patching the decoder and streamer to 640x480:====
go to /app and edit the mach.cfg

replace DL384 with D640 and edit the resolution to 640 480

(press i in vi to enter edit mode, press ESC to exit edit mode. :wq to write and quit.)

repeat that procedure for the dali.cfg

=====(optional) patching app.sh to prevent it from rebooting=====
edit the app.sh in /app and remove all "reboot" occasions to prevent the camera from rebooting if onvifserver, httpd or daliServer arent running for debugging purposes.

 

====Patching the Thermal Camera module====
To patch it, you need to disassemble everything down to the FPGA Board,

on the bottom there is a SPI SOIC8 Flash.

Use a CH341 EEPROM programmer (be sure to have a fixed or modified version to not put out 5V!, set it to 3.3V) and SOIC8 clamp.

Use NeoProgrammer (i used 2.2.0.10 but there are newer available, use the latest) and click Detect. It should find W25Q128 chips, select the FV one.

Dont forget to download a backup of your flash and save it !

Download the Binary "Dali 640x480 '''actual''' cleared pixelmap.bin" from #3 below and load it into NeoProgrammer,

Click Erase, Program and Verify.

This can take a while.

Your imager should start up right after assembly by hearing the shutter click.

==Hardware Hacking==

===Flash Contents===
On archive, click on show all files to download them.

<nowiki>#</nowiki>1 a Flash dump of the original downgraded D8X3N can be found [https://archive.org/details/dali-d-843n-flash-dump here]

<nowiki>#</nowiki>2 a Flash dump of a original 640x480 model can be found [https://archive.org/details/d-843-n-640x-480 here]

<nowiki>#</nowiki>3 a modified Flash dump of a 640x480 with cleared dead pixel map, flat map etc. can be found [https://archive.org/details/d-843-n-640x-480-cleared-pixelmap here]

a Flash dump of the web server SPI flash W25Q256JV can be found [https://archive.org/details/dm-60-webserver-flash-dump here] in case a bad firmware update caused a bootloop.

 

===Flash Binary Analysis===
The Flash IC is a Winbond 25Q128JV SPI Flash that contains the FPGA Bitstream, Deadpixel and Flatmap, aswell as the Device Settings.

a copy of the SPI Logic Capture at startup can be found [https://archive.org/details/dali-eeprom-capture here], the free software [https://www.dreamsourcelab.com/download/ DSView from DreamSourceLab] is required to view it.
[[File:Dali Thermal Imager SPI Flash capture.png|thumb|SPI Flash access while booting the Thermal Module]]

a approximation of the offsets resulted in this list:<syntaxhighlight lang="vb">
0x000000 - altera cyclone iv stuff
0x200000 - settings
0x280000 - Flat field correction map
0x4C0000 - Bad Pixel correctio nmap
0x580000 - image aswell? 36010 bytes
0x740000 - GUIX?
0x7C0000 - Strings for Gui?
0x800000 - another shorter GUIX
0x880000 - Strings for second gui?
0x8C0000 - GUIX
0x940000 - Strings for gui
0xE00000 - ?
0xE80000 - dzxg? short
0xEC0000 - crosshair.bmp
0xF40000 - 3DTM?
0xF80000 - fake? Bad pixel map BPRP
</syntaxhighlight> 

====Settings offset 0x200000====
The settings are read and written every startup, aswell when you close the OSD, sporadically and when executing the command MSV

these are some of the settings i could figure out by changing and watching the logic capture what changed.
 <syntaxhighlight lang="vb">
offset size Cmd
0x0 1 SAG (0-2) auto gain
0x2 2 SVB (0-16383) saved value is 16383 - SVB
0x4 2 SVC (0-1023) set exposure or gain
0x6 1 SSM image filtering
0x8 1 SEH image enhancement
0xA 1 SWP invert b/w polarity
0x14 1 SMR Flip
0x16 1 SMR Mirror
0x20 1 MENU Cal source 0 IN, 1 OUT
0x3A 1 MENU Enhance value 0-100
0x40 1 MENU Rectify (shutter 0 OFF, 1 L, 2 H)
0x50 1 MENU Language 0 english, 1 chinese, 2 russian
0xA2 - SCO set contrast gain
0xA4 - IBR set brightness
0xAE 2 MENU Fire Threshold
0xAC 1 SPA set color palette
0xE2 1 SMS display "collected 0/80" enabled
0xF8 1 SEM set emissivity
0x110 1 SRT set revise temp
0x116 1 SHD set humidity
0x118 1 SET set ambient temp
0x11A 1 STD set temp range
0x120 2 SLG -500 to 500?
0x124 2 SRD set distance
0x12C 1 SCP ???
0x130 2 SCT ???
</syntaxhighlight> 
[[File:Dali D8X3N Bad Pixel Map Viewer.png|thumb|Bad pixel map of a 640x512 sensor, about 0.56% of dead pixels in this map]]
So i let the AI create a [https://2476424.playcode.io/ Configurator page] that lets you change the Settings in your Flashdump to your liking
 

====Bad Pixel and Flatframe Maps 0x280000 and 0x4C0000====
Thermal cameras require a bad pixel and flat frame map to compensate for manufacturing inconsistencies.

unfourtainly, the maps of the downgraded cameras only contain enough data for a 384 model, not the full 640.

at offset 0xF80000 there is a BPRP which was mistaken at first as the Bad pixel map, it could just be a mask to where to apply the offset maps, as its either 0x0 or 0x1.

The [https://2477569.playcode.io/ Viewer Page] is written in JS and does not require any special dependencies, it can run as a plain html file offline.

''See "Automatic Dead Pixels and Flatmap Correction" below how to create new dead pixel and flatmaps using the system menu.''

[[File:Dali D8X3N Flat Field Map Viewer.png|thumb|Flat Field viewer]]

==Dali Commands==
To control the TIM you can either use Pelco or Dali command set. By default the Dali commandset is used at 38400 BAUD.

Those commands consist of a 0x02 start byte followed by two length Bytes, then the actual command which is allways 3 uppercase Letters in ASCII (eg. KBD for keyboard) followed by a comma and the values.

Some commands take multiple values, some dont. But you allways have to send the comma after the Command.

The camera will answer with the Command and 0, 1 or 2. Sending no value counts as zero.
0 is invalid parameters, too few or out of range

1 is OK, valid command

2 is Invalid command

Commands can be sent trough the Web server using the URL Api endpoint or directly trough the UART port.

(keyboard, C button, causes the shutter to do a calibration)
<camera ip>/cgi-bin/dmcmd?Command=KBD,C
Listening to the answer can be done while being in the Linux shell and typing
cat /dev/ttyAMA2 | strings

By bruteforcing the UART with AAA to ZZZ a list of Commands could be obtained, but some with unknown Parameters or functionality yet. including some from a decompiled DM60comm.so module found in /app/modules folder.<syntaxhighlight lang="vb">
KBD KEY Keyboard (F S M C + -)
SSM 0-1 Image Filtering Off/On
GSM 0 Image filter status
SEH 0-1 Image Enhancement Off/On
GEH 0-1 Image enhancer status
SCO 0-255 Set Gain (locked when SAG auto gain is on)
GCO 0-255 Get gain
INT 15-320 set actual gain? not just contrast sometimes disabled?
IBR 0-255 Set brightness
GBR 0-255 Get brightness
SMR 0-3 Mirror mode bit0=horizontal, bit1=vertical
GMR 0 Get rotation/flip
SDT 0-1 displays temp=44.65°C osd, but webserver sends date/time to the cam there....
GDT 0-1 Get temp display active?
GPT Display temp oft SDT
GNU 0-1 Get Shutter closed/open
SNU 0-1 Shutter close / open
STD 0-1 Set Range 0: -20-180°C 1: 100-600°C
GTD 0-1 Get Range
SET °C Set Ambient temperature
GET °C Get Ambient temperature
SEM 0-100 0-1 set emissivity x100
GEM 0-100 Get Emissivity
SRT °C Set revise temperature -100-100 -10-10°
GRT °C Get revise temperature
SRD 100 Set Distance 4.4m x100
GRD 100 Get Distance
SHD 0-100 Set Humidity
GHD 55 Get Humidity
SWP 0-1 invert s/w polarity image
GWP 1 is inverted?
SPA 0-10? Set color palette
GPA 3 white hot
SMV 0-1 Show temperature 3x3 grid?? in combination with GTV maybe
GMV 0
SMS 0-1 displays "collected 0/<number set by SCT>" by SCP delay "saves the daily number of highest temperatures?"
GMS 0
SCT 1-500 sets the amount of "collected" points for SMS
GCT 80
SCP 5-60 "collected" delay in seconds for SMS
GCP 60
SAG 0-2 Auto brightness / gain
GAG 0
SLR 0-9 ???
GLR 0
SRP 0,0 - 639,479 set crosshair position
GRP 320,240 get crosshair position
DRC 0-1 Show crosshair
SLG -500-500 ??
GLG
SCE text ??
GCE 0
SCB text ??
GCB 0
SVB 0-16383 adc offset, exposure? good at 9650
GVB 6733 value is 16383 minus SVB
SVC 1-1023 set contrast but better
GVC 260
SVF 100-? ?? video freaks out 3400 seems good
SVS 100-? ?? video freaks out 3300 seems good
SOT 0-1 ?? sensor supply, looks weird when off.
SZM 1-4 ?
GZM 1
MSV save settings too eeprom
ASV Saves something aswell?
GCS 0 Get Core status & faults
ALD 0,2? video blanks lots of eeprom activity. reload pixel map??
SAV 0-9999 set Fire threshold
GAV 2100 get Fire Threshold
BAC change uart protocol? careful
CBD Displays Recovery successful?
CBS Displays Saved successfully
LRD Displays Recovery successful?
LRS Displays Saved successfully?
LRE Displays Temperature Repair successful?
CBT Displays Calibration successful?
DBP ??? shutter clicks
DPI Show weird pixels
API Hide weird pixels
CCM ??
ASN 0-4 ??
GAB 4 vals ?? 3,-10,50,150
GAN 1 ??
GAR 11 vals ?? 10,10,5,20,35,50,70,90,120,150,180,,
GCM 6 values ??
GFV prints screen gray value?
GIT 200 ??
GTV Get the collected temp values?
PTS echoes but with extra stuff??
QYA 7170 Query Gray Info (information mode)
QYI 7124 Query Gray Average mode
QYM 7512 Query Gray Minimum mode
VTP 400-4000 ??
MTD U/S,0,0 ?? S answers with bytes, U upload bytes?
MTC U/S? ?? S answers with U,0,0, S doesnt.

return 0 invalid params:
STS ??
STT ??
SAC ??
SAH ??
SAS ??
SAT ??
SCX ?? displays crosshair but invalid params
SCY ?? displays crosshair but invalid params
GAC ??
GAH ??
GAS ??
GAT ??
GME ??
GPC ??
GPI ??
GPM ??
GTA ??
GTC ??
GTI ??
GTM ??
GTS ??
GTT ??

answer only:

BPM 0-1 stream ready? answers with 0 stop, 1 go, 2 when prompted
AVS 0,1
MEH
PWI 0-1 changing palette from wh to fire

unconfirmed (from dm60comm.so):
SDT 2024,03,15,14,30,25 Set Date Time with year,month,day,hour,minute,second
STS 1 Set Temperature Show display (0=off, 1=on)
SVA 2 Set Video Auto mode (0=manual, 2=auto)
SMP 0,1,1,0,100,150,200,250,300,350,90,25 Set Measurement Point (type,index,enable,mode,startX,startY,endX,endY,anchorX,anchorY,threshold,color)
STV Stop Temperature View measurements
SPF 5 Set Profile parameter
SVL -10 Set Video Left pan movement (signed value)
SVU -5 Set Video Up tilt movement (signed value)
SVD 5 Set Video Down tilt movement (signed value)
SSP 17,1,0 Set System Parameter (param_id,value,index) #46 temperature format 0 °C, 1 °F, 2 K
SCP Set Current Preset (save current position)
GCP Get Current Preset
STT 300,350 Set Temperature Threshold (low,high values *10)
SDC 1 Set Display Configuration parameter
GCS Get Current Status
GMM Get Memory Map information
GFV Get Frame Value (grayscale data)
GFZ Get Freeze Status
GSI 1 Get System Information (parameter=1)
GSS Get System Status
GSP 21,0 Get System Parameter (param_21=surround temp, value=0)
GTT Get Temperature Threshold range
GTV 1,3,10 Get Temperature Values (enable,type,count)
GNU Get Network Update status (response command)
FRZ Freeze current display frame
LIV Live mode (unfreeze display)
CAL Calibrate system
CCP 3 Call Current Preset (preset number 0-9)
APF 100 Auto Profile setting
MEH Measure Enhancement
BPT Built-in Test
MTC S,0 Measure Temperature Capture (S=start, 0=sequence)
MTG U,0,1024,<data> Measure Temperature Gray data transfer
MTD U,0,1024,<data> Measure Temperature Data transfer
UFP S,0,2048 Update Firmware Prepare (S=start, 0=offset, 2048=size)
UFD S,0,1024 Update Firmware Data transfer
BAB U Buffer operation (U=update)
TTH S,0 Temperature Threshold operation
IPP 192.168.001.102,255.255.255.000,192.168.001.001,192.168.000.001,9989,9998 IP Parameters (IP,netmask,gateway,DNS,port1,port2)
MAC 00:60:A9:10:00:01 MAC Address setting
SNP Set Network Parameters (response command)
QYI Query Gray Info (information mode)
QYA Query Gray Average mode
QYM Query Gray Minimum mode
GAI Get Alarm Info (response command)
YTC <data> Unknown command with data parameter
HTH
LRS
LRD
GAR
DRC
PTS
SCX
SCY
CBT
LRE
CBD
CBS
XXX
GSP
GTT
QYI
QYA
QYM

</syntaxhighlight>

==Secret Menu Overview==
The secret menus Main and System can be openend with the password '''+-MC+-'''

Its structured like this, not all variables have been figured out yet.

The format is Menu: submenu: submenu:

and for menu entries: Name, default value, command, description or messages that pop up.
 <syntaxhighlight lang="vb">
MAIN & SYSTEM PASS: +-MC+-

entries are NAME VALUE COMMAND DESC or if its a folder its just ":"

System:
System:
Gain 255 SCO
Bright 102 IBR
BenDi 100 ?
BenDiContrase 80 ?
DisMode 0 ?
Frequency 48hz (24,25,48,50)
DigitalOut 8-14bit 14bit, BT656(_P), ?, BT601
AutoFocus N ?
Line 1 ?
Ltemp0 11800 ?
LTemp1 11000 ?
HTemp0 9500 ?
HTemp1 8700 ?
DelayTime 0 ?
Enhance 0-1 ?
Enhanced E1 230 ?
FPA_Gain 12pF ? between 4 and 18 at random.
NUCEn N ?

Area:
SE 2 ASN 0-4 "Partition"
INT 200 INT "Points time"
VS 3161 SVS
VF 2800 SVF
Vtemp 1401 VTP
VtempArea Low ?
VtempBase 13500 ?
VtempStep -1 ?
VsStep 8 ?
DeadPixelModel preset / calculate
DP: Cursor to select dead pixels
X 360 position
Y 288 position
AutoBP: 50 Press C to start automatic dotting
Quit? Number of bad pixels 961& "Blind element replacement in progress"
Undo
R2: Save data? blind pixel replacement in progress
Replace Y N = DPI, Y = API
L: Reading parameters
S: Saving parameters

Debug:
Rectify N
DisplayGary N
TE N SDT
AutoE ? ?
AutoVS Y ?
VSGrayH 8000 ?
VSGrayL 7000 ?
Trends 1 ?
Shelter N ?
MotorCon 3 ?
SaveFactoryPara:
LanTyp EN ? LANGUAGE
DisplayMT N ?
Version:
PRJ D843 DLD640 ImLib, MTlib, Soft, Logic

BackDispose:
GammaEN 1 ?
Gain 1 ?
EnhanceEN 0 ?
Hpf_shift 5 ?
Hpf_thrd 5 ?
Enhance 150 ?
Lthrd 50 ?

Monitor:
Opens normal OSD

Alarm Set:
Alarm Switch Y ?
Alarm Mode No ?
Alarm Temperature -1°C ?
Reference Gray Y ?
Alarm Level 1L ?
Alarm Gray 65535 ?
Alarm PointNum 0 ?
Correct Gray 0 ?

Thermometry:
Data Collection 0 SMS
Interval 60 SCP
Ammount 90 SCT
Environment normal ?
Export:
Displays: Exportin normal temperature MTC data
Correction -1 ?
Emissivity 100 SEM
Calibration:
BlackbodyTemp -10 grabs a val from GAB
Save CBS
Cancel CBD
Correction:
BlackbodyTemp -10 Picks from the list GAR
Grayscale 0 SLG
Confirm LRE
Save LRS
Cancel LRD
Ninepoint measurement SMV

Cursor:
Cur N DRC enable cursor
X 320 SRP set cursor position
Y 240 SRP set cursor position

Main:
Auto 2 SAG Auto gain
G 211 SVC
B 10002 SVB
P 1 SWP polarity
Z X ?
Settings:
Image:
FI Y ?
FIValue 0 ? 0-31
Freeze N Freeze image
VE N SMR Vertical flip
HO N SMR Horizontal flip
AutoCali L same as rectify?
O IN internal or external
COM:
Opens UART menu
AvoidburnSwitch OFF enable anti burn in
ProtectedTime 10S duration
AvoidBurn 16383 threshold to trigger antiburn

</syntaxhighlight>

===Automatic Dead Pixels and Flatmap Correction===

It it possible to generate a new flat and dead pixel map automatically within the camera after flashing the cleared-map binary.
 

=====Dead pixels:=====
In the secret menu "System", navigate to Area - DeadPixelModel and set the AutoBP (sensitivity for auto bad pixel finding) to 50 or so. Then press C Button

This can take a while.
[[File:High emissivity peltier black body.jpg|thumb|A Peltier / TEC coated in Candle sood to give it a high emissivity surface. It can be cooled or heated by swapping the polarity. ]]

Afterwards, navigate to S: and press + to save it.
 

=====Flatfield:=====
In the Debug menu navigate to R2 and press +

now place something '''Cold''' infront of the Camera with a high emissivity. (it needs to fill the whole image)

Press '''+''', wait for it to says High temperature.

Place something '''Hot''' infront and press '''+''' again.

Afterwards, save with '''S:''' again.

Flatfield should now be calibrated
 <blockquote>Note: Not all dead pixels are auto detected or get removed. you can manually select them in the Dead pixel editor but its not known yet how to select and correct them.</blockquote>

 

==Using the Thermal module without Webserver==
[[File:Breakoutboard d8x3c dali v1.1.png|alt=|thumb|Breakout board for D8X3C]]
to use it, you need to interface it directly.

The module will put out a Analog video signal (High-Z, need to buffer when connecting it to 75Ohm Video input)

Also a 8 or 14bit or 8-bit BT656 output.

the header exposes the FPGA JTAG and UART aswell as 6 Hardware Keys to Navigate the OSD.

To interface, you need to have a adapter board with a DF12-50DS-0.5V(86) Docking socket.

A open source project can be found here, it includes pin access to:

*FPGA JTAG
*UART 3.3V with pin compatible FT232 socket
*Power 5V over USB-C
*5 Button inputs
*Buffered video output and socket for USB Videograbber
*Digital 14 bit video out header with hsync vsync and clk.
*

the pcb layout has been tested and seems to work.

<blockquote>Very basic fanout of pins to 2.54mm headers with a socket for a Video grabber and FT232 adapter and buttons. by gamerpaddy
https://oshwlab.com/gamerpaddy/d8x3c-backpack-usb</blockquote><blockquote>Professional adapter with integrated Video grabber and USB/UART bridge built in including a FFC connector for pin fanout and buttons. by TOA-HI / Killy.THI

https://github.com/TOA-HI/Dali-Tech-D8X3C-Thermal-Camera-Backpack</blockquote>

==Sending Serial Commands directly over UART==

Sending Serial commands directly over UART to the core requires some additional bytes.

The packet structure is as follows (Strip spaces, commands are allways uppercase and 3 chars)
<STX> <LENGTH1> <LENGTH2> Command, Value, Checksum <ETX>

Pseudocode to craft a command packet may look like this<syntaxhighlight lang="c">
//cmd is allways 3 byte uppercase chars
//values can be multiple comma seperated like 320,240
function make_packet(cmd, values):
payload = cmd + "," + join(values, ",") + ","
bytes = ascii(payload)
length = len(bytes)
checksum = sum(bytes) mod 256
return [0x02, length&0xFF, length>>8] + bytes + [checksum, 0x03]
</syntaxhighlight>

 

==Sensor Pinout==
[[File:Dali DLD384 Sensor pinout basic.png|thumb|basic pinout of a DLD384]]
the pinout of the thermal sensor havent been analyzes much.

besides some supply and Control voltages, 3 clocks and a analog output have been found.

17.5MHz

14.705KHz

50Hz

Dali D8X3N Thermal Camera

2025-08-29T13:08:46Z

Gamerpaddy: /* Using the Thermal module without Webserver */

=Dali D8X3N Thermal Camera Reverse Engineering=
 

===Introduction===
The [https://www.dali-irtech.com/productinfo/741567.html Dali D8X3N] Thermal Camera module comes in two versions, a 384x288 and 640x480 resolution, utilizing the [http://www.dali-tech.us/products/dld64017m-uncooled-infrared-fpa-detector-86.html DLD Series] of amorphous-Silicon Microbolometers.

They were mainly used in [http://www.dali-tech.us/products/dm60-w--online-body-temperature-thermal-imaging-camera-55.html Dali DM60-W] or WS-1 Body Temperature screening cameras in conjunction with a Black Body radiator set to 37°C to detect infected individuals at the start of the 2020 Covid Pandemic.
[[File:ICI FM320P Innerts.jpg|thumb|Internals. A TP-Link Switch, HikVision Visible Camera and the D8x3N Network thermal camera module]]
[https://infraredcameras.com/ ICI] rebranded these models as FM 320 P and FM 640 P, and distributed them on the local US market, but as the need for such Cameras exploded, those models were built with what was in stock.

So happens, that some of the FM 320 P Models had a DLD640 640x480 instead of a DLD384 384x288 Microbolometer in them, and just got their Firmware modified.

It also could be, because they have excessive amounts of bad pixels outside the 384x288 area, that they were binned to a lower grade.

Discussions about these Cameras started around 2022 in the [https://www.eevblog.com/forum/thermal-imaging/ici-and-dali-thermal-camera-software/ EEVBlog Forums.] when they started to appear secondhand and affordable.

Originally they were priced around US$ 20... 30.000 by ICI, and a unknown amount by Dali Tech.

The Modules specs according to the manufacturer are:

≤50..60mK@F1，300K，50Hz

17 or 25µm pixel pitch

Hisilicon SoC running Linux to provide Onvif and RTSP streams, analysis and a Web UI

 
[[File:Dali D8X3N Module.jpg|thumb|A real 384x288 model with a DLD384 sensor. notice the Productnumber ]]
ICI FM Cameras are found all over Online secondhand marketplaces for scrap Prices, as they are no longer needed.

But you never know, what are you getting. It could be a real DLD384 or the better DLD640 inside. Its a gamble.
 

======640x480 Imagers======
are labeled 22D843 Nxxxx and have a DLD640 sensor in it, they can be upgraded if they run the 384x288 firmware.

======384x288 Imagers======
are labeled 22D883Nxxxx and have a DLD384 sensor in it, they cannot be upgraded

 

==D8X3N Module closer look==
From now on, i will refer to the Thermal Imaging Module as TIM

On the front there is a 2 Element Germanium Lens of a unknown focal length and aperture.

It can be focus-adjusted when unscrewing the clamp around the housing. It can be focussed from infinity down to 10..20cm with some quality loss.
 The outter diameter of the Lens is 42mm with a 1 1/3 inch thread diameter of undetermined pitch.

Dimensions of the germanium elements are 21mm to 3 and 6mm and 14grams in weight.
[[File:Disassembled Thermal Camera Lens.jpg|thumb|Two element Germanium Lens of unknown focal length and aperture]]

The TIM is composed of 6 Stacked PCB modules, 3 of which are for the Web Server functionality. taking them off will give you the basic configuration of a [https://www.dalithermal.com/productinfo/741568.html Dali D8X3C] TIM<gallery>
File:Dali DLD640 Thermal Image Sensor.jpeg|DLD640 Sensor
File:Dali DLD384 Thermal Imaging Sensor.jpeg|DLD384 Sensor
File:Dali D8X3N Board1 Back.jpeg|Network & GPIO Board Back
File:Dali D8X3N Board1 Front.jpeg|Network & GPIO Board Front
File:Dali D8X3N Glue Board Back.jpeg|Board between Logic and IO Back
File:Dali D8X3N Glue Board Front.jpeg|Board between Logic and IO Front
File:Dali D8X3N SoC Board Back.jpeg|SoC Board back
File:Dali D8X3N SoC Board front.jpeg|SoC board front
File:Dali D8X3N FPGA Board Back.jpeg|FPGA Board of the D8X3C Thermal Imager including a PMIC
File:Dali D8X3N FPGA Board Front.jpeg|FPGA Board Front with Video DAC and SPI Flash
File:Dali D8X3N Sensor Power and ADC Board.jpeg|Sensor control and ADC board
File:Dali D8X3N Thermal Core Debug wiring.jpeg|Debug wiring for sniffing SPI and UART
</gallery>

===User Manual===
including pinout diagram and important data

can be found here https://archive.org/details/dali-d-8-x-3-cuser-manualen-v-1.0-1

==Viewing the Video Stream==
[[File:Onvif Device Manager ODM.png|thumb|ODM streaming the Thermal view]]
when first connecting it to power and Ethernet, the camera will have 192.168.1.102 as a Static ip.

If you are running a 192.168.0.x or .178.x net, you need to change it or add a subnet under windows ipv4 settings.

to view it, you can use VLC and the stream URL
rtsp://admin@admin:<camera ip>/ONVIFMedia
there is /ONVIFMedia /ONVIFMediaM and /ONVIFMediaS for different stream Profiles.

VLC is quite slow and delayed, rather use Onvif Device Manager ODM,

it has no delay and auto-detects cameras in the network.

Be sure to log in as user: admin pass: admin in ODM.

in there, you can also set you camera to DHCP under Network settings.

===Web Interface===
[[File:Dali D8X3N web interface.png|thumb|Since browsers cant display RTSP anymore, open in Edge and select IE Compatibility Mode.]]
the web interface can be accessed by opening the camera IP in a browser

login is:
user: admin pass: admin
You can set Temperature markers and areas, but without using the Black Body calibration source, your readings may be way off or not working.

 

====OSD====
there is a debug-login with
user: super pass: 871897
that lets you send Key commands to the Imager to navigate the OSD.

Setting the OSD to english is accomplished with option #11
[[File:Dali D8X3C OSD.png|thumb|OSD in english, if yours is Chinese. go to option #11 and click + or -]]

To acces some locked menus, press
+ - + - + -

The password for the locked System and Main menu is
+-MC+-

Be careful in the UART menu to not change the BAUD rate or Protocol, as your ability to control it via the Web API gets lost.

You need to reflash or solder buttons on the thermal core then.

==Viewing Raw Thermal Data from the Web API==
there is a hidden endpoint in the stream.so file that could be found while decompiling

accessing
[[File:Arduino Nano blink sketch thermal gif.gif|thumb|Arduino Nano running blink sketch while thermally recording it, notice the led and resistor on the right]]
<ip of camera>:5000/stream?Type=JPEG&Source=Jpeg&Mode=TCP
lets you download a JPEG. but there are more options available (not all have been tested)

we are mainly interessted in Raw thermal data.

====Source (Stream Type)====

*<code>Major</code> - Main video stream (channel 0)
*<code>Minor</code> - Sub video stream (channel 1)
*<code>MinorAV</code> - Sub video + audio stream
*<code>MajorAV</code> - Main video + audio stream
*<code>Jpeg</code> - JPEG snapshot stream
*<code>Raw</code> - Raw thermal data stream
*<code>YUV</code> - YUV raw video stream

====Type (Data Format)====

*<code>H264</code> - H.264 video encoding
*<code>JPEG</code> - JPEG image format
*<code>RAW</code> - Raw sensor data
*<code>QBOX</code> - Custom protocol format
*<code>FRAME</code> - Frame-based format

====Mode (Transport Protocol)====

*<code>TCP</code> - TCP streaming (default)
*<code>UDP</code> - UDP streaming
*<code>MUL</code> - Multicast streaming

====Quality Parameters====

*<code>Quality=[1-100]</code> - Video quality level
*<code>Frames=[number]</code> - Number of frames to send
*<code>Interval=[ms]</code> - Frame interval in milliseconds

====Network Parameters====

*<code>IPAddr=[ip]</code> - Client IP address for UDP/multicast
*<code>Port=[port]</code> - Client port for UDP/multicast
*<code>Heart-beat=[Yes/No]</code> - Enable/disable heartbeat

====Snapshot Parameters====

*<code>Snap=[Yes/No]</code> - Enable snapshot mode

 
====Raw Viewer for PC (Python)====
[[File:Dali D8X3N Raw Thermal viewer.png|thumb|Raw Data Viewer in python]]

To view the raw stream, i made a python program that converts the 14bit thermal data to a visible image.

it is low fps tho, due to bad optimizations.

rev1 first working version https://pastebin.com/dyNWDPT3

rev2 with temperature readout https://pastebin.com/u107Q85w

rev3 and onward will only be available directly as a Webpage on the Device (see below).

====Raw Viewer for the internal Webserver (recommended)====
It is also possible to use the Raw viewer directly in the browser.

To achieve this, the stream had to be proxied from port 5000 to 80 due to CORS.

luckily the internal lighttpd had the CGI module enabled, so piping it troug (using wget ... i know) worked with very low overhead.

To install, you need '''Terminal access''' to the Camera. see below.

optional for simplicity: '''ftp''' access

[[File:Dali D8X3N Webviewer.png|thumb|Web Raw Viewer with histogram (rev3)]]

Create the files and the code inside.

'''/app/web/webpages/raw.html''' https://pastebin.com/kaiXwAgD

and

'''/app/web/webpages/cgi-bin/proxy.cgi''' https://pastebin.com/vii1HXcU

then run
chmod +x /app/web/webpages/cgi-bin/proxy.cgi
'''restart''' your camera.

It should be accessible now trough '''http://<camera ip>/raw.html''' in the browser and click Start Stream

'''NOTE''': ''If it does not work'', check the contents of both files. FTP sometimes messes them up.

also run
dos2unix /app/web/webpages/cgi-bin/proxy.cgi
because linux <> windows difficulties that couldnt be resolved in over 30 years.

<blockquote>

performance may need improvement.</blockquote>

==Getting Root Terminal Access==
To access the Terminal you need to solder or plug in a UART connection to Connector J7 on the "Glue" board.

Pinout is (left to right) '''RX TX GND 3.3V Baud 115200 3.3V!'''

But the system will spam with debug messages, making patching the files a hard job unless you use "tftp" or "sed" commands.
 

====Enabling Telnet access to make patching easier====
[[File:Upgrade ici dali firmware updater.png|thumb|ICI Firmware updater software with modified firmware loaded]]

there is a easier way using a modified Firmware updater to enable Telnet temporarily to patch the Files.

Download the '''upgrade_ici.exe''' form [https://archive.org/details/fwupdate here] and run it.

Then you should be able to connect to it via Telnet.

The Login credentials are '''User: roo'''t '''Password: DLroot'''

 

===Patching Device===

===Patching the Web Server===
 

====Enabling Telnet and ftpd permanently====

This only works if you also patch the Thermal Camera module flash!

to permanently enable Telnet, go to '''/etc/init.d''' and edit '''S90app'''
vi S90app
in vi, move your cursor to the '''#''' at '''#telnetd''' and press x<blockquote>optional: enable ftp by removing the '''#''' at '''ftpd''' and adjust the path to / </blockquote>now press ''':''' and type '''wq''' and hit '''enter'''. this should be it.

====Patching the decoder and streamer to 640x480:====
go to /app and edit the mach.cfg

replace DL384 with D640 and edit the resolution to 640 480

(press i in vi to enter edit mode, press ESC to exit edit mode. :wq to write and quit.)

repeat that procedure for the dali.cfg

=====(optional) patching app.sh to prevent it from rebooting=====
edit the app.sh in /app and remove all "reboot" occasions to prevent the camera from rebooting if onvifserver, httpd or daliServer arent running for debugging purposes.

 

====Patching the Thermal Camera module====
To patch it, you need to disassemble everything down to the FPGA Board,

on the bottom there is a SPI SOIC8 Flash.

Use a CH341 EEPROM programmer (be sure to have a fixed or modified version to not put out 5V!, set it to 3.3V) and SOIC8 clamp.

Use NeoProgrammer (i used 2.2.0.10 but there are newer available, use the latest) and click Detect. It should find W25Q128 chips, select the FV one.

Dont forget to download a backup of your flash and save it !

Download the Binary "Dali 640x480 '''actual''' cleared pixelmap.bin" from #3 below and load it into NeoProgrammer,

Click Erase, Program and Verify.

This can take a while.

Your imager should start up right after assembly by hearing the shutter click.

==Hardware Hacking==

===Flash Contents===
On archive, click on show all files to download them.

<nowiki>#</nowiki>1 a Flash dump of the original downgraded D8X3N can be found [https://archive.org/details/dali-d-843n-flash-dump here]

<nowiki>#</nowiki>2 a Flash dump of a original 640x480 model can be found [https://archive.org/details/d-843-n-640x-480 here]

<nowiki>#</nowiki>3 a modified Flash dump of a 640x480 with cleared dead pixel map, flat map etc. can be found [https://archive.org/details/d-843-n-640x-480-cleared-pixelmap here]

a Flash dump of the web server SPI flash W25Q256JV can be found [https://archive.org/details/dm-60-webserver-flash-dump here] in case a bad firmware update caused a bootloop.

 

===Flash Binary Analysis===
The Flash IC is a Winbond 25Q128JV SPI Flash that contains the FPGA Bitstream, Deadpixel and Flatmap, aswell as the Device Settings.

a copy of the SPI Logic Capture at startup can be found [https://archive.org/details/dali-eeprom-capture here], the free software [https://www.dreamsourcelab.com/download/ DSView from DreamSourceLab] is required to view it.
[[File:Dali Thermal Imager SPI Flash capture.png|thumb|SPI Flash access while booting the Thermal Module]]

a approximation of the offsets resulted in this list:<syntaxhighlight lang="vb">
0x000000 - altera cyclone iv stuff
0x200000 - settings
0x280000 - Flat field correction map
0x4C0000 - Bad Pixel correctio nmap
0x580000 - image aswell? 36010 bytes
0x740000 - GUIX?
0x7C0000 - Strings for Gui?
0x800000 - another shorter GUIX
0x880000 - Strings for second gui?
0x8C0000 - GUIX
0x940000 - Strings for gui
0xE00000 - ?
0xE80000 - dzxg? short
0xEC0000 - crosshair.bmp
0xF40000 - 3DTM?
0xF80000 - fake? Bad pixel map BPRP
</syntaxhighlight> 

====Settings offset 0x200000====
The settings are read and written every startup, aswell when you close the OSD, sporadically and when executing the command MSV

these are some of the settings i could figure out by changing and watching the logic capture what changed.
 <syntaxhighlight lang="vb">
offset size Cmd
0x0 1 SAG (0-2) auto gain
0x2 2 SVB (0-16383) saved value is 16383 - SVB
0x4 2 SVC (0-1023) set exposure or gain
0x6 1 SSM image filtering
0x8 1 SEH image enhancement
0xA 1 SWP invert b/w polarity
0x14 1 SMR Flip
0x16 1 SMR Mirror
0x20 1 MENU Cal source 0 IN, 1 OUT
0x3A 1 MENU Enhance value 0-100
0x40 1 MENU Rectify (shutter 0 OFF, 1 L, 2 H)
0x50 1 MENU Language 0 english, 1 chinese, 2 russian
0xA2 - SCO set contrast gain
0xA4 - IBR set brightness
0xAE 2 MENU Fire Threshold
0xAC 1 SPA set color palette
0xE2 1 SMS display "collected 0/80" enabled
0xF8 1 SEM set emissivity
0x110 1 SRT set revise temp
0x116 1 SHD set humidity
0x118 1 SET set ambient temp
0x11A 1 STD set temp range
0x120 2 SLG -500 to 500?
0x124 2 SRD set distance
0x12C 1 SCP ???
0x130 2 SCT ???
</syntaxhighlight> 
[[File:Dali D8X3N Bad Pixel Map Viewer.png|thumb|Bad pixel map of a 640x512 sensor, about 0.56% of dead pixels in this map]]
So i let the AI create a [https://2476424.playcode.io/ Configurator page] that lets you change the Settings in your Flashdump to your liking
 

====Bad Pixel and Flatframe Maps 0x280000 and 0x4C0000====
Thermal cameras require a bad pixel and flat frame map to compensate for manufacturing inconsistencies.

unfourtainly, the maps of the downgraded cameras only contain enough data for a 384 model, not the full 640.

at offset 0xF80000 there is a BPRP which was mistaken at first as the Bad pixel map, it could just be a mask to where to apply the offset maps, as its either 0x0 or 0x1.

The [https://2477569.playcode.io/ Viewer Page] is written in JS and does not require any special dependencies, it can run as a plain html file offline.

''See "Automatic Dead Pixels and Flatmap Correction" below how to create new dead pixel and flatmaps using the system menu.''

[[File:Dali D8X3N Flat Field Map Viewer.png|thumb|Flat Field viewer]]

==Dali Commands==
To control the TIM you can either use Pelco or Dali command set. By default the Dali commandset is used at 38400 BAUD.

Those commands consist of a 0x02 start byte followed by two length Bytes, then the actual command which is allways 3 uppercase Letters in ASCII (eg. KBD for keyboard) followed by a comma and the values.

Some commands take multiple values, some dont. But you allways have to send the comma after the Command.

The camera will answer with the Command and 0, 1 or 2. Sending no value counts as zero.
0 is invalid parameters, too few or out of range

1 is OK, valid command

2 is Invalid command

Commands can be sent trough the Web server using the URL Api endpoint or directly trough the UART port.

(keyboard, C button, causes the shutter to do a calibration)
<camera ip>/cgi-bin/dmcmd?Command=KBD,C
Listening to the answer can be done while being in the Linux shell and typing
cat /dev/ttyAMA2 | strings

By bruteforcing the UART with AAA to ZZZ a list of Commands could be obtained, but some with unknown Parameters or functionality yet. including some from a decompiled DM60comm.so module found in /app/modules folder.<syntaxhighlight lang="vb">
KBD KEY Keyboard (F S M C + -)
SSM 0-1 Image Filtering Off/On
GSM 0 Image filter status
SEH 0-1 Image Enhancement Off/On
GEH 0-1 Image enhancer status
SCO 0-255 Set Gain (locked when SAG auto gain is on)
GCO 0-255 Get gain
INT 15-320 set actual gain? not just contrast sometimes disabled?
IBR 0-255 Set brightness
GBR 0-255 Get brightness
SMR 0-3 Mirror mode bit0=horizontal, bit1=vertical
GMR 0 Get rotation/flip
SDT 0-1 displays temp=44.65°C osd, but webserver sends date/time to the cam there....
GDT 0-1 Get temp display active?
GPT Display temp oft SDT
GNU 0-1 Get Shutter closed/open
SNU 0-1 Shutter close / open
STD 0-1 Set Range 0: -20-180°C 1: 100-600°C
GTD 0-1 Get Range
SET °C Set Ambient temperature
GET °C Get Ambient temperature
SEM 0-100 0-1 set emissivity x100
GEM 0-100 Get Emissivity
SRT °C Set revise temperature -100-100 -10-10°
GRT °C Get revise temperature
SRD 100 Set Distance 4.4m x100
GRD 100 Get Distance
SHD 0-100 Set Humidity
GHD 55 Get Humidity
SWP 0-1 invert s/w polarity image
GWP 1 is inverted?
SPA 0-10? Set color palette
GPA 3 white hot
SMV 0-1 Show temperature 3x3 grid?? in combination with GTV maybe
GMV 0
SMS 0-1 displays "collected 0/<number set by SCT>" by SCP delay "saves the daily number of highest temperatures?"
GMS 0
SCT 1-500 sets the amount of "collected" points for SMS
GCT 80
SCP 5-60 "collected" delay in seconds for SMS
GCP 60
SAG 0-2 Auto brightness / gain
GAG 0
SLR 0-9 ???
GLR 0
SRP 0,0 - 639,479 set crosshair position
GRP 320,240 get crosshair position
DRC 0-1 Show crosshair
SLG -500-500 ??
GLG
SCE text ??
GCE 0
SCB text ??
GCB 0
SVB 0-16383 adc offset, exposure? good at 9650
GVB 6733 value is 16383 minus SVB
SVC 1-1023 set contrast but better
GVC 260
SVF 100-? ?? video freaks out 3400 seems good
SVS 100-? ?? video freaks out 3300 seems good
SOT 0-1 ?? sensor supply, looks weird when off.
SZM 1-4 ?
GZM 1
MSV save settings too eeprom
ASV Saves something aswell?
GCS 0 Get Core status & faults
ALD 0,2? video blanks lots of eeprom activity. reload pixel map??
SAV 0-9999 set Fire threshold
GAV 2100 get Fire Threshold
BAC change uart protocol? careful
CBD Displays Recovery successful?
CBS Displays Saved successfully
LRD Displays Recovery successful?
LRS Displays Saved successfully?
LRE Displays Temperature Repair successful?
CBT Displays Calibration successful?
DBP ??? shutter clicks
DPI Show weird pixels
API Hide weird pixels
CCM ??
ASN 0-4 ??
GAB 4 vals ?? 3,-10,50,150
GAN 1 ??
GAR 11 vals ?? 10,10,5,20,35,50,70,90,120,150,180,,
GCM 6 values ??
GFV prints screen gray value?
GIT 200 ??
GTV Get the collected temp values?
PTS echoes but with extra stuff??
QYA 7170 Query Gray Info (information mode)
QYI 7124 Query Gray Average mode
QYM 7512 Query Gray Minimum mode
VTP 400-4000 ??
MTD U/S,0,0 ?? S answers with bytes, U upload bytes?
MTC U/S? ?? S answers with U,0,0, S doesnt.

return 0 invalid params:
STS ??
STT ??
SAC ??
SAH ??
SAS ??
SAT ??
SCX ?? displays crosshair but invalid params
SCY ?? displays crosshair but invalid params
GAC ??
GAH ??
GAS ??
GAT ??
GME ??
GPC ??
GPI ??
GPM ??
GTA ??
GTC ??
GTI ??
GTM ??
GTS ??
GTT ??

answer only:

BPM 0-1 stream ready? answers with 0 stop, 1 go, 2 when prompted
AVS 0,1
MEH
PWI 0-1 changing palette from wh to fire

unconfirmed (from dm60comm.so):
SDT 2024,03,15,14,30,25 Set Date Time with year,month,day,hour,minute,second
STS 1 Set Temperature Show display (0=off, 1=on)
SVA 2 Set Video Auto mode (0=manual, 2=auto)
SMP 0,1,1,0,100,150,200,250,300,350,90,25 Set Measurement Point (type,index,enable,mode,startX,startY,endX,endY,anchorX,anchorY,threshold,color)
STV Stop Temperature View measurements
SPF 5 Set Profile parameter
SVL -10 Set Video Left pan movement (signed value)
SVU -5 Set Video Up tilt movement (signed value)
SVD 5 Set Video Down tilt movement (signed value)
SSP 17,1,0 Set System Parameter (param_id,value,index) #46 temperature format 0 °C, 1 °F, 2 K
SCP Set Current Preset (save current position)
GCP Get Current Preset
STT 300,350 Set Temperature Threshold (low,high values *10)
SDC 1 Set Display Configuration parameter
GCS Get Current Status
GMM Get Memory Map information
GFV Get Frame Value (grayscale data)
GFZ Get Freeze Status
GSI 1 Get System Information (parameter=1)
GSS Get System Status
GSP 21,0 Get System Parameter (param_21=surround temp, value=0)
GTT Get Temperature Threshold range
GTV 1,3,10 Get Temperature Values (enable,type,count)
GNU Get Network Update status (response command)
FRZ Freeze current display frame
LIV Live mode (unfreeze display)
CAL Calibrate system
CCP 3 Call Current Preset (preset number 0-9)
APF 100 Auto Profile setting
MEH Measure Enhancement
BPT Built-in Test
MTC S,0 Measure Temperature Capture (S=start, 0=sequence)
MTG U,0,1024,<data> Measure Temperature Gray data transfer
MTD U,0,1024,<data> Measure Temperature Data transfer
UFP S,0,2048 Update Firmware Prepare (S=start, 0=offset, 2048=size)
UFD S,0,1024 Update Firmware Data transfer
BAB U Buffer operation (U=update)
TTH S,0 Temperature Threshold operation
IPP 192.168.001.102,255.255.255.000,192.168.001.001,192.168.000.001,9989,9998 IP Parameters (IP,netmask,gateway,DNS,port1,port2)
MAC 00:60:A9:10:00:01 MAC Address setting
SNP Set Network Parameters (response command)
QYI Query Gray Info (information mode)
QYA Query Gray Average mode
QYM Query Gray Minimum mode
GAI Get Alarm Info (response command)
YTC <data> Unknown command with data parameter
HTH
LRS
LRD
GAR
DRC
PTS
SCX
SCY
CBT
LRE
CBD
CBS
XXX
GSP
GTT
QYI
QYA
QYM

</syntaxhighlight>

==Secret Menu Overview==
The secret menus Main and System can be openend with the password '''+-MC+-'''

Its structured like this, not all variables have been figured out yet.

The format is Menu: submenu: submenu:

and for menu entries: Name, default value, command, description or messages that pop up.
 <syntaxhighlight lang="vb">
MAIN & SYSTEM PASS: +-MC+-

entries are NAME VALUE COMMAND DESC or if its a folder its just ":"

System:
System:
Gain 255 SCO
Bright 102 IBR
BenDi 100 ?
BenDiContrase 80 ?
DisMode 0 ?
Frequency 48hz (24,25,48,50)
DigitalOut 8-14bit 14bit, BT656(_P), ?, BT601
AutoFocus N ?
Line 1 ?
Ltemp0 11800 ?
LTemp1 11000 ?
HTemp0 9500 ?
HTemp1 8700 ?
DelayTime 0 ?
Enhance 0-1 ?
Enhanced E1 230 ?
FPA_Gain 12pF ? between 4 and 18 at random.
NUCEn N ?

Area:
SE 2 ASN 0-4 "Partition"
INT 200 INT "Points time"
VS 3161 SVS
VF 2800 SVF
Vtemp 1401 VTP
VtempArea Low ?
VtempBase 13500 ?
VtempStep -1 ?
VsStep 8 ?
DeadPixelModel preset / calculate
DP: Cursor to select dead pixels
X 360 position
Y 288 position
AutoBP: 50 Press C to start automatic dotting
Quit? Number of bad pixels 961& "Blind element replacement in progress"
Undo
R2: Save data? blind pixel replacement in progress
Replace Y N = DPI, Y = API
L: Reading parameters
S: Saving parameters

Debug:
Rectify N
DisplayGary N
TE N SDT
AutoE ? ?
AutoVS Y ?
VSGrayH 8000 ?
VSGrayL 7000 ?
Trends 1 ?
Shelter N ?
MotorCon 3 ?
SaveFactoryPara:
LanTyp EN ? LANGUAGE
DisplayMT N ?
Version:
PRJ D843 DLD640 ImLib, MTlib, Soft, Logic

BackDispose:
GammaEN 1 ?
Gain 1 ?
EnhanceEN 0 ?
Hpf_shift 5 ?
Hpf_thrd 5 ?
Enhance 150 ?
Lthrd 50 ?

Monitor:
Opens normal OSD

Alarm Set:
Alarm Switch Y ?
Alarm Mode No ?
Alarm Temperature -1°C ?
Reference Gray Y ?
Alarm Level 1L ?
Alarm Gray 65535 ?
Alarm PointNum 0 ?
Correct Gray 0 ?

Thermometry:
Data Collection 0 SMS
Interval 60 SCP
Ammount 90 SCT
Environment normal ?
Export:
Displays: Exportin normal temperature MTC data
Correction -1 ?
Emissivity 100 SEM
Calibration:
BlackbodyTemp -10 grabs a val from GAB
Save CBS
Cancel CBD
Correction:
BlackbodyTemp -10 Picks from the list GAR
Grayscale 0 SLG
Confirm LRE
Save LRS
Cancel LRD
Ninepoint measurement SMV

Cursor:
Cur N DRC enable cursor
X 320 SRP set cursor position
Y 240 SRP set cursor position

Main:
Auto 2 SAG Auto gain
G 211 SVC
B 10002 SVB
P 1 SWP polarity
Z X ?
Settings:
Image:
FI Y ?
FIValue 0 ? 0-31
Freeze N Freeze image
VE N SMR Vertical flip
HO N SMR Horizontal flip
AutoCali L same as rectify?
O IN internal or external
COM:
Opens UART menu
AvoidburnSwitch OFF enable anti burn in
ProtectedTime 10S duration
AvoidBurn 16383 threshold to trigger antiburn

</syntaxhighlight>

===Automatic Dead Pixels and Flatmap Correction===

It it possible to generate a new flat and dead pixel map automatically within the camera after flashing the cleared-map binary.
 

=====Dead pixels:=====
In the secret menu "System", navigate to Area - DeadPixelModel and set the AutoBP (sensitivity for auto bad pixel finding) to 50 or so. Then press C Button

This can take a while.
[[File:High emissivity peltier black body.jpg|thumb|A Peltier / TEC coated in Candle sood to give it a high emissivity surface. It can be cooled or heated by swapping the polarity. ]]

Afterwards, navigate to S: and press + to save it.
 

=====Flatfield:=====
In the Debug menu navigate to R2 and press +

now place something '''Cold''' infront of the Camera with a high emissivity. (it needs to fill the whole image)

Press '''+''', wait for it to says High temperature.

Place something '''Hot''' infront and press '''+''' again.

Afterwards, save with '''S:''' again.

Flatfield should now be calibrated
 <blockquote>Note: Not all dead pixels are auto detected or get removed. you can manually select them in the Dead pixel editor but its not known yet how to select and correct them.</blockquote>

 

==Using the Thermal module without Webserver==
[[File:Breakoutboard d8x3c dali v1.1.png|alt=|thumb|Breakout board for D8X3C]]
to use it, you need to interface it directly.

The module will put out a Analog video signal (High-Z, need to buffer when connecting it to 75Ohm Video input)

Also a 8 or 14bit or 8-bit BT656 output.

the header exposes the FPGA JTAG and UART aswell as 6 Hardware Keys to Navigate the OSD.

To interface, you need to have a adapter board with a DF12-50DS-0.5V(86) Docking socket.

A open source project can be found here, it includes pin access to:

* FPGA JTAG
* UART 3.3V with pin compatible FT232 socket
* Power 5V over USB-C
* 5 Button inputs
* Buffered video output and socket for USB Videograbber
* Digital 14 bit video out header with hsync vsync and clk.
*

the pcb layout has been tested and seems to work.

https://oshwlab.com/gamerpaddy/d8x3c-backpack-usb

== Sending Serial Commands directly over UART ==

Sending Serial commands directly over UART to the core requires some additional bytes.

The packet structure is as follows (Strip spaces, commands are allways uppercase and 3 chars)
<STX> <LENGTH1> <LENGTH2> Command, Value, Checksum <ETX>

Pseudocode to craft a command packet may look like this<syntaxhighlight lang="c">
//cmd is allways 3 byte uppercase chars
//values can be multiple comma seperated like 320,240
function make_packet(cmd, values):
payload = cmd + "," + join(values, ",") + ","
bytes = ascii(payload)
length = len(bytes)
checksum = sum(bytes) mod 256
return [0x02, length&0xFF, length>>8] + bytes + [checksum, 0x03]
</syntaxhighlight>

 

==Sensor Pinout==
[[File:Dali DLD384 Sensor pinout basic.png|thumb|basic pinout of a DLD384]]
the pinout of the thermal sensor havent been analyzes much.

besides some supply and Control voltages, 3 clocks and a analog output have been found.

17.5MHz

14.705KHz

50Hz

Dali D8X3N Thermal Camera

2025-08-29T13:03:50Z

Gamerpaddy: /* Using the Thermal module without Webserver */

=Dali D8X3N Thermal Camera Reverse Engineering=
 

===Introduction===
The [https://www.dali-irtech.com/productinfo/741567.html Dali D8X3N] Thermal Camera module comes in two versions, a 384x288 and 640x480 resolution, utilizing the [http://www.dali-tech.us/products/dld64017m-uncooled-infrared-fpa-detector-86.html DLD Series] of amorphous-Silicon Microbolometers.

They were mainly used in [http://www.dali-tech.us/products/dm60-w--online-body-temperature-thermal-imaging-camera-55.html Dali DM60-W] or WS-1 Body Temperature screening cameras in conjunction with a Black Body radiator set to 37°C to detect infected individuals at the start of the 2020 Covid Pandemic.
[[File:ICI FM320P Innerts.jpg|thumb|Internals. A TP-Link Switch, HikVision Visible Camera and the D8x3N Network thermal camera module]]
[https://infraredcameras.com/ ICI] rebranded these models as FM 320 P and FM 640 P, and distributed them on the local US market, but as the need for such Cameras exploded, those models were built with what was in stock.

So happens, that some of the FM 320 P Models had a DLD640 640x480 instead of a DLD384 384x288 Microbolometer in them, and just got their Firmware modified.

It also could be, because they have excessive amounts of bad pixels outside the 384x288 area, that they were binned to a lower grade.

Discussions about these Cameras started around 2022 in the [https://www.eevblog.com/forum/thermal-imaging/ici-and-dali-thermal-camera-software/ EEVBlog Forums.] when they started to appear secondhand and affordable.

Originally they were priced around US$ 20... 30.000 by ICI, and a unknown amount by Dali Tech.

The Modules specs according to the manufacturer are:

≤50..60mK@F1，300K，50Hz

17 or 25µm pixel pitch

Hisilicon SoC running Linux to provide Onvif and RTSP streams, analysis and a Web UI

 
[[File:Dali D8X3N Module.jpg|thumb|A real 384x288 model with a DLD384 sensor. notice the Productnumber ]]
ICI FM Cameras are found all over Online secondhand marketplaces for scrap Prices, as they are no longer needed.

But you never know, what are you getting. It could be a real DLD384 or the better DLD640 inside. Its a gamble.
 

======640x480 Imagers======
are labeled 22D843 Nxxxx and have a DLD640 sensor in it, they can be upgraded if they run the 384x288 firmware.

======384x288 Imagers======
are labeled 22D883Nxxxx and have a DLD384 sensor in it, they cannot be upgraded

 

==D8X3N Module closer look==
From now on, i will refer to the Thermal Imaging Module as TIM

On the front there is a 2 Element Germanium Lens of a unknown focal length and aperture.

It can be focus-adjusted when unscrewing the clamp around the housing. It can be focussed from infinity down to 10..20cm with some quality loss.
 The outter diameter of the Lens is 42mm with a 1 1/3 inch thread diameter of undetermined pitch.

Dimensions of the germanium elements are 21mm to 3 and 6mm and 14grams in weight.
[[File:Disassembled Thermal Camera Lens.jpg|thumb|Two element Germanium Lens of unknown focal length and aperture]]

The TIM is composed of 6 Stacked PCB modules, 3 of which are for the Web Server functionality. taking them off will give you the basic configuration of a [https://www.dalithermal.com/productinfo/741568.html Dali D8X3C] TIM<gallery>
File:Dali DLD640 Thermal Image Sensor.jpeg|DLD640 Sensor
File:Dali DLD384 Thermal Imaging Sensor.jpeg|DLD384 Sensor
File:Dali D8X3N Board1 Back.jpeg|Network & GPIO Board Back
File:Dali D8X3N Board1 Front.jpeg|Network & GPIO Board Front
File:Dali D8X3N Glue Board Back.jpeg|Board between Logic and IO Back
File:Dali D8X3N Glue Board Front.jpeg|Board between Logic and IO Front
File:Dali D8X3N SoC Board Back.jpeg|SoC Board back
File:Dali D8X3N SoC Board front.jpeg|SoC board front
File:Dali D8X3N FPGA Board Back.jpeg|FPGA Board of the D8X3C Thermal Imager including a PMIC
File:Dali D8X3N FPGA Board Front.jpeg|FPGA Board Front with Video DAC and SPI Flash
File:Dali D8X3N Sensor Power and ADC Board.jpeg|Sensor control and ADC board
File:Dali D8X3N Thermal Core Debug wiring.jpeg|Debug wiring for sniffing SPI and UART
</gallery>

===User Manual===
including pinout diagram and important data

can be found here https://archive.org/details/dali-d-8-x-3-cuser-manualen-v-1.0-1

==Viewing the Video Stream==
[[File:Onvif Device Manager ODM.png|thumb|ODM streaming the Thermal view]]
when first connecting it to power and Ethernet, the camera will have 192.168.1.102 as a Static ip.

If you are running a 192.168.0.x or .178.x net, you need to change it or add a subnet under windows ipv4 settings.

to view it, you can use VLC and the stream URL
rtsp://admin@admin:<camera ip>/ONVIFMedia
there is /ONVIFMedia /ONVIFMediaM and /ONVIFMediaS for different stream Profiles.

VLC is quite slow and delayed, rather use Onvif Device Manager ODM,

it has no delay and auto-detects cameras in the network.

Be sure to log in as user: admin pass: admin in ODM.

in there, you can also set you camera to DHCP under Network settings.

===Web Interface===
[[File:Dali D8X3N web interface.png|thumb|Since browsers cant display RTSP anymore, open in Edge and select IE Compatibility Mode.]]
the web interface can be accessed by opening the camera IP in a browser

login is:
user: admin pass: admin
You can set Temperature markers and areas, but without using the Black Body calibration source, your readings may be way off or not working.

 

====OSD====
there is a debug-login with
user: super pass: 871897
that lets you send Key commands to the Imager to navigate the OSD.

Setting the OSD to english is accomplished with option #11
[[File:Dali D8X3C OSD.png|thumb|OSD in english, if yours is Chinese. go to option #11 and click + or -]]

To acces some locked menus, press
+ - + - + -

The password for the locked System and Main menu is
+-MC+-

Be careful in the UART menu to not change the BAUD rate or Protocol, as your ability to control it via the Web API gets lost.

You need to reflash or solder buttons on the thermal core then.

==Viewing Raw Thermal Data from the Web API==
there is a hidden endpoint in the stream.so file that could be found while decompiling

accessing
[[File:Arduino Nano blink sketch thermal gif.gif|thumb|Arduino Nano running blink sketch while thermally recording it, notice the led and resistor on the right]]
<ip of camera>:5000/stream?Type=JPEG&Source=Jpeg&Mode=TCP
lets you download a JPEG. but there are more options available (not all have been tested)

we are mainly interessted in Raw thermal data.

====Source (Stream Type)====

*<code>Major</code> - Main video stream (channel 0)
*<code>Minor</code> - Sub video stream (channel 1)
*<code>MinorAV</code> - Sub video + audio stream
*<code>MajorAV</code> - Main video + audio stream
*<code>Jpeg</code> - JPEG snapshot stream
*<code>Raw</code> - Raw thermal data stream
*<code>YUV</code> - YUV raw video stream

====Type (Data Format)====

*<code>H264</code> - H.264 video encoding
*<code>JPEG</code> - JPEG image format
*<code>RAW</code> - Raw sensor data
*<code>QBOX</code> - Custom protocol format
*<code>FRAME</code> - Frame-based format

====Mode (Transport Protocol)====

*<code>TCP</code> - TCP streaming (default)
*<code>UDP</code> - UDP streaming
*<code>MUL</code> - Multicast streaming

====Quality Parameters====

*<code>Quality=[1-100]</code> - Video quality level
*<code>Frames=[number]</code> - Number of frames to send
*<code>Interval=[ms]</code> - Frame interval in milliseconds

====Network Parameters====

*<code>IPAddr=[ip]</code> - Client IP address for UDP/multicast
*<code>Port=[port]</code> - Client port for UDP/multicast
*<code>Heart-beat=[Yes/No]</code> - Enable/disable heartbeat

====Snapshot Parameters====

*<code>Snap=[Yes/No]</code> - Enable snapshot mode

 
====Raw Viewer for PC (Python)====
[[File:Dali D8X3N Raw Thermal viewer.png|thumb|Raw Data Viewer in python]]

To view the raw stream, i made a python program that converts the 14bit thermal data to a visible image.

it is low fps tho, due to bad optimizations.

rev1 first working version https://pastebin.com/dyNWDPT3

rev2 with temperature readout https://pastebin.com/u107Q85w

rev3 and onward will only be available directly as a Webpage on the Device (see below).

====Raw Viewer for the internal Webserver (recommended)====
It is also possible to use the Raw viewer directly in the browser.

To achieve this, the stream had to be proxied from port 5000 to 80 due to CORS.

luckily the internal lighttpd had the CGI module enabled, so piping it troug (using wget ... i know) worked with very low overhead.

To install, you need '''Terminal access''' to the Camera. see below.

optional for simplicity: '''ftp''' access

[[File:Dali D8X3N Webviewer.png|thumb|Web Raw Viewer with histogram (rev3)]]

Create the files and the code inside.

'''/app/web/webpages/raw.html''' https://pastebin.com/kaiXwAgD

and

'''/app/web/webpages/cgi-bin/proxy.cgi''' https://pastebin.com/vii1HXcU

then run
chmod +x /app/web/webpages/cgi-bin/proxy.cgi
'''restart''' your camera.

It should be accessible now trough '''http://<camera ip>/raw.html''' in the browser and click Start Stream

'''NOTE''': ''If it does not work'', check the contents of both files. FTP sometimes messes them up.

also run
dos2unix /app/web/webpages/cgi-bin/proxy.cgi
because linux <> windows difficulties that couldnt be resolved in over 30 years.

<blockquote>

performance may need improvement.</blockquote>

==Getting Root Terminal Access==
To access the Terminal you need to solder or plug in a UART connection to Connector J7 on the "Glue" board.

Pinout is (left to right) '''RX TX GND 3.3V Baud 115200 3.3V!'''

But the system will spam with debug messages, making patching the files a hard job unless you use "tftp" or "sed" commands.
 

====Enabling Telnet access to make patching easier====
[[File:Upgrade ici dali firmware updater.png|thumb|ICI Firmware updater software with modified firmware loaded]]

there is a easier way using a modified Firmware updater to enable Telnet temporarily to patch the Files.

Download the '''upgrade_ici.exe''' form [https://archive.org/details/fwupdate here] and run it.

Then you should be able to connect to it via Telnet.

The Login credentials are '''User: roo'''t '''Password: DLroot'''

 

===Patching Device===

===Patching the Web Server===
 

====Enabling Telnet and ftpd permanently====

This only works if you also patch the Thermal Camera module flash!

to permanently enable Telnet, go to '''/etc/init.d''' and edit '''S90app'''
vi S90app
in vi, move your cursor to the '''#''' at '''#telnetd''' and press x<blockquote>optional: enable ftp by removing the '''#''' at '''ftpd''' and adjust the path to / </blockquote>now press ''':''' and type '''wq''' and hit '''enter'''. this should be it.

====Patching the decoder and streamer to 640x480:====
go to /app and edit the mach.cfg

replace DL384 with D640 and edit the resolution to 640 480

(press i in vi to enter edit mode, press ESC to exit edit mode. :wq to write and quit.)

repeat that procedure for the dali.cfg

=====(optional) patching app.sh to prevent it from rebooting=====
edit the app.sh in /app and remove all "reboot" occasions to prevent the camera from rebooting if onvifserver, httpd or daliServer arent running for debugging purposes.

 

====Patching the Thermal Camera module====
To patch it, you need to disassemble everything down to the FPGA Board,

on the bottom there is a SPI SOIC8 Flash.

Use a CH341 EEPROM programmer (be sure to have a fixed or modified version to not put out 5V!, set it to 3.3V) and SOIC8 clamp.

Use NeoProgrammer (i used 2.2.0.10 but there are newer available, use the latest) and click Detect. It should find W25Q128 chips, select the FV one.

Dont forget to download a backup of your flash and save it !

Download the Binary "Dali 640x480 '''actual''' cleared pixelmap.bin" from #3 below and load it into NeoProgrammer,

Click Erase, Program and Verify.

This can take a while.

Your imager should start up right after assembly by hearing the shutter click.

==Hardware Hacking==

===Flash Contents===
On archive, click on show all files to download them.

<nowiki>#</nowiki>1 a Flash dump of the original downgraded D8X3N can be found [https://archive.org/details/dali-d-843n-flash-dump here]

<nowiki>#</nowiki>2 a Flash dump of a original 640x480 model can be found [https://archive.org/details/d-843-n-640x-480 here]

<nowiki>#</nowiki>3 a modified Flash dump of a 640x480 with cleared dead pixel map, flat map etc. can be found [https://archive.org/details/d-843-n-640x-480-cleared-pixelmap here]

a Flash dump of the web server SPI flash W25Q256JV can be found [https://archive.org/details/dm-60-webserver-flash-dump here] in case a bad firmware update caused a bootloop.

 

===Flash Binary Analysis===
The Flash IC is a Winbond 25Q128JV SPI Flash that contains the FPGA Bitstream, Deadpixel and Flatmap, aswell as the Device Settings.

a copy of the SPI Logic Capture at startup can be found [https://archive.org/details/dali-eeprom-capture here], the free software [https://www.dreamsourcelab.com/download/ DSView from DreamSourceLab] is required to view it.
[[File:Dali Thermal Imager SPI Flash capture.png|thumb|SPI Flash access while booting the Thermal Module]]

a approximation of the offsets resulted in this list:<syntaxhighlight lang="vb">
0x000000 - altera cyclone iv stuff
0x200000 - settings
0x280000 - Flat field correction map
0x4C0000 - Bad Pixel correctio nmap
0x580000 - image aswell? 36010 bytes
0x740000 - GUIX?
0x7C0000 - Strings for Gui?
0x800000 - another shorter GUIX
0x880000 - Strings for second gui?
0x8C0000 - GUIX
0x940000 - Strings for gui
0xE00000 - ?
0xE80000 - dzxg? short
0xEC0000 - crosshair.bmp
0xF40000 - 3DTM?
0xF80000 - fake? Bad pixel map BPRP
</syntaxhighlight> 

====Settings offset 0x200000====
The settings are read and written every startup, aswell when you close the OSD, sporadically and when executing the command MSV

these are some of the settings i could figure out by changing and watching the logic capture what changed.
 <syntaxhighlight lang="vb">
offset size Cmd
0x0 1 SAG (0-2) auto gain
0x2 2 SVB (0-16383) saved value is 16383 - SVB
0x4 2 SVC (0-1023) set exposure or gain
0x6 1 SSM image filtering
0x8 1 SEH image enhancement
0xA 1 SWP invert b/w polarity
0x14 1 SMR Flip
0x16 1 SMR Mirror
0x20 1 MENU Cal source 0 IN, 1 OUT
0x3A 1 MENU Enhance value 0-100
0x40 1 MENU Rectify (shutter 0 OFF, 1 L, 2 H)
0x50 1 MENU Language 0 english, 1 chinese, 2 russian
0xA2 - SCO set contrast gain
0xA4 - IBR set brightness
0xAE 2 MENU Fire Threshold
0xAC 1 SPA set color palette
0xE2 1 SMS display "collected 0/80" enabled
0xF8 1 SEM set emissivity
0x110 1 SRT set revise temp
0x116 1 SHD set humidity
0x118 1 SET set ambient temp
0x11A 1 STD set temp range
0x120 2 SLG -500 to 500?
0x124 2 SRD set distance
0x12C 1 SCP ???
0x130 2 SCT ???
</syntaxhighlight> 
[[File:Dali D8X3N Bad Pixel Map Viewer.png|thumb|Bad pixel map of a 640x512 sensor, about 0.56% of dead pixels in this map]]
So i let the AI create a [https://2476424.playcode.io/ Configurator page] that lets you change the Settings in your Flashdump to your liking
 

====Bad Pixel and Flatframe Maps 0x280000 and 0x4C0000====
Thermal cameras require a bad pixel and flat frame map to compensate for manufacturing inconsistencies.

unfourtainly, the maps of the downgraded cameras only contain enough data for a 384 model, not the full 640.

at offset 0xF80000 there is a BPRP which was mistaken at first as the Bad pixel map, it could just be a mask to where to apply the offset maps, as its either 0x0 or 0x1.

The [https://2477569.playcode.io/ Viewer Page] is written in JS and does not require any special dependencies, it can run as a plain html file offline.

''See "Automatic Dead Pixels and Flatmap Correction" below how to create new dead pixel and flatmaps using the system menu.''

[[File:Dali D8X3N Flat Field Map Viewer.png|thumb|Flat Field viewer]]

==Dali Commands==
To control the TIM you can either use Pelco or Dali command set. By default the Dali commandset is used at 38400 BAUD.

Those commands consist of a 0x02 start byte followed by two length Bytes, then the actual command which is allways 3 uppercase Letters in ASCII (eg. KBD for keyboard) followed by a comma and the values.

Some commands take multiple values, some dont. But you allways have to send the comma after the Command.

The camera will answer with the Command and 0, 1 or 2. Sending no value counts as zero.
0 is invalid parameters, too few or out of range

1 is OK, valid command

2 is Invalid command

Commands can be sent trough the Web server using the URL Api endpoint or directly trough the UART port.

(keyboard, C button, causes the shutter to do a calibration)
<camera ip>/cgi-bin/dmcmd?Command=KBD,C
Listening to the answer can be done while being in the Linux shell and typing
cat /dev/ttyAMA2 | strings

By bruteforcing the UART with AAA to ZZZ a list of Commands could be obtained, but some with unknown Parameters or functionality yet. including some from a decompiled DM60comm.so module found in /app/modules folder.<syntaxhighlight lang="vb">
KBD KEY Keyboard (F S M C + -)
SSM 0-1 Image Filtering Off/On
GSM 0 Image filter status
SEH 0-1 Image Enhancement Off/On
GEH 0-1 Image enhancer status
SCO 0-255 Set Gain (locked when SAG auto gain is on)
GCO 0-255 Get gain
INT 15-320 set actual gain? not just contrast sometimes disabled?
IBR 0-255 Set brightness
GBR 0-255 Get brightness
SMR 0-3 Mirror mode bit0=horizontal, bit1=vertical
GMR 0 Get rotation/flip
SDT 0-1 displays temp=44.65°C osd, but webserver sends date/time to the cam there....
GDT 0-1 Get temp display active?
GPT Display temp oft SDT
GNU 0-1 Get Shutter closed/open
SNU 0-1 Shutter close / open
STD 0-1 Set Range 0: -20-180°C 1: 100-600°C
GTD 0-1 Get Range
SET °C Set Ambient temperature
GET °C Get Ambient temperature
SEM 0-100 0-1 set emissivity x100
GEM 0-100 Get Emissivity
SRT °C Set revise temperature -100-100 -10-10°
GRT °C Get revise temperature
SRD 100 Set Distance 4.4m x100
GRD 100 Get Distance
SHD 0-100 Set Humidity
GHD 55 Get Humidity
SWP 0-1 invert s/w polarity image
GWP 1 is inverted?
SPA 0-10? Set color palette
GPA 3 white hot
SMV 0-1 Show temperature 3x3 grid?? in combination with GTV maybe
GMV 0
SMS 0-1 displays "collected 0/<number set by SCT>" by SCP delay "saves the daily number of highest temperatures?"
GMS 0
SCT 1-500 sets the amount of "collected" points for SMS
GCT 80
SCP 5-60 "collected" delay in seconds for SMS
GCP 60
SAG 0-2 Auto brightness / gain
GAG 0
SLR 0-9 ???
GLR 0
SRP 0,0 - 639,479 set crosshair position
GRP 320,240 get crosshair position
DRC 0-1 Show crosshair
SLG -500-500 ??
GLG
SCE text ??
GCE 0
SCB text ??
GCB 0
SVB 0-16383 adc offset, exposure? good at 9650
GVB 6733 value is 16383 minus SVB
SVC 1-1023 set contrast but better
GVC 260
SVF 100-? ?? video freaks out 3400 seems good
SVS 100-? ?? video freaks out 3300 seems good
SOT 0-1 ?? sensor supply, looks weird when off.
SZM 1-4 ?
GZM 1
MSV save settings too eeprom
ASV Saves something aswell?
GCS 0 Get Core status & faults
ALD 0,2? video blanks lots of eeprom activity. reload pixel map??
SAV 0-9999 set Fire threshold
GAV 2100 get Fire Threshold
BAC change uart protocol? careful
CBD Displays Recovery successful?
CBS Displays Saved successfully
LRD Displays Recovery successful?
LRS Displays Saved successfully?
LRE Displays Temperature Repair successful?
CBT Displays Calibration successful?
DBP ??? shutter clicks
DPI Show weird pixels
API Hide weird pixels
CCM ??
ASN 0-4 ??
GAB 4 vals ?? 3,-10,50,150
GAN 1 ??
GAR 11 vals ?? 10,10,5,20,35,50,70,90,120,150,180,,
GCM 6 values ??
GFV prints screen gray value?
GIT 200 ??
GTV Get the collected temp values?
PTS echoes but with extra stuff??
QYA 7170 Query Gray Info (information mode)
QYI 7124 Query Gray Average mode
QYM 7512 Query Gray Minimum mode
VTP 400-4000 ??
MTD U/S,0,0 ?? S answers with bytes, U upload bytes?
MTC U/S? ?? S answers with U,0,0, S doesnt.

return 0 invalid params:
STS ??
STT ??
SAC ??
SAH ??
SAS ??
SAT ??
SCX ?? displays crosshair but invalid params
SCY ?? displays crosshair but invalid params
GAC ??
GAH ??
GAS ??
GAT ??
GME ??
GPC ??
GPI ??
GPM ??
GTA ??
GTC ??
GTI ??
GTM ??
GTS ??
GTT ??

answer only:

BPM 0-1 stream ready? answers with 0 stop, 1 go, 2 when prompted
AVS 0,1
MEH
PWI 0-1 changing palette from wh to fire

unconfirmed (from dm60comm.so):
SDT 2024,03,15,14,30,25 Set Date Time with year,month,day,hour,minute,second
STS 1 Set Temperature Show display (0=off, 1=on)
SVA 2 Set Video Auto mode (0=manual, 2=auto)
SMP 0,1,1,0,100,150,200,250,300,350,90,25 Set Measurement Point (type,index,enable,mode,startX,startY,endX,endY,anchorX,anchorY,threshold,color)
STV Stop Temperature View measurements
SPF 5 Set Profile parameter
SVL -10 Set Video Left pan movement (signed value)
SVU -5 Set Video Up tilt movement (signed value)
SVD 5 Set Video Down tilt movement (signed value)
SSP 17,1,0 Set System Parameter (param_id,value,index) #46 temperature format 0 °C, 1 °F, 2 K
SCP Set Current Preset (save current position)
GCP Get Current Preset
STT 300,350 Set Temperature Threshold (low,high values *10)
SDC 1 Set Display Configuration parameter
GCS Get Current Status
GMM Get Memory Map information
GFV Get Frame Value (grayscale data)
GFZ Get Freeze Status
GSI 1 Get System Information (parameter=1)
GSS Get System Status
GSP 21,0 Get System Parameter (param_21=surround temp, value=0)
GTT Get Temperature Threshold range
GTV 1,3,10 Get Temperature Values (enable,type,count)
GNU Get Network Update status (response command)
FRZ Freeze current display frame
LIV Live mode (unfreeze display)
CAL Calibrate system
CCP 3 Call Current Preset (preset number 0-9)
APF 100 Auto Profile setting
MEH Measure Enhancement
BPT Built-in Test
MTC S,0 Measure Temperature Capture (S=start, 0=sequence)
MTG U,0,1024,<data> Measure Temperature Gray data transfer
MTD U,0,1024,<data> Measure Temperature Data transfer
UFP S,0,2048 Update Firmware Prepare (S=start, 0=offset, 2048=size)
UFD S,0,1024 Update Firmware Data transfer
BAB U Buffer operation (U=update)
TTH S,0 Temperature Threshold operation
IPP 192.168.001.102,255.255.255.000,192.168.001.001,192.168.000.001,9989,9998 IP Parameters (IP,netmask,gateway,DNS,port1,port2)
MAC 00:60:A9:10:00:01 MAC Address setting
SNP Set Network Parameters (response command)
QYI Query Gray Info (information mode)
QYA Query Gray Average mode
QYM Query Gray Minimum mode
GAI Get Alarm Info (response command)
YTC <data> Unknown command with data parameter
HTH
LRS
LRD
GAR
DRC
PTS
SCX
SCY
CBT
LRE
CBD
CBS
XXX
GSP
GTT
QYI
QYA
QYM

</syntaxhighlight>

==Secret Menu Overview==
The secret menus Main and System can be openend with the password '''+-MC+-'''

Its structured like this, not all variables have been figured out yet.

The format is Menu: submenu: submenu:

and for menu entries: Name, default value, command, description or messages that pop up.
 <syntaxhighlight lang="vb">
MAIN & SYSTEM PASS: +-MC+-

entries are NAME VALUE COMMAND DESC or if its a folder its just ":"

System:
System:
Gain 255 SCO
Bright 102 IBR
BenDi 100 ?
BenDiContrase 80 ?
DisMode 0 ?
Frequency 48hz (24,25,48,50)
DigitalOut 8-14bit 14bit, BT656(_P), ?, BT601
AutoFocus N ?
Line 1 ?
Ltemp0 11800 ?
LTemp1 11000 ?
HTemp0 9500 ?
HTemp1 8700 ?
DelayTime 0 ?
Enhance 0-1 ?
Enhanced E1 230 ?
FPA_Gain 12pF ? between 4 and 18 at random.
NUCEn N ?

Area:
SE 2 ASN 0-4 "Partition"
INT 200 INT "Points time"
VS 3161 SVS
VF 2800 SVF
Vtemp 1401 VTP
VtempArea Low ?
VtempBase 13500 ?
VtempStep -1 ?
VsStep 8 ?
DeadPixelModel preset / calculate
DP: Cursor to select dead pixels
X 360 position
Y 288 position
AutoBP: 50 Press C to start automatic dotting
Quit? Number of bad pixels 961& "Blind element replacement in progress"
Undo
R2: Save data? blind pixel replacement in progress
Replace Y N = DPI, Y = API
L: Reading parameters
S: Saving parameters

Debug:
Rectify N
DisplayGary N
TE N SDT
AutoE ? ?
AutoVS Y ?
VSGrayH 8000 ?
VSGrayL 7000 ?
Trends 1 ?
Shelter N ?
MotorCon 3 ?
SaveFactoryPara:
LanTyp EN ? LANGUAGE
DisplayMT N ?
Version:
PRJ D843 DLD640 ImLib, MTlib, Soft, Logic

BackDispose:
GammaEN 1 ?
Gain 1 ?
EnhanceEN 0 ?
Hpf_shift 5 ?
Hpf_thrd 5 ?
Enhance 150 ?
Lthrd 50 ?

Monitor:
Opens normal OSD

Alarm Set:
Alarm Switch Y ?
Alarm Mode No ?
Alarm Temperature -1°C ?
Reference Gray Y ?
Alarm Level 1L ?
Alarm Gray 65535 ?
Alarm PointNum 0 ?
Correct Gray 0 ?

Thermometry:
Data Collection 0 SMS
Interval 60 SCP
Ammount 90 SCT
Environment normal ?
Export:
Displays: Exportin normal temperature MTC data
Correction -1 ?
Emissivity 100 SEM
Calibration:
BlackbodyTemp -10 grabs a val from GAB
Save CBS
Cancel CBD
Correction:
BlackbodyTemp -10 Picks from the list GAR
Grayscale 0 SLG
Confirm LRE
Save LRS
Cancel LRD
Ninepoint measurement SMV

Cursor:
Cur N DRC enable cursor
X 320 SRP set cursor position
Y 240 SRP set cursor position

Main:
Auto 2 SAG Auto gain
G 211 SVC
B 10002 SVB
P 1 SWP polarity
Z X ?
Settings:
Image:
FI Y ?
FIValue 0 ? 0-31
Freeze N Freeze image
VE N SMR Vertical flip
HO N SMR Horizontal flip
AutoCali L same as rectify?
O IN internal or external
COM:
Opens UART menu
AvoidburnSwitch OFF enable anti burn in
ProtectedTime 10S duration
AvoidBurn 16383 threshold to trigger antiburn

</syntaxhighlight>

===Automatic Dead Pixels and Flatmap Correction===

It it possible to generate a new flat and dead pixel map automatically within the camera after flashing the cleared-map binary.
 

=====Dead pixels:=====
In the secret menu "System", navigate to Area - DeadPixelModel and set the AutoBP (sensitivity for auto bad pixel finding) to 50 or so. Then press C Button

This can take a while.
[[File:High emissivity peltier black body.jpg|thumb|A Peltier / TEC coated in Candle sood to give it a high emissivity surface. It can be cooled or heated by swapping the polarity. ]]

Afterwards, navigate to S: and press + to save it.
 

=====Flatfield:=====
In the Debug menu navigate to R2 and press +

now place something '''Cold''' infront of the Camera with a high emissivity. (it needs to fill the whole image)

Press '''+''', wait for it to says High temperature.

Place something '''Hot''' infront and press '''+''' again.

Afterwards, save with '''S:''' again.

Flatfield should now be calibrated
 <blockquote>Note: Not all dead pixels are auto detected or get removed. you can manually select them in the Dead pixel editor but its not known yet how to select and correct them.</blockquote>

 

==Using the Thermal module without Webserver==
[[File:Breakoutboard d8x3c dali v1.1.png|alt=|thumb|Breakout board for D8X3C]]
to use it, you need to interface it directly.

The module will put out a Analog video signal (High-Z, need to buffer when connecting it to 75Ohm Video input)

Also a 8 or 14bit or 8-bit BT656 output.

the header exposes the FPGA JTAG and UART aswell as 6 Hardware Keys to Navigate the OSD.

To interface, you need to have a adapter board with a DF12-50DS-0.5V(86) Docking socket.

A open source project can be found here, it includes pin access to:

FPGA JTAG

UART 3.3V with pin compatible FT232 socket

Power 5V over USB-C

5 Button inputs

Buffered video output and socket for USB Videograbber

Digital 14 bit video out header with hsync vsync and clk.

the pcb has been tested and seems to work.https://oshwlab.com/gamerpaddy/d8x3c-backpack-usb

 

==Sensor Pinout==
[[File:Dali DLD384 Sensor pinout basic.png|thumb|basic pinout of a DLD384]]
the pinout of the thermal sensor havent been analyzes much.

besides some supply and Control voltages, 3 clocks and a analog output have been found.

17.5MHz

14.705KHz

50Hz

File:Breakoutboard d8x3c dali v1.1.png

2025-08-29T13:01:29Z

Gamerpaddy:

fixed version

Dali D8X3N Thermal Camera

2025-08-15T17:14:50Z

Gamerpaddy: /* Bad Pixel and Flatframe Maps 0x280000 and 0x4C0000 */

=Dali D8X3N Thermal Camera Reverse Engineering=
 

===Introduction===
The [https://www.dali-irtech.com/productinfo/741567.html Dali D8X3N] Thermal Camera module comes in two versions, a 384x288 and 640x480 resolution, utilizing the [http://www.dali-tech.us/products/dld64017m-uncooled-infrared-fpa-detector-86.html DLD Series] of amorphous-Silicon Microbolometers.

They were mainly used in [http://www.dali-tech.us/products/dm60-w--online-body-temperature-thermal-imaging-camera-55.html Dali DM60-W] or WS-1 Body Temperature screening cameras in conjunction with a Black Body radiator set to 37°C to detect infected individuals at the start of the 2020 Covid Pandemic.
[[File:ICI FM320P Innerts.jpg|thumb|Internals. A TP-Link Switch, HikVision Visible Camera and the D8x3N Network thermal camera module]]
[https://infraredcameras.com/ ICI] rebranded these models as FM 320 P and FM 640 P, and distributed them on the local US market, but as the need for such Cameras exploded, those models were built with what was in stock.

So happens, that some of the FM 320 P Models had a DLD640 640x480 instead of a DLD384 384x288 Microbolometer in them, and just got their Firmware modified.

It also could be, because they have excessive amounts of bad pixels outside the 384x288 area, that they were binned to a lower grade.

Discussions about these Cameras started around 2022 in the [https://www.eevblog.com/forum/thermal-imaging/ici-and-dali-thermal-camera-software/ EEVBlog Forums.] when they started to appear secondhand and affordable.

Originally they were priced around US$ 20... 30.000 by ICI, and a unknown amount by Dali Tech.

The Modules specs according to the manufacturer are:

≤50..60mK@F1，300K，50Hz

17 or 25µm pixel pitch

Hisilicon SoC running Linux to provide Onvif and RTSP streams, analysis and a Web UI

 
[[File:Dali D8X3N Module.jpg|thumb|A real 384x288 model with a DLD384 sensor. notice the Productnumber ]]
ICI FM Cameras are found all over Online secondhand marketplaces for scrap Prices, as they are no longer needed.

But you never know, what are you getting. It could be a real DLD384 or the better DLD640 inside. Its a gamble.
 

======640x480 Imagers======
are labeled 22D843 Nxxxx and have a DLD640 sensor in it, they can be upgraded if they run the 384x288 firmware.

======384x288 Imagers======
are labeled 22D883Nxxxx and have a DLD384 sensor in it, they cannot be upgraded

 

==D8X3N Module closer look==
From now on, i will refer to the Thermal Imaging Module as TIM

On the front there is a 2 Element Germanium Lens of a unknown focal length and aperture.

It can be focus-adjusted when unscrewing the clamp around the housing. It can be focussed from infinity down to 10..20cm with some quality loss.
 The outter diameter of the Lens is 42mm with a 1 1/3 inch thread diameter of undetermined pitch.

Dimensions of the germanium elements are 21mm to 3 and 6mm and 14grams in weight.
[[File:Disassembled Thermal Camera Lens.jpg|thumb|Two element Germanium Lens of unknown focal length and aperture]]

The TIM is composed of 6 Stacked PCB modules, 3 of which are for the Web Server functionality. taking them off will give you the basic configuration of a [https://www.dalithermal.com/productinfo/741568.html Dali D8X3C] TIM<gallery>
File:Dali DLD640 Thermal Image Sensor.jpeg|DLD640 Sensor
File:Dali DLD384 Thermal Imaging Sensor.jpeg|DLD384 Sensor
File:Dali D8X3N Board1 Back.jpeg|Network & GPIO Board Back
File:Dali D8X3N Board1 Front.jpeg|Network & GPIO Board Front
File:Dali D8X3N Glue Board Back.jpeg|Board between Logic and IO Back
File:Dali D8X3N Glue Board Front.jpeg|Board between Logic and IO Front
File:Dali D8X3N SoC Board Back.jpeg|SoC Board back
File:Dali D8X3N SoC Board front.jpeg|SoC board front
File:Dali D8X3N FPGA Board Back.jpeg|FPGA Board of the D8X3C Thermal Imager including a PMIC
File:Dali D8X3N FPGA Board Front.jpeg|FPGA Board Front with Video DAC and SPI Flash
File:Dali D8X3N Sensor Power and ADC Board.jpeg|Sensor control and ADC board
File:Dali D8X3N Thermal Core Debug wiring.jpeg|Debug wiring for sniffing SPI and UART
</gallery>

===User Manual===
including pinout diagram and important data

can be found here https://archive.org/details/dali-d-8-x-3-cuser-manualen-v-1.0-1

==Viewing the Video Stream==
[[File:Onvif Device Manager ODM.png|thumb|ODM streaming the Thermal view]]
when first connecting it to power and Ethernet, the camera will have 192.168.1.102 as a Static ip.

If you are running a 192.168.0.x or .178.x net, you need to change it or add a subnet under windows ipv4 settings.

to view it, you can use VLC and the stream URL
rtsp://admin@admin:<camera ip>/ONVIFMedia
there is /ONVIFMedia /ONVIFMediaM and /ONVIFMediaS for different stream Profiles.

VLC is quite slow and delayed, rather use Onvif Device Manager ODM,

it has no delay and auto-detects cameras in the network.

Be sure to log in as user: admin pass: admin in ODM.

in there, you can also set you camera to DHCP under Network settings.

===Web Interface===
[[File:Dali D8X3N web interface.png|thumb|Since browsers cant display RTSP anymore, open in Edge and select IE Compatibility Mode.]]
the web interface can be accessed by opening the camera IP in a browser

login is:
user: admin pass: admin
You can set Temperature markers and areas, but without using the Black Body calibration source, your readings may be way off or not working.

 

====OSD====
there is a debug-login with
user: super pass: 871897
that lets you send Key commands to the Imager to navigate the OSD.

Setting the OSD to english is accomplished with option #11
[[File:Dali D8X3C OSD.png|thumb|OSD in english, if yours is Chinese. go to option #11 and click + or -]]

To acces some locked menus, press
+ - + - + -

The password for the locked System and Main menu is
+-MC+-

Be careful in the UART menu to not change the BAUD rate or Protocol, as your ability to control it via the Web API gets lost.

You need to reflash or solder buttons on the thermal core then.

==Viewing Raw Thermal Data from the Web API==
there is a hidden endpoint in the stream.so file that could be found while decompiling

accessing
[[File:Arduino Nano blink sketch thermal gif.gif|thumb|Arduino Nano running blink sketch while thermally recording it, notice the led and resistor on the right]]
<ip of camera>:5000/stream?Type=JPEG&Source=Jpeg&Mode=TCP
lets you download a JPEG. but there are more options available (not all have been tested)

we are mainly interessted in Raw thermal data.

====Source (Stream Type)====

*<code>Major</code> - Main video stream (channel 0)
*<code>Minor</code> - Sub video stream (channel 1)
*<code>MinorAV</code> - Sub video + audio stream
*<code>MajorAV</code> - Main video + audio stream
*<code>Jpeg</code> - JPEG snapshot stream
*<code>Raw</code> - Raw thermal data stream
*<code>YUV</code> - YUV raw video stream

====Type (Data Format)====

*<code>H264</code> - H.264 video encoding
*<code>JPEG</code> - JPEG image format
*<code>RAW</code> - Raw sensor data
*<code>QBOX</code> - Custom protocol format
*<code>FRAME</code> - Frame-based format

====Mode (Transport Protocol)====

*<code>TCP</code> - TCP streaming (default)
*<code>UDP</code> - UDP streaming
*<code>MUL</code> - Multicast streaming

====Quality Parameters====

*<code>Quality=[1-100]</code> - Video quality level
*<code>Frames=[number]</code> - Number of frames to send
*<code>Interval=[ms]</code> - Frame interval in milliseconds

====Network Parameters====

*<code>IPAddr=[ip]</code> - Client IP address for UDP/multicast
*<code>Port=[port]</code> - Client port for UDP/multicast
*<code>Heart-beat=[Yes/No]</code> - Enable/disable heartbeat

====Snapshot Parameters====

*<code>Snap=[Yes/No]</code> - Enable snapshot mode

 
====Raw Viewer for PC (Python)====
[[File:Dali D8X3N Raw Thermal viewer.png|thumb|Raw Data Viewer in python]]

To view the raw stream, i made a python program that converts the 14bit thermal data to a visible image.

it is low fps tho, due to bad optimizations.

rev1 first working version https://pastebin.com/dyNWDPT3

rev2 with temperature readout https://pastebin.com/u107Q85w

rev3 and onward will only be available directly as a Webpage on the Device (see below).

====Raw Viewer for the internal Webserver (recommended)====
It is also possible to use the Raw viewer directly in the browser.

To achieve this, the stream had to be proxied from port 5000 to 80 due to CORS.

luckily the internal lighttpd had the CGI module enabled, so piping it troug (using wget ... i know) worked with very low overhead.

To install, you need '''Terminal access''' to the Camera. see below.

optional for simplicity: '''ftp''' access

[[File:Dali D8X3N Webviewer.png|thumb|Web Raw Viewer with histogram (rev3)]]

Create the files and the code inside.

'''/app/web/webpages/raw.html''' https://pastebin.com/kaiXwAgD

and

'''/app/web/webpages/cgi-bin/proxy.cgi''' https://pastebin.com/vii1HXcU

then run
chmod +x /app/web/webpages/cgi-bin/proxy.cgi
'''restart''' your camera.

It should be accessible now trough '''http://<camera ip>/raw.html''' in the browser and click Start Stream

'''NOTE''': ''If it does not work'', check the contents of both files. FTP sometimes messes them up.

also run
dos2unix /app/web/webpages/cgi-bin/proxy.cgi
because linux <> windows difficulties that couldnt be resolved in over 30 years.

<blockquote>

performance may need improvement.</blockquote>

==Getting Root Terminal Access==
To access the Terminal you need to solder or plug in a UART connection to Connector J7 on the "Glue" board.

Pinout is (left to right) '''RX TX GND 3.3V Baud 115200 3.3V!'''

But the system will spam with debug messages, making patching the files a hard job unless you use "tftp" or "sed" commands.
 

====Enabling Telnet access to make patching easier====
[[File:Upgrade ici dali firmware updater.png|thumb|ICI Firmware updater software with modified firmware loaded]]

there is a easier way using a modified Firmware updater to enable Telnet temporarily to patch the Files.

Download the '''upgrade_ici.exe''' form [https://archive.org/details/fwupdate here] and run it.

Then you should be able to connect to it via Telnet.

The Login credentials are '''User: roo'''t '''Password: DLroot'''

 

===Patching Device===

===Patching the Web Server===
 

====Enabling Telnet and ftpd permanently====

This only works if you also patch the Thermal Camera module flash!

to permanently enable Telnet, go to '''/etc/init.d''' and edit '''S90app'''
vi S90app
in vi, move your cursor to the '''#''' at '''#telnetd''' and press x<blockquote>optional: enable ftp by removing the '''#''' at '''ftpd''' and adjust the path to / </blockquote>now press ''':''' and type '''wq''' and hit '''enter'''. this should be it.

====Patching the decoder and streamer to 640x480:====
go to /app and edit the mach.cfg

replace DL384 with D640 and edit the resolution to 640 480

(press i in vi to enter edit mode, press ESC to exit edit mode. :wq to write and quit.)

repeat that procedure for the dali.cfg

=====(optional) patching app.sh to prevent it from rebooting=====
edit the app.sh in /app and remove all "reboot" occasions to prevent the camera from rebooting if onvifserver, httpd or daliServer arent running for debugging purposes.

 

====Patching the Thermal Camera module====
To patch it, you need to disassemble everything down to the FPGA Board,

on the bottom there is a SPI SOIC8 Flash.

Use a CH341 EEPROM programmer (be sure to have a fixed or modified version to not put out 5V!, set it to 3.3V) and SOIC8 clamp.

Use NeoProgrammer (i used 2.2.0.10 but there are newer available, use the latest) and click Detect. It should find W25Q128 chips, select the FV one.

Dont forget to download a backup of your flash and save it !

Download the Binary "Dali 640x480 '''actual''' cleared pixelmap.bin" from #3 below and load it into NeoProgrammer,

Click Erase, Program and Verify.

This can take a while.

Your imager should start up right after assembly by hearing the shutter click.

==Hardware Hacking==

===Flash Contents===
On archive, click on show all files to download them.

<nowiki>#</nowiki>1 a Flash dump of the original downgraded D8X3N can be found [https://archive.org/details/dali-d-843n-flash-dump here]

<nowiki>#</nowiki>2 a Flash dump of a original 640x480 model can be found [https://archive.org/details/d-843-n-640x-480 here]

<nowiki>#</nowiki>3 a modified Flash dump of a 640x480 with cleared dead pixel map, flat map etc. can be found [https://archive.org/details/d-843-n-640x-480-cleared-pixelmap here]

a Flash dump of the web server SPI flash W25Q256JV can be found [https://archive.org/details/dm-60-webserver-flash-dump here] in case a bad firmware update caused a bootloop.

 

===Flash Binary Analysis===
The Flash IC is a Winbond 25Q128JV SPI Flash that contains the FPGA Bitstream, Deadpixel and Flatmap, aswell as the Device Settings.

a copy of the SPI Logic Capture at startup can be found [https://archive.org/details/dali-eeprom-capture here], the free software [https://www.dreamsourcelab.com/download/ DSView from DreamSourceLab] is required to view it.
[[File:Dali Thermal Imager SPI Flash capture.png|thumb|SPI Flash access while booting the Thermal Module]]

a approximation of the offsets resulted in this list:<syntaxhighlight lang="vb">
0x000000 - altera cyclone iv stuff
0x200000 - settings
0x280000 - Flat field correction map
0x4C0000 - Bad Pixel correctio nmap
0x580000 - image aswell? 36010 bytes
0x740000 - GUIX?
0x7C0000 - Strings for Gui?
0x800000 - another shorter GUIX
0x880000 - Strings for second gui?
0x8C0000 - GUIX
0x940000 - Strings for gui
0xE00000 - ?
0xE80000 - dzxg? short
0xEC0000 - crosshair.bmp
0xF40000 - 3DTM?
0xF80000 - fake? Bad pixel map BPRP
</syntaxhighlight> 

====Settings offset 0x200000====
The settings are read and written every startup, aswell when you close the OSD, sporadically and when executing the command MSV

these are some of the settings i could figure out by changing and watching the logic capture what changed.
 <syntaxhighlight lang="vb">
offset size Cmd
0x0 1 SAG (0-2) auto gain
0x2 2 SVB (0-16383) saved value is 16383 - SVB
0x4 2 SVC (0-1023) set exposure or gain
0x6 1 SSM image filtering
0x8 1 SEH image enhancement
0xA 1 SWP invert b/w polarity
0x14 1 SMR Flip
0x16 1 SMR Mirror
0x20 1 MENU Cal source 0 IN, 1 OUT
0x3A 1 MENU Enhance value 0-100
0x40 1 MENU Rectify (shutter 0 OFF, 1 L, 2 H)
0x50 1 MENU Language 0 english, 1 chinese, 2 russian
0xA2 - SCO set contrast gain
0xA4 - IBR set brightness
0xAE 2 MENU Fire Threshold
0xAC 1 SPA set color palette
0xE2 1 SMS display "collected 0/80" enabled
0xF8 1 SEM set emissivity
0x110 1 SRT set revise temp
0x116 1 SHD set humidity
0x118 1 SET set ambient temp
0x11A 1 STD set temp range
0x120 2 SLG -500 to 500?
0x124 2 SRD set distance
0x12C 1 SCP ???
0x130 2 SCT ???
</syntaxhighlight> 
[[File:Dali D8X3N Bad Pixel Map Viewer.png|thumb|Bad pixel map of a 640x512 sensor, about 0.56% of dead pixels in this map]]
So i let the AI create a [https://2476424.playcode.io/ Configurator page] that lets you change the Settings in your Flashdump to your liking
 

====Bad Pixel and Flatframe Maps 0x280000 and 0x4C0000====
Thermal cameras require a bad pixel and flat frame map to compensate for manufacturing inconsistencies.

unfourtainly, the maps of the downgraded cameras only contain enough data for a 384 model, not the full 640.

at offset 0xF80000 there is a BPRP which was mistaken at first as the Bad pixel map, it could just be a mask to where to apply the offset maps, as its either 0x0 or 0x1.

The [https://2477569.playcode.io/ Viewer Page] is written in JS and does not require any special dependencies, it can run as a plain html file offline.

''See "Automatic Dead Pixels and Flatmap Correction" below how to create new dead pixel and flatmaps using the system menu.''

[[File:Dali D8X3N Flat Field Map Viewer.png|thumb|Flat Field viewer]]

==Dali Commands==
To control the TIM you can either use Pelco or Dali command set. By default the Dali commandset is used at 38400 BAUD.

Those commands consist of a 0x02 start byte followed by two length Bytes, then the actual command which is allways 3 uppercase Letters in ASCII (eg. KBD for keyboard) followed by a comma and the values.

Some commands take multiple values, some dont. But you allways have to send the comma after the Command.

The camera will answer with the Command and 0, 1 or 2. Sending no value counts as zero.
0 is invalid parameters, too few or out of range

1 is OK, valid command

2 is Invalid command

Commands can be sent trough the Web server using the URL Api endpoint or directly trough the UART port.

(keyboard, C button, causes the shutter to do a calibration)
<camera ip>/cgi-bin/dmcmd?Command=KBD,C
Listening to the answer can be done while being in the Linux shell and typing
cat /dev/ttyAMA2 | strings

By bruteforcing the UART with AAA to ZZZ a list of Commands could be obtained, but some with unknown Parameters or functionality yet. including some from a decompiled DM60comm.so module found in /app/modules folder.<syntaxhighlight lang="vb">
KBD KEY Keyboard (F S M C + -)
SSM 0-1 Image Filtering Off/On
GSM 0 Image filter status
SEH 0-1 Image Enhancement Off/On
GEH 0-1 Image enhancer status
SCO 0-255 Set Gain (locked when SAG auto gain is on)
GCO 0-255 Get gain
INT 15-320 set actual gain? not just contrast sometimes disabled?
IBR 0-255 Set brightness
GBR 0-255 Get brightness
SMR 0-3 Mirror mode bit0=horizontal, bit1=vertical
GMR 0 Get rotation/flip
SDT 0-1 displays temp=44.65°C osd, but webserver sends date/time to the cam there....
GDT 0-1 Get temp display active?
GPT Display temp oft SDT
GNU 0-1 Get Shutter closed/open
SNU 0-1 Shutter close / open
STD 0-1 Set Range 0: -20-180°C 1: 100-600°C
GTD 0-1 Get Range
SET °C Set Ambient temperature
GET °C Get Ambient temperature
SEM 0-100 0-1 set emissivity x100
GEM 0-100 Get Emissivity
SRT °C Set revise temperature -100-100 -10-10°
GRT °C Get revise temperature
SRD 100 Set Distance 4.4m x100
GRD 100 Get Distance
SHD 0-100 Set Humidity
GHD 55 Get Humidity
SWP 0-1 invert s/w polarity image
GWP 1 is inverted?
SPA 0-10? Set color palette
GPA 3 white hot
SMV 0-1 Show temperature 3x3 grid?? in combination with GTV maybe
GMV 0
SMS 0-1 displays "collected 0/<number set by SCT>" by SCP delay "saves the daily number of highest temperatures?"
GMS 0
SCT 1-500 sets the amount of "collected" points for SMS
GCT 80
SCP 5-60 "collected" delay in seconds for SMS
GCP 60
SAG 0-2 Auto brightness / gain
GAG 0
SLR 0-9 ???
GLR 0
SRP 0,0 - 639,479 set crosshair position
GRP 320,240 get crosshair position
DRC 0-1 Show crosshair
SLG -500-500 ??
GLG
SCE text ??
GCE 0
SCB text ??
GCB 0
SVB 0-16383 adc offset, exposure? good at 9650
GVB 6733 value is 16383 minus SVB
SVC 1-1023 set contrast but better
GVC 260
SVF 100-? ?? video freaks out 3400 seems good
SVS 100-? ?? video freaks out 3300 seems good
SOT 0-1 ?? sensor supply, looks weird when off.
SZM 1-4 ?
GZM 1
MSV save settings too eeprom
ASV Saves something aswell?
GCS 0 Get Core status & faults
ALD 0,2? video blanks lots of eeprom activity. reload pixel map??
SAV 0-9999 set Fire threshold
GAV 2100 get Fire Threshold
BAC change uart protocol? careful
CBD Displays Recovery successful?
CBS Displays Saved successfully
LRD Displays Recovery successful?
LRS Displays Saved successfully?
LRE Displays Temperature Repair successful?
CBT Displays Calibration successful?
DBP ??? shutter clicks
DPI Show weird pixels
API Hide weird pixels
CCM ??
ASN 0-4 ??
GAB 4 vals ?? 3,-10,50,150
GAN 1 ??
GAR 11 vals ?? 10,10,5,20,35,50,70,90,120,150,180,,
GCM 6 values ??
GFV prints screen gray value?
GIT 200 ??
GTV Get the collected temp values?
PTS echoes but with extra stuff??
QYA 7170 Query Gray Info (information mode)
QYI 7124 Query Gray Average mode
QYM 7512 Query Gray Minimum mode
VTP 400-4000 ??
MTD U/S,0,0 ?? S answers with bytes, U upload bytes?
MTC U/S? ?? S answers with U,0,0, S doesnt.

return 0 invalid params:
STS ??
STT ??
SAC ??
SAH ??
SAS ??
SAT ??
SCX ?? displays crosshair but invalid params
SCY ?? displays crosshair but invalid params
GAC ??
GAH ??
GAS ??
GAT ??
GME ??
GPC ??
GPI ??
GPM ??
GTA ??
GTC ??
GTI ??
GTM ??
GTS ??
GTT ??

answer only:

BPM 0-1 stream ready? answers with 0 stop, 1 go, 2 when prompted
AVS 0,1
MEH
PWI 0-1 changing palette from wh to fire

unconfirmed (from dm60comm.so):
SDT 2024,03,15,14,30,25 Set Date Time with year,month,day,hour,minute,second
STS 1 Set Temperature Show display (0=off, 1=on)
SVA 2 Set Video Auto mode (0=manual, 2=auto)
SMP 0,1,1,0,100,150,200,250,300,350,90,25 Set Measurement Point (type,index,enable,mode,startX,startY,endX,endY,anchorX,anchorY,threshold,color)
STV Stop Temperature View measurements
SPF 5 Set Profile parameter
SVL -10 Set Video Left pan movement (signed value)
SVU -5 Set Video Up tilt movement (signed value)
SVD 5 Set Video Down tilt movement (signed value)
SSP 17,1,0 Set System Parameter (param_id,value,index) #46 temperature format 0 °C, 1 °F, 2 K
SCP Set Current Preset (save current position)
GCP Get Current Preset
STT 300,350 Set Temperature Threshold (low,high values *10)
SDC 1 Set Display Configuration parameter
GCS Get Current Status
GMM Get Memory Map information
GFV Get Frame Value (grayscale data)
GFZ Get Freeze Status
GSI 1 Get System Information (parameter=1)
GSS Get System Status
GSP 21,0 Get System Parameter (param_21=surround temp, value=0)
GTT Get Temperature Threshold range
GTV 1,3,10 Get Temperature Values (enable,type,count)
GNU Get Network Update status (response command)
FRZ Freeze current display frame
LIV Live mode (unfreeze display)
CAL Calibrate system
CCP 3 Call Current Preset (preset number 0-9)
APF 100 Auto Profile setting
MEH Measure Enhancement
BPT Built-in Test
MTC S,0 Measure Temperature Capture (S=start, 0=sequence)
MTG U,0,1024,<data> Measure Temperature Gray data transfer
MTD U,0,1024,<data> Measure Temperature Data transfer
UFP S,0,2048 Update Firmware Prepare (S=start, 0=offset, 2048=size)
UFD S,0,1024 Update Firmware Data transfer
BAB U Buffer operation (U=update)
TTH S,0 Temperature Threshold operation
IPP 192.168.001.102,255.255.255.000,192.168.001.001,192.168.000.001,9989,9998 IP Parameters (IP,netmask,gateway,DNS,port1,port2)
MAC 00:60:A9:10:00:01 MAC Address setting
SNP Set Network Parameters (response command)
QYI Query Gray Info (information mode)
QYA Query Gray Average mode
QYM Query Gray Minimum mode
GAI Get Alarm Info (response command)
YTC <data> Unknown command with data parameter
HTH
LRS
LRD
GAR
DRC
PTS
SCX
SCY
CBT
LRE
CBD
CBS
XXX
GSP
GTT
QYI
QYA
QYM

</syntaxhighlight>

==Secret Menu Overview==
The secret menus Main and System can be openend with the password '''+-MC+-'''

Its structured like this, not all variables have been figured out yet.

The format is Menu: submenu: submenu:

and for menu entries: Name, default value, command, description or messages that pop up.
 <syntaxhighlight lang="vb">
MAIN & SYSTEM PASS: +-MC+-

entries are NAME VALUE COMMAND DESC or if its a folder its just ":"

System:
System:
Gain 255 SCO
Bright 102 IBR
BenDi 100 ?
BenDiContrase 80 ?
DisMode 0 ?
Frequency 48hz (24,25,48,50)
DigitalOut 8-14bit 14bit, BT656(_P), ?, BT601
AutoFocus N ?
Line 1 ?
Ltemp0 11800 ?
LTemp1 11000 ?
HTemp0 9500 ?
HTemp1 8700 ?
DelayTime 0 ?
Enhance 0-1 ?
Enhanced E1 230 ?
FPA_Gain 12pF ? between 4 and 18 at random.
NUCEn N ?

Area:
SE 2 ASN 0-4 "Partition"
INT 200 INT "Points time"
VS 3161 SVS
VF 2800 SVF
Vtemp 1401 VTP
VtempArea Low ?
VtempBase 13500 ?
VtempStep -1 ?
VsStep 8 ?
DeadPixelModel preset / calculate
DP: Cursor to select dead pixels
X 360 position
Y 288 position
AutoBP: 50 Press C to start automatic dotting
Quit? Number of bad pixels 961& "Blind element replacement in progress"
Undo
R2: Save data? blind pixel replacement in progress
Replace Y N = DPI, Y = API
L: Reading parameters
S: Saving parameters

Debug:
Rectify N
DisplayGary N
TE N SDT
AutoE ? ?
AutoVS Y ?
VSGrayH 8000 ?
VSGrayL 7000 ?
Trends 1 ?
Shelter N ?
MotorCon 3 ?
SaveFactoryPara:
LanTyp EN ? LANGUAGE
DisplayMT N ?
Version:
PRJ D843 DLD640 ImLib, MTlib, Soft, Logic

BackDispose:
GammaEN 1 ?
Gain 1 ?
EnhanceEN 0 ?
Hpf_shift 5 ?
Hpf_thrd 5 ?
Enhance 150 ?
Lthrd 50 ?

Monitor:
Opens normal OSD

Alarm Set:
Alarm Switch Y ?
Alarm Mode No ?
Alarm Temperature -1°C ?
Reference Gray Y ?
Alarm Level 1L ?
Alarm Gray 65535 ?
Alarm PointNum 0 ?
Correct Gray 0 ?

Thermometry:
Data Collection 0 SMS
Interval 60 SCP
Ammount 90 SCT
Environment normal ?
Export:
Displays: Exportin normal temperature MTC data
Correction -1 ?
Emissivity 100 SEM
Calibration:
BlackbodyTemp -10 grabs a val from GAB
Save CBS
Cancel CBD
Correction:
BlackbodyTemp -10 Picks from the list GAR
Grayscale 0 SLG
Confirm LRE
Save LRS
Cancel LRD
Ninepoint measurement SMV

Cursor:
Cur N DRC enable cursor
X 320 SRP set cursor position
Y 240 SRP set cursor position

Main:
Auto 2 SAG Auto gain
G 211 SVC
B 10002 SVB
P 1 SWP polarity
Z X ?
Settings:
Image:
FI Y ?
FIValue 0 ? 0-31
Freeze N Freeze image
VE N SMR Vertical flip
HO N SMR Horizontal flip
AutoCali L same as rectify?
O IN internal or external
COM:
Opens UART menu
AvoidburnSwitch OFF enable anti burn in
ProtectedTime 10S duration
AvoidBurn 16383 threshold to trigger antiburn

</syntaxhighlight>

===Automatic Dead Pixels and Flatmap Correction===

It it possible to generate a new flat and dead pixel map automatically within the camera after flashing the cleared-map binary.
 

=====Dead pixels:=====
In the secret menu "System", navigate to Area - DeadPixelModel and set the AutoBP (sensitivity for auto bad pixel finding) to 50 or so. Then press C Button

This can take a while.
[[File:High emissivity peltier black body.jpg|thumb|A Peltier / TEC coated in Candle sood to give it a high emissivity surface. It can be cooled or heated by swapping the polarity. ]]

Afterwards, navigate to S: and press + to save it.
 

=====Flatfield:=====
In the Debug menu navigate to R2 and press +

now place something '''Cold''' infront of the Camera with a high emissivity. (it needs to fill the whole image)

Press '''+''', wait for it to says High temperature.

Place something '''Hot''' infront and press '''+''' again.

Afterwards, save with '''S:''' again.

Flatfield should now be calibrated
 <blockquote>Note: Not all dead pixels are auto detected or get removed. you can manually select them in the Dead pixel editor but its not known yet how to select and correct them.</blockquote>

 

==Using the Thermal module without Webserver==
[[File:Dali D8X3C Breakout board.png|thumb|Breakout board for D8X3C ]]
to use it, you need to interface it directly.

The module will put out a Analog video signal (High-Z, need to buffer when connecting it to 75Ohm Video input)

Also a 8 or 14bit or 8-bit BT656 output.

the header exposes the FPGA JTAG and UART aswell as 6 Hardware Keys to Navigate the OSD.

To interface, you need to make a adapter board with a DF12-50DS-0.5V(86) Docking socket.

A breakout board is still a work in progress

 

==Sensor Pinout==
[[File:Dali DLD384 Sensor pinout basic.png|thumb|basic pinout of a DLD384]]
the pinout of the thermal sensor havent been analyzes much.

besides some supply and Control voltages, 3 clocks and a analog output have been found.

17.5MHz

14.705KHz

50Hz

Dali D8X3N Thermal Camera

2025-08-06T00:26:32Z

Gamerpaddy: breakout board setback

=Dali D8X3N Thermal Camera Reverse Engineering=
 

===Introduction===
The [https://www.dali-irtech.com/productinfo/741567.html Dali D8X3N] Thermal Camera module comes in two versions, a 384x288 and 640x480 resolution, utilizing the [http://www.dali-tech.us/products/dld64017m-uncooled-infrared-fpa-detector-86.html DLD Series] of amorphous-Silicon Microbolometers.

They were mainly used in [http://www.dali-tech.us/products/dm60-w--online-body-temperature-thermal-imaging-camera-55.html Dali DM60-W] or WS-1 Body Temperature screening cameras in conjunction with a Black Body radiator set to 37°C to detect infected individuals at the start of the 2020 Covid Pandemic.
[[File:ICI FM320P Innerts.jpg|thumb|Internals. A TP-Link Switch, HikVision Visible Camera and the D8x3N Network thermal camera module]]
[https://infraredcameras.com/ ICI] rebranded these models as FM 320 P and FM 640 P, and distributed them on the local US market, but as the need for such Cameras exploded, those models were built with what was in stock.

So happens, that some of the FM 320 P Models had a DLD640 640x480 instead of a DLD384 384x288 Microbolometer in them, and just got their Firmware modified.

It also could be, because they have excessive amounts of bad pixels outside the 384x288 area, that they were binned to a lower grade.

Discussions about these Cameras started around 2022 in the [https://www.eevblog.com/forum/thermal-imaging/ici-and-dali-thermal-camera-software/ EEVBlog Forums.] when they started to appear secondhand and affordable.

Originally they were priced around US$ 20... 30.000 by ICI, and a unknown amount by Dali Tech.

The Modules specs according to the manufacturer are:

≤50..60mK@F1，300K，50Hz

17 or 25µm pixel pitch

Hisilicon SoC running Linux to provide Onvif and RTSP streams, analysis and a Web UI

 
[[File:Dali D8X3N Module.jpg|thumb|A real 384x288 model with a DLD384 sensor. notice the Productnumber ]]
ICI FM Cameras are found all over Online secondhand marketplaces for scrap Prices, as they are no longer needed.

But you never know, what are you getting. It could be a real DLD384 or the better DLD640 inside. Its a gamble.
 

======640x480 Imagers======
are labeled 22D843 Nxxxx and have a DLD640 sensor in it, they can be upgraded if they run the 384x288 firmware.

======384x288 Imagers======
are labeled 22D883Nxxxx and have a DLD384 sensor in it, they cannot be upgraded

 

==D8X3N Module closer look==
From now on, i will refer to the Thermal Imaging Module as TIM

On the front there is a 2 Element Germanium Lens of a unknown focal length and aperture.

It can be focus-adjusted when unscrewing the clamp around the housing. It can be focussed from infinity down to 10..20cm with some quality loss.
 The outter diameter of the Lens is 42mm with a 1 1/3 inch thread diameter of undetermined pitch.

Dimensions of the germanium elements are 21mm to 3 and 6mm and 14grams in weight.
[[File:Disassembled Thermal Camera Lens.jpg|thumb|Two element Germanium Lens of unknown focal length and aperture]]

The TIM is composed of 6 Stacked PCB modules, 3 of which are for the Web Server functionality. taking them off will give you the basic configuration of a [https://www.dalithermal.com/productinfo/741568.html Dali D8X3C] TIM<gallery>
File:Dali DLD640 Thermal Image Sensor.jpeg|DLD640 Sensor
File:Dali DLD384 Thermal Imaging Sensor.jpeg|DLD384 Sensor
File:Dali D8X3N Board1 Back.jpeg|Network & GPIO Board Back
File:Dali D8X3N Board1 Front.jpeg|Network & GPIO Board Front
File:Dali D8X3N Glue Board Back.jpeg|Board between Logic and IO Back
File:Dali D8X3N Glue Board Front.jpeg|Board between Logic and IO Front
File:Dali D8X3N SoC Board Back.jpeg|SoC Board back
File:Dali D8X3N SoC Board front.jpeg|SoC board front
File:Dali D8X3N FPGA Board Back.jpeg|FPGA Board of the D8X3C Thermal Imager including a PMIC
File:Dali D8X3N FPGA Board Front.jpeg|FPGA Board Front with Video DAC and SPI Flash
File:Dali D8X3N Sensor Power and ADC Board.jpeg|Sensor control and ADC board
File:Dali D8X3N Thermal Core Debug wiring.jpeg|Debug wiring for sniffing SPI and UART
</gallery>

===User Manual===
including pinout diagram and important data

can be found here https://archive.org/details/dali-d-8-x-3-cuser-manualen-v-1.0-1

==Viewing the Video Stream==
[[File:Onvif Device Manager ODM.png|thumb|ODM streaming the Thermal view]]
when first connecting it to power and Ethernet, the camera will have 192.168.1.102 as a Static ip.

If you are running a 192.168.0.x or .178.x net, you need to change it or add a subnet under windows ipv4 settings.

to view it, you can use VLC and the stream URL
rtsp://admin@admin:<camera ip>/ONVIFMedia
there is /ONVIFMedia /ONVIFMediaM and /ONVIFMediaS for different stream Profiles.

VLC is quite slow and delayed, rather use Onvif Device Manager ODM,

it has no delay and auto-detects cameras in the network.

Be sure to log in as user: admin pass: admin in ODM.

in there, you can also set you camera to DHCP under Network settings.

===Web Interface===
[[File:Dali D8X3N web interface.png|thumb|Since browsers cant display RTSP anymore, open in Edge and select IE Compatibility Mode.]]
the web interface can be accessed by opening the camera IP in a browser

login is:
user: admin pass: admin
You can set Temperature markers and areas, but without using the Black Body calibration source, your readings may be way off or not working.

 

====OSD====
there is a debug-login with
user: super pass: 871897
that lets you send Key commands to the Imager to navigate the OSD.

Setting the OSD to english is accomplished with option #11
[[File:Dali D8X3C OSD.png|thumb|OSD in english, if yours is Chinese. go to option #11 and click + or -]]

To acces some locked menus, press
+ - + - + -

The password for the locked System and Main menu is
+-MC+-

Be careful in the UART menu to not change the BAUD rate or Protocol, as your ability to control it via the Web API gets lost.

You need to reflash or solder buttons on the thermal core then.

==Viewing Raw Thermal Data from the Web API==
there is a hidden endpoint in the stream.so file that could be found while decompiling

accessing
[[File:Arduino Nano blink sketch thermal gif.gif|thumb|Arduino Nano running blink sketch while thermally recording it, notice the led and resistor on the right]]
<ip of camera>:5000/stream?Type=JPEG&Source=Jpeg&Mode=TCP
lets you download a JPEG. but there are more options available (not all have been tested)

we are mainly interessted in Raw thermal data.

====Source (Stream Type)====

*<code>Major</code> - Main video stream (channel 0)
*<code>Minor</code> - Sub video stream (channel 1)
*<code>MinorAV</code> - Sub video + audio stream
*<code>MajorAV</code> - Main video + audio stream
*<code>Jpeg</code> - JPEG snapshot stream
*<code>Raw</code> - Raw thermal data stream
*<code>YUV</code> - YUV raw video stream

====Type (Data Format)====

*<code>H264</code> - H.264 video encoding
*<code>JPEG</code> - JPEG image format
*<code>RAW</code> - Raw sensor data
*<code>QBOX</code> - Custom protocol format
*<code>FRAME</code> - Frame-based format

====Mode (Transport Protocol)====

*<code>TCP</code> - TCP streaming (default)
*<code>UDP</code> - UDP streaming
*<code>MUL</code> - Multicast streaming

====Quality Parameters====

*<code>Quality=[1-100]</code> - Video quality level
*<code>Frames=[number]</code> - Number of frames to send
*<code>Interval=[ms]</code> - Frame interval in milliseconds

====Network Parameters====

*<code>IPAddr=[ip]</code> - Client IP address for UDP/multicast
*<code>Port=[port]</code> - Client port for UDP/multicast
*<code>Heart-beat=[Yes/No]</code> - Enable/disable heartbeat

====Snapshot Parameters====

*<code>Snap=[Yes/No]</code> - Enable snapshot mode

 
====Raw Viewer for PC (Python)====
[[File:Dali D8X3N Raw Thermal viewer.png|thumb|Raw Data Viewer in python]]

To view the raw stream, i made a python program that converts the 14bit thermal data to a visible image.

it is low fps tho, due to bad optimizations.

rev1 first working version https://pastebin.com/dyNWDPT3

rev2 with temperature readout https://pastebin.com/u107Q85w

rev3 and onward will only be available directly as a Webpage on the Device (see below).

====Raw Viewer for the internal Webserver (recommended)====
It is also possible to use the Raw viewer directly in the browser.

To achieve this, the stream had to be proxied from port 5000 to 80 due to CORS.

luckily the internal lighttpd had the CGI module enabled, so piping it troug (using wget ... i know) worked with very low overhead.

To install, you need '''Terminal access''' to the Camera. see below.

optional for simplicity: '''ftp''' access

[[File:Dali D8X3N Webviewer.png|thumb|Web Raw Viewer with histogram (rev3)]]

Create the files and the code inside.

'''/app/web/webpages/raw.html''' https://pastebin.com/kaiXwAgD

and

'''/app/web/webpages/cgi-bin/proxy.cgi''' https://pastebin.com/vii1HXcU

then run
chmod +x /app/web/webpages/cgi-bin/proxy.cgi
'''restart''' your camera.

It should be accessible now trough '''http://<camera ip>/raw.html''' in the browser and click Start Stream

'''NOTE''': ''If it does not work'', check the contents of both files. FTP sometimes messes them up.

also run
dos2unix /app/web/webpages/cgi-bin/proxy.cgi
because linux <> windows difficulties that couldnt be resolved in over 30 years.

<blockquote>

performance may need improvement.</blockquote>

==Getting Root Terminal Access==
To access the Terminal you need to solder or plug in a UART connection to Connector J7 on the "Glue" board.

Pinout is (left to right) '''RX TX GND 3.3V Baud 115200 3.3V!'''

But the system will spam with debug messages, making patching the files a hard job unless you use "tftp" or "sed" commands.
 

====Enabling Telnet access to make patching easier====
[[File:Upgrade ici dali firmware updater.png|thumb|ICI Firmware updater software with modified firmware loaded]]

there is a easier way using a modified Firmware updater to enable Telnet temporarily to patch the Files.

Download the '''upgrade_ici.exe''' form [https://archive.org/details/fwupdate here] and run it.

Then you should be able to connect to it via Telnet.

The Login credentials are '''User: roo'''t '''Password: DLroot'''

 

===Patching Device===

===Patching the Web Server===
 

====Enabling Telnet and ftpd permanently====

This only works if you also patch the Thermal Camera module flash!

to permanently enable Telnet, go to '''/etc/init.d''' and edit '''S90app'''
vi S90app
in vi, move your cursor to the '''#''' at '''#telnetd''' and press x<blockquote>optional: enable ftp by removing the '''#''' at '''ftpd''' and adjust the path to / </blockquote>now press ''':''' and type '''wq''' and hit '''enter'''. this should be it.

====Patching the decoder and streamer to 640x480:====
go to /app and edit the mach.cfg

replace DL384 with D640 and edit the resolution to 640 480

(press i in vi to enter edit mode, press ESC to exit edit mode. :wq to write and quit.)

repeat that procedure for the dali.cfg

=====(optional) patching app.sh to prevent it from rebooting=====
edit the app.sh in /app and remove all "reboot" occasions to prevent the camera from rebooting if onvifserver, httpd or daliServer arent running for debugging purposes.

 

====Patching the Thermal Camera module====
To patch it, you need to disassemble everything down to the FPGA Board,

on the bottom there is a SPI SOIC8 Flash.

Use a CH341 EEPROM programmer (be sure to have a fixed or modified version to not put out 5V!, set it to 3.3V) and SOIC8 clamp.

Use NeoProgrammer (i used 2.2.0.10 but there are newer available, use the latest) and click Detect. It should find W25Q128 chips, select the FV one.

Dont forget to download a backup of your flash and save it !

Download the Binary "Dali 640x480 '''actual''' cleared pixelmap.bin" from #3 below and load it into NeoProgrammer,

Click Erase, Program and Verify.

This can take a while.

Your imager should start up right after assembly by hearing the shutter click.

==Hardware Hacking==

===Flash Contents===
On archive, click on show all files to download them.

<nowiki>#</nowiki>1 a Flash dump of the original downgraded D8X3N can be found [https://archive.org/details/dali-d-843n-flash-dump here]

<nowiki>#</nowiki>2 a Flash dump of a original 640x480 model can be found [https://archive.org/details/d-843-n-640x-480 here]

<nowiki>#</nowiki>3 a modified Flash dump of a 640x480 with cleared dead pixel map, flat map etc. can be found [https://archive.org/details/d-843-n-640x-480-cleared-pixelmap here]

a Flash dump of the web server SPI flash W25Q256JV can be found [https://archive.org/details/dm-60-webserver-flash-dump here] in case a bad firmware update caused a bootloop.

 

===Flash Binary Analysis===
The Flash IC is a Winbond 25Q128JV SPI Flash that contains the FPGA Bitstream, Deadpixel and Flatmap, aswell as the Device Settings.

a copy of the SPI Logic Capture at startup can be found [https://archive.org/details/dali-eeprom-capture here], the free software [https://www.dreamsourcelab.com/download/ DSView from DreamSourceLab] is required to view it.
[[File:Dali Thermal Imager SPI Flash capture.png|thumb|SPI Flash access while booting the Thermal Module]]

a approximation of the offsets resulted in this list:<syntaxhighlight lang="vb">
0x000000 - altera cyclone iv stuff
0x200000 - settings
0x280000 - Flat field correction map
0x4C0000 - Bad Pixel correctio nmap
0x580000 - image aswell? 36010 bytes
0x740000 - GUIX?
0x7C0000 - Strings for Gui?
0x800000 - another shorter GUIX
0x880000 - Strings for second gui?
0x8C0000 - GUIX
0x940000 - Strings for gui
0xE00000 - ?
0xE80000 - dzxg? short
0xEC0000 - crosshair.bmp
0xF40000 - 3DTM?
0xF80000 - fake? Bad pixel map BPRP
</syntaxhighlight> 

====Settings offset 0x200000====
The settings are read and written every startup, aswell when you close the OSD, sporadically and when executing the command MSV

these are some of the settings i could figure out by changing and watching the logic capture what changed.
 <syntaxhighlight lang="vb">
offset size Cmd
0x0 1 SAG (0-2) auto gain
0x2 2 SVB (0-16383) saved value is 16383 - SVB
0x4 2 SVC (0-1023) set exposure or gain
0x6 1 SSM image filtering
0x8 1 SEH image enhancement
0xA 1 SWP invert b/w polarity
0x14 1 SMR Flip
0x16 1 SMR Mirror
0x20 1 MENU Cal source 0 IN, 1 OUT
0x3A 1 MENU Enhance value 0-100
0x40 1 MENU Rectify (shutter 0 OFF, 1 L, 2 H)
0x50 1 MENU Language 0 english, 1 chinese, 2 russian
0xA2 - SCO set contrast gain
0xA4 - IBR set brightness
0xAE 2 MENU Fire Threshold
0xAC 1 SPA set color palette
0xE2 1 SMS display "collected 0/80" enabled
0xF8 1 SEM set emissivity
0x110 1 SRT set revise temp
0x116 1 SHD set humidity
0x118 1 SET set ambient temp
0x11A 1 STD set temp range
0x120 2 SLG -500 to 500?
0x124 2 SRD set distance
0x12C 1 SCP ???
0x130 2 SCT ???
</syntaxhighlight> 
[[File:Dali D8X3N Bad Pixel Map Viewer.png|thumb|Bad pixel map of a 640x512 sensor, about 0.56% of dead pixels in this map]]
So i let the AI create a [https://2476424.playcode.io/ Configurator page] that lets you change the Settings in your Flashdump to your liking
 

====Bad Pixel and Flatframe Maps 0x280000 and 0x4C0000====
Thermal cameras require a bad pixel and flat frame map to compensate for manufacturing inconsistencies.

unfourtainly, the maps of the downgraded cameras only contain enough data for a 384 model, not the full 640.

at offset 0xF80000 there is a BPRP which was mistaken at first as the Bad pixel map, it could just be a mask to where to apply the offset maps, as its either 0x0 or 0x1.

The [https://2477569.playcode.io/ Viewer Page] is written in JS and does not require any special dependencies, it can run as a plain html file offline.

There still needs to be work done to create own maps and flatfields but the cameras are still very capable and useable with fully cleared maps.

To clear the maps, just go to these offsets and fill with values around 0x3F or 0x0 for total length of X Resolution x Y Resolution x 2 bytes (0x96000 for 640x480)

[[File:Dali D8X3N Flat Field Map Viewer.png|thumb|Flat Field viewer]]

==Dali Commands==
To control the TIM you can either use Pelco or Dali command set. By default the Dali commandset is used at 38400 BAUD.

Those commands consist of a 0x02 start byte followed by two length Bytes, then the actual command which is allways 3 uppercase Letters in ASCII (eg. KBD for keyboard) followed by a comma and the values.

Some commands take multiple values, some dont. But you allways have to send the comma after the Command.

The camera will answer with the Command and 0, 1 or 2. Sending no value counts as zero.
0 is invalid parameters, too few or out of range

1 is OK, valid command

2 is Invalid command

Commands can be sent trough the Web server using the URL Api endpoint or directly trough the UART port.

(keyboard, C button, causes the shutter to do a calibration)
<camera ip>/cgi-bin/dmcmd?Command=KBD,C
Listening to the answer can be done while being in the Linux shell and typing
cat /dev/ttyAMA2 | strings

By bruteforcing the UART with AAA to ZZZ a list of Commands could be obtained, but some with unknown Parameters or functionality yet. including some from a decompiled DM60comm.so module found in /app/modules folder.<syntaxhighlight lang="vb">
KBD KEY Keyboard (F S M C + -)
SSM 0-1 Image Filtering Off/On
GSM 0 Image filter status
SEH 0-1 Image Enhancement Off/On
GEH 0-1 Image enhancer status
SCO 0-255 Set Gain (locked when SAG auto gain is on)
GCO 0-255 Get gain
INT 15-320 set actual gain? not just contrast sometimes disabled?
IBR 0-255 Set brightness
GBR 0-255 Get brightness
SMR 0-3 Mirror mode bit0=horizontal, bit1=vertical
GMR 0 Get rotation/flip
SDT 0-1 displays temp=44.65°C osd, but webserver sends date/time to the cam there....
GDT 0-1 Get temp display active?
GPT Display temp oft SDT
GNU 0-1 Get Shutter closed/open
SNU 0-1 Shutter close / open
STD 0-1 Set Range 0: -20-180°C 1: 100-600°C
GTD 0-1 Get Range
SET °C Set Ambient temperature
GET °C Get Ambient temperature
SEM 0-100 0-1 set emissivity x100
GEM 0-100 Get Emissivity
SRT °C Set revise temperature -100-100 -10-10°
GRT °C Get revise temperature
SRD 100 Set Distance 4.4m x100
GRD 100 Get Distance
SHD 0-100 Set Humidity
GHD 55 Get Humidity
SWP 0-1 invert s/w polarity image
GWP 1 is inverted?
SPA 0-10? Set color palette
GPA 3 white hot
SMV 0-1 Show temperature 3x3 grid?? in combination with GTV maybe
GMV 0
SMS 0-1 displays "collected 0/<number set by SCT>" by SCP delay "saves the daily number of highest temperatures?"
GMS 0
SCT 1-500 sets the amount of "collected" points for SMS
GCT 80
SCP 5-60 "collected" delay in seconds for SMS
GCP 60
SAG 0-2 Auto brightness / gain
GAG 0
SLR 0-9 ???
GLR 0
SRP 0,0 - 639,479 set crosshair position
GRP 320,240 get crosshair position
DRC 0-1 Show crosshair
SLG -500-500 ??
GLG
SCE text ??
GCE 0
SCB text ??
GCB 0
SVB 0-16383 adc offset, exposure? good at 9650
GVB 6733 value is 16383 minus SVB
SVC 1-1023 set contrast but better
GVC 260
SVF 100-? ?? video freaks out 3400 seems good
SVS 100-? ?? video freaks out 3300 seems good
SOT 0-1 ?? sensor supply, looks weird when off.
SZM 1-4 ?
GZM 1
MSV save settings too eeprom
ASV Saves something aswell?
GCS 0 Get Core status & faults
ALD 0,2? video blanks lots of eeprom activity. reload pixel map??
SAV 0-9999 set Fire threshold
GAV 2100 get Fire Threshold
BAC change uart protocol? careful
CBD Displays Recovery successful?
CBS Displays Saved successfully
LRD Displays Recovery successful?
LRS Displays Saved successfully?
LRE Displays Temperature Repair successful?
CBT Displays Calibration successful?
DBP ??? shutter clicks
DPI Show weird pixels
API Hide weird pixels
CCM ??
ASN 0-4 ??
GAB 4 vals ?? 3,-10,50,150
GAN 1 ??
GAR 11 vals ?? 10,10,5,20,35,50,70,90,120,150,180,,
GCM 6 values ??
GFV prints screen gray value?
GIT 200 ??
GTV Get the collected temp values?
PTS echoes but with extra stuff??
QYA 7170 Query Gray Info (information mode)
QYI 7124 Query Gray Average mode
QYM 7512 Query Gray Minimum mode
VTP 400-4000 ??
MTD U/S,0,0 ?? S answers with bytes, U upload bytes?
MTC U/S? ?? S answers with U,0,0, S doesnt.

return 0 invalid params:
STS ??
STT ??
SAC ??
SAH ??
SAS ??
SAT ??
SCX ?? displays crosshair but invalid params
SCY ?? displays crosshair but invalid params
GAC ??
GAH ??
GAS ??
GAT ??
GME ??
GPC ??
GPI ??
GPM ??
GTA ??
GTC ??
GTI ??
GTM ??
GTS ??
GTT ??

answer only:

BPM 0-1 stream ready? answers with 0 stop, 1 go, 2 when prompted
AVS 0,1
MEH
PWI 0-1 changing palette from wh to fire

unconfirmed (from dm60comm.so):
SDT 2024,03,15,14,30,25 Set Date Time with year,month,day,hour,minute,second
STS 1 Set Temperature Show display (0=off, 1=on)
SVA 2 Set Video Auto mode (0=manual, 2=auto)
SMP 0,1,1,0,100,150,200,250,300,350,90,25 Set Measurement Point (type,index,enable,mode,startX,startY,endX,endY,anchorX,anchorY,threshold,color)
STV Stop Temperature View measurements
SPF 5 Set Profile parameter
SVL -10 Set Video Left pan movement (signed value)
SVU -5 Set Video Up tilt movement (signed value)
SVD 5 Set Video Down tilt movement (signed value)
SSP 17,1,0 Set System Parameter (param_id,value,index) #46 temperature format 0 °C, 1 °F, 2 K
SCP Set Current Preset (save current position)
GCP Get Current Preset
STT 300,350 Set Temperature Threshold (low,high values *10)
SDC 1 Set Display Configuration parameter
GCS Get Current Status
GMM Get Memory Map information
GFV Get Frame Value (grayscale data)
GFZ Get Freeze Status
GSI 1 Get System Information (parameter=1)
GSS Get System Status
GSP 21,0 Get System Parameter (param_21=surround temp, value=0)
GTT Get Temperature Threshold range
GTV 1,3,10 Get Temperature Values (enable,type,count)
GNU Get Network Update status (response command)
FRZ Freeze current display frame
LIV Live mode (unfreeze display)
CAL Calibrate system
CCP 3 Call Current Preset (preset number 0-9)
APF 100 Auto Profile setting
MEH Measure Enhancement
BPT Built-in Test
MTC S,0 Measure Temperature Capture (S=start, 0=sequence)
MTG U,0,1024,<data> Measure Temperature Gray data transfer
MTD U,0,1024,<data> Measure Temperature Data transfer
UFP S,0,2048 Update Firmware Prepare (S=start, 0=offset, 2048=size)
UFD S,0,1024 Update Firmware Data transfer
BAB U Buffer operation (U=update)
TTH S,0 Temperature Threshold operation
IPP 192.168.001.102,255.255.255.000,192.168.001.001,192.168.000.001,9989,9998 IP Parameters (IP,netmask,gateway,DNS,port1,port2)
MAC 00:60:A9:10:00:01 MAC Address setting
SNP Set Network Parameters (response command)
QYI Query Gray Info (information mode)
QYA Query Gray Average mode
QYM Query Gray Minimum mode
GAI Get Alarm Info (response command)
YTC <data> Unknown command with data parameter
HTH
LRS
LRD
GAR
DRC
PTS
SCX
SCY
CBT
LRE
CBD
CBS
XXX
GSP
GTT
QYI
QYA
QYM

</syntaxhighlight>

==Secret Menu Overview==
The secret menus Main and System can be openend with the password '''+-MC+-'''

Its structured like this, not all variables have been figured out yet.

The format is Menu: submenu: submenu:

and for menu entries: Name, default value, command, description or messages that pop up.
 <syntaxhighlight lang="vb">
MAIN & SYSTEM PASS: +-MC+-

entries are NAME VALUE COMMAND DESC or if its a folder its just ":"

System:
System:
Gain 255 SCO
Bright 102 IBR
BenDi 100 ?
BenDiContrase 80 ?
DisMode 0 ?
Frequency 48hz (24,25,48,50)
DigitalOut 8-14bit 14bit, BT656(_P), ?, BT601
AutoFocus N ?
Line 1 ?
Ltemp0 11800 ?
LTemp1 11000 ?
HTemp0 9500 ?
HTemp1 8700 ?
DelayTime 0 ?
Enhance 0-1 ?
Enhanced E1 230 ?
FPA_Gain 12pF ? between 4 and 18 at random.
NUCEn N ?

Area:
SE 2 ASN 0-4 "Partition"
INT 200 INT "Points time"
VS 3161 SVS
VF 2800 SVF
Vtemp 1401 VTP
VtempArea Low ?
VtempBase 13500 ?
VtempStep -1 ?
VsStep 8 ?
DeadPixelModel preset / calculate
DP: Cursor to select dead pixels
X 360 position
Y 288 position
AutoBP: 50 Press C to start automatic dotting
Quit? Number of bad pixels 961& "Blind element replacement in progress"
Undo
R2: Save data? blind pixel replacement in progress
Replace Y N = DPI, Y = API
L: Reading parameters
S: Saving parameters

Debug:
Rectify N
DisplayGary N
TE N SDT
AutoE ? ?
AutoVS Y ?
VSGrayH 8000 ?
VSGrayL 7000 ?
Trends 1 ?
Shelter N ?
MotorCon 3 ?
SaveFactoryPara:
LanTyp EN ? LANGUAGE
DisplayMT N ?
Version:
PRJ D843 DLD640 ImLib, MTlib, Soft, Logic

BackDispose:
GammaEN 1 ?
Gain 1 ?
EnhanceEN 0 ?
Hpf_shift 5 ?
Hpf_thrd 5 ?
Enhance 150 ?
Lthrd 50 ?

Monitor:
Opens normal OSD

Alarm Set:
Alarm Switch Y ?
Alarm Mode No ?
Alarm Temperature -1°C ?
Reference Gray Y ?
Alarm Level 1L ?
Alarm Gray 65535 ?
Alarm PointNum 0 ?
Correct Gray 0 ?

Thermometry:
Data Collection 0 SMS
Interval 60 SCP
Ammount 90 SCT
Environment normal ?
Export:
Displays: Exportin normal temperature MTC data
Correction -1 ?
Emissivity 100 SEM
Calibration:
BlackbodyTemp -10 grabs a val from GAB
Save CBS
Cancel CBD
Correction:
BlackbodyTemp -10 Picks from the list GAR
Grayscale 0 SLG
Confirm LRE
Save LRS
Cancel LRD
Ninepoint measurement SMV

Cursor:
Cur N DRC enable cursor
X 320 SRP set cursor position
Y 240 SRP set cursor position

Main:
Auto 2 SAG Auto gain
G 211 SVC
B 10002 SVB
P 1 SWP polarity
Z X ?
Settings:
Image:
FI Y ?
FIValue 0 ? 0-31
Freeze N Freeze image
VE N SMR Vertical flip
HO N SMR Horizontal flip
AutoCali L same as rectify?
O IN internal or external
COM:
Opens UART menu
AvoidburnSwitch OFF enable anti burn in
ProtectedTime 10S duration
AvoidBurn 16383 threshold to trigger antiburn

</syntaxhighlight>

===Automatic Dead Pixels and Flatmap Correction===

It it possible to generate a new flat and dead pixel map automatically within the camera after flashing the cleared-map binary.
 

=====Dead pixels:=====
In the secret menu "System", navigate to Area - DeadPixelModel and set the AutoBP (sensitivity for auto bad pixel finding) to 50 or so. Then press C Button

This can take a while.
[[File:High emissivity peltier black body.jpg|thumb|A Peltier / TEC coated in Candle sood to give it a high emissivity surface. It can be cooled or heated by swapping the polarity. ]]

Afterwards, navigate to S: and press + to save it.
 

=====Flatfield:=====
In the Debug menu navigate to R2 and press +

now place something '''Cold''' infront of the Camera with a high emissivity. (it needs to fill the whole image)

Press '''+''', wait for it to says High temperature.

Place something '''Hot''' infront and press '''+''' again.

Afterwards, save with '''S:''' again.

Flatfield should now be calibrated
 <blockquote>Note: Not all dead pixels are auto detected or get removed. you can manually select them in the Dead pixel editor but its not known yet how to select and correct them.</blockquote>

 

==Using the Thermal module without Webserver==
[[File:Dali D8X3C Breakout board.png|thumb|Breakout board for D8X3C ]]
to use it, you need to interface it directly.

The module will put out a Analog video signal (High-Z, need to buffer when connecting it to 75Ohm Video input)

Also a 8 or 14bit or 8-bit BT656 output.

the header exposes the FPGA JTAG and UART aswell as 6 Hardware Keys to Navigate the OSD.

To interface, you need to make a adapter board with a DF12-50DS-0.5V(86) Docking socket.

A breakout board is still a work in progress

 

==Sensor Pinout==
[[File:Dali DLD384 Sensor pinout basic.png|thumb|basic pinout of a DLD384]]
the pinout of the thermal sensor havent been analyzes much.

besides some supply and Control voltages, 3 clocks and a analog output have been found.

17.5MHz

14.705KHz

50Hz

Dali D8X3N Thermal Camera

2025-08-04T18:00:06Z

Gamerpaddy: /* Raw Viewer for the internal Webserver (recommended) */

=Dali D8X3N Thermal Camera Reverse Engineering=
 

===Introduction===
The [https://www.dali-irtech.com/productinfo/741567.html Dali D8X3N] Thermal Camera module comes in two versions, a 384x288 and 640x480 resolution, utilizing the [http://www.dali-tech.us/products/dld64017m-uncooled-infrared-fpa-detector-86.html DLD Series] of amorphous-Silicon Microbolometers.

They were mainly used in [http://www.dali-tech.us/products/dm60-w--online-body-temperature-thermal-imaging-camera-55.html Dali DM60-W] or WS-1 Body Temperature screening cameras in conjunction with a Black Body radiator set to 37°C to detect infected individuals at the start of the 2020 Covid Pandemic.
[[File:ICI FM320P Innerts.jpg|thumb|Internals. A TP-Link Switch, HikVision Visible Camera and the D8x3N Network thermal camera module]]
[https://infraredcameras.com/ ICI] rebranded these models as FM 320 P and FM 640 P, and distributed them on the local US market, but as the need for such Cameras exploded, those models were built with what was in stock.

So happens, that some of the FM 320 P Models had a DLD640 640x480 instead of a DLD384 384x288 Microbolometer in them, and just got their Firmware modified.

It also could be, because they have excessive amounts of bad pixels outside the 384x288 area, that they were binned to a lower grade.

Discussions about these Cameras started around 2022 in the [https://www.eevblog.com/forum/thermal-imaging/ici-and-dali-thermal-camera-software/ EEVBlog Forums.] when they started to appear secondhand and affordable.

Originally they were priced around US$ 20... 30.000 by ICI, and a unknown amount by Dali Tech.

The Modules specs according to the manufacturer are:

≤50..60mK@F1，300K，50Hz

17 or 25µm pixel pitch

Hisilicon SoC running Linux to provide Onvif and RTSP streams, analysis and a Web UI

 
[[File:Dali D8X3N Module.jpg|thumb|A real 384x288 model with a DLD384 sensor. notice the Productnumber ]]
ICI FM Cameras are found all over Online secondhand marketplaces for scrap Prices, as they are no longer needed.

But you never know, what are you getting. It could be a real DLD384 or the better DLD640 inside. Its a gamble.
 

======640x480 Imagers======
are labeled 22D843 Nxxxx and have a DLD640 sensor in it, they can be upgraded if they run the 384x288 firmware.

======384x288 Imagers======
are labeled 22D883Nxxxx and have a DLD384 sensor in it, they cannot be upgraded

 

==D8X3N Module closer look==
From now on, i will refer to the Thermal Imaging Module as TIM

On the front there is a 2 Element Germanium Lens of a unknown focal length and aperture.

It can be focus-adjusted when unscrewing the clamp around the housing. It can be focussed from infinity down to 10..20cm with some quality loss.
 The outter diameter of the Lens is 42mm with a 1 1/3 inch thread diameter of undetermined pitch.

Dimensions of the germanium elements are 21mm to 3 and 6mm and 14grams in weight.
[[File:Disassembled Thermal Camera Lens.jpg|thumb|Two element Germanium Lens of unknown focal length and aperture]]

The TIM is composed of 6 Stacked PCB modules, 3 of which are for the Web Server functionality. taking them off will give you the basic configuration of a [https://www.dalithermal.com/productinfo/741568.html Dali D8X3C] TIM<gallery>
File:Dali DLD640 Thermal Image Sensor.jpeg|DLD640 Sensor
File:Dali DLD384 Thermal Imaging Sensor.jpeg|DLD384 Sensor
File:Dali D8X3N Board1 Back.jpeg|Network & GPIO Board Back
File:Dali D8X3N Board1 Front.jpeg|Network & GPIO Board Front
File:Dali D8X3N Glue Board Back.jpeg|Board between Logic and IO Back
File:Dali D8X3N Glue Board Front.jpeg|Board between Logic and IO Front
File:Dali D8X3N SoC Board Back.jpeg|SoC Board back
File:Dali D8X3N SoC Board front.jpeg|SoC board front
File:Dali D8X3N FPGA Board Back.jpeg|FPGA Board of the D8X3C Thermal Imager including a PMIC
File:Dali D8X3N FPGA Board Front.jpeg|FPGA Board Front with Video DAC and SPI Flash
File:Dali D8X3N Sensor Power and ADC Board.jpeg|Sensor control and ADC board
File:Dali D8X3N Thermal Core Debug wiring.jpeg|Debug wiring for sniffing SPI and UART
</gallery>

===User Manual===
including pinout diagram and important data

can be found here https://archive.org/details/dali-d-8-x-3-cuser-manualen-v-1.0-1

==Viewing the Video Stream==
[[File:Onvif Device Manager ODM.png|thumb|ODM streaming the Thermal view]]
when first connecting it to power and Ethernet, the camera will have 192.168.1.102 as a Static ip.

If you are running a 192.168.0.x or .178.x net, you need to change it or add a subnet under windows ipv4 settings.

to view it, you can use VLC and the stream URL
rtsp://admin@admin:<camera ip>/ONVIFMedia
there is /ONVIFMedia /ONVIFMediaM and /ONVIFMediaS for different stream Profiles.

VLC is quite slow and delayed, rather use Onvif Device Manager ODM,

it has no delay and auto-detects cameras in the network.

Be sure to log in as user: admin pass: admin in ODM.

in there, you can also set you camera to DHCP under Network settings.

===Web Interface===
[[File:Dali D8X3N web interface.png|thumb|Since browsers cant display RTSP anymore, open in Edge and select IE Compatibility Mode.]]
the web interface can be accessed by opening the camera IP in a browser

login is:
user: admin pass: admin
You can set Temperature markers and areas, but without using the Black Body calibration source, your readings may be way off or not working.

 

====OSD====
there is a debug-login with
user: super pass: 871897
that lets you send Key commands to the Imager to navigate the OSD.

Setting the OSD to english is accomplished with option #11
[[File:Dali D8X3C OSD.png|thumb|OSD in english, if yours is Chinese. go to option #11 and click + or -]]

To acces some locked menus, press
+ - + - + -

The password for the locked System and Main menu is
+-MC+-

Be careful in the UART menu to not change the BAUD rate or Protocol, as your ability to control it via the Web API gets lost.

You need to reflash or solder buttons on the thermal core then.

==Viewing Raw Thermal Data from the Web API==
there is a hidden endpoint in the stream.so file that could be found while decompiling

accessing
[[File:Arduino Nano blink sketch thermal gif.gif|thumb|Arduino Nano running blink sketch while thermally recording it, notice the led and resistor on the right]]
<ip of camera>:5000/stream?Type=JPEG&Source=Jpeg&Mode=TCP
lets you download a JPEG. but there are more options available (not all have been tested)

we are mainly interessted in Raw thermal data.

====Source (Stream Type)====

*<code>Major</code> - Main video stream (channel 0)
*<code>Minor</code> - Sub video stream (channel 1)
*<code>MinorAV</code> - Sub video + audio stream
*<code>MajorAV</code> - Main video + audio stream
*<code>Jpeg</code> - JPEG snapshot stream
*<code>Raw</code> - Raw thermal data stream
*<code>YUV</code> - YUV raw video stream

====Type (Data Format)====

*<code>H264</code> - H.264 video encoding
*<code>JPEG</code> - JPEG image format
*<code>RAW</code> - Raw sensor data
*<code>QBOX</code> - Custom protocol format
*<code>FRAME</code> - Frame-based format

====Mode (Transport Protocol)====

*<code>TCP</code> - TCP streaming (default)
*<code>UDP</code> - UDP streaming
*<code>MUL</code> - Multicast streaming

====Quality Parameters====

*<code>Quality=[1-100]</code> - Video quality level
*<code>Frames=[number]</code> - Number of frames to send
*<code>Interval=[ms]</code> - Frame interval in milliseconds

====Network Parameters====

*<code>IPAddr=[ip]</code> - Client IP address for UDP/multicast
*<code>Port=[port]</code> - Client port for UDP/multicast
*<code>Heart-beat=[Yes/No]</code> - Enable/disable heartbeat

====Snapshot Parameters====

*<code>Snap=[Yes/No]</code> - Enable snapshot mode

 
====Raw Viewer for PC (Python)====
[[File:Dali D8X3N Raw Thermal viewer.png|thumb|Raw Data Viewer in python]]

To view the raw stream, i made a python program that converts the 14bit thermal data to a visible image.

it is low fps tho, due to bad optimizations.

rev1 first working version https://pastebin.com/dyNWDPT3

rev2 with temperature readout https://pastebin.com/u107Q85w

rev3 and onward will only be available directly as a Webpage on the Device (see below).

====Raw Viewer for the internal Webserver (recommended)====
It is also possible to use the Raw viewer directly in the browser.

To achieve this, the stream had to be proxied from port 5000 to 80 due to CORS.

luckily the internal lighttpd had the CGI module enabled, so piping it troug (using wget ... i know) worked with very low overhead.

To install, you need '''Terminal access''' to the Camera. see below.

optional for simplicity: '''ftp''' access

[[File:Dali D8X3N Webviewer.png|thumb|Web Raw Viewer with histogram (rev3)]]

Create the files and the code inside.

'''/app/web/webpages/raw.html''' https://pastebin.com/kaiXwAgD

and

'''/app/web/webpages/cgi-bin/proxy.cgi''' https://pastebin.com/vii1HXcU

then run
chmod +x /app/web/webpages/cgi-bin/proxy.cgi
'''restart''' your camera.

It should be accessible now trough '''http://<camera ip>/raw.html''' in the browser and click Start Stream

'''NOTE''': ''If it does not work'', check the contents of both files. FTP sometimes messes them up.

also run
dos2unix /app/web/webpages/cgi-bin/proxy.cgi
because linux <> windows difficulties that couldnt be resolved in over 30 years.

<blockquote>

performance may need improvement.</blockquote>

==Getting Root Terminal Access==
To access the Terminal you need to solder or plug in a UART connection to Connector J7 on the "Glue" board.

Pinout is (left to right) '''RX TX GND 3.3V Baud 115200 3.3V!'''

But the system will spam with debug messages, making patching the files a hard job unless you use "tftp" or "sed" commands.
 

====Enabling Telnet access to make patching easier====
[[File:Upgrade ici dali firmware updater.png|thumb|ICI Firmware updater software with modified firmware loaded]]

there is a easier way using a modified Firmware updater to enable Telnet temporarily to patch the Files.

Download the '''upgrade_ici.exe''' form [https://archive.org/details/fwupdate here] and run it.

Then you should be able to connect to it via Telnet.

The Login credentials are '''User: roo'''t '''Password: DLroot'''

 

===Patching Device===

===Patching the Web Server===
 

====Enabling Telnet and ftpd permanently====

This only works if you also patch the Thermal Camera module flash!

to permanently enable Telnet, go to '''/etc/init.d''' and edit '''S90app'''
vi S90app
in vi, move your cursor to the '''#''' at '''#telnetd''' and press x<blockquote>optional: enable ftp by removing the '''#''' at '''ftpd''' and adjust the path to / </blockquote>now press ''':''' and type '''wq''' and hit '''enter'''. this should be it.

====Patching the decoder and streamer to 640x480:====
go to /app and edit the mach.cfg

replace DL384 with D640 and edit the resolution to 640 480

(press i in vi to enter edit mode, press ESC to exit edit mode. :wq to write and quit.)

repeat that procedure for the dali.cfg

=====(optional) patching app.sh to prevent it from rebooting=====
edit the app.sh in /app and remove all "reboot" occasions to prevent the camera from rebooting if onvifserver, httpd or daliServer arent running for debugging purposes.

 

====Patching the Thermal Camera module====
To patch it, you need to disassemble everything down to the FPGA Board,

on the bottom there is a SPI SOIC8 Flash.

Use a CH341 EEPROM programmer (be sure to have a fixed or modified version to not put out 5V!, set it to 3.3V) and SOIC8 clamp.

Use NeoProgrammer (i used 2.2.0.10 but there are newer available, use the latest) and click Detect. It should find W25Q128 chips, select the FV one.

Dont forget to download a backup of your flash and save it !

Download the Binary "Dali 640x480 '''actual''' cleared pixelmap.bin" from #3 below and load it into NeoProgrammer,

Click Erase, Program and Verify.

This can take a while.

Your imager should start up right after assembly by hearing the shutter click.

==Hardware Hacking==

===Flash Contents===
On archive, click on show all files to download them.

<nowiki>#</nowiki>1 a Flash dump of the original downgraded D8X3N can be found [https://archive.org/details/dali-d-843n-flash-dump here]

<nowiki>#</nowiki>2 a Flash dump of a original 640x480 model can be found [https://archive.org/details/d-843-n-640x-480 here]

<nowiki>#</nowiki>3 a modified Flash dump of a 640x480 with cleared dead pixel map, flat map etc. can be found [https://archive.org/details/d-843-n-640x-480-cleared-pixelmap here]

a Flash dump of the web server SPI flash W25Q256JV can be found [https://archive.org/details/dm-60-webserver-flash-dump here] in case a bad firmware update caused a bootloop.

 

===Flash Binary Analysis===
The Flash IC is a Winbond 25Q128JV SPI Flash that contains the FPGA Bitstream, Deadpixel and Flatmap, aswell as the Device Settings.

a copy of the SPI Logic Capture at startup can be found [https://archive.org/details/dali-eeprom-capture here], the free software [https://www.dreamsourcelab.com/download/ DSView from DreamSourceLab] is required to view it.
[[File:Dali Thermal Imager SPI Flash capture.png|thumb|SPI Flash access while booting the Thermal Module]]

a approximation of the offsets resulted in this list:<syntaxhighlight lang="vb">
0x000000 - altera cyclone iv stuff
0x200000 - settings
0x280000 - Flat field correction map
0x4C0000 - Bad Pixel correctio nmap
0x580000 - image aswell? 36010 bytes
0x740000 - GUIX?
0x7C0000 - Strings for Gui?
0x800000 - another shorter GUIX
0x880000 - Strings for second gui?
0x8C0000 - GUIX
0x940000 - Strings for gui
0xE00000 - ?
0xE80000 - dzxg? short
0xEC0000 - crosshair.bmp
0xF40000 - 3DTM?
0xF80000 - fake? Bad pixel map BPRP
</syntaxhighlight> 

====Settings offset 0x200000====
The settings are read and written every startup, aswell when you close the OSD, sporadically and when executing the command MSV

these are some of the settings i could figure out by changing and watching the logic capture what changed.
 <syntaxhighlight lang="vb">
offset size Cmd
0x0 1 SAG (0-2) auto gain
0x2 2 SVB (0-16383) saved value is 16383 - SVB
0x4 2 SVC (0-1023) set exposure or gain
0x6 1 SSM image filtering
0x8 1 SEH image enhancement
0xA 1 SWP invert b/w polarity
0x14 1 SMR Flip
0x16 1 SMR Mirror
0x20 1 MENU Cal source 0 IN, 1 OUT
0x3A 1 MENU Enhance value 0-100
0x40 1 MENU Rectify (shutter 0 OFF, 1 L, 2 H)
0x50 1 MENU Language 0 english, 1 chinese, 2 russian
0xA2 - SCO set contrast gain
0xA4 - IBR set brightness
0xAE 2 MENU Fire Threshold
0xAC 1 SPA set color palette
0xE2 1 SMS display "collected 0/80" enabled
0xF8 1 SEM set emissivity
0x110 1 SRT set revise temp
0x116 1 SHD set humidity
0x118 1 SET set ambient temp
0x11A 1 STD set temp range
0x120 2 SLG -500 to 500?
0x124 2 SRD set distance
0x12C 1 SCP ???
0x130 2 SCT ???
</syntaxhighlight> 
[[File:Dali D8X3N Bad Pixel Map Viewer.png|thumb|Bad pixel map of a 640x512 sensor, about 0.56% of dead pixels in this map]]
So i let the AI create a [https://2476424.playcode.io/ Configurator page] that lets you change the Settings in your Flashdump to your liking
 

====Bad Pixel and Flatframe Maps 0x280000 and 0x4C0000====
Thermal cameras require a bad pixel and flat frame map to compensate for manufacturing inconsistencies.

unfourtainly, the maps of the downgraded cameras only contain enough data for a 384 model, not the full 640.

at offset 0xF80000 there is a BPRP which was mistaken at first as the Bad pixel map, it could just be a mask to where to apply the offset maps, as its either 0x0 or 0x1.

The [https://2477569.playcode.io/ Viewer Page] is written in JS and does not require any special dependencies, it can run as a plain html file offline.

There still needs to be work done to create own maps and flatfields but the cameras are still very capable and useable with fully cleared maps.

To clear the maps, just go to these offsets and fill with values around 0x3F or 0x0 for total length of X Resolution x Y Resolution x 2 bytes (0x96000 for 640x480)

[[File:Dali D8X3N Flat Field Map Viewer.png|thumb|Flat Field viewer]]

==Dali Commands==
To control the TIM you can either use Pelco or Dali command set. By default the Dali commandset is used at 38400 BAUD.

Those commands consist of a 0x02 start byte followed by two length Bytes, then the actual command which is allways 3 uppercase Letters in ASCII (eg. KBD for keyboard) followed by a comma and the values.

Some commands take multiple values, some dont. But you allways have to send the comma after the Command.

The camera will answer with the Command and 0, 1 or 2. Sending no value counts as zero.
0 is invalid parameters, too few or out of range

1 is OK, valid command

2 is Invalid command

Commands can be sent trough the Web server using the URL Api endpoint or directly trough the UART port.

(keyboard, C button, causes the shutter to do a calibration)
<camera ip>/cgi-bin/dmcmd?Command=KBD,C
Listening to the answer can be done while being in the Linux shell and typing
cat /dev/ttyAMA2 | strings

By bruteforcing the UART with AAA to ZZZ a list of Commands could be obtained, but some with unknown Parameters or functionality yet. including some from a decompiled DM60comm.so module found in /app/modules folder.<syntaxhighlight lang="vb">
KBD KEY Keyboard (F S M C + -)
SSM 0-1 Image Filtering Off/On
GSM 0 Image filter status
SEH 0-1 Image Enhancement Off/On
GEH 0-1 Image enhancer status
SCO 0-255 Set Gain (locked when SAG auto gain is on)
GCO 0-255 Get gain
INT 15-320 set actual gain? not just contrast sometimes disabled?
IBR 0-255 Set brightness
GBR 0-255 Get brightness
SMR 0-3 Mirror mode bit0=horizontal, bit1=vertical
GMR 0 Get rotation/flip
SDT 0-1 displays temp=44.65°C osd, but webserver sends date/time to the cam there....
GDT 0-1 Get temp display active?
GPT Display temp oft SDT
GNU 0-1 Get Shutter closed/open
SNU 0-1 Shutter close / open
STD 0-1 Set Range 0: -20-180°C 1: 100-600°C
GTD 0-1 Get Range
SET °C Set Ambient temperature
GET °C Get Ambient temperature
SEM 0-100 0-1 set emissivity x100
GEM 0-100 Get Emissivity
SRT °C Set revise temperature -100-100 -10-10°
GRT °C Get revise temperature
SRD 100 Set Distance 4.4m x100
GRD 100 Get Distance
SHD 0-100 Set Humidity
GHD 55 Get Humidity
SWP 0-1 invert s/w polarity image
GWP 1 is inverted?
SPA 0-10? Set color palette
GPA 3 white hot
SMV 0-1 Show temperature 3x3 grid?? in combination with GTV maybe
GMV 0
SMS 0-1 displays "collected 0/<number set by SCT>" by SCP delay "saves the daily number of highest temperatures?"
GMS 0
SCT 1-500 sets the amount of "collected" points for SMS
GCT 80
SCP 5-60 "collected" delay in seconds for SMS
GCP 60
SAG 0-2 Auto brightness / gain
GAG 0
SLR 0-9 ???
GLR 0
SRP 0,0 - 639,479 set crosshair position
GRP 320,240 get crosshair position
DRC 0-1 Show crosshair
SLG -500-500 ??
GLG
SCE text ??
GCE 0
SCB text ??
GCB 0
SVB 0-16383 adc offset, exposure? good at 9650
GVB 6733 value is 16383 minus SVB
SVC 1-1023 set contrast but better
GVC 260
SVF 100-? ?? video freaks out 3400 seems good
SVS 100-? ?? video freaks out 3300 seems good
SOT 0-1 ?? sensor supply, looks weird when off.
SZM 1-4 ?
GZM 1
MSV save settings too eeprom
ASV Saves something aswell?
GCS 0 Get Core status & faults
ALD 0,2? video blanks lots of eeprom activity. reload pixel map??
SAV 0-9999 set Fire threshold
GAV 2100 get Fire Threshold
BAC change uart protocol? careful
CBD Displays Recovery successful?
CBS Displays Saved successfully
LRD Displays Recovery successful?
LRS Displays Saved successfully?
LRE Displays Temperature Repair successful?
CBT Displays Calibration successful?
DBP ??? shutter clicks
DPI Show weird pixels
API Hide weird pixels
CCM ??
ASN 0-4 ??
GAB 4 vals ?? 3,-10,50,150
GAN 1 ??
GAR 11 vals ?? 10,10,5,20,35,50,70,90,120,150,180,,
GCM 6 values ??
GFV prints screen gray value?
GIT 200 ??
GTV Get the collected temp values?
PTS echoes but with extra stuff??
QYA 7170 Query Gray Info (information mode)
QYI 7124 Query Gray Average mode
QYM 7512 Query Gray Minimum mode
VTP 400-4000 ??
MTD U/S,0,0 ?? S answers with bytes, U upload bytes?
MTC U/S? ?? S answers with U,0,0, S doesnt.

return 0 invalid params:
STS ??
STT ??
SAC ??
SAH ??
SAS ??
SAT ??
SCX ?? displays crosshair but invalid params
SCY ?? displays crosshair but invalid params
GAC ??
GAH ??
GAS ??
GAT ??
GME ??
GPC ??
GPI ??
GPM ??
GTA ??
GTC ??
GTI ??
GTM ??
GTS ??
GTT ??

answer only:

BPM 0-1 stream ready? answers with 0 stop, 1 go, 2 when prompted
AVS 0,1
MEH
PWI 0-1 changing palette from wh to fire

unconfirmed (from dm60comm.so):
SDT 2024,03,15,14,30,25 Set Date Time with year,month,day,hour,minute,second
STS 1 Set Temperature Show display (0=off, 1=on)
SVA 2 Set Video Auto mode (0=manual, 2=auto)
SMP 0,1,1,0,100,150,200,250,300,350,90,25 Set Measurement Point (type,index,enable,mode,startX,startY,endX,endY,anchorX,anchorY,threshold,color)
STV Stop Temperature View measurements
SPF 5 Set Profile parameter
SVL -10 Set Video Left pan movement (signed value)
SVU -5 Set Video Up tilt movement (signed value)
SVD 5 Set Video Down tilt movement (signed value)
SSP 17,1,0 Set System Parameter (param_id,value,index) #46 temperature format 0 °C, 1 °F, 2 K
SCP Set Current Preset (save current position)
GCP Get Current Preset
STT 300,350 Set Temperature Threshold (low,high values *10)
SDC 1 Set Display Configuration parameter
GCS Get Current Status
GMM Get Memory Map information
GFV Get Frame Value (grayscale data)
GFZ Get Freeze Status
GSI 1 Get System Information (parameter=1)
GSS Get System Status
GSP 21,0 Get System Parameter (param_21=surround temp, value=0)
GTT Get Temperature Threshold range
GTV 1,3,10 Get Temperature Values (enable,type,count)
GNU Get Network Update status (response command)
FRZ Freeze current display frame
LIV Live mode (unfreeze display)
CAL Calibrate system
CCP 3 Call Current Preset (preset number 0-9)
APF 100 Auto Profile setting
MEH Measure Enhancement
BPT Built-in Test
MTC S,0 Measure Temperature Capture (S=start, 0=sequence)
MTG U,0,1024,<data> Measure Temperature Gray data transfer
MTD U,0,1024,<data> Measure Temperature Data transfer
UFP S,0,2048 Update Firmware Prepare (S=start, 0=offset, 2048=size)
UFD S,0,1024 Update Firmware Data transfer
BAB U Buffer operation (U=update)
TTH S,0 Temperature Threshold operation
IPP 192.168.001.102,255.255.255.000,192.168.001.001,192.168.000.001,9989,9998 IP Parameters (IP,netmask,gateway,DNS,port1,port2)
MAC 00:60:A9:10:00:01 MAC Address setting
SNP Set Network Parameters (response command)
QYI Query Gray Info (information mode)
QYA Query Gray Average mode
QYM Query Gray Minimum mode
GAI Get Alarm Info (response command)
YTC <data> Unknown command with data parameter
HTH
LRS
LRD
GAR
DRC
PTS
SCX
SCY
CBT
LRE
CBD
CBS
XXX
GSP
GTT
QYI
QYA
QYM

</syntaxhighlight>

==Secret Menu Overview==
The secret menus Main and System can be openend with the password '''+-MC+-'''

Its structured like this, not all variables have been figured out yet.

The format is Menu: submenu: submenu:

and for menu entries: Name, default value, command, description or messages that pop up.
 <syntaxhighlight lang="vb">
MAIN & SYSTEM PASS: +-MC+-

entries are NAME VALUE COMMAND DESC or if its a folder its just ":"

System:
System:
Gain 255 SCO
Bright 102 IBR
BenDi 100 ?
BenDiContrase 80 ?
DisMode 0 ?
Frequency 48hz (24,25,48,50)
DigitalOut 8-14bit 14bit, BT656(_P), ?, BT601
AutoFocus N ?
Line 1 ?
Ltemp0 11800 ?
LTemp1 11000 ?
HTemp0 9500 ?
HTemp1 8700 ?
DelayTime 0 ?
Enhance 0-1 ?
Enhanced E1 230 ?
FPA_Gain 12pF ? between 4 and 18 at random.
NUCEn N ?

Area:
SE 2 ASN 0-4 "Partition"
INT 200 INT "Points time"
VS 3161 SVS
VF 2800 SVF
Vtemp 1401 VTP
VtempArea Low ?
VtempBase 13500 ?
VtempStep -1 ?
VsStep 8 ?
DeadPixelModel preset / calculate
DP: Cursor to select dead pixels
X 360 position
Y 288 position
AutoBP: 50 Press C to start automatic dotting
Quit? Number of bad pixels 961& "Blind element replacement in progress"
Undo
R2: Save data? blind pixel replacement in progress
Replace Y N = DPI, Y = API
L: Reading parameters
S: Saving parameters

Debug:
Rectify N
DisplayGary N
TE N SDT
AutoE ? ?
AutoVS Y ?
VSGrayH 8000 ?
VSGrayL 7000 ?
Trends 1 ?
Shelter N ?
MotorCon 3 ?
SaveFactoryPara:
LanTyp EN ? LANGUAGE
DisplayMT N ?
Version:
PRJ D843 DLD640 ImLib, MTlib, Soft, Logic

BackDispose:
GammaEN 1 ?
Gain 1 ?
EnhanceEN 0 ?
Hpf_shift 5 ?
Hpf_thrd 5 ?
Enhance 150 ?
Lthrd 50 ?

Monitor:
Opens normal OSD

Alarm Set:
Alarm Switch Y ?
Alarm Mode No ?
Alarm Temperature -1°C ?
Reference Gray Y ?
Alarm Level 1L ?
Alarm Gray 65535 ?
Alarm PointNum 0 ?
Correct Gray 0 ?

Thermometry:
Data Collection 0 SMS
Interval 60 SCP
Ammount 90 SCT
Environment normal ?
Export:
Displays: Exportin normal temperature MTC data
Correction -1 ?
Emissivity 100 SEM
Calibration:
BlackbodyTemp -10 grabs a val from GAB
Save CBS
Cancel CBD
Correction:
BlackbodyTemp -10 Picks from the list GAR
Grayscale 0 SLG
Confirm LRE
Save LRS
Cancel LRD
Ninepoint measurement SMV

Cursor:
Cur N DRC enable cursor
X 320 SRP set cursor position
Y 240 SRP set cursor position

Main:
Auto 2 SAG Auto gain
G 211 SVC
B 10002 SVB
P 1 SWP polarity
Z X ?
Settings:
Image:
FI Y ?
FIValue 0 ? 0-31
Freeze N Freeze image
VE N SMR Vertical flip
HO N SMR Horizontal flip
AutoCali L same as rectify?
O IN internal or external
COM:
Opens UART menu
AvoidburnSwitch OFF enable anti burn in
ProtectedTime 10S duration
AvoidBurn 16383 threshold to trigger antiburn

</syntaxhighlight>

===Automatic Dead Pixels and Flatmap Correction===

It it possible to generate a new flat and dead pixel map automatically within the camera after flashing the cleared-map binary.
 

=====Dead pixels:=====
In the secret menu "System", navigate to Area - DeadPixelModel and set the AutoBP (sensitivity for auto bad pixel finding) to 50 or so. Then press C Button

This can take a while.
[[File:High emissivity peltier black body.jpg|thumb|A Peltier / TEC coated in Candle sood to give it a high emissivity surface. It can be cooled or heated by swapping the polarity. ]]

Afterwards, navigate to S: and press + to save it.
 

=====Flatfield:=====
In the Debug menu navigate to R2 and press +

now place something '''Cold''' infront of the Camera with a high emissivity. (it needs to fill the whole image)

Press '''+''', wait for it to says High temperature.

Place something '''Hot''' infront and press '''+''' again.

Afterwards, save with '''S:''' again.

Flatfield should now be calibrated
 <blockquote>Note: Not all dead pixels are auto detected or get removed. you can manually select them in the Dead pixel editor but its not known yet how to select and correct them.</blockquote>

 

==Using the Thermal module without Webserver==
[[File:Dali D8X3C Breakout board.png|thumb|Breakout board for D8X3C ]]
to use it, you need to interface it directly.

The module will put out a Analog video signal (High-Z, need to buffer when connecting it to 75Ohm Video input)

Also a 8 or 14bit or 8-bit BT656 output.

the header exposes the FPGA JTAG and UART aswell as 6 Hardware Keys to Navigate the OSD.

To interface, you need to make a adapter board with a DF12-50DS-0.5V(86) Docking socket.

The breakout board files can be found [https://oshwlab.com/gamerpaddy/d8x3c-backpack-usb here] but may be still work in progress.

 

==Sensor Pinout==
[[File:Dali DLD384 Sensor pinout basic.png|thumb|basic pinout of a DLD384]]
the pinout of the thermal sensor havent been analyzes much.

besides some supply and Control voltages, 3 clocks and a analog output have been found.

17.5MHz

14.705KHz

50Hz

Dali D8X3N Thermal Camera

2025-08-04T17:49:54Z

Gamerpaddy: /* Automatic Dead Pixels and Flatmap Correction */

=Dali D8X3N Thermal Camera Reverse Engineering=
 

===Introduction===
The [https://www.dali-irtech.com/productinfo/741567.html Dali D8X3N] Thermal Camera module comes in two versions, a 384x288 and 640x480 resolution, utilizing the [http://www.dali-tech.us/products/dld64017m-uncooled-infrared-fpa-detector-86.html DLD Series] of amorphous-Silicon Microbolometers.

They were mainly used in [http://www.dali-tech.us/products/dm60-w--online-body-temperature-thermal-imaging-camera-55.html Dali DM60-W] or WS-1 Body Temperature screening cameras in conjunction with a Black Body radiator set to 37°C to detect infected individuals at the start of the 2020 Covid Pandemic.
[[File:ICI FM320P Innerts.jpg|thumb|Internals. A TP-Link Switch, HikVision Visible Camera and the D8x3N Network thermal camera module]]
[https://infraredcameras.com/ ICI] rebranded these models as FM 320 P and FM 640 P, and distributed them on the local US market, but as the need for such Cameras exploded, those models were built with what was in stock.

So happens, that some of the FM 320 P Models had a DLD640 640x480 instead of a DLD384 384x288 Microbolometer in them, and just got their Firmware modified.

It also could be, because they have excessive amounts of bad pixels outside the 384x288 area, that they were binned to a lower grade.

Discussions about these Cameras started around 2022 in the [https://www.eevblog.com/forum/thermal-imaging/ici-and-dali-thermal-camera-software/ EEVBlog Forums.] when they started to appear secondhand and affordable.

Originally they were priced around US$ 20... 30.000 by ICI, and a unknown amount by Dali Tech.

The Modules specs according to the manufacturer are:

≤50..60mK@F1，300K，50Hz

17 or 25µm pixel pitch

Hisilicon SoC running Linux to provide Onvif and RTSP streams, analysis and a Web UI

 
[[File:Dali D8X3N Module.jpg|thumb|A real 384x288 model with a DLD384 sensor. notice the Productnumber ]]
ICI FM Cameras are found all over Online secondhand marketplaces for scrap Prices, as they are no longer needed.

But you never know, what are you getting. It could be a real DLD384 or the better DLD640 inside. Its a gamble.
 

======640x480 Imagers======
are labeled 22D843 Nxxxx and have a DLD640 sensor in it, they can be upgraded if they run the 384x288 firmware.

======384x288 Imagers======
are labeled 22D883Nxxxx and have a DLD384 sensor in it, they cannot be upgraded

 

==D8X3N Module closer look==
From now on, i will refer to the Thermal Imaging Module as TIM

On the front there is a 2 Element Germanium Lens of a unknown focal length and aperture.

It can be focus-adjusted when unscrewing the clamp around the housing. It can be focussed from infinity down to 10..20cm with some quality loss.
 The outter diameter of the Lens is 42mm with a 1 1/3 inch thread diameter of undetermined pitch.

Dimensions of the germanium elements are 21mm to 3 and 6mm and 14grams in weight.
[[File:Disassembled Thermal Camera Lens.jpg|thumb|Two element Germanium Lens of unknown focal length and aperture]]

The TIM is composed of 6 Stacked PCB modules, 3 of which are for the Web Server functionality. taking them off will give you the basic configuration of a [https://www.dalithermal.com/productinfo/741568.html Dali D8X3C] TIM<gallery>
File:Dali DLD640 Thermal Image Sensor.jpeg|DLD640 Sensor
File:Dali DLD384 Thermal Imaging Sensor.jpeg|DLD384 Sensor
File:Dali D8X3N Board1 Back.jpeg|Network & GPIO Board Back
File:Dali D8X3N Board1 Front.jpeg|Network & GPIO Board Front
File:Dali D8X3N Glue Board Back.jpeg|Board between Logic and IO Back
File:Dali D8X3N Glue Board Front.jpeg|Board between Logic and IO Front
File:Dali D8X3N SoC Board Back.jpeg|SoC Board back
File:Dali D8X3N SoC Board front.jpeg|SoC board front
File:Dali D8X3N FPGA Board Back.jpeg|FPGA Board of the D8X3C Thermal Imager including a PMIC
File:Dali D8X3N FPGA Board Front.jpeg|FPGA Board Front with Video DAC and SPI Flash
File:Dali D8X3N Sensor Power and ADC Board.jpeg|Sensor control and ADC board
File:Dali D8X3N Thermal Core Debug wiring.jpeg|Debug wiring for sniffing SPI and UART
</gallery>

===User Manual===
including pinout diagram and important data

can be found here https://archive.org/details/dali-d-8-x-3-cuser-manualen-v-1.0-1

==Viewing the Video Stream==
[[File:Onvif Device Manager ODM.png|thumb|ODM streaming the Thermal view]]
when first connecting it to power and Ethernet, the camera will have 192.168.1.102 as a Static ip.

If you are running a 192.168.0.x or .178.x net, you need to change it or add a subnet under windows ipv4 settings.

to view it, you can use VLC and the stream URL
rtsp://admin@admin:<camera ip>/ONVIFMedia
there is /ONVIFMedia /ONVIFMediaM and /ONVIFMediaS for different stream Profiles.

VLC is quite slow and delayed, rather use Onvif Device Manager ODM,

it has no delay and auto-detects cameras in the network.

Be sure to log in as user: admin pass: admin in ODM.

in there, you can also set you camera to DHCP under Network settings.

===Web Interface===
[[File:Dali D8X3N web interface.png|thumb|Since browsers cant display RTSP anymore, open in Edge and select IE Compatibility Mode.]]
the web interface can be accessed by opening the camera IP in a browser

login is:
user: admin pass: admin
You can set Temperature markers and areas, but without using the Black Body calibration source, your readings may be way off or not working.

 

====OSD====
there is a debug-login with
user: super pass: 871897
that lets you send Key commands to the Imager to navigate the OSD.

Setting the OSD to english is accomplished with option #11
[[File:Dali D8X3C OSD.png|thumb|OSD in english, if yours is Chinese. go to option #11 and click + or -]]

To acces some locked menus, press
+ - + - + -

The password for the locked System and Main menu is
+-MC+-

Be careful in the UART menu to not change the BAUD rate or Protocol, as your ability to control it via the Web API gets lost.

You need to reflash or solder buttons on the thermal core then.

==Viewing Raw Thermal Data from the Web API==
there is a hidden endpoint in the stream.so file that could be found while decompiling

accessing
[[File:Arduino Nano blink sketch thermal gif.gif|thumb|Arduino Nano running blink sketch while thermally recording it, notice the led and resistor on the right]]
<ip of camera>:5000/stream?Type=JPEG&Source=Jpeg&Mode=TCP
lets you download a JPEG. but there are more options available (not all have been tested)

we are mainly interessted in Raw thermal data.

====Source (Stream Type)====

*<code>Major</code> - Main video stream (channel 0)
*<code>Minor</code> - Sub video stream (channel 1)
*<code>MinorAV</code> - Sub video + audio stream
*<code>MajorAV</code> - Main video + audio stream
*<code>Jpeg</code> - JPEG snapshot stream
*<code>Raw</code> - Raw thermal data stream
*<code>YUV</code> - YUV raw video stream

====Type (Data Format)====

*<code>H264</code> - H.264 video encoding
*<code>JPEG</code> - JPEG image format
*<code>RAW</code> - Raw sensor data
*<code>QBOX</code> - Custom protocol format
*<code>FRAME</code> - Frame-based format

====Mode (Transport Protocol)====

*<code>TCP</code> - TCP streaming (default)
*<code>UDP</code> - UDP streaming
*<code>MUL</code> - Multicast streaming

====Quality Parameters====

*<code>Quality=[1-100]</code> - Video quality level
*<code>Frames=[number]</code> - Number of frames to send
*<code>Interval=[ms]</code> - Frame interval in milliseconds

====Network Parameters====

*<code>IPAddr=[ip]</code> - Client IP address for UDP/multicast
*<code>Port=[port]</code> - Client port for UDP/multicast
*<code>Heart-beat=[Yes/No]</code> - Enable/disable heartbeat

====Snapshot Parameters====

*<code>Snap=[Yes/No]</code> - Enable snapshot mode

 
====Raw Viewer for PC (Python)====
[[File:Dali D8X3N Raw Thermal viewer.png|thumb|Raw Data Viewer in python]]

To view the raw stream, i made a python program that converts the 14bit thermal data to a visible image.

it is low fps tho, due to bad optimizations.

rev1 first working version https://pastebin.com/dyNWDPT3

rev2 with temperature readout https://pastebin.com/u107Q85w

rev3 and onward will only be available directly as a Webpage on the Device (see below).

====Raw Viewer for the internal Webserver (recommended)====
It is also possible to use the Raw viewer directly in the browser.

To achieve this, the stream had to be proxied from port 5000 to 80 due to CORS.

luckily the internal lighttpd had the CGI module enabled, so piping it troug (using wget ... i know) worked with very low overhead.

To install, you need '''Terminal access''' to the Camera. see below.

optional for simplicity: '''ftp''' access

[[File:Dali D8X3N Webviewer.png|thumb|Web Raw Viewer with histogram (rev3)]]

Create the files and the code inside.

'''/app/web/webpages/raw.html''' https://pastebin.com/kaiXwAgD

and

'''/app/web/webpages/cgi-bin/proxy.cgi''' https://pastebin.com/vii1HXcU

then run
chmod +x /app/web/webpages/cgi-bin/proxy.cgi
'''restart''' your camera.

It should be accessible now trough '''http://<camera ip>/raw.html''' in the browser and click Start Stream

 <blockquote>performance may need improvement.</blockquote>

==Getting Root Terminal Access==
To access the Terminal you need to solder or plug in a UART connection to Connector J7 on the "Glue" board.

Pinout is (left to right) '''RX TX GND 3.3V Baud 115200 3.3V!'''

But the system will spam with debug messages, making patching the files a hard job unless you use "tftp" or "sed" commands.
 

====Enabling Telnet access to make patching easier====
[[File:Upgrade ici dali firmware updater.png|thumb|ICI Firmware updater software with modified firmware loaded]]

there is a easier way using a modified Firmware updater to enable Telnet temporarily to patch the Files.

Download the '''upgrade_ici.exe''' form [https://archive.org/details/fwupdate here] and run it.

Then you should be able to connect to it via Telnet.

The Login credentials are '''User: roo'''t '''Password: DLroot'''

 

===Patching Device===

===Patching the Web Server===
 

====Enabling Telnet and ftpd permanently====

This only works if you also patch the Thermal Camera module flash!

to permanently enable Telnet, go to '''/etc/init.d''' and edit '''S90app'''
vi S90app
in vi, move your cursor to the '''#''' at '''#telnetd''' and press x<blockquote>optional: enable ftp by removing the '''#''' at '''ftpd''' and adjust the path to / </blockquote>now press ''':''' and type '''wq''' and hit '''enter'''. this should be it.

====Patching the decoder and streamer to 640x480:====
go to /app and edit the mach.cfg

replace DL384 with D640 and edit the resolution to 640 480

(press i in vi to enter edit mode, press ESC to exit edit mode. :wq to write and quit.)

repeat that procedure for the dali.cfg

=====(optional) patching app.sh to prevent it from rebooting=====
edit the app.sh in /app and remove all "reboot" occasions to prevent the camera from rebooting if onvifserver, httpd or daliServer arent running for debugging purposes.

 

====Patching the Thermal Camera module====
To patch it, you need to disassemble everything down to the FPGA Board,

on the bottom there is a SPI SOIC8 Flash.

Use a CH341 EEPROM programmer (be sure to have a fixed or modified version to not put out 5V!, set it to 3.3V) and SOIC8 clamp.

Use NeoProgrammer (i used 2.2.0.10 but there are newer available, use the latest) and click Detect. It should find W25Q128 chips, select the FV one.

Dont forget to download a backup of your flash and save it !

Download the Binary "Dali 640x480 '''actual''' cleared pixelmap.bin" from #3 below and load it into NeoProgrammer,

Click Erase, Program and Verify.

This can take a while.

Your imager should start up right after assembly by hearing the shutter click.

==Hardware Hacking==

===Flash Contents===
On archive, click on show all files to download them.

<nowiki>#</nowiki>1 a Flash dump of the original downgraded D8X3N can be found [https://archive.org/details/dali-d-843n-flash-dump here]

<nowiki>#</nowiki>2 a Flash dump of a original 640x480 model can be found [https://archive.org/details/d-843-n-640x-480 here]

<nowiki>#</nowiki>3 a modified Flash dump of a 640x480 with cleared dead pixel map, flat map etc. can be found [https://archive.org/details/d-843-n-640x-480-cleared-pixelmap here]

a Flash dump of the web server SPI flash W25Q256JV can be found [https://archive.org/details/dm-60-webserver-flash-dump here] in case a bad firmware update caused a bootloop.

 

===Flash Binary Analysis===
The Flash IC is a Winbond 25Q128JV SPI Flash that contains the FPGA Bitstream, Deadpixel and Flatmap, aswell as the Device Settings.

a copy of the SPI Logic Capture at startup can be found [https://archive.org/details/dali-eeprom-capture here], the free software [https://www.dreamsourcelab.com/download/ DSView from DreamSourceLab] is required to view it.
[[File:Dali Thermal Imager SPI Flash capture.png|thumb|SPI Flash access while booting the Thermal Module]]

a approximation of the offsets resulted in this list:<syntaxhighlight lang="vb">
0x000000 - altera cyclone iv stuff
0x200000 - settings
0x280000 - Flat field correction map
0x4C0000 - Bad Pixel correctio nmap
0x580000 - image aswell? 36010 bytes
0x740000 - GUIX?
0x7C0000 - Strings for Gui?
0x800000 - another shorter GUIX
0x880000 - Strings for second gui?
0x8C0000 - GUIX
0x940000 - Strings for gui
0xE00000 - ?
0xE80000 - dzxg? short
0xEC0000 - crosshair.bmp
0xF40000 - 3DTM?
0xF80000 - fake? Bad pixel map BPRP
</syntaxhighlight> 

====Settings offset 0x200000====
The settings are read and written every startup, aswell when you close the OSD, sporadically and when executing the command MSV

these are some of the settings i could figure out by changing and watching the logic capture what changed.
 <syntaxhighlight lang="vb">
offset size Cmd
0x0 1 SAG (0-2) auto gain
0x2 2 SVB (0-16383) saved value is 16383 - SVB
0x4 2 SVC (0-1023) set exposure or gain
0x6 1 SSM image filtering
0x8 1 SEH image enhancement
0xA 1 SWP invert b/w polarity
0x14 1 SMR Flip
0x16 1 SMR Mirror
0x20 1 MENU Cal source 0 IN, 1 OUT
0x3A 1 MENU Enhance value 0-100
0x40 1 MENU Rectify (shutter 0 OFF, 1 L, 2 H)
0x50 1 MENU Language 0 english, 1 chinese, 2 russian
0xA2 - SCO set contrast gain
0xA4 - IBR set brightness
0xAE 2 MENU Fire Threshold
0xAC 1 SPA set color palette
0xE2 1 SMS display "collected 0/80" enabled
0xF8 1 SEM set emissivity
0x110 1 SRT set revise temp
0x116 1 SHD set humidity
0x118 1 SET set ambient temp
0x11A 1 STD set temp range
0x120 2 SLG -500 to 500?
0x124 2 SRD set distance
0x12C 1 SCP ???
0x130 2 SCT ???
</syntaxhighlight> 
[[File:Dali D8X3N Bad Pixel Map Viewer.png|thumb|Bad pixel map of a 640x512 sensor, about 0.56% of dead pixels in this map]]
So i let the AI create a [https://2476424.playcode.io/ Configurator page] that lets you change the Settings in your Flashdump to your liking
 

====Bad Pixel and Flatframe Maps 0x280000 and 0x4C0000====
Thermal cameras require a bad pixel and flat frame map to compensate for manufacturing inconsistencies.

unfourtainly, the maps of the downgraded cameras only contain enough data for a 384 model, not the full 640.

at offset 0xF80000 there is a BPRP which was mistaken at first as the Bad pixel map, it could just be a mask to where to apply the offset maps, as its either 0x0 or 0x1.

The [https://2477569.playcode.io/ Viewer Page] is written in JS and does not require any special dependencies, it can run as a plain html file offline.

There still needs to be work done to create own maps and flatfields but the cameras are still very capable and useable with fully cleared maps.

To clear the maps, just go to these offsets and fill with values around 0x3F or 0x0 for total length of X Resolution x Y Resolution x 2 bytes (0x96000 for 640x480)

[[File:Dali D8X3N Flat Field Map Viewer.png|thumb|Flat Field viewer]]

==Dali Commands==
To control the TIM you can either use Pelco or Dali command set. By default the Dali commandset is used at 38400 BAUD.

Those commands consist of a 0x02 start byte followed by two length Bytes, then the actual command which is allways 3 uppercase Letters in ASCII (eg. KBD for keyboard) followed by a comma and the values.

Some commands take multiple values, some dont. But you allways have to send the comma after the Command.

The camera will answer with the Command and 0, 1 or 2. Sending no value counts as zero.
0 is invalid parameters, too few or out of range

1 is OK, valid command

2 is Invalid command

Commands can be sent trough the Web server using the URL Api endpoint or directly trough the UART port.

(keyboard, C button, causes the shutter to do a calibration)
<camera ip>/cgi-bin/dmcmd?Command=KBD,C
Listening to the answer can be done while being in the Linux shell and typing
cat /dev/ttyAMA2 | strings

By bruteforcing the UART with AAA to ZZZ a list of Commands could be obtained, but some with unknown Parameters or functionality yet. including some from a decompiled DM60comm.so module found in /app/modules folder.<syntaxhighlight lang="vb">
KBD KEY Keyboard (F S M C + -)
SSM 0-1 Image Filtering Off/On
GSM 0 Image filter status
SEH 0-1 Image Enhancement Off/On
GEH 0-1 Image enhancer status
SCO 0-255 Set Gain (locked when SAG auto gain is on)
GCO 0-255 Get gain
INT 15-320 set actual gain? not just contrast sometimes disabled?
IBR 0-255 Set brightness
GBR 0-255 Get brightness
SMR 0-3 Mirror mode bit0=horizontal, bit1=vertical
GMR 0 Get rotation/flip
SDT 0-1 displays temp=44.65°C osd, but webserver sends date/time to the cam there....
GDT 0-1 Get temp display active?
GPT Display temp oft SDT
GNU 0-1 Get Shutter closed/open
SNU 0-1 Shutter close / open
STD 0-1 Set Range 0: -20-180°C 1: 100-600°C
GTD 0-1 Get Range
SET °C Set Ambient temperature
GET °C Get Ambient temperature
SEM 0-100 0-1 set emissivity x100
GEM 0-100 Get Emissivity
SRT °C Set revise temperature -100-100 -10-10°
GRT °C Get revise temperature
SRD 100 Set Distance 4.4m x100
GRD 100 Get Distance
SHD 0-100 Set Humidity
GHD 55 Get Humidity
SWP 0-1 invert s/w polarity image
GWP 1 is inverted?
SPA 0-10? Set color palette
GPA 3 white hot
SMV 0-1 Show temperature 3x3 grid?? in combination with GTV maybe
GMV 0
SMS 0-1 displays "collected 0/<number set by SCT>" by SCP delay "saves the daily number of highest temperatures?"
GMS 0
SCT 1-500 sets the amount of "collected" points for SMS
GCT 80
SCP 5-60 "collected" delay in seconds for SMS
GCP 60
SAG 0-2 Auto brightness / gain
GAG 0
SLR 0-9 ???
GLR 0
SRP 0,0 - 639,479 set crosshair position
GRP 320,240 get crosshair position
DRC 0-1 Show crosshair
SLG -500-500 ??
GLG
SCE text ??
GCE 0
SCB text ??
GCB 0
SVB 0-16383 adc offset, exposure? good at 9650
GVB 6733 value is 16383 minus SVB
SVC 1-1023 set contrast but better
GVC 260
SVF 100-? ?? video freaks out 3400 seems good
SVS 100-? ?? video freaks out 3300 seems good
SOT 0-1 ?? sensor supply, looks weird when off.
SZM 1-4 ?
GZM 1
MSV save settings too eeprom
ASV Saves something aswell?
GCS 0 Get Core status & faults
ALD 0,2? video blanks lots of eeprom activity. reload pixel map??
SAV 0-9999 set Fire threshold
GAV 2100 get Fire Threshold
BAC change uart protocol? careful
CBD Displays Recovery successful?
CBS Displays Saved successfully
LRD Displays Recovery successful?
LRS Displays Saved successfully?
LRE Displays Temperature Repair successful?
CBT Displays Calibration successful?
DBP ??? shutter clicks
DPI Show weird pixels
API Hide weird pixels
CCM ??
ASN 0-4 ??
GAB 4 vals ?? 3,-10,50,150
GAN 1 ??
GAR 11 vals ?? 10,10,5,20,35,50,70,90,120,150,180,,
GCM 6 values ??
GFV prints screen gray value?
GIT 200 ??
GTV Get the collected temp values?
PTS echoes but with extra stuff??
QYA 7170 Query Gray Info (information mode)
QYI 7124 Query Gray Average mode
QYM 7512 Query Gray Minimum mode
VTP 400-4000 ??
MTD U/S,0,0 ?? S answers with bytes, U upload bytes?
MTC U/S? ?? S answers with U,0,0, S doesnt.

return 0 invalid params:
STS ??
STT ??
SAC ??
SAH ??
SAS ??
SAT ??
SCX ?? displays crosshair but invalid params
SCY ?? displays crosshair but invalid params
GAC ??
GAH ??
GAS ??
GAT ??
GME ??
GPC ??
GPI ??
GPM ??
GTA ??
GTC ??
GTI ??
GTM ??
GTS ??
GTT ??

answer only:

BPM 0-1 stream ready? answers with 0 stop, 1 go, 2 when prompted
AVS 0,1
MEH
PWI 0-1 changing palette from wh to fire

unconfirmed (from dm60comm.so):
SDT 2024,03,15,14,30,25 Set Date Time with year,month,day,hour,minute,second
STS 1 Set Temperature Show display (0=off, 1=on)
SVA 2 Set Video Auto mode (0=manual, 2=auto)
SMP 0,1,1,0,100,150,200,250,300,350,90,25 Set Measurement Point (type,index,enable,mode,startX,startY,endX,endY,anchorX,anchorY,threshold,color)
STV Stop Temperature View measurements
SPF 5 Set Profile parameter
SVL -10 Set Video Left pan movement (signed value)
SVU -5 Set Video Up tilt movement (signed value)
SVD 5 Set Video Down tilt movement (signed value)
SSP 17,1,0 Set System Parameter (param_id,value,index) #46 temperature format 0 °C, 1 °F, 2 K
SCP Set Current Preset (save current position)
GCP Get Current Preset
STT 300,350 Set Temperature Threshold (low,high values *10)
SDC 1 Set Display Configuration parameter
GCS Get Current Status
GMM Get Memory Map information
GFV Get Frame Value (grayscale data)
GFZ Get Freeze Status
GSI 1 Get System Information (parameter=1)
GSS Get System Status
GSP 21,0 Get System Parameter (param_21=surround temp, value=0)
GTT Get Temperature Threshold range
GTV 1,3,10 Get Temperature Values (enable,type,count)
GNU Get Network Update status (response command)
FRZ Freeze current display frame
LIV Live mode (unfreeze display)
CAL Calibrate system
CCP 3 Call Current Preset (preset number 0-9)
APF 100 Auto Profile setting
MEH Measure Enhancement
BPT Built-in Test
MTC S,0 Measure Temperature Capture (S=start, 0=sequence)
MTG U,0,1024,<data> Measure Temperature Gray data transfer
MTD U,0,1024,<data> Measure Temperature Data transfer
UFP S,0,2048 Update Firmware Prepare (S=start, 0=offset, 2048=size)
UFD S,0,1024 Update Firmware Data transfer
BAB U Buffer operation (U=update)
TTH S,0 Temperature Threshold operation
IPP 192.168.001.102,255.255.255.000,192.168.001.001,192.168.000.001,9989,9998 IP Parameters (IP,netmask,gateway,DNS,port1,port2)
MAC 00:60:A9:10:00:01 MAC Address setting
SNP Set Network Parameters (response command)
QYI Query Gray Info (information mode)
QYA Query Gray Average mode
QYM Query Gray Minimum mode
GAI Get Alarm Info (response command)
YTC <data> Unknown command with data parameter
HTH
LRS
LRD
GAR
DRC
PTS
SCX
SCY
CBT
LRE
CBD
CBS
XXX
GSP
GTT
QYI
QYA
QYM

</syntaxhighlight>

==Secret Menu Overview==
The secret menus Main and System can be openend with the password '''+-MC+-'''

Its structured like this, not all variables have been figured out yet.

The format is Menu: submenu: submenu:

and for menu entries: Name, default value, command, description or messages that pop up.
 <syntaxhighlight lang="vb">
MAIN & SYSTEM PASS: +-MC+-

entries are NAME VALUE COMMAND DESC or if its a folder its just ":"

System:
System:
Gain 255 SCO
Bright 102 IBR
BenDi 100 ?
BenDiContrase 80 ?
DisMode 0 ?
Frequency 48hz (24,25,48,50)
DigitalOut 8-14bit 14bit, BT656(_P), ?, BT601
AutoFocus N ?
Line 1 ?
Ltemp0 11800 ?
LTemp1 11000 ?
HTemp0 9500 ?
HTemp1 8700 ?
DelayTime 0 ?
Enhance 0-1 ?
Enhanced E1 230 ?
FPA_Gain 12pF ? between 4 and 18 at random.
NUCEn N ?

Area:
SE 2 ASN 0-4 "Partition"
INT 200 INT "Points time"
VS 3161 SVS
VF 2800 SVF
Vtemp 1401 VTP
VtempArea Low ?
VtempBase 13500 ?
VtempStep -1 ?
VsStep 8 ?
DeadPixelModel preset / calculate
DP: Cursor to select dead pixels
X 360 position
Y 288 position
AutoBP: 50 Press C to start automatic dotting
Quit? Number of bad pixels 961& "Blind element replacement in progress"
Undo
R2: Save data? blind pixel replacement in progress
Replace Y N = DPI, Y = API
L: Reading parameters
S: Saving parameters

Debug:
Rectify N
DisplayGary N
TE N SDT
AutoE ? ?
AutoVS Y ?
VSGrayH 8000 ?
VSGrayL 7000 ?
Trends 1 ?
Shelter N ?
MotorCon 3 ?
SaveFactoryPara:
LanTyp EN ? LANGUAGE
DisplayMT N ?
Version:
PRJ D843 DLD640 ImLib, MTlib, Soft, Logic

BackDispose:
GammaEN 1 ?
Gain 1 ?
EnhanceEN 0 ?
Hpf_shift 5 ?
Hpf_thrd 5 ?
Enhance 150 ?
Lthrd 50 ?

Monitor:
Opens normal OSD

Alarm Set:
Alarm Switch Y ?
Alarm Mode No ?
Alarm Temperature -1°C ?
Reference Gray Y ?
Alarm Level 1L ?
Alarm Gray 65535 ?
Alarm PointNum 0 ?
Correct Gray 0 ?

Thermometry:
Data Collection 0 SMS
Interval 60 SCP
Ammount 90 SCT
Environment normal ?
Export:
Displays: Exportin normal temperature MTC data
Correction -1 ?
Emissivity 100 SEM
Calibration:
BlackbodyTemp -10 grabs a val from GAB
Save CBS
Cancel CBD
Correction:
BlackbodyTemp -10 Picks from the list GAR
Grayscale 0 SLG
Confirm LRE
Save LRS
Cancel LRD
Ninepoint measurement SMV

Cursor:
Cur N DRC enable cursor
X 320 SRP set cursor position
Y 240 SRP set cursor position

Main:
Auto 2 SAG Auto gain
G 211 SVC
B 10002 SVB
P 1 SWP polarity
Z X ?
Settings:
Image:
FI Y ?
FIValue 0 ? 0-31
Freeze N Freeze image
VE N SMR Vertical flip
HO N SMR Horizontal flip
AutoCali L same as rectify?
O IN internal or external
COM:
Opens UART menu
AvoidburnSwitch OFF enable anti burn in
ProtectedTime 10S duration
AvoidBurn 16383 threshold to trigger antiburn

</syntaxhighlight>

===Automatic Dead Pixels and Flatmap Correction===

It it possible to generate a new flat and dead pixel map automatically within the camera after flashing the cleared-map binary.
 

=====Dead pixels:=====
In the secret menu "System", navigate to Area - DeadPixelModel and set the AutoBP (sensitivity for auto bad pixel finding) to 50 or so. Then press C Button

This can take a while.
[[File:High emissivity peltier black body.jpg|thumb|A Peltier / TEC coated in Candle sood to give it a high emissivity surface. It can be cooled or heated by swapping the polarity. ]]

Afterwards, navigate to S: and press + to save it.
 

=====Flatfield:=====
In the Debug menu navigate to R2 and press +

now place something '''Cold''' infront of the Camera with a high emissivity. (it needs to fill the whole image)

Press '''+''', wait for it to says High temperature.

Place something '''Hot''' infront and press '''+''' again.

Afterwards, save with '''S:''' again.

Flatfield should now be calibrated
 <blockquote>Note: Not all dead pixels are auto detected or get removed. you can manually select them in the Dead pixel editor but its not known yet how to select and correct them.</blockquote>

 

==Using the Thermal module without Webserver==
[[File:Dali D8X3C Breakout board.png|thumb|Breakout board for D8X3C ]]
to use it, you need to interface it directly.

The module will put out a Analog video signal (High-Z, need to buffer when connecting it to 75Ohm Video input)

Also a 8 or 14bit or 8-bit BT656 output.

the header exposes the FPGA JTAG and UART aswell as 6 Hardware Keys to Navigate the OSD.

To interface, you need to make a adapter board with a DF12-50DS-0.5V(86) Docking socket.

The breakout board files can be found [https://oshwlab.com/gamerpaddy/d8x3c-backpack-usb here] but may be still work in progress.

 

==Sensor Pinout==
[[File:Dali DLD384 Sensor pinout basic.png|thumb|basic pinout of a DLD384]]
the pinout of the thermal sensor havent been analyzes much.

besides some supply and Control voltages, 3 clocks and a analog output have been found.

17.5MHz

14.705KHz

50Hz

Dali D8X3N Thermal Camera

2025-08-04T16:27:04Z

Gamerpaddy: /* Raw Viewer for the internal Webserver (recommended) */

=Dali D8X3N Thermal Camera Reverse Engineering=
 

===Introduction===
The [https://www.dali-irtech.com/productinfo/741567.html Dali D8X3N] Thermal Camera module comes in two versions, a 384x288 and 640x480 resolution, utilizing the [http://www.dali-tech.us/products/dld64017m-uncooled-infrared-fpa-detector-86.html DLD Series] of amorphous-Silicon Microbolometers.

They were mainly used in [http://www.dali-tech.us/products/dm60-w--online-body-temperature-thermal-imaging-camera-55.html Dali DM60-W] or WS-1 Body Temperature screening cameras in conjunction with a Black Body radiator set to 37°C to detect infected individuals at the start of the 2020 Covid Pandemic.
[[File:ICI FM320P Innerts.jpg|thumb|Internals. A TP-Link Switch, HikVision Visible Camera and the D8x3N Network thermal camera module]]
[https://infraredcameras.com/ ICI] rebranded these models as FM 320 P and FM 640 P, and distributed them on the local US market, but as the need for such Cameras exploded, those models were built with what was in stock.

So happens, that some of the FM 320 P Models had a DLD640 640x480 instead of a DLD384 384x288 Microbolometer in them, and just got their Firmware modified.

It also could be, because they have excessive amounts of bad pixels outside the 384x288 area, that they were binned to a lower grade.

Discussions about these Cameras started around 2022 in the [https://www.eevblog.com/forum/thermal-imaging/ici-and-dali-thermal-camera-software/ EEVBlog Forums.] when they started to appear secondhand and affordable.

Originally they were priced around US$ 20... 30.000 by ICI, and a unknown amount by Dali Tech.

The Modules specs according to the manufacturer are:

≤50..60mK@F1，300K，50Hz

17 or 25µm pixel pitch

Hisilicon SoC running Linux to provide Onvif and RTSP streams, analysis and a Web UI

 
[[File:Dali D8X3N Module.jpg|thumb|A real 384x288 model with a DLD384 sensor. notice the Productnumber ]]
ICI FM Cameras are found all over Online secondhand marketplaces for scrap Prices, as they are no longer needed.

But you never know, what are you getting. It could be a real DLD384 or the better DLD640 inside. Its a gamble.
 

======640x480 Imagers======
are labeled 22D843 Nxxxx and have a DLD640 sensor in it, they can be upgraded if they run the 384x288 firmware.

======384x288 Imagers======
are labeled 22D883Nxxxx and have a DLD384 sensor in it, they cannot be upgraded

 

==D8X3N Module closer look==
From now on, i will refer to the Thermal Imaging Module as TIM

On the front there is a 2 Element Germanium Lens of a unknown focal length and aperture.

It can be focus-adjusted when unscrewing the clamp around the housing. It can be focussed from infinity down to 10..20cm with some quality loss.
 The outter diameter of the Lens is 42mm with a 1 1/3 inch thread diameter of undetermined pitch.

Dimensions of the germanium elements are 21mm to 3 and 6mm and 14grams in weight.
[[File:Disassembled Thermal Camera Lens.jpg|thumb|Two element Germanium Lens of unknown focal length and aperture]]

The TIM is composed of 6 Stacked PCB modules, 3 of which are for the Web Server functionality. taking them off will give you the basic configuration of a [https://www.dalithermal.com/productinfo/741568.html Dali D8X3C] TIM<gallery>
File:Dali DLD640 Thermal Image Sensor.jpeg|DLD640 Sensor
File:Dali DLD384 Thermal Imaging Sensor.jpeg|DLD384 Sensor
File:Dali D8X3N Board1 Back.jpeg|Network & GPIO Board Back
File:Dali D8X3N Board1 Front.jpeg|Network & GPIO Board Front
File:Dali D8X3N Glue Board Back.jpeg|Board between Logic and IO Back
File:Dali D8X3N Glue Board Front.jpeg|Board between Logic and IO Front
File:Dali D8X3N SoC Board Back.jpeg|SoC Board back
File:Dali D8X3N SoC Board front.jpeg|SoC board front
File:Dali D8X3N FPGA Board Back.jpeg|FPGA Board of the D8X3C Thermal Imager including a PMIC
File:Dali D8X3N FPGA Board Front.jpeg|FPGA Board Front with Video DAC and SPI Flash
File:Dali D8X3N Sensor Power and ADC Board.jpeg|Sensor control and ADC board
File:Dali D8X3N Thermal Core Debug wiring.jpeg|Debug wiring for sniffing SPI and UART
</gallery>

===User Manual===
including pinout diagram and important data

can be found here https://archive.org/details/dali-d-8-x-3-cuser-manualen-v-1.0-1

==Viewing the Video Stream==
[[File:Onvif Device Manager ODM.png|thumb|ODM streaming the Thermal view]]
when first connecting it to power and Ethernet, the camera will have 192.168.1.102 as a Static ip.

If you are running a 192.168.0.x or .178.x net, you need to change it or add a subnet under windows ipv4 settings.

to view it, you can use VLC and the stream URL
rtsp://admin@admin:<camera ip>/ONVIFMedia
there is /ONVIFMedia /ONVIFMediaM and /ONVIFMediaS for different stream Profiles.

VLC is quite slow and delayed, rather use Onvif Device Manager ODM,

it has no delay and auto-detects cameras in the network.

Be sure to log in as user: admin pass: admin in ODM.

in there, you can also set you camera to DHCP under Network settings.

===Web Interface===
[[File:Dali D8X3N web interface.png|thumb|Since browsers cant display RTSP anymore, open in Edge and select IE Compatibility Mode.]]
the web interface can be accessed by opening the camera IP in a browser

login is:
user: admin pass: admin
You can set Temperature markers and areas, but without using the Black Body calibration source, your readings may be way off or not working.

 

====OSD====
there is a debug-login with
user: super pass: 871897
that lets you send Key commands to the Imager to navigate the OSD.

Setting the OSD to english is accomplished with option #11
[[File:Dali D8X3C OSD.png|thumb|OSD in english, if yours is Chinese. go to option #11 and click + or -]]

To acces some locked menus, press
+ - + - + -

The password for the locked System and Main menu is
+-MC+-

Be careful in the UART menu to not change the BAUD rate or Protocol, as your ability to control it via the Web API gets lost.

You need to reflash or solder buttons on the thermal core then.

==Viewing Raw Thermal Data from the Web API==
there is a hidden endpoint in the stream.so file that could be found while decompiling

accessing
[[File:Arduino Nano blink sketch thermal gif.gif|thumb|Arduino Nano running blink sketch while thermally recording it, notice the led and resistor on the right]]
<ip of camera>:5000/stream?Type=JPEG&Source=Jpeg&Mode=TCP
lets you download a JPEG. but there are more options available (not all have been tested)

we are mainly interessted in Raw thermal data.

====Source (Stream Type)====

*<code>Major</code> - Main video stream (channel 0)
*<code>Minor</code> - Sub video stream (channel 1)
*<code>MinorAV</code> - Sub video + audio stream
*<code>MajorAV</code> - Main video + audio stream
*<code>Jpeg</code> - JPEG snapshot stream
*<code>Raw</code> - Raw thermal data stream
*<code>YUV</code> - YUV raw video stream

====Type (Data Format)====

*<code>H264</code> - H.264 video encoding
*<code>JPEG</code> - JPEG image format
*<code>RAW</code> - Raw sensor data
*<code>QBOX</code> - Custom protocol format
*<code>FRAME</code> - Frame-based format

====Mode (Transport Protocol)====

*<code>TCP</code> - TCP streaming (default)
*<code>UDP</code> - UDP streaming
*<code>MUL</code> - Multicast streaming

====Quality Parameters====

*<code>Quality=[1-100]</code> - Video quality level
*<code>Frames=[number]</code> - Number of frames to send
*<code>Interval=[ms]</code> - Frame interval in milliseconds

====Network Parameters====

*<code>IPAddr=[ip]</code> - Client IP address for UDP/multicast
*<code>Port=[port]</code> - Client port for UDP/multicast
*<code>Heart-beat=[Yes/No]</code> - Enable/disable heartbeat

====Snapshot Parameters====

*<code>Snap=[Yes/No]</code> - Enable snapshot mode

 
====Raw Viewer for PC (Python)====
[[File:Dali D8X3N Raw Thermal viewer.png|thumb|Raw Data Viewer in python]]

To view the raw stream, i made a python program that converts the 14bit thermal data to a visible image.

it is low fps tho, due to bad optimizations.

rev1 first working version https://pastebin.com/dyNWDPT3

rev2 with temperature readout https://pastebin.com/u107Q85w

rev3 and onward will only be available directly as a Webpage on the Device (see below).

====Raw Viewer for the internal Webserver (recommended)====
It is also possible to use the Raw viewer directly in the browser.

To achieve this, the stream had to be proxied from port 5000 to 80 due to CORS.

luckily the internal lighttpd had the CGI module enabled, so piping it troug (using wget ... i know) worked with very low overhead.

To install, you need '''Terminal access''' to the Camera. see below.

optional for simplicity: '''ftp''' access

[[File:Dali D8X3N Webviewer.png|thumb|Web Raw Viewer with histogram (rev3)]]

Create the files and the code inside.

'''/app/web/webpages/raw.html''' https://pastebin.com/kaiXwAgD

and

'''/app/web/webpages/cgi-bin/proxy.cgi''' https://pastebin.com/vii1HXcU

then run
chmod +x /app/web/webpages/cgi-bin/proxy.cgi
'''restart''' your camera.

It should be accessible now trough '''http://<camera ip>/raw.html''' in the browser and click Start Stream

 <blockquote>performance may need improvement.</blockquote>

==Getting Root Terminal Access==
To access the Terminal you need to solder or plug in a UART connection to Connector J7 on the "Glue" board.

Pinout is (left to right) '''RX TX GND 3.3V Baud 115200 3.3V!'''

But the system will spam with debug messages, making patching the files a hard job unless you use "tftp" or "sed" commands.
 

====Enabling Telnet access to make patching easier====
[[File:Upgrade ici dali firmware updater.png|thumb|ICI Firmware updater software with modified firmware loaded]]

there is a easier way using a modified Firmware updater to enable Telnet temporarily to patch the Files.

Download the '''upgrade_ici.exe''' form [https://archive.org/details/fwupdate here] and run it.

Then you should be able to connect to it via Telnet.

The Login credentials are '''User: roo'''t '''Password: DLroot'''

 

===Patching Device===

===Patching the Web Server===
 

====Enabling Telnet and ftpd permanently====

This only works if you also patch the Thermal Camera module flash!

to permanently enable Telnet, go to '''/etc/init.d''' and edit '''S90app'''
vi S90app
in vi, move your cursor to the '''#''' at '''#telnetd''' and press x<blockquote>optional: enable ftp by removing the '''#''' at '''ftpd''' and adjust the path to / </blockquote>now press ''':''' and type '''wq''' and hit '''enter'''. this should be it.

====Patching the decoder and streamer to 640x480:====
go to /app and edit the mach.cfg

replace DL384 with D640 and edit the resolution to 640 480

(press i in vi to enter edit mode, press ESC to exit edit mode. :wq to write and quit.)

repeat that procedure for the dali.cfg

=====(optional) patching app.sh to prevent it from rebooting=====
edit the app.sh in /app and remove all "reboot" occasions to prevent the camera from rebooting if onvifserver, httpd or daliServer arent running for debugging purposes.

 

====Patching the Thermal Camera module====
To patch it, you need to disassemble everything down to the FPGA Board,

on the bottom there is a SPI SOIC8 Flash.

Use a CH341 EEPROM programmer (be sure to have a fixed or modified version to not put out 5V!, set it to 3.3V) and SOIC8 clamp.

Use NeoProgrammer (i used 2.2.0.10 but there are newer available, use the latest) and click Detect. It should find W25Q128 chips, select the FV one.

Dont forget to download a backup of your flash and save it !

Download the Binary "Dali 640x480 '''actual''' cleared pixelmap.bin" from #3 below and load it into NeoProgrammer,

Click Erase, Program and Verify.

This can take a while.

Your imager should start up right after assembly by hearing the shutter click.

==Hardware Hacking==

===Flash Contents===
On archive, click on show all files to download them.

<nowiki>#</nowiki>1 a Flash dump of the original downgraded D8X3N can be found [https://archive.org/details/dali-d-843n-flash-dump here]

<nowiki>#</nowiki>2 a Flash dump of a original 640x480 model can be found [https://archive.org/details/d-843-n-640x-480 here]

<nowiki>#</nowiki>3 a modified Flash dump of a 640x480 with cleared dead pixel map, flat map etc. can be found [https://archive.org/details/d-843-n-640x-480-cleared-pixelmap here]

a Flash dump of the web server SPI flash W25Q256JV can be found [https://archive.org/details/dm-60-webserver-flash-dump here] in case a bad firmware update caused a bootloop.

 

===Flash Binary Analysis===
The Flash IC is a Winbond 25Q128JV SPI Flash that contains the FPGA Bitstream, Deadpixel and Flatmap, aswell as the Device Settings.

a copy of the SPI Logic Capture at startup can be found [https://archive.org/details/dali-eeprom-capture here], the free software [https://www.dreamsourcelab.com/download/ DSView from DreamSourceLab] is required to view it.
[[File:Dali Thermal Imager SPI Flash capture.png|thumb|SPI Flash access while booting the Thermal Module]]

a approximation of the offsets resulted in this list:<syntaxhighlight lang="vb">
0x000000 - altera cyclone iv stuff
0x200000 - settings
0x280000 - Flat field correction map
0x4C0000 - Bad Pixel correctio nmap
0x580000 - image aswell? 36010 bytes
0x740000 - GUIX?
0x7C0000 - Strings for Gui?
0x800000 - another shorter GUIX
0x880000 - Strings for second gui?
0x8C0000 - GUIX
0x940000 - Strings for gui
0xE00000 - ?
0xE80000 - dzxg? short
0xEC0000 - crosshair.bmp
0xF40000 - 3DTM?
0xF80000 - fake? Bad pixel map BPRP
</syntaxhighlight> 

====Settings offset 0x200000====
The settings are read and written every startup, aswell when you close the OSD, sporadically and when executing the command MSV

these are some of the settings i could figure out by changing and watching the logic capture what changed.
 <syntaxhighlight lang="vb">
offset size Cmd
0x0 1 SAG (0-2) auto gain
0x2 2 SVB (0-16383) saved value is 16383 - SVB
0x4 2 SVC (0-1023) set exposure or gain
0x6 1 SSM image filtering
0x8 1 SEH image enhancement
0xA 1 SWP invert b/w polarity
0x14 1 SMR Flip
0x16 1 SMR Mirror
0x20 1 MENU Cal source 0 IN, 1 OUT
0x3A 1 MENU Enhance value 0-100
0x40 1 MENU Rectify (shutter 0 OFF, 1 L, 2 H)
0x50 1 MENU Language 0 english, 1 chinese, 2 russian
0xA2 - SCO set contrast gain
0xA4 - IBR set brightness
0xAE 2 MENU Fire Threshold
0xAC 1 SPA set color palette
0xE2 1 SMS display "collected 0/80" enabled
0xF8 1 SEM set emissivity
0x110 1 SRT set revise temp
0x116 1 SHD set humidity
0x118 1 SET set ambient temp
0x11A 1 STD set temp range
0x120 2 SLG -500 to 500?
0x124 2 SRD set distance
0x12C 1 SCP ???
0x130 2 SCT ???
</syntaxhighlight> 
[[File:Dali D8X3N Bad Pixel Map Viewer.png|thumb|Bad pixel map of a 640x512 sensor, about 0.56% of dead pixels in this map]]
So i let the AI create a [https://2476424.playcode.io/ Configurator page] that lets you change the Settings in your Flashdump to your liking
 

====Bad Pixel and Flatframe Maps 0x280000 and 0x4C0000====
Thermal cameras require a bad pixel and flat frame map to compensate for manufacturing inconsistencies.

unfourtainly, the maps of the downgraded cameras only contain enough data for a 384 model, not the full 640.

at offset 0xF80000 there is a BPRP which was mistaken at first as the Bad pixel map, it could just be a mask to where to apply the offset maps, as its either 0x0 or 0x1.

The [https://2477569.playcode.io/ Viewer Page] is written in JS and does not require any special dependencies, it can run as a plain html file offline.

There still needs to be work done to create own maps and flatfields but the cameras are still very capable and useable with fully cleared maps.

To clear the maps, just go to these offsets and fill with values around 0x3F or 0x0 for total length of X Resolution x Y Resolution x 2 bytes (0x96000 for 640x480)

[[File:Dali D8X3N Flat Field Map Viewer.png|thumb|Flat Field viewer]]

==Dali Commands==
To control the TIM you can either use Pelco or Dali command set. By default the Dali commandset is used at 38400 BAUD.

Those commands consist of a 0x02 start byte followed by two length Bytes, then the actual command which is allways 3 uppercase Letters in ASCII (eg. KBD for keyboard) followed by a comma and the values.

Some commands take multiple values, some dont. But you allways have to send the comma after the Command.

The camera will answer with the Command and 0, 1 or 2. Sending no value counts as zero.
0 is invalid parameters, too few or out of range

1 is OK, valid command

2 is Invalid command

Commands can be sent trough the Web server using the URL Api endpoint or directly trough the UART port.

(keyboard, C button, causes the shutter to do a calibration)
<camera ip>/cgi-bin/dmcmd?Command=KBD,C
Listening to the answer can be done while being in the Linux shell and typing
cat /dev/ttyAMA2 | strings

By bruteforcing the UART with AAA to ZZZ a list of Commands could be obtained, but some with unknown Parameters or functionality yet. including some from a decompiled DM60comm.so module found in /app/modules folder.<syntaxhighlight lang="vb">
KBD KEY Keyboard (F S M C + -)
SSM 0-1 Image Filtering Off/On
GSM 0 Image filter status
SEH 0-1 Image Enhancement Off/On
GEH 0-1 Image enhancer status
SCO 0-255 Set Gain (locked when SAG auto gain is on)
GCO 0-255 Get gain
INT 15-320 set actual gain? not just contrast sometimes disabled?
IBR 0-255 Set brightness
GBR 0-255 Get brightness
SMR 0-3 Mirror mode bit0=horizontal, bit1=vertical
GMR 0 Get rotation/flip
SDT 0-1 displays temp=44.65°C osd, but webserver sends date/time to the cam there....
GDT 0-1 Get temp display active?
GPT Display temp oft SDT
GNU 0-1 Get Shutter closed/open
SNU 0-1 Shutter close / open
STD 0-1 Set Range 0: -20-180°C 1: 100-600°C
GTD 0-1 Get Range
SET °C Set Ambient temperature
GET °C Get Ambient temperature
SEM 0-100 0-1 set emissivity x100
GEM 0-100 Get Emissivity
SRT °C Set revise temperature -100-100 -10-10°
GRT °C Get revise temperature
SRD 100 Set Distance 4.4m x100
GRD 100 Get Distance
SHD 0-100 Set Humidity
GHD 55 Get Humidity
SWP 0-1 invert s/w polarity image
GWP 1 is inverted?
SPA 0-10? Set color palette
GPA 3 white hot
SMV 0-1 Show temperature 3x3 grid?? in combination with GTV maybe
GMV 0
SMS 0-1 displays "collected 0/<number set by SCT>" by SCP delay "saves the daily number of highest temperatures?"
GMS 0
SCT 1-500 sets the amount of "collected" points for SMS
GCT 80
SCP 5-60 "collected" delay in seconds for SMS
GCP 60
SAG 0-2 Auto brightness / gain
GAG 0
SLR 0-9 ???
GLR 0
SRP 0,0 - 639,479 set crosshair position
GRP 320,240 get crosshair position
DRC 0-1 Show crosshair
SLG -500-500 ??
GLG
SCE text ??
GCE 0
SCB text ??
GCB 0
SVB 0-16383 adc offset, exposure? good at 9650
GVB 6733 value is 16383 minus SVB
SVC 1-1023 set contrast but better
GVC 260
SVF 100-? ?? video freaks out 3400 seems good
SVS 100-? ?? video freaks out 3300 seems good
SOT 0-1 ?? sensor supply, looks weird when off.
SZM 1-4 ?
GZM 1
MSV save settings too eeprom
ASV Saves something aswell?
GCS 0 Get Core status & faults
ALD 0,2? video blanks lots of eeprom activity. reload pixel map??
SAV 0-9999 set Fire threshold
GAV 2100 get Fire Threshold
BAC change uart protocol? careful
CBD Displays Recovery successful?
CBS Displays Saved successfully
LRD Displays Recovery successful?
LRS Displays Saved successfully?
LRE Displays Temperature Repair successful?
CBT Displays Calibration successful?
DBP ??? shutter clicks
DPI Show weird pixels
API Hide weird pixels
CCM ??
ASN 0-4 ??
GAB 4 vals ?? 3,-10,50,150
GAN 1 ??
GAR 11 vals ?? 10,10,5,20,35,50,70,90,120,150,180,,
GCM 6 values ??
GFV prints screen gray value?
GIT 200 ??
GTV Get the collected temp values?
PTS echoes but with extra stuff??
QYA 7170 Query Gray Info (information mode)
QYI 7124 Query Gray Average mode
QYM 7512 Query Gray Minimum mode
VTP 400-4000 ??
MTD U/S,0,0 ?? S answers with bytes, U upload bytes?
MTC U/S? ?? S answers with U,0,0, S doesnt.

return 0 invalid params:
STS ??
STT ??
SAC ??
SAH ??
SAS ??
SAT ??
SCX ?? displays crosshair but invalid params
SCY ?? displays crosshair but invalid params
GAC ??
GAH ??
GAS ??
GAT ??
GME ??
GPC ??
GPI ??
GPM ??
GTA ??
GTC ??
GTI ??
GTM ??
GTS ??
GTT ??

answer only:

BPM 0-1 stream ready? answers with 0 stop, 1 go, 2 when prompted
AVS 0,1
MEH
PWI 0-1 changing palette from wh to fire

unconfirmed (from dm60comm.so):
SDT 2024,03,15,14,30,25 Set Date Time with year,month,day,hour,minute,second
STS 1 Set Temperature Show display (0=off, 1=on)
SVA 2 Set Video Auto mode (0=manual, 2=auto)
SMP 0,1,1,0,100,150,200,250,300,350,90,25 Set Measurement Point (type,index,enable,mode,startX,startY,endX,endY,anchorX,anchorY,threshold,color)
STV Stop Temperature View measurements
SPF 5 Set Profile parameter
SVL -10 Set Video Left pan movement (signed value)
SVU -5 Set Video Up tilt movement (signed value)
SVD 5 Set Video Down tilt movement (signed value)
SSP 17,1,0 Set System Parameter (param_id,value,index) #46 temperature format 0 °C, 1 °F, 2 K
SCP Set Current Preset (save current position)
GCP Get Current Preset
STT 300,350 Set Temperature Threshold (low,high values *10)
SDC 1 Set Display Configuration parameter
GCS Get Current Status
GMM Get Memory Map information
GFV Get Frame Value (grayscale data)
GFZ Get Freeze Status
GSI 1 Get System Information (parameter=1)
GSS Get System Status
GSP 21,0 Get System Parameter (param_21=surround temp, value=0)
GTT Get Temperature Threshold range
GTV 1,3,10 Get Temperature Values (enable,type,count)
GNU Get Network Update status (response command)
FRZ Freeze current display frame
LIV Live mode (unfreeze display)
CAL Calibrate system
CCP 3 Call Current Preset (preset number 0-9)
APF 100 Auto Profile setting
MEH Measure Enhancement
BPT Built-in Test
MTC S,0 Measure Temperature Capture (S=start, 0=sequence)
MTG U,0,1024,<data> Measure Temperature Gray data transfer
MTD U,0,1024,<data> Measure Temperature Data transfer
UFP S,0,2048 Update Firmware Prepare (S=start, 0=offset, 2048=size)
UFD S,0,1024 Update Firmware Data transfer
BAB U Buffer operation (U=update)
TTH S,0 Temperature Threshold operation
IPP 192.168.001.102,255.255.255.000,192.168.001.001,192.168.000.001,9989,9998 IP Parameters (IP,netmask,gateway,DNS,port1,port2)
MAC 00:60:A9:10:00:01 MAC Address setting
SNP Set Network Parameters (response command)
QYI Query Gray Info (information mode)
QYA Query Gray Average mode
QYM Query Gray Minimum mode
GAI Get Alarm Info (response command)
YTC <data> Unknown command with data parameter
HTH
LRS
LRD
GAR
DRC
PTS
SCX
SCY
CBT
LRE
CBD
CBS
XXX
GSP
GTT
QYI
QYA
QYM

</syntaxhighlight>

==Secret Menu Overview==
The secret menus Main and System can be openend with the password '''+-MC+-'''

Its structured like this, not all variables have been figured out yet.

The format is Menu: submenu: submenu:

and for menu entries: Name, default value, command, description or messages that pop up.
 <syntaxhighlight lang="vb">
MAIN & SYSTEM PASS: +-MC+-

entries are NAME VALUE COMMAND DESC or if its a folder its just ":"

System:
System:
Gain 255 SCO
Bright 102 IBR
BenDi 100 ?
BenDiContrase 80 ?
DisMode 0 ?
Frequency 48hz (24,25,48,50)
DigitalOut 8-14bit 14bit, BT656(_P), ?, BT601
AutoFocus N ?
Line 1 ?
Ltemp0 11800 ?
LTemp1 11000 ?
HTemp0 9500 ?
HTemp1 8700 ?
DelayTime 0 ?
Enhance 0-1 ?
Enhanced E1 230 ?
FPA_Gain 12pF ? between 4 and 18 at random.
NUCEn N ?

Area:
SE 2 ASN 0-4 "Partition"
INT 200 INT "Points time"
VS 3161 SVS
VF 2800 SVF
Vtemp 1401 VTP
VtempArea Low ?
VtempBase 13500 ?
VtempStep -1 ?
VsStep 8 ?
DeadPixelModel preset / calculate
DP: Cursor to select dead pixels
X 360 position
Y 288 position
AutoBP: 50 Press C to start automatic dotting
Quit? Number of bad pixels 961& "Blind element replacement in progress"
Undo
R2: Save data? blind pixel replacement in progress
Replace Y N = DPI, Y = API
L: Reading parameters
S: Saving parameters

Debug:
Rectify N
DisplayGary N
TE N SDT
AutoE ? ?
AutoVS Y ?
VSGrayH 8000 ?
VSGrayL 7000 ?
Trends 1 ?
Shelter N ?
MotorCon 3 ?
SaveFactoryPara:
LanTyp EN ? LANGUAGE
DisplayMT N ?
Version:
PRJ D843 DLD640 ImLib, MTlib, Soft, Logic

BackDispose:
GammaEN 1 ?
Gain 1 ?
EnhanceEN 0 ?
Hpf_shift 5 ?
Hpf_thrd 5 ?
Enhance 150 ?
Lthrd 50 ?

Monitor:
Opens normal OSD

Alarm Set:
Alarm Switch Y ?
Alarm Mode No ?
Alarm Temperature -1°C ?
Reference Gray Y ?
Alarm Level 1L ?
Alarm Gray 65535 ?
Alarm PointNum 0 ?
Correct Gray 0 ?

Thermometry:
Data Collection 0 SMS
Interval 60 SCP
Ammount 90 SCT
Environment normal ?
Export:
Displays: Exportin normal temperature MTC data
Correction -1 ?
Emissivity 100 SEM
Calibration:
BlackbodyTemp -10 grabs a val from GAB
Save CBS
Cancel CBD
Correction:
BlackbodyTemp -10 Picks from the list GAR
Grayscale 0 SLG
Confirm LRE
Save LRS
Cancel LRD
Ninepoint measurement SMV

Cursor:
Cur N DRC enable cursor
X 320 SRP set cursor position
Y 240 SRP set cursor position

Main:
Auto 2 SAG Auto gain
G 211 SVC
B 10002 SVB
P 1 SWP polarity
Z X ?
Settings:
Image:
FI Y ?
FIValue 0 ? 0-31
Freeze N Freeze image
VE N SMR Vertical flip
HO N SMR Horizontal flip
AutoCali L same as rectify?
O IN internal or external
COM:
Opens UART menu
AvoidburnSwitch OFF enable anti burn in
ProtectedTime 10S duration
AvoidBurn 16383 threshold to trigger antiburn

</syntaxhighlight>

===Automatic Dead Pixels and Flatmap Correction===

It it possible to generate a new flat and dead pixel map automatically within the camera after flashing the cleared-map binary.
 

=====Dead pixels:=====
In the secret menu "System", navigate to Debug - DeadPixelModel and set the AutoBP (sensitivity for auto bad pixel finding) to 50 or so. Then press C Button

This can take a while.
[[File:High emissivity peltier black body.jpg|thumb|A Peltier / TEC coated in Candle sood to give it a high emissivity surface. It can be cooled or heated by swapping the polarity. ]]

Afterwards, navigate to S: and press + to save it.
 

=====Flatfield:=====
In the Debug menu navigate to R2 and press +

now place something '''Cold''' infront of the Camera with a high emissivity. (it needs to fill the whole image)

Press '''+''', wait for it to says High temperature.

Place something '''Hot''' infront and press '''+''' again.

Afterwards, save with '''S:''' again.

Flatfield should now be calibrated
 <blockquote>Note: Not all dead pixels are auto detected or get removed. you can manually select them in the Dead pixel editor but its not known yet how to select and correct them.</blockquote>

 

==Using the Thermal module without Webserver==
[[File:Dali D8X3C Breakout board.png|thumb|Breakout board for D8X3C ]]
to use it, you need to interface it directly.

The module will put out a Analog video signal (High-Z, need to buffer when connecting it to 75Ohm Video input)

Also a 8 or 14bit or 8-bit BT656 output.

the header exposes the FPGA JTAG and UART aswell as 6 Hardware Keys to Navigate the OSD.

To interface, you need to make a adapter board with a DF12-50DS-0.5V(86) Docking socket.

The breakout board files can be found [https://oshwlab.com/gamerpaddy/d8x3c-backpack-usb here] but may be still work in progress.

 

==Sensor Pinout==
[[File:Dali DLD384 Sensor pinout basic.png|thumb|basic pinout of a DLD384]]
the pinout of the thermal sensor havent been analyzes much.

besides some supply and Control voltages, 3 clocks and a analog output have been found.

17.5MHz

14.705KHz

50Hz