diff --git a/docs/faq.md b/docs/faq.md index c7d7a118e3..e53d3a4d93 100644 --- a/docs/faq.md +++ b/docs/faq.md @@ -691,23 +691,28 @@ You can get the epoch time on and use it to set ### 6.6. Q: My Heltec V3 keeps disconnecting from my smartphone. It can't hold a solid Bluetooth connection. **A:** Heltec V3 has a very small coil antenna on its PCB for Wi-Fi and Bluetooth connectivity. It has a very short range, only a few feet. It is possible to remove the coil antenna and replace it with a 31mm wire. The BT range is much improved with the modification. -### 6.7. Q: My RAK/T1000-E/xiao_nRF52 device seems to be corrupted, how do I wipe it clean to start fresh? -**A:** - -1. Connect USB-C cable to your device, per your device's instruction, get it to flash mode: - - For RAK, click the reset button **TWICE** - - For T1000-e, quickly disconnect and reconnect the magnetic side of the cable from the device **TWICE** - - For Heltec T114, click the reset button **TWICE** (the bottom button) - - For Xiao nRF52, click the reset button once. If that doesn't work, quickly double-click the reset button twice. If that doesn't work, disconnect the board from your PC and reconnect again ([seeed studio wiki](https://wiki.seeedstudio.com/XIAO_BLE/#access-the-swd-pins-for-debugging-and-reflashing-bootloader)) -2. A new folder will appear on your computer's desktop -3. Download the `flash_erase*.uf2` file for your device on - - RAK WisBlock and Heltec T114: `Flash_erase-nRF32_softdevice_v6.uf2` - - Seeed Studio Xiao nRF52 WIO: `Flash_erase-nRF52_softdevice_v7.uf2` -4. drag and drop the uf2 file for your device to the root of the new folder -5. Wait for the copy to complete. You might get an error dialog, you can ignore it -6. Go to , click `Console` and select the serial port for your connected device -7. In the console, press enter. Your flash should now be erased -8. You may now flash the latest MeshCore firmware onto your device +### 6.7. Q: My RAK/T1000-E/xiao_nRF52/... device seems to be corrupted, how do I wipe it clean to start fresh? +**A: If you're able to connect to the device from your MeshCore app** +1. Navigate to Gear icon(Settings) on the upper right corner +2. Click on `Export Settings` button, choose `Select All` and Confirm. This will save your Node configuration +3. Now choose `Factory Reset` option +4. Confirm that you want to reset your device +5. Go to Bluetooth System settings and remove pairing of the device, so you can connect again +6. Connect your device in the app and enter the PIN +7. Navigate to Gear icon(Settings) on the upper right corner +8. Click on `Import Settings` and choose the file from 2., click on `Select All` and Confirm +9. Find `Reboot` button on of the Settings list + +**B: You're not able to connect to the App** +1. Connect USB cable to your device +2. Go to https://flasher.meshcore.io +3. Search for your device in the list +4. Choose `Companion Bluetooth` +5. Press `Enter DFU mode` button, choose your USB device +6. Press `Erase Flash` button, choose the device again and wait until it completes +7. Press `Flash!` button and choose the USB device last time +8. The device is erased and newest firmware is installed +9. You might need to remove the pairing in Bluetooth System Settings in order to re-pair the app again. Separately, starting in firmware version 1.7.0, there is a CLI Rescue mode. If your device has a user button (e.g. some RAK, T114), you can activate the rescue mode by holding down the user button of the device within 8 seconds of boot. Then you can use the 'Console' on @@ -716,9 +721,9 @@ Separately, starting in firmware version 1.7.0, there is a CLI Rescue mode. If y `NetworkError: Failed to execute 'open' on 'SerialPort': Failed to open serial port.` -Allow the browser user on it: +Allow user access on your USB port: -`# setfacl -m u:YOUR_USER_HERE:rw /dev/ttyUSB0` +`sudo setfacl -m u:$USER:rw /dev/ttyUSB0` --- diff --git a/docs/kiss_modem_protocol.md b/docs/kiss_modem_protocol.md index 3f4dbf9c4b..7ff4878684 100644 --- a/docs/kiss_modem_protocol.md +++ b/docs/kiss_modem_protocol.md @@ -18,10 +18,10 @@ Standard KISS framing per the KA9Q/K3MC specification. | `0xDD` | TFESC | Escaped FESC (FESC + TFESC = 0xDB) | ``` -┌──────┬───────────┬──────────────┬──────┐ -│ FEND │ Type Byte │ Data (escaped)│ FEND │ -│ 0xC0 │ 1 byte │ 0-510 bytes │ 0xC0 │ -└──────┴───────────┴──────────────┴──────┘ +┌──────┬───────────┬────────────────┬──────┐ +│ FEND │ Type Byte │ Data (escaped) │ FEND │ +│ 0xC0 │ 1 byte │ 0-510 bytes │ 0xC0 │ +└──────┴───────────┴────────────────┴──────┘ ``` ### Type Byte @@ -82,10 +82,10 @@ MeshCore-specific functionality uses the standard KISS SetHardware command. The ### Frame Format ``` -┌──────┬──────┬─────────────┬──────────────┬──────┐ -│ FEND │ 0x06 │ Sub-command │ Data (escaped)│ FEND │ -│ 0xC0 │ │ 1 byte │ variable │ 0xC0 │ -└──────┴──────┴─────────────┴──────────────┴──────┘ +┌──────┬──────┬─────────────┬────────────────┬──────┐ +│ FEND │ 0x06 │ Sub-command │ Data (escaped) │ FEND │ +│ 0xC0 │ │ 1 byte │ variable │ 0xC0 │ +└──────┴──────┴─────────────┴────────────────┴──────┘ ``` ### Request Sub-commands (Host to TNC) diff --git a/docs/radio_presets.md b/docs/radio_presets.md new file mode 100644 index 0000000000..ea3b07e51f --- /dev/null +++ b/docs/radio_presets.md @@ -0,0 +1,66 @@ +# Radio Presets + +The radio presets are currently stored on the MeshCore App API server. + +This allows us to update the presets without releasing new application updates. + +The presets can be fetched from [https://api.meshcore.nz/api/v1/config](https://api.meshcore.nz/api/v1/config) + +If you'd like a new radio preset to be added, this will need to be brought up for discussion in the [MeshCore Discord](https://meshcore.gg) server, or via the [issues section](https://github.com/meshcore-dev/MeshCore/issues) in our GitHub repo. + +Before a new preset will be considered for being added, local radio regulations must be researched by the person suggesting the preset, and investigation of the frequencies with an SDR is advised to ensure the least interference to provide a decent user experience. + +Once a preset is added, it's unlikely to be changed. Adding too many presets can lead to user frustration, as new users won't know which preset to select during setup. + +At this time, presets provided by the MeshCore App API are just suggestions, but you are free to configure any radio settings through the companion applications, provided they comply with local laws/regulations. + +> Note: We are planning to implement deep linking such as meshcore:// URLs, and QR codes so local mesh networks can easily distribute their own settings, without relying on the internet, or all the companion applications to provide all the settings. + +## JSON Response + +See the example JSON response below, which shows the expected format provided by the API server. + +Your application should be programmed to expect any of the JSON keys to be missing from the response, as the format could change at any time without any notification. + +Please configure an appropriate User Agent header string when sending your request to the server. We should be able to reach out to you if needed. + +> Note: Some presets contain an optional `network_settings` section which defines the `path_hash_size` to use for this mesh network. + +```json +{ + "config": { + "suggested_radio_settings": { + "info_message": "These presets are suggested by the community.", + "entries": [ + { + "title": "Australia (Narrow)", + "description": "916.575MHz / SF7 / BW62.5 / CR7", + "frequency": "916.575", + "spreading_factor": "7", + "bandwidth": "62.5", + "coding_rate": "7" + }, + { + "title": "New Zealand (Narrow)", + "description": "917.375MHz / SF7 / BW62.5 / CR5 / 2B", + "frequency": "917.375", + "spreading_factor": "7", + "bandwidth": "62.5", + "coding_rate": "5", + "network_settings": { + "path_hash_size": 2 + } + }, + { + "title": "Portugal 868", + "description": "869.618MHz / SF7 / BW62.5 / CR6", + "frequency": "869.618", + "spreading_factor": "7", + "bandwidth": "62.5", + "coding_rate": "6" + } + ] + } + } +} +``` \ No newline at end of file diff --git a/variants/thinknode_m3/ThinkNodeM3Board.cpp b/variants/thinknode_m3/ThinkNodeM3Board.cpp index ac513ade5b..f42206a259 100644 --- a/variants/thinknode_m3/ThinkNodeM3Board.cpp +++ b/variants/thinknode_m3/ThinkNodeM3Board.cpp @@ -13,6 +13,46 @@ void ThinkNodeM3Board::begin() { delay(10); // give sx1262 some time to power up } +void ThinkNodeM3Board::shutdownPeripherals() { + NRF52Board::shutdownPeripherals(); // display, LoRa radio and GNSS receiver + + // GPIO output latches survive SYSTEMOFF, so every switched rail still enabled + // here keeps draining the battery while the board looks powered off + digitalWrite(PIN_GPS_POWER, !GPS_POWER_ACTIVE); + digitalWrite(LED_POWER, LOW); // RGB led supply + digitalWrite(EEPROM_POWER, LOW); + digitalWrite(BAT_POWER, LOW); // battery voltage divider + digitalWrite(PIN_EN1, LOW); + digitalWrite(PIN_EN2, LOW); + digitalWrite(PIN_PWR_EN, LOW); +} + +void ThinkNodeM3Board::powerOff() { + // turn off all leds, sd_power_system_off will not do this for us + digitalWrite(PIN_LED_BLUE, !LED_STATE_ON); + digitalWrite(PIN_LED_GREEN, !LED_STATE_ON); + digitalWrite(PIN_LED_RED, !LED_STATE_ON); + + // the button is what powers the board back on, and SENSE is level triggered: + // wait for the release, or the board wakes up as soon as it goes SYSTEMOFF + uint32_t started_at = millis(); + uint32_t released_at = started_at; + while (millis() - released_at < 50) { // require a continuously released button + uint32_t now = millis(); + if (digitalRead(BUTTON_PIN) == LOW) { + released_at = now; + } + if (now - started_at > 10000) { // button held down for too long, or stuck: + reboot(); // SYSTEMOFF would wake up right away anyway + } + delay(10); + } + nrf_gpio_cfg_sense_input(g_ADigitalPinMap[BUTTON_PIN], NRF_GPIO_PIN_PULLUP, NRF_GPIO_PIN_SENSE_LOW); + + // power off board + NRF52Board::powerOff(); +} + uint16_t ThinkNodeM3Board::getBattMilliVolts() { int adcvalue = 0; diff --git a/variants/thinknode_m3/ThinkNodeM3Board.h b/variants/thinknode_m3/ThinkNodeM3Board.h index 9e8f49894d..821bb82880 100644 --- a/variants/thinknode_m3/ThinkNodeM3Board.h +++ b/variants/thinknode_m3/ThinkNodeM3Board.h @@ -42,13 +42,6 @@ class ThinkNodeM3Board : public NRF52BoardDCDC { return 0; } - void powerOff() override { - // turn off all leds, sd_power_system_off will not do this for us - digitalWrite(PIN_LED_BLUE, !LED_STATE_ON); - digitalWrite(PIN_LED_GREEN, !LED_STATE_ON); - digitalWrite(PIN_LED_RED, !LED_STATE_ON); - - // power off board - NRF52Board::powerOff(); - } + void shutdownPeripherals() override; + void powerOff() override; }; diff --git a/variants/thinknode_m3/variant.cpp b/variants/thinknode_m3/variant.cpp index b47b83543d..c384a1fb9b 100644 --- a/variants/thinknode_m3/variant.cpp +++ b/variants/thinknode_m3/variant.cpp @@ -71,10 +71,10 @@ void initVariant() pinMode(EEPROM_POWER, OUTPUT); digitalWrite(EEPROM_POWER, HIGH); - pinMode(36, OUTPUT); - digitalWrite(36, HIGH); - pinMode(34, OUTPUT); - digitalWrite(34, HIGH); + pinMode(PIN_EN1, OUTPUT); + digitalWrite(PIN_EN1, HIGH); + pinMode(PIN_EN2, OUTPUT); + digitalWrite(PIN_EN2, HIGH); pinMode(LED_POWER, OUTPUT); digitalWrite(LED_POWER, HIGH); diff --git a/variants/thinknode_m3/variant.h b/variants/thinknode_m3/variant.h index 78dfab85d9..08f7580ce5 100644 --- a/variants/thinknode_m3/variant.h +++ b/variants/thinknode_m3/variant.h @@ -42,6 +42,8 @@ #define EEPROM_POWER (7) #define BAT_POWER (17) #define PIN_PWR_EN (16) +#define PIN_EN1 (36) // P1.4, buzzer supply +#define PIN_EN2 (34) // P1.2 ////////////////////////////////////////////////////////////////////////////////