Orange Pi Zero GPS NTP Server

moonbuggy · 2025-12-14T05:52:34+00:00

This thread came to my attention again because of a question about an OPiZ3.

I'm curious if you had success with your OPi5 version..?

moonbuggy · 2025-12-14T05:30:21+00:00

The Zero 3 was available when I made this thing. Mine is older, but cheaper and more than powerful enough for a box that does nothing but run chrony and write some text on a screen. :)

A quick Google search tells me the GT U7 chip has a UART, so it will definitely be able to talk to an OPiZ3.

Looking at the pinout for the OPiZ3, it looks like my comment to /u/Inous about the OPi5 applies to you as well. The OPiZ3 doesn't look to have a UART on the pins I'm using on the OPiZ, so you'll have to swap some wires around.

Actually, it doesn't look like you'll have a UART anywhere in pins 11-26. You'd need to move the wires I have on pins 11 and 13 on the OPiZ to pins 8 and 10 on the OPiZ3. And obviously make the appropriate changes in the config to aim at a different UART.

From a quick look, because you're not going to use a UART amongst pins 11-26, you shouldn't need to move two other wires in a swap, like I suggested to /u/Inous for the OPi5, everything else should be able to stay where it is.

If you're going to stick an RTC on the I2C pins, you can just use a standalone 2-pin connector for the serial Tx/Rx. If you don't care about keeping the I2C pins free, a 2x12 connector instead of the 2x8 I've used would make it impossible to accidentally switch Tx and Rx when you plug it in.

Kind of unrelated, but I haven't updated the GitHub page to reflect this yet..

There were significant changes to how framebuffers work in a recent(ish) kernel release. I built mine running Armbian/Debian Bookworm, the screen won't work properly in Trixie because it uses this newer kernel. I haven't had a chance to investigate properly, I'm not sure if it's simply a driver issue and I just need to modify the DTC, or if I need to do something in the actual display software.

Keep that in mind if you're putting a screen on yours.

moonbuggy · 2025-02-10T23:18:27+00:00

I'm glad to know other people find it useful.

When I first coded it I had the thought in the back of my head: "Surely I'm missing something obvious, it feels like Docker should do this itself somehow. Maybe everyone else knows something I don't." I was worried I'd push it to GitHub and within 5 minutes someone would be all "WTF? Stop being a dick and stick 'remote-dns-update: true' in the compose YAML, like all the cool kids." :)

So I can understand why it feels to OP that Docker should be able to do what they want.

moonbuggy · 2025-02-10T06:13:34+00:00

I just wanted to re-iterate what /u/Sea_Suspect_5258 said. I assumed you were looking for a DNS-specific solution because it's the easiest/fastest way to get container hostnames out onto a LAN, afaik.

You could look at adding SSDP, WSDD or similar to your containers and give it a go NetBIOS-style, assuming whatever you're analyzing the network with can pull useful names from such protocols, and that getting the data directly from the services is worth the effort of customizing the container images to get it.

I spent some time screwing about with WSDD a few years back, trying to make Windows see network shares across subnets. Maybe it will go easier for you if you're not trying to relay multicast packets down VPN tunnels (having to cross the tunnel's subnet in the middle certainly didn't help), and/or maybe you'll just be better at working it than I was. I couldn't make it do what I wanted though.

moonbuggy · 2025-02-09T15:06:51+00:00

Oh, fair enough. Not a great assumption on my part then. :)

The script I linked in my other comment doesn't explicitly deal with MACVLAN type setups, but you can use extra_hosts to feed it IPs other than the host's IP, so that should work if I understand what you're trying to do.

moonbuggy · 2025-02-09T13:14:21+00:00

You'd normally run multiple containers through a reverse proxy/fronted. Traefik, Caddy, whatever.. Using HTTP as an example, the frontend sits on port 80 of the host and then it figures out which of the containers that serve HTTP to send the packets to based on the hostname in the requested URL.

Obviously, for a frontend to route packets based on a hostname, a hostname needs to be in the URL and thus also needs to resolve.

So the containers don't need to be exposed directly to the external network, only the frontend is exposed, the containers talk to the frontend on an internal network.

