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

After 1 h flight the frequency jumped up to 14.111 :-( #10

Closed whallmann closed 6 months ago

whallmann commented 6 months ago

After one hour flight the hf-oszillator jumped after a short ping on 14.097 up to 14.111 for further transmissions. I am not ammused about this. image Also see the TX is now unstable. It looks the calculation of the TIMEPULSE has problems? The TX works well for many days on the ground. image

Appendix 1: Frequenz jumping maybe have some issue with temperatur? during lifoff the temp went down to reported -3 Celsius. After half an hour an TX was reported with upper 0 C. image

whallmann commented 6 months ago

i build a new one on the desk and o wonder, it is always transmitting on 14.111. So i decreased the 4 Frequency lines in the source code about 3 Hz down. Wow - now the frequency is on 14.097. Resetet the to the originally frequencies, and its back on 14.111. In my opinion thats not a temperature problem. Dont know how to get this fixed.

EngineerGuy314 commented 6 months ago

it seems like maybe a lack of PPS. if its getting serial data from the GPS module, it will continue to transmit on the correct timeslot. But without steady PPS pulses the frequency will vary greatly with temperature of the pico's crystal.

whallmann commented 6 months ago

Hi Loss of PPS maybe a reason, but i tried also with a shorter Cabel (3 cm) and i watched the same problem. The system worked with success over a week here on an outdoor vertikal. So i can not explain whats happens. Maybe the level of timepulse changing on temperature maybe the pico port sensibility gets lower on low temperatures. I dont know. I will not start any more until we find some method to get this fixed.

thanks for your attention

73 Wolf

EngineerGuy314 @.***> schrieb am Do., 9. Mai 2024, 18:45:

it seems like maybe a lack of PPS. if its getting serial data from the GPS module, it will continue to transmit on the correct timeslot. But without steady PPS pulses the frequency will vary greatly with temperature of the pico's crystal.

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

EngineerGuy314 commented 6 months ago

please try one more thing. Simon had similar problems that were fixed by removing some Print Statements. Set the verbosity to 0 (which will kill all prints) and see if the problem persists. thanks.

whallmann commented 6 months ago

Ok Thanks will test this, but for results we have to wait now until July (longer Holidays here ;-) cu 73

EngineerGuy314 @.***> schrieb am Do., 9. Mai 2024, 19:51:

please try one more thing. Simon had similar problems that were fixed by removing some Print Statements. Set the verbosity to 0 (which will kill all prints) and see if the problem persists. thanks.

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

serych commented 6 months ago

I had also problems with GPS during my tests two days ago. It saw about 10 to 12 satelites and after some minutes the number decreased rapidly to 6, 4 and 0 and GPS stopped to respond. When the RP2040 started to transmit my slot, GPS stopped to respond nearly immediately. So I suspect interference from the transmission itself or ripple in the supply voltage. I plan to add 100nF suppression capacitors between power supply and ground and see if there is an improvement.

Jakub, OK1SE

From: Antennen-Wolfgang @.> Sent: Thursday, May 9, 2024 6:58 PM To: EngineerGuy314/pico-WSPRer @.> Cc: Subscribed @.***> Subject: Re: [EngineerGuy314/pico-WSPRer] After 1 h flight the frequency jumped up to 14.111 :-( (Issue #10)

Hi Loss of PPS maybe a reason, but i tried also with a shorter Cabel (3 cm) and i watched the same problem. The system worked with success over a week here on an outdoor vertikal. So i can not explain whats happens. Maybe the level of timepulse changing on temperature maybe the pico port sensibility gets lower on low temperatures. I dont know. I will not start any more until we find some method to get this fixed.

thanks for your attention

73 Wolf

EngineerGuy314 @.<mailto:@.>> schrieb am Do., 9. Mai 2024, 18:45:

it seems like maybe a lack of PPS. if its getting serial data from the GPS module, it will continue to transmit on the correct timeslot. But without steady PPS pulses the frequency will vary greatly with temperature of the pico's crystal.

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

— Reply to this email directly, view it on GitHubhttps://github.com/EngineerGuy314/pico-WSPRer/issues/10#issuecomment-2103049481, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADCVHZH22H322YXQRMWUTPLZBOTKRAVCNFSM6AAAAABHOQX22GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBTGA2DSNBYGE. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>

whallmann commented 6 months ago

Here are some news about jumping in frequency First: i am using the today version - sure! Tested to day over 3 hours. I am connected with usb and the "screen" cmd on debian. Parallel i watched the kiwisdr at my location. First thing: i saw on 14.112 that the hf-osz. is working in stdby at very low level. TX on board is not transmitting on trace Every TXing the 14.112 was used. Signal is unstable so no decodings on the kiwisdr. No chance to get the tx qrg on 14.097

What i then see may be interessting. I pluged the pico on usb again and did not start the screen communicator. This thime i see on the sdr no hf-osz. standby signal. The hf-osz. signal also not visible on 14.097 nor 14.112 until iam starting the screen programm. This time the 14.112 is aquired and later the tx is sending here. Other way: if iam not starting screen-prg then later the pico is really tx-ing ong 14.097 - wow. first time its on the right QRG.

Condx: Verbose was allways on 0. No screen programm was started if its qrg is ok, after one time screen prg was called and closed the QRG still stands on 14.112 if tx-ing.

BTW: there are new problems - maybe i open another issue

EngineerGuy314 commented 6 months ago

after 8 hours, i found a math bug in some of the original code. it turns out that compensating for a fast xtal was ok, but on another pico with a xtal that happened to be slower i was seeing an incorrect freq output above 14.1mhz. fix has been implemented and pushed.

EngineerGuy314 commented 6 months ago

some more details: the problem was occurring with boards whose crystal was giving less than exactly 12Mhz. Some picos are like that, but on others I was able to make a a normally good pico exhibit the jump to 14.1Mhz by heating it up enough to reduce crystal frequency below 12Mhz.

on line 90 of GPStime.c Roman was using iSar64 to do bit shifting. The macro for iSar typecasts the argument as int64_t. But a part of the argument used _u64_pps_period_1M, which is an unsigned int. If that number was greater than eDtUpscale * dt_per_window the overall argument to iSar64 was negative and there would be a problem.

I changed the definition of _u64_pps_period_1M from uint64 to int64 and that seems to have solved the problem. I am not exactly sure why that was needed, or if there was a better way to fix it.

serych commented 6 months ago

WOW! Great! Just now I am analysing that part of code which seems to be the core of the pico GPSDO. I would like to clearly document it soon.

Jakub

From: EngineerGuy314 @.> Sent: Saturday, May 11, 2024 1:30 AM To: EngineerGuy314/pico-WSPRer @.> Cc: Šerých Jakub @.>; Comment @.> Subject: Re: [EngineerGuy314/pico-WSPRer] After 1 h flight the frequency jumped up to 14.111 :-( (Issue #10)

some more details: the problem was occurring with boards whose crystal was giving less than exactly 12Mhz. Some picos are like that, but on others I was able to make a a normally good pico exhibit the jump to 14.1Mhz by heating it up enough to reduce crystal frequency below 12Mhz.

on line 90 of GPStime.c Roman was using iSar64 to do bit shifting. The macro for iSar typecasts the argument as int64_t. But a part of the argument used _u64_pps_period_1M, which is an unsigned int. If that number was greater than eDtUpscale * dt_per_window the overall argument to iSar64 was negative and there would be a problem.

I changed the definition of _u64_pps_period_1M from uint64 to int64 and that seems to have solved the problem. I am not exactly sure why that was needed, or if there was a better way to fix it.

— Reply to this email directly, view it on GitHubhttps://github.com/EngineerGuy314/pico-WSPRer/issues/10#issuecomment-2105379873, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADCVHZHTZNJEYEQXGHR5JALZBVJ67AVCNFSM6AAAAABHOQX22GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBVGM3TSOBXGM. You are receiving this because you commented.Message ID: @.**@.>>

whallmann commented 6 months ago

Oh my goodness, you are great!

Thanks for you time to dive into the code so deep. I may check this version today on this test Board and will report soon.

best 73 Wolf

EngineerGuy314 @.***> schrieb am Sa., 11. Mai 2024, 01:29:

some more details: the problem was occurring with boards whose crystal was giving less than exactly 12Mhz. Some picos are like that, but on others I was able to make a a normally good pico exhibit the jump to 14.1Mhz by heating it up enough to reduce crystal frequency below 12Mhz.

on line 90 of GPStime.c Roman was using iSar64 to do bit shifting. The macro for iSar typecasts the argument as int64_t. But a part of the argument used _u64_pps_period_1M, which is an unsigned int. If that number was greater than eDtUpscale * dt_per_window the overall argument to iSar64 was negative and there would be a problem.

I changed the definition of _u64_pps_period_1M from uint64 to int64 and that seems to have solved the problem. I am not exactly sure why that was needed, or if there was a better way to fix it.

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