Open ra1nb0w opened 11 months ago
Dear ra1nb0w,
Thank you for your attention to the project!
You've proposed an interesting direction of further development. Definitely, such way of time sync is good for WSPR sending schedule, but I'm afraid it is unsuitable for carrier frequency correction, which require more precise source such as PPS leg of GPS receiver.
You might know that since release 1.0 the project covers frequency range up to ~32 MHz. Tests have shown that the frequency drift is often too large on these frequencies when running standalone, without GPS receiver, especially during the board heating up.
Nevertheless, your proposal definitely deserves attention. I'll look at Pico W NTP solutions available here.
Cheers, Roman 73 & 72 de R2BDY
Dear ra1nb0w,
Thank you for your attention to the project!
You've proposed an interesting direction of further development. Definitely, such way of time sync is good for WSPR sending schedule, but I'm afraid it is unsuitable for carrier frequency correction, which require more precise source such as PPS leg of GPS receiver.
You might know that since release 1.0 the project covers frequency range up to ~32 MHz. Tests have shown that the frequency drift is often too large on these frequencies when running standalone, without GPS receiver, especially during the board heating up.
Nevertheless, your proposal definitely deserves attention. I'll look at Pico W NTP solutions available here.
Cheers, Roman 73 & 72 de R2BDY
Hello and thanks for this great project. I had a question, I wanted to know if it is possible to use AC sinewave signal instead of GPS?
thanks.
Hi ErfanDL,
Thank you for your question about the project.
It is possible for majority of such external oscillator (TCXO) types. Fortunately I possess a number of obsolete TXO4080 TCXO's (Rakon, 10 MHz). I'll try to devise a frequency locked loop based on this TCXO signal, that's quite simple. However some schematic will be required to match TCXO output to Pico's GPIO input (I suppose two resistors will be sufficient). TCXO will be an additional option, the good one is often more valuable than GPS receiver.
Cheers, Roman 73 & 72 de R2BDY
Hi Roman, thanks for this neat work, I built and tried it, very nice. I agree a 10 MHz reference input would be useful. I've found a 3.3 v microcontroller (TVB PicDiv) is quite happy driven with 7 dBm or less, decoupled with a capacitor and then biased to 1.7 V with two resistors. Is it possible to keep the USB interface alive for remote control of frequency? (I haven't looked closely, maybe it is already) Thomas
Hi Thomas,
Thank you for the positive feedback.
As you surmise, the USB interface is alive, but today is only for debugging purposes ( debug/logutils.c ).
As an accurate (+-1 sec) time is essential for holding WSPR tx window properly, GPS UTC time stamp is used in today version. However, if we supersede GPS to TCXO, the user will have to set the time manually using minicom terminal and Pico USB interface for example. So, your idea definitely looks sound.
Regards, Roman 73 & 72 de R2BDY
Hi ErfanDL,
Thank you for your question about the project.
It is possible for majority of such external oscillator (TCXO) types. Fortunately I possess a number of obsolete TXO4080 TCXO's (Rakon, 10 MHz). I'll try to devise a frequency locked loop based on this TCXO signal, that's quite simple. However some schematic will be required to match TCXO output to Pico's GPIO input (I suppose two resistors will be sufficient). TCXO will be an additional option, the good one is often more valuable than GPS receiver.
Cheers, Roman 73 & 72 de R2BDY
thanks for reply. I had another question, is it possible to activate the output pin every 12 seconds for 100 milliseconds?
Hi ErfanDL,
It is possible, you can do that easily. Please read RP2040's https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf , paragraph 4.6.4.2. Set an alarm
. There is an example which is very close to your task.
Regards, Roman 73 & 72 de R2BDY
Will be very nice to use the TCXO as clock and the Wifi/NTP for the timing. Very compact solution for WSPR
NTP as an alternative is an option, but i asume in that case you need to add the ntpd in the code to get the system in an optimal shape for correcting time drift. NTP as protocol seems to be suitable. In the past the servers i managed made use of the TIME beacon at the long wave if i remember richt, and later, when internet was no longer dial up based we started to step over to NTP.
Using NTP could solve issues when you have not a clear skyview, some gps modules could become instable at in house situations.
How does NTP handle time drift? But after the offset reaches 55 ms, ntpd seems to set the time again and the offset becomes sufficiently small and stable (< 1ms). It seems that ntpd let the clocks drift for a while and after a (too) long period of time, the deamon takes countermeasures to the clock drift between NTP client and NTP server.19 Oct 2018 NTP on its own is thin, on the another hand, a GPSmodule is cheap and accurate. GPS is an issue when used in house with thick concrete, the module will not lock to the satelites, NTP is in that case an option.
I have added NTP + FT8 support @ https://github.com/kholia/Pico-FT8-TX/tree/free-beacon-ntp-pico-w.
My drift correction technique -> Just reboot the Pico W using a cheap smart switch every day on a schedule.
Thank you very much! Why not re-synching the clock from time to time? o rebooting the board with a timer/watchdog?
Sure - that can be done too. Good ideas! I like the reboot-using-watchdog idea as that keeps the code simple.
I also recommend checking out https://github.com/kholia/HF-PA-v10/tree/master - it is quite rugged and awesome :D
In case the beacon system is deployed remotely, I recommend keeping it attached to a WiFi smart switch for "emergency remote power control".
Thanks for sharing, I will check the PA.
Hi, first, thanks for this great work! I have a pico with wifi and can be great to have a fully standalone version without any additional GPS module/antenna. Is it feasible?