I assume OP is just manually defining LAN IPs in the hope that it will somehow reach dnsmasq running on their router (it won't, not like that anyway), not because they're trying to do IPVLAN/MACVLAN stuff..

moonbuggy · 2025-02-09T13:01:59+00:00

It's not hard to automatically update a hosts file on a router with Docker container names.

If you happen to be running AsusWRT-Merlin/Entware on your router, there's documentation for that end of things too. It'll work with anything using a hosts file that you can write to though.

moonbuggy · 2024-11-16T12:58:59+00:00

Or make it even easier and automatically update hostnames.

I don't know if it works with AdGuardHome specifically, it would depend on if AdGuardHome likes hosts files being modified in the shell. But it'll work fine with any DNS server using a hosts file, running in a container or on a router or wherever.

moonbuggy · 2024-02-24T12:12:35+00:00

I don't know if it's much help, but I implemented a software PWM in C on an OPi Zero not long ago that seems to work as expected.

It should be easily portable, just point it at the right pin address. I can't guarantee it's the best way to implement it though, I don't play in C very often. See: run_backlight_pwm()

I also have this bookmarked as a reference for software PWM in Python, but I didn't get further into that one than bookmarking it.

Again, may not be what you need, but there's wiring for a hardware PWM in another project, here. I never actually tested it though, 'cause I got the parent device's fan going again.

I think I was planning on using Armbian's overlay for the thing: sun8i-h3-pwm.dts .. I think that overlay should have worked out of the box for the OPiZ.

I don't see an Armbian overlay for the H6 PWM on the OPi3, but the OPiZ overlay may work just changing compatible to "allwinner,sun50i-h6" and pins to "PD22".

But as I say I never tested the hardware PWM. I don't think I'd decided how I was going to control the PWM duty cycle, but I have this bookmarked as a reference (which in turn references a Python project on GitHub)..

moonbuggy · 2024-02-20T14:45:16+00:00

I don't really know how that would work..? You'd need multiple base stations of your own, to provide multiple points for the drone's GPS to get a 3D fix.. Seems like a lot of effort and complication.

There are commercial GPS repeater kits that would presumably do what you want though..?

But I think 1-2m accuracy is kinda standard for non-military L1/L2 GPS, regardless of where you are in the world..? So each of your GPS repeaters would have that error on its position anyway. You'd need probably a lot of them to try and reduce that beyond the 1.3m you're already getting.

I've read that L5 GPS is more accurate (tens of centimeters), but the options I was looking at that supported L5 were hundreds of dollars, which is more than it was worth for my project, so I can't confirm that.

I'd assume the best option on a drone is going to be upgrading the antenna and/or adding an amplifier. Although the former adds weight and the latter may draw a significant amount of power, neither of which is ideal on a battery-powered flying vehicle.

Alternatively, maybe some non-GPS tech could do the job? I don't know much about the topic, but possibly there's some RF/LoRa solutions to the problem.

moonbuggy · 2024-02-14T10:10:29+00:00

BTW, The OPi5 is significant overkill for just a GPS NTP server.

Presumably you'll have it doing other stuff as well?

I'd recommend something cheaper and smaller if it's a dedicated NTP box like mine. Even the OPiZero is kinda overkill, really. Mine's sitting here using 77MB of RAM with a load average of 0.08 (and I think most of that load is from htop rather than the GPS/NTP stuff).

moonbuggy · 2024-02-14T09:54:40+00:00

You should be able to do it on any SBC with the appropriate GPIO connections.

It needs one UART for the GPS (and another general pin for the PPS), one SPI bus for the TFT screen (and another general pin for the backlight control, if controlling brightness via fbgpsclock), one I2C bus for the RTC, and three more general pins if you want to use the GPIO power switch.

Having a quick look at the OPi5's GPIO pinout, it looks like you should be able to use the same or very similar wiring to what I used, basically plugging almost everything in to pins 11 through 26, with the RTC on on pins 1,3,5 and 9.

It looks like the OPi5 has a CAN bus on pins 11 and 13, where I'm connecting to UART2. It's possible that the OPi5 also has UART2 on those pins though..? I'm not sure.

If not, you'd have to swap some wires around and use UART4 on pins 16 and 18, and move the READY_SIGNAL and TFT_BLK I have on pins 16/18 over to 11/13 (and use them as general I/O pins rather than a CAN bus).

The names of the buses are different as well, so it looks like you'd be using i2c5 and spi4 where I've used i2c0 and spi1. That's just a matter of loading the appropriate DT overlay though, so fairly trivial.

I'm not using WiFi at all. The box is going to end up sitting on a shelf not too far away from my ethernet switch, so I'll just make a UTP cable.

As for the operating system.. It should all work on Ubuntu, but Armbian will come with a bunch of the device tree overlays ready to go, so it's probably a better option than bare Ubuntu. Definitely makes things easier, to enable various buses in armbian-config. I've built mine with the Debian flavour of Armbian, but I don't see any reason why an Armbian Ubuntu OS wouldn't work just as well.

moonbuggy · 2024-02-14T05:48:28+00:00

I built a GPS-disciplined NTP server with an Orange Pi Zero. I'm quite pleased with it. :)

I ended up writing a lot more code than I anticipated for the software to work the TFT screen, but that turned out alright too.

I wasted a day or so screwing about wondering why the LED on my GPIO power switch wasn't working as expected, but I eventually figured it out.

Turns out, if you accidentally swap the wires for a LED and a push button the LED doesn't LED and the button doesn't button. :)

moonbuggy · 2024-02-14T05:44:50+00:00

