Added reference documentation

References/SS_SW_Notes/telemetry.txt

@@ -0,0 +1,133 @@
+
+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.
+