# Technicavolous

Members

157

## Reputation Activity

1. Technicavolous got a reaction from Jens Bauer in PROVE your power
As in this Armbian forum I am regularly diagnosing power issues. I've answered with this info on a few different posts over the years but I wanted this in one place so my students and the Armbian forum could discuss it.

You will read over and over the importance of good power, both in the supply, the cables, and the connection. Anything that causes the voltage to drop below each boards threshold will cause problems that seem to have no explanation. The board may run and appear to be 'working' but operations that draw more power may fail and let the processor continue running. You might think a fully functional board has software failures. It's hair pulling, especially for those uneducated in power issues.

Without attempting to teach a power class I've come up with some tools that can 'prove' weather the power supply and cables can deliver the power you expect. There's deep math and science to all of it, but what we really need is to be able to 'trust' our power. These tools can help us 'prove' our power is at least staying above the levels we expect.

When there are so many variables in a situation we have to eliminate things to narrow down the problem. Since power is frequently the problem and fairly easy to prove, it's smart to start there. But how? We use our tools to test what we need to eliminate.

We used to use banks of resistors and separate power and current meters to measure power draw and voltage drop, but these days there are inexpensive tools called DC Electronic Loads that do this for us. I've purchased numerous versions and models, and they've all been good at what they are designed for yet lacking in some other things. A trade off of quality for expense, but good enough really is good enough.

Basically they have a transistor and a very low value resistor across the output and your power supply is pulsed with a PWM across that transistor. The width of the pulse determines the current draw on your power supply, effectively 'simulating' power draw from your device while displaying the voltage at the point of the load and the draw current. You simply attach your power supply and increase the load until the voltage drops below the supply's rating. If the voltage stays above its voltage rating at its rated current, it passes. If not, it fails. Almost as simple as that.

I usually let the thing run for a while and check for heating, voltage drop over time and shutdown. Sometimes failure comes with heat.

If you have a 5v power supply that's rated at 4 amps, and your load reports 4.9v at 4A draw, your supply has failed.

The image below shows a successful test of a popular power supply, the Meanwell RD65A., a dual voltage supply rated for 3A at 12v, and 6A at 5v.  As you can see in the photos the voltage stays above its rating at the rated current. This particular photo was taken after approximately 40 minutes running at full load, which is highly inadvisable for this kind of power supply. Usually one would never run over 80% load continuously, but hey, this was a burn test.  The only thing that failed here was the load, as the fan sensors on these particular models are somewhat flawed and overheat at less than their rating and shut down. Both the load and supply were run to their limits and we 'proved' this is a viable supply for our purposes.

Here is an ebay search in the US that has similar inexpensive loads -

and Amazon -

They can be inexpensive and the fancy high power ones can be quite expensive ... find one that suits your needs.

With another voltmeter you can check the drop in your cables. Set up the load to draw what you think is appropriate, note the voltage at the load. Then using the voltmeter measure the voltage at the power supply. Note the difference between the voltage at the supply and the voltage at the load. Viola, there's your drop. Is it good enough to run your board?

Most 5v boards complain at 5v. They want above 5v, like 5.1.

This is only a basic test, you can go a lot further but this will definitely prove your supply or fail it. If you really get into testing get some inline current measuring tools so you can see what your board is actually drawing. Most voltmeters have inline current meters and many are quite accurate and detailed. Watching the current draw on your board as you perform various operations can tell you if you have a hardware problem; if it draws more than the manufacturer specifies then there may well be a hardware issue.

I hope this motivates someone to go farther with testing and proving their power.

Board: Not on the list
2. Technicavolous got a reaction from Werner in armbian orange pi one stuck
does your monitor have an 'auto adjust' ?I had a similar issue where the monitor was underscanning or overscanning or something and 'auto adjust' (from the monitors menu) brought the whole screen into the viewport of the monitor.
3. Technicavolous got a reaction from gounthar in Compiling ffmpeg on the Orange Pi 4B
I am absolutely unqualified to give an answer here but out of curiosity I searched the error and found you may not have to specify an option to use neon?

https://stackoverflow.com/questions/29851128/gcc-arm64-aarch64-unrecognized-command-line-option-mfpu-neon
4. Technicavolous got a reaction from Werner in Orange Pi Zero does not start
Yes I should have thought of that ... but you'd be surprised at what comes in to my student labs!!

