schwar3kat

I'm building from the armbian-next branch for testing and I'm finding the experience quite unfamiliar and a little annoying.   It does seem faster though.

Orangepizeroplus (H5) built successfully for current, jammy and the image produced worked. I suspect that other flavors will build okay for testing.
but it errored after building the image [] Error occurred [ code 23 at /root/build-armbian/rc/build/lib/functions/logging/runners.sh:134

Orangepi-r1plus-lts (rockchip64 RK3328) built successfully for current, jammy.  No build errors.

Orangepi-r1 (H2) build system failed near the end.  019.000.create_board_package.log
--> 🛠1272: 1319406 - 1319406 - 1319406: ehBE: debug: Running family_tweaks_bsp [ sunxi ]
--> 🧽 1272: 1319406 - 1319406 - 1319406: ehBE: trap: main_trap_handler [ ERR and 1 trap_manager_error_handled: ]
The annoying 6.8 MiB html log file is a pain to parse. 

I guess that the build system enhancement issues will be picked up and dealt with separately and should probably not have bugs logged by SBC testers, or should I be logging bugs?

Can I switch off the time wasting and annoying markdown / html logging behaviour?
I don't want caterpillars, butterflies ants, bunches of leaves and comic explosions that don't make anything clearer and are unnecessary annoyances that don't play nicely with my tools.
LOG_ENABLE_EXTENSION=no, didn't do it.
Is it possible to keep the split .tmp files on error / build fail?

fixed

Happy that it works. 😀
 

Thanks MichaIng,  that's what I thought too.    Seems the linux kernel people are trying purposely to make it difficult.

I eventually found it
I compared the compile artifacts from legacy and current /drivers/gpio (before the build cleaned them) and found that .gpiolib-legacy.o.cmd and .gpiolib-sysfs.o.cmd were missing.  They were not compiling. This was in spite of kernel config containing CONFIG_GPIO_SYSFS=y and Makefile containing obj-$(CONFIG_GPIOLIB) += gpiolib-legacy.o and obj-$(CONFIG_GPIO_SYSFS) += gpiolib-sysfs.o

I then compared Kconfig, hoping to find a hint in the comments. There was a hint in the comments "select GPIO_CDEV # We need to encourage the new ABI"

but also... bool "/sys/class/gpio/... (sysfs interface)" if EXPERT  (this I did not expect).

I patched Kconfig to remove the if EXPERT, built it and it worked.  I tested the GPIO and was able to toggle a pin.  I will prep a PR for current and edge.

Kat

Hans, It is a kernel deprecation issue.  There is a possibility that it can be added back dependent on effort required.  I will look into this.
https://www.kernel.org/doc/Documentation/gpio/sysfs.txt
https://www.kernel.org/doc/Documentation/ABI/obsolete/sysfs-gpio
https://www.kernel.org/doc/Documentation/driver-api/gpio/drivers-on-gpio.rst

In the mean time, you may want to look into whether libgpiod can do what you need. ( apt install gpiod).
A reasonable explanation and some instructions for using libgpiod.
https://www.thegoodpenguin.co.uk/blog/stop-using-sys-class-gpio-its-deprecated/

Update: The pull request has been merged and functionality restored (in nightly builds until next release).

I've since become a maintainer for this board. 
I've added the new phy into the build, and it's working well for Linux-5.10y, Linux-5.15y and Linux-5.16y.

A little update regarding 'network performance' since people wrote me the results with our Armbian/Xenial image look too good to be true.
 
So back to the basics: most benchmarks you find somewhere on the internet regarding SBC performance are showing numbers without meaning since they were made in 'passive benchmarking' mode without taking care of what's important.
  What's different on SBCs compared to real servers (be it x86, Sparc, MIPS, ARMv8)? Network and IO performance on cheap ARM SoCs are affected by current CPU clockspeed (that's different on 'real' servers) A benchmarking tool that adds to CPU utilization on a real server in a negligible fashion might max out CPU ressources on a weak ARM SoC so the tool used for benchmarking might bastardize performance numbers itself. Also when acting single-threaded it might in reality test CPU and not network -- true for iperf in most operation modes The OS distribution might use horribly wrong settings (cpufreq governor, IRQ distribution and so on), might contain mechanisms that are counterproductive (screensavers that start after periods of inactivity and influence performance numbers massively) and might be optimized for different use cases (for example on any ARM SoC around CPU and GPU cores share access to DRAM so we already know that by disabling GPU/HDMI on headless servers we automagically improve performance due to less consumption/temperature now leading to better throttling behaviour under load and more memory bandwidth leading to higher throughput numbers for some tasks) Since we already know that common tools like iperf are CPU intensive let's try out the upper and lower clockspeed on Pine64 to get the idea how a wrong cpufreq governor might influence results (switching way too slow from lower to upper clockspeeds when starting short benchmark executions) and how bottlenecked iperf is by CPU anyway.   Results as follows (please remember: this is always the same hardware and test setup, the only real difference is the OS image used!): TX RX Armbian Xenial @ 480 MHz: 630 / 940 Mbits/sec Armbian Jessie @ 480 MHz: 620 / 600 Mbits/sec pine64.pro Jessie @ 480 MHz: 410 / 595 Mbits/sec TX RX Armbian Xenial @ 1152 MHz: 920 / 940 Mbits/sec Armbian Jessie @ 1152 MHz: 920 / 810 Mbits/sec pine64.pro Jessie @ 1152 MHz: 740 / 770 Mbits/sec What does this mean? Obviously the OS image matters. Someone wanting to benchmark Pine64+ and relying on the OS images from their official download location gets 500 Mbits/sec on average while someone choosing our Xenial image gets 930 Mbits/sec on average.
 
