Meteo node II

I'm reporting some progress on the meteo node today. It worked more or less on first power on - with the exception of the RF24 not working at all, but the problem was easy to discover - swapped pins MISO and SCK! I don't get how could I make that mistake as I was following the table, and I am sure I counted the pins right. Anyway, after fixing that, all worked just fine.
The node still misses the battery measurement support, but I am going to leave it out until I know what kind of battery I am actually going to use. The voltage divider will depend on if I am going to power it from AA cell, LiIon cell or something else. I ordered some samples of step-up converter from Linear, which could be used, and I am considering those MCP1640 from Farnell (they're still the cheapest), but that needs some testing first.
The high voltage capacitors finally arrived from Austria - sheesh, it took more than a week to get them shipped and delivered, and given the S/H price... I just hope they're any good, or else I ended up with 200 pieces of junk. They're surprisingly small for 1KV 10nF capacitors. Anyway, I'll see if I find some time this weekend to build - yes, you guessed - yet another HV power supply for GM tubes. In fact, I am thinking about putting together the not-so-common components and offer it on eBay for some reasonable price, saving people from hassle of getting bits and pieces here and there. I have a load of MPSA42 transistors, 10nF capacitors, 10mH inductors, fuse holders etc etc.
The lead accu I ordered month ago still did not arrive, and eBay returned me the money. I ordered some goldcaps today, and will do further experiments with them. I'll get two 22F/2.3V ones that could be great if I'll manage to make the step up converters working.

Meteo node

After that experiment yesterday that helped me to confirm that I can safely use DHT22 for temperature measurement, I started to work on the meteo node. It's not tested (my wife needed some changes on her blog that took me some time to figure out), but it already is getting shape. The white thingy is the DHT22 sensor, the small bluish one is BMP180 module. I found out the module actually had 3.3V LDO so I  had to remove it, that's why you can see some missing components, and the wire on it. I was originally planning on powering the whole thing from 18650 LiIon accu, but I can't find the holders I bought some time ago. CR2032 was the second choice, but that probably won't work for DHT22 as it is specified for 3.3-6V, and according to some into on web, it starts to show erratic behaviour under 3V. I'll try a step up booster and power the thing from one AA battery. I wanted to order some MCP1640 chips, so this is a good time to do so. Farnell has them for nice 41 cents when ordering 10 pieces... just the shipping price is way too high, so I'd better think of some other stuff I need before I make the purchase. Anyway, the CR2032 should do for the moment.
There is a few things that are still missing - the battery voltage measurement, and I should probably switch off the sensors when Arduino is sleeping to conserve power. The DHT22 draws something like 40uA when idle, which is pretty much a lot of power. Now the question is, how to do that? Using a PNP transistor as a high side switch should work, but I am a bit worried of the voltage drop on it. Of course that would not work at all with CR2032 (that's why I did not add this to the node yet). Another option is to power the sensor from the Arduino digital pin. That should be pretty easy, but again, I am not sure about the voltage. The safest would be to use something like 3.5V for Arduino, which should be fine for all other devices, like the NRF24L01, and still give a plenty of headroom for powering the sensors. Time to do some measurement tomorrow!

Back from Embedded World 2015!

I did not update the blog for a few days. I was on Embedded World 2015 in Nuremberg, visited customer in Essen, and then recovering from all that :) All that were business trips, and I can tell you that all of that was exhausting. I took train to Essen and back, and that was refreshing, I really enjoyed that... but still, it's five hours on train.

We spoke to some people on MS booth (not MS directly), and we were given this 16GB USB stick. I originally thought it's a chewing gum or something. The other side says "Internet of Your Things". IoT was a major buzzword this year. Why not.

I also brought a new STM Nucleo board. I don't have it with me, and I don't remember the model number - just guessing it's the F303RE variant. Unfortunately, I didn't realize I could (and should) register for the NFC expansion board.
I did not bring anything from Essen, but we had time to have a lunch in Maredo steakhouse. Yum!
As for the hardware projects, I did a few minor things.
I was about to update the "white" clock with support for buttons to set time, and when looking into the code, I realized I did it already long time ago. It's funny, the clock was sitting on my desk for a few months and waiting for the update.
I received some goodies from China, one of them a boost-buck converter. I hooked it to the solar panels and I can see it works as expected. The panel voltage dropped to something like 2.5V, so it's still far from ideal, but it was pretty cloudy today anyway. The lead accu I ordered almost a month ago still did not arrive, and I can't test the whole setup with it (eBay case opened already).

I played with the sensor nodes a little, and added some indicator LEDs to the central node, just to show if it's alive, and if packets arrive from time to time. I wanted to use PWM, and most of the PWM capable pins are on that odd-placed Arduino connector (pins 8-13). The trick to make the connector compatible with stripe board can be seen on left. Those are originally pins extracted from right-angled pinheader, and they're bent accordingly using pliers.

I am also making another attempt with the CR2032 based node. I placed it outside on a dry place, let it report every minute, and I will monitor the battery voltage again. It started with 2.94V - or actually a bit higher, but the voltage dropped after moving the node to the balcony. Outside temperature is around 4°C, compared to something like 22°C inside, thus some voltage drop was expected. Other nodes are scattered around the home, just to keep the central node busy.

Last but not least, I again put some stuff on eBay. I sorted out the vacuum tubes I purchased some weeks ago, and found some that might sold (like DY-802, 25kV diode that could be used for X-Ray). We'll see.

Arduino Due Central Node, part III

Yesterday and today was mostly related to the central node and example sensor node. I added those two RF24 modules as planned, and immediatelly ran into problems, as they were not able to pick up almost any packets sent by other nodes. I am still not quite sure what was the problem, but adding some filtering capacitors - a lot of them - helped. One thing that really helped me to realize it could be power supply problem was the fact that the reception got much, much worse after attaching that flat cable with display and Ethernet module (ENC28J60). Even when they weren't in active use, they still messed something up. Anyway, now there's a huge cap (1mF or so) under Arduino and each module has its own 33uF tantalum SMD cap. That seems to do the trick.
Another thing that might have caused problems was the DMA mode used for the display. I decided to turn it off in the end, after realizing it doesn't really play well with other devices on the SPI bus. The sources mentioned something like that the DMA can stall other devices. What I noticed was more like the opposite - clearing the screen took 29ms with DMA enabled before other devices were activated, but a few seconds in the main program loop where other devices were talked to!
I changed the sensor node code to be more similar to the sample code I already wrote. Resulting code uses just pure RF24 radio without the RF24Network extension, runs on 250kbps for longer range, and does not use any acks. I might change it in the future after doing some tests. The sensor node also uses EEPROM and simplified identification in form of two characters, like 'T0' for first temperature sensor etc. The packet that temperature sensors send looks like this:

typedef struct PACKED {
  uint8_t PacketType;
  uint8_t BattLevel;
  uint16_t Flags;
  uint16_t SensorId;
  uint16_t Temperature[2];   // Up to two temperatures in tenths of degrees. 
} SensorPayloadTemperature_t;

To recap, I am planning four types of nodes:

• Central node - Arduino Due, has Internet access and serves as a central hub
• Network nodes - support RF24Network (maybe with Mesh extension), typically used for bigger tasks with a lot of communication happening
• Broadcast receivers (consumers) - RF24 radio only, receiving broadcast info from Central node but do not send anything back. Typically clocks etc. Broadcast receivers have no ID
• Sensors - RF24 radio only, sending data to Central node, not receiving anything. Have simple two char ID to distinguish between multiple sensors of one type

 I also spent most of the afternoon by putting stuff on eBay, some old chips I probably won't use, some kits, VFD displays etc. One VFD display was immediatelly sold, and few people already bid on some microcontrollers - good!
Last but not least. After finishing the Friday's entry, I finally had chance to try my new telescope out. It probably needs some adjusting, but I was able to identify that bright planet I was seeing from my window every evening. It's Jupiter, and I can confirm it as I saw its moons - for the first time in my life! It left me in awe, and Jupiter is no more just a word, but something that physically exists for me.

Arduino Due Central Node, part II

I spent most of the yesterday evening despairing and tearing my hair, struggling with the RF24 nodes on Arduino Due. The logic analyzer gave me confusing results, the signals did not make any sense, and of course the node didn't respond, no matter how I tried. Well, in fact it did respond when I touched the MISO pin, but that wasn't the kind of response I hoped for. Those strange signals on logic analyzer turned out to be caused by slow sampling, and all worked fine when I bumped the sampling frequency to max (24MHz). Anyway, I gave up and went to bed, as I was tired and could not think straight.
Yes, you guessed that already - I made a mistake when wiring the thing. The RF24 modules have two pins named CE and CSN. I assumed that CE is SPI chip select, and CSN is something specific to RF24 module. Even when I saw that the RF24 does not respond, I still did not realize that the module is obviously not selected and there's something wrong with chip selects. Well, that will teach me a lesson for next time.
After swapping the pins, all started to work just fine. I quickly tried if I can use any pin as chip select for SPI, but that doesn't work. As I am still planning on attaching RFM12B sender, it will obviously need to be modified for software SPI... oh well, at least I can reuse the code from ENC28J60.
The plan is to have two RF24 modules. One will be running with just a basic RF24 radio stack, withouth ACK, on 250kpbs (for biggest range), with fixed packet size, and its own channel. This will be used for sensor reporting to central node, and for central node to broadcast info.
The second RF24 module will use different channel and will run the whole RF24Network stack. I am not sure what I will use it for, but if nothing else, it will multicast similar info packages, and additionally provide some services, like offering nodes to sign up for mode detailed and extended info etc.
The rest of the evening took me beautifying the code, and I'll check it into SVN. I'll change the sample RF24 node code to use just the basic radio... and hopefully it will solve that strange quick battery discharge problem. By the way - I am not sure if the voltage measurement is actually not the main cause of the problems. The node is soldered together on rather cheap paper-based PCB, and the voltage dividers use pretty high value resistors. It could be that the PCB absorbed some water that decreased the PCB resistance and messed up the whole voltage measurement.

Python? No thanks...

Oh well. My attempt to use Python for the RasPi node was over before it actually begun. I was about to port the include file over to Python, just to find out that Python does not support structures. There's some sort of emulation of regular structures, but that looked so complicated and awkward I simply gave up. Back to C. If nothing else, I will be able to share the source code with any other hardware I have at home, being it Arduino, RasPi, MSP430 or PICs.
I tried to use the ILI9341 display as RasPi console, and add ncurses to my skeleton RasPi RF24 central node. To my surprise, RasPi crashed. I did not get any message about the crash, but it was hard, as even SD card wasn't synced. I tried older code without ncurses that actually did not touch the display at all (and I am running stuff over SSH thus nothing was really written to the display). Crash. I tried even older code that for sure worked. Crash. Disabling the ILI9341 as console solved the crash. Strange.
I have no good explanation for this. I even tried to debug this behaviour with gdb, but the last thing I can see is the RF24 library opening the /dev/mem. Then the program gets out of gdb's control as it continues running, starts communicating with the RF24 chip, displays some internal details about it, and then the whole system stops responding. I guess it's two things trying to use the SPI device at the same time (console and RF24) and that somehow doesn't work... I don't think I will be able to fix this, and I am now remembering why I always preferred using Arduino to RasPi. Anyway, I need to think about this. Most likely going to my own library for the TFT support, probably porting the Adafruit Arduino lib. Great...
There is one positive outcome of all this - I found out about gdb's TUI (Text UI). Not that it makes gdb the best debugger ever, but certainly makes it less PITA *grins*

RasPi extension board

As promised, a picture of the extension board that will become a center of the RasPi node. Arduino Pro Mini in the middle, surrounded by RF24 module connected to SPI.0 of RasPi, the flat cable to RasPi GPIO header, a display (and buttons) connector with attached display, power supply part with KIS-3R33S, and another RF24 connected to Arduino. The empty socked next to Arduino will host PCF8574P I2C expander (when it arrives from China) that will take care about buttons (if any) and other low speed stuff.To test the display, I used Adafruit ILI9341 Python library, and it worked fine. I rewired the thing a bit and did not test it since, but I assume it should work, or could be fixed if it doesn't.
I had some major issues with the RF24 module - it did talk to RasPi, but did not receive any packets. I spent a few hours trying pretty much everything, and in the end added some tantalum caps directly to the module pins. That helped, and I hope it was the only problem. I added a few capacitors here and there, and one 1000uF is hidden under Arduino... the whole module has so much juice it can run by itself now.
The CR2032 module stopped with around 2.45V. Unfortunately it was snowing overnight, and the snow melted so I retrieved the module in the morning, dripping wet, and reporting voltages around 4V - the water bricked the 1M24 resistor, fooling the divider into thinking there's much higher input voltage. Anyway, the battery now shows 2.94V without any load. I'll continue the experiments in upcoming days.

Future plans for the central node

Lazy day today, I sorted out some components I had laying around in drawers, took a long afternoon nap and played Deus Ex: The Fall. The game isn't bad... just a bit weird, and it looks like I cannot jump... Did someone say "Doom"?
I needed to make the final decision about the central node. I was leaning towards using Arduino Mega or Due, but finally I decided to go the "Raspberry Pi + Arduino Pro Mini" way. That way I'll have the whole communication under control and I can use the code I already have for Arduino, but additionally I'll have access to the processing power of RasPi. If possible, I'll make the RasPi act as a web radio as well, and will let Arduino control the mpd or whatever music program I'll use.
The plan is to have one RF24 module connected to the RasPi directly, and RasPi will act as an internet bridge, using one dedicated channel for nodes that care about getting internet connection. Another RF24 will be controlled by Arduino, communicating with sensors and sending out time info, weather info etc. on another channel. I might actually connect TWO RF24 modules to Arduino,  one running the RF24Network stack, the other just using basic RF24 for reading data from sensors (reason explained below). That sounds as an overhead, but when one RF24 module costs 70 cents... Arduino will also control one RFM12B module for compatibility with other devices at home using these modules, and will also need to support the RS485 interface for the old clock on my wife's bedside table. The clock is about ten years old, before the wireless modules became available and popular, and it's running on PIC!
To recap and write my thoughts down:

• RasPi
• RF24 module providing internet access on specific channel, using RF24Ether
• 2.2" ILI9341 based TFT LCD
• Arduino
• RF24 module running basic RF24 radio stack to receive info from sensors
• RF24 module running RF24Network to communicate with clever nodes (clock, remote displays etc)
• RFM12B module for older devices
• RS485 for that old clock
• IR receiver, control knob etc. for controlling the web radio running on RasPi

I started to build the "baseboard" that will hold all this additional hardware, but I barely finished the power supply and RasPi cable / connector, so no pictures today. I'll work on it tomorrow and post a pic of it when it takes final shape. It's connected to RasPi via flat cable. If necessary, I will be able to flip it over, face-to-face to RasPi, making the whole thing more compact to be put into a small box.
The CR2032 node doesn't perform well. I started it yesterday evening with 2.97V, and in the morning it was still around 2.97V - 2.96V, hovewer, it dropped over day, and while I am writing this, it dropped again to 2.92V. My impression is I am at the end of the discharge curve (meanwhile, the voltage dropped to 2.91V) and the battery is dead. I am puzzled, and wondering if perhaps the whole overhead of RF24Network isn't causing this. It only sent something like one or two hundred of packets! Another node running with just basic RF24 radio stack was running for two weeks without much of power optimization.
Voltage dropped to 2.90V... oh well. I'll let it run and see where it stops - that would be the minimal operating voltage *grin*.

CR2032 node and power consumption

It looks like I was way too optimistic. The CR2032 node on the balcony worked in the morning, but the battery voltage dropped from 3.07V to 2.90V, so I stopped the experiment. No need to ruin the battery when there's something not working as expected.
The node was set to send both temperature and ID packets every 8 seconds, which is definitely too frequently, but I was still surprised to see the battery getting depleted so fast. The situation called for some action. I spent most of the evening trying to figure out how to measure how long the node stays up, doing the measurements and sending the packet to central node. In the end, I did the following:
 - node was powered from 3.3V through 56Ohm resistor. That means that the voltage drops by some 700/800mV every time the node wakes up.
 - the voltage is sampled by LM339 comparator, and compared with a reference voltage
 - output of the comparator is captured using logic analyzer (Saleae clone)
This sort of works, and shows that the time for what the node is up is not consistent, ranging from a few miliseconds to 80ms (I even saw 330ms once). However, I can safely say that the time is some 50ms on average. Assuming the node taking 20mA when running, the node consumes:
50ms * 20mA = 1000uAs = 1mC (microampersecond, milicoulomb)
for one active packet. The standby power consumption is let's say 25uA (Arduino, RF24, sensor etc.), and node stays in standby for 8 seconds:
8s * 25uA = 200uAs = 0.2mC
I have to add the power consumption of the DS1820 when performing the temperature conversion. That takes 750ms and the power consumption according to the datasheet is up to 1.5mA:
750ms * 1.5mA = 1125uAs ~ 1.1mC
All together, one 9s period (8s standby, 1s temperature measurement while node is in standby, RF24 communication) consumes ~2.5mC. There are 400 periods in one hour, that's 1C of charge.
The CR2032 should be able to supply 200mAh, that's 0.2A * 3600s = 720C of charge. In other words, even with 8s between the measurements and RF24 communication, I should be able to run for 720 hours, or 30 days on one CR2032!
The only explanation I have for this is that I am simply facing two things I did not take into account:
 - The CR2032 (according to GP datasheet) drops the voltage very quickly at the very beginning of the discharge curve. The battery was brand new when I put it into the node.
 - The voltage drops a little for lower temperatures. I measured the initial voltage on my desk at room temperature, then moved the node to the balcony with temperature around freezing point.
I've changed the constants, so the node now reports temperature every 5 minutes, and sends identification every half an hour. The node now sits outside on the window ledge, showing 2.97V and -3 degrees of Celsius. Let's check it again in the morning!

CR2032 node reports for duty!

I finished the CR2032 node finally, and put it on the balcony to give it a try. I faced a few problems getting it run, but so far so good, and we'll see in a few days.
It turned out that even a fresh new CR2032 cell does not like high current draw. Those 15mA made it to drop the voltage below 2.7V, and the BOD in Arduino kicked in, resetting the whole thing. I added a small cap (33uF) just to cover any potential current surges, and reduced the current drawn during power up and regular operation (powering down the RF24 radio all the time), and that helped. I experimentally set the start-up fuses to "6CK/14CK + 0ms", and BOD to 1.8V, and we'll see how that will perform.
The picture shows the node reporting the temperature and other info about itself. This LCD is connected to Raspberry Pi and I am using it as a temporary control node before I make a final decision if the central node will run on RasPi, Arduino Due or Arduino Mega. My original idea would require RasPi, but if I drop some requirements that probably do not make much sense, I can easily run it on something smaller. The requirements included checking emails and making the info about unread email messages available to all nodes that care about that, and that would need SSL which is tough on Arduino, but that might not really be necessary.
What I don't like on RasPi is just two SPI devices support... I might get over it by using bit banging, which could work for some situations, or perhaps by adding Arduino Pro Mini over I2C to handle all the RF24 and RFM12 stuff.

Low power success!

A brief update. After fixing the problem with uploading the code to that CR2032 powered sensor node, I took some power consumption measurements today. I was pretty disappointed to find out the average consumption to be around 15mA, compared to 4uA what I saw yesterday. The difference was due to attaching the nRF24L01 module. It turned out that the RF24Network library does not put the module to sleep mode (as it might need to route the traffic). After manually forcing the module to sleep with Radio.powerDown (), the power consumption went down to expected levels - 7uA! I still need to tweak it a little bit and see how it performs, but I am one step closer to the goal!
I also need to review and test the wake up sequence of Arduino. I am guessing that the fuses are set to slowest wake up. As Arduino draws some 5mA when operating, I have to keep this wake up as short as possible. Other things to do are adding a real temperature sensor, and battery measurement circuitry... and fix a bug with reading node ID from EEPROM (hardcoded to 8 bytes).
I received some samples from Linear today, namely the LT1307 step-up switcher. I tried that on a breadboard, and I am disappointed. It works, sort of, but doesn't even power a LED. I know that breadboard isn't a good test platform for 600kHz switcher, but still... Time to put it on a piece of PCB, and experiment with some inductors.
I'll need a good way to measure the efficiency. As I don't have four multimeters and all the cables, I need to think about something else.