search

cfr34k / t-echo-lora-aprs

LoRa-APRS firmware for the Lilygo T-Echo
Other
24 stars 4 forks source link

Advanced Settings "Error: could not read setting #7. subsection not found" #23

Open SheepiAnna opened 2 months ago

SheepiAnna commented 2 months ago

Hello! Thank you for creating this firmware. I tested this on both a Mac and Linux computer and had similar issues.

In the Python-based client, once I reach the main menu, and hit "a," it responds with

Main menu

0 = Show configuration 1 = Set source call 2 = Set comment 3 = Set symbol a = Advanced configuration q = Disconnect and quit. Type the entry number: a

Advanced settings menu

Updating settings cache... 86 % loaded. Error: could not read setting #7. 100 % loaded.

Current configuration: 1 SOURCE_CALL [ ] -> TEST 2 SYMBOL_CODE [ ] -> /. 3 COMMENT [ ] -> this is a test. 4 LORA_POWER [ ] -> 10 dBm 5 APRS_FLAGS [ ] -> 0x00000004 subsection not found Disconnected.

On my Mac is says the above ^ "could not read setting #7." and on the Linux, it just fails to enter the advanced config and disconnects immediately without details.

Otherwise entering and changing options 0,1,2,3 works fine.

I also tried with the nRF connect app, by entering 0x07 0xc0 0xca 0x89 0x36 (to configure to 950mHz) into the 00000111-B493.. characteristic but it rejected it IMG_4932

Thanks, Anna

cfr34k commented 2 months ago

Hello Anna,

I think the problem with the Python client may be that the frequency was never set on your device and the script crashes because of that. I've just pushed a new version that hopefully catches this and also prints a more useful stacktrace in case something still goes wrong. Can you try that version, please?

The value you are trying to write using nRF Connect should work in principle (however, you are setting 915 MHz, not 950). If the write is not accepted, your phone and the T-Echo are probably not bonded. I don't know the iOS version of nRF Connect, but the Android version has a “Bond” menu item on the top right which starts the process. You should then be asked to enter a code that is displayed by the T-Echo. Afterwards you should be able to access the characteristic.

Let me know if that helps.

Thomas DL5TKL

SheepiAnna commented 2 months ago

Hello Thomas!



Your modifications led us to discover the core problem. Turns out that the return value for 
LAST_BLE_SYMBOL was bytearray(b'/bag') and did not have 0 in it so index(0) could not find it.


After we used find instead of index method, we saw the whole printout as follows (with extra prints we added for debugging), including the [None] for frequency, which you helpfully provided:


After that, we stumbled a little because we didn’t realize we had to hit “w” to save the modified settings :) oops!

Now the frequency has been set successfully! Thank you!

cfr34k commented 2 months ago

Thanks for so quickly debugging this further! As I can't reproduce it here so far, I'd appreciate if you could send me a patch of your working version.

I wonder if the extra characters in LAST_BLE_SYMBOL are the result of a firmware bug. The internal settings storage works on 4-byte granularity. As far as I can see, only the first two bytes are written for LAST_BLE_SYMBOL and the remaining two bytes are uninitialized, which could result in the "/bag" that you see. But for some reason, the string seems to be always zero-padded on my device.

I'll look into this further and leave this issue open for now.