Miniature GM detector, part I

First thing first. I tested the GM tubes from yesterday, and the results are more or less as expected. The huge tube, SI-22G, is really sensitive to the background, and it was nice to have it sitting on my desk and clicking. The STS-5, that one in the middle, was more or less on par with the SBM-20 I am using for my detector. The tiny one, SBM-21 does not seem to care about background much. I did not have any active source at hand, but I believe the results will be different when actually measuring something hot. The tiny tube is simply too small, compared to the monstrous SI-22G, and the chances that a particle will hit such a small target are simply... small.

I started to work on the miniature version of the GM detector, and I cloned the HV supply from my very first design, using the same parts, and duplicating the capacitors to achieve similar 

capacity as the original design (original caps are 18nF, these small blue ones are 10nF only). The results are positive - without load, the HV supply draws less than 0.5mA from 9V battery, and 0.25mA from 4.2LiPol 18650 accumulator. I am not sure what was the trick, though. The basic schematic comes from the Geiger Counter Circuits, the second circuit. Picture above is the component side, the picture on the left is the bottom side. I used SMD parts for pretty much all I could. Transistors are SMBT3904, 3906 and SMBTA42. I believe the transistor selection is vital, the SMBT39xx have relatively high hfe. Inductor uses cca 100-200 turns on ferrite core (hand wound). I don't remember what is exact inductivity, but it was pretty high when I measured it before, around or over 50mH. My impression is that bigger is better here. The ferrite core bears marks "SEM TM12". It's either coming from Pollin (part of the mixed inductor sale), or from local shop. Pollin is more likely.

The power supply seems to be relatively 'hard' - measuring the voltage with common 10MOhm multimeter shows 270V, while my previous constructions usually did not get over 150V. I still did not add the GM tube and clicker, that's left for tomorrow, or more likely after my vacation.

GitHub! (and fixing yet another old LCD)

Let me start with a picture today again. I swear I am not making it up!
This morning, my wife attempted to start her PC, and after a while, she said "Well, I don't want to sound stupid - but my monitor died." Let me remember that few days ago, I fixed two old FSC P19-2 LCD monitors. My wife uses the third one - and obviously, its time has come. I quickly swapped my wife's monitor for the one I fixed already, and went to work.
After arriving hope, I opened the monitor and discovered another failed Capxon, this time 100uF/25V. The top was bulged slightly, but as you can see on the picture, it was pretty much done. Luckily, I found some Samxon KM capacitors that seem to do the trick for the moment, and I already ordered some Rubycon and Panasonic ones.

The second picture shows the GM tubes that arrived from Bulgary recently. The middle one is STS-5, an equivalent of SBM-20. That lovely little tube is SBM-21 I want to use for pocket GM I could carry with me on vacation to Krkonose. The big one is SI-22G to be used for background measurement.
Last thing, the one that took me most of my evening and annoyed and frustrated me almost to death. As you might know, Google will shut down Google Code and suggests to migrate to GitHub. I am not going to rant here about Git - I just don't like it, I find it confusing and overly complicated for my purposes, and I am worried I'll hit the wall using it. But... well, that's the way it is. I had to manually import my Google Code repositories, as the default import didn't work the way I needed, and I already managed to mess the repository by a single click to such a degree I almost needed to import it from Google code again... I'll give it a try and see if I shall stay with it, or find another SVN service. Anyway, a hint for all who need to use Git - don't waste your time, and go and get TortoiseGit. It makes the whole process of using Git a bit less painful.

How much solar power II

I realized I did not post any pictures recently. In order to keep the blog more entertaining, this is my evening creation. I know, it's nothing, but at least a picture!
It's Arduino Uno with Ethernet shield (I bought two of them years ago and used them just a few times for testing, I usually use ENC28J60). I added two power 5.6Ohm resistors in series as a dummy load, and I hacked together a few demos to post the results of the solar panel performance on plot.ly. The graph shows voltage and wattage, the time is shown as number seconds after this evening. Not the best scaling, but it serves the purpose of giving me a better picture of what's going on, and I can monitor the results in realtime from work.
As for today's solar panel performance results - they're both promising and disappointing. After I moved the panel a little to face the morning sun, the wattage jumped to 3.73W. That was at 9:28 before I went to work. The power peaked at cca 4.5W, and changed with the clouds covering the Sun and disappearing again. The last usable reading arrived before 3PM, and then the power begun to decline. A rough guess is I was able to generate some 20Wh. It's not bad, although I'd expect the power to peak higher - those are three 5W panels! However, the position isn't optimal, and especially in winter, the building at the opposite side of the yard casts a shadow on our balcony in the afternoon, that's probably that sharp decline of power at 3PM.
I found some info on proper tilting the panels, and mine are obviously not optimally tilted. For bigger panels I plan, I'll need to come with better way to tilt them, and being able to adjust it over the year. Ideally, they should also trace the Sun, but that would be too complicated.
New goodies arrived - the GM tubes from Bulgary! Pictures tomorrow.

How much solar power?

The problem with my solar panels and experiments is that I have no clue how much power I will be able to generate. Theoretically, I should get 15W on ideal day, with panels properly set. I would expect much less later in the afternoon on a winter day, but so far, I am getting something like a few mW only. I can assume that part of the problem are less than ideal light conditions, not really optimal panels angle, and the fact I am at work during the day, thus all I can observe are results on late afternoon.
To overcome at least the last problem, I hacked together a quick measurement unit - just one of the RF24 nodes I have laying around. The only thing the modul does is measuring the voltage of the panel (bridged with 470 Ohm resistor), and report it to the RasPi that takes care about logging it into file. That way, I should see if the panels are worth anything.
That's pretty much all I've done today, I am afraid.
I received a nice box of goodies, I did not open it but I assume it's those old fans and heatsinks. I overdid it this time for sure, and I will end up with something like 20kg of Alu heatsinks. I am planning to use some of them for LED lights, and I wasn't careful when bidding on eBay - oh well, I can still sell them :)

