Strobotics

New boot loaders for the WidgetBoards have been uploaded to both SVN and to the downloads area.  The fuse settings have also been updated in the documentation.

I’ve also integrated the Atmega328P version of the WidgetBoard into the Arduino development environment so please update your boards.txt with the one from SVN.

I have successfully re-compiled and re-flashed the firmware source to remove the console on ttyS0, as suspected the console attached to ttyS0 was the root of my problems, now avrdude will talk to the WidgetBoard!

and here is my WidgetBoard booting my test blinky on ContikiOS as seen by the gateway ttyS0

now back to writing the contiki radio driver…..

I’ve had some mixed success with the serial port hack on the Airlive device since my previous post.

After setting up the uclib development environment I have now successfully compiled avrdude so I can program the RFM12WidgetBoard located inside the device, however I had a couple of issues when trying to talk to the WidgetBoard.

Nothing happens when trying to query the WidgetBoard…data is going out the serial port but nothing being returned.

First problem I found….crossed Tx and Rx due to a silkscreen error on the WidgetBoard, the silkscreen for TxO and RxI are wrong way around on the PCB.

After fixing this problem and re-testing Avrdude it’s still not working….so further testing…..

Serial port is definitely working and I now have a serial console to the device.   When I connect up a terminal program via my FTDI USB ttl serial cable I can see the boot process and logon to the console via ttyS0, which is probably one of my problems, the bootloader may be getting confused by the console chatter. 

The trace below confirms this.  I’ve re-flashed the WidgetBoard with my blinky  example from the Contiki port, besides blinking the LEDS it also outputs a string “There is” to the serial port, you can see by the trace what the WidgetBoard is sending, and the output sent back by the console.

By default this kernel has the console attached to ttyS0 (see my previous post and the dmesg dump) so one of my next steps will is to recompile the kernel and disable the  serial console access attached to ttyS0.

The WidgetMesh network development for the Widgets is now underway, the last couple of days I’ve been learning how everything fits together in Contiki OS, as far as drivers go and how they communicate with the upper stacks, lots of looking through existing code.  I now have a reasonable idea of how things should work and how I need to write my driver.

That said the biggest problem with the WidgetMesh is going to be on chip resources, especially with the ATMega168 and maybe even the ATMmega328P, I’m not looking at running an IP stack on the mesh (well at least not yet), but the gateway/coordinator device needs to keep track of the nodes in the network.  It’s role is to manage node associations, link forming and routing within the mesh, so this will require more ram than most of the nodes will have, especially in larger networks.  It’s also the gateway to the world for the data collected.

I’ve been scratching my head as to what I’m going to use.  I was leaning towards an ARM7 hooked up to a RFM12 or WidgetBoard, something along the lines of a make controller as I have a couple at home from past tinkering, or one of these ARM9 devices running Linux, the MMnet1001, from Propox, Both these have onboard Ethernet and plenty of resources for what I want.  But it turns out that I had a solution at home already, in the form of an Airlive NAS device, WMU-6000FS.  The Airlive NAS comes with Ethernet, WIFI and x2 USB ports, also PATA or SATA hard drive, all this runs from a 12V supply, so I could also run this from a SLA battery.

The Airlive WMU-6000FS is a not so great NAS device that I evaluated for work project involving offsite replication.  The project was eventually shelved. 

The great thing is that it runs embedded Linux, after a bit of research found that I can re-flash the current device easily with a distribution from http://mgb111.pradnik.net/ will allow me to make changes to the system, whereas the current flavour is embedded and is Read only, all changes are lost at boot, however no documentation anywhere regarding serial ports, or in fact if one exists onboard. 

I proceeded to re-flash the board with FW C009-M2 Advanced firmware, this gave me console access, once in I checked that Linux is detecting a Serial Port.

-bash-3.2# dmesg | grep ttyS0
Kernel command line: rw console=ttyS0,38400
ttyS00 at 0x03f8 (irq = 4) is a 16550A
-bash-3.2#

A UART is being detected and is used by the system as a console.

Here are the memory and CPU as reported by dmesg, so plenty of resource for what I want.

