CliffB

If anyone is still following this then adding a command to rc.local isn't a complete fix. I left the unit running for 7 days without doing anything to it and power management has re-enabled itself again. This would explain why other distros have bodged in cron jobs to periodically disable power management. There must be some re-initialisation mechanism somewhere I presume.

Back at base now, I confirm that Igor's fix in rc.local works here also. armbianmonitor -u output without rc.local fix is at http://sprunge.us/TLVa

I did try this earlier on with the delay again without success and wondered if it was due to a delay in my network connection. However I will try again tomorrow when I'm back at base. Thanks for looking in any case and noted about a generic fix further down the line.

Tried that early on and no difference.

I stated the same early on in the thread and indeed I've already been doing that. The question is how to make the system default to power management off at start up.

Just for information I have tried all of the methods above including the service (in a slightly different form) apart from adding anything into modprobe.d. I was unable to determine the relevant module name and parameters. I am currently travelling but will post the output of armbianmonitor -u when I return on Tuesday,

Thanks for confirming this, not that it was really in much doubt. My pings swing more wildly up to a second or so probably due to the quality of my connection. Since I have a fix for the problem and along the line it will doubtless get properly sorted I'll focus on my application for the moment.

@zador.blood.stained I have tried many methods but the one with the reported results above was for pure vanilla NM configured using nmtui. For the record I have also tried disabling NM and setting up a traditional interfaces file with wireless-power off both with and without wireless-mode managed and it makes no difference, power management is always shown as enabled. I've tried adding various switches to /etc/NetworkManager/conf.d and a heap of other methods but whatever I try fails to disable power management at start up. Issuing iwconfig wlan0 power off from the command line fixes the problem instantly and iwconfig the reports that power management is off of course. @Bubba I don't believe this is about a noisy or occupied channel, the noise will and doubtless does affect the link of course but the AP is located 10 meters away and the OPi is running 32dBm which is over a Watt! Also after the iwconfig wlan0 power off has been run the ping response magically improves to sub 5ms and is steady and constant. The power management feature is simply disabling the device to save power. If I run a throughput test even with power management enabled I still achieve a reasonable rate (15Mbs) with speedtest-cli. It's just that the ping response becomes unusable for my application. Moving to a new channel may well be sensible with the increased number of WLANs in the area here but it's not the underlying cause. I would however be interested to see you test results for comparison to my OPi Zero H3 Plus 2 both with and without power management enabled. Thanks!

Hi Igor It was absolutely not my intention to put pressure on anyone, I appreciate all the effort you guys have made to get armbian where it is today. So my apologies if that was the impression given. Also I would not adopt DietPi for my purposes due to all the extra 'froth' involved with the distro. My comment was an observation that it did not default to power management being on. Understand that my purposes rely on a stable OS but naturally my thoughts are more trying to program my solution rather than spending time on the OS. None of this is in anyway your problem of course. I thank you graciously for your help and commentary above, all points are noted. It'll all come out in the wash I'm sure. My kids are all grown up, a disadvantage of age I suppose. Or then again maybe it's an advantage

Yup I did find that in the end. However running systool -a -v -m brcmfmac tells me 'Error opening module brcmfmac' On another note DietPi does appear to boot with power management off. Even after changing the setting in interfaces power management remains off. I have tried explicitly enabling it but I'm not after that anyway. I thought that DietPi was based on Armbian so maybe they are some steps behind with an older version? I'd rather use armbian but my time is becoming limited at this point.

I've no idea where to find the module name or parameters I'm afraid. lsmod doesn't yield sufficient information. Any pointers where to look?

Other than adding a cron job to periodically disable the power management I've not found any solution to disable power at boot. Adding a script containing iwconfig wlan0 power off to all the usual places including /etc/network/ifup.d /etc/NetworkManager/dispatcher.d and so on steadfastly does not disable the power management. I have even tried disabling power as the wpa-supplicant configs are processed. I presume that power management can be disabled either at the start of the process (if the driver disables it) or at the very end when the interface is configured, up and connected. What else should I be looking at at this point?

For the record setting 'wifi.powersave = 2' in '/etc/NetworkManager/conf.d/default-wifi-powersave-on.conf' doesn't work, power management is still enabled. Sigh. Just realised the other file zz-override-wifi-powersave-off.conf has the value set to 2 but in any case it still doesn't default to power save off.