5. Technicavolous got a reaction from Werner in RK3328 Kernel
I thought I had edited that out ... total 'oops' moment ...
6. Technicavolous reacted to balbes150 in dist-upgrade?
7. Technicavolous got a reaction from gounthar in THE testing thread
Awesome thanks. Let me know what \$\$ you need. This looks right up my alley hihi I've been a bench tech all my (professional) life.
8. Technicavolous got a reaction from Igor in Updated images for Odroid C4
I submitted an application on the maintainer page for the C4.

9. Technicavolous got a reaction from Francesco Zuliani in Wrong power supply. Board does not start
You have wiped out your input voltage circuit. To be brutally sincere you've probably destroyed the board.

That being said, take a look at the schematics -
http://wiki.espressobin.net/tiki-index.php?page=Schematics

scroll down to page 14 and look at U9 - the regulator ... if all you did was wipe that out, you could replace it. You will need hot air soldering equipment and skills.

HOWEVER, it's my experience that when over voltage is applied to a regulator, many times it fails by passing the power rather than blocking it. There is a good chance that 19 volts was applied to many 1.8 and 3.3 v circuits. In that case your board is toast.

Mark it up to expensive education ... we've all done it. Most of us have plugged 12v into 5v boards that have no regulation. In that case the board is also toast.
10. Technicavolous got a reaction from Igor in PROVE your power
As in this Armbian forum I am regularly diagnosing power issues. I've answered with this info on a few different posts over the years but I wanted this in one place so my students and the Armbian forum could discuss it.

You will read over and over the importance of good power, both in the supply, the cables, and the connection. Anything that causes the voltage to drop below each boards threshold will cause problems that seem to have no explanation. The board may run and appear to be 'working' but operations that draw more power may fail and let the processor continue running. You might think a fully functional board has software failures. It's hair pulling, especially for those uneducated in power issues.

Without attempting to teach a power class I've come up with some tools that can 'prove' weather the power supply and cables can deliver the power you expect. There's deep math and science to all of it, but what we really need is to be able to 'trust' our power. These tools can help us 'prove' our power is at least staying above the levels we expect.

When there are so many variables in a situation we have to eliminate things to narrow down the problem. Since power is frequently the problem and fairly easy to prove, it's smart to start there. But how? We use our tools to test what we need to eliminate.

We used to use banks of resistors and separate power and current meters to measure power draw and voltage drop, but these days there are inexpensive tools called DC Electronic Loads that do this for us. I've purchased numerous versions and models, and they've all been good at what they are designed for yet lacking in some other things. A trade off of quality for expense, but good enough really is good enough.

Basically they have a transistor and a very low value resistor across the output and your power supply is pulsed with a PWM across that transistor. The width of the pulse determines the current draw on your power supply, effectively 'simulating' power draw from your device while displaying the voltage at the point of the load and the draw current. You simply attach your power supply and increase the load until the voltage drops below the supply's rating. If the voltage stays above its voltage rating at its rated current, it passes. If not, it fails. Almost as simple as that.

I usually let the thing run for a while and check for heating, voltage drop over time and shutdown. Sometimes failure comes with heat.

If you have a 5v power supply that's rated at 4 amps, and your load reports 4.9v at 4A draw, your supply has failed.

The image below shows a successful test of a popular power supply, the Meanwell RD65A., a dual voltage supply rated for 3A at 12v, and 6A at 5v.  As you can see in the photos the voltage stays above its rating at the rated current. This particular photo was taken after approximately 40 minutes running at full load, which is highly inadvisable for this kind of power supply. Usually one would never run over 80% load continuously, but hey, this was a burn test.  The only thing that failed here was the load, as the fan sensors on these particular models are somewhat flawed and overheat at less than their rating and shut down. Both the load and supply were run to their limits and we 'proved' this is a viable supply for our purposes.

Here is an ebay search in the US that has similar inexpensive loads -

and Amazon -

They can be inexpensive and the fancy high power ones can be quite expensive ... find one that suits your needs.

With another voltmeter you can check the drop in your cables. Set up the load to draw what you think is appropriate, note the voltage at the load. Then using the voltmeter measure the voltage at the power supply. Note the difference between the voltage at the supply and the voltage at the load. Viola, there's your drop. Is it good enough to run your board?

Most 5v boards complain at 5v. They want above 5v, like 5.1.

This is only a basic test, you can go a lot further but this will definitely prove your supply or fail it. If you really get into testing get some inline current measuring tools so you can see what your board is actually drawing. Most voltmeters have inline current meters and many are quite accurate and detailed. Watching the current draw on your board as you perform various operations can tell you if you have a hardware problem; if it draws more than the manufacturer specifies then there may well be a hardware issue.

