Friday, January 1, 2010

Very Interesting Development

While a friend was over, Mum was talking to his Dad. He said that it would be fine to have a unit that is stationary, with no connection to the internet. Mum argued that it would be easier to have live data streaming to the computer. My friend's Dad said that it is easy to have a council worker drive to the unit, and download data from it.

This is interesting as I no longer need to worry about an internet connection. The internet can be an optional add-on rather than the main logger. The internet connection would be a tack on, and not affect the original system. It would listen for data, and relay it to the internet. Simple.

My job has got a whole lot easier. Instead of having to make long range antennae, I can simply have them transmitting to the one base unit. This base unit will somehow upload data to a laptop. Be it a removable USB stick, a cable you have to plug in, a wireless setup. Who knows. Bluetooth is expensive, and hard to use. WiFi would be completely new (not including the router). The HopeRF is an option. If I put a USB to serial adapter in, then I am all set for your average laptop.

I want to get away from modules such as the wireless router. If I go comercial, it is going to be near impossible to get the routers I need. They go out of fassion, they are hard work to get to the stage where thay will work, they are more expensive. Eliminating the router has been a good decision. Instead of a funny looking module, I can have a professional looking box with a custom built board. The only modules i can't get away from are the HopeRF modules. I don't have the skills, tools, or know how to build my own wireless units to the caliber of the professionally made ones. Luck for me they are very small boards with a rubber duck antenna attached.

I need to think of a storage and retrival method. That is the next step on the hardware side of things in my opinion.

Sunday, December 27, 2009

Order Arrived

My LCD screen arrived! Along with the switching regulators.

Turns out the switching regulators were the wrong ones. They do perfectly fine on 3v, but not at all on 1.2v. Thankfully, futurlec sells another one by maxim which is designed for 1-cell operation. I'll include it in my next order. The alternative is to wire two solar garden lights together, and have a two cell system.

I also need to figure out the windmill, the voltage varies a huge amount, and I was thing that charging a 3v battery pack might be the go. My only concern is voltage, as the windmill can get pretty fast! Maybe I should keep an eye out for a dedicated two cell charging chip - accepting a wide range of voltages.

On the web interface, I am rather stuck. I need to make it so that I can edit configuration files from the internet. PHP doesn't have any major line editing functions, but I have figured out a few work arounds. Next time I work on it, I might get somewhere!

Wednesday, December 16, 2009

What's been happening?

Where have I been!?

I've started working on all sorts of projects lately. Largely due to the long lead times on low priority shipping from Taiwan. I've ordered a new LCD - this one is a graphics LCD! - and some switching regulators - to power these devices from 2 AA batteries.

I need to get my entire sensor net up and running. I'm considering building a USB powered device. It's easy, and has no major power design issues - unlike the solar powered version I haven't managed to get working! I'm ordering two switching regulator sets, so when those arrive I should be sorted. One is going in the garage with a 3v battery pack, and one is going to be wired to the solar garden light. This one will be fed on a 1.2v NiMh AAA battery charged by the solar panel.

On the software side. I have a fully functional, but not yet fully featured python script that runs on boot. The trick was to put the start-up scripts in the original root, not the pivot root! A hurdle I am currently experiencing is time. I need to synchronise the router with a NTP server - a server designed to update system clocks. This will give my router the correct time as it has no backup battery / capacitor. That is the easy part... That hard part is making the router use the correct timezone. I could call it a feature that it uses UTC (Universal Coordinated Time - not an acronym mistake!), but I would really prefer it used the local time. Hopefully I can change this in the python program rather than the router itself...

I have successfully made an LED that will turn on and off via an SMS sent to twitter. The direct message is read by the router, and this triggers the LED. I plan to use this for a fan I have - the type used in summer for keeping cool!

No photos as of yet. The whole device is still in the early days.

Saturday, November 21, 2009

Scripts, and more scripts...


My router runs three different scripting languages now. Built in bash, lua, and python.

