mirror of
https://github.com/meshtastic/firmware.git
synced 2025-12-24 03:31:14 +00:00
Merge remote-tracking branch 'origin/post1'
# Conflicts: # docs/software/TODO.md # docs/software/nrf52-TODO.md
This commit is contained in:
@@ -2,7 +2,14 @@
|
||||
|
||||
You probably don't care about this section - skip to the next one.
|
||||
|
||||
* Nimble getting started https://espressif-esp-idf.readthedocs-hosted.com/zh_CN/release-v3.3/api-reference/bluetooth/nimble/index.html#overview? could it work with arduino esp-idf 4.2
|
||||
- brf52 ble
|
||||
- update protocol description per cyclomies
|
||||
- esp32 pairing
|
||||
- update faq with antennas https://meshtastic.discourse.group/t/range-test-ideas-requested/738/2
|
||||
- update faq on recommended android version and phones
|
||||
- add help link inside the app, reference a page on the wiki
|
||||
- turn on amazon reviews support
|
||||
- add a tablet layout (with map next to messages) in the android app
|
||||
|
||||
# Medium priority
|
||||
|
||||
|
||||
14
docs/software/ant.md
Normal file
14
docs/software/ant.md
Normal file
@@ -0,0 +1,14 @@
|
||||
# ANT protocol notes
|
||||
|
||||
SD340 terms are reasonable for NRF52
|
||||
https://www.thisisant.com/developer/components/nrf52832#tab_protocol_stacks_tab
|
||||
|
||||
Profiles to implement:
|
||||
|
||||
tracker
|
||||
https://www.thisisant.com/developer/ant-plus/device-profiles/#4365_tab
|
||||
|
||||
ebike
|
||||
https://www.thisisant.com/developer/ant-plus/device-profiles/#527_tab
|
||||
|
||||
no profile for messaging?
|
||||
@@ -1,12 +1,26 @@
|
||||
# Bluetooth API
|
||||
# Device API
|
||||
|
||||
The Bluetooth API is design to have only a few characteristics and most polymorphism comes from the flexible set of Google Protocol Buffers which are sent over the wire. We use protocol buffers extensively both for the bluetooth API and for packets inside the mesh or when providing packets to other applications on the phone.
|
||||
The Device API is design to have only a simple stream of ToRadio and FromRadio packets and all polymorphism comes from the flexible set of Google Protocol Buffers which are sent over the wire. We use protocol buffers extensively both for the bluetooth API and for packets inside the mesh or when providing packets to other applications on the phone.
|
||||
|
||||
## A note on MTU sizes
|
||||
## Streaming version
|
||||
|
||||
This device will work with any MTU size, but it is highly recommended that you call your phone's "setMTU function to increase MTU to 512 bytes" as soon as you connect to a service. This will dramatically improve performance when reading/writing packets.
|
||||
This protocol is **almost** identical when it is deployed over BLE, Serial/USB or TCP (our three currently supported transports for connecting to phone/PC). Most of this document is in terms of the original BLE version, but this section describes the small changes when this API is exposed over a Streaming (non datagram) transport. The streaming version has the following changes:
|
||||
|
||||
## MeshBluetoothService
|
||||
- We assume the stream is reliable (though the protocol will resynchronize if bytes are lost or corrupted). i.e. we do not include CRCs or error correction codes.
|
||||
- Packets always have a four byte header (described below) prefixed before each packet. This header provides framing characters and length.
|
||||
- The stream going towards the radio is only a series of ToRadio packets (with the extra 4 byte headers)
|
||||
- The stream going towards the PC is a stream of FromRadio packets (with the 4 byte headers), or if the receiver state machine does not see valid header bytes it can (optionally) print those bytes as the debug console from the radio. This allows the device to emit regular serial debugging messages (which can be understood by a terminal program) but also switch to a more structured set of protobufs once it sees that the PC client has sent a protobuf towards it.
|
||||
|
||||
The 4 byte header is constructed to both provide framing and to not look line 'normal' 7 bit ASCII.
|
||||
|
||||
- Byte 0: START1 (0x94)
|
||||
- Byte 1: START2 (0xc3)
|
||||
- Byte 2: MSB of protobuf length
|
||||
- Byte 3: LSB of protobuf length
|
||||
|
||||
The receiver will validate length and if >512 it will assume the packet is corrupted and return to looking for START1. While looking for START1 any other characters are printed as "debug output". For small example implementation of this reader see the meshtastic-python implementation.
|
||||
|
||||
## MeshBluetoothService (the BLE API)
|
||||
|
||||
This is the main bluetooth service for the device and provides the API your app should use to get information about the mesh, send packets or provision the radio.
|
||||
|
||||
@@ -71,16 +85,20 @@ Not all messages are kept in the fromradio queue (filtered based on SubPacket):
|
||||
- No WantNodeNum / DenyNodeNum messages are kept
|
||||
A variable keepAllPackets, if set to true will suppress this behavior and instead keep everything for forwarding to the phone (for debugging)
|
||||
|
||||
## Protobuf API
|
||||
### A note on MTU sizes
|
||||
|
||||
This device will work with any MTU size, but it is highly recommended that you call your phone's "setMTU function to increase MTU to 512 bytes" as soon as you connect to a service. This will dramatically improve performance when reading/writing packets.
|
||||
|
||||
### Protobuf API
|
||||
|
||||
On connect, you should send a want_config_id protobuf to the device. This will cause the device to send its node DB and radio config via the fromradio endpoint. After sending the full DB, the radio will send a want_config_id to indicate it is done sending the configuration.
|
||||
|
||||
## Other bluetooth services
|
||||
### Other bluetooth services
|
||||
|
||||
This document focuses on the core mesh service, but it is worth noting that the following other Bluetooth services are also
|
||||
This document focuses on the core device protocol, but it is worth noting that the following other Bluetooth services are also
|
||||
provided by the device.
|
||||
|
||||
### BluetoothSoftwareUpdate
|
||||
#### BluetoothSoftwareUpdate
|
||||
|
||||
The software update service. For a sample function that performs a software update using this API see [startUpdate](https://github.com/meshtastic/Meshtastic-Android/blob/master/app/src/main/java/com/geeksville/mesh/service/SoftwareUpdateService.kt).
|
||||
|
||||
@@ -98,10 +116,10 @@ Characteristics
|
||||
| GATT_UUID_MANU_NAME/0x2a29 | read | |
|
||||
| GATT_UUID_HW_VERSION_STR/0x2a27 | read | |
|
||||
|
||||
### DeviceInformationService
|
||||
#### DeviceInformationService
|
||||
|
||||
Implements the standard BLE contract for this service (has software version, hardware model, serial number, etc...)
|
||||
|
||||
### BatteryLevelService
|
||||
#### BatteryLevelService
|
||||
|
||||
Implements the standard BLE contract service, provides battery level in a way that most client devices should automatically understand (i.e. it should show in the bluetooth devices screen automatically)
|
||||
@@ -1,15 +1,22 @@
|
||||
# NRF52 TODO
|
||||
|
||||
* Possibly switch from softdevice to Apachy Newt: https://github.com/espressif/esp-nimble
|
||||
https://github.com/apache/mynewt-core - use nimble BLE on both ESP32 and NRF52
|
||||
- Possibly switch from softdevice to Apachy Newt: https://github.com/espressif/esp-nimble
|
||||
https://github.com/apache/mynewt-core - use nimble BLE on both ESP32 and NRF52
|
||||
|
||||
## RAK815
|
||||
|
||||
### Bootloader
|
||||
Installing the adafruit bootloader is optional - I think the stock bootloader will work okay for most.
|
||||
TODO:
|
||||
|
||||
- i2c gps comms not quite right
|
||||
- ble: AdafruitBluefruit::begin - adafruit_ble_task was assigned an invalid stack pointer. out of memory?
|
||||
- measure power draw
|
||||
|
||||
### Bootloader
|
||||
|
||||
Install our (temporarily hacked up) adafruit bootloader
|
||||
|
||||
```
|
||||
kevinh@kevin-server:~/development/meshtastic/Adafruit_nRF52_Bootloader$ make BOARD=rak815 flash
|
||||
kevinh@kevin-server:~/development/meshtastic/Adafruit_nRF52_Bootloader$ make BOARD=rak815 sd flash
|
||||
LD rak815_bootloader-0.3.2-111-g9478eb7-dirty.out
|
||||
text data bss dec hex filename
|
||||
20888 1124 15006 37018 909a _build/build-rak815/rak815_bootloader-0.3.2-111-g9478eb7-dirty.out
|
||||
@@ -33,20 +40,52 @@ Applying system reset.
|
||||
Run.
|
||||
```
|
||||
|
||||
### Appload
|
||||
|
||||
tips on installing https://github.com/platformio/platform-nordicnrf52/issues/8#issuecomment-374017768
|
||||
|
||||
to see console output over jlink:
|
||||
|
||||
```
|
||||
12:17
|
||||
in one tab run "bin/nrf52832-gdbserver.sh" - leave this running the whole time while developing/debugging
|
||||
12:17
|
||||
~/development/meshtastic/meshtastic-esp32$ bin/nrf52-console.sh
|
||||
###RTT Client: ************************************************************
|
||||
###RTT Client: * SEGGER Microcontroller GmbH *
|
||||
###RTT Client: * Solutions for real time microcontroller applications *
|
||||
###RTT Client: ************************************************************
|
||||
###RTT Client: * *
|
||||
###RTT Client: * (c) 2012 - 2016 SEGGER Microcontroller GmbH *
|
||||
###RTT Client: * *
|
||||
###RTT Client: * www.segger.com Support: support@segger.com *
|
||||
###RTT Client: * *
|
||||
###RTT Client: ************************************************************
|
||||
###RTT Client: * *
|
||||
###RTT Client: * SEGGER J-Link RTT Client Compiled Apr 7 2020 15:01:22 *
|
||||
###RTT Client: * *
|
||||
###RTT Client: ************************************************************
|
||||
###RTT Client: -----------------------------------------------
|
||||
###RTT Client: Connecting to J-Link RTT Server via localhost:19021 ..............
|
||||
###RTT Client: Connected.
|
||||
SEGGER J-Link V6.70c - Real time terminal output
|
||||
SEGGER J-Link ARM V9.6, SN=69663845
|
||||
Process: JLinkGDBServerCLExein another tab run:
|
||||
12:18
|
||||
On NRF52 I've been using the jlink fake serial console. But since the rak815 has the serial port hooked up we can switch back to that once the basics are working.
|
||||
```
|
||||
|
||||
## Misc work items
|
||||
|
||||
RAM investigation.
|
||||
nRF52832-QFAA 64KB ram, 512KB flash vs
|
||||
nrf52832-QFAB 32KB ram, 512kb flash
|
||||
nrf52833 128KB RAM
|
||||
nrf52840 256KB RAM, 1MB flash
|
||||
|
||||
platform.json
|
||||
Manual hacks needed to build (for now):
|
||||
|
||||
"framework-arduinoadafruitnrf52": {
|
||||
"type": "framework",
|
||||
"optional": true,
|
||||
"version": "https://github.com/meshtastic/Adafruit_nRF52_Arduino.git"
|
||||
},
|
||||
kevinh@kevin-server:~/.platformio/packages/framework-arduinoadafruitnrf52/variants\$ ln -s ~/development/meshtastic/meshtastic-esp32/variants/\* .
|
||||
|
||||
## Initial work items
|
||||
|
||||
|
||||
6
docs/software/rak815.md
Normal file
6
docs/software/rak815.md
Normal file
@@ -0,0 +1,6 @@
|
||||
# RAK815
|
||||
|
||||
Notes on trying to get the RAK815 working with meshtastic.
|
||||
|
||||
good tutorial: https://www.hackster.io/naresh-krish/getting-started-with-rak815-tracker-module-and-arduino-1c7bc9
|
||||
(includes software serial link - possibly useful for GPS)
|
||||
Reference in New Issue
Block a user