I hope this motivates someone to go farther with testing and proving their power.

Board: Not on the list
11. Technicavolous got a reaction from Werner in Wrong power supply. Board does not start
You have wiped out your input voltage circuit. To be brutally sincere you've probably destroyed the board.

That being said, take a look at the schematics -
http://wiki.espressobin.net/tiki-index.php?page=Schematics

scroll down to page 14 and look at U9 - the regulator ... if all you did was wipe that out, you could replace it. You will need hot air soldering equipment and skills.

HOWEVER, it's my experience that when over voltage is applied to a regulator, many times it fails by passing the power rather than blocking it. There is a good chance that 19 volts was applied to many 1.8 and 3.3 v circuits. In that case your board is toast.

Mark it up to expensive education ... we've all done it. Most of us have plugged 12v into 5v boards that have no regulation. In that case the board is also toast.
12. Technicavolous got a reaction from Igor in Do you recommend ODROID-HC1 ?
I have several HC1s in service very long time running armbian with isp-config installed from armbian-config. (Thank you, Igor, armbian-config rocks!)  Very stable and performs excellently. We have one set up as NAS, I believe OMV. It works well but has little load so we never see any stress on it.
13. Technicavolous got a reaction from Igor in mpcie 4g with sim
It works GREAT!
14. Technicavolous got a reaction from TonyMac32 in mpcie 4g with sim
It works GREAT!
15. Technicavolous got a reaction from lanefu in Armbian Certification
WHEN will I be able to take a course here, or series of courses here, and become a Certified Armbian Technician or Certified Armbian Engineer?

May sound odd, but seriously consider the ramifications ...
16. Technicavolous got a reaction from Igor in ODroid XU4 - DVD Drive/ISO9660 Issue
OK tonight I hooked up an old SH-S182 DVDR (+10 yrs) to a usb to ata adapter and had a little trouble reading any disk until I rebooted. When I rebooted with the DVD drive on and attached everything worked as I expected. I did NOT do any editing on /etc/fstab .

I was able to read several burned DVD and CD s I had laying around. It even identified my K-Pax movie although I don't have anything installed with which to play it.

Did you 'plug and try to play?' Perhaps turn the drive on first then boot the XU4 and see if anything id's?

It's nice having a disk drive available to bring things from old CDs and DVDs to USB, so thanks for the exercise! I hope you are able to get yours working, it's not a limitation of the XU4 or Armbian.

technicavolous@odroidxu4:~\$ uname -a
Linux odroidxu4 4.9.61-odroidxu4 #2 SMP PREEMPT Wed Nov 22 16:34:23 CET 2017 armv7l armv7l armv7l GNU/Linux

17.
SOLVED. I got the ethernet ports running using the dev branch of Armbian for the Clearfog then I bridged all the lan port to br0. Then I installed a dhcp server listing to br0. For more detail visit http://superuser.com/questions/1120714/how-make-a-switch-in-linux
where its explained very clearly.
18.
Excuse this double post / push.

But I think I found your problem Techni and a simple solution.

I built a new armbian image using newest kernel and debian and made sure to check the ath10k pci driver option.

Then burned it to my sd card and booted my clearfog -> voila same error as yours in dmesg. And no firmware files in /lib/firmware/ath10k!

A simple apt install firmware-atheros got me the firmware and after a reboot the card is detected and available in ifconfig.

So just try it using lan and install the atheros firmware.

I will also provide my testimage (login: root and 1234) in case you have no network connectivity.
(Upload will take some time, will update this with link when its done...)
EDIT: couldnt get a running image resized from my 64GB SD Card in time. Will try again if you need it...

Greetings,
count-doku

19.
You don't need additional packages (except ifupdown) for a manual network configuration.

Just edit /etc/network/interfaces, you can check here for reference https://wiki.debian.org/NetworkConfiguration
Or have a look at my config attached to this post.

Greets,
count-doku

