Upgrade Ubiquiti RouterStation OpenWRT firmware

This post is a shorter version of the one found in the openwrt mailing lists.

First steps:
1. Unplug your RouterStation (POE cable) and remove wlan cards
2. Set your computers IP to be in the same network as routerstation 192.168.1.* (Don't use the routerstation 192.168.1.20 IP)
3. Set your computer to ping the ip 192.168.1.20 continously (M$ Win cmd "ping -t 192.168.1.20") to see that the RS is there.
4. Press and hold the RS reset button. (RS powered off at this point)
5. Connect the POE cable.
6. Wait for the rf light to show up. Your RS is now in failsafe mode, waiting for tftp-connection.
7. Use tftpd32 or some other tftp software to upload the new firmware to your RS's IP (192.168.1.20). In this software, it's the tftp Client tab. Enter IP (192.168.1.20) and select the new firmware, and press put.
8. Wait, wait, wait.
9. Eventually it should reboot.

New firmwares can be found from Ubiquiti Forum for RouterStation. Beware, the UPGRADE version will overwrite Redboot bootloader also.


Ps. Having a serial adapter and a cable to monitor the RouterStation is a very good idea during this process.

My output from the RS serial console during the flashing process:

TFTPD: waiting for connection...
TFTPD: waiting for connection...
TFTPD: waiting for connection...
TFTPD: Incoming connection from 192.168.1.66:50758
Received: 6215536 bytes
Firmware Version: RSx.ar7100.OpenWrt.r15349
Initializing default partitions for 16M flash size.
Created 'kernel' - base: 0xBF030000, mem base; 0x80060000, entry: 0x80060000, size: 0x000E0000
Created 'rootfs' - base: 0xBF110000, mem base; 0xBF170000, entry: 0x00000000, size: 0x00560000
Created 'cfg' - base: 0xBFFD0000, mem base; 0xBFFD0000, entry: 0x00000000, size: 0x00020000
Created 'data' - base: 0xBFBD0000, mem base; 0xBFBD0000, entry: 0x00000000, size: 0x00400000

Updating FIS directory!
... Erase from 0xbfff0000-0xc0000000: .
... Program from 0x83ff0000-0x84000000 at 0xbfff0000: .

Flashing partition 'RedBoot' (size: 0x00030000, actual data: 0x00030000)
... Erase from 0xbf000000-0xbf030000: ...
... Program from 0x8006cd44-0x8009cd44 at 0xbf000000: ...

Flashing partition 'kernel' (size: 0x000E0000, actual data: 0x000E0000)
... Erase from 0xbf030000-0xbf110000: ..............
... Program from 0x8009a31c-0x8017a31c at 0xbf030000: ..............

Flashing partition 'rootfs' (size: 0x00560000, actual data: 0x004E0000)
... Erase from 0xbf110000-0xbf670000: ......................................................................................
... Program from 0x8017a35c-0x8065a35c at 0xbf110000: ..............................................................................
... Resetting.+

Generic $2.5 USB to Serial adapter for Vista and Linux

I decided to check out those cheap USB to Serial adapters sold on eBay. And even though the description says they are only Windows 98/2000/XP compatible, it worked in my Ubuntu 8.10 out of the box and after a driver install also in Vista 32-bit.

The Chipset in the cable is: Profilic PL2303

Drivers for 64-bit Vista / Windows 7 here.

Lets hope it also works in OpenWRT without compiling kernel modules... I think I'll buy a bunch of these to strip out the serial connector and integrate them in various projects. Needless to say - I like the price point :)

The item was this. And the seller store can be found here.

Why should Model Aircraft be unstable? Meet the moment of inertia

Physics is not my strongest subject, but while playing around with a pencil in my hand, I started wondering what's wrong with the following picture of a traditional setup of an RC plane:


While this might be a good setup for a fast manually controlled "trick planes", the end result of concentrating all the weight on the center of the plane makes it more "unstable". Simply put if most of the mass of an object is located in it's center of gravity, it's easier to rotate than an object with weight concentrated on the outside edges. So especially for UAV and training models, I'd recommend a setup, where for example the batteries would be located at the wingtips rather than at the center:


This setup should allow for a more stable flight and make it easier to do automatic stabilisation. It also has the added bonus of not having to make wings as strong, as the lighter central body of an aircraft won't bend wings so much - there's a reason why big real aircraft have fuel tanks on the wings. This setup might be hard to modify on an existing model, but when designing a flying wing UAV - this is a must.

The article on Moment of Inertia in Wikipedia explains the physics behind rotating similar objects with different weight distributions. To get an easier example I recommend this site.

The plane images are originally from an article on Wikipedia, so use them if you want. And as always, if I'm wrong on this one - please correct me :)

Timing of Arduino communication with GPS on the same serial line

The problem with using one serial port for two devices (see previsous post), is timing.

My Holux GPSlim 240 sends data every second, and satellite info every 5 seconds. I estimate that maximum number of charaters received is about 500, so it takes only 500ch/(38400bps /8bit/ch) ~ 0.1 sec to receive the whole GPS "datapack". That leaves 0.9 secods for arduino communication. Just to be on the safe side, I think 0.2 secods for gps-data should be reserved. The good thing is that sending data to arduino can happen at any time.

Here's my plan for the flow control from arduino:

1. OpenWrt: Wait for GPS data receive to end
2. OpwnWrt: Send "Ready to receive" notification to Arduino
3. Arduino can reply for 0.7 seconds. (Sensor telemetry data etc.)
4. Arduino goes to "no send mode", and only receives serial data.
5. There's a 0.1-0.2s gap between the last Arduino data and the next GPS data.

Naturally I'll implement a checksum for data coming from arduino just to be safe.

Arduino serial + GPS data on single OpenWrt serial port

I want to process the GPS data on OpenWrt, and still communicate with the arduino port even though I have only one serial port on my test platform (Fonera).

I've connected both Adruino rx/tx and GPS tx pins to the serial pins of the Fonera box, but I'm using two diodes in both tx lines to isolate problems. Now I can receive NMEA data from GPS, but also sensor data from Arduino. I can also send commands to the arduino.

Illustration:

GPS  tx   ->diode->   rx  FON  rx  <-diode<-  tx  Arduino 
GPS gnd   -------->   gnd FON gnd  <--------  gnd Arduino
                          FON  tx  -------->  rx  Arduino

stty settings on Fonera:

# ttyS0 38400 bps, 8 data bits, no parity, no hardware HS, no echo
./stty -F /dev/ttyS0 raw cs8 -parenb -crtscts -echo speed 38400

I also commented the /dev/ttyS0 line from /etc/inittab to disable the automatic Serial console of OpenWrt

Change serial port speed on OpenWrt Kamikaze 8.09 with stty

The forums were full of descriptions how to change the console speed, but the basic busybox-package on kamikaze doesn't have the stty program. It can be found on the coreutils-package, but some platforms don't have enought space to install the whole package.

So here's the download link to the stty-program for Kamikaze 8.09 on mips/atheros/fonera platform. Hopefully it helps someone.

Ps. The reason why the default 9600bps didn't work for me, is that I wanted to test my Holux GPSlim 240 bluetooth GPS dongle through the serial port. Even though this GPS has only a usb-port for charging, it's actually not usb at all. It's aserial line working in 38400bps. Works with arduino also. Pinout can be found from the manual.

Ubiquiti Networks Routerstation based OpenWrt UAV

I've had an arduino board and cheap ebay three axis accelerometers + GPS + compass sensors for a while, but I think that using just arduino is a bit limiting and good serial modems for telemetryare quite expensive.

I want something more scalable, and therefore have been thinking about the Routerstation platform. It's only about 50-60€ + postage, and it features 680Mhz MIPS 24K CPU, 64MB RAM, and 16MB Flash and most importantly Srrial and USB 2.0. Atheros mini-pci wlan-boards can be used for connectivity and are dirt cheap on ebay.

So if you have USB, you have basically everything to play around with. UMTS modems, webcams, USB-serial ports, gphoto2 usb interface to your digital camera etc.

Please share your thoughts and give other suggestions on embedded linux platforms.