Merge remote-tracking branch 'origin/post1'

# Conflicts:
#	docs/software/TODO.md
#	docs/software/nrf52-TODO.md
This commit is contained in:
geeksville
2020-07-24 12:49:24 -07:00
45 changed files with 16944 additions and 350 deletions

View File

@@ -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
View 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?

View File

@@ -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)

View File

@@ -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
View 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)