Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NTP over wifi #2

Open
ra1nb0w opened this issue Dec 11, 2023 · 13 comments
Open

NTP over wifi #2

ra1nb0w opened this issue Dec 11, 2023 · 13 comments

Comments

@ra1nb0w
Copy link

ra1nb0w commented Dec 11, 2023

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?

@RPiks
Copy link
Owner

RPiks commented Dec 12, 2023

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

@ErfanDL
Copy link

ErfanDL commented Dec 12, 2023

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.

@RPiks
Copy link
Owner

RPiks commented Dec 12, 2023

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

@thomasabbott
Copy link

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

@RPiks
Copy link
Owner

RPiks commented Dec 13, 2023

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

@ErfanDL
Copy link

ErfanDL commented Dec 13, 2023

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?

@RPiks
Copy link
Owner

RPiks commented Dec 15, 2023

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

@ra1nb0w
Copy link
Author

ra1nb0w commented Dec 17, 2023

Will be very nice to use the TCXO as clock and the Wifi/NTP for the timing. Very compact solution for WSPR

@edegraaff
Copy link

edegraaff commented Dec 30, 2023

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.

@kholia
Copy link

kholia commented Oct 13, 2024

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.

@ra1nb0w
Copy link
Author

ra1nb0w commented Oct 13, 2024

Thank you very much! Why not re-synching the clock from time to time? o rebooting the board with a timer/watchdog?

@kholia
Copy link

kholia commented Oct 13, 2024

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".

@ra1nb0w
Copy link
Author

ra1nb0w commented Oct 14, 2024

Thanks for sharing, I will check the PA.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants