search

EngineerGuy314 / pico-WSPRer

Minimalist WSPR tracker for pico-balloons utilizing Raspberry Pi Pico (or Rp2040) as the RF generator (aka The Cheapest Tracker In The World™). More info: [WIKI](https://github.com/EngineerGuy314/pico-WSPRer/wiki/pico%E2%80%90WSPRer-(aka-Cheapest-Tracker-in-the-World%E2%84%A2))
MIT License
38 stars 6 forks source link

Values set per cmd line get lost after disconnect power. #28

Closed whallmann closed 1 month ago

whallmann commented 2 months ago

I watched this here since some versions. i set the values via cmd connected via the screen cmd. pushed return. Set all values as ever, send X to leave this. Connected again and still see all settings as left. Then power of the pi.

Next day powered it on and i wounder why it is not transmitting. Checked again per screen cmd and see only the default values. My only way is to modifiy the source code in read_NVM and set fixed settings into the values. This works as new default. Any ideas? is this only my problem? Used original raspi pico, no clones. So the precomiled bins are not usefull for me. 73 Wolfgang

EngineerGuy314 commented 2 months ago

I have not heard of anyone else experiencing this yet.

My only idea so far is to mention that (as long as you connect quickly enough) it will do a hexdump to the terminal of the NVRAM when it boots. So configure the settings via command line, and press to X to reboot. Re-connect the serial terminal quickly and screenshot the dump. Repeat that after a power cycle and see if the raw dump looks any different. It will be interesting to see if if maybe it is reading all zeroes, or garbled data,

whallmann commented 2 months ago

Ok, i will aquire this infomation and be back with this.

EngineerGuy314 @.***> schrieb am Mo., 22. Juli 2024, 05:14:

I have not heard of anyone else experiencing this yet.

My only idea so far is to mention that (as long as you connect quickly enough) it will do a hexdump to the terminal of the NVRAM when it boots. So configure the settings via command line, and press to X to reboot. Re-connect the serial terminal quickly and screenshot the dump. Repeat that after a power cycle and see if the raw dump looks any different. It will be interesting to see if if maybe it is reading all zeroes, or garbled data,

— Reply to this email directly, view it on GitHub https://github.com/EngineerGuy314/pico-WSPRer/issues/28#issuecomment-2241961991, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKZWUENSGXNXHFEBYMVEEDZNR2KZAVCNFSM6AAAAABLA5OF5GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBRHE3DCOJZGE . You are receiving this because you authored the thread.Message ID: @.***>

EngineerGuy314 commented 1 month ago

I just realized that I have experienced this 2 or 3 times. (they were on custom PCB boards, and I had already snapped off the USB connector, so I had just assumed something else had gone wrong, and tossed them aside).

I will start digging into this. I am open to ideas.

whallmann commented 1 month ago

Just yesterday i done some research. I set all Data and disconnected the usb cable after this. Then started with usb power after a Minute. All Data was recovered successfull from nvram. Then let all power off and started next day again. Now the call was set back to abc123 but the other values were restored successfull. This needs some more investigation. Will report soon.

EngineerGuy314 @.***> schrieb am Mo., 5. Aug. 2024, 20:16:

I just realized that I have experienced this 2 or 3 times. (they were on custom PCB boards, and I had already snapped off the USB connector, so I had just assumed something else had gone wrong, and tossed them aside).

I will start digging into this. I am open to ideas.

— Reply to this email directly, view it on GitHub https://github.com/EngineerGuy314/pico-WSPRer/issues/28#issuecomment-2269638192, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKZWUBUTUJ32OM6LDHQ3J3ZP66QVAVCNFSM6AAAAABLA5OF5GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRZGYZTQMJZGI . You are receiving this because you authored the thread.Message ID: @.***>

EngineerGuy314 commented 1 month ago

I've been doing some testing, and it seems on very rare occasion, for reasons i cannot understand, it will read shifted or corrupted data from the NVRAM (the data in the NVRAM itself isn't corrupted though). By design, as soon as the NVRAM is read, it runs the same feasibility-checking it does whenever you enter values from the user setup menu, and replaces any bad data with defaults, which obviously will ruin the flight. I need it to work that way so that when you first load the program into a new pico, it won't try to run the program with crazy data.

But I think the best way to fix this is that on power-up, it checks for good data. If it finds any bad data, instead of replacing it with defaults, it just pauses 10 seconds, then reboots. After reboot it will probably read the values correctly.

The 10 second delay is needed in case you are running the program on a brand new pico, the 10 seconds will give you a chance to enter the user-setup menu.

I suppose there is still a small chance that it reads corrupted data that is bad but still passes the feasibility check. In that case, at worst, the tracker will only be out of commission until the following dawn, when it will presumably read the data correctly.

whallmann commented 1 month ago

That sound as a very good soloution. If implemented i will check it here. Unfortunelly my test object just started yesterday. Have to solder a new one first. 🙃

EngineerGuy314 @.***> schrieb am Di., 6. Aug. 2024, 05:15:

I've been doing some testing, and it seems on very rare occasion, for reasons i cannot understand, it will read shifted or corrupted data from the NVRAM (the data in the NVRAM itself isn't corrupted though). By design, as soon as the NVRAM is read, it runs the same feasibility-checking it does whenever you enter values from the user setup menu, and replaces any bad data with defaults, which obviously will ruin the flight. I need it to work that way so that when you first load the program into a new pico, it won't try to run the program with crazy data.

But I think the best way to fix this is that on power-up, it checks for good data. If it finds any bad data, instead of replacing it with defaults, it just pauses 10 seconds, then reboots. After reboot it will probably read the values correctly.

The 10 second delay is needed in case you are running the program on a brand new pico, the 10 seconds will give you a chance to enter the user-setup menu.

I suppose there is still a small chance that it reads corrupted data that is bad but still passes the feasibility check. In that case, at worst, the tracker will only be out of commission until the following dawn, when it will presumably read the data correctly.

— Reply to this email directly, view it on GitHub https://github.com/EngineerGuy314/pico-WSPRer/issues/28#issuecomment-2270303339, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKZWUDBEKLUVA3TP75FSRTZQA5WVAVCNFSM6AAAAABLA5OF5GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZQGMYDGMZTHE . You are receiving this because you authored the thread.Message ID: @.***>

EngineerGuy314 commented 1 month ago

ok, I made the change. If bad data is read it will reboot after 10 seconds. This will continue until good data is read, or the user enters the setup menu