RTC on the PXA270

In order to get DTN working properly in the future we need to have RTC setup and working on the gumstix. Jeremy and I at first thought that we could simply attach a backup battery to the V_BACKUP pin on the power control chip. We tried that and had 3V coming out on the V_RTC pin, but still the RTC would reset on every power down/restart. Then we thought it may be in software, so I looked through the driver code and commented out the line that resets the clock if the status register is misbehaving. The resets still persisted. Finally, I found out that on the PXA270 the RTC is on the chip and in order to keep the oscillator running we'd need to power the whole chip (at least keep it in deep sleep mode) and keep RAM alive. We decided to order an external RTC board, which is a DS1307 board which has I2C interface. Gumstix already has the patches for these boards and it should be pretty easy to get them setup once they come in and just set the PXA RTC to the external RTC.

Also, I've started to look at the CLA code for DTN2 and I'm still trying to figure out whether DTN sends out the bundles or if the CL has to do that. I should be able to understand that pretty soon. Ideally, I'll be able to simply notify DTN2 of link changes and have it handle message delivery. All the discovery can already be done by OLSR anyway.

more dtn on gumstix

I found that for some reason berkeleydb refuses to use pthreads installed on the gumstix. I've tried building the db with test and set by supplying "ARM/gcc-assembly". Also, I had to add -fPIC to CFLAGS to get it dtnd to load it on the verdex board. Lastly, it appears that the dtn build compiles in absolute paths, which has its issues since now it looks for the tcl in /home/timur/.... I ended up adding a symlink to the build. I will add more here once I make more progress.

Ok, Berkeley DB seems to be running with test-and-set, but now dtn crashes at the assertion: ASSERTION FAILED ((u_int)now.tv_sec >= TIMEVAL_CONVERSION) at bundling/BundleTimestamp.cc:39. I tried adding printf in there to see the value of now.tv_sec and I tried printing it to a file, but neither way produced any output (I did replace the dtnd file after recompiling). I'm not sure what the issue is and how to go about resolving it. I will look into this more tomorrow. I'm hoping Brian will know something about this, but not keeping my hopes up. If I can figure out why nothing is printed it'd be a big step in troubleshooting.

EDIT: Ok, the problem is not with the code or the assertion. DTN checks if the time is past midnight UTC December 31st, 1999 is (probably to make sure packet dates can be used correctly). The gumstix were set to midnight December 31st, 1969, thus the assertion was failing. I have DTN now running on the gumstix.

dtn and hostap

I built DTN for verdex with reasonable success and no big issues. For connex, using revision 1360 proved to be difficult so I tried a different one. Right now I'm trying to build revision 1340 with the packages required by dtn. One thing I have to fix is the path for berkeley db (which was also an issue with verdex). I think this will be done by tomorrow and then I can test it out.

On another note, with hostap it appears that ap_scan is very useful, as we can check ssids without invoking scan directly but instead examine the file in proc. This can be great in the future when we want passive scans to happen and simply check whether a new access point is available. I don't know if the linux-wlan driver supports this, but would be neat.

Justin has the communication setup and we looked into powering devices up/down. Looks like we can do it with wireless pretty easily by pccardctl and eject/insert commands. We're going to do more power measurements to verify that the card does indeed consume less power in that mode. I could not find a gpio pin to toggle to turn it off. Hopefully this will be sufficient.

building dtn

Dave's guide for DTN has been quite useful. A lot of the patches actually already appear in the later revision of the gumstix though. I had to add -ltcl8.4 to the LIBS in Rules.make in oasys to get liboasys to compile, thus getting dtn to compile. Everything else seems to compile fine.

DTN2

Since AP and OLSR appear to be running as expected, I was looking into how to setup store and forward. It appears that the route to take is to try to setup DTN2. After reading RFC4838, I realized that DTN runs on top of the transport layer, which means that OLSR can still do the routing and a DTN daemon on top can handle broken/disconnected links and store the data if a link is not available. I found a few explanations as to how to set it up and I will try to have DTN setup today.

dhcpd and dyn_gw

I have setup DHCPd on the verdex board and it appears I can communicate with the board fine. I have one more test to see if I can setup a simple two hop network and check if I can see the dhcp clients on a different subnet, which are not running OLSR. Hopefully, it will work fine. For dynamic gateway operation I used the dyn_gw_plain plugin, which seems to work fine. We have to toggle the interface manually, i.e. bring it up and down, but it detects such changes. The script to scan for access points and verify connectivity seems to be working fine now as well.