So let's switch from passive to active benchmarking mode (monitoring the benchmark itself) and check what's different:
When using Xenial's iperf the tool acts single-threaded only in one direction (TX), with the iperf version in Jessie it's single-threaded in both directions. So by using Jessie you ensure that CPU clockspeed tampers network throughput always in both directions (iperf maxing out one CPU core at 100%) while with Xenial that happens only in TX direction. With Xenial you would also see full 940 Mbits/sec in both directions by adjusting maximum cpufreq from 1152 to 1200 MHz. The performance numbers also show that compiler switches do not affect iperf performance that much when comparing Xenial with Jessie (with other tools like sysbench you get a whopping 30 percent better numbers on Xenial compared to Jessie) The differences between Armbian Jessie and the one from pine64.pro are: my Jessie image is headless while pine64.pro runs a desktop and more importantly that the pine64.pro OS image uses the wrong cpufreq governor (ondemand instead of interactive) which affects standard iperf/iperf3 test execution using the 10s defaults. When using longer test executions benchmark numbers improve but this is obviously the wrong way to handle the problem -- switching to interactive is the real solution With iperf in single-threaded mode you will also see performance differences caused by CPU affinity. If for whatever reasons the kernel decides to assign the iperf task to cpu0 performance numbers might differ compared to running on cpu1 (depends on IRQ distribution). So to get really a clue what's going on you have to monitor IRQ distribution (/proc/interrupts) and assign the benchmark tool to a specific core using taskset to get the idea whether tool and IRQ handling on the same core improve performance or not (since then you could decide whether improving IRQ distribution is worth a try) What do these numbers tell us?
 
iperf/iperf3 are both not able to measure network througput realiably on SBCs since they are too much CPU bound (as used by most people using default window sizes the results are useless anyway) on the other hand that means that actual CPU clockspeeds matters a lot and therefore choosing an inappropriate cpufreq governor results in worse performance (simple solution: switch to performance or interactive with Allwinner's BSP kernel or schedutil on mainline kernel 4.7 or later) Also inapproriate heat dissipation leads to benchmarks showing lower network performance so in case you cramped your Pine64 in a tiny enclosure without using a heatsink you ensure that performance sucks iperf seems to perform better when using Xenial since it behaves differently there (maybe caused by Jessie compiling distro packages with GCC 4.9 while Xenial uses GCC 5.4 instead). So you get better performance numbers by switching from Jessie to Xenial but it's important to understand that this ONLY affects meaningless benchmark numbers! Real world workloads behave differently. Don't trust in any benchmark blindly iperf when used with default settings (that's 10 seconds test execution here) might show weird/random numbers since we have to deal with a a phenomenon called TX/RX delay and cpufreq scaling governor chosen adds to random behaviour. With iperf you should always test 5 times with 10 seconds, then 1 x 60 seconds and 1 x 300 seconds since then you immediately get the idea why ondemand is wrong for this workload and how the other phenomenon might influence results. Use iperf3 also since this outputs 1 second statistics and might report different numbers (so you learn at least to not blindly trust into benchmark tools!) Most important lesson: Try to understand how these iperf/iperf3 numbers correlate with reality and then measure/monitor real world workloads. If you let Pine64 run as a web server for example with Jessie from pine64.pro then with light workloads Pine64 will be magnitudes slower than when using Armbian (remaining at 480 MHz vs. jumping to 1152 MHz when needed)... or switch to interactive governor with the pine64.pro image. The numbers above do not tell you this real difference for this specific use case. It's always important to try to understand what a benchmark actually tells you We at Armbian should ask ourselves whether we will provide desktop images for Pine64 at all (please, please not, let's prevent that our forum gets flooded with all the HDMI and DVI issues and 'why does firefox not play youtube videos?' and crap like that) and whether we make our CLI images 'true headless' (disabling GPU/HDMI like we did with H3 boards since both SoCs are pretty identical in this regard and I would assume that this helps with specific server workloads a lot due to more memory bandwidth, more useable RAM and better throttling behaviour)

