moonfire-nvr
Our great sponsors
beaglebone-gps-clock | moonfire-nvr | |
---|---|---|
3 | 31 | |
27 | 1,114 | |
- | - | |
0.0 | 8.6 | |
about 1 year ago | 13 days ago | |
Go | Rust | |
- | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
beaglebone-gps-clock
-
Raspberry Pi Nixie Atomic Clock
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!)
-
The Raspberry Pi as a Stratum-1 NTP Server
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
-
Facebook open-sourcing a more precise time server
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.)
moonfire-nvr
-
Mock Service Worker(msw) releases 2.0
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...
-
Alternative open firmware for your IP camera
> 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
-
NVR in Rust
saw one nvr project in rust - https://github.com/scottlamb/moonfire-nvr - maybe you can find answer there
-
IP Camera stream - simple recording - no resize/detection/etc - is it possible?
Moonfire NVR does basically that. No decoding at all. The configuration process could be smoother, but there's a decent setup guide to follow.
-
Surveillance system, how low can you go?
This is exactly what you're looking for: https://github.com/scottlamb/moonfire-nvr
-
Installing Rust in a Raspberry Pi 3A+
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.
- Self Hosted CCTV/Home Security
-
NVR Suggestions & Experience...Any decent alternatives for MotionEye?
Moonfire may be what you're looking for otherwise.
-
What's everyone working on this week (50/2022)?
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!
-
surveillance station
Moonfire
What are some alternatives?
txtempus - A DCF77, WWVB, JJY and MSF clock LF-band signal transmitter using the Raspberry Pi
Shinobi - :peace_symbol: :palestinian_territories: Shinobi CE - The Free Open Source CCTV platform written in Node.JS (Camera Recorder - Security Surveillance Software - Restreamer
Time-Appliance-Project - Develop an end-to-end hypothetical reference model, network architectures, performance objectives and the methods to distribute, operate, monitor time synchronization within data center and much more...
frigate - NVR with realtime local object detection for IP cameras
magma - Platform for building access networks and modular network services
motioneyeos - A Video Surveillance OS For Single-board Computers
Flicks - A unit of time defined in C++.
viseron - Self-hosted, local only NVR and AI Computer Vision software. With features such as object detection, motion detection, face recognition and more, it gives you the power to keep an eye on your home, office or any other place you want to monitor.
onload - OpenOnload high performance user-level network stack
jupyter-rust - a docker container for jupyter notebooks for rust
GNSSTimeServer - WiFi-enabled GNSS (GPS, BeiDou, GLONASS, Galileo) fed NTP/RDATE server based on ESP8266/ESP32 and Arduino
neolink - An RTSP bridge to Reolink IP cameras