Hi all. Maybe this question has been asked. If so please point me in its direction.
I need the date and time on the Linux side of the Yun. Where I am going to use the Yun there is no internet connection but there is wifi. So my question is this. What is the best way to set the Linux time and date. Should I have a ntp server running on the wifi network and have the Yun gets its values from it. Or is there a better way to have a rtc hooked up so the Linux side can use it?
Hi. Thanks I did have a look at that post. But the rtc is on the Arduino side. I need the time set on the Linux side. Do I have to add code then to the Sketch that the Linux side will call to set its time after a boot? I am just afraid Iwill run out of Sketch space just to set the date and time to start.
By pass arduino, connect USB GPS module directly with Yun.
That module is going to push up the cost of the hardware a lot. Is this the only way. Can I not have a ntp server on the wifi network ? Or i guess I could try the RTC, have a part to set the time on Linux and call that from Python once the os has booted up.
The way I see it, you have three basic choices:
- Add an RTC to the shield connectors, add some code to pass the time to Linux on boot. (And perhaps periodically after that?)
- Add an RTC directly to the Linux processor, add some code to read it at boot time and set the Linux clock.
- Set up your own NTP time server on your local network, update the Linux configuration to use that rather than the default Internet servers.
Option 1 is probably the easiest local time option, with the most examples. But it does require some extra code in the sketch, code which has a limited ‘once per boot’ utility.
Option 2 could be much more work or more expensive. GPS is expensive, and requires receiving a satellite signal, but has the advantage of not needing to be set initially. There are discussions of hooking up an RTC to OpenWRT routers using I2C, but it could be difficult getting to the required GPIO lines because they are under the metal shield. The Linux side can drive the SPI lines on the six pin ICSP header, and an RTC chip could be connected there, but care must be taken to prevent interference with other devices connected to the SPI bus and driven from the sketch. I’m guessing the simplest and least expensive solution is to make a small board with a processor, USB interface, and RTC module: perhaps using an Arduino Micro? Plug that into the Linux side USB port, and on startup Linux would query the time over the USB serial port. A quick search for “USB RTC module” turned up several people who did just that.
Option 3 requires no extra programming or hardware (other than the server) and minimal configuration changes. But it does require setting up a server, and a way to manage the time on it.
You’ve got me thinking… I’ve just finished up a project that needs the time, and the network conditions where it will be run will be quite variable. It’s quite likely that there will be no Internet access. I will have to think of something similar, and I’m leaning toward option 2, a small board that can be plugged directly into the USB host port.
Why the Linux side does not have a RTC is beyond me. How can you have a PC without a clock? I hope that Yun version 2 has it build in. It is a very basic thing to have part of the micro processor. I will probably end up doing option 1 with code to call from the Linux side to set the time from the Arduino side.
But now you have another piece of hardware and the battery can go flat. Mybe I should do both option 1 and 3. Have the RTC time be set by the ntp server (I need a server on the network anyway as all the Arduinos will send its data to this server). And if it cant fine the server then It does have the time on the RTC.
I just hope all the code fits in the space. I will probably end up using a mega with a Yun Shield if all the code does not fit.
Why the Linux side does not have a RTC is beyond me. How can you have a PC without a clock? I hope that Yun version 2 has it build in. It is a very basic thing to have part of the micro processor.
I don't know what the designers were thinking, but I have some guesses. First and foremost, it's added cost (and board real estate) and the board is already expensive enough. Yes, an RTC quickly became a standard feature on PCs, but that happened back in the very early stages of the Internet and live Internet connections were basically unheard of outside of academic circles - in fact, it was extremely rare for a PC to be hooked up to any kind of local network, let alone the Internet. So they HAD to have an RTC if you didn't want to set the clock every time at bootup (my first two computers didn't have an RTC, I lived without it on the first one, and added and RTC card to my second one.) When compared to the cost of the overall product, the added cost of adding an RTC to a PC adds a much smaller percentage to the cost, while on a Yun it would be a much higher percentage.
Another factor is that the OpenWRT operating system running on the Linux side is primarily designed for routers. An RTC would add cost to a router, so it is generally not included - after all, by definition, the router probably has access to the Internet and an NTP server, so it doesn't make sense to spend money on the RTC hardware. When designing a commodity product (like a router) that is price sensitive (many people will look only at the price when buying a router) every penny counts - when you're mass producing a product, even saving pennies per unit can add up into real money - making a difference of tens to hundreds of thousands dollars in overall profit.
A similar thought may have been a factor with the Yun: they may have assumed that most people will have Internet access, and thus there is no need to include an RTC?
I have an Adafruit Trinket that I got free in a recent order (it's normally $7) and I have an RTC breakout board sitting around. I will probably cobble them together to make a generic USB RTC that plugs into the host port if needed. That should take care of my needs. I'm thinking something very simple: it sends the complete date and time over the USB serial port every second or so, and sets its clock if it receives a properly formatted date and time string. The Linux code would simply open the serial port, wait for a complete date/time string, and then update the software clock based on that.
I wish you good luck with your decision and project!