Temperature & Humidity monitoring

Started to build a temp & humidity monitoring system. Yes, it's a ton of them out there already but I didn't make them so they don't count.

The requirements are multiple (more than standard 3) remote temp and humidity sensors that can be inside or outside. A central console connected to computer that receive the data and can log it somewhere.

Starting with remote sensor part I now figured out the parts needed, put them together and done some coding for it.
For initial round I'm going with all off the shelf stuff. Arduino pro mini as the brain, DHT22 as sensor and the dime a dussin 315MHz transmitters from ebay. Did find a case in a local store that seems to be perfect for the remote sensors at least.
Box to be filled
Since I want to run this off 2xAA batteries I also need a booster (the sensor requires at least 3.3v).
Remote Sensor

Coding is simplified by using VirtualWire lib and DHT22 lib. Was going to use jeelib for power saving sleep but for unknown reason jeelib doesn't like the other two (any one of them seems to work, strange) so I ended up grabbing some pieces from internet to make the arduino power down completely for 8 seconds wake up long enough to see that it's not yet time to send and keep sleeping.
Need to remove the power led but with that one still installed I'm down to 3.5mA during sleep and about 22mA when sending data.

Coding I done so far has defined a protocol that is <27 bytes (VirtualWire lib default limit) and still contain all I think I currently need.
  • 1 byte: Type of transmitter, 1=temp/humidity, 2=water level, 3-127=reserved for future use
  • 1 byte: Protocol format, depends on sensor but format 2 follows (1 is missing mV)
  • 4 byte = unit no of the device, basically a random 64bit number (don't think I need the 128bit uuid)
  • 2 byte = Sequence number so receiving side know it's same msg
  • 2 byte = vcc in mV
  • 2 byte = batt mV
  • 1 byte DHT22 status of the data
  • 2 byte temp*10
  • 2 byte humidity*10
  • 2 checksum - 2 bytes
I know length is missing but the first two bytes does define format and with that length can be added if the size is dynamic.
Vcc is calculated reading internal 1.1v ref
batt is a separate wire from before the booster

On the receiving side I got it to receive data, separate the different sensors and show a csv or human readable output on the serial port.
My current issue is current and presentation.
The remote sensor is taking to much power for to long, considering changing so it only sends the data once and only if status is ok. If that transmission is lost we get it next round.

On the receiving side I'm wondering how to best present the info (besides serial output). The csv output is pretty simple
#Unitno,unitId,msgCnt,vcc mV,batt mV,stat,temp c,humid %
No time since then I would need a rtc somewhere and the time is when it's coming so the receiving app can time stamp itself.
I could add a 4x20 lcd but with more than 4 sensors it gets hard to present anything useful.
Thinking of sending it to an raspberry pi where I add it to a database and then have a website that can do the presentation.

One more thing to figure out is distance, how far away can a sensor be and what can be done to increase the range.

Update1: Managed to put it all inside the box
But I think I may have to find another sensor/add 1 battery, the stepup- converter is killing my battery even when idle.

Done some testing and decided that the stepup converter must go. Running it on 5V means higher current to start with and the converter does use some power also. I have removed the power LED in the arduino so now it's only on when sending. I also improved the sleep part so it's doing a full power down and let the watchdog start it up every 8 seconds, so time between transmissions need to be a multiple of 8sec.
Some numbers measured with a cheap multimeter.
The battery lifetime is based on 2400mAh batteries, a sampling of about 4 sec (have to check on why so long) and with a rest of 72sec:

Running on 5v from booster, mA after booster:

Active: 15-18ma
Rest: 0.58mA
Batterylife: N/A (70 days - but not really relevant since that's after booster)

mA before boster:

Active: 42-44mA
Rest: 1.49mA
Batterylife: 27 days

Power usage during using 3xAA and no step-up

Active, 3-4 sec, 11mA
Resting - 78sec, .46-.47 mA
Batterylife: 98 days

So if I run on 2 batteries it takes 3x more power during rest than if I run on 3 batteries and no booster (partly because it's then running on 3.6v instead of 5v) and that means 3.6 times longer between battery replacements. While the arduino can run of 2 batteries the sensor requires at least 3.3V so I need 3x.

Version - 0.4 of the remote sensor code, still need a lot of cleanup but it works


Clock system

It's a clock challange open to make the ultimate clock that I joined (please go there and vote). Since it been a while I feel it's time to write down something about what I'm up to in regards to it.
I looked around a lot trying to figure out some new way to present the time but it's not that easy. I was thinking on things like a bookshelf, Domino 9, gear clockrolling ballPropeller clock and many many more but whatever I thought about it was already done a thousand times.
I talked to a friend for ideas and he suggested to attack the backend instead. The plan is to make a clock that is modularized. It has a base with the smarts in it. Then you plug in a presentation module on top to show the time. In the base you have holes/slots where you can plug in modules for atomic clock, GPS time, ntp over wifi (both receiving and broadcasting), your smartphone, radio, audio and so on.
The units communicate over i2c/spi bus with some defined protocol so that you can plug in things and it just discovers it and starts using it.
Now the first version will be some 3D printed base with modules that plug together. For display it can be a simple 7SEG display or analog clock that is just put on top.


Light following robot

I joined the Ottawa Hacker Challange where you get a mystery sensor and this time it was a light sensor that need to be used.
For some time I wanted to make a simple robot and after watching lots of line following robots I now decided to make a light following robot.
I got a basic chassis

and the plan is to put two servos on top with the light sensor on. They then sweep around, find the brightest direction and go towards the light. With that I can have a light source hanging in front of it and it will follow it, at least that's the plan.
I added some hardware to read the encoder wheels

 to be able to control the direction and a I2C based LCD to show some numbers.

Got it to partly work but the motors are so weak and unbalanced that when I go full speed on one and 60% on the other it still can't go straight and when I go below 60% it stops completely.
While pondering  on what to do I passed by a thrift store and found a simple radio controlled hummer that I bought for $10.

The default function is binary, it's full speed forward or back and full tilt left or right so it's limited but I'm not interested in that part, I did go for the chassis. A single motor that I can control the speed on, replace the full tilt servo with one I can control with better precision. Add the sensors and so on and I have something that might work.
So far I only managed to rip out the provided electronics and put in my servo but I'm not sure if it's strong enough.

Added the controller and got it to move around. It is moving a little at 25% and is to fast at 100%.
Steering works but is somewhat limited, no more then 20 degrees left and right (=total of 40) but it was like that before I changed it so it's not my mod that caused it.

What's left now is to figure out how to mount all parts and some programming. May need to add some kind of remote control to stop/start it or it will drive around at some predefined speed all the time.


Kinetic Lance - completed version

Now when it's completed I do a new follow up on my previous post on how what to make with a proximity sensor.

A friend (who like to stay off the net) suggested a kinetic knife. It's about a knife that has to come close but it can't touch. (The idea comes from the books/movies "Dune" where they have kinetic shields).

After working on it for a while I have now managed to get everything together and working. Did some minor changes but over all it works better than expected.

From the top - component list
* Lance from the $$ store
* Long breadboard
* 2xAAA battery holder (inside the handle)
* on/off switch
* DC-DC Booster to convert 2.4V to 5V
* Arduino Pro 5V 328 16MHz
* 2x74HC595 shift register
* 1xULN2803 driver
* 5 RGB LEDs
* 4x7SEG display, Common Cathod
* Buzzer to make some noise
* 9x66.5 ohm resistors (58-100 probably works fine)
* 1x10K ohm resistor
* 5x330ohm resistor
* tcrt5000 sensor
* some wires

The Schematic for it, the battery and dc-dc is missing and using common anode RGB LEDs could been better (use driver IC instead of shift register) but now i had common cathode ones at home so that's what I used:
After figuring out where to put everything and solder all the wires the assembly was done.
The programming was next step and after changing around things I managed to get it to work the way I want it - here is a short demo

The code contains interrupt timer controlled driver for the digits using SPI to send it to the shift registers, just load an array with the numbers you want to display and forget about it. I'm happy with the way that part of the code worked out and will probably use it else were if I need it some other time.
The rest is just some logic to count points and make the RGB LEDs flash.

Version - 0.5 of the code

(photo credit to my shy friend)


Ottawa Arduino Challange - lance sensor/kinetic lance.

I joined Ottawa Arduino Challange where you get a mystery sensor and then need to make something out of it. Besides figure out what to make of it I also need to make the project available on internet so people can see what I'm up to so I'm now writing this down.

The mystery sensor given is a proximity sensor called tcrt5000 and the datasheet indicates it's effective range is 0.2-15mm, practical testing indicates it's a little more depending on what the surface is.
When looking for what to do with it the first thing google took me to was all this robots that follow lines so that I quickly scratched any robot from my project list.
A friend (who like to stay off the net) suggested a kinetic knife. It's about a knife that has to come close but it can't touch. (The idea comes from the books/movies "Dune" where they have kinetic shields).
I have some other ideas but they need more time/material so I decided to go a version of this knife and at $$ store I found a toy that can be used for it.

The plan is
- loose the bubble juice
- use a arduino pro (the small board above the lance) to control it
- set the sensor in the tip
- add some LEDs in the lance part that flashes and shows when you get close or to close(hit)
- somehow add a 7seg led to use as counter
- put the electronics in the transparent part (so you can see it)
- put the battery in the handle (as counter balance)
- maybe put in some noise maker
Usage - it's a  game, you need to get close but can't hit. The closer you are the more points but hit and you loose points big time/get to zero.

So far I only figured out how to use the arduino uno as a oversised usb adapter to program the small arduino pro and got it to flash the built in LED different depending on distance that the proxy sensor give.

As I figure out more (like how to format this) I will update this page.

Update1: Have done some testing and coding and got just about all of it to work. Still need some tuning but I got a led showing points, it counts up when close and counts down when hit.
Got one bright RGB LED to indicate score/hit, plan on add more in parallel.

Version - 0.4 of the code


Done some more work, created a eagle schematic of what I plan to do and started assembly.