FTDI adapter now available

Some people have been asking for FTDI adapters for programming Moteinos to avoid having to buy them from another store and hence pay shipping/handling twice. So I created one. It’s actually based on the Adafruit FTDI-friend which was a very good design. Here are the features:

  • 5V power level (default) – adjustable to 3V
  • 3V logic level (default) – adjustable to 5V
  • pin 6 is RTS (default) – adjustable to DTR
  • RX/TX LEDs
  • The pinout is standard [ GND - CTS - VCC - TX - RX - RTS ] and will work with any Arduino clone that has this as a programming interface.
  • compact layout

The underside of the board contains some jumpers that are shorted for the default settings mentioned above (5V power level, 3V logic level, pin6 = RTS) – these are standard settings that come with the FTDI cables and should work in most instances. Hackers may want to switch these settings – for this the default shorts need to be cut with a razor blade and the other jumper needs to be shorted by soldering the jumper pads together.

I’m working on sourcing some USB cables to go with these soon. Here are more images and the schematic:

DSC_0640 DSC_0643_logo
DSC_0641 Schematic

Wireless programming update

The initial code commit for wireless programming was a little sluggish and the performance wasn’t very good. I had to add delays to make sure everything was synch-ed and the protocol was working. The result was a rather slow wireless upload of a new sketch, especially if it was a large sketch. But it worked…

Today I worked on improving the protocol and was able to cut down the over-the-air upload time by a factor of ~5. The gains are mostly from improved serial communication. This will still take about twice as long as normal sketch uploads by means of an FTDI adapter. For instance, a 9,8Kbyte sketch takes me about 11 seconds to upload directly to a Moteino using an FTDI cable; wirelessly programming that same sketch takes about 22 seconds. Not bad given how involved the whole handshaking protocol works. And much better than almost 1 minute with the old code. So I’m classifying this new release as a beta. More improvements or bug fixes might be added later, but it’s definitely a functional release. I’ve uploaded different sketches of around 10KB several times without a glitch.

The wireless sketches examples (gateway and node) and the python script are in their github repo. The SPIFlash library was also updated (the WirelessHEX part of it), so get latest before you try this.

As mentioned before, the target node of the wireless programming protocol will need to have an SPI Flash chip attached (if they don’t have one already), and also run the DualOptiboot bootloader for this to work. Moteinos come with this bootloader (all orders since the other Wireless Programming post and code was released). If you have all these components right, any Arduino clone with an RFM12B transceiver and an SPI Flash chip of at least 32Kbytes of memory will do the job.

Just for fun, here’s how the end of a wireless upload looks like, notice there were 617 packets sent all the way from the PC (through the python script) to the attached Moteino (gateway), wirelessly to the remote Moteino (target node):

Transmission_end

Sump pump alert with Moteino & HC-SR04

Here’s another project I wanted to do for a long time. I wanted a sump pump flood warning alert system in place, for peace of mind when I’m gone from home for prolonged periods. For whatever reason I thought this was going to be more difficult but no, it’s almost as easy as pie!

All I needed was a HC-SR04 sonar sensor and a USB 5V wall supply. The sensor only works at 5V so this method of powering the Moteino was very convenient since I already have an outlet close by for the sump pump.

The sensor has 4 pins clearly marked: VCC, GND, TRIG and ECHO. I connected VCC to VIN on Moteino, ECHO goes to D3 and TRIG to D4.

Moteino_HC-SR04_SumpPumpAlert

I used some of the code this instructable to get started and added my wireless code to handle packets and blink the LED and was done in no time. The setup was very simple, I estimated a good spot underneath the sump pump cover where there are no obstructions inside, cleaned it up, taped some velcro, secured the wires and that was pretty much it.

 Moteino_HC-SR04_SumpPumpAlert_cover  Moteino_HC-SR04_SumpPumpAlert_installed

I added a few lines of code to my main Python script running on the RaspberryPi.
By the way, here’s how my RaspberryPi setup looks like, including the ATXRaspi power controller, the power button and the gateway Moteino (it’s an older R1 but just as good for as a gateway):

Moteino_RaspberryPi_ATXRaspi_PowerButton