# Bring up automatically: auto lo auto eth0 auto eth1 lan1 lan2 lan3 lan4 lan5 lan6 br0 # Configure loopback interface iface lo inet loopback # Configure eth0, my outgoing public interface allow-hotplug eth0 iface eth0 inet dhcp post-up iptables-restore < /etc/iptables.up.rules post-up ip6tables-restore < /etc/ip6tables.up.rules # Bring up eth1 manual w/o ip config. This is neccessary to communicate with the switch / dsa iface eth1 inet manual # address 169.254.100.100 # netmask 255.255.255.255 # Do with the SFP Port whatever you want iface eth2 inet manual # Set all switched lan ports to manual iface lan1 inet manual iface lan2 inet manual iface lan3 inet manual iface lan4 inet manual iface lan5 inet manual iface lan6 inet manual # Create bridge over all lanports and ip config them iface br0 inet static bridge_ports lan1 lan2 lan3 lan4 lan5 lan6 address 192.168.1.1 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255
20.
According to my tests this will be fixed in 4.16. Or it can be fixed right now by removing NM and using a different way for configuring networking (ifupdown, systemd-networkd)

Edit: Though I don't have the Pro model so not sure if DSA will still be an issue with NM.
21.
<OT>
First post - so hi everyone and thanks for the great stuff here.
I am new to Armbian, just installed yesterday (replace bananian), migrated everything, fine.
</OT>

It took me several hours to get my 5" LCD display working on Bananapro but it's working now :-) . All the stuff to do it is there, however it wasn't easy for me as a noob to get the relevant items out and to adopt to changes that occurred over time.
So, by summarizing the different steps I'd like to give back - maybe it's useful. If I did not understand correctly, just drop me a note. Of course, dates and version numbers may progress. Full credits to @MartinKeppler and @zador.blood.stained

It's basically 2 steps:
You need a u-boot version that supports the LCD - must be compiled You need a dtb (Device Tree Blob) file that fits to your Kernel and supports pwm (Power for the LCD) ad 1)
You need a Linux x64 PC to compile u-boot.
NOTE: If you want to compile on a Windows 10 Subsystem for Linux, build will fail due to fakeroot incompatibility. You need to replace fakeroot with fakeroot-tcp:
sudo update-alternatives --set fakeroot /usr/bin/fakeroot-tcp Go to https://github.com/armbian/build and follow instructions from README.md (as root) with change in bold:
CREATE_PATCHES=yes tells the compile process to stop after downloading and preparing the sources, so they can be modified when needed (and yes, we need to do that)
This takes a loooong while when run for the first time on a vanilla linux.
Build u-boot and Kernel only (Kernel will not be needed).
The Build process downloads the Sources. So you can only modify them when prompted to do so.
When prompted to modify, change the following files:
build/cache/sources/u-boot/v2017.11/configs/Bananapro_defconfig
For 5" display append the following (or see your params at http://linux-sunxi.org/LCD )
CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:24,pclk_khz:30000,le:40,ri:40,up:29,lo:13,hs:48,vs:3,sync:3,vmode:0" CONFIG_VIDEO_LCD_POWER="PH12" CONFIG_VIDEO_LCD_BL_EN="PH8" CONFIG_VIDEO_LCD_BL_PWM="PB2"  build/cache/sources/u-boot/v2017.11/arch/arm/dts/sun7i-a20-bananapro.dts
build/cache/sources/u-boot/v2017.11/arch/arm/dts/sun7i-a20-bananapi.dts
build/cache/sources/linux-mainline/linux-4.14.y/arch/arm/boot/dts/sun7i-a20-bananapro.dts
build/cache/sources/linux-mainline/linux-4.14.y/arch/arm/boot/dts/sun7i-a20-bananapi.dts
Let the compiler finish u-boot.
You will find build/output/debs/linux-u-boot-next-bananapipro_5.37_armhf.deb
install it on your pi using
sudo dpkg -i linux-u-boot-next-bananapipro_5.37_armhf.deb Step 1 completed.

To create a device specific file fitting to your Kernel and Board, you can recompile your kernel version directly on the PI. I used the guide supplied by @zador.blood.stained
mkdir kernel cd kernel git init . git remote add origin "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git" git fetch --depth 1 origin tags/v4.13.16 sudo git checkout -f FETCH_HEAD  Then edit
arch/arm/boot/dts/sun7i-a20-bananapi.dts and
arch/arm/boot/dts/sun7i-a20-bananapro.dts to include changes from above (add the &pwm section)
Run in the top directory of kernel source tree
sudo cp /boot/config-`uname -r` .config sudo make ARCH=arm dtbs After the process is finished, you should get compiled DT files arch/arm/boot/dts/sun7i-a20-bananapi.dtb arch/arm/boot/dts/sun7i-a20-bananapro.dtb
Copy them to /boot/dtb, reboot and pray.
End of Step 2

DISCLAIMER: It worked for me - however you may end up with a non-bootable SD Card so be careful and have a backup :-)