Initializing CPU#0
Calibrating delay loop... 44.33 BogoMIPS
Memory: 29984k/32768k available (1418k kernel code, 2396k reserved, 337k data, 56k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
CPU:     After generic, caps: 00000000 00000000 00000000 00000000
CPU:             Common caps: 00000000 00000000 00000000 00000000
CPU: Cyrix Cx486SLC

This can only mean one thing.  Time for surgery!

Disassembly

Disassembly is very easy, two screws at the rear allow the extruded aluminium case to slide off , at least it’s solid.  Inside is a 1TB drive that I had swapped out with the original some time ago, so If all goes to plan then I’ll have plenty of storage available for the Wireless Sensor Network.

I love it when designers of hardware have fore thought to design in for future expansion, adding a second antenna is going to be simple enough, just drill out the rear cover to suit, actually the cover already as the markings on the inside for this.

Also another Spare antenna mounting hole, perfect for a reset button.

Search for the Serial Port

Prime serial port candidate CN2 (10 pin socket centre of shot) ,  The processor (top left) is an RDC 3210, a 486 equivalent.  The  datasheets (no longer available from RDC website, but found via Google) tells me that the CPU has a single onboard UART that the pin outs coincide with the rough location of the CN2 header, either it CN2 or part of the larger connecter, but I doubt it.

Continuity tests of CN2 confirm that this in indeed the serial port, some further checking and voltage measurements confirm everything I need is there. Whoot!

Adding the WidgetBoard

I moved the Wi-Fi antenna SMA across to the spare and added in an SMA pigtail to suit a 915Mhz GSM antenna that I use for my WidgetBoards.

Next wire in the Serial port to an external header

WidgetBoard trying out it’s new home with SMA pigtail connected.  Actually this is the first of my Widgetboards to use the Atmega 328P processor.

I used the third spare antenna connecter on the right for an external reset button for the WidgetBoard, may not be required, but hey, if the DTR reset does not work at least I can force the issue.

All wired up and safe and sound in a simple card surround to stop any shorts from happening.

All boxed up to see how it all all goes together, 2.4Ghz and 915Mhz antennas side by side and reset bottom right.

Next Step

The next step is to get minicom and do some further testing, along with getting a version of avrdude working from the Linux console, this will allow me re-flash the WidgetBoard locally if the need arises.

I’ve just committed my current progress on porting Contiki Operating System to the RFM12WidgetBoard to SVN.

• Serial working
• LED API implemented.
• Event timers now working.
• Added blinky example that demonstrates all of the above.

Now compiling to 5166 bytes of flash and using 387 bytes of ram.

Next step is SPI and RFM12B drivers!

I’m still alive…… Its been awhile between blog entries, unfortunately this is the busiest time of the year for me at work, the few months after the Australian financial year, projects are kicking off due to funding etc.  There is however light at the end of the tunnel and I’m hoping to get back to geeking very soon

I thought I’d let you know that a) I’m still alive, and b) what’s been happening on the development front.

In between work projects I’ve been porting the Contiki operating system to the widget as the underlying event framework for WidgetMesh.

I now have the Hello-world application up and running on the Atmega168 @10Mhz, no radio drivers or anything else for that matter just yet.  For those interested it’s been checked into SVN.  I’m learning a lot about Contiki and how it all fits in together (i.e. I know that I don’t know much at all about it)

On the hardware front the next iteration of the Widgetboard is idle, though pretty well stable as far as the design goes (might be a couple of small tweaks before boards get made).  I just need time and resources to get the next round of PCBs ordered and tested. 

Noteworthy design changes include:

• Standard smd or PTH crystal footprint, allows the use of a standard HC49 crystal of your choice.
• Lots of changes to the board supply side of things. Board voltage supply input range from 0.7V to 16VDC (probably beyond to 20VDC but just to be on the safe side…)  The core components are still powered  @ 3V
• Minor changes based from user feedback of the current board.
• A couple of optional onboard sensors to utilise the normally unused A6 and A7 analogue only ports, these can be disabled via onboard solder jumpers if these ports need to be used for something else, but has a temperature and light sensor, so the widget board can be used as a basic standalone wireless sensor.

I’ve been meaning to run off another batch of WidgetBoards and have been waiting for some processors, a month ago 40 Atmega328P processors arrived after a 5 week backorder, according to my vendor these were hard to get, hopefully supply issues will settle down after production catches up with the the initial demand for Atmega328P. 

All future widget boards will now have this processor as the default in the next batch of boards I make.

Sample parts I’ve been ordering for various future projects have been steadily rocking up and sitting in my ever growing inbox, the RFM22 arrived some time ago and I’ve not yet had time to play with them either   sigh