Edit: I disabled power management with iwconfig wlan0 power off Pings are now consistent at <5ms with the odd sub 50ms ping. I need to disable power management all the time or understand and fix the issue when it's enabled. Here is the information requested before power management was disabled. I'm using a 3A USB PSU (5.2V), the same PSU supplied with an RPI 3 root@orangepizeroplus2:~# iwconfig lo no wireless extensions. wlan0 IEEE 802.11 ESSID:"NMIWIFI" Mode:Managed Frequency:2.462 GHz Access Point: C8:D3:A3:40:F6:80 Bit Rate=19.5 Mb/s Tx-Power:32 dBm Retry min limit:10 RTS thr:off Fragment thr:off Encryption key:off Power Managementmode:All packets received Link Quality=4/5 Signal level=-65 dBm Noise level=-91 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 root@orangepizeroplus2:~# root@orangepizeroplus2:~# h3consumption -p Active settings: cpu 1200 mhz allowed, 1200 mhz possible, 4 cores active dram 408 mhz hdmi/gpu active usb ports active wlan0 IEEE 802.11 ESSID:"NMIWIFI" Mode:Managed Frequency:2.462 GHz Access Point: C8:D3:A3:40:F6:80 Bit Rate=19.5 Mb/s Tx-Power:32 dBm Retry min limit:10 RTS thr:off Fragment thr:off Encryption key:off Power Managementmode:All packets received Link Quality=4/5 Signal level=-66 dBm Noise level=-91 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 root@orangepizeroplus2:~# I also ran speedtest-cli root@orangepizeroplus2:~# speedtest-cli Retrieving speedtest.net configuration... Retrieving speedtest.net server list... Testing from PlusNet (81.174.156.174)... Selecting best server based on latency... Hosted by Vorboss Limited (London) [2.56 km]: 28.395 ms Testing download speed........................................ Download: 29.36 Mbit/s Testing upload speed.................................................. Upload: 9.38 Mbit/s root@orangepizeroplus2:~# And here's the ping test from my Windows dev machine C:\Users\cliffb.UIT>ping 10.236.0.60 -t Pinging 10.236.0.60 with 32 bytes of data: Reply from 10.236.0.60: bytes=32 time=880ms TTL=64 Reply from 10.236.0.60: bytes=32 time=3ms TTL=64 Reply from 10.236.0.60: bytes=32 time=298ms TTL=64 Reply from 10.236.0.60: bytes=32 time=5ms TTL=64 Reply from 10.236.0.60: bytes=32 time=1486ms TTL=64 Reply from 10.236.0.60: bytes=32 time=2ms TTL=64 Reply from 10.236.0.60: bytes=32 time=1513ms TTL=64 Reply from 10.236.0.60: bytes=32 time=3ms TTL=64 Reply from 10.236.0.60: bytes=32 time=2054ms TTL=64 Reply from 10.236.0.60: bytes=32 time=3ms TTL=64 Reply from 10.236.0.60: bytes=32 time=946ms TTL=64 Reply from 10.236.0.60: bytes=32 time=6ms TTL=64 Request timed out. Reply from 10.236.0.60: bytes=32 time=229ms TTL=64 Ping statistics for 10.236.0.60: Packets: Sent = 14, Received = 13, Lost = 1 (7% loss), Approximate round trip times in milli-seconds: Minimum = 2ms, Maximum = 2054ms, Average = 571ms Control-C ^C C:\Users\cliffb.UIT>

I should probably start a new thread for this but it seemed appropriate to post here at this time of nght.. So the OPi Zero Plus 2 boards arrived and I duly set up the image on a 8GB SD card, connected the serial TTL to USB adapter and booted. Everything came up fine so I set up the wifi to my local network using nmtui. Again no problems. I did an apt-get update and upgrade and rebooted, all OK again. Having SSHed into the device I get very sluggish performance and pinging from another machine on the lan I see hugely variable pings ie variations from a few ms to over a second. I installed wavemon and it shows a very strong wifi signal (as expected). The pings are when the OPi is quiescent so no heavy loads to cause issues AFAICT. I read that the earlier wifi chip with the Pi Zero has issues but thought that the AP6212(A) was stable and reliable? Is there anything I have missed in the set up? By way of comparison a RaspPi Zero W yields very stable low ms pings. Forgot to say the installed version. uname -a output below Linux orangepizeroplus2 3.4.113-sun8i #18 SMP PREEMPT Thu Jun 15 02:16:06 CEST 2017 armv7l armv7l armv7l GNU/Linux

I've looked at almost all of the available boards and have used some of the earlier generation in the past. Power isn't a problem for my application as it will be mains powered. That said tkaiser's report of a 700mW OPi Zero is interesting however it has no eMMC as standard. I even considered using an ESP8266 but it is too basic for my purposes. I have used an ESP8266 as a wifi enabled fan controller for refrigeration cooling. It seems to me that a stable Linux distro running on many platforms (thank you armbian!) makes an attractive starting point, especially where options like audio I/O and even video I/O are also possible. I am platform agnostic but as an old hardware designer who then had to program his creations I know the benefit of a standard platform with a stable, core OS.

