search

WaiveCar / WaiveTelem

Repository for files related to the waivetelem project
0 stars 0 forks source link

Lean out communication structure #58

Open jlandau10 opened 5 years ago

jlandau10 commented 5 years ago

Want to lean out the communication structure to make sure we don't needlessly send redundant data.

jlandau10 commented 5 years ago

Thinking only send full status by request. The start ride/end ride code can request a full status update at both events.

3 other types of updates:

Event - Update Payload Ignition State Change - Ignition Status Door Lock/Unlock/Open/Close - Door Status [Open Q: by individual door, or sum status] Immo/Unimmo - Immo Status Reboot - full status Impact Detected - Impact Detected Flag with timestamp

State Step - Delta/Qualifiers - Update Payload Fuel/Charge Level - 1% - Fuel/Charge Level GPS Position Change - ~20 meters(above noise threshold) && t_last_send > [90sec w/ignition >0, 10min w/ignition==0] - GPS Info, Speed (from selected or all sources), Odometer

ravelab commented 5 years ago

Here is what it correctly looks like: { "remoteLog": "4", "init": { "firmware": "1.2.3", "debug": 0, "configFreeMem": 239, "modem": "L0.0.00.00.05.08,A.02.04", "sd": 1, "eeprom": 1, "motion": -1, "cfg": 1 }, "heartbeat": { "lat": 34.149962, "long": -118.027841, "hdop": 820, "speed": 0, "heading": 0, "uptime": 933, "temp": -1, "signal": 24, "carrier": "AT&T Sierra Wireless" } }

(I have separated the init and heartbeat to make it easier to know what was sent when

Then there is the can bus updates that are dictated by delta

events: also have vin low alert, last command...