Started using WiFi with a Pico 2W and updating clock with the not 100% reliable ‘web ntp’ (with no UK summer time adjustment !). Yet running out of ideas already and it seems basic web page browsing is beyond the device. Dissapinted to find the WiFi connect command can’t be run from within a program too so moving from one known wifi to another involves typing in the name and password every time !!. Peter Mather has also just said no to making this a command that can be run within programs !!. Clock speed is also limited to 252 Mhz (or even less on the Pimoroni). Hence questions…
-
Any other websites in UK that give simple responses ?. Local weather etc
-
Anyone managed remote control of their TV etc ?
I’ve found web ntp to be 100% reliable if I use an actual IP address rather than an alias. (don’t use nist.time.org or the like) As for DST, I adjust the offset to account for it. I’m located in the EST zone, usually -5 hours from GMT. During DST, I just change the offset to -4.
Yes I’m using ‘uk.pool.ntp.org’. Sometimes fails first time but usually works the second. On a bad day fails the third attempt 
. I get the impression my router doesn’t like a ntp check right after establishing wifi. All this doesn’t help when it slows down PicoCalc startup considerably. If I can’t find much use for wifi I’ll go back to the faster Pi Pico2 and wire in a good RTC for time… Yes I just do a simple month check at the moment and add an hour if needed, will update with an array of future UK DST dates to check against when I get the time as there seems no simple way of doing correctly…
1 Like
Search on the backshed and you will find routines for lots of useful stuff like daylight savings
https://www.thebackshed.com/forum/ViewTopic.php?TID=17730&P=2
1 Like
Try 185.53.45.4 instead of the pool name. This works for me. The website says they change the addresses frequently but I’ve found they’re fairly stable.
I have gotten NTP working on the Pico 2 W with the RP2350 NTP client that I have included with zeptoforth. (There is also a differing RP2040 NTP client, which differs because it uses the RP2040’s RTC which can only be set to the second whereas the RP2350 NTP client uses the Always-On Timer set up to be the number of milliseconds since 1 Jan 1970 00:00:00 UTC). Note that I have been using pool.ntp.org as my NTP server (or properly, set of NTP servers, as I am using DNS which maps to multiple IP’s rather than the IP itself), and have been using time in UTC rather than trying to take local time into account.
Don’t need a lookup - just last sunday in March or October.
Handy… He uses my first step of removing months outside DST and then adds to that days in the months before and after DST months that cannot be DST affected. That was going to be my next step after analysing patterns in the last Sunday dates over the next few years by noting dates from my mobiles calendar. He then takes the last step of determining exactly when the last Sundays must be. Will keep me busy for a while adding in these steps to my own code while making as short, fast and compact as possible. A good library function.
I had the same problem when I was auto running a program to grab the time from the internet. I think the issue is auto run programs start to execute before the pico has finished getting its IP address. Now I have the program tied to F1, so when the PicoCalc finishes booting, I press F1 and then it goes and grabs the time. Since I started doing that, it has never failed unless the PicoCalc failed to get an IP address.
After the initial wifi connect the Library executes in slot 3 then my autorun in slot 1 so virtually always has a valid ip address (errors if not with ‘NO WIFI’). Autorun invokes my do-all menu showing amongst other things the date and DST (partially) corrected date so additional delays or requirements certainly not wanted. In general I dont have an issue beyond the initial wifi connect delay, occasionally a second NTP request, rarely a third or fourth (my program gives up after that).