beaglebone-gps-clock VS moonfire-nvr

This is a great project! I was expecting a run-of-the-mill GPSDO, but this is way better.

I've been looking for more time sources to add to my own GPS clock: https://github.com/jrockway/beaglebone-gps-clock (which is one of those boring ones that everyone has).

I have been thinking about buying a rubidium oscillator from eBay for fun, but basically anticipated the problem the author had -- they have been mistreated for years before finally landing on eBay, and aren't any good. GPS is my only frequency reference, so I wouldn't really be able to fix it; I'm at the mercy of my very obstructed view of the sky.

I'd like to be able to measure how badly out of sync I get when I fall down from 16 satellites to 4 satellite throughout the day. I can sort of intuit that from the data I get right now (I send "chronyc sourcestats" to influxdb every 30 seconds, and you can see that when the GPS signal gets bad, the frequency error in my system clock also gets bad.), but I'd like to measure it conclusively. Will probably spend a bunch of money on the problem and become even more unsure which way is up ;)

The link to the "time to digital converter": https://www.ti.com/lit/ds/symlink/tdc7200.pdf is very interesting, and I totally forgot that I should be measuring AC powerline cycles to see how they're doing relative to GPS.

(In the past, I also incorporated a WWVB receiver, but get such a terrible signal in New York that I didn't get any usable data out of it. I then dropped the ceramic antenna and that was the end of that project. I have since realized that I can buy a phase-modulation receiver inside of a clock, throw away the clock, and try that, however. Ordering one right now, actually! Thanks HN!)

I made one as well (with a Beaglebone) and also have notes:

https://github.com/jrockway/beaglebone-gps-clock

My guide is also quite out of date, but I did rebuild it from scratch a couple years ago by following my own instructions and they worked ;)

Some discussion on HN this morning: https://news.ycombinator.com/item?id=28141493

What's interesting to me is how the form factor of timing GPS modules has stayed constant over the years. I started my GNSS timing journey with a used Trimble GPS from the 2000s, and it has the same form factor and pinout as the modern multi-constellation timing GPSes from uBlox.

I've had a GPS clock going for several years at this point, and without an atomic clock or really any fanciness (just LinuxPPS and Chrony), I see about +/- 380ns, which is pretty good. NTP to the Internet gives me jitter in the range of about 20ms-70ms, about 5 orders of magnitude worse.

(The version a few iterations ago looked like this: https://github.com/jrockway/beaglebone-gps-clock. But I now have a uBlox multi-constellation GPS, which is much more accurate with my limited view of the sky from my Brooklyn apartment. And I 3D printed the case, so it actually looks presentable instead of like some crazed madman that attacked a plastic case with a hacksaw -- which is exactly how I made the first case. As for the DS3231 RTC that I added... that seems to be stable within about 1.5us, which is pretty impressive. I tuned it a little bit with the trim register, though.)

How do folks test timing-related stuff with MSW? AFAIK, MSW doesn't get along with jest.useFakeTimers. It drives me nuts; I have a bunch of disabled tests in an open-source project and at least one that is flaky because it uses real timers where I'd like to be using fake timers. [1, 2]

I've been thinking about ripping out MSW from my tests in favor of my own API-level mock for this reason. But it seems like many other folks are happy with MSW. I have to assume there's something I'm not getting. I'm a fish out of water with frontend stuff in general...

[1] https://github.com/scottlamb/moonfire-nvr/blob/5ea5d27908f1a...

[2] https://github.com/scottlamb/moonfire-nvr/blob/5ea5d27908f1a...

> I wonder how hard it would be to run your own streamer pipeline or whatnot on these things?

Agree with the_biot: The actual streaming component is not too hard. If this were the biggest problem, I'd be thrilled to contribute to an open source streaming server to complement my open source NVR. [1] The driver situation is indeed a bit harder—these things don't just have mainline Linux support with v4l2 for the video input and encoder. Or open source drivers of any kind to crib from AFAIK.

The biggest problem IMHO is that there just aren't any good cameras to buy, even completely ignoring the software aspect. I want a camera that:

1. doesn't support genocide. Nothing that involves Dahua, Hikvision, or Huawei. See IPVM articles on the subject. And a lot of available cameras are relabeled Dahua/Hikvision stuff and/or use Huawei components.

2. is legal for sale / authorized for use in the US. (See the Secure Equipment Act of 2021.)

3. has good night mode performance: IR/day switch, a sensor that is at least 1/1.8", reasonable resolution (somewhere from HD to 4k).

4. has an "eyeball" or "turret" form factor rather than "bullet". The latter seems to really attract spiders, so you end up with a really nice video of a web...

5. supports PoE.

6. is weatherized (IP66 or so).

7. is reasonably priced.

If you ignore #1 and #2, there's some nice hardware out there, but I'm not willing to do that. If you ignore #3, there are a few options (GeoVision, maybe Reolink, maybe Hanwha.) If you ignore #4 and #7, there might be a couple (Axis, maybe Hanwha.) Nothing that ticks all the boxes.

Hard to get excited about investing a lot in the software when the hardware isn't there.

[1] https://github.com/scottlamb/moonfire-nvr

saw one nvr project in rust - https://github.com/scottlamb/moonfire-nvr - maybe you can find answer there

Moonfire NVR does basically that. No decoding at all. The configuration process could be smoother, but there's a decent setup guide to follow.

This is exactly what you're looking for: https://github.com/scottlamb/moonfire-nvr

But I would definitely avoid compiling Rust on the Raspberry Pi 3 if you can avoid it. I set up a Docker cross-compile environment for this reason.

Moonfire may be what you're looking for otherwise.

That last bit's not quite true: another option is to just use the cameras as a dumb stream source and do all the fanciness in an open source NVR. I've been slowly working on moonfire-nvr. Help welcome!

Moonfire