Sunseeker Telemetry
Notes 1 
1/28/2010

The CAN bus will have many short messages on it, which the telemetry board
will listen to. It will select the information to format and transmit it
to the chase vehicle or store onto a USB data stick. This is a set of 
thoughts on collecting, formatting and storing such data.

The next week, initial decisions need to be made so that the students
working on the strategy program for the chase vehicle can program and
test it with their code.

-----------------------------------------------------------------------
Observations:
1) The USB driver for the data stick on the telemetry board is not
currently working. It requires a FAT formatted USB stick that is limited
to 2 or 4 GB (I do not recall which). This is outside the main scope
for the strategy programing team.

2) The radio link and its buffers are limited, so that the total data
transferred can not likely match all the CAN bus traffic. An estimate
of this volume should be made and testing shod be done.

3) The CAN bus controller on the telemetry board has a SPI interface
to the MCU that appears to prevent all CAN traffic to be transferred
to the MPU. This rate and the CAN controller's buffer should be considered,
to estimate what this limit is. You must / should expect to miss some
CAN packets, if they are on the bus too closely together. It may be necessary
to use the CAN mask to only wait for a specific needed packet type,
changing the mask as needed.

4) No assumption on the CAN packet spacing should be made by the telemetry
board.

5) Non-Tritium traffic on the CAN bus (such as traffic from the BPS to
the telemetry board) should be kept to a minimum, so it does not interfere
with the critical driver controller to motor controller traffic.Such
interference might be very random and hard to debug.

5) At some future point it is hoped that a 20 bit value for the
current in/out of the battery will be available. Perhaps this will be
integrated into the BPS.  Such a value is needed to reliably predict
the State of Charge for the Battery. Such a value might be sampled \
10 time a second. However it would only be necessary to transmit
a summary of this to the telemetry board, not every measurement.
Perhaps only every 60 seconds.

6) The same remarks on current BPS data apply. All the data the BPS master
might get does not have to be placed on the CAN bus.

7) The next telemetry board should have a hardware serial interface for
an on Sunseeker GPS. The current cards might allow an on board GPS (on the 
LED board?) then GPS packets could be put on the CAN bus to the telemetry
board.  Such traffic should be limited as above.

8) The chase vehicle program should receive two types of data. Data needed
for race driving strategy (speed, distance?, battery state, array output,
... ) and warning information (motor temp, controller temp, driver temp
BPS warnings). Some other information might be sent for logging,; however
most logging should be done on the data stick.

9) There will be a need to reconcile (time correlate) data logged on the
chase vehicle with data logged on the telemetry data stick.

10) Power use for all telemetry needs to be known: telemetry board, 
radio modem, GPS ...  as race rules may allow this to be done on a AUX
battery; although it may be more effective to use the cars 12V system
from the main battery.

11) What happens when data is not received? Does the modem
automatically retransmit?. When the modem's buffer is filled (sender or
receiver) what happens when more data arrives? How does this effect
the "messages" being sent?

12) The longer you make messages, the more likely they will not
be transmitted cleanly.

13) For modeling, having a high resolution low g accelerometer to
log to the data stick might also be fun. Not critical.

14) Another piece of data for modeling that might be useful would be 
measurements from a Pitot tube extending from the from of the car. 
again not critical.
-----------------------------------------------------------------------
 
Proposal:

Communications will be one way, from the telemetry board to the chase.
Thus no ACKs or retransmissions will occur under telemetry board
control; although the modem may be doing some of this at a lower level
Missed messages will simply be dropped.


The telemetry board will transmit messages of the form
	Start Bytes (2)
	Message size (one unsigned byte: 0-255)
	Message type (one unsigned byte: 0-255)
	Sequence Number (two bytes?) - useful but perhaps not critical.

	data bytes (0-255 bytes)

	check sum (2 bytes: 16 bit unsigned sum of all message bytes)
	Stop Bytes (2)

Any message that is not complete will be rejected.

Note: a more complicated checksum could be considered later.


-----------------------------------------------------------------------
Next step: 

Review this and then determine messages and message frequency.
Consider the logging to data stick as well, although outside
the main scope of the strategy team's responsibility.
Consider timestamps, which might best be part of data. Look at
the Tritium Motor CAN packets. In order of importance:

Motor and Motor controller State -- state, voltage, current, temps, speed
Battery State -- If put into BPS master code: voltage, current, high temp 
  and id, low temp and id, high voltage and id, low voltage and id.
Array State -- Does not look like this will be available, on an
  MPPT by MPPT basis. It could be roughly inferred in the chase vehicle for
  the whole whole array from the Motor controller (BUS voltage and currents
  in/out of the motor controller) and the BPS information (current in/out
  of the battery pack.), although time correlation is important here.
GPS information - if GPS added.

I'd also like a record of braking (although this will only be on/off),
this could be logged on the data stick.