nippoo / maxbox-v2 Goto Github PK

View Code? Open in Web Editor NEW

0.0 0.0 0.0 1 MB

Firmware for MaxBox v2

License: GNU Affero General Public License v3.0

CMake 0.13% Makefile 0.07% C++ 3.78% C 96.03%

maxbox-v2's Issues

GNSS powersave

Watchdog task that updates battery voltage
Turn GNSS / SIM7600 on and off at predefined battery threshold

Decode NMEA string into decimal lat/long

Some ideas here: https://stackoverflow.com/questions/36254363/how-to-convert-latitude-and-longitude-of-nmea-format-data-to-decimal

Implement and test OTA FW update

Network telemetry JSON implementation

	"telemetry":	{
		"gnss":	{
			"lat":	51.12342142333984,
			"lng":	-5.1345166229248047,
			"hdop":	4.5,
			"nosats":	6,
			"ts":	353
		},
		"soc":	{
			"percent":	82,
			"ts":	355
		},
		"soh":	{
			"percent":	95,
			"ts":	355
		},
		"odometer":	{
			"miles":	5003,
			"ts":	355
		},
		"tyre_pressures":	{
			"fl_psi":	39,
			"fr_psi":	40,
			"rl_psi":	39,
			"rr_psi":	38,
			"ts":	355
		},
		"doors":	{
			"locked":	0,
			"ts":	355
		},
		"aux_battery":	{
			"voltage":	14.318400382995605
		},
		"maxbox":	{
			"ibutton_id":	"",
			"uptime_s":	355,
			"free_heap_bytes":	313252
		}
	}
}

iButton implementation

Port deprecated RMT implementation to new API

WiFi implementation

Basic network class + JSON en/decode
WiFi class with disconnect/reconnect

Right now there's a lot of floating-point calculations, particularly to get the swirling pattern right, which sometimes causes glitching. This could be stored in a precalculated intensity LUT and fetched from RAM.

Tidy up codebase

Reorder #includes
Remove unneeded #includes
Check static declarations
Static variables prefixed with s_
Standardise on portTICK_PERIOD_MS
Cleanup logging and downgrade to ESP_LOGD and ESP_LOGV as needed

Port I2C drivers to new i2c_master.h

Tasks to be beta-ready

Basic WiFi network connect/disconnect class
WiFi telemetry send task
Operator card handler
Touch handler
Watchdog task to update state
Remove esp-modem and replace with basic UART code
GNSS power-up/power-down based on battery voltage

Implement LoRaWAN codec

    FORMAT:
    lm[0] bit 0: SOC_STALE (has SoC been updated since last packet)
    lm[0] bit 1: TP_STALE (have tyre pressures been updated since last packet)
    lm[0] bit 2: GNSS_STALE (has location been updated since last packet)
    lm[0] bit 7: DOORS_LOCKED (0: locked, 1: locked)
    lm[1-4]: GNSS_LAT (float, GNSS latitude in decimal)
    lm[5-8]: GNSS_LONG (float, GNSS longitude in decimal)
    lm[9]: GNSS_HDOP (uint8, 1-9 = metres, 10-254 = 9 + (metres/10) [254 = <2.45km], 255=NaN)
    lm[10]: GNSS_AGE (age_t, see below)
    lm[11]: AUX_BAT_V (uint8, V/10 (255 = 25.5V))
    lm[12]: SOC_PERCENTAGE (uint8, 0-100, >100 NaN)
    lm[13]: SOC_AGE (age_t, see below)
    lm[14-16]: TYRE_PRESSURE_PSI (uint6 * 4, packed into 3 bytes)
    lm[17]: TYRE_PRESSURE_AGE (age_t, see below)
    
    age_t format (variable precision time in one byte)
    0           less than 1 minute
    1 to 60     minutes
    61          1-2 hours
    62          2-3 hours
    …           
    83          23-24 hours
    84          1-2 days
    …           
    253         170-171 days
    254         older than 171 days
    255         invalid/NaN

GNSS handling improvements

Only send GNSS activate string if device is powered on (otherwise just wait until next retry)
Don't update lat/long struct unless a lat/long is received

Extra telemetry to add

GPS lat/long/time of last fix/uncertainty
Tyre pressures
PCB temperature
Anything else...? Need to dig into CAN bus

Retry LoRaWAN join if initial join fails

Autogenerate devEUI based on MAC

Some standards have described how an EUI-48 value could be mapped to an EUI-64, as follows: Let the six octets of the EUI-48 be labeled eui48[0] through eui48[5]. Let the eight octets of the mapped EUI-64 be labeled eui64[0] through eui64[7]. The following mapping has been described:

eui64[0] = eui48[0]
eui64[1] = eui48[1]
eui64[2] = eui48[2]
eui64[3] = FFhex
eui64[4] = FEhex or eui64[4] = FFhex
eui64[5] = eui48[3]
eui64[6] = eui48[4]
eui64[7] = eui48[5]

In other words, the EUI-64 value was generated by inserting either the value FFFEhex or the value FFFFhex in between eui48[2] and eui48[3].

nippoo / maxbox-v2 Goto Github PK

maxbox-v2's People

Contributors

Watchers

maxbox-v2's Issues

Recommend Projects

Recommend Topics

Recommend Org