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
50 stars 9 forks source link

No matter which callsign I put (currently: 9A4GE), when it emit 6 figure grid, it is WB0KWJ, why? #8

Closed WildMany closed 6 months ago

WildMany commented 6 months ago

LU7AA will NOT accept only 4 figures gridsquare, and when RPi Pico emits 6 figures gridsquare, callsign changes from 9A4GE to WB0KWJ. I am unable to find where is the error. Tracker is set as U4B, Lane 1, minute 8, ID13 Q9.

Tell me how to rectify that problem. 73, Milan, 9A4GE

image

P.S. This is not the only problem. If there are no GPS fix, it should NOT emit, but it emits something weird: image

EngineerGuy314 commented 6 months ago

Hello WildMany,

Interesting problems, I will gladly help get to the bottom of it.

Tracker is set as U4B

So you only want it to transmit U4b, and not the Zachtek protocol? To disable the Zachtek protocol you must enter a single - (a single minus sign) into the Suffix setting of the user config menu. (I know the interface is a bit clumsy and not well documented, i am working on that).

Your data indicates that it is trying to do both protocols right now. U4b on minute 8 and 0, a 2 minute rest, and then zachtek protocol on minute 4 and 6. so i surmise you didnt disable zachtek mode.

Short answer: it is correctly sending the U4B info, but incorrectly sending the zachtek protocol (if you only want to do U4B, then just disable zachtek with a - in the suffix and you are done).

The two U4B packets it sent are (at minute 8) your callsign and 4 char grid. (that is correct, u4b only encodes the last 2 chars in the second message). The second U4B messages, at minute 0, is QD9MTC at locator OL15 and power 7. If you type that into Doug's decoder at https://traquito.github.io/pro/decode you get this: image This conveys the last two grid chars (JG) your altitude of 0, 24 degrees C, and 4.8 volts.

regarding the incorrect zachtek info, first thing I noticed is that it shows a two character suffix (/12). I only have a single character of memory used to store the suffix, so how is this possible? I wonder if its because you have a 5 char callsign, and I only tested with a 6 charactecter callsign? This is a legitimate bug that I need to look into on my end, thank you for bringing it to my attention. this bug may also account for the strange BB00JG you saw.

i will get back to you shortly

EngineerGuy314 commented 6 months ago

ok, just did a test on my end, and 5 character callsign is not a problem.

If the suffix was blank, that means it probably had some unprintable character in there, that was garbage from reading uninitialized NVRAM.

I need to add some plausibility checks for bad data.

but for now, please configure the suffix with either a minus (-) or a single numeric digit. Let me know if that fixes it.

WildMany commented 6 months ago

Yes, it is configured with '-' as a suffix: image Is it correct if I want only U4B protocol?

73, Milan, 9A4GE

P.S. Tried it again and something strange happened; during waiting for GPS fix, it says "Content: AA22" where instead there are two symbols like three fields, top, middle, bottom. After getting GPS fix, I am unable to replicate that error.

EngineerGuy314 commented 6 months ago

Is it correct if I want only U4B protocol? yes, that should be the correct way to make sure only U4B protocol is used. But apparently its not working. I will check for a bug.

EngineerGuy314 commented 6 months ago

I found the mistake, it should fine now. thank you.