The Python script logs the data to EmonCMS and here’s a graph of how that looks like, the Moteino reports the distance to the water surface, so the spikes means the sump pump just kicked ON, and as water rises the distance decreases until the pump starts again:

EmonCMS_SumpPump

It’s been a rainy spring so far here and I knew my pump kicks ON quite often, now I can see it in real time, and setup alerts if the water rises too much. Seems like the pump is always pumping water out when it rises to 32cm below basement surface. So setting an alert to something like 20cm below surface should be enough since I don’t expect the water to ever rise so much as long as the pump works. The alert code will send me a SMS message when this happens, here’s a test level, I set the live value at 20cm:

Moteino_HC-SR04_SumpPumpAlert_SMS

You can of course setup other types of alerts – like audio alerts or maybe a LED visual indicator (less useful when you’re not in your basement).

Fun/Scary fact: The sensor is very accurate even though there’s a variance of 1cm between some readings (resulting in a sawtooth graph) as water rises. Based on the graphs, how often the water is pumped (every ~23 minutes), and how big the reservoir is, I figured my sump pump removes roughly about 18.5 liters every cycle, or about 1158 liters (306 gal) every day, wow!

So now there’s an extra level of peace of mind when I leave on vacation. I guess being gone for even 1 day could mean disaster if the sump pump breaks down at the same time!

Time to think about how to gather/store all that water instead of throwing it away, after all, I pay something like $11 for every 1000 gallons of city water.

Source code is on GitHub: https://github.com/LowPowerLab/SumpPumpAlert

Moteino Leo: Atmega32u4 based Moteino

MoteinoLeo_R1

I’ve been working on a Atmega32u4 version of Moteino, one that would allow USB connectivity and inherently no need for a FTDI adapter. This is basically an Arduino Leonardo clone that adds the RFM12B radio and a SPI FLASH footprint for optional data logging ability. I meant to post the details of this for several weeks but never found the time for a write-up.

MoteinoLeo_TOP

I now have a working prototype. I have some small changes in mind but it is functional as is. For this version I had to make a small change to the Caterina bootloader to make the onboard LED work properly. By default the Caterina bootloader assumes the LED is sinking current from VDD to the output pin, my version was sinking current from the output pin to GND. This is one of my planned changes, to allow the default Caterina to work with MoteinoLeo out of the box. Wireless programming will not yet work on Moteino Leo and I don’t know when I will find the time to customize Caterina for this purpose. From all I know Caterina takes about ~4kb of bootloader space which might be too much to add ~500 bytes of extra code. I will have to experiment with this sometime in the future if people actually have an interest in this.

Fun fact: using the same DIY metal stencil technique I was able to make a stencil, apply the paste with it and make this Moteino Leo prototype.

 MoteinoLeo_R1_stencil  DSC02551_banner  DSC02552

Eagle files and bootloader source are published in GitHub.

ATX-Raspi: smart power controller for RaspberryPi

I’ve posted details about one of my last projects that I’ve been working on.

ATXRaspi is a smart power controller for RaspberryPi or similar embedded systems running form a 5V input. It allows you to have an external shutdown button to turn off your target system without a need to login or to issue manual shutdown/sudo halt commands. I needed this so I could power off my Pi without having to log in all the time. I wanted a physical button to shutdown/turn off my RaspberryPi.

Also now available in the shop, pre-assembled or as a DIY kit.

DSC02674_ ATXRaspi ATXRaspi_wiring_to_RaspberryPi

Moteino wireless programming source code

I managed to put together a library and refactor the code that I used to achieve Moteino wireless programming. I uploaded everything to my Github repository.

There’s a new WirelessHEX file in the SPIFlash library. That file contains helper code that handles the new sketch over-the-air transmission for both the transmitting and receiving ends. It will increase your sketch size by a few KB, that is just an unavoidable tradeoff.

https://github.com/LowPowerLab/SPIFlash

The target node that is to be wirelessly reprogrammed will need to have code to listen for a potential new sketch. I uploaded the example sketch along with everything else to the RFM12B library examples.

The gateway node sketch, target node sketch, python script that passes the HEX file to gateway node are all located here: https://github.com/LowPowerLab/RFM12B/tree/master/Examples/WirelessProgramming