If I get 10 spare samples I'd be happy to. I'm told that size always matters but in this case if I was going to use a larger board I might just use a Pi 3 and be done with it. The power connector is a non issue as whatever board I use will plug into a motherboard. At $18 or so an OPi Zero Plus 2 is a reasonable compromise, in any case I've ordered two so the decision is made. I'll hold off completing my motherboard PC until I've evaluated the OPis although I'm sure they'll be fine. Considering the first incarnation of the project some years ago used an Atmel Mega with a CS8900 and used a version of the uIP stack any modern Pi or Pi clone will make the development process total luxury programming and hardware wise.

I emailed sales@banana-pi.com and received a reply from HailyMei in their China office. Since they appear not to provide any valid information or respond to your (or others) data requests it would appear that quietly dropping them off the radar is the most appropriate action for users like me at least.

QED I don't rely on anyone's comments, but some feedback is more useful and valued than others. I came across the BPI-R1 issues after I had ordered the damn thing, hence my initial post about the BPI Zero. For the record they replied to my email saying the OS 'wasn't yet ready' and the board wasn't available in the UK but I could order one for 15 USD. I'm looking forward to the OPI offering arriving.

chwe's test should yield useful information although it's on a sample of one unit of course. I don't want to use the OPI-Zero original as I intend running from onboard eMMC but since the price is so low anyway I may order a couple. I have already stepped off the fence and ordered two of the OPi Zero Plus 2 boards. I'm more comforted that at least there are a range of OPi boards with similar footprints. Having looked into my current PCB design I noticed that the pin layout for the OPi is different from the Pi Zero W in that odd number pins are on the edge of the PCB rather than it being the even numbered pins like the Pi Zero W. This doesn't make any difference electrically, just mechanically so I'm redoing my CAD in any case. it's no big deal to change it before boards are made. I note that the Nano Neo Air has the pins physically arranged as per the Pi Zero W. I'll try and allow for a Neo Air to be a pluggable option as well albeit with the PCB extending the other way over the main board. The low current consumption of the original OPi-Zero is attractive as is a network port but since it's relatively easy to just install and configure an OS using an SD card and then move it to eMMC I'd rather have the option of an HDMI socket as it opens up other possibilities in the future. tkaiser's comments re the Banana Pi products (camera interface being incompatible for instance) have steered me away from them.

I didn't realise that the heat issue was related to the original OPI Zero but having re-read the posting I see that it was. I did see the thread regarding the change from AP6212 to AP6212A however and the comments in this thread have put my mind at rest. High speed connectivity isn't required for my unit but stability is. The links to the tests indicate that wifi perfomance is more than adequate. I shall go with the OPI-Zero Plus 2 for the moment and change the design to suit. Thanks again for the comments.

Thanks for all the replies. For the record my project isn't multimedia based, it simply needs a stable (reliable!) armbian (or whatever) headless environment with wifi connectivity, SPI and GPIO. I would stick with the PI Zero W if it were possible to buy them in quantities greater than one at a time and yes, I know the risks of using a PI Zero (W) rather than a PI Compute module etc. I'm not looking for huge quantities, even five at a time would be a start. Hence the BPI-Zero would be attractive if it provided the same header interface assuming the relevant drivers isolate the hardware from my application. From tkaiser's comments, and having fought the BPI-R1 (please don't reopen the debates about it, I'm trying to forget how much time was wasted before I dumped it), I think it's probably best I give the BPI-Zero a miss, at least for now. I have seen and considered the Orange PI Zero (Plus 2) but recent postings about hardware v1.4 having heat issues and earlier versions have flaky wifi devices steered me away from it. The Nano Neo Air is something I have considered assuming the wifi is stable now (think that's been the case for some time) however comments on the armbian download page such as ‘Out of memory’ (OOM) issues are possible due to a kernel bug do not full me with confidence about stability. If someone can persuade me that the Nano Neo Air is stable I'll alter my PCB design to support it as well as the Pi Zero W You guys do a great job with supporting these various boards so a thanks from me for that at least.

Hi all, this is my first posting although I've been following armbian for some time. Hopefully this is the right forum area... Does anyone know the availability (or otherwise!) and cost of the Banana Pi Zero? It looks like a board clone of the Pi Zero W but with a different processor. Secondly will/does armbian support it assuming it is available? I have a project using the Pi Zero W but of course they are only available in one off quantities. Cliff