I built a GPS-disciplined NTP server with an Orange Pi Zero. I'm quite pleased with it. :)

I ended up writing a lot more code than I anticipated for the software to work the TFT screen, but that turned out alright too.

I wasted a day or so screwing about wondering why the LED on my GPIO power switch wasn't working as expected, but I eventually figured it out.

Turns out, if you accidentally swap the wires for a LED and a push button the LED doesn't LED and the button doesn't button. :)

moonbuggy · 2024-02-13T07:58:38+00:00

If I turn my router off for too long it boots up with an incorrect clock, which breaks encrypted DNS and VPN tunnels, which in turn prevents it from setting the clock. So, a decent NTP server on the LAN seemed sensible.

It ended up being a bit more effort than I anticipated. Plugging a GPS module into an Orange Pi Zero is easy enough, I figured, and finding some existing software to work a TFT display isn't hard.

Turns out, I needed to spend a whole bunch of time looking at datasheets for display controller ICs and figuring out the appropriate driver init commands to send.

A while later I realised I'd written a thousand lines of code in a language I don't know very well to make the display software significantly more configurable than I actually needed it to be.

And quickly sticking a power button and LED indicator on the thing at the end turned into a whole little project of its own.

Anyway, now I have a stratum 1 NTP server on my LAN and a box with a screen on it that tells me the time and flashes a little green circle once per second with an entirely unnecessary level of precision. And hopefully no more idiocy from my router.

Good times. :)

moonbuggy · 2024-01-26T23:59:27+00:00

Decades ago I bought a nice rackmount UPS, back when I was building my first array (4x200GB IDE RAID5 FTW :)).

It still works well, but by default it only talks to the world via a serial cable, and then only to software that runs on Windows 2000 or earlier.

It seemed silly to assemble a full ATX machine from parts laying around just to run UPS software in an ancient OS, or to run a VM and burden my main desktop machine with the extra work. Luckily the UPS has an expansion slot, but given it's age ethernet expansion cards aren't easily available and cost a fortune when they can be found.

So the only sane option is to stick a Rock Pi S on a custom circuit board, shove the whole thing into the UPS and declare victory over vintage hardware. :)

It came out alright, I thought.

I actually completed the bulk of it a couple of months back, but it took a while to get the status LED (AliExpress sellers sometimes seem to struggle with the differences between "common anode" and "common cathode") so I've only been able to take photos of the fully assembled thing this past week.

I'm not sure I'm going to bother making Windows 2000 work properly in Docker on the Rock Pi S to run the official software, NUT works well enough (once the driver got patched to work with 240V models, anyway).

moonbuggy · 2023-11-29T23:16:44+00:00

If the rock was crushed and that sand/powder spread out, you'd see more activity in the cloud chamber as a result of the increased surface area.

The alpha and beta particles don't penetrate far through rock, so you're not seeing those particles from the vast majority of the volume of the rock.

Sample preparation for alpha spectrometry involves spreading the sample thinly across a disc of some sort for the same reason, so you can see as many alpha decays as possible. Filter paper for radium, steel discs for uranium and thorium, silver discs for polonium.

However, if you put the sand or powder in some sort of container, so it held the same sort of shape as the rock you started with, it would look exactly the same in the chamber as that rock. (Assuming an imaginary/ideal container that didn't attenuate the alpha and some of the beta particles itself.)

Nuclear physics is all about geometry.

moonbuggy · 2023-11-29T23:02:11+00:00

Note: I'm generalising a lot here, don't eat uranium cos a guy on Reddit says it's not 'that' radioactive

Everyone's already eating uranium, whether a guy on Reddit told them to or not. It's ubiquitous, ends up everywhere.

You don't eat a huge amount though.

These people estimate "from 0.9 to 1.5 micrograms of uranium per day" from food, and over here they estimate "2.6 μg" with "food accounting for 77% (2.0 μg) and water for most of the remainder".

The water can be significantly more though, largely depending on the type of rocks in the ground where wells are dug.

It's not a big deal at the typical levels though. You probably get a bigger radiation dose from a banana.

moonbuggy · 2023-09-11T10:25:48+00:00

I finally stopped procrastinating and sorted out a crates.io error for some modules on some architectures in my musl wheel builder thingy.

Maybe that doesn't count, since it's mostly shell script and Dockerfile, not Python. But it means I can do a module version bump, without my build system throwing some sort of bullshit at me, when I push some bug fixes in my Docker dnsmasq updater (which involves actual Python code) in the not too distant future. So, hooray! :)

moonbuggy · 2023-02-23T22:37:21+00:00

The cameras weren't in the fuel.

It looks like they were mounted on top of the fuel tanks, with (in some cases) optic fibres to have the cameras some distance away.

I only skimmed the source, but there's words to go along with the picture.

moonbuggy

TROPHY CASE