Cool set-up :) Where are all of these clocks in the ntpq picture though?
I'm surprised that stratum 1 devices have such large offsets from each
other... A solid PPS set-up should easily give sub 1ms accuracy, but it
looks like these all disagree by a few, if not dozens of, ms. I assume this
is due
> I have another Raspberry Pi that uses ntpq to query all of my
> clocks, along with two commercial NTP servers on my network,
> plus two external servers, and compares them.
ntpq doesn't really compare them. It just reports what the other ntpd thinks
is going on. You might be able to get
You can also use the 'f2fs' as filesystem on your sd-card.
Things become rather slow (as it is a logging filesystem) but I used the
same card for more over 5 years in a frontdoorcamerasystem I wrote and
made.
On Wed, Dec 08, 2021 at 02:43:47PM -0800, Kevin Rowett wrote:
> Jim,
>
> The wear
I don't recommend USB as a highly reliable boot device for Linux. I did
development and support on a Linux based embedded product that kept all its
nonvolatile storage on a USB drive on an eUSB card inside the case, a lower
cost alternative to SSD or PCIe based drives. While it worked on about 99%
piCorePlayer aka. pCP, a DIY high quality audio player for Squeezelite
are running entirely in RAM after loading from SD card. Only
configuration changes are written to SD card. I have been running a
handful of these devices daily for years on cheap SD cards without any
SD card problems.
> In fact, as long as you can set the clock once, you don't need NTP at
> all. The display will be locked to GPS.
I can't figure out what you mean.
If you don't run something like NTP, your system clock will drift.
If you have something like a PPS from a GPS, then you could run a clock
off the
Jim,
The wear leveling algorithms have gotten very good at garbage collection, wear
leveling, and bit error recovery codes. (LDPC has gotten a lot of practical
research for flash).
(the challenges are - when to do the garage collection, so as not to impact
read and write rates, yet not run so
On 12/8/21 2:15 PM, Bill Dailey wrote:
You can also set them up so they don’t write to the SD once everything is set.
SD’s will last forever like this. Basically read only and RAM disk.
yes indeed - these days, with lots o'RAM on a rPi, you should boot off
the SD (or eMMC) and run out of
You can also set them up so they don’t write to the SD once everything is set.
SD’s will last forever like this. Basically read only and RAM disk.
Bill Dailey
Negativity always wins the short game. But positivity wins the long game. -
Gary Vaynerchuk
Don’t be easy to understand,
Be
SD cards used in dashcams also suffer severe rewriting behaviour. I believe
there are reviews and comparisons covering various makes in this
application.
On Wed, Dec 8, 2021 at 9:30 PM Kevin Rowett wrote:
> The sandisk extreme sd cards have an excellent wear leveling algorithm.
>
> KR
>
>
> >
On Wed, Dec 8, 2021 at 9:41 PM Lux, Jim wrote:
>
> When last I was looking at this, it turns out there's a bunch of
> non-traditional display shapes available for things like "Shelf edge
> displays" and such. That is the google-able phrase to turn up stuff.
>
>
On 12/6/21 11:34 AM, John Miller via time-nuts wrote:
This is something I have explored from time to time in order to find
a good local display option for Pis running as GIS-disciplined NTP
servers. I've done a lot of exploring and fiddling around with different
options but have yet to find a
The sandisk extreme sd cards have an excellent wear leveling algorithm.
KR
> On Dec 8, 2021, at 1:26 PM, Nick Sayer via time-nuts
> wrote:
>
> I forget where I saw it, but my understanding is that the big issue is
> finding SD cards that can perform whole-disk wear leveling, like proper
I forget where I saw it, but my understanding is that the big issue is finding
SD cards that can perform whole-disk wear leveling, like proper SSDs do.
Apparently, the WD purple series do, according to the e-mail thread I read that
I forgot where. Someone contacted WD and got a confirmation
Thanks for the suggestion. I am not averse to C++, and will definitely look
into these examples and try replicate something similar.
Adam
On Mon, Dec 6, 2021 at 3:35 PM Attila Kinali wrote:
> On Sun, 5 Dec 2021 15:53:57 -0500
> Adam Space wrote:
>
> > For example,
> > the only solutions in
Thanks for the ideas. The first idea sounds interesting. I recently got a
Raspberry Pi GPS/PPS setup working, which is still having some issues but
overall ok. (In particular, it seems as if there is a few ms lag from the
PPS signal, which I'm not sure what to do about). I've never done anything
> In this application RPis seem to last for many years - in others where we
> use the SD-card (e.g. influxdb or similar) they seem to regularly fail in
> 1-2 years, requiring an reformat or new SD-card. An RPi or similar with a
> more robust SSD/M2 drive would be good.
I’ve had the same
I have four home-built clocks, each using a Raspberry Pi, all with slightly
different designs, all running gpsd and ntpd (so all are NTP servers on my home
network). Three are GPS disciplined; one is WWVB disciplined. Two of the GPS
clocks use the modem-control lines on a serial port for the
You can also let them boot from nfs.
On Tue, Dec 07, 2021 at 10:01:13AM +0200, Anders Wallin wrote:
> We use this simple python script with RPi and a 7" RPi screen in many labs
> just to have a simple clock display. AFAIK the timing and update rate is
> good enough for human visual readout.
> The
On 05/12/2021 20:53, Adam Space wrote:
Most distributions of Linux already have a "clock" application that shows
the system time, but I am wondering how to program a more customizable
display on a Linux system / Raspberry pi. There are a few solutions that
pop up by googling the issue, but these
On Mon, 06 Dec 2021 17:14:22 -0800
Hal Murray wrote:
> Where/when/what/how did you get that idea?
>From scripts I wrote that did not behave as I expected them to
behave. Yes, I do indeed look at the mili-second accuracy
of sleep() calls of scripts. I am a time-nut after all ;-)
> I've had no
We use this simple python script with RPi and a 7" RPi screen in many labs
just to have a simple clock display. AFAIK the timing and update rate is
good enough for human visual readout.
The RPis get time over NTP.
https://github.com/aewallin/digiclock
In this application RPis seem to last for many
> I would advise against using python for something like this.
> time.sleep() of python is extremely inaccurate.
Where/when/what/how did you get that idea?
I've had no problems with Python timing. Am I not looking
in the right place? Were you using some really old
software or hardware?
Hi Adam,
It would help to know, numerically, what you're goals or requirements
are. But it sounds like you're not interested in microseconds or
nanoseconds, maybe just milliseconds?
There are untold number of layers of latency in the system you describe,
especially since you're using a
On Sun, 5 Dec 2021 15:53:57 -0500
Adam Space wrote:
> For example,
> the only solutions in Python (which I would prefer to use if possible, but
> not necessary)
I would advise against using python for something like this.
time.sleep() of python is extremely inaccurate. For long
sleep times (a
This is something I have explored from time to time in order to find
a good local display option for Pis running as GIS-disciplined NTP
servers. I've done a lot of exploring and fiddling around with different
options but have yet to find a solution that I am fond of, for the
reasons that you
26 matches
Mail list logo
