beacon period does not survive reboot

[deafboy]

beacon period setting is not persistent.

[paidforby]

Hmmm, this is a very odd problem. Everything looks right in the code,

What board are you using? I'm using a TTGO-Tbeam v7. The setting seems to be persisting for me, though the GPS antenna is a little unreliable (especially after I pull power, but less so after /restart or pressing the reset button). My guess is that you are seeing a "false negative", that is, if the GPS does not successfully retrieve a lat-long value, then nothing is ever printed to the console, so it would look like the beaconPeriod setting did not persist (if say you changed it from 0 to 10000).

I'll add some more printing to the console that should help debug your setup. (And soon will also add a setting to toggle GPS debug printing to the console)

Let me know is your issue persists :p after I make my commit

[deafboy]

ttgo-lora32-v1 and ttgo-lora32-v2. Both without GPS capability. Maybe I misunderstood and it's not supposed to work without GPS ? :) d1601d9 did not help

/get config Current LoRa Config Local Addr: abfa0cfc Initialized: 1 CS, RST, DIO: 18, 14, 26 SPI Freq: 100000 LoRa Freq: 868000000 SF: 9 TxPwr: 17 Routing mode: manual Duty Cycle: 0.100000 /set interval 60000 Routing mode set to `auto`, interval of routing table messages set to 60000 /get config Current LoRa Config Local Addr: abfa0cfc Initialized: 1 CS, RST, DIO: 18, 14, 26 SPI Freq: 100000 LoRa Freq: 868000000 SF: 9 TxPwr: 17 Routing mode: auto Routing interval: 60000ms Duty Cycle: 0.100000 /restart ets Jun 8 2016 00:22:57 rst:0xc (SW_CPU_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:1044 load:0x40078000,len:8896 load:0x40080400,len:5828 entry 0x400806ac Got username new Got IF setting BLE Got txPwr setting 17 Got loraFrq setting 868 Got sf setting 9 [E][Preferences.cpp:457] getBytesLength(): nvs_get_blob len fail: duty NOT_FOUND Got duty setting 0.100000 Got interval setting 60000 Got gps setting 0 * Initializing SPIFFS... * Initializing history... --> Storing (limited) history in memory * Initializing serial... * Initializing BLE... * Initializing LoRa... --> Layer1 init succeeded --> LL2 init succeeded Current LoRa Config Local Addr: abfa0cfc Initialized: 1 CS, RST, DIO: 18, 14, 26 SPI Freq: 100000 LoRa Freq: 868000000 SF: 9 TxPwr: 17 Routing mode: manual Duty Cycle: 0.100000 * Initializing display... WelcomeMessage username: >new<

[paidforby]

Oh, you are talking about the routing table message broadcast/beacon interval, not the GPS becaon period. Very confusing. I knew I should have made those commands more distinct. Yes, that should definitely work without GPS. It looks like it is being stored in the memory, see line after reboot that reads, Got interval setting 60000. Maybe it isn't getting passed to the LL2 client correctly, or maybe the /get config print out is just wrong. Have you confirmed that two nodes do not automatically get routes to one another after /set interval VAL and /restart? Use /lora to check the routing table.

I'll take a closer look at this tonight.`

[paidforby]

Found the problem, a stray default config in LoRaClient.cpp that was always resetting the interval right after it was set in main.ino. Sorry about that.

Also, be on the watch for a name change to that "interval" command so we can avoid future confusion with other intervals. (probably will change it to something like "routing" or "ll2" so it's more specific and could be expanded to accept other LL2 setting.)