Over The Air Updates For Your Arduino

An Arduino and a data radio can make a great remote sensor node. Often in such situations, the hardware ends up installed somewhere hard to get to – be it in a light fitting, behind a wall, or secreted somewhere outdoors. Not places that you’d want to squeeze a cable repeatedly into while debugging.

[2BitOrNot2Bit] decided this simply wouldn’t do, and decided to program the Arduinos over the air instead.

Using the NRF24L01 chip with the Arduino is a popular choice to add wireless communications to a small project. By installing one of these radios on both the remote hardware and a local Arduino connected to the programming computer, it’s possible to remotely flash the Arduino without any physical contact whatsoever using Optiboot.

The writeup is comprehensive and covers both the required hardware setup for both ends of the operation as well as how to install the relevant bootloaders. If you’re already using the NRF24L01 in your projects, this could be the ideal solution to your programming woes. Perhaps you’re using a different platform though – like an Arduino on WiFi? Don’t worry – you can do OTA updates that way, too.

17 thoughts on “Over The Air Updates For Your Arduino

  1. Seems horrendously complicated, my solution to this issue was to simply use a bluetooth->serial module (make sure you have one which hast the DTR pin broken out and working, not all of them do) connected to the remote arduino. All that is needed to communicate or program the arduino is to select the bluetooth serial port in the arduino IDE and hit program.

    The one tricky part was that with the default pin on the usb->bluetooth adaptor it meant anyone could come and reprogram the device, so I ended up going down the rabbit hole of reflashing the bluetooth adapter to change its pin. This setup doesn’t seem to implement any security whatosever so I suppose that wouldn’t be an issue for this use case.

    1. I used HC-05 in master mode on a project (unreachable). To program it, all it needs to do it enter slave mode (send commands for bootloader baudrate + save an eeprom parameter so main program knows what to do when repowered).
      Repowering changes the HC-05 to slave, then the device waits for any input on serial port and triggers watchdog reset when there is input (and saves different value to the eeprom to tell the main program re-enter master mode+higher baudrade for the HC-05 on next powerup and resume main program).
      The bootloaded needed to be modified to reset the watchdog flags so it does not reset during programming.
      Avrdude has no problems with the slight delay when the thing resets and enters bootloader.

      I got avrdude on my phone and made an alias so with single command a hexfile is sent over bluetooth (SPP serial mirror).
      Best thing is the it is unbrickable by bad transmission, if the transmission fails, the bootloader stays active as does the slave mode.
      Only way to brick it is to send a bad/wrong program to it.

      1. True, would love to see a tutorial about it, will help much.
        I used rf24 for couple of reasom, range, protocol, communication is many to many address based, grater control on power and protocol stack (there is none, just writing to registers) and I did not wNted to add to each station a BT module as well, will not fit in place. Also.did not wanted to use wifi due to the radiation, my rf24 is in listening mode.99% of the time== no transmission == no radiation

    2. Yeah, today I wouldn’t use an Arduino and an nRF but at the point I wrote the optiboot extension for OTA flashing this was the cheapest option available and what I had at hand: $1 for the pro mini + $0.50 for the nRF module. This must have been two years ago. The tutorial linked in this article uses a github fork of a fork of my fork of optiboot but there seem to be no major changes, only file movement and pin assignment.

      1. Yes, I used your code, also sent yo emails on the way for question ???????? thank you so much for the project, Took me time.to.figure out how to use your code, So I wrote a tutorial about it to help other that might want to use it, I linked your git in my article (or the one that forked you)
        I made some changes but mostly for debug, led blinking (port manipulation to make it fast and not change the timing).
        Mostly to see that the code is doing what I was thinking it should ????

  2. Just as a alternative voice, I used Ariadne bootloader, reflash over the network, hacked it about a bit to secure the facility with a PIN on the webservers they run anyway to give basic security but its still tftp based and everything is plain text across the lan it doesn’t count for that much, but I don’t connect arduino’s in places they should be exposed to untrusted traffic anyway. You’ve only got to make one error…

  3. This is a really nice solution! I’ve seen other projects (like the Moteino over at LowPowerLab) that have some external flash for storing the new firmware, which then gets flashed to the main program flash by a modified boooader. This way, though, you can avoid extra components!

    1. What sort of range are you getting? I quite like Moteino for the 1km range and the 900 MHz radio works through metal buildings where 2.4 GHz does not, though it’s comparing apples to oranges on all fronts.

    2. It’s definitely starting to feel like we have better options now.

      But there are also objectively better ARM boards than the Raspberry Pi, and yet every 4th project on HaD is using one. People tend to stick with what they know, even if there are better options out there, so long as they can accomplish what they’re trying to do.

      I don’t think the Arduino is going away anytime soon, even if it’s increasingly the “wrong” choice for a given project.

      1. The reason why people tend to stick with what they know is mostly because they’ve invested time and money into their set of tools. If for every project you’d go for the best choice, you’d most likely never get things done. You’d need to invest in how things work, which may take a lot of time to do it right. Sometimes it’s faster to use “the worse” option but doing it while knowing what you are doing, then using something new and hitting every obstacle on the way to success. Finding every bug in the new compiler for the new board… using the best choice in most cases means finding the bugs first. Solving problems nobody has found yet… because it is to new.

        Also when you have a drawer full of raspberry pi or arduinos you’d most likely do not throw them away, do you?

        There is always a better option, but in most cases it is better to stick to what you already know. Personally, I do not want to use the best stuff for the job unless it is really really necessary. Simply because the “old stuff” is proven technology (it works because other people have found bugs for you and solved them already). It is cheaper, and widely available. You can find much more info and examples for in on the internet.

        So in short… if better isn’t always better.

        1. If this was the 1980’s, I might agree with you.

          But nobody is “finding new bugs in the compiler” when they copy their Python script over from the Pi to the BeagleBone. Or losing ” invested time and money” when they use their existing Arduino IDE and code on an ESP.

          These are largely drop-in replacements for older tech, and in some cases (such as ESP vs Arduino + WiFi shield) considerably cheaper than their predecessors.

          So no, there’s nothing hold them back other than habit. Nearly any technical or monetary excuse is hand waving to try and justify a resistance to change.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.