Hello, I am looking the way how to create a new board after cloned https://github.com/armbian/build in my local.
 
I am woking on a A20 (allwinner) project.
The Idea is copy the current configuration of eg. cubieboard2 and modify it in order to fit my requirements.
 
I already read the Armbian documentation and I spent 1 day searching in the forum for that receipt. Customize things are pretty easy but no info about how to create a new board.
 
Basically I looking for:
 
1) How and where to clone an existing A20 board configuration locally (in my PC).
2) How to enable locally (in my PC) that new board in the Armbian developtment environment.
3) After the board will be working well I will send a pull request for that new board.
 
Regards
Eric 

@yang is maintaining a list of people that stands up as official board maintainer. AFAIK he is not on the list. He probably don't know that we have change policy of board support since we are just starting to enforce this policy.

I almost forgot. There is also an R2C which has different PHY.
https://github.com/armbian/build/commit/687c3639183e23e06406739af1684fdeb3efa454

We never get to the stage to have a good manual for that since things we changing so much and since we have plan to refactor all this. To make it more simple.
 
Those examples can help (from simple to complex)
https://github.com/armbian/build/pull/3352
https://github.com/armbian/build/commit/f60920a2b776b544c9e37cddec8d495d22e2867c
https://github.com/armbian/build/commit/3c4b69650e9f98edbf7f0a934add1dd19eb14772
 

Its almost identical to Nanopi R2S. This can also help.

Your GPS module may contain a well disciplined temperature compensated RTC and oscillator (most do), and there is a possibility that it may be able to provide accurate PPS output and NMEA time messages for a period even if there is no GPS signal, if programmed to do it.  (This is called holdover mode and some modules can do it, although the affordable ones may not offer this).

Many years ago I made PPS generator with a quartz xtal in an oven composed of a large TO220 transistor clamped to the xtal and surrounded by polystyrene.  The transistor was it's own temperature sensor, and the simple circuit maintained a steady temperature.  An 8048 programmed in assembler divided the oscillator down to 1Hz and added an extra unit to the division every now and then to compensate for the quantization error to get a final drift of about 4 parts per million.

The oven used the same principal as the link below, but the bigger transistor gave a better thermal coupling.  Something like this could provide stable temperature for any RTC.  https://www.romanblack.com/xoven.htm

A few months back I came across something interesting on David Taylor's web site.
A shell script to control the temperature of a SBC using the heat generated by the CPU.
Of course if your clock oscillator is integrated into the CPU then this is a way to control it's temperature and theoretically get more accurate time.
I tried this and it worked really well with a few tweaks.  I liked it so scripted it as a service.
I'm getting a maximum offset of less than +-20 micro seconds

http://www.satsignal.eu/ntp/Raspberry-Pi-ntpheat.html
 
