Research

I made a backup of the stargate before I attempted doing “radical” software changes, and am glad I did. I decided to try out mobilemesh, and since the stargate software is based on the software at [http://familiar.handhelds.org/releases/v0.8.2/feed/base/] I decided to download mobilemesh and all the dependencies that it listed for mobilemesh. Listed in the actual package file, which is a debian package file (do `file filename.ipk` if in doubt). Since I knew how to extract data from a debian package I just did a `ar x filename.ipk` and then I was left with a control.tar.gz, data.tar.gz, and debian-binary files. The interesting ones are the gz’ed ones. The data.tar.gz file holds the actual files that become installed. In this case, all that control.tar.gz contained was control, which has the dependency information that I was seeking. This is what the control file form Mobilemesh looked like.

Package: mobilemesh
Version: 1.2-r1
Description: MobileMesh mobile ad-hoc routing protocol
Section: console/network
Priority: optional
Maintainer: Bruno Randolf
Architecture: arm
OE: mobilemesh-1.2
Depends: libcrypto0.9.7 (>= 0.9.7e), libssl0.9.7 (>= 0.9.7e), libstdc++6 (>= 3.4.3), libc6 (>= 2.3.2+cvs20040726), libgcc1 (>= 3.4.3)
Source: svn://meshcube.org/svn/application;module=mobilemesh;proto=http
Thus I see the dependencies are libcrypto, libssl, etc.

I need to get all those files, so I did.  Then without really thinking all that hard about it, I decided to just install them all by copying them over via ssh.  I copied over some library that was being used (libc6……and caused a fun kernel panic and thus didn’t complete the file transfer.  This led me to have to follow the steps in the previous post to recover.  I think i will now just make a copy of my relevant config files and download the latest stargate release from [http://platformx.sourceforge.net/], since it now has ipkg (like dpkg, but slimmer) installed by default.

Backups are good.

I believe I convered earlier on how to get yourself a copy of the image on the stargate onto your linux hard drive. Now mounting it is a different matter. It is a little more complicated than I thought it should be, as it isn’t possible to mount the jffs2 image with loopback as I would normally do with an iso image or a hd image (mount -t fstype -o loop /path/to/image /mnt/point). This webpage [https://notfaq.wordpress.com/2006/07/20/mounting-a-jffs2-image/] proved rather useful.

The stargate appears to be 31488 Kbytes, and you can replace insmod with modprobe or modprobe -v if you want verbosity.

If you have a tftp server (or don’t mind setting one up) then [http://platformx.sourceforge.net/Documents/build/TFTPHowTo.txt] will be useful. However, if you don’t want to (and have the time to wait for a serial transfer) just type “set loadmethod serial” in the boot loader of the stargate. Then to load the image onto the stargate, just type load “partition name”. Then, if you are using minicom, just do ^A S and navigate to the correct image. It will take a great deal of time to do this via serial.

Update: Problem fixed.  I asked on the AmesFUG [http://amesfug.org/] mailing list and Tom Pohl resonded with the answer to add my ip into the hosts file (/etc/hosts).  The problem appeared to be that the stargate was looking for dns resolutions.
I am having some problems with the Stargate and the speed of the initial ssh login.

A Stargate is a tiny embedded arm machine running a extremely slimmed down version of debian (minus the packagemanager, etc) with a pcmcia slot, usb, ethernet, and cf card slot, and a specially designed 51 pin connecctor.
[http://www.xbow.com/Products/XScale.htm]

More background information

# cat /proc/version
Linux version 2.4.19-rmk7-pxa2-star (eepp@clyde) (gcc version 3.3.2) #1 Fri Aug 13 12:58:00 PDT 2004
STARGATE Version 7.2

I have the stargate set to automatically start in adhoc mode via /etc/pcmcia/wireless.opts
#AmbiCom Wireless Card….
*,*,*,*)
INFO=”Netgear”
ESSID=”sense”
Mode=”Ad-hoc”
Channel=”3″
Rate=”11M”
# KEY=”1234-1234-12 open”
;;

Is the first and only network.

I have commented out the pump -i eth0 lines in /etc/init.d/networking so that the wired devices does not come up on boot and waste time trying to bring up something that isn’t there.

Contents of /etc/network/interfaces
# /etc/network/interfaces — configuration file for ifup(8), ifdown(8)

# The loopback interface
# automatically added when upgrading
auto lo
iface lo inet loopback

# auto eth0 — don’t automatically bring this up
#iface eth0 inet dhcp

openSSH version
SSH Version OpenSSH_2.2.0p1, protocol versions 1.5/2.0.
Compiled with SSL (0×0090581f).

I have public key authentication set up (DSA) and that works.

I did the timing with the following command
time ssh -t root@stargate “echo”
(stargate is defined in my /etc/hosts file)

The actual problem

Whenever I boot up the Stargate I can connect via ssh over the wireless network as soon as I can see it. However, it takes between 20 and 25 seconds to actually connect and get a login prompt. However, when there is a wired ethernet device connected and I run
ifconfig eth0 up;pump -i eth0
I can then connect in under 4 seconds via either interface. Unplugging the network device again results in 20-25 second login times.

The code in cvs for xlisten does not seem to compile to anything close to that which has been distributed on the CD. I am confused. Even the Stock one does not seem to get parsed in the same way. The raw mode from the pre compiled one shows different data than the raw mode of the one compiled from cvs. I whasill have to investigate this more and find out why the cvs one doesn’t appear to work correctly. Doing any modifications for different AM Types seems a little harder now, since the original doesn’t work in the same way. It may be more convenient to use something else if xlisten turns out to be more difficult to modify/correct than originally thought. I will checkout the cvs of tinyos-2.x and see if there is a contrib there that works, I’m doubtful.

Update: The xlisten from beta doesn’t even compile.  There is no xlisten in tinyos-2.x.

This is a general overview, with some specifics.

Surge like code on the motes.
SurgeBase on the mote attached to the Stargate. The Stargate currently has version 7.2
–
Linux version 2.4.19-rmk7-pxa2-star (eepp@clyde) (gcc version 3.3.2) #1 Fri Aug 13 12:58:00 PDT 2004
STARGATE Version 7.2
–
Upgrading to 7.3 would be perhaps advantageous, it would be much simpler to add software, as the 7.3 build from
platformx.sf.net
has support for the ipkg system (the same system that would be used on the compaq’s).

The Stargate will listen with a modified version of xlisten that will put the data into a postgresql database. This database can be dumped, and transferred to a faster machine to do the processing of the data, or it can be viewed on the actual machine (with a little change to a config file) via a tcp port. What is stored in the database can be configured. Currently I am thinking about storing everything, the raw data packet, and the parsed data.

For sending commands to the network, the application Xcmd from xbow will be used. This was modified slightly in order to send all the packet types that we are using.

We will have to create a program to access the database (or some data file) and find the currentpath to the specific mote in order to send commands to that specific mote. This program will be essentially the glue that holds everything together. It will probably be a daemon of sorts, accessible on a port, and having a simple set of commands, which will be easily extendable.
It could be a web application as putting apache on the machine would not be that difficult. The advantage of the web application would be that no applications would have to be installed on the machine trying to access the data from the sensor network. Of course, this would make the stargate the machine doing all the calculations, which are mostly minimal, but with the Stargate running on batteries this could be an issue. This web frontend would probably be easiest for communication purposes, choosing from the options, then the machine would send the command via xcmd. Visualization and analysis of the data would probably be far more convenient on a different box of course. Output to csv may be more useful than a database file for many applications. This could be done through a web interface as well of course. Advantage of a web based application is that any client can access it provided it has a 802.11b card and a web browser. Disadvantage is of course the limitations of a web app.

Minimum requirements of the Application

Be able to display the current data in some manner. Likely graphs of some sort, or maybe just a giant table. With options on how many rows to show or something.
Be able to send a command to a specific Mote, likely selecting from drop down lists of all the currently connected elements.

Problems at this time:

USB

Usb mounting on boot seems to be an issue with the 2.4 kernel, the usb-storage driver is compiled as a driver, and thus will have to be loaded (via insmod or modprobe) before and usb-storage devices can be used…The problem comes as /dev/sda1 (the usb device) isn’t recognized fast enough.
This is written to a file when I have it try to mount in a bootup script.
mount: special device /dev/sda1 does not exist

There are also problems when there are usb devices plugged into the Stargate with `shutdown -r now` not working as it should. The machine has to be rebooted by hand, the command doesn’t terminate the usb devices properly unfortunately.

Possible solutions,: get a different kernel, add cron (to make it check to see if the device is mounted, and if it is not try to mount it), or get a cf card, which should mount on boot from what I have read.

Current Solution:
added
# Needed because usb isn’t found fast enough to mount
sleep 15
mount -t ext2 /dev/sda1 /mnt/cf1

to both /etc/init.d/cfcardapps and /sbin/setup.sh
Adding only one call to mount didn’t work for some odd reason, and having them both in one file didn’t work either, quite annoying.
This will of course sleep for 30 extra seconds on boot no matter what, not the most ideal of solutions.

/etc/init.d/rcS calls /sbin/setup.sh which calls `/etc/init.d/cfcardapps start` to start the postgresql apps (and whatever else we want to start on the card).

Lack of “glue” application

It has yet to be written, or even what type, c, web, java, socket, etc.

I have been working with xlisten (aka xserve) for the Stargate to interact with the motes.

The reason I have been looking at this is to make it so that we can have custom packets sent nicely to the postgresql database with minimal hassle. The best way for one to figure out what they need to do is of course stsart reading the xlisten.c source file (in the contrib/xbow/tools/src/xlisten folder of your tinyos-1.x install (if you came from CVS)) at the main part of the file. This is after you’ve mad sure that you can compile the code. I was able to compile it only for the arm (make xlisten-arm), but I did not try very hard to get a non arm version to compile. The process would involve getting the source for postgresql (same version for “best” results), but that doesn’t sound too bad…

This will lead you to amtypes and boards eventually, which will lead you to believe that you just have to create a copy of say surge.c and rename it and start modifying it to your specifications. You need to make sure that the AMTYPE_WHAT_YOU_WANT = 0x##; for your new packet type in xsensors.h in the typedef enum { … } XbowGeneralPacketType; (or similar)
Then you need to make sure that you have the whatever_initialize() called, as well as including the necessary source file(s).

If you look at amtypes/surge.c you will see a line like XPacketHandler surge_packet_handler; That makes it quite easy to add multiple other packet handlers.

This is just enough to get others started in the right direction.

I’ll add more later, and perhaps even some detailed steps on how to add a new Packet Handler (or AM Type) to the Stargate xlisten-arm/xserve-arm application.