134 lines
5.7 KiB
Plaintext
134 lines
5.7 KiB
Plaintext
|
|
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.
|
|
|