Ad-Hoc

Ok, Ming pointed out that running nodes in Ad-Hoc mode will make a lot more sense, since OLSR will take care of loops and can use signal strength to find the best route to a node. The script to scan for access points and associate with them was almost finished, but then I found linux-wlan-ng support wireless extensions if "options p80211 wlan_wext_write=1" is added to modprobe.conf. I will modify the script today and see if it works correctly. The next step is to get the dynamic gateway plugin to work. Last time I tried to use it, it segfaulted, but I have not looked into why too much. Worst case scenario I think I can put together a hack to do the same thing.

OLSR power consumption on gumstix

We set up a small circuit (thank you Matt) to measure the power consumption of the verdex board while running OLSR. We put a small, .5 Ohm resistor in series between the DC voltage generator and the board and measured the voltage drop. From my calculations the power consumed by the board at different stages is as follows:

	Voltage	Current	Power
Compact flash in	0.04	0.08	0.42
Connected USB	0.05	0.09	0.46
Loaded the PCMCIA driver	0.04	0.08	0.39
Loaded the USB driver	0.04	0.08	0.39
Started AP	0.06	0.13	0.64
Associated with an AP. Started OLSRd	0.09	0.17	0.86

Thus, our consumption with OLSR running is roughly .9W, which is not terrible and I will talk to Jeremy about getting solar panels to support this. We still need to duty cycle and have a way to scan for APs and to set the association and links appropriately. I will start writing the script today and I'm meeting with Deepak, Jeremy, and Devesh to figure out how this will be packaged.

more olsrd news

Well, it definitely works now! I'm browsing the web through the two gumstix OLSR nodes I set up. I still think that the D-Link card was flaky and right now I'm using the Linksys WCF-11 Card. For the 2.6.18 kernel a small patch has to be added to linux/drivers/net/wireless/hostap/hostap_cs.c. Essentially, add PCMCIA_DEVICE_MANF_CARD(0x0274, 0x3301) to static struct pcmcia_device_id hostap_cs_ids[]. I created a patch to do it for that particular kernel if anyone's interested, but like I said, it's very easy.

Now, I have multiple topics to choose from for possible directions:
1. I could start writing the "brain" script in something like perl or as a shell script
2. I could start working on duty cycling with tiny nodes

I think I'm gonna get some hot chocolate first to celebrate and then talk with Deepak about the direction.

Last thing, to reduce packet loss I used the firmware TX rate control. You can set it with iwpriv iface txratectrl 1 (0 is to use driver's tx control). You can also find more information about the driver online: http://hostap.epitest.fi/cgi-bin/viewcvs.cgi/hostap/Attic/README.prism2?rev=HEAD

let there be mesh

Finally got mesh networking to work, if only for a short while. The configuration I setup was as follows: node A was a verdex board with a netstix and a usb hub connected to it. I put in a D-Link CF card and a D-Link usb card. Node B was a connex board with a CF Linksys card and connected to a router with internet access through ethernet. The last piece in the setup was my laptop which connected to node A. Both of the CF cards acted as access points, with different ESSIDs. The usb card acted as a client connecting node A to B. I ran OLSR on both of the nodes and successfully telnetted to 128.119.101.5 (umass page) and retrieved index.html, which apparently did not exist, so I retrieved a 404 message :). The connecting was done of my laptop. To configure the routes OLSR took maybe 2-3 seconds. I had to specify the AP as a default gateway for all traffic on the laptop, but that seems a natural step either way. The subnet configuration was as follows: Laptop and node A AP were on 192.168.1.0/24, node A to node B on 192.168.2.0/24, and node B to the router on 192.168.4.0/24. The router ran a dhcp server. The rest of IPs were configured manually but a DHCP server could be setup with each access point.

This setup worked until I called Deepak to check it out, of course that's when it stopped working. The moment I would try to reach the D-Link access point, I would be disassociated from the AP. I will go back and try to figure it out tomorrow. Overall though, OLSR was very easy to set up, and we should've used it to begin with.

OLSRd part 2

Setting up OLSR turned out to be much easier than click/roofnet. The configuration file is very straightforward and it seems we can handle broadcasting internet access easily by using simple shell scripts (much like the brain script). The current configuration for the verdex works rather well: netstix with wireless for hostap and a usb hub with a dlink card to be used with wlan-ng to connect to other access points. I'm hoping to test OLSRd tomorrow and get some power consumption measurements under various modes. Hopefully, we gain something this way.