rbxii3/firmware
1
0
Fork 0
mirror of https://github.com/meshtastic/firmware.git synced 2026-01-06 01:48:13 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'master' into PlatformIO-build-guide-update

Browse Source
This commit is contained in:
Kevin Hester
2020-08-10 08:56:15 -07:00
committed by GitHub
parent 05531b2684 7652331e8c
commit d6658dbb2e
149 changed files with 20543 additions and 2124 deletions
Download Patch File Download Diff File Expand all files Collapse all files

55
docs/software/TODO.md
View File

@@ -1,43 +1,44 @@
# High priority
# Geeksville's current work queue
- modem sleep should work if we lower serial rate to 115kb?
- device wakes, turns BLE on and phone doesn't notice (while phone was sitting in auto-connect)
- encryption review findings writeup
You probably don't care about this section - skip to the next one.
- turn on modem-sleep mode - https://github.com/espressif/arduino-esp32/issues/1142#issuecomment-512428852
last EDF release in arduino is: https://github.com/espressif/arduino-esp32/commit/1977370e6fc069e93ffd8818798fbfda27ae7d99
IDF release/v3.3 46b12a560
IDF release/v3.3 367c3c09c
https://docs.espressif.com/projects/esp-idf/en/release-v3.3/get-started/linux-setup.html
kevinh@kevin-server:~/development/meshtastic/esp32-arduino-lib-builder\$ python /home/kevinh/development/meshtastic/esp32-arduino-lib-builder/esp-idf/components/esptool_py/esptool/esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dout --flash_freq 40m --flash_size detect 0x1000 /home/kevinh/development/meshtastic/esp32-arduino-lib-builder/build/bootloader/bootloader.bin
cp -a out/tools/sdk/_ components/arduino/tools/sdk
cp -ar components/arduino/_ ~/.platformio/packages/framework-arduinoespressif32@src-fba9d33740f719f712e9f8b07da6ea13/
Nimble tasks:
- readerror.txt stress test bug
- started RPA long test, jul 22 6pm
- implement nimble software update api
- update to latest bins, test OTA again (measure times) and then checkin bins
- do alpha release
* update protocol description per cyclomies email thread
* 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
Items to complete before the first beta release.
Items to complete before 1.0.
- turn on watchdog timer (because lib code seems buggy)
- show battery level as % full
- rx signal measurements -3 marginal, -9 bad, 10 great, -10 means almost unusable. So scale this into % signal strength. preferably as a graph, with an X indicating loss of comms.
# Pre-beta priority
During the beta timeframe the following improvements 'would be nice'
# Post 1.0 ideas
- finish DSR for unicast
- check fcc rules on duty cycle. we might not need to freq hop. https://www.sunfiretesting.com/LoRa-FCC-Certification-Guide/ . Might need to add enforcement for europe though.
- pick channel center frequency based on channel name? "dolphin" would hash to 900Mhz, "cat" to 905MHz etc? allows us to hide the concept of channel # from hte user.
- make a no bluetooth configured yet screen - include this screen in the loop if the user hasn't yet paired
- if radio params change fundamentally, discard the nodedb
- re-enable the bluetooth battery level service on the T-BEAM
- implement first cut of router mode: preferentially handle flooding, and change sleep and GPS behaviors
- provide generalized (but slow) internet message forwarding service if one of our nodes has internet connectivity (MQTT) [ Not a requirement but a personal interest ]
# Low priority
# Low priority ideas
Items after the first final candidate release.
- implement nimble battery level service
- Nimble implement device info service remaining fields (hw version etc)
- Turn on RPA addresses for the device side in Nimble
- Try to teardown less of the Nimble protocol stack across sleep
- dynamic frequency scaling could save a lot of power on ESP32, but it seems to corrupt uart (even with ref_tick set correctly)
- Change back to using a fixed sized MemoryPool rather than MemoryDynamic (see bug #149)
- scan to find channels with low background noise? (Use CAD mode of the RF95 to automatically find low noise channels)
- If the phone doesn't read fromradio mailbox within X seconds, assume the phone is gone and we can stop queing location msgs
@@ -63,11 +64,17 @@ Items after the first final candidate release.
- split out the software update utility so other projects can use it. Have the appload specify the URL for downloads.
- read the PMU battery fault indicators and blink/led/warn user on screen
- discard very old nodedb records (> 1wk)
- add a watchdog timer
- handle millis() rollover in GPS.getTime - otherwise we will break after 50 days
- report esp32 device code bugs back to the mothership via android
- change BLE bonding to something more secure. see comment by pSecurity->setAuthenticationMode(ESP_LE_AUTH_BOND)
Changes related to wifi support on ESP32:
- iram space: https://esp32.com/viewtopic.php?t=8460
- set https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/external-ram.html spi ram bss
- figure out if iram or bluetooth classic caused ble problems
- post bug on esp32-arduino with BLE bug findings
# Spinoff project ideas
- an open source version of https://www.burnair.ch/skynet/

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?

9
docs/software/build-instructions.md
View File

@@ -15,9 +15,14 @@ This project uses the simple PlatformIO build system. PlatformIO is an extension
## Command Line
1. Purchase a suitable [radio](https://github.com/meshtastic/Meshtastic-device/wiki/Hardware-Information).
2. Install [PlatformIO](https://platformio.org/platformio-ide)
3. Download this git repo and cd into it. `git clone https://github.com/meshtastic/Meshtastic-device.git` and `cd Meshtastic-device`
3. Download this git repo and cd into it:
```
git clone https://github.com/meshtastic/Meshtastic-device.git
cd Meshtastic-device
```
4. Run `git submodule update --init --recursive` to pull in dependencies this project needs.
5. If you are outside the USA, edit [platformio.ini](/platformio.ini) to set the correct frequency range for your country. The line you need to change starts with `hw_version` and instructions are provided above that line. Options are provided for `EU433`, `EU835`, `CN`, `JP` and `US` (default). Pull-requests eagerly accepted for other countries.
5. If you are outside the USA, run "export COUNTRY=EU865" (or whatever) to set the correct frequency range for your country. Options are provided for `EU433`, `EU865`, `CN`, `JP` and `US` (default). Pull-requests eagerly accepted for other countries.
6. Plug the radio into your USB port
7. Type `pio run --environment XXX -t upload` (This command will fetch dependencies, build the project and install it on the board via USB). For XXX, use the board type you have (either `tlora-v2, tlora-v1, tlora-v2-1-1.6, tbeam, heltec, tbeam0.7`).
8. Platform IO also installs a very nice VisualStudio Code based IDE, see their [tutorial](https://docs.platformio.org/en/latest/tutorials/espressif32/arduino_debugging_unit_testing.html) if you'd like to use it.

52
docs/software/crypto.md
View File

@@ -5,33 +5,47 @@ the project developers are not cryptography experts. Therefore we ask two things
- If you are a cryptography expert, please review these notes and our questions below. Can you help us by reviewing our
notes below and offering advice? We will happily give as much or as little credit as you wish ;-).
- Consider our existing solution 'alpha' and probably fairly secure against a not particularly aggressive adversary. But until
it is reviewed by someone smarter than us, assume it might have flaws.
- Consider our existing solution 'alpha' and probably fairly secure against a not particularly aggressive adversary
(but we can't yet make a more confident statement).
## Notes on implementation
## Summary of strengths/weaknesses of our current implementation
Based on comments from reviewers (see below), here's some tips for usage of these radios. So you can know the level of protection offered:
* It is pretty likely that the AES256 security is implemented 'correctly' and an observer will not be able to decode your messages.
* Warning: If an attacker is able to get one of the radios in their position, they could either a) extract the channel key from that device or b) use that radio to listen to new communications.
* Warning: If an attacker is able to get the "Channel QR code/URL" that you share with others - that attacker could then be able to read any messages sent on the channel (either tomorrow or in the past - if they kept a raw copy of those broadcast packets)
Possible future areas of work (if there is enough interest - post in our [forum](https://meshtastic.discourse.group) if you want this):
1. Optionally requiring users to provide a PIN to regain access to the mesh. This could be based on: intentionally locking the device, time since last use, or any member could force all members to reauthenticate,
2. Until a device reauthenticates, any other access via BLE or USB would be blocked (this would protect against attackers who are not prepared to write custom software to extract and reverse engineer meshtastic flash memory)
3. Turning on read-back protection in the device fuse-bits (this would extend protection in #2 to block all but **extremely** advanced attacks involving chip disassembly)
4. Time limiting keys used for message transmission and automatically cycling them on a schedule. This would protect past messages from being decoded even if an attacker learns the current key.
### Notes for reviewers
If you are reviewing our implementation, this is a brief statement of our method.
- We do all crypto at the SubPacket (payload) level only, so that all meshtastic nodes will route for others - even those channels which are encrypted with a different key.
- Mostly based on reading [Wikipedia](<https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter_(CTR)>) and using the modes the ESP32 provides support for in hardware.
- We use AES256-CTR as a stream cypher (with zero padding on the last BLOCK) because it is well supported with hardware acceleration.
Parameters for our CTR implementation:
- Our AES key is 128 or 256 bits, shared as part of the 'Channel' specification.
- Each SubPacket will be sent as a series of 16 byte BLOCKS.
- The node number concatenated with the packet number is used as the NONCE. This counter will be stored in flash in the device and should essentially never repeat. If the user makes a new 'Channel' (i.e. picking a new random 256 bit key), the packet number will start at zero. The packet number is sent
in cleartext with each packet. The node number can be derived from the "from" field of each packet.
- Each BLOCK for a packet has an incrementing COUNTER. COUNTER starts at zero for the first block of each packet.
- The IV for each block is constructed by concatenating the NONCE as the upper 96 bits of the IV and the COUNTER as the bottom 32 bits. Note: since our packets are small counter will really never be higher than 32 (five bits).
- The node number concatenated with the packet number is used as the NONCE. This nonce will be stored in flash in the device and should essentially never repeat. If the user makes a new 'Channel' (i.e. picking a new random 256 bit key), the packet number will start at zero.
- The packet number is sent in cleartext with each packet. The node number can be derived from the "from" field of each packet. (Cleartext is acceptable because it merely provides IV for each encryption run)
- Each 16 byte BLOCK for a packet has an incrementing COUNTER. COUNTER starts at zero for the first block of each packet.
- The IV for each block is constructed by concatenating the NONCE as the upper 96 bits of the IV and the COUNTER as the bottom 32 bits. Since our packets are small counter portion will really never be higher than 32 (five bits).
```
You can encrypt separate messages by dividing the nonce_counter buffer in two areas: the first one used for a per-message nonce, handled by yourself, and the second one updated by this function internally.
For example, you might reserve the first 12 bytes for the per-message nonce, and the last 4 bytes for internal use. In that case, before calling this function on a new message you need to set the first 12 bytes of nonce_counter to your chosen nonce value, the last 4 to 0, and nc_off to 0 (which will cause stream_block to be ignored). That way, you can encrypt at most 2**96 messages of up to 2**32 blocks each with the same key.
## Comments from reviewer #1
The per-message nonce (or information sufficient to reconstruct it) needs to be communicated with the ciphertext and must be unique. The recommended way to ensure uniqueness is to use a message counter. An alternative is to generate random nonces, but this limits the number of messages that can be securely encrypted: for example, with 96-bit random nonces, you should not encrypt more than 2**32 messages with the same key.
This reviewer is a cryptography professional, but would like to remain anonymous. We thank them for their comments ;-):
Note that for both stategies, sizes are measured in blocks and that an AES block is 16 bytes.
```
I'm assuming that meshtastic is being used to hike in places where someone capable is trying to break it - like you were going to walk around DefCon using these. I spent about an hour reviewing the encryption, and have the following notes:
## Remaining todo
* The write-up isn't quite as clear as the code.
* The code is using AES-CTR mode correctly to ensure confidentiality.
* The comment for initNonce really covers the necessary information.
* I think the bigger encryption question is "what does the encryption need to do"? As it stands, an attacker who has yet to capture any of the devices cannot reasonably capture text or location data. An attacker who captures any device in the channel/mesh can read everything going to that device, everything stored on that device, and any other communication within the channel that they captured in encrypted form. If that capability basically matches your expectations, it is suitable for whatever adventures this was intended for, then, based on information publicly available or widely disclosed, the encryption is good. If those properties are distressing (like, device history is deliberately limited and you don't want a device captured today to endanger the information sent over the channel yesterday) we could talk about ways to achieve that (most likely synchronizing time and replacing the key with its own SHA256 every X hours, and ensuring the old key is not retained unnecessarily).
* Two other things to keep in mind are that AES-CTR does not itself provide authenticity (e.g. an attacker can flip bits in replaying data and scramble the resulting plaintext), and that the current scheme gives some hints about transmission in the size. So, if you worry about an adversary deliberately messing-up messages or knowing the length of a text message, it looks like those might be possible.
- Have the app change the crypto key when the user generates a new channel
I'm guessing that the network behaves somewhat like a store-and-forward network - or, at least, that the goal is to avoid establishing a two-way connection to transmit data. I'm afraid I haven't worked with mesh networks much, but remember studying them briefly in school about ten years ago.

40
docs/software/bluetooth-api.md → docs/software/device-api.md
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)

23
docs/software/esp32-arduino-build-notes.md Normal file
View File

@@ -0,0 +1,23 @@
# esp32-arduino build instructions
We build our own custom version of esp32-arduino, in order to get some fixes we've made but haven't yet been merged in master.
These are a set of currently unformatted notes on how to build and install them. Most developers should not care about this, because
you'll automatically get our fixed libraries.
```
last EDF release in arduino is: https://github.com/espressif/arduino-esp32/commit/1977370e6fc069e93ffd8818798fbfda27ae7d99
IDF release/v3.3 46b12a560
IDF release/v3.3 367c3c09c
https://docs.espressif.com/projects/esp-idf/en/release-v3.3/get-started/linux-setup.html
kevinh@kevin-server:~/development/meshtastic/esp32-arduino-lib-builder\$ python /home/kevinh/development/meshtastic/esp32-arduino-lib-builder/esp-idf/components/esptool*py/esptool/esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dout --flash_freq 40m --flash_size detect 0x1000 /home/kevinh/development/meshtastic/esp32-arduino-lib-builder/build/bootloader/bootloader.bin
cp -a out/tools/sdk/* components/arduino/tools/sdk
cp -ar components/arduino/* ~/.platformio/packages/framework-arduinoespressif32
/// @src-fba9d33740f719f712e9f8b07da6ea13/
or
cp -ar out/tools/sdk/* ~/.platformio/packages/framework-arduinoespressif32/tools/sdk
```

11
docs/software/mesh-alg.md
View File

@@ -19,20 +19,21 @@ reliable messaging tasks (stage one for DSR):
- DONE once an ack comes in, remove the packet from the retry list and deliver the ack to the original sender
- DONE after three retries, deliver a no-ack packet to the original sender (i.e. the phone app or mesh router service)
- DONE test one hop ack/nak with the python framework
- Do stress test with acks
- DONE Do stress test with acks
dsr tasks
- oops I might have broken message reception
- DONE oops I might have broken message reception
- DONE Don't use broadcasts for the network pings (close open github issue)
- DONE add ignoreSenders to radioconfig to allow testing different mesh topologies by refusing to see certain senders
- test multihop delivery with the python framework
- DONE test multihop delivery with the python framework
optimizations / low priority:
- read this [this](http://pages.cs.wisc.edu/~suman/pubs/nadv-mobihoc05.pdf) paper and others and make our naive flood routing less naive
- read @cyclomies long email with good ideas on optimizations and reply
- Remove NodeNum assignment algorithm (now that we use 4 byte node nums)
- make android app warn if firmware is too old or too new to talk to
- DONE Remove NodeNum assignment algorithm (now that we use 4 byte node nums)
- DONE make android app warn if firmware is too old or too new to talk to
- change nodenums and packetids in protobuf to be fixed32
- low priority: think more careful about reliable retransmit intervals
- make ReliableRouter.pending threadsafe

91
docs/software/nrf52-TODO.md
View File

@@ -1,14 +1,93 @@
# 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
## RAK815
TODO:
- shrink soft device RAM usage
- get nrf52832 working again (currently OOM)
- 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 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
Create rak815_bootloader-0.3.2-111-g9478eb7-dirty.hex
Create rak815_bootloader-0.3.2-111-g9478eb7-dirty-nosd.hex
Flashing: rak815_bootloader-0.3.2-111-g9478eb7-dirty-nosd.hex
nrfjprog --program _build/build-rak815/rak815_bootloader-0.3.2-111-g9478eb7-dirty-nosd.hex --sectoranduicrerase -f nrf52 --reset
Parsing hex file.
Erasing page at address 0x0.
Erasing page at address 0x74000.
Erasing page at address 0x75000.
Erasing page at address 0x76000.
Erasing page at address 0x77000.
Erasing page at address 0x78000.
Erasing page at address 0x79000.
Erasing UICR flash area.
Applying system reset.
Checking that the area to write is not protected.
Programming device.
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
platform.json
RAM investigation.
nRF52832-QFAA 64KB ram, 512KB flash vs
nrf52832-QFAB 32KB ram, 512kb flash
nrf52833 128KB RAM
nrf52840 256KB RAM, 1MB flash
"framework-arduinoadafruitnrf52": {
"type": "framework",
"optional": true,
"version": "https://github.com/meshtastic/Adafruit_nRF52_Arduino.git"
},
Manual hacks needed to build (for now):
kevinh@kevin-server:~/.platformio/packages/framework-arduinoadafruitnrf52/variants\$ ln -s ~/development/meshtastic/meshtastic-esp32/variants/\* .
## Initial work items

27
docs/software/pinetab.md Normal file
View File

@@ -0,0 +1,27 @@
# Pinetab
These are **preliminary** notes on support for Meshtastic in the Pinetab.
A RF95 is connected via a CS341 USB-SPI chip.
Pin assignments:
CS0 from RF95 goes to CS0 on CS341
DIO0 from RF95 goes to INT on CS341
RST from RF95 goes to RST on CS341
This linux driver claims to provide USB-SPI support: https://github.com/gschorcht/spi-ch341-usb
Notes here on using that driver: https://www.linuxquestions.org/questions/linux-hardware-18/ch341-usb-to-spi-adaptor-driver-doesn%27t-work-4175622736/
Or if **absolutely** necessary could bitbang: https://www.cnx-software.com/2018/02/16/wch-ch341-usb-to-serial-chip-gets-linux-driver-to-control-gpios-over-usb/
## Task list
* Port meshtastic to build (under platformio) for a poxix target. spec: no screen, no gpios, sim network interface, posix threads, posix semaphores & queues, IO to the console only
Use ARM linux: https://platformio.org/platforms/linux_arm
And linux native: https://platformio.org/platforms/native
* Test cs341 driver - just test reading/writing a register and detecting interrupts, confirm can see rf95
* Make a radiolib spi module that targets the cs341 (and builds on linux)
* use new radiolib module to hook pinebook lora to meshtastic, confirm mesh discovery works
* Make a subclass of StreamAPI that works as a posix TCP server
* Use new TCP endpoint from meshtastic-python

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)

202
docs/software/ramusage-nrf52.txt Normal file
View File

@@ -0,0 +1,202 @@
23K + messages
+ heap of 70ish packets, 300ish bytes per packet: 20KB
+ 14KB soft device RAM
With max length Data inside the packet
Size of NodeInfo 104
Size of SubPacket 272
Size of MeshPacket 304
If Data was smaller: for 70 data packets we would save 7KB. We would need to make SubPacket.data and MeshPacket.encrypted into "type:FT_POINTER" - variably sized mallocs
Size of NodeInfo 104
Size of SubPacket 96
Size of MeshPacket 292 (could have been much smaller but I forgot to shrink MeshPacket.encrypted)
therefore:
a) we should store all ToPhone message queued messages compressed as protobufs (since they will become that anyways)
b) shrink packet pool size because none of that storage will be used for ToPhone packets
c) don't allocate any storage in RAM for the tophone messages we save inside device state, instead just use nanopb callbacks to save/load those
d) a smarter MeshPacket in memory representation would save about 7KB of RAM. call pb_release before freeing each freshly malloced MeshPacket
- nrf52 free memory https://learn.adafruit.com/bluefruit-nrf52-feather-learning-guide/hathach-memory-map
2000790c 00003558 B devicestate // 16KB
2000b53c 00001000 b _cache_buffer // 4KB flash filesystem support
20003b1c 000006b0 B console
2000d5f4 00000400 b vApplicationGetTimerTaskMemory::uxTimerTaskStack
2000da04 00000400 b _acUpBuffer
2000c558 0000036c B Bluefruit
2000c8d8 00000358 b _cdcd_itf
2000e54c 00000258 B _midid_itf
2000d0dc 00000200 b ucStaticTimerQueueStorage.9390
2000e044 00000200 b _mscd_buf
2000e284 000001cc b _vendord_itf
2000d410 00000190 b vApplicationGetIdleTaskMemory::uxIdleTaskStack
2000374c 0000016c D __global_locale
2000de48 0000012c B USBDevice
2000afa4 00000100 b Router::send(_MeshPacket*)::bytes
2000aea4 00000100 b Router::perhapsDecode(_MeshPacket*)::bytes
200039b0 000000f4 B powerFSM
20004258 000000f0 B screen
2000cd7c 000000c4 b _dcd
2000cc68 000000c0 b _usbd_qdef_buf
2000b3c4 000000bc B Wire
2000cef4 000000a8 B Serial2
2000ce4c 000000a8 B Serial1
2000e498 000000a8 B _SEGGER_RTT
2000b498 000000a4 B InternalFS
2000dfb8 0000008c b _hidd_itf
2000b260 00000088 b meshtastic::normalFrames
2000cfdc 00000064 b pxReadyTasksLists
2000b340 00000060 b meshtastic::drawTextMessageFrame(OLEDDisplay*, OLEDDisplayUiState*, short, short)::tempBuf
200036ec 00000060 d impure_data
2000b104 00000060 B bledfu
2000b0a4 00000060 B blebas
20003684 00000058 D _usbd_qdef
200038c0 00000058 d tzinfo
2000d5a0 00000054 b vApplicationGetTimerTaskMemory::xTimerTaskTCB
2000d3bc 00000054 b vApplicationGetIdleTaskMemory::xIdleTaskTCB
2000d308 00000050 b xStaticTimerQueue.9389
2000b1f4 00000050 B hrmc
2000b1a4 00000050 B bslc
20004360 0000004c B service
2000d374 00000048 b m_cb
2000df74 00000042 b _desc_str
2000cd3c 00000040 b _usbd_ctrl_buf
20004214 00000040 B realRouter
2000e244 00000040 b _mscd_itf
2000b164 00000040 B bledis
20003634 00000038 d _InternalFSConfig
2000cc30 00000031 b _usbd_dev
2000398c 00000020 B periodicScheduler
2000cfa4 00000020 b callbacksInt
2000de10 0000001f b fw_str.13525
20003974 00000018 b object.9934
2000ae68 00000018 B nodeDB
2000366c 00000018 d _cache
2000b314 00000014 b meshtastic::drawNodeInfo(OLEDDisplay*, OLEDDisplayUiState*, short, short)::signalStr
2000b300 00000014 b meshtastic::drawNodeInfo(OLEDDisplay*, OLEDDisplayUiState*, short, short)::lastStr
2000b2ec 00000014 b meshtastic::drawNodeInfo(OLEDDisplay*, OLEDDisplayUiState*, short, short)::distStr
200041e0 00000014 b getDeviceName()::name
2000d0b8 00000014 b xTasksWaitingTermination
2000d0a4 00000014 b xSuspendedTaskList
2000d08c 00000014 b xPendingReadyList
2000d06c 00000014 b xDelayedTaskList2
2000d058 00000014 b xDelayedTaskList1
2000d2f0 00000014 b xActiveTimerList2
2000d2dc 00000014 b xActiveTimerList1
2000b480 00000014 B SPI
2000c8c4 00000014 B Serial
2000cd28 00000014 b _ctrl_xfer
2000de30 00000011 b serial_str.13534
2000c544 00000010 b BLEAdvertising::_start(unsigned short, unsigned short)::gap_adv
20003614 00000010 d meshtastic::btPIN
2000434c 00000010 b sendOwnerPeriod
2000ae8c 00000010 b staticPool
2000e484 00000010 B xQueueRegistry
20003b04 00000010 B stateSERIAL
20003af4 00000010 B stateSDS
20003ae4 00000010 B stateON
20003ad4 00000010 B stateNB
20003ac4 00000010 B stateLS
20003ab4 00000010 B stateDARK
20003aa4 00000010 B stateBOOT
200041f8 00000010 B ledPeriodic
2000b244 00000010 B hrms
2000d9f4 00000010 b _acDownBuffer
2000b3b8 0000000c B preflightSleep
20004208 0000000c B powerStatus
2000e540 0000000c B nrf_nvic_state
2000b3ac 0000000c B notifySleep
2000b3a0 0000000c B notifyDeepSleep
2000e463 0000000b b __tzname_std
2000e458 0000000b b __tzname_dst
2000b338 00000008 b meshtastic::estimatedHeading(double, double)::oldLon
2000b330 00000008 b meshtastic::estimatedHeading(double, double)::oldLat
200041d0 00000008 b zeroOffsetSecs
2000ae80 00000008 b spiSettings
200038b8 00000008 D _tzname
20003b14 00000008 B noopPrint
2000cfc4 00000008 b channelMap
2000cf9c 00000008 b callbackDeferred
200043ac 00000006 b ourMacAddr
2000435c 00000004 b MeshService::onGPSChanged(void*)::lastGpsSend
2000b32c 00000004 b meshtastic::estimatedHeading(double, double)::b
2000b328 00000004 b meshtastic::drawNodeInfo(OLEDDisplay*, OLEDDisplayUiState*, short, short)::simRadian
2000362c 00000004 d meshtastic::Screen::setup()::bootFrames
20003628 00000004 d meshtastic::Screen::handleStartBluetoothPinScreen(unsigned long)::btFrames
200039ac 00000004 b onEnter()::lastPingMs
2000ae9c 00000004 b generatePacketId()::i
2000ae88 00000004 B RadioLibInterface::instance
2000b2e8 00000004 b meshtastic::nodeIndex
20003610 00000004 d meshtastic::targetFramerate
2000c554 00000004 B BLEService::lastService
200041cc 00000004 b timeStartMsec
200036dc 00000004 d sbrk_heap_top
2000d364 00000004 b _loopHandle
2000c540 00000004 b guard variable for BLEAdvertising::_start(unsigned short, unsigned short)::gap_adv
2000d0d0 00000004 b xYieldPending
2000d35c 00000004 b xTimerTaskHandle
2000d358 00000004 b xTimerQueue
2000d0cc 00000004 b xTickCount
2000d0a0 00000004 b xSchedulerRunning
2000d088 00000004 b xNumOfOverflows
2000d084 00000004 b xNextTaskUnblockTime
2000d304 00000004 b xLastTime.9343
2000d080 00000004 b xIdleTaskHandle
2000d054 00000004 b uxTopReadyPriority
2000d050 00000004 b uxTaskNumber
2000d04c 00000004 b uxSchedulerSuspended
2000d048 00000004 b uxPendedTicks
2000d044 00000004 b uxDeletedTasksWaitingCleanUp
2000d040 00000004 b uxCurrentNumberOfTasks
2000d360 00000004 b uxCriticalNesting
2000cc64 00000004 b _usbd_q
2000e478 00000004 B _timezone
200036e0 00000004 D SystemCoreClock
2000c53c 00000004 b _sem
2000d0d8 00000004 b pxOverflowTimerList
2000cfd8 00000004 b pxOverflowDelayedTaskList
2000cfd4 00000004 b pxDelayedTaskList
2000d0d4 00000004 b pxCurrentTimerList
2000cfd0 00000004 B pxCurrentTCB
2000e470 00000004 b prev_tzenv
2000360c 00000004 D preftmp
20003608 00000004 D preffile
2000b25c 00000004 B nrf52Bluetooth
2000d370 00000004 b m_usbevt_handler
2000d36c 00000004 b m_sleepevt_handler
2000d368 00000004 b m_pofwarn_handler
2000e454 00000004 B __malloc_sbrk_start
2000e450 00000004 B __malloc_free_list
2000e480 00000004 B MAIN_MonCnt
2000e47c 00000004 b initial_env
200036e8 00000004 D _impure_ptr
200041d8 00000004 B gps
2000e7a4 00000004 B errno
20003918 00000004 D environ
2000cfcc 00000004 b enabled
2000ae64 00000004 B displayedNodeNum
2000e474 00000004 B _daylight
2000b254 00000004 B crypto
2000ce44 00000004 B count_duration
2000de0c 00000004 b _cb_task
2000de08 00000004 b _cb_queue
2000de04 00000004 b _cb_qdepth
2000de44 00000004 B bootloaderVersion
200041f5 00000001 b ledBlinker()::ledOn
20003604 00000001 d loop::showingBootScreen
200041f4 00000001 b loop::wasPressed
2000b494 00000001 b DefaultFontTableLookup(unsigned char)::LASTCHAR
2000aea0 00000001 b generatePacketId()::didInit
20003624 00000001 d meshtastic::prevFrame
2000b258 00000001 b bleOn
200041dc 00000001 B timeSetFromGPS
20004348 00000001 B ssd1306_found
2000ce49 00000001 B pin_sound
2000e494 00000001 B nrfx_power_irq_enabled
2000ce48 00000001 B no_stop
20003630 00000001 D neo6M
2000ce40 00000001 b _initialized
200036e4 00000001 D __fdlib_version
20003970 00000001 b completed.9929

148
docs/software/read-error.txt Normal file
View File

@@ -0,0 +1,148 @@
nimble stress test error (private notes for @geeksville)
findings:
only happens when stress testing multiple sleepwake cycles?
failed packets all have initial mbuflen of zero (should be 1)
restarting the connection on phone sometimes (but not always) fixes it (is the larger config nonce pushing packet size up too large?)
- packets >= 79 bytes (FromRadio) cause INVALID_OFFSET (7) gatt errors to be sent to the app
- some packets are missing
theory:
some sort of leak in mbuf storage during unfortunately timed sleep shutdowns
device side
connection updated; status=0 handle=0 our_ota_addr_type=0 our_ota_addr=00:24:62:ab:dd:df
our_id_addr_type=0 our_id_addr=00:24:62:ab:dd:df
peer_ota_addr_type=0 peer_ota_addr=00:7c:d9:5c:ba:2e
peer_id_addr_type=0 peer_id_addr=00:7c:d9:5c:ba:2e
conn_itvl=36 conn_latency=0 supervision_timeout=500 encrypted=1 authenticated=1 bonded=1
BLE fromRadio called
getFromRadio, !available
toRadioWriteCb data 0x3ffc3d72, len 4
Trigger powerFSM 9
Transition powerFSM transition=Contact from phone, from=DARK to=DARK
Client wants config, nonce=6864
Reset nodeinfo read pointer
toRadioWriteCb data 0x3ffc3d72, len 4
Trigger powerFSM 9
Transition powerFSM transition=Contact from phone, from=DARK to=DARK
Client wants config, nonce=6863
Reset nodeinfo read pointer
BLE fromRadio called
getFromRadio, state=2
encoding toPhone packet to phone variant=3, 50 bytes
BLE fromRadio called
getFromRadio, state=3
encoding toPhone packet to phone variant=6, 83 bytes
BLE fromRadio called
getFromRadio, state=4
Sending nodeinfo: num=0xabdddf38, lastseen=1595606850, id=!2462abdddf38, name=Bob b
encoding toPhone packet to phone variant=4, 67 bytes
BLE fromRadio called
getFromRadio, state=4
Sending nodeinfo: num=0x28b200b4, lastseen=1595606804, id=!246f28b200b4, name=Unknown 00b4
encoding toPhone packet to phone variant=4, 80 bytes
BLE fromRadio called
getFromRadio, state=4
Sending nodeinfo: num=0xabf84098, lastseen=1593680756, id=!2462abf84098, name=bx n
encoding toPhone packet to phone variant=4, 72 bytes
BLE fromRadio called
getFromRadio, state=4
Sending nodeinfo: num=0x83f0d8e5, lastseen=1594686931, id=!e8e383f0d8e5, name=Unknown d8e5
encoding toPhone packet to phone variant=4, 64 bytes
BLE fromRadio called
getFromRadio, state=4
Sending nodeinfo: num=0xd1dc7764, lastseen=1595602082, id=!f008d1dc7764, name=dg
encoding toPhone packet to phone variant=4, 52 bytes
BLE fromRadio called
getFromRadio, state=4
Sending nodeinfo: num=0xd1dc7828, lastseen=1595598298, id=!f008d1dc7828, name=ryan
encoding toPhone packet to phone variant=4, 54 bytes
BLE fromRadio called
getFromRadio, state=4
Done sending nodeinfos
getFromRadio, state=5
phone side
2020-07-24 09:11:00.642 6478-6545/com.geeksville.mesh W/com.geeksville.mesh.service.BluetoothInterface: Attempting reconnect
2020-07-24 09:11:00.642 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: Enqueuing work: connect
2020-07-24 09:11:00.642 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth$BluetoothContinuation: Starting work: connect
2020-07-24 09:11:00.643 6478-6545/com.geeksville.mesh D/BluetoothGatt: connect() - device: 24:62:AB:DD:DF:3A, auto: false
2020-07-24 09:11:00.643 6478-6545/com.geeksville.mesh D/BluetoothGatt: registerApp()
2020-07-24 09:11:00.643 6478-6545/com.geeksville.mesh D/BluetoothGatt: registerApp() - UUID=026baf7f-d2de-43f1-961f-4e00e04c6fbb
2020-07-24 09:11:00.645 6478-27868/com.geeksville.mesh D/BluetoothGatt: onClientRegistered() - status=0 clientIf=4
2020-07-24 09:11:01.022 6478-27868/com.geeksville.mesh D/BluetoothGatt: onClientConnectionState() - status=0 clientIf=4 device=24:62:AB:DD:DF:3A
2020-07-24 09:11:01.022 6478-27868/com.geeksville.mesh I/com.geeksville.mesh.service.SafeBluetooth: new bluetooth connection state 2, status 0
2020-07-24 09:11:01.023 6478-27868/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: work connect is completed, resuming status=0, res=kotlin.Unit
2020-07-24 09:11:01.023 6478-6545/com.geeksville.mesh I/com.geeksville.mesh.service.BluetoothInterface: Connected to radio!
2020-07-24 09:11:01.023 6478-6545/com.geeksville.mesh D/BluetoothGatt: refresh() - device: 24:62:AB:DD:DF:3A
2020-07-24 09:11:01.526 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: Enqueuing work: discover
2020-07-24 09:11:01.526 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth$BluetoothContinuation: Starting work: discover
2020-07-24 09:11:01.526 6478-6545/com.geeksville.mesh D/BluetoothGatt: discoverServices() - device: 24:62:AB:DD:DF:3A
2020-07-24 09:11:01.829 6478-27868/com.geeksville.mesh D/BluetoothGatt: onConnectionUpdated() - Device=24:62:AB:DD:DF:3A interval=6 latency=0 timeout=500 status=0
2020-07-24 09:11:02.008 6478-27868/com.geeksville.mesh D/BluetoothGatt: onSearchComplete() = Device=24:62:AB:DD:DF:3A Status=0
2020-07-24 09:11:02.009 6478-27868/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: work discover is completed, resuming status=0, res=kotlin.Unit
2020-07-24 09:11:02.009 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.BluetoothInterface: Discovered services!
2020-07-24 09:11:02.095 6478-27868/com.geeksville.mesh D/BluetoothGatt: onConnectionUpdated() - Device=24:62:AB:DD:DF:3A interval=36 latency=0 timeout=500 status=0
2020-07-24 09:11:03.010 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.RadioInterfaceService: Broadcasting connection=true
2020-07-24 09:11:03.012 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: Enqueuing work: readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5
2020-07-24 09:11:03.012 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth$BluetoothContinuation: Starting work: readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5
2020-07-24 09:11:03.012 6478-6478/com.geeksville.mesh D/com.geeksville.mesh.service.MeshService: Received broadcast com.geeksville.mesh.CONNECT_CHANGED
2020-07-24 09:11:03.012 6478-6478/com.geeksville.mesh D/com.geeksville.mesh.service.MeshService: onConnectionChanged=CONNECTED
2020-07-24 09:11:03.012 6478-6478/com.geeksville.mesh D/com.geeksville.mesh.service.MeshService: Starting config nonce=6878
2020-07-24 09:11:03.013 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.BluetoothInterface: queuing 4 bytes to f75c76d2-129e-4dad-a1dd-7866124401e7 *** sending start config
2020-07-24 09:11:03.013 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: Enqueuing work: writeC f75c76d2-129e-4dad-a1dd-7866124401e7
2020-07-24 09:11:03.015 6478-6478/com.geeksville.mesh D/com.geeksville.mesh.service.MeshService: Received broadcast com.geeksville.mesh.CONNECT_CHANGED
2020-07-24 09:11:03.015 6478-6478/com.geeksville.mesh D/com.geeksville.mesh.service.MeshService: onConnectionChanged=CONNECTED
2020-07-24 09:11:03.015 6478-6478/com.geeksville.mesh D/com.geeksville.mesh.service.MeshService: Starting config nonce=6877
2020-07-24 09:11:03.016 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.MeshService: device sleep timeout cancelled
2020-07-24 09:11:03.016 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.BluetoothInterface: queuing 4 bytes to f75c76d2-129e-4dad-a1dd-7866124401e7
2020-07-24 09:11:03.016 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: Enqueuing work: writeC f75c76d2-129e-4dad-a1dd-7866124401e7
2020-07-24 09:11:03.130 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth$BluetoothContinuation: Starting work: writeC f75c76d2-129e-4dad-a1dd-7866124401e7
2020-07-24 09:11:03.132 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: work readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5 is completed, resuming status=0, res=android.bluetooth.BluetoothGattCharacteristic@556a315
2020-07-24 09:11:03.132 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.BluetoothInterface: Done reading from radio, fromradio is empty
2020-07-24 09:11:03.132 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: starting setNotify(ed9da18c-a800-4f66-a670-aa7547e34453, true) *** start notify
2020-07-24 09:11:03.132 6478-19966/com.geeksville.mesh D/BluetoothGatt: setCharacteristicNotification() - uuid: ed9da18c-a800-4f66-a670-aa7547e34453 enable: true
2020-07-24 09:11:03.133 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: Enqueuing work: writeD
2020-07-24 09:11:03.220 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth$BluetoothContinuation: Starting work: writeC f75c76d2-129e-4dad-a1dd-7866124401e7
2020-07-24 09:11:03.221 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: work writeC f75c76d2-129e-4dad-a1dd-7866124401e7 is completed, resuming status=0, res=android.bluetooth.BluetoothGattCharacteristic@2d2062a
2020-07-24 09:11:03.221 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.BluetoothInterface: write of 4 bytes completed
2020-07-24 09:11:03.221 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: Enqueuing work: readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5
2020-07-24 09:11:03.310 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth$BluetoothContinuation: Starting work: writeD
2020-07-24 09:11:03.311 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: work writeC f75c76d2-129e-4dad-a1dd-7866124401e7 is completed, resuming status=0, res=android.bluetooth.BluetoothGattCharacteristic@2d2062a
2020-07-24 09:11:03.311 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.BluetoothInterface: write of 4 bytes completed
2020-07-24 09:11:03.400 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth$BluetoothContinuation: Starting work: readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5
2020-07-24 09:11:03.402 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: work writeD is completed, resuming status=0, res=android.bluetooth.BluetoothGattDescriptor@fc99c1b
2020-07-24 09:11:03.402 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: Notify enable=true completed
2020-07-24 09:11:03.769 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: work readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5 is completed, resuming status=0, res=android.bluetooth.BluetoothGattCharacteristic@556a315
2020-07-24 09:11:03.769 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.BluetoothInterface: Received 80 bytes from radio **** received an 80 byte fromradio. Why did we miss three previous reads?
2020-07-24 09:11:03.774 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: Enqueuing work: readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5
2020-07-24 09:11:03.774 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth$BluetoothContinuation: Starting work: readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5
2020-07-24 09:11:03.774 6478-6478/com.geeksville.mesh D/com.geeksville.mesh.service.MeshService: Received broadcast com.geeksville.mesh.RECEIVE_FROMRADIO
2020-07-24 09:11:03.776 6478-6478/com.geeksville.mesh E/com.geeksville.mesh.service.MeshService: Invalid Protobuf from radio, len=80 (exception Protocol message had invalid UTF-8.)
2020-07-24 09:11:03.776 6478-6478/com.geeksville.mesh D/com.geeksville.mesh.service.MeshService: Received broadcast com.geeksville.mesh.RECEIVE_FROMRADIO
2020-07-24 09:11:03.776 6478-6478/com.geeksville.mesh E/com.geeksville.mesh.service.MeshService: Invalid Protobuf from radio, len=80 (exception Protocol message had invalid UTF-8.)
2020-07-24 09:11:04.031 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: work readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5 is completed, resuming status=0, res=android.bluetooth.BluetoothGattCharacteristic@556a315
2020-07-24 09:11:04.031 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.BluetoothInterface: Received 52 bytes from radio *** received 52 bytes - where did the previous two read results go?
2020-07-24 09:11:04.033 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: Enqueuing work: readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5
2020-07-24 09:11:04.033 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth$BluetoothContinuation: Starting work: readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5
2020-07-24 09:11:04.034 6478-6478/com.geeksville.mesh D/com.geeksville.mesh.service.MeshService: Received broadcast com.geeksville.mesh.RECEIVE_FROMRADIO
2020-07-24 09:11:04.035 6478-6478/com.geeksville.mesh E/com.geeksville.mesh.service.MeshService: Invalid Protobuf from radio, len=52 (exception While parsing a protocol message, the input ended unexpectedly in the middle of a field. This could mean either that the input has been truncated or that an embedded message misreported its own length.)
2020-07-24 09:11:04.036 6478-6478/com.geeksville.mesh D/com.geeksville.mesh.service.MeshService: Received broadcast com.geeksville.mesh.RECEIVE_FROMRADIO
2020-07-24 09:11:04.036 6478-6478/com.geeksville.mesh E/com.geeksville.mesh.service.MeshService: Invalid Protobuf from radio, len=52 (exception While parsing a protocol message, the input ended unexpectedly in the middle of a field. This could mean either that the input has been truncated or that an embedded message misreported its own length.)
2020-07-24 09:11:04.210 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: work readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5 is completed, resuming status=7, res=android.bluetooth.BluetoothGattCharacteristic@556a315 *** read failed
2020-07-24 09:11:04.211 6478-19966/com.geeksville.mesh W/com.geeksville.mesh.service.BluetoothInterface: Scheduling reconnect because error during doReadFromRadio - disconnecting, Bluetooth status=7 while doing readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5
2020-07-24 09:11:04.211 6478-6545/com.geeksville.mesh W/com.geeksville.mesh.service.BluetoothInterface: Forcing disconnect and hopefully device will comeback (disabling forced refresh)
2020-07-24 09:11:04.211 6478-6545/com.geeksville.mesh I/com.geeksville.mesh.service.SafeBluetooth: Closing our GATT connection
2020-07-24 09:11:04.211 6478-6545/com.geeksville.mesh D/BluetoothGatt: cancelOpen() - device: 24:62:AB:DD:DF:3A
2020-07-24 09:11:04.214 6478-19966/com.geeksville.mesh D/BluetoothGatt: onClientConnectionState() - status=0 clientIf=4 device=24:62:AB:DD:DF:3A
2020-07-24 09:11:04.215 6478-19966/com.geeksville.mesh I/com.geeksville.mesh.service.SafeBluetooth: new bluetooth connection state 0, status 0
2020-07-24 09:11:04.215 6478-19966/com.geeksville.mesh I/com.geeksville.mesh.service.SafeBluetooth: Got disconnect because we are shutting down, closing gatt
2020-07-24 09:11:04.215 6478-19966/com.geeksville.mesh D/BluetoothGatt: close()