#!/usr/bin/env python # # Requires python3 # generate some heat! # # Run ntpheat in the background. # It will try to stabilize the CPU temperature at 54C by default. # Sometimes one copy of ntpheat can use 100% of one CPU and #!/usr/bin/env python # # generate some heat! # # Run ntpheat in the background. # It will try to stabilize the CPU temperature at 54C by default. # Sometimes one copy of ntpheat can use 100% of one CPU and # still not heat up your Pi as much as you want. The temptation # is to add more insulation to your Pi, but then it will overshoot # your target temperature if your load factor goes high. # # The solution is to run more than one copy of ntpheat. This is # easy to do with the -c option. # # To run 3 copies of ntpheat: ntpheat -c 3 import argparse import hashlib import os import sys import time # Work with argvars parser = argparse.ArgumentParser(description="make heat") parser.add_argument('-c', '--copies', default=[1], dest='copies', help="Number of copies to run. Default is 1", nargs=1, type=int) parser.add_argument('-t', '--temp', default=[57.0], dest='target_temp', help="Temperature to hold. Default is 57.0", nargs=1, type=float) parser.add_argument('-w', '--wait', default=[0.001], dest='wait', help="Set delay time in seconds, default is 0.1", nargs=1, type=float) args = parser.parse_args() args.copies[0] -= 1 while args.copies[0]: args.copies[0] -= 1 pid = os.fork() if pid: # I am the fork break zone0 = '/sys/class/thermal/thermal_zone0/temp' cnt = 0 m = hashlib.md5() temp = 0 max_cnt = args.wait[0] * 100000 # on a RasPi 3 the temp steps seem to be about 0.537 to 0.539C temp_gate = args.target_temp[0] while True: # on a RasPi 3, 200,000 of the m.update() can be one second delta = temp_gate - temp if 0 < delta: # heat it up my_str = "Time is an illusion. Lunchtime doubly so." my_enc = my_str.encode('utf-8') m.update(my_enc) else: cnt = max_cnt # cools off slower than it heats up. # undocumented Python 'feature', no sleep less than 1 milli Sec sleep = args.wait[0] * 10.0 * -delta if 0.001 > sleep: sleep = 0.001 time.sleep(sleep) cnt += 1 # read the temperature every max_cnt if max_cnt < cnt: cnt = 0 zone_data = open(zone0, 'r') for line in zone_data: temp = float(line) / 1000 zone_data.close() The service file: ntpheat.service - if you don't know how to set up a systemd service then go here https://wiki.debian.org/systemd/Services
[Unit] Description=ntpheat [Service] ExecStart=/usr/bin/ntpheat.sh Restart=on-failure [Install] WantedBy=multi-user.target  

 
I should add:  To make the CPU based temperature control work, there must be no CPU intensive processes at all.  This means disabling any cron jobs that load the CPU or forcing them to use less CPU over a longer period.
To do this you need cgroup-tools
 
#spread out heating caused by scheduled maintenance on NTP server #get package sudo apt-get install -y cgroup-tools #create a cpu group called cpulimit sudo cgcreate -g cpu:/cpulimit #set cpulimit group limit to 100000uS out of 1000000uS (= 10% of CPU cycles) sudo cgset -r cpu.cfs_period_us=1000000 cpulimit sudo cgset -r cpu.cfs_quota_us=100000 cpulimit #check settings sudo cgget -g cpu:cpulimit #to limit your process start it as follows - sudo cgexec -g cpu:cpulimit YOUR_COMMAND
You can use this to run CPU intensive jobs at 10%
To reconfigure some cron jobs:
 
/etc/cron.d/armbian-updates @daily root cgexec -g cpu:cpulimit /usr/lib/armbian/armbian-apt-updates
Some cron jobs run scripts:
#for some cron scripts: /etc/cron.daily/apt-show-versions cgexec -g cpu:cpulimit apt-show-versions -i /etc/cron.daily/sysstat cgexec -g cpu:cpulimit exec /usr/lib/sysstat/sa2 -A Apt xapian index is a hog...  limit it to 5%
#create a cpu group called cpulimit5 (for 5% CPU) sudo cgcreate -g cpu:/cpulimit5 #set cpulimit group limit to 25000uS out of 500000uS (= 5% of CPU cycles) for bad process. sudo cgset -r cpu.cfs_period_us=500000 cpulimit5 sudo cgset -r cpu.cfs_quota_us=25000 cpulimit5 /etc/cron.weekly/apt-xapian-index - comment out all except top line and replace with cgexec -g cpu:cpulimit5 /usr/sbin/update-apt-xapian-index
 

I understand that boards without maintainer must be dropped. But, the announcement leaves me somewhat puzzled. I would like to learn which boards need new maintainers. The pull request is not really answering this. Do we have a list of boards with current and missing maintainers? Maybe post a link to it here. This could help people to get involved.

At the moment these boards have no maintainer:
 

Hi gounthar,
Sorry that I'm way to late to this party.  But if you are still interested.... 

I've built a GPS disciplined time server using ESP8266.  Jitter is way too high, the onboard oscillator is jittery and the WiFi module has variable latency.

I'll link you to a tutorial that I wrote for GPS discipline on OrangePi zero (should work for other boards to)
I get jitter of less than +- 20 microseconds with temperature control at 57 degrees C  about +-60 microseconds without temperature control.

EDIT: I read my tutorial again and note that you already responded to it. 
I'll leave this here in case it's useful to others finding your thread.
 