The cusom Optiboot allowing the reflashing with the sketch stored on the external SPI FLASH memory chip is here: https://github.com/LowPowerLab/DualOptiboot
I managed to keep the size just under 1k. So in the future Moteinos will probably ship with this bootloader to allow for potential wireless reprogramming.

I would call this an alpha release even though it works pretty well. Sometimes it’s a hit or miss because of the delays I’ve set in python. Those could be refactored and code improved to be smarter about initial requests for a sketch transmission. But it seems in most cases it works the first try.

Further improvements are:

  • increase speed of transmission
  • test with larger sketches
  • refactor python script, WirelessHEX library and gateway/target node sketches

I’ll try to keep up with changes and updates. Right now I have no idea if anyone will find this useful or not.

SPIFlash memory library for Arduino/Moteino

I posted the SPIFlash library I was talking about in previous posts. I have not found a convenient library for that purpose hence this library written by myself.

Get it at my Github repository: http://github.com/LowPowerLab/SPIFlash
Also added a basic usage example under the library.

The All-About-Moteino page describes how you can add a flash chip to your Moteino or even to your Arduino. To access this chip you will need a library such as this one to conveniently read or write bytes to the chip. I would recommend getting used to the chip itself by doing some reading in the datasheet of the chip you are using – there are some particularities as to how these chips work. The library attemps to abstract most of these things so you don’t have to worry about them. At the very least please read the comments in the code for now. Soon I will hopefully add more info and tutorials. Stay tuned for the complete solution code for wireless/in-field programming of Arduino/Moteino using this library. I am working to get all that code organized and posted on this blog.

Wireless programming step 2: SUCCESS!

It works! I was able to reprogram a remote Moteino over the air with a blinky sketch!

Definitely not a ground breaking achievement, but it really felt like “Hello World” all over again! :)

I didn’t expect to overcome this so soon but I managed to get past what I thought would be the biggest hurdle: customizing Optiboot for wireless programming. Actually it’s just reading the new flash image from the external flash chip and transferring it into the internal flash memory. The “wireless” part happens in Step 1. Continue reading

DIY manual SMD pick and place machine for $20

I’ve shot this video over several days a few weeks ago and finally had some time to put it together. Kind of rough cut but I think it proves the point that you can build a very effective pick and place aid tool without spending a fortune. This has already saved me tons of time assembling Moteinos and other SMD projects. I highly recommend something like this as opposed to a tweezers plus microscope/magnifier, it’s very quick and easy to get used to. This tool combined with my home-made SMD metal stencils are a huge improvement over manual solder paste dispensing and hand placing SMD components with tweezers. I also tape the SMD component strips to a piece of cardboard with double sided sticky tape, to avoid having to dump components on the table and then spend time turning and aligning all those that are upside down and in all directions. That also really helps with polarized components.

Wireless programming step 1: SUCCESS!

Well, the title may sound somewhat misleading. But read on. After many days/hours of trial and error I was finally able to validate and transmit an intel HEX flash image to a remote Moteino, which stores it on an external SPI flash chip (soldered to the new SPI Flash footprint available on all Moteino R2s). This is the first step towards wireless programming, and probably the easier step.

Moteino_R2_withFlash

I really hate to write bits and pieces of an unfinished solution and keep the readers in suspense/anticipation of what’s coming next (I see there’s a trend for this on some blogs, to increase blog hits and keep users “hooked”), but I think the wireless programming endeavor is rather long and complicated. Yesterday I achieved what I long wanted, to get a new sketch wirelessly transmitted and stored on a remote Moteino, for later interception and reprogramming through a custom bootloader.

For those unfamiliar with a HEX file, it’s the file generated by your Arduino sketch, and then uploaded to your Arduino/Moteino when you click “Upload”. It all happens behind the scenes and through the attached FTDI adapter. It’s a complex protocol that involves a handful of moving parts. The most important is the bootloader which lives on your Arduino/Moteino, which must be able to intercept the “Hey here’s a new program for you!” request and start re-programming the internal flash memory. But for all this you need wires!

Wireless programming of your Arduino/Moteino is useful when you have nodes sitting in trees, on top of your house, in your attic, underwater, underground, inside sealed enclosures, generally where it’s very hard to physically reach once you have a node deployed.

Continue reading