Gaiss Project

The trial of GAISS occurred over the last bank holiday weekend (June) and was, overall, a success. A lot of work was put into setting up for the trial, as we had to set up APRS repeaters, set up a station to capture mountain rescue messages and retransmit them as APRS, and last minute work had to be carried out on the software to give it the capability to handle the variations in the different packet formats it would be receiving (previously unexpected formats, I might add). The conversion station for the map27 position reports involved our map27 radio, one of our rovers running the conversion software, an OpenTrackerII and radio operating on the amateur radio APRS frequency. This is shown in the first picture below along with an extra radio for keeping the operator for the day up to date with voice communications. The second picture is a shot of what the operator spent the day watching on the screen, checking all was valid.

Also, screenshots are shown below of SEMRA personnel (map27) and amateur radio walkers appearing on our prototype software.

Now that the MAP27 messages were being captured, interpreted and displayed on a console for people to see, the next step was to perform the conversion to APRS format and retransmit the packet on the APRS frequency (which is a frequency in the amateur radio band) so that our collation software back at base could pick it up and display it.

To do this, it was decided to have our MAP27 program take the information it receives and send it out (as a long text string) to an IPv6 multicast address, and have another program (on a seperate machine) which listened at the particular address and took in the string, made it an APRS packet and transmitted it out. The reason for spreading it out over two machines is that there is no rehashing of code required when a machine that must be used has only a single serial port, as might be the case in other uses after the trial. Two serials ports are required to keep the conversion on one PC (one for MAP27 input, one for APRS output).

Once the multicast send and receive was gotten operational, it was possible to use Linux’s native support for radio transmission (i.e. ax25) to transmit out the APRS packet. This was tested successfully last week, and the location of MAP27 radios was shown appearing on xastir. 

Based on our reference transcript, and the MAP27 documentation it was possible to figure out what the handshaking sequence of messages was between the radio and PC.  Armed with this knowledge, code was written that performed the handshaking, and then started into general communicaton with the attached radio.  The handshaking was an immediate success, but we ran into bother when we were trying to get the data, data acknowedgement sequence working, as we were falling out of sequence very soon into the program and then the link was being dropped by the radio.  This turned out to be caused by inaccurate use of our serial port library as opposed to invalid messges being sent.

After some rearranging of code, this problem was rectified and data was being received from the radio.  This meant the next step was to transmit valid GPS data from a mobile radio and see if could we decipher it and display it.  This transmission had to be done in the amateur radio band of frequencies as we have a licensed amateur radio operator but not a licensed marine band operator which is what mountain rescue use (hopefully, a situation to be rectified by the time of the June trial).

Deciphering the incoming GPS data was a task that involved manipulating the binary data with the intent of making the correct divisions to capture radio ID, latitude, longitude and time, and then displaying this in a human readable format.

By the end of last week, this was working as required and a program was running that captured MAP27 messages and displayed them, correctly formatted, on the screen.

The majority of recent work on GAISS has been centered around a protocol called MAP27.  This is the protocol used by mountain rescue radios to interface with terminal equipment.  A library exists for Windows machines to perform the interfacing between application software and the attached radio equipment.  However, all the GAISS machines (in particular, the rovers)  run Linux, so it was apparent that we would need Tto write our own code to perform the interfacing.  The easiest way to do this was to run a program which uses MAP27 on a windows machine and then listen on the serial port to find out what the raw messages were.

Once a transcript of the actual messages sent through the serial port was obtained, work was started on decoding these messages and finding out how we could emulate their behaviour in our own software. Thankfully, to aid us in this task, we had the MAP27 documentation. This is a massive document, but between that, the SRM9000-application note from TMC radio, and a lot of trial and error, we eventually deciphered what messages were available and how they were structured.

Being a properly defined protocol, the communications between the radio and pc had to be structured in the exact defined format, with error checking, message acknowledgement, and control messages/information all needing to be based. Therefore, the first item we set about getting working was generating checksum values and making sure our checksum matched the checksum contained in messages we heard being sent out the serial port. Thankfully, the code used to generate the specific CRC-16 checksum is given in the MAP27 documentation so it soon became a case of figuring out which parts of a packet are included and which are not. Another trawl through the documentation revealed the start sequence (SYN-DLE-STX) and DLE escape characters (to preserve data transparency) are not included and everything else is. We also learned (again, via trial and error, error, error) that there is no spaceholders added for the checksum values. The next task will be to get handshaking and comms working.

After some on-site testing, we have realised that we cannot make the WiFi connections we wanted between our various nodes. This is a setback as it would have simplified matters to have a radio listening at each node and then simply passing the information (time, GPS, etc) it hears from field units back to a base station via a TCP socket. However, a way around this is to use APRS as a means of passing the data back to the collation software at base. It is known for definite an APRS (i.e. radio) link can make the connection between the two points.  On the plus side, this requires the collation software to be able to handle one less message format at the time of the trial.  This is because any APRS packets that the mobile node hears will simply be forwarded on to the base (no change from the original plan) and any MAP 27 (i.e. mountain rescue protocol) packets will be converted to APRS, and then forwarded on.

Recent work that was done on the GAISS project was to implement a form of networking between the mobile nodes and a laptop that would be acting as a base station.  For this purpose, a mesh network running an implementation of OLSR was decided upon and implemented.  OLSR was ideally suited to our purposes as it allows for a certain amount of maneuverability of the nodes that are going to be involved in the network (the design of OLSR means that if a node loses its direct connection to another node it wants to communicate with, then it can hop through any neighbour it is still in range of and use them as a means of reaching the required destination. Multiple hops are possible.)

The planned interconnections and hardware to be used on the weekend of the trial is quite simple. At the centre of the planned layout is a WRAP board. This is a piece of configurable hardware with two wireless connections and one wired connection. The two rovers, the laptop acting as base and one of the wireless interfaces on the WRAP board will be connected via a mesh network. The other wireless connection will be used as an access point for whatever machines end up congregated around the base area. The wired connection will be the uplink for both the wireless networks.

Ubuntu 6.06 was picked as the OS of choice for our two gleaming ROVERs. As is inevitable (and inexplicable), install was a flawless success on ROVER2, but failed three or four times on the other ROVER1. However, a highly technical solution was implemented. I kept pressing retry until it installed. Brute force and ignorance = everybodys friend!!

 As these machines are going to be running from a battery, it’s obviously desirable to minimise the processes that will be running on them and after a quick google around, a little process by the name of sysv-rc-conf showed its name (available via apt-get )A handy utility that lists in columns all the processes running and all the run levels they are switched on for.  Damn useful if you wanted to keep the processes installed and just turn them off, presuming it interacts and edits the init scripts competently.  I never tried it though, as for my purpose, uninstall was a  better option and sysv-rc-conf was used as a handy reference list!

The first step is, obviously creating the actual nodes themselves.  Mini-itx motherboards were used and installing  them was kind of fun based on the sheer novelty of their size.  The boards were used in conjunction with DC-DC power supplies from Opus Solutions(as they will be running off car batteries).  It was these power supplies that proved to be a nightmare.  The power supply used was a model called 90W DC-DC, which is now obselete and just as well as I wouldn’t recommend that power supply, due solely to its extremely unhelpful manual (yes, i did actually read it). Days were given trying to implement the features on the power supply which allow it to turn on and off with the ignition. It would turn on when the ignition was turned, no hassle, but it would stay on when the ignition went off. Unimpressed!! The reason? The manual specified two particular pins on a block of pins to connect a wire to (for sending power signals, e.g. on, off). These pins didn’t work and by a matter of sheer luck it was discovered it was the adjacent two pins that should be connected. That was a promising start indeed. A picture or two of the neat and discreet mobile nodes will be added soon, I promise. Anyway, what harm, they are built now and have been christened Rover1 and Rover2. Next up, installing and customising Ubuntu on the mobile nodes. Should be straightforward…

The trial of GAISS in June will consist of two mobile nodes reporting back to a base location.  Each of these nodes will contain various items that will test specific aspects of the softwares capabilities.  This page will document progress as each item is added and maybe provide an opinion or two!!