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 · 2 Days 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.

dj41354 · 8 Hours Ago

That's a lot of good information.. thank you. My target is an 8bit PIC18F46K22 and doesn't have the ability to hold a complete image for verification before programming. My current bootloader sends & programs in small blocks (64bytes) as the blocks come in. They're never sent out of order, and sending is paced such that the programming of the 64byte block always finishes before the next block is received.. that means there's no handshake necessary and the sending is simply streamed until complete. It's a Intel HEX file that gets sent, so there are embedded checksums that allow the bootloader to check the data, and flag a bad block to stop the programming process.. but if that happens in the middle, it is possible to brick the target.. and while it does occasionally happen, it's really rare. It sounds like the RDM based bootloading might be more susceptible to issues than what I'm currently using?.. I'll continue to look into this.. Thanks again. DougJ

admin · 7 Hours Ago

If your bootloader has the ability to perform E1.37-4 then you'll at least be able to make another attempt at uploading firmware to it again (assuming the controller process isn't broken).

All the moving lights at High End Systems for many years completely erased the operating flash during the upload process. If the upload failed, the unit would be functionally bricked but you could always run the process again while it is in boot code and get a good upload that way.

3 Days Ago	#1
dj41354 Member Join Date: Nov 2015 Posts: 34	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

8 Hours Ago	#3
dj41354 Member Join Date: Nov 2015 Posts: 34	That's a lot of good information.. thank you. My target is an 8bit PIC18F46K22 and doesn't have the ability to hold a complete image for verification before programming. My current bootloader sends & programs in small blocks (64bytes) as the blocks come in. They're never sent out of order, and sending is paced such that the programming of the 64byte block always finishes before the next block is received.. that means there's no handshake necessary and the sending is simply streamed until complete. It's a Intel HEX file that gets sent, so there are embedded checksums that allow the bootloader to check the data, and flag a bad block to stop the programming process.. but if that happens in the middle, it is possible to brick the target.. and while it does occasionally happen, it's really rare. It sounds like the RDM based bootloading might be more susceptible to issues than what I'm currently using?.. I'll continue to look into this.. Thanks again. DougJ Last edited by dj41354; 8 Hours Ago at 05:09 PM. Reason: clarity

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

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

2 Days 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.

7 Hours Ago	#4
admin Administrator Join Date: Feb 2006 Posts: 2	If your bootloader has the ability to perform E1.37-4 then you'll at least be able to make another attempt at uploading firmware to it again (assuming the controller process isn't broken). All the moving lights at High End Systems for many years completely erased the operating flash during the upload process. If the upload failed, the unit would be functionally bricked but you could always run the process again while it is in boot code and get a good upload that way.