E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM General Implementation Discussion (http://www.rdmprotocol.org/forums/forumdisplay.php?f=4)
-   -   Firmware download (http://www.rdmprotocol.org/forums/showthread.php?t=1014)

kster June 23rd, 2009 12:10 AM

Firmware download
I was wondering of there is, or will be, a standard way to download firmware into a device using the RDM protocol? It would be nice to have a standard way that can be implemented in the controller so it can be used for all devices of any manufacture (like in the ArtNet protocol).



sblair June 23rd, 2009 10:50 AM


At this point it doesn't look like there will likely be a standardized method of doing this, at least not anytime on the horizon. We spent a lot of effort on this and had several draft versions but never reached concensus.

The issue was that there are too many different architectures out there and to make a single implementation that was robust enough to be reliable and not risk leaving a product doorstopped with nothing other than boot code made the process a bit cumbersome for some.

Ultimately what happened was that everyone adopted their own manufacturer-specific way of doing it and as a result interest was lost by most involved with it as they then had their own solution.

Firmware uploads are probably best left being a manufacturer-specific implementation that way there isn't the risk of someones bad implementation on the controller side erasing the flash and leaving a product stuck in boot without completing the upgrade process.

kster June 23rd, 2009 01:01 PM


Thanks for the reply.

I understand the arguments and the difficulties, but we, as developers, make it our customers even more difficult. Now they must use different and special software to perform the update. When we would choose a good microprocessor, and this is now a lot easier and cheaper then 5 years ago, we could solve the problem relative easy. So it may be a good idea to place the issue back on the wish list and start thinking again, with the lasted technology in mind, to solve the problem. Maybe the solution will not be the fasted possible or the most elegant, but you can make it very robust without a problem. With the current flash, eeprom, ram sizes, there is also no more need for a very restricted bootloader. This standard feature can then be implemented in future products, so that there will come no more(or less) manufacture specific solutions and our customers can be better off.

In the mean time I will also create my own solution.



sblair June 23rd, 2009 03:03 PM


The issue is that it takes people that are interested in solving it to attend and participate in the meetings to develop it. It is not a trival process. Right now there is not anyone that is interested in leading or investing effort in that project, that is why it died.

dangeross June 25th, 2009 05:13 PM

I agree the a firmware download addition to RDM would be very difficult to implement in a way that would useful to all user's with the different hardware requirements of all the different manufactures. I think that a microFTP type addition could receive more support. It could be used to allow the storage/retrieval of a file containing the fixture personality (new XML fixture personality standard ?) and of course a firmware image could be downloaded and then a manufacturer specific PID used to cause the update from the loaded file.

sblair June 28th, 2009 07:41 PM

We also discussed and explored doing a TFTP style basic implementation but there wasn't enough interest from people in working on it, so that is why we ultimately shelved it for now.

fgramme November 9th, 2009 03:06 AM

Hi all,

Could anyone tell me about a way to implement a remote software upgrade? I mean, do I have to keep a kind of RDM-like frame, with a 0xCC startcode? I guess it could be harmful for other devices on the bus...

Then what are your advices? Is there any prefered startcode or way to achieve it?

Best regards,


sblair November 27th, 2009 12:52 PM


I would highly suggest implementing as using manufacuturer-specific PID's within RDM. See Section in RDM.

Using the standard RDM frame and defining your own messages within that you can implement firmware uploads. The advantage of doing it within RDM packets and start code is that you can then take advantage of all the other infrastructure that exists out there such as RDM splitters.


fgramme November 29th, 2009 10:07 AM


Thanks for your answer. I agree this is probably the smartest way. I can't believe I haven't thought of it! :)


sblair December 8th, 2009 04:51 PM


I just have the benefit of living and breathing this for the last 10 years now is all :)

dj41354 December 12th, 2019 12:51 PM

Hello rdmprotocol..
Long time, no post.. probably because our RDM implementation seems to be mostly ok.. in large part to the help I've received here. many continued thanks.. as always!. I saw this thread and am interested in any information anyone can provide about firmware updating over RDM.. Has there been any activity worth mentioning since this last post 10 years ago?! Thanks in advance. Also, is there any plan for a Dallas Plugfest in the next year? It's been a while and it'd probably be good to go again... Thanks! dougj

ericthegeek December 13th, 2019 01:53 PM

The E1.37-4 document for file transfer is moving, although I've lost track of exactly where it is. It's been through at least one public review. There will be a plugfest in 2020. The plugfest is often held in Dallas in July, but the July 2020 meetings are in NYC. I suspect the next plugfest will be October 2020. It's not been formally scheduled yet, so watch the TSP meeting schedule. Come visit us, it'd be nice to see you again.

All times are GMT -6. The time now is 12:54 AM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2021, vBulletin Solutions, Inc.