Document UART as primary communication method
This commit is contained in:
+25
-40
@@ -2,18 +2,18 @@
|
||||
|
||||
## Overview
|
||||
|
||||
The first hardware version will use plain UART over CAT5 between the Pico dashboard and the ESP32 cargo controller.
|
||||
The first hardware version will use UART over CAT5 between the Pico dashboard and the ESP32 controller.
|
||||
|
||||
UART is simpler than RS-485 and should be reliable enough for the short cable run inside the Xterra.
|
||||
UART is simpler than RS-485 and should be reliable for the short cable run inside the Xterra.
|
||||
|
||||
RS-485 remains a fallback if UART proves unreliable.
|
||||
RS-485 remains a future fallback if testing reveals communication issues.
|
||||
|
||||
## Architecture
|
||||
|
||||
Pico Dashboard
|
||||
↓
|
||||
UART over CAT5
|
||||
↓
|
||||
|
|
||||
| UART over CAT5
|
||||
|
|
||||
ESP32 Controller
|
||||
|
||||
Backup:
|
||||
@@ -26,60 +26,45 @@ RS-485 over CAT5
|
||||
|
||||
Pico TX -> ESP32 RX
|
||||
Pico RX <- ESP32 TX
|
||||
Ground <-> Ground
|
||||
Ground <-> Ground
|
||||
|
||||
## Planned Baud Rate
|
||||
|
||||
Initial:
|
||||
115200 baud
|
||||
115200
|
||||
|
||||
Future testing:
|
||||
- 57600 baud if noise becomes an issue
|
||||
- 230400 baud if higher update rates are needed
|
||||
Future Options:
|
||||
- 57600
|
||||
- 230400
|
||||
|
||||
## Message Format
|
||||
|
||||
Messages will use newline-delimited JSON.
|
||||
|
||||
Example request:
|
||||
Newline-delimited JSON
|
||||
|
||||
Request:
|
||||
{"type":"status_request"}
|
||||
|
||||
Example response:
|
||||
|
||||
{"type":"status_response","data":{"battery":{"soc":82}}}
|
||||
|
||||
Each message ends with a newline character.
|
||||
Response:
|
||||
{"type":"status_response"}
|
||||
|
||||
## Failure Handling
|
||||
|
||||
If no valid response is received within the timeout:
|
||||
If communication is lost:
|
||||
|
||||
- Dashboard shows communication warning
|
||||
- Dashboard shows warning
|
||||
- Last known values remain visible
|
||||
- Relay commands fail safely
|
||||
- WiFi backup may be attempted if enabled
|
||||
- WiFi backup may be attempted
|
||||
|
||||
## Why UART First
|
||||
|
||||
Advantages:
|
||||
## Advantages
|
||||
|
||||
- Fewer parts
|
||||
- Easier wiring
|
||||
- Easier debugging
|
||||
- No direction-control pin
|
||||
- No transceiver modules required
|
||||
- Works well over short distances
|
||||
- Easier wiring
|
||||
- No transceivers
|
||||
- No direction control
|
||||
- Works well for short runs
|
||||
|
||||
## Why RS-485 Is Still Available
|
||||
## Future RS-485 Option
|
||||
|
||||
RS-485 may be used later if UART has issues caused by:
|
||||
|
||||
- Alternator noise
|
||||
- Relay switching noise
|
||||
- Fridge compressor noise
|
||||
- Inverter noise
|
||||
- Long cable run
|
||||
- Ground noise
|
||||
|
||||
The software should keep a transport abstraction so UART and RS-485 can be swapped without changing the application protocol.
|
||||
If vehicle electrical noise causes issues, the transport layer can be switched to RS-485 without changing application logic.
|
||||
|
||||
Reference in New Issue
Block a user