A person suggested lua as an easy scripting language already supported in OpenWRT. The problem was that I couldn't get processes to start on boot. So I set up a simple lua script to try do the job.

The problem wasn't to do with init.d however. The problem was I used pivot_root - a tool to create a new '/'. This meant I could move the old root to /mnt, and use my USB stick as /. Anyway... To get things to start on boot, I had to copy my init.d to the old root and make the symlink to rc.d.

The lua script is now redundant, so I might get rid of it. It does however make it easy to add new stuff without having to copy the script and symlink - not that that is hard...


My router now starts a *working* pythong script, a server for hosting my website (lighttpd), and a server for uploading files to my website (vsftpd). Everything it needs to do it now does!

Finally I can stop repeating myself on the router, and start getting a functional system online! The only major router stuff to do is:
  • get python to read twitter names from a text file
  • get the website's members area to edit the above file
  • get ntpclient to run on startup, and edit the timezone to NZDT
I figure I will get the *.CSV files to be created fresh daily. So at 0000 to 2359 is will have one file, and the next day there will be a new file. This will make it a little easier to see what happens day to day.

I think I will get python to create a 'comments' log file. It will be more user readable than the *.CSV files, and will include things like boot, message file edited, and any other useful stuff I can think of.

I've built the simple indoor temperature sensor into a warehouse box I found (don't worry mum, it was from an old project!). All I need now is a power supply. The HopeRF units need a steady 5v. This makes powersupplies hard to design, as I want them to be efficient, and low power. I'm hoping for atleast a one year battery life. Did somebody say switching regulator?

Friday, November 20, 2009

Long Day

Been a long day today... I've managed to svn checkout the latest trunk, configure the image for flashing, compile the binaries, flash the new firmware via TFTP, configure the basic network options, set up a pivot_root so I can have more space (uses 32MB flash drive), re-configured network stuff, installed lighttpd, vsftpd, python, python-twitter.

The damn init scripts wont work! For some reason the /etc/init.d/lifghttpd and /etc/init.d/vsftpd scripts will not activate on boot. They have been enabled and made executable.

The only work around I have left is to lower the serial port baud rate, and use a microcontroller to start them. A higher power type deal. The micro waits for a particular string (I'm thinking a long pause might be easier...) and then sends a linefeed. This will acitvate the console over the serial port. The microcontroller will have to send a few commands to the router. Then there will be a python program running in the FOREGROUND. Instead of using pyserial, I will just have the python wait at a raw_input() command. The microconroller will talk directly to the python program.

I don't like this solution. It seems like a stupid idea to have a microcontroller take the place of a person when it shouldn't need to. The router should be able to run the processes on its own.

Wednesday, November 18, 2009

It works!

Took this video a while ago, but I'm showing you now =)



At the moment I have flashing new router firmware. A few things were going wrong with the last lot... I'm hoping to have that done before I go to bed. No school tomorrow, so I'll be able to get lots done! I might even make a blog post about it!

Monday, November 16, 2009

New Plan

AVRs are hard. Coming from a PICAXE background they are hard. Development time with a PICAXE was a few minutes to a few days. I still have only managed basic tasks with AVRs that took minutes on a PICAXE.

So, I have decided to build the system with PICAXE, and replace them with AVRs. What this will mean is I have a working system online, can easily add features, and not spend all my time learning. AFTER I have a working system, I will then try copy it with a bunch of ATmega48s. After replicating the circuit on a breadboard, I will order a collection of SMD parts, etch a board, then solder together a nice small finished product.

Basically, I will get a system online, and then take my time with the AVRs. Each unit will be done as standalone - I will replace individual components, and keep communications protocols the same. Once I have a fully operational AVR system, adding new features (software I might add) shouldn't be too much of a task.

I spend a bunch of time working on an AVR project, and don't get very far. It took me a weekend (on and off) to get a HopeRF -> AVR -> 16x2 Character LCD. This in PICAXE would have been a simple excercize, but for AVR it meant learning how to interface the LCD and the USART. Both very simple on the PICAXE.

I have big plans for microLOG =)