No solar fun on this rainy day

Lazy Sunday here. I slept long, really long. My wife's bed is always so warm when she leaves it that I cannot resist to sneak under her blanket, and this time I fell asleep and woke up at 10AM or even later!
The Sunday wasn't only lazy, but also rainy and dark, not really the day you need when you're playing with solar panels. The ones installed on the balcony generated just a few milliwatts, not worth doing anything with it. I used the LTC3525 I received yesterday, and after a few experiments with coils, I made it work. The mistake was to use the small SMD coil I had at hand, but using bigger, 47uH one helped. The whole setup consists of the 2V solar cell, Schottky diode, 22F goldcap and the LTC chip. Unfortunately the goldcap was drained to 0.7V so it took some time for it to get charged. The power generated by the solar cell on this rainy afternoon was barely able to keep the LTC running without any load, but attaching an Arduino to it was definitely pushing it over the limit, and the voltage begun to drop steadily, mV by mV. To be honest, the Arduino I attached to it wasn't low power at all, it uses LP2981 LDO with something like 100uA of quiescent current, and red power LED with cca 1mA consumption, so I am not that surprised. Let's redo the test with fully charged goldcap, and one of the low power nodes I have.
I modded the meteo node a little. The DHT22 and BMP180 sensors are now powered from Arduino pin, thus I can control their power. The program was changed to not enable the sensors for battery (goldcap) voltages under 3.3V, but the program still needs some tweaking.
While tidying up my desk, I found the 24x2 LCD I bought recently. I had the idea of converting it to a Matrix Orbital compatible display that could be used with Winamp, thus I quickly hacked Arduino to it - just to find out that there's no working plugin! I found "LCDPlugin", but that one is pretty old, and reports that the COM port used for display cannot be accessed. It does work sometimes, but the chances of it working are around 10%. The other plugin is "LCD Smartie", but I don't like the idea of having that program running all the time. As Winamp seems to be dead (the official Winamp page didn't change for years, and just promises something new), I assume it's dead and chances of finding working LCD plugin are close to zero... well, I wonder if there are other players capable of all that Winamp could do, with LCD support. I tried foobar before, but I wasn't impressed at all.

Solar panel installation

Not much done today, and no picture unfortunately for reasons explained below.
I was thinking about the best way to put the three small solar panels on my balcony. There were some options, and I decided to let the panels hang on the outer side of railings. I am not sure if that's 'kosher', as the local landlord seems to complain about things like satellite dishes - we'll see. After all, this is the land of alternative energy, solar panels are everywhere, so why not on my balcony! I had to rush to the shop to get some nuts and bolts, and I got cheese and anchovy as well while I was there.
I wired the three panels in parallel. I am still not sure if that's smart, but I'll see, and rewiring them shouldn't be that complicated if necessary. The problem is that those panels are 9V ones, which is sort of a strange voltage for common SLA accumulators. I have both 6V and 12V ones.
When I finished, and put the panels on the balcony, it was already dark, and raining, thus no pictures today.
The meteo node (powered from solar/goldcap combo) died at 4AM, more or less as I expected. The latest reported voltage was 2.71V, but the values from the DHT22 sensor were obviously wrong, and I think I should stop trusting the values much earlier. Let's declare the minimal acceptable voltage as 2.9V. At this level, the voltage begun to drop quickly, and the humidity reported by DHT22 went to the roof. I assume that the sensor simply went to weeds, and consumed all the power it could get before RF24 module gave up :)
I received the long expected LTC3525 chips today - I'll give them a try tomorrow, and also will try pairing it with that 22F goldcap, and see how long a node will run off it!

Fixing old LCD monitors - Fujitsu Siemens P19-2

I realized I'll need a secondary LCD monitor for my vacation. I had two FSC P19-2 LCD monitors in my basement, as I was planning on fixing them one day, and the day arrived :) Those monitors were really a high end ones when I bought them (okay, high end consumer ones), sporting PVA panel and pretty good speed and size. They're 1280x1024, 19 inches.
The first one did not start properly, and if it did start, it switched off itself soon again. It dies last year, so I still remembered what was wrong with it. The second one was sitting in the basement for a bit longer, and I just barely recall the backlight died, although I am not completely sure. Anyway, after watching Dave Jones' video on fixing the LCD monitors, I felt confident I'll be able to fix at least one.
Opening it isn't that difficult. A nice guide is on Diit, however after figuring out that the two important screws are hidden under the white rubber plugs, it did not take more than a few minutes. Just demount the monitor stand first (four screws), then the two under the white rubber plugs, and then gently pry the back cover apart. The electronic is hidden under the metal sheet held by three screws around, two screws near the power socket, and the four hexagonal nuts (or how they are called?) of the DVI and VGA connector. Then slide the metal cover off the holders, and that's it.
The source of the problem can be easily spotted - see that green capacitor on the left side of the picture above, close to the heatsink? It's bulged - not much, but it is. More detailed picture on the left. All I needed to do is replacing it with similar, but working capacitor. I didn't have any new one at hand, thus I used an older capacitor I recovered from an old Pentium mainboard - and, well, that was all. After putting the LCD together again, it works, at least for now. The original bulged cap showed no capacity at all!
By the way - I used the same method for fixing our late satellite Topfield receiver. Again, replacing the bulged cap with an old one recovered from old mainboard was sufficient. If you happen to have some old mainboard from the era before those capacitor problems, don't throw them away, keep the caps! And the coils, and maybe some other stuff - heatsinks, PS/2 connectors, resettable fuses...
The second LCD (again, P19-2) was a mystery. It worked when I tried it today, although I am sure it didn't work before. The cap in the power supply that I expected to be bulged was okay. I replaced it just to be sure, and also replaced another, smaller cap nearby that looked bulged, but I did not have adequate low ESR replacement, so I'll order some and will fix it once for all.
That's pretty much for today - oh wait, three small things:
 - the pre-WW2 vase with uranium-oxide paint arrived today. It looks nice, and is not as hot as I expected, showing something around 2000CPM (1mR/h). However, because of bigger active areas, there's a measurably increased radioactivity even some 20cm far from the vase.
 - we had partial Sun eclipse here. I watched it for a while, and although it doesn't compare to the total eclipse I saw in 1999, it was still nice.
 - the meteo node powered by a solar cell and 1F goldcap is still up and kicking. I am using RasPi to monitor it, and despite the fact the node isn't power optimized yet, and reports every 8 seconds, it's still at 3.47V (almost midnight here). The voltage drops by 10mV every 3-4 minutes and I expect it to die at around 3-4AM. With some optimizations, I am pretty sure it can make it through the night! (an afterthought - in emergency situations like when the voltage drops to dangerous levels, what about sending the meteo packet less often?)
Last but not least - I'll rework the sensor packet definition to give bigger range of voltages. Maybe one bit flag, specifying either 10mV precision as being used by now, or something like 50mV usable for higher voltages. Actually, that would be backward compatible!

Fixing old central, and fixing meteo node

Time flies - I just wanted to finish something, and it's almost midnight.
We had some problems with electricity yesterday. Few weeks ago, the wall socket in the bathroom burned out. Well, not really, but my wife reported strange smell when using the washing machine. It wasn't your typical burning smell, it was more like ironing a perfumed piece of clothing. As a quick hack, I asked my wife to use an extender cord. However, the other circuit did not handle a water kettle and the washing machine at the same time, and breakers went off.
I am using an old central node designed few years ago. The new, Arduino Due based central node I am working on is supposed to replace this old central node.
The old central node has a problem I was aware of, but wasn't able to debug so far. Sometimes, it simply hangs after being powered up, or stutters in the main loop. I noticed that before, but the problem went away when I attached the debugger. This time, it didn't, and first debug output suggested the central node isn't getting the IP address via DHCP. A few tests suggested the MAC address isn't unique, and router refuses to assign new IP. I am still not sure what caused this, probably a router problem. I'll keep an eye on it and if it happens again, I'll generate random MAC on every start or something.
Next thing I worked on this evening was making the RasPi log all the sensor node packets into a file. It was pretty simple, and works fine so far. I want to see what exactly is happening with the meteo node in the evening.
The meteo node was also modified to report the correct voltage of the goldcap that powers it. I assume the sensor are eating too much of juice, and the whole thing will need some optimization. Not a big deal, I was planning on running this from battery anyway, but - well, if it can be solar powered, even better!

Goldcaps? Goldcaps!

As promised yesterday, some new toys that arrived recently. I got some solar panels - those are 4.5V and 5V rated ones. The 5V one can actually put over 5.6V on a really bright sunlight, which is - after dropping 0.2V of the forward voltage of a Schottky diode - close to the 5.5V rating of the goldcap, so I am using the 4.5V panel. Then, there are two goldcaps, 1F/5.5V and 22F/2.3V, and finally a sealed lead-acid accumulator, 6V/4Ah.
First thing I tried was a few experiments with the goldcaps and solar panels, of course. I just added the BAT54 Schottky diode and used my incadescent lamp to generate some electricity. The voltage went up nicely and I was watching the 22F goldcap charging - sweet! After removing the light, the voltage begun to drop quickly, and it looked like the self discharge of the goldcap is that high that it won't hold the charge for more than just a few minutes!
After looking up more info on web, I realized that a goldcap is really behaving like that - the charge slowly trickles in and it takes some time for it to reach all the parts of the golcap. To prove that, I let the goldcap with attached panel charge all the day on the balcony. It got charged to 1.9V, and after more than a day, the voltage dropped to 1.78V only. Much better!
I used the 5.5V goldcap with the meteo node. It worked over day, but after nightfall, the voltage dropped pretty quickly and the node only worked for a few hours. I need to create a monitoring and logging tool that isn't dependant on my computer working all the time. Hmmm, a good application for RasPI! If nothing else, I know it works with RF24 *evil grin*.
That's all for today, I need to make plans for further steps. One of them will be finding the best way how to put the solar panels (the 9V ones I have) on the balcony, on a direct sunlight, avoiding my wife's flowers and plants, and the sunshades she puts over the flowers on hot days. That's the trickiest thing.

Back from vacation

I took a break, partly due to high workload at work, partly due to a short trip to my family. I did enjoy it, and even enjoyed driving that tiny, brand new Ford Fiesta I got from Hertz. That was a nice surprise, I paid for Ka, and got Fiesta.
Last two evenings before the departure (well, not exactly, last two evenings were mostly about packing, planning the trip, getting the Google Maps working on my phone etc etc).. what was I talking about? Oh yes. Last two evenings before the departure were about making the RFM12B work with Due. I finally decided on removing the display, and the freed SPI port is now used for RFM12B. I started porting the library to Due, but that turned out to be pretty complex task, as the library uses various bits and pieces specific for AVR (like EEPROM etc.) and I gave up pretty quickly as I had that feeling of reinventing the wheel. I took the library from Boredomprojects and first tests looked really promising, it could talk to Arduino running the latest version of Jeelib.
Happy about the progress, I tried to send a broadcast message to my already existing devices with RFM12B - and... well, nothing happened. After some debugging, I figured out two things that were wrong:
 - the existing devices use old version of the library. New version adds one byte in the header for destination or source address
 - the new library initializes the RFM12B to a different speed
After fixing those two problems - nothing happened. I tried all I could think of, but the Due running new library with my patches still doesn't talk to the old devices. The packet seems to be correct, the CRC matches, the channel and speed is the same... I gave up for the moment as I had no time to pursue that. I'll debug the init sequence using my good old Saleae clone and see if there are any differences.
In the meantime, I received a whole bunch of new stuff. The most interesting things are some goldcaps, solar panels, LCR meter, RF24 modules with antenna, partly dead MX510 mouse (as a spare part donor for the mouse I am using for years), and other small stuff. I should do an unboxing video one day :)
I did some experiments with the goldcaps, and I'll put together some more info in upcoming days.

