summaryrefslogtreecommitdiff
path: root/CanNodeFirmwareGps.mdwn
blob: 852e069bcf51a8d4cbd4ce5884a21b662230c904 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
## <a name="LV2 GPS CAN Node Firmware"></a> LV2 GPS CAN Node Firmware

This node interfaces a Rockwell AKA Conexant now AKA SiRF "Jupiter" GPS Board (firmware v2.30) to the LV2 CAN bus. The current board is a PIC16F877+SJA1000 PCB modified to use a PIC18F458.

----

**Jupiter GPS Messages We care about:**

1000 -- Geodetic Position Status Output<br /> 1003 -- Visible Satellites<br /> 1009 -- ECEF Position Status Output<br />

These three messages contain the position date from the Jupiter board - position output in ECEF (preferred) and lat/lon/alt coordinates. We don't really need the lat/lon/alt data since they can be converted directly from the ECEF data, but they are essentially free from the GPS and thus there's no reason to make the FC or the ATV node (which needs to display lat/lon/alt on the ATV overlay) redo the calculation.

1102 -- Measurement Time mark Message (Measurement Engine Raw Data)

Here's the real information. We currently have no idea what it means, but we'll grab it and store it for future post-processing (i.e., DGPS post-processing). In the future, the FC will be munching on this data itself doing GPS measurements.

----

**Jupiter EEPROM Settings:**

Here's the list of bits we set on the Jupiter board using LABMON:

- Message 1212: Elevation Mask Angle??
- Message 1214: Disable DGPS
- Message 1217: Solution Validity Criteria: Alititude NOT used = 1, DGPS required = 0, minimum # sats = 4, max EHPE = ? max EVPE = ?
- Message 1218: Antenna type = 1 (ACTIVE?)
- Message 1220: Platform = air
- Message 1221: Hel Altitude, Ground Track somoothing, position pinning = 0 (DISABLED - IS THIS THE CORRECT INTERPRETATION?) -- what about measurement filtering?
- Message 1330 (Serial port communication parameters): Port 1 data = 1, port 2 data = 0, P1 character width = 1, P1 stop bits = 1, P1 parity = 0, P1 bps = 7 (19.2kbps)
- Message 1331: Protocol type = 0 (binary)... RELATION TO GPIO PIN?

----

**Current Firmware Features:**

1. Only sends CAN messages if the GPS message checksums (header and data) are ok (example: bit errors on the serial line).
2. Doesn't miss a GPS message if the previous GPS message is incomplete - in other words, it's continuously looking for headers (example: GPS board reset due to brown outs).

**Future Firmware Features (in no particular order):**

1. Do a BIT on the GPS board and interpret the results.
2. Make sure all of the EEPROM settings on the Jupiter board are correct.
3. GPS operating properly alogrithm: Check for screwups (dropped messages, timing of messages, etc.) and report to the FC.

----

**Questions to pose to SiRF:**

- EHPE, EHVPE - what's the computation? relation to DOP?
- dB-Hz?
- C/No?
- Many questions in the input messages.
- Millions of questions in Message 1102.
- Ok, WHICH MESSAGES ACTUALL EXIST?!?!?! 03/08/2000 spec? or 2/1999?

----

**Attachments:**

- [[Schematic|gps_can_node_schematic.pdf]] (generated in EAGLE).
- [[Firmware from the "SolarBoy" Solar bike project|solarbike_firmware_11-07-2001.zip]] which used the same PCB but with a 16F877 and without a SJA1000 to serve as the telemetry controller for a solar bicycle. The C code should be a starting place to understand how to parse the messages coming from the GPS.
- GPS CAN node [[main.c]] as of Tues 17 Nov '02. Parsing of Zodiac messages 1000, 1003, &amp; 1009 is implemented. Code compiles, but MPLAB does not successfully build the entire project ("MPLAB is unable to find output file 'LV2CORE.HEX'."). Stay twoned...

----
Attachments:

- [[gps091802_b.zip]]
- [[gps_09-18-2002.zip]]