Is ths one of those questions where you ask a nominally valid question, but since you don't know what you are talking about you get lots of repsonses?
A "real time clock" is the thing that interrupts the computer every so often, and the software that counts those interruptions.
In the old days, you had to set the time when you started the computer, because it didn't know what time it was, just the time relative from that starting point.
Later, a hardware clock was added, so the computer could poll that clock and get the time by itself. This actually keeps time by a clock and a bunch of counters, so the computer reads the absolute time. But the computer only reads the hardware clock on booting up, or when you tell it to read the hardware clock, otherwise it uses the RTC to keep track of the time. That's why I'd lose time on my Radio Shack Color Computer decades ago when reading floppy disks; disk operations turned off the interrupts because the routine needed to work fast, so the clock would lose time due to lack of updates.
Since Linux is very interrupt driven, I find it hard to believe that Linux can run without also keeping track of the time.
If the Raspberry Pi really does not have a hardware clock to keep track of the time when it's turned off, then all you need to do is manually set the time once you turn on the computer. The utility has to be there, it has other uses
Michael
is lost. > It's a universal truth that you'll want to get the most-recent
It does get you version numbering and date stamping without having to DIY. OTOH, version diffs on binary files are meaningless (I will probably now be told that there are times when they're not).
Or rsync - may not be installed out of the box, but its definitely included in the standard package set (use apt-get or the equivalent GUI command to install it. Its my favourite backup because, after the initial run, its fast.
Speed ups of around 30-70 times are typical: it does the minimum work needed to make a backup disk or SD card identical to the current state of the source device and has clever tricks for doing minimal work on large files (databases, binaries etc). You'll probably want to use a cycle of at least two backup cards: I do exactly that using a cycle of two USB hard drives which are kept offline in a fireproof safe when not being used to make a backup or (much more rarely) to recover after an old disk has died.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
No. A real time clock is a little clock chip on the computer which actually counts the seconds and keeps track of the actual date and time as well. It is run off a battery and still works even if the computer is shut off, unplugged and (for a laptop) the main battery removed.
PCs have had RTC for a long long time now.
What you call the hardware clock is more usually called the RTC. The system clock is what you seem to call the RTC. The rPi has a system clock. It has no RTC.
Yes. Unfortunately linux (usually) does not have a program which asks for the current time when switched on.
Files are transfered to OP's rPi on a USBstik, before that is carried to a location which has no electricity-supply. It's in a shoe-box with a 6V accumulator. For TextToSpeech; no display; only control is on/off switch.
Setting the date at each boot, on a device which HAS a keybrd+display is lame - too.
This problem is for inventive minds, not a hi-tech solution via your credit-card-at-wallmart.
& how does the OP get then from the stick to the PI? is there some kind of automated script in lace or does he have to issue a copy command?
The solution from the inventive minds is already available there are a number of very small, very cheep RTC add on boards for the PI
Therefore the options are simple & in order of preference.
1) but a clock module
2) if manual sync then set the time manually before performing the sync.
3) if an auto script modify the auto sync script to set the time to that of the newest file on the stick, or that of the destination directory (whichever is the later) before performing the sync. the time will be wrong but usable wrt the time stamps of the files.
Aha it is you! We should have known that, and just ignore you.
Anyway, when you have designed and built a system that requires real time and has no network, your selection of the Raspberry Pi has been WRONG, because it does not include an RTC.
Fortunately for you, RTC modules are available as an add-on, so you can still save your butt.
Only from August 1984 when IBM introduced the AT (successor to the XT and the earlier PC) based on the 80286 CPU with the expansion bus slots extended from 8 bit to 16 bit data buses and an extra 4 bits on top of the existing 20 bit address bus.
Prior to the AT, the original PC and XT motherboards didn't include a RTC. However, a lot of add in peripherals such as CGA and VGA, memory expansion cards and Multi-I/O adapters (required to connect floppy disks, modems, printers and hard disks) started appearing with RTC chips included, along with, typically, a lithium coin cell holder).
The RTC became such a ubiquitous feature of add on adapter cards that it wasn't unusual to see a PC or XT with as many as 3 such RTCs to choose from! In fact I myself reached such a state of 'surplus RTCs' with my early home assembled PC (made from 'scrapped' parts) around
1984/85 due to this proliferation of RTCs being "Free with every 8 bit adapter!" effect. :-)
IBM put paid to this by including the RTC on-board in their then latest AT motherboard specification. The CMOS RTC with its 70 odd spare 8 bit registers were able to amply serve the needs previously supplied by the three or four 8 way dip switches required to configure the hardware (presence and number of floppy disk drives, the amount of installed ram and other junk) which freed up a significant chunk of MoBo real estate as well as allow "The CMOS" to be configured via software, initially from a special setup program on a floppy but very swiftly incorporated into the BIOS rom via a hot key during the POST sequence so that all PCs _except_ the crap made by Compaq, could be configured _without_ the need for a special floppy disk setup program.
In the meantime, MSDOS would always prompt for the date and time on every boot _unless_ an AUTOEXEC.BAT file was found on the boot disk. It was enough for such a file of that name to be present, even if it was empty, to suppress MSDOS's ever present request for the date and time.
This quite neatly saved the early users of PCs who weren't bothered about date/time stamps from having to type these details in after every crash or install induced reboot, typically games players, whilst at the same time, allowing this question to be explicitly re-submitted and then answered by the RTC supplied interface software when such an RTC module was available.
All subsequent PCs (essentially AT and the ATX variant) retained timer chip compatability with the original PC where the OS would program a timer to produce a timer interrupt (18.1818 times per second for the OS's system time function, AFAICR).
The hardware RTC merely supplied the initial settings on each reboot and was normally never consulted again unless a specific software request was made (manually inputting the date and time from a dos prompt would automatically update the RTC as well as the system time (at least for the AT class of PC hardware - I'm not so sure about the earlier PC standard with its add-on RTC though).
Well, since Linus didn't attempt to port a version of Unix onto a PC until Intel finally got off their fat backsides to produce their first decent CPU in the form of the 80386 (which every subsequent intel CPU has been based upon), the integrated RTC has always existed in the history of X86 versions of Linux. The lack of such an integrated RTC would seem to be unique to the ARM SoC processors used by R-Pis and similar SBCs.
Historically, for all the PC versions at least, there hasn't been any need to automatically prompt for such user information on every reboot as was the case with MSDOS. However, it's quite simple to include such a request in a startup script, including initiating a date/time update from an externally added RTC module.
IMO, the best "Algorithm" is to use an add on RTC module and add the appropriate time setting requests to the startup script if reasonably accurate time is required on a R-Pi that stands in total isolation from the internet or any other time setting source such as MSF Rugby or a GPS receiver.
Relying on the latest date of a regularly updated file is a piss poor workaround at best, only being slightly better than nothing at all. If the system date/time has any importance at all (at least to the extent of asking this question), you really aught to fit an RTC module if no alternative source of accurate time setting is available.
Of course you now tell us what the situation is. And you ignore suggestions-- eg look into /var/log/ and find the most recent date, and use that or say 5 min later, to set your clock on bootup. Or as others have noted apparenlty the RPi saves the current time to a file periodically. Use that as the new time when the Pi boots up. Or put a cron job to run every minute to save the current time to a file, and use that at bootup.
All of these suggestions have been made and you spend your time attacking someone who had not idea what your setup was, because you never told anyone. It does look like you are a troll.
0-59 * ** * date +%s >/etc/currenttime And into a startup script (eg in /etc/init.d with a link from the appropriate /etc/rc?.d)
--------------- #!/bin/bash
date -s @`cat /etc/currenttime`
------------- You want this happening before cron starts up so it should be early ( a low number in the link in /etc/rc?.d) Eg ln -s /etc/init.d/settime /etc/rc3.d/S20settime if you called that script settime The above is a very abreviated description. Look at other scripts in /etc/init.d to find the appropriate format etc.
You could also try adding 60 or more to the "currenttime" as an estimate of the time the computer was shut off, since it takes time to shut down and come back up. But of course with no rtc you cannot know how much time has passed.
I have no idea what format fake-hwclock.data is in. It would make more sense for it to be seconds after epoch rather than a human readable string, but who knows.
suggests that these stations are no longer in operation.
So alternative sources of time could be DVB-t (using a DVB-t card in a PCI, grab the time from that and use it to seed the LAN ntpd) or in a similar manner from DVB-s if a satellite dish is available, or from a GPS handheld receiver.
Probably all of these suggestions will be rejected by Chris Glurr on account of being Walmart-credit-card solutions because they involve some additional cost, so that leaves just the Noon Gun solution, if he can hear it, way out on the veldt.
Yes, down in ZA I'd probably go for a GPS receiver, but one of the 'blind' receivers, e.g a Garmin GPS35 or GPS18, rather than a handheld. These output an NMEA 183 sentence every second, typically at 4800 baud by default but are configurable to higher speeds if required. The GPS35-HV model is set up to communicate over a single D-9 connector and wants a
12v power supply. From memory the other models use TTL levels.
You can find blind GPS receivers on eBay and can probably find used ones in ZA - ships chandlers or yacht clubs would be good places to start asking around.
But you're right: Mr Glurr may not agree about the benefits of GPS as a time source.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.