Barbie bed

I felt like doing something else today, I definitely need a break and think about further updates of the central node. I was asked to build a bed for Barbie and her friend, so here it is. The frame is made of plywood, my wife provided the fabric, and the mattress from soft foam material I found somewhere, it was originally part of keyboard packing or something like that.

I used my old good Proxxon table saw. The saw is fastened to a little plank of wood by four screws, and then the plank is fastened to the table with two clamps. To cut big pieces of plywood more or less rectangular, I made a bigger working are of plywood and some squared timber. It's not perfectly rectangular, and has other problems, but with a bit of effort, the results are at least satisfying.

The frame slides along the saw table, and helps me to make long and straight cuts. Unfortunately, this whole arrangement only allows me to cut plywood not thicker than 5-6mm, but it's still a major help.





I also made another attempt on the high voltage power supply for GM counter. The results are even worse than the previous attempt, and I am wondering why. I ordered some 9.1MOhm SMD resistors, and next attemp will use SMD transistors, the same I used for the very first supply.
Some minor changes were done to the central node code as well, but nothing major. I started to look into the available libraries for RFM12B that could be used with Due. I found one, using SPI port, but I am a bit skeptical about it - plus, of course, I have no free SPI CS pins. However, I am considering getting rid of the display, and if nothing else, I can just convert an existing library to use SW SPI.
Why removing the display? First, I am not sure how useful it will be in final product. It is pretty useful now, but the nRF24L01 modules have quite short range, and even with 250kbps, the signal doesn't make it through walls to the bathroom. To overcome this, I am considering putting the central node to more central location in the appartment, but then the display will be useless. Second, as clearing the screen takes over 100ms, it would greatly impact the response time of the RF24Network, eventually losing packets randomly, and I don't like that idea.

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!