A few months back I came across something interesting on David Taylor's web site.
A shell script to control the temperature of a SBC using the heat generated by the CPU.
Of course if your clock oscillator is integrated into the CPU then this is a way to control it's temperature and theoretically get more accurate time.
I tried this and it worked really well with a few tweaks.  I liked it so scripted it as a service.
I'm getting a maximum offset of less than +-20 micro seconds

http://www.satsignal.eu/ntp/Raspberry-Pi-ntpheat.html
 
#!/usr/bin/env python # # Requires python3 # generate some heat! # # Run ntpheat in the background. # It will try to stabilize the CPU temperature at 54C by default. # Sometimes one copy of ntpheat can use 100% of one CPU and #!/usr/bin/env python # # generate some heat! # # Run ntpheat in the background. # It will try to stabilize the CPU temperature at 54C by default. # Sometimes one copy of ntpheat can use 100% of one CPU and # still not heat up your Pi as much as you want. The temptation # is to add more insulation to your Pi, but then it will overshoot # your target temperature if your load factor goes high. # # The solution is to run more than one copy of ntpheat. This is # easy to do with the -c option. # # To run 3 copies of ntpheat: ntpheat -c 3 import argparse import hashlib import os import sys import time # Work with argvars parser = argparse.ArgumentParser(description="make heat") parser.add_argument('-c', '--copies', default=[1], dest='copies', help="Number of copies to run. Default is 1", nargs=1, type=int) parser.add_argument('-t', '--temp', default=[57.0], dest='target_temp', help="Temperature to hold. Default is 57.0", nargs=1, type=float) parser.add_argument('-w', '--wait', default=[0.001], dest='wait', help="Set delay time in seconds, default is 0.1", nargs=1, type=float) args = parser.parse_args() args.copies[0] -= 1 while args.copies[0]: args.copies[0] -= 1 pid = os.fork() if pid: # I am the fork break zone0 = '/sys/class/thermal/thermal_zone0/temp' cnt = 0 m = hashlib.md5() temp = 0 max_cnt = args.wait[0] * 100000 # on a RasPi 3 the temp steps seem to be about 0.537 to 0.539C temp_gate = args.target_temp[0] while True: # on a RasPi 3, 200,000 of the m.update() can be one second delta = temp_gate - temp if 0 < delta: # heat it up my_str = "Time is an illusion. Lunchtime doubly so." my_enc = my_str.encode('utf-8') m.update(my_enc) else: cnt = max_cnt # cools off slower than it heats up. # undocumented Python 'feature', no sleep less than 1 milli Sec sleep = args.wait[0] * 10.0 * -delta if 0.001 > sleep: sleep = 0.001 time.sleep(sleep) cnt += 1 # read the temperature every max_cnt if max_cnt < cnt: cnt = 0 zone_data = open(zone0, 'r') for line in zone_data: temp = float(line) / 1000 zone_data.close() The service file: ntpheat.service - if you don't know how to set up a systemd service then go here https://wiki.debian.org/systemd/Services
[Unit] Description=ntpheat [Service] ExecStart=/usr/bin/ntpheat.sh Restart=on-failure [Install] WantedBy=multi-user.target  

 
I should add:  To make the CPU based temperature control work, there must be no CPU intensive processes at all.  This means disabling any cron jobs that load the CPU or forcing them to use less CPU over a longer period.
To do this you need cgroup-tools
 
#spread out heating caused by scheduled maintenance on NTP server #get package sudo apt-get install -y cgroup-tools #create a cpu group called cpulimit sudo cgcreate -g cpu:/cpulimit #set cpulimit group limit to 100000uS out of 1000000uS (= 10% of CPU cycles) sudo cgset -r cpu.cfs_period_us=1000000 cpulimit sudo cgset -r cpu.cfs_quota_us=100000 cpulimit #check settings sudo cgget -g cpu:cpulimit #to limit your process start it as follows - sudo cgexec -g cpu:cpulimit YOUR_COMMAND
You can use this to run CPU intensive jobs at 10%
To reconfigure some cron jobs:
 