22. Technicavolous got a reaction from Igor in Why are you using Armbian?
Armbian ROCKS in a classroom environment - everyone has their own board and still things work remarkably similar.  There is very little hardware specific stuff a student needs to differentiate from the instructions given.

May not seem like much, but so far we've got 14 kids to use a board other than a RPi and 'learn linux.' (I think a couple of adults secretly use their kids Odroids late at night ...)
23. Technicavolous got a reaction from Larry Bank in Why are you using Armbian?
Armbian ROCKS in a classroom environment - everyone has their own board and still things work remarkably similar.  There is very little hardware specific stuff a student needs to differentiate from the instructions given.

May not seem like much, but so far we've got 14 kids to use a board other than a RPi and 'learn linux.' (I think a couple of adults secretly use their kids Odroids late at night ...)
24.
Until getting a second adapter, I set off to see if there's anything else that can be done with my current hardware. And... there is.
I managed to make the TinkerBoard my VPN router using Wireguard. It would be similar with OpenVPN, but (see figures above) speeds are not that exciting.

If anyone else is interested, here are the steps. I assume you are using a "standard" setup with your end equipment (laptops, PCs, TVs etc) connected to a router (I have a Netgear R7000), which in turn is connected to a cable modem / fiber modem / any other sort of uplink.
What you need: TinkerBoard (TB for short) running Armbian, power supply, a network cable, case (optional, using the RPI 3 standard one), a WireGuard or OpenVPN connection to a remote endpoint.

1. Install Armbian on the TB.
2. Connect your TB to the router using a wired connection. You will get an IP address, say 192.168.1.5. The router is 192.168.1.1 and your PC is 192.168.1.10.
3. Perform a full update (apt update && apt dist-upgrade) and reboot (you will likely need to power cycle the box, mine doesn't reboot properly).
--> Note: I believe the OpenVPN package in the Armbian is a bit old (I think I saw 2.3.10, current is 2.4); this may give you trouble with some options.
4. Set up your WireGuard or OpenVPN connection on the TB. Note Jason's hint above about removing the ipv6 route. Install the iptables package (apt-get install iptables).
5. Bring up your WireGuard or OpenVPN tunnel. You will get a new interface (called as you wish - we'll use wg0 for the Wireguard one and tun0 for the OpenVPN).
So far so good, all standard steps. Now comes the slightly trickier part.
6. On your router, in the DHCP options (this typically sits in the LAN chapter, YMMV), set the default gateway (the one which gets sent out to clients) to 192.168.1.5 (the IP of the TB).
7. On the TB, issue the following commands to enable packet forwarding:
echo 1 > /proc/sys/net/ipv4/ip_forward /sbin/route add default gw 192.168.1.1 dev eth0 /sbin/iptables -A FORWARD -i wg0 -o eth0 -j ACCEPT /sbin/iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE Above - eth0 is the router's interface which carries the IP address 192.168.1.1. wg0 is the Wireguard interface on the TB (tun0 would be VPN one).
If you want to make the changes permanent, edit /etc/sysctl.conf for ip_forward and add the iptables and route lines somewhere (I'm lazy, so I've put them in rc.local)

8. Reconnect your computer to the LAN (replug the cable, ipconfig /release and /renew and so on). Your gateway should now be 192.168.1.5 (instead of the old 192.168.1.1
9. Try pinging a remote host, should work. Try a traceroute, the first hop should be 192.168.1.5, the second 192.168.1.1, the third your Wireguard/OpenVPN remote end.
10. If you have any special routes declared on the old router, you will need to carry them over to the Tinkerboard. For instance, add the necessary commands to rc.local (yes, lazy).
11. If everything works, don't forget to make your tunnel start automatically, prior to any iptables / route invocations. OpenVPN starts as a service, for Wireguard I've set a manual call in (no surprise...) rc.local.

The result: I'm maxing out my Internet connection (200+ Mbps down) while using Wireguard. In order to do that with OpenVPN, I would have needed an i3 (at least, if not an i5) processor.  I'm happy.
Thanks to the Armbian team, to Jason for Wireguard, to Mullvad.net for providing the testing infrastructure.
25. Technicavolous got a reaction from wildcat_paris in XU4 Hangs at SSH key regeneration
Every time I check entropy it is a 4 digit number, but sometimes is less than 4096, one time was 1200 something. I never even knew 'entropy' was part of the kernel. I thought it was space and time but that's another forum ;]