TinyOS-2.x zigbit serial communication

As mentioned in the previous post, due to the fact that we were downloading the Motorola S-record file ‘main.srec’ via Serial Bootloader (using meshprog on Linux), fuse bits were not getting updated. If we had used JTAG interface (e.g using DRAGON Kit) and aurdude, this would have happened. S-record can have application code as well as fuse bit setting, unlike Intel Hex format.

This meant that the default TinyOS setting of 8 MHz for clock rate was not appropriate for this since Meshbeans are set for 4 MHz by default. So to get the Serial Communication working, we had to make the following changes:

1. Check the following  in

tinyos-2.x/tos/platforms/meshbean/hardware.h

=> change clock rate to 4 MHz by

#define MHZ  4

=> Change here the default baud rate, if you need – 57600 works fine for me

#define PLATFORM_BAUDRATE 57600L

2. make sure that:

“The file chips/atm128/Atm128Uart.h contained some wrong constants, which produce  strange results. The correct ones can be found in the ATmega 1281 datasheet and are:
ATM128_38400_BAUD_8MHZ_2X = 25
ATM128_57600_BAUD_8MHZ_2X = 16”

This change would not have effect on 4 MHz clock that we are using but its best to correct them anyway. Anyother Baud Rate combination can also be added.

I must add here that give a choice use a crystal which gives less errors  – e.g. 3.6864 MHz instead of 4 MHz , similarly 7.3728 MHz instead of 8 MHz. (See the ATMega128a manual).

3. With these changes done, now one can try TestPrintf utility. Do read this README file :

http://www.tinyos.net/tinyos-2.x/apps/tests/TestPrintf/

I was first looking at serial data using MiniCom – this was producing some unprintable characters including what is expected. One has to use the Jave client to get the proper message displayed as output of Printf command. I used the following command to get the data displayed right:
java  net.tinyos.tools.PrintfClient  -comm serial@/dev/ttyUSB3:57600

Here /dev/ttyUSB3 is the port to which my meshbean module was connected vis USB port.

This would give the this  output in a loop:

Hi I am writing to you from my TinyOS application!!
Here is a uint8: 123
Here is a uint16: 12345
Here is a uint32: 1234567890

TinyOS-2.x on Zigbit – Baud rate mismatch

We tried to use TinyOS on Meshnetics Meshbean modules based on Zigbit module containing both microcontroller and radio transceiver. Fortunately a port was made available as a contributed code. I got many student group to start using TinyOS on Meshbean modules. However no one could get the UART communication through USB port working and all the projects which needed this got stalled. I took up this task as I got little free now to figure out what may be happening. It looked like a Baud Mismatch problem since we were received some characters but no baud rate setting was making it come right.

I think I have now understood the problem and however need to try it out tomorrow to make sure that my guess is correct. I am writing it up now and would verify later.

TinyOS port by Distributed Computing Group, ETH used JTAG interface to download firmware into the Meshbean module. This had the capability of programming fues bit as well. What we have been doing is to use Serial Bootloader to program the modules. This does not have the capability of programming the fuse bits. My guess it that due to this the Baud Rates do not match to the right value since clock related fuse does not get set appropriately. I also noticed the default settings of fuse bits are different in Meshnetics software as compared to TinyOS :

Meshnetics : 0xFF, 0x9D, 0x62.

TinyOS : 0xFF, 0x99, 9xE2

So Meshnetics default settings may not work specially since CKDIV8 is the most significant bit of low fuse byte (0x62 vs 0xE2) and can have impact on the clock rate.

I plan to use Dragon to do JTAG programming of Meshbean modules and verify my guess! If it works, we can work on doing Time Synchronization development for seismic measurements.

[Added later : My hunch was correct. Dr Philipp Sommer, who is managing TinyOS port on meshbean also confirmed same. I adjusted some parameters based on his suggestion and it nearly works now. Would update more details in a separate blog.]

Meshprog – USB device opening failure on Fedora 11/12

I had been using meshprog to program Meshnetics Zigbit Evaluation Modules on Linux. I discovered that it was not getting programmed on Fedora 11 or 12. It took me some time to figure out what was happening. I am recording this here in case some one else faces the same problem. Here are my observations:

1. Meshnetics modules use UART to USB converter from Silicon Labs – CP2102. This has idVendor=10c4, idProduct=ea60 as shown by Kernel message.

2. I found that /dev/ttyUSBx to which it was getting attached was not opening by Meshprog

3. System log showed the following :

May 22 20:56:28 ranjan kernel: usb 4-1: cp210x converter now attached to ttyUSB3
May 22 20:56:30 ranjan NetworkManager: <info>  (ttyUSB3): ignoring due to lack of mobile broadband capabilties
May 22 20:56:30 ranjan gpsd.hotplug: gpsd_control(action=add, arg=/dev/ttyUSB3)
May 22 20:56:30 ranjan gpsd.hotplug: socket /var/run/gpsd.sock doesn’t exist
May 22 20:56:30 ranjan gpsd.hotplug: launching gpsd -F /var/run/gpsd.sock
May 22 20:56:30 ranjan gpsd.hotplug: socket /var/run/gpsd.sock doesn’t exist
May 22 20:56:30 ranjan gpsd.hotplug: can’t reach gpsd

4. So it looked like it was trying to attach it as a GPS device by starting gpsd

5. I located the hotplug rule for this and disabled that. In Fedora 11 it s in :

/etc/udev/rules.d/99-gpsd.rules

I commented the line :

#SYSFS{idVendor}==”10c4″, SYSFS{idProduct}==”ea60″, SYMLINK=”gps%n”, RUN+=”/lib/udev/gpsd.hotplug.wrapper”

6. Now it works !