Temperature sensors precision

I was always curious how much can I trust various types of temperature sensors. I loved the TI's TMP100, tiny I2C based sensors, and used them a lot before. In one project, I got a feeling that the sensors are actually lying to me, and I became a bit cautios. I later abandoned them in favor of DS1820 style sensors, and the few remaining TMP100's were resting in the box. As I recently got the DHT22 that also has temperature sensor, I felt like I should really take a look at various sensors and compare their readings. The results are interesting.
First thing first - the contestants are:

• TMP100 - I2C based sensor from TI in SOT23-6 package
• DS1820 (and similar ones) - 1-Wire based sensor from Dallas / Maxim
• DHT22 - sort of one-wire protocol, temperature and humidity, based on AM2302

I already played with all the DS1820 (DS18B20, DS1822 etc.) sensors I have, comparing all of them, and I found out that at least at room temperature, they all report more or less the same temperature, with maximal difference between the lowest and highest value around 0.5°C.

As always, I took Arduino, attached LCD display to it and all three sensors, using sample code from Arduino libraries. I did not see any example for TMP100, but Google suggested the Fork Robotics page, and the example described on that page worked just fine. I do not offer the code for download, it's a big mess, and throwing it together took me about ten minutes anyway.

The results are interesting, and reassuring me I can use any kind of sensor without risking the temperatures being too different compared to any other sensor. In other words, I can use the DHT22 for the meteo node, and trust the temperature. There is no need for an additional DS18xx sensor on that node.

I tweaked the code for the central node a little, nothing important. I am considering a change of the packet definition, making just a single structure that will use anonymous structures and unions to describe any kind of sensor packet. I am still not sure if there are any drawback other than the obvious one (prone to mistake). Just to explain what do I mean:

typedef union {
  SensorPayloadTemperature_t Temp;
  SensorPayloadMeteo_t Meteo;
  struct {
    uint8_t PacketType;
    uint8_t BattLevel;
    uint8_t ___pad[2];
    uint16_t SensorId;
  };
} SensorPayload_t;

This allows me to directly refer to PacketType, BattLevel etc. without 'going into' the Temp structure. Arduino supports this, at least the 1.5.8 version.

Arduino Due rant and debouncing

