E1.37-4 File Transfer Control - E1.20 RDM (Remote Device Management) Protocol Forums

dj41354 · 3 Days Ago

I'm looking into E1.37-4 File Transfer Control for the purpose of bootloading using RDM. I'm curious if anyone has implemented this on a Responder, and what they think about it. I'm particularly interested in issues of robustness, and bricking. We currently have a custom bootloader on our fixtures that does not use RDM.. mitigating these issues was top of the list of requirements. Also, are console manufacturers starting to design this File Transfer Control capability into their consoles?.. is it commonplace?, or not yet? Thanks in advance for any information! DougJ

daria22 · 1 Day Ago

Hi Doug,
We've done some work with E1.37-4 for RDM-based bootloading, so I can share a few thoughts. Robustness and avoiding bricking really come down to your responder-side design: keep the bootloader itself in protected/immutable flash so a failed transfer can never overwrite it, and use an A/B (dual-bank) image scheme so the new firmware is only marked valid after it's fully received and its checksum/CRC verifies. That way an interrupted or corrupted transfer just falls back to the last known-good image.
The file transfer PIDs give you the framing for chunked, acknowledged transfers, but you'll want solid handling of retries, timeouts, and out-of-order/dropped packets on top of that, since DMX/RDM lines can be noisy in the field.
On the console side, adoption is still fairly limited — most controllers don't yet expose full E1.37-4 file transfer as a built-in feature, so in practice a lot of people still drive it from a dedicated tool or updater rather than the lighting console itself. That may change as the standard matures.
Hope that helps — happy to compare notes.

3 Days Ago	#1
dj41354 Member Join Date: Nov 2015 Posts: 33	E1.37-4 File Transfer Control I'm looking into E1.37-4 File Transfer Control for the purpose of bootloading using RDM. I'm curious if anyone has implemented this on a Responder, and what they think about it. I'm particularly interested in issues of robustness, and bricking. We currently have a custom bootloader on our fixtures that does not use RDM.. mitigating these issues was top of the list of requirements. Also, are console manufacturers starting to design this File Transfer Control capability into their consoles?.. is it commonplace?, or not yet? Thanks in advance for any information! DougJ

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
RDM Appendix A #define header file attached	sblair	RDM General Implementation Discussion	12	August 1st, 2012 04:38 AM
ESTA Control Protocols Plugfest Returns in July!	sblair	RDM General Implementation Discussion	0	June 21st, 2010 04:29 PM
ESTA Control Protocols Plug Fest Returns in January!	sblair	RDM General Implementation Discussion	0	December 10th, 2009 01:11 PM

1 Day Ago	#2
daria22 Junior Member Join Date: Jul 2026 Posts: 2	Hi Doug, We've done some work with E1.37-4 for RDM-based bootloading, so I can share a few thoughts. Robustness and avoiding bricking really come down to your responder-side design: keep the bootloader itself in protected/immutable flash so a failed transfer can never overwrite it, and use an A/B (dual-bank) image scheme so the new firmware is only marked valid after it's fully received and its checksum/CRC verifies. That way an interrupted or corrupted transfer just falls back to the last known-good image. The file transfer PIDs give you the framing for chunked, acknowledged transfers, but you'll want solid handling of retries, timeouts, and out-of-order/dropped packets on top of that, since DMX/RDM lines can be noisy in the field. On the console side, adoption is still fairly limited — most controllers don't yet expose full E1.37-4 file transfer as a built-in feature, so in practice a lot of people still drive it from a dedicated tool or updater rather than the lighting console itself. That may change as the standard matures. Hope that helps — happy to compare notes.