A standalone GPS NTP server is $750 retail. Commercial soft serve ice cream machines are at least $4000. Just building the machines with an autonomous GPS clock that doesn't need to be set, would double the revenue but only increase the upfront cost by 18%.
Since they need internet connectivity to phone home status to McCloud, I don't know why they wouldn't just run an NTP client to keep their time synchronized and accurate?
Moreover the $750 you reference must be a commercial product since you can do GPS on a Raspberry Pi for < $50 easily? Which product are you thinking works for this scenario? Think I've seen everything from $300 to $13000 solutions for this over the years.
I doubt these machines are internet-connected. Most likely is that the store manager notices the machine has gone into its cleaning cycle and manually marks the item on the menu as unavailable.
If it was being integrated, the cost would be more like 5 dollars, since the ntp unit could just be an esp8266 chip that connects to the store wifi to sync the time.
If they can't manage to set the time what makes you think they'll connect the Wifi?
(...although in fairness some of the other comments here suggest the things might already have some kind of int[er/ra]net connectivity in which case no extra hardware required)
That sounds like an awful lot of work to not send NTP requests over WiFi. Then again, I'm sure someone will inevitably find a way to make these things spray ice cream everywhere over WiFi if they do. Or worse, mess with the internal temperature or cleaning settings to make them not safe to consume.
It's actually probably best they never touch the public wifi. I don't know why no one has mentioned ethernet yet, though. These machines are static, they just sit there. There's already tons of wiring going everywhere, so I would assume that it should be relatively easy to get a cable drop to the ice cream machine. Then you don't have to worry about any of this wifi security. You could do port level security, but that's probably overkill for an edge network.
I have actually been wondering lately why there isn't more of a market for some of these things that it seems like you could hack together. There has to be something I'm missing. You'll never be a unicorn, because most of these kinds of sensors have a limited scale, but it seems like a good return on investment for a small team.
I don‘t know about 3G, but I just checked for LTE [1] and the timing is broadcasted in SIB16, which is not encrypted, so theoretically anything could pick it up.
WWV/WWVH might not be a great idea, as I've read that there are rumblings about phasing it out.
You used to be able to pick up a time signal almost anywhere in CONUS with an FM receiver. It was encoded in the transmissions of PBS television stations.
This was back in NTSC days. Now that everything is digital, I don't know if it's still true.
The specification was called XDS and was developed by Sony to automatically set the clocks on their VCRs. PBS was a major participant but some other networks included XDS timecodes as well. Unfortunately late in the systems life reliability became poor (the encoder was not integrated with any of the other station equipment and was not being modernized) and I assume they all died out with the digital transition.
A better source today would be the time codes sent out by some FM radio stations with RDS encoders, to allow car radios to set their clocks. Unfortunately not that many radio stations do this and, once again, the time is not always all that reliable since the RDS encoder may not have any synchronization source itself.
The cellular network used to be an excellent source, CDMA cells required GPS time sync for TDMA reasons (well, CDMA reasons, technically speaking...) and broadcast a time code that is directly off of their GPS time source. Unfortunately, while GSM cells (and LTE) do broadcast the time, there is no guarantee made of precise synchronization as they don't broadcast a time code directly from their GPS source (not an expert in this field but I think the GSM/LTE time information comes from the possibly remote controller rather than the local radio hardware). Still, it would probably be good enough for this application.
GPS time sync is actually quite cheap to implement these days but tends not to work in these scenarios since a clear sky view is needed. WWVB is possibly on the way out. SNTP is probably ruled out less by the BOM cost of WiFi hardware and more by the deployment pain of having to get kitchen equipment configured for the corporate WiFi network.
Here's a fun idea: McDonalds presumably centrally controls the in-restaurant audio. Could they encode timestamps into the background music in a way that machines can cheaply recover? You wouldn't need high reliability, just enough for it to work once in a while. The old-ish Nielsen Peoplemeter system would be a model.