Mostly ranting today. I wonder who came up with the brilliant idea to name Arduino Due this way. Did they realize that 'due' is regular English word, and googling up 'Arduino Due xxx', where xxx is a description of the problem, or a library name, will point to regular Arduino article that accidentally uses the word 'due'?
Yeah, I can use doublequotes, but I usually forget to do that. What will be the next great name? 'Arduino And'? 'Arduino The'? Or even better, 'Arduino Sex'? (Actually, that leads to interesting results in Google already). I am already pissed off with that misplaced connector problem (as I described few days ago), and I am more and more believing that those Italians should stick with what they do best (ice cream and pizza), and for gossake don't mess with electronics! (Just kidding, I still like Arduino).
Anyway. I spent a few hours adding button support, or better said debouncing, and using the button to switch between different screens on the display. I tried to use regular Bounce2 library, but that does not compile, and I didn't want to mess with the library. The easiest solution was to use my old debouncing code that also supports autorepeat. The code isn't mine, I found it years ago, and works like a treat. Just call this piece of code in regular intervals, like 10ms, and tweak the constants according to how often the code is being called. 

#define DELAY_DEBOUNCE 10
#define DELAY_REPEAT_START 40
#define DELAY_REPEAT 25

void UpdateButtons (void) {
  static byte id = 0x00;
  static word key_counter = 0;
  byte c;
 
  c = GetButtons ();
  if (c == 0) {                   // No key pressed
    id = 0;
    key_counter = 0;
  } else if (c != id) {           // New key differs from previous one
    id = c;
    key_counter = 0;
  } else {                        // New key is the same as previous
    key_counter++;
  }
 
  if (key_counter == DELAY_DEBOUNCE) {    // Debouncing complete
    Buttons = id;
  } else if (key_counter == DELAY_REPEAT_START) { // Repeated key
    Buttons = id;
    key_counter -= DELAY_REPEAT;
  }
}

GetButtons() returns what buttons are pressed in form of bitmap. Global variable Buttons contains a bitmap of pressed buttons. When you process particular button, clear the corresponding bit in Buttons. The constants above are fine when calling the function every 10ms.
 