/etc/cron.d/armbian-updates @daily root cgexec -g cpu:cpulimit /usr/lib/armbian/armbian-apt-updates
Some cron jobs run scripts:
#for some cron scripts: /etc/cron.daily/apt-show-versions cgexec -g cpu:cpulimit apt-show-versions -i /etc/cron.daily/sysstat cgexec -g cpu:cpulimit exec /usr/lib/sysstat/sa2 -A Apt xapian index is a hog...  limit it to 5%
#create a cpu group called cpulimit5 (for 5% CPU) sudo cgcreate -g cpu:/cpulimit5 #set cpulimit group limit to 25000uS out of 500000uS (= 5% of CPU cycles) for bad process. sudo cgset -r cpu.cfs_period_us=500000 cpulimit5 sudo cgset -r cpu.cfs_quota_us=25000 cpulimit5 /etc/cron.weekly/apt-xapian-index - comment out all except top line and replace with cgexec -g cpu:cpulimit5 /usr/sbin/update-apt-xapian-index
 

Orange Pi Zero NTP Stratum 1 PPS GPS Server with Armbian OS.
Link to the Tutorial - http://schwartzel.eu3.org/ntp-stratum1.html

This tutorial uses a 3.3V capable GPS module with PPS output - TOPGNSS GN-701 (u-blox 7) but other similar modules should work.

 
This tutorial is for the Orange Pi Zero, but will probably work for other boards.

 

I couldn't easily do a comprehensive hardware and software tutorial on this forum, so I've published it on my web server and linked from here and attached a PDF.
Link to the Tutorial - http://schwartzel.eu3.org/ntp-stratum1.html

Tutorial PDF
ntp-stratum1.pdf

If you spot any typo's or errors please let me know.
 

Hi @Elektrický,
Nice tutorial, worked great for me. Bought a cheap GPS module:

 
And a pinheader to solder onto the OrangePi Zero board itself.

 
The only thing I had to change was to swap the RX/TX wires, as a straight connection did not work for my GPS board.


 
I did not have any success getting PPS to work through the USB connection (works as ttyACM). I had to use the GPIO dtb overlay and electrical connection as per your tut.
gpsd in action:

 
ntp[sec] in action:

 
Thanks a lot!
Groetjes,
 
p.s. I still have to figure out why I needed this

Orange Pi Zero NTP Stratum 1 PPS GPS Server with Armbian OS.
Link to the Tutorial - http://schwartzel.eu3.org/ntp-stratum1.html

This tutorial uses a 3.3V capable GPS module with PPS output - TOPGNSS GN-701 (u-blox 7) but other similar modules should work.

 
This tutorial is for the Orange Pi Zero, but will probably work for other boards.

 

I couldn't easily do a comprehensive hardware and software tutorial on this forum, so I've published it on my web server and linked from here and attached a PDF.
Link to the Tutorial - http://schwartzel.eu3.org/ntp-stratum1.html

Tutorial PDF
ntp-stratum1.pdf

If you spot any typo's or errors please let me know.
 

Thanks @Guidol,  I had the same issue with Orange Pi Zero Plus. 

One showed Cpu Temp And Cpu Frequency.  Two did not show the options.
~/.config/htop/htoprc was blank on the two that did not work.
Changing settings on htop did not populate the file and settings were lost between sessions.
File permissions were the same for all three.
I copied the working htoprc to the other two and this solved the problem.

Orange Pi Zero NTP Stratum 1 PPS GPS Server with Armbian OS.
Link to the Tutorial - http://schwartzel.eu3.org/ntp-stratum1.html

This tutorial uses a 3.3V capable GPS module with PPS output - TOPGNSS GN-701 (u-blox 7) but other similar modules should work.

 
This tutorial is for the Orange Pi Zero, but will probably work for other boards.

 

I couldn't easily do a comprehensive hardware and software tutorial on this forum, so I've published it on my web server and linked from here and attached a PDF.
Link to the Tutorial - http://schwartzel.eu3.org/ntp-stratum1.html

Tutorial PDF
ntp-stratum1.pdf

If you spot any typo's or errors please let me know.
 

Orange Pi Zero NTP Stratum 1 PPS GPS Server with Armbian OS.
Link to the Tutorial - http://schwartzel.eu3.org/ntp-stratum1.html

This tutorial uses a 3.3V capable GPS module with PPS output - TOPGNSS GN-701 (u-blox 7) but other similar modules should work.

 
This tutorial is for the Orange Pi Zero, but will probably work for other boards.

 

I couldn't easily do a comprehensive hardware and software tutorial on this forum, so I've published it on my web server and linked from here and attached a PDF.
Link to the Tutorial - http://schwartzel.eu3.org/ntp-stratum1.html

Tutorial PDF
ntp-stratum1.pdf

If you spot any typo's or errors please let me know.
 

This topic continues here with the solution: