TRAM has always used the concept of a PIC processor on board the trolley transmitting data over a RF modem to a data system at a fixed location -- usually near the middle of the track.  This is essentially the 1990 vision...

PIC

The first PIC version used the TAOS board with two PIC processors.  One handled the PTU module (?) and the other collected data and sent it over a radio module.  I  later built my own board dedicated to the specific sensors that TRAM used.  After lots of mods as TRAM evolved, I created a second board in 2008 with 8 independent UARTS that could handle a variety of sensors (3.3, 5, and 12V power, RS-232 or TTL output).  I believe that all of these version have used the PIC18F252.  (Ned Chamberlin picked a useful CPU for TAOS!)  I soon found that the radios I had selected were not the best choice.  I also have had to add more strange modifications:

• A power daughter board (12V -> 3.3V) on the power board to supply the high current needed by the Novatel GPS
• A custom solid-state relay board on the power board since stock relays had limited life and failed in the "on" position.
• A daughter board just with a TTL logic gate to supply the drive current needed for the power relay
• A second PIC (PIC24F32K) as a front-end to the IMU to reduce the baud rate from 115.2 to 19.2Kbaud (since the PIC couldn't keep up and dropped characters at 115.2).  Needed to use the PIC24 to get two independent UARTs (and needed 2 UARTs since baud rates are different).  Since this circuit is on a proto board, I haven't drawn it up electronically.  The pin connections are in the table below. [21 Mar 2014: Changed also to format data to hex and only transmit message ID FF.]
  
  Note that I have added a header to this board for connections and a second header just to secure the board mechanically.
• Removed all on-board radios and simply wire to an XBee daughter board.  Have also used a Bluetooth module connected this way for lab testing.

Radios

TRAM started using WIT2410 2.4GHz point-to-point radios.  Later I tried HAC-UEM 433 MHz radios, thinking that the lower frequency would better transmit through trees. Not only didn't it work very well, it also turned out to be an illegal frequency in the US.  I later tried XBee radios both at 915MHz (XBP09-DMSIT-156) and 2.4GHz (XBP24-DMSIT-250) and haven't noticed a significant difference.  I'm now using a pair of XBP09's for the trolley and have another pair of XBP24's if needed (was using with for the power supply before direct-connecting it).

Settings for the XbeePro Radios:

All: (to enter command mode, send "+++", wait for "OK", times out of command mode after 10(?) seconds)

  ATBD 7 (115k; ATBD 3 for 9600)

  ATRO 0 (send each character; default is 3 for packetizing)

  ATPL 4 (max power in field; ATPL 0 in lab; Doesn't work for XBP09s?)

  ATWR (save settings)

  ATDH, ATDL as appropriate:

Software

The PIC code mostly just polls each serial port for characters.  As it gets characters, it fills a separate buffer for each port.  If a termination character is found, it copies the entire message to an output queue and prepends the port number.  Before polling every port, it also checks if the user has entered a command (listed below).  A 10Hz interrupt is used to grab the speed counter and set up A/D sampling.  After each serial port scan, these values (if available) also are copied to the output queue.  An interrupt on the radio transmit UART flushes the output queue.

I've tried to make this code reasonably efficient, for example by making a table-driven binary-to-hex converter.

With this flow, all channel processing must be accomplished before the input UART 4-byte FIFO is filled.  I found that the IMU at 115.2kbaud was too fast for the PIC to keep up, so I added a second PIC to read its data at 115.2kbaud and echo it back out at 19.2kbaud.  Another oddity of the IMU is that it is in binary and sends several types of record (with variable message lengths).  Special code runs, now in the second PIC, to create hex characters of these data so that they may be parsed like the other TRAM sensors.  I was able to get the PICs to talk using SPI (see "nidas8.c" and "cristafe4"), but this didn't improve data transfer and made the code clumsier.  Also, I should note that the message types are included in the hex translation and have been added to the .xml to parse each of these records.  C code for this front-end PIC is attached. Note that this version has error checking commented out, since it appears to introduce even more errors into the data stream (rejecting entire packets if one byte has an error).

Update (8/2015): Changed to VN100 IMU from Crista, since the VN has a more flexible output (sample rate and baud rate).  Can't run both together, so have removed the "IMU" PIC and wired the Crista directly into its own Xbee radio that goes into another GuruPlug input.

Flow chart:

Main:

Initialize

Infinite loop

Execute command, if present

Loop over serial ports

If new character, add to buffer

If character is end-of-line, prepare to send by adding wrapper and appending to output buffer

If speed counter value available

Adjust speed contoller duty cycle

Prepare to send counter value

Prepare to send duty cycle value

If A/D reading available

Set up for next A/D conversion

Prepare to send last A/D reading

Interrupt service routine (avoids calling subroutines within this ISR to save time):

2ms timer:

Loop over serial ports

If byte available, stuff into buffer

if 100ms has passed

Grab speed counter value

Send one character of VN prompt for P&T values

Prepare first A/D conversion

Transmitter:

If output buffer has character, send next character

DSM

I can't remember the first version of the TRAM data system -- probably simple logging on a laptop using minicom.  For NIWOT07/09, I used a laptop running pre-NIDAS software to collect trolley data in the same manner as ASTER data.  For BAO12, I ran NIDAS on a laptop.  I now have a GuruPlug running NIDAS that is even easier to start up.  My current .xml configuration is attached.  Note that data come in through only two serial ports (connected to a USB adaptor).  One serial port is connected to the radio receiving trolley data.   Data from the different sensors on the trolley are identified with a 1:, 2:, 3:, etc. prefix, indicating which PIC board serial port the data came from.  Some special data sources on the PIC have other prefixes.  These are listed below.  The other DSM serial port is direct connected to the Lambda power supply.

My intent for multiple trolleys is either to multiple pairs of radios, or to use incorporate a trolley ID in the Prefix above, e.g. 1A:xxx, 37:xxx.  I'd need something similar with the commands: 1G, 2S, etc.

A third USB serial port also is used for a fixed GPS receiver (one of the old ASTER Garmin GPS35s) used as the time source for chrony to set the GuruPlug clock.  This is not ideal, since USB data polling limits the PPS accuracy to about 100us.  At some point, I'll try using the GuruPlug's built-in UART port for the GPS, but will have to figure out how to get the PPS signal from a DIO line.  In this case, I'll go back to the old Lassen GPS (which supplies 3.3V-level signals, is smaller, and can be powered directly from the GuruPlug).

Useful links:

My GuruPlug documentation on EOL's Software Engineering Wiki.

chrony documentation (especially 3.2.3, configuration parameters)

gpsd how-to