(I just looked up in my old sources that it's based on algorithm by guy KimmoHop from avrfreaks.org)

I reviewed the CR2032 node and noticed that there's a potential short circuit that might ground the analog input of the battery voltage measurement when wet. I fixed that, and will give it a try overnight. The voltage is 2890mV right now (it has changed a little after I cut the traces that were likely causing the problems, which suggests they actually had some conductance... or not?)

Telling the time

A bit lazy day today, spent on eBay and selling some old junk, getting what was already sold ready for shipment, and playing with the Due central node a little. The node now retrieves the time via NTP and sets its local clock, another step towards telling the time to all nodes that are interested. I did some minor changes of the code, added button and photoresistor to the node, and improved the LED support to make them blink smoothly.
The CR2032 node reported battery dead in the morning. I measured the CR2032 cell and found out that the voltage is perfectly fine. That explains what is going on - it must be the air moisture. Either it condenses on the resistors of the voltage divider, or the cheap chinese paper PCB gets soaked and its resistence decreases. I know it's a really cheap PCB and I am not blaming anyone, I bought a pack of fifty for few euros and they so far performed well. Anyway, I'll leave one of them on balcony for a day and see if it will show any measurable resistence.
If the problem is in the air moisture condensing on the resistors of the voltage divider (they're something like 1M5 and 330K if I recall the values correctly), I'll use standard through-hole resistors for the divider, and maybe smaller values. It should not be a problem, I am grounding the lower end of the divider before measurement, thus it should not draw any noticeable current anyway.
Speaking of power consumption - after the node dried up and the reported voltage stabilised at 2920mV, it didn't change a single bit. Did I finally succeed in creating a sensor node that will run off the CR2032 cell for a few months at least? *evil grin*

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.

Arduino Due Central Node

I started working on the new central node yesterday. After giving up RasPi as the problems I faced and expected were more than I could stand, I decided to go back to roots. Mega was one option, but I decided to try Due this time. If that won't work, I can still go back to Mega, but so far so good, and I am knocking on wood here.
Anyway, the ILI9341 library for Due works just great, the ENC28J60 network behaves as well, and both work together. I wrote really basic sketch just to test the hardware, called DueCentral.  I plan to move all the diagnostic output to TFT as a first step, and make sure that I can get exact time from network. The node also acts as a web server, maybe I could use it somehow? Like a table of all sensors etc...
Of course, when attempting to slap the stripboard on Arduino, I got pissed off again. I definitely need all the connectors to be available on the stripboard, including the famous one that's shifted by 50mils (pins 8-13). This connector provides some pretty important signals, like 10 for SPI CS, and the rest is available as PWM. Oh well, what should I expect from a board designed in Italy - the guys should stick with making ice cream, and don't mess with electronic.
I wanted to update the GM counter sketch yesterday, but I figured out I don't really know what I expect to be displayed and measured, so let's leave it alone for a few days.

ENC28J60 library, GM counter - part III

Lazy evening today, but what would you expect on Monday. I spent most of the time getting the ENC28J60 library to work on Arduino Due, and I succeeded in the end. One of the problems I met was the fact that Due fed from USB cable wasnt' able to provide enough power to the network chip. That was really strange, as the USB cable was connected to a powered hub, but whatever... after using a barrel jack with 12V, the network started to work. I had to do a few minor changes in the library itself, mostly sorting out of the small incompatibilities, like replacing "sei" with "interrupts" etc. The library is available from SVN, revision 154.
I changed the code for GM counter slightly to update the CPM more frequently, basically guessing the CPM based on 5 second measurement with a running average over 30 seconds, and I changed the display from mR/h to uR/h. The natural background shown is between 5-15 uR/h, which is more or less of what I'd expect. According to web, the natural background in Munich is around 0.8mSv/a, that's 80mR/a. Year has 8766 hour, thus we should expect to measure roughly 10uR/h.

ENC28J60 library, GM counter - part II

I continued with what I was working on yesterday. First task today was to get the SW SPI library working with ENC28J60. I used the old goold Ethercard library by Jeelabs, and the porting went pretty well. I did not care to port it properly, with defines and stuff, I just wanted to verify if it works. It does, despite the fact I am using digitalWrite, and the demo properly displays the web page. I'll polish the library in upcoming days, test it on Due (I used Uno for tests today), and will put it into SVN repository.
I also finished the hardware of the GM counter. Nothing big, just small change of the hardware, and adding Arduino Pro Mini and Nokia display, plus some small changes of the HV power supply. I tried to replicate the other power supply, hoping to get the power consumption under 1mA, but no matter how I tried, it stays around 2.5mA unloaded. I don't get it, the power supply is the same, just the transistors are different, and the capacitors are actually smaller - 6.8nF instead of 18nF. Anyway, the whole thing is not supposed to be switched on for extended period of time, and Arduino and display also consume some power, so there's no need to keep it low... but still. I am really curious what causes this. I found some reasonably prices disc ceramic capacitors on eBay, and those should be smaller than the ones I am using (size-wise), which, combined with a small tube like SBM-21 could make a nice pocket geiger.
I put a very simple software into the Arduino, basically just to find out how it performs, and added basic CPM -> dose calculation based on the SBM-20 datasheet for Ra226. The hottest ore sample I have shows 4 mR/h (on the picture). I bought it as uranocircite, although I guess that there's some torbernite in the sample that's much more active, because the most active part of the sample does not fluoresce, so that's most likely not uranocircite. The reading depends on which value of the CPM -> dose I choose, there are some similar values for Cs137 and Co60, but the final number will be around those 4-5 mR/h.
I have a few ideas for the software, based on these kits. That's definitely something I want to finish next week!

ENC28J60 library, GM counter

As promised and planned, I took better look at the SW SPI modification of the ENC28J60 library. I am not sure I mentioned what library I am using, so here's the link.
Unfortunately, there are two problems:

• the library I originally got was version for regular Arduinos. It took me some time and research to find out there is a branch numbered 1.5.x that is compatible with Arduino Due and Arduino 1.5.x. In fact, I figured this just as I am writing this text. I originally only got a ZIP file what was linked from forum, and just now I realized it's a branch of the library. Anyway, I had problems to compile the thing, and in the end something went wrong and the library stopped work at all. I suspect Arduino, I was changing the versions of the library, and at one moment I had Arduino actually using a library I already deleted!
• the library seems to have a known bug that the communication hangs after a short while. This was supposedly fixed in the branch I didn't have this morning, so I had no chance to test it, and then I moved to another project.

However, my SW SPI modifications actually worked.  The problem I was facing yesterday was just a minor bug in SPI read. The SPI clock goes high, then the data from slave can be read, and then the SPI clock goes low again. After fixing this, Due communicated with network... until the library bug caused it to hang.

I was fed up with that, and moved to the GM counter project. I used slightly different HV power supply for this variant, and it wasn't a good idea. The power supply is safer, sort of, because the output voltage bleeds to zero quickly when I remove the battery. The previous power supply kept the output capacitor charged, and despite it's just something like 10nF, those 450V made a nice spark when I shorted it with a screwdriver! The new power supply drops the voltage to zero within a second or so. Another problem with this new one is the power consumption - unloaded, it draws around 5mA from 5V power supply. The old one, with some tweaking, draws less than 500uA. I am considering to change the new power supply to the old one. See this page. The very first one is the "new" one, second is the "old" one. The second is simpler and better, and given the fact I power it from 4.2 LiIon, there's no need to stick with the new design.
I also found out that when it comes to inductance, bigger is better. The guy recommends 10mH, but I am getting the best performance with an inductance so big I even cannot measure it. The second best is my home wound pot core inductor with something like 80mH. Less inductance means bigger power consumption.

I also received some small toroid cores and I tried to wind my own inductor in an attempt to make the 10mH reference one as being used by the "old" HV power supply. I found nice video about winding toroids, and tried it myself. It's a good idea, unfortunately my wire was thinner, and curled all the time. It took me a lot of time to straighten the curls every turn, and in the end some curls bent, and the wire broke after some 30-40 turns out of 100 planned turns. The enamel on the wire was pretty worn out at some spots, and I wouldn't really want to use the resulting coil in a mission critical application. However, with thicker wire, more patience and after finding a way to straighten the wire so it stays so, I can make my own inductors!

The fastest way to high inductances turned out to be a combination of pot core with plastic holder, and an electric drill. In no time, I had a pot core with few hundreds of turns.

ENC28J60 library for Due

After sorting out the priorities and deciding on features, I found out that the ENC28J60 ethernet chip will be connected over software SPI.  I don't expect any heavy traffic, and anyway, the software SPI on Arm shoudn't be that bad (it turned out I can get to something like 1MHz, which isn't bad at all). Modifying the library for the soft SPI wasn't that difficult, but the debugging was.
It did not work, no ping, nothing. I wasn't surprised, as I expected a few packed structure and endianity problems. First thing I wanted was to check if the soft SPI implementation works correctly. I took the Saleae logic analyzer, hooked it to the SPI bus, and captured the communication. All looks fine, the values make sense, and they're same as the values the code actually tries to write to the chip. I was a bit puzzled by the fact the chip does not send any meaningful output, the MISO line stays at the same level all the time. However, after capturing some more, I actually noticed that later on, the chip sends some data via MISO line.
All looks good, but still, there's no ping, no matter what. As a next step, I'll add some code to read something from the chip, preferrably a known value, like stepping or something to make sure that reading also works.
When looking for some details on the web, I found out that the same guy who wrote the UIPEthernet library I am using also wrote the Due port of it. That one still uses the HW SPI, but could help when it comes to those problems when migrating 8bit to 32bit code.
Completely different topic. My telescope arrived yesterday, but so far the sky wasn't clear and I had no chance to test it, hopefully over the weekend. It's a very cheap and basic telescope and I don't expect miracles, but hopefully it will help me to identify the planet I am seeing every evening from my window.
The other thing that arrived yesterday are the fuse holders that I am planning to use as holders for the SBM-20 GM tube. If my wife's computer behaves and won't demand my attention, I could have quite interesting weekend!

RasPi or not...

No updates yesterday, sorry. I was looking for the best library I could use for the ILI9341 display from C code on RasPi, and ended up rewriting the Adafruit library. However, the whole thing is object oriented, inheriting stuff from the GFX class that inherits the stuff from Print class... not that it's impossible to port all those to RasPi, but I got bored pretty quickly. I cannot guarantee that it will work, and I don't want to waste one evening by porting a few C++ libraries, then another evening debugging it, and in the end finding out it does not work.
I thought about it and decided to go back to Arduino, abandoning the whole RasPi idea for now. In fact, there's not much of benefit in using RasPi. I was thinking about that email checker, but I still don't know I really want it. If I decide I really do, I can hook up the RasPi to the whole system somehow. The limitations of RasPi do not overcome the benefits. So - I am back to Arduino. I in fact want to use Due this time, making at least one small step towards ARM. Due has enough of RAM, enough of pins, three HW SPI ports, and even DMA.
When looking for a good ILI9341 library, I verified that Adafruit works fine, but there's another library based on Adafruit code that allows using HW SPI, and even DMA, making the display blazingly fast. Library is made by Marek Buriak (?) and can be found here.
There's a few open things related to SPI on Due. The chip supports three HW CS pins, but I might need more. Can I combine hardware and software CS? Or will I need to move some of the peripherals to software SPI? I am planning on using the ILI9341 display, ENC28J60 network, and a few nRF24L01 modules. My guess is that the ENC28J60 library will need porting, and thus using the software SPI would be the easiest way to go.
Anyway, the ILI9341 works, I'll test the RF24 modules tomorrow, and if all looks good, I'll start porting one of the ENC28J60 libraries. There's Ethercard library I am already using for other projects, and then there's arduino_uip that looks good, too. I am also running out of ENC28J60 modules, I actually had to steal one for testing from an older project that's on standby right now.

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

I spent most of the evening testing the TFT display attached to RasPi (see my yesterday's entry), and enabling it to work. The info is confusing, or at least I did not find anything that would look simple enough. In the end, I followed the guide for notro/fbtft and managed to make the display work. It's not that difficult, although it still sounds to me like magic.This is what I needed to do:

1) FBTFT drivers as loadable modules. This installs the necessary kernel drivers without actually recompiling anything:
   sudo REPO_URI=https://github.com/notro/rpi-firmware rpi-update
   sudo reboot

2) To continue using fbtft_device, add to /boot/config.txt:
   dtparam=spi=on
   dtoverlay=pitft

3) Add to /etc/modules - edit according to your connection of TFT signals to GPIOs, and according to used CS0 or CS1. All on one line!
   fbtft_device custom name=fb_ili9341 width=240 height=320 rotate=270
   speed=32000000    buswidth=8 bgr=1 gpios=reset:23,dc:18 cs=1

4) Add kernel argument to file /boot/cmdline.txt if you want to use the panel as console
   fbcon=map:10

I also need to make a final decision about the language I'll use for the RasPi code. I am deciding between C and Python. C would be the language of choice, but a lot of nice libraries, like the Adafruit TFT one, is written in Python, thus I am more and more leaning towards Python. I need to start with it anyway as we'll use it at work, and this could be a nice way to start with it for real. Let's think about it till tomorrow.

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.

GM counter tube test

The GM tubes from Bulgary arrived today, to my big surprise - I didn't expect them this month :) It becomes more and more obvious that the major cause of all the shipment delays is the German import duty office.
I hooked the tubes to my sparrow nest HV supply and tested them immediatelly. Both work fine, the sensitivity is much, much higher than the SI-3BG. While my hottest uranium ore barely made the SI-BG3 tick, the new tubes go crazy. The tubes are SBM-20 and SBM-20U. After I ordered them, I found out those are basically the same spec tubes, just the U variant is specified for more humid environment (or something alike).
Anyway, the analog part of the GM counter works fine. I'll replicate it in more good-looking fashion and add the digital part to it. I am still waiting for some small inductors from China, the one I am using right now is rather bulky. But so are the capacitors (the circuit uses voltage doubler, which increases the amount of capacitors to three), so maybe I will just use what I have. The whole counter draws something like 0.5mA from 5V power supply - not bad!

Low power failure

Not much successful day today. The first thing I realized when I woke up today was that the node from yesterday of course draws much more than I expected. I left the debug outputs to serial port in the code, followed by some 50ms of delay to make sure the debug outputs get transmitted before the node eventually goes to sleep :) Another power hog turned out to be the LDO. I sort of suspected that the datasheet does not lie when it specifies 17uA of quiescent current, and I was right.
I stopped working on it for the moment and ordered lead acid acumulator for further experiments. In the meantime, I just finished building a basic CR2032 powered node with bare 328p and using internal RC oscilator. Tests on modified Arduino Pro Mini were succesful, but the node doesn't work yet. I'll look into it tomorrow.
Update: I went shooting tanks, and quickly realized I slightly deviated from the standard Arduino schematic - forgetting the AVCC, and no pull up resistor on RESET. There should be an internal one so I thought WTF, and omitted it. Anyway, it turned out the resistor is important :) Now I have upload working and I can sleep better.

Solar power - The Search For Current

I hacked together a simple node with 3.3V Arduino and RF24 sender, just to measure the power consumption and see how long the node will be actually able to run on the energy stored in the three supecaps 0.047F. To my disappointment, it runs for about a minute, despite the fact the node is sleepping most of the time. There's something drawing much more current than I anticipated.
I need to do some further measurement tomorrow, and I need to think it over. There's an TPS77033 LDO that has relatively high quiescent current, but not THAT high. My previous measurements of Arduino (the Pro Mini with LDO and LEDs removed) showed I am somewhere around 20uA when the thing is sleeping, but the current being drawn with this setup looks more like miliamps, not just tens of microamps... strange.
I even disconnected the RF24, just to be sure it's not this thing, but that didn't help.
If I understand this right: the capacity is 0.15F, I am charging it to 4.2V and I draw current from it until it drops to 3.3V, that gives me 0.9V * 0.15F = 0.135 Coulombs. With current draw of let's say 1mA, I am able to operate for 0.135C / 0.001A = 135 seconds... hmmm...
That tells me two things:
 - these supercaps won't be enough to power the sensor for the whole night, even when the average power consumption will be below 50uA as I expect. It will be enough for about one hour of operation, and I'll need something like 3F at least.
 - The efficiency of this setup is terrible :) I really need to get back to the idea of using boost regulator to drain the supercaps till they drop.

Solar power - part II

I had some plans for the weekend, but unfortunately my wife's computer needed some attention, and I have spent most of the weekend replacing the mainboard and then getting the whole thing up and running. In the end, it looks like a monitor problem, so my whole effort was pretty useless. Anyway...
I was lucky to get some direct sunlight today around 11AM, and I quickly hooked a 10W white LED directly to the two panels in series. The LED clamped the voltage to 8V, making the panels operate way below their sweet spot, but I still managed to draw over 300mA out of them at max. That's almost 2.5W, which isn't bad! Even with some overcast, the current dropped to around 30mA and staying there.
I moved the panels to the balcony where they won't be in danger of falling down (they were origially sitting on the window ledge), and I attached a four wire cable to them, extending the both solar panel terminals to my desk (they're two 9V/5W ones). This gives me the opportunity to connect them in parallel and see if they perform any better.
I've seen some simple, NE555 based MPPT solar booster that I might try. That one charges 12v lead battery which I don't have, but that wouldn't be a problem. I would try the booster even without the battery, but... I dont have any NE555s. No kidding. I might find one in my UV-light PCB exposer timer, but I'd need two NE555s anyway.
The other way would be to go the supercap way. I am more and more leaning towards the idea of getting some 2.7V or 2.5V supercaps, and using a nanopower booster to get 3.3V out of them. That way I can drain them down to something like 0.9V at least. My idea of charging the 5.5V supercap to 5V and then using LDO to get 3.3V out of it would simply waste too much of remaining energy. More than half of it would be unusable!
I know, comparing 12V, 5Ah SLA battery with something like 10F supercap is strange... but keep on mind I am just experimenting without having any goal. I want to be able to power one sensor node with the whole thing, which means I need 10mAh per day in the worst case. But, if I could get the SLA battery charged, I could use that power for something useful... charging my phone, letting RasPi running from it, or something. The only problem is - where to keep the battery? I don't feel good about having something that nasty sitting in the living room, and leaving the battery on the balcony would mean exposing it to wild range of temperatures. Anyway, that's a distant future, let's focus on the NE555 booster first.

Solar power - part I

A small experiment this evening. This is a standard basic MC34063a step-down converter attached to two solar panels in series. The panels are rated 9V / 5W, but I sincerely doubt they would get anywhere near that. Last time I tried, I got a few milliwats from them on a cloudy winter afternoon... Anyway, my first attempt to use them with my beloved KIS-3R33S converter failed - that thing draws way too much current, making the solar voltage drop to 4V which is too low for the KIS to operate.
That's where MC34063a comes into play. Since I bought a handful of KIS-3R33S modules, I did not use any MC34063a (except for LCD panel driving voltages). It works great, playing nicely with the solar panels even when exposed to a 30W desk lamp, and makes a blue led shine! I've set the output voltage to 4.5V, but I might increase it a bit over 5V later as it will feed a bunch of goldcaps rated for 5.5V.
One thing I quickly realized - I'll need a Schottky diode to make sure the goldcaps won't discharge back through the converter on low light condition.
The plan is to convert the output voltage with a LDO to 3.3V and make my sensor nodes run from it. It's a bit of overkill, but at the moment I have no good use for the solar panels, and letting them just sit in the cellar is a waste. I need to find a good place for those panels, probably on the balcony. That'll be a challenge as my wife fills the space with flowers and stuff every spring. On the other hand, I won't need that much of light after all, and the balcony is mostly empty in winter. I'd guess that the amout of light available to those solar panels will be about the same in summer and winter after all!

On another note - I ordered two GM tubes from Bulgary, one CBM-20, one CBM-20U. The SI-3BG I have made a great proof of concept, but it's not really sensitive, and my best uranium ore sample barely makes it tick. No wonder, the tube is supposed to be used to detect high doses (300R/h). Anyway, the simple GM counter I made works, and with those new tubes... mmm!

Another thing I ordered today was a few thingies from China, namely the BMP180 barometric pressure sensor. I am considering complex sensor node - humidity, barometric pressure, temperature... and radiation background *insert evil grin here*