jscax

Did some cleanup here.
 
  
 
Might be slightly off-topic but I won't serve anything via WiFi lol.

Hello, I am wondering what is the current status of wifi on Orange Pi Zero 2? Is it working? If yes then on which release? If not then what are the current problems related to this? Is somebody working on it? How one could help to make it working?
 
I am asking because I am a little bit confused because of this
This topic is more than 2 years old but I see no update.

I run Armbian_5.30_Orangepizero_Ubuntu_xenial_default_3.4.113 in my zero.
I add headset in jack， A noise start with system boot and never stop，I try play music with pygame, at first can play with noise, and system crash soon.
I have to reboot it by power line.

The OPi Zero doesnt need much power.
I only disabled the Wifi - because I do use Ethernet - with the following commands in the /etc/rc.local (I know are are also other/better ways):
 
ifconfig wlan0 down rmmod xradio_wlan rmmod mac80211 rmmod cfg80211  

Hi guys,
some months ago I implemented an Odroid C2 as readout controller for a scientific instrument.
Lot of people were kind and helped me with some problems with Armbian, especially eMMC and PWM.
 
Today, finally, we managed to have our instrument (two strings with several Odroid C2 and other stuff) deployed.
It is sitting now at 2628m depth in the Pacific Ocean, and will go operational the next days.
 
Here we are... I think I can announce the deepest Odroid so far (cry loud if I'm wrong :) )
In the picture you just can see the Titanium housing with two glass covers attached to the string.
 
Again, thanks for the fish :)
 
Michael

If @jscax is using a default/legacy image it's pretty easy to lower DRAM clockspeed with 'h3consumption -D'. And yes, undervoltage might be the culprit (the Micro USB nightmare).

It is applied. Perhaps in some rare cases, even this adjustment might not be enough? And powering with microUSB ?

If a board crashed or freezes nothing will be written to syslog so searching for the strings that appeared in the logfile long before the crash/freeze happened is pretty much useless.
 
We provide diagnosis tools, check the output of 'armbianmonitor -m' yourself (maybe post a few lines after an hour of operation) and please post the output from 'armbianmonitor -u' (since without no one has a clue which branch and kernel you're running and so on).
 
@Igor: Is this patch not applied any more? https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sunxi/adjust-default-dram-clockspeeds.patch#L244

Random crashes are usually related to DRAM clocked too high. Your DRAM configuration might be below average quality and ... the second option is DVFS, which is also not done properly yet. Setting to fixed CPU speed might help. For first you need to recompile u-boot with lower DRAM speed, second, you need to adjust /etc/default/cpufrequtils

Hi,
 
Thank you for your interest, you won't be disappointed. You have probably read that the developer want to do some changes - and some of this changes are now ready to get tested in the BETA's of armbian.
 
Do not test with your 'production' SDcard unless you have done a backup ;-)
 
Once done that, please go to 'armbian-config' System  switch to BETA (Nightly), do an update/upgrade, reboot, check if your system still performs as before.
If it does work like before - please let us know and post your 'armbianmonitor -u' link If it doesn't work, please try a reboot, check if the problem is reproduceable and if so  explain the steps to reproduce it and post your 'armbianmonitor -u' link  
If you like to know what has changed or is changing:
Kernel upgrade for Allwinner boards. NEXT is 4.17.y and it's getting daily updates. (LIB_TAG="sunxi-4.18" in our build system)
https://forum.armbian.com/topic/7398-bsp-scripts-rfc/
https://forum.armbian.com/topic/5565-zram-vs-swap/
https://forum.armbian.com/topic/6444-varlog-file-fills-up-to-100-using-pihole/
 
This is not all, see details on GitHub look at the shell code - which makes this happen - more eyes less errors
 
And if you want to try a fresh install, look for the nightly created 17. June https://dl.armbian.com/
 
Thank you in advance for your support
 

Thanks for the response. I took the path of least resistance and tested it on a Raspberry Pi Zero. On that platform I can edit the /boot/config.txt to change the I2C speed. It maxes out at 400Khz no matter what value you give it. That's fast enough to do decent animation:
 
 
I wrote a blog post and shared the code on github:
 
http://bitbanksoftware.blogspot.com/2018/05/practical-animation-on-i2c-ssd1306.html
 

No. If you are using, for example, a H3 based device, a recent enough Armbian image and want to change frequency of the I2C controller 1, you need to install kernel headers, create a file (i.e. "i2c1-change-frequency.dts")
/dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target = <&i2c1>; __overlay__ { clock-frequency = <200000>; }; }; }; and add it via "armbian-add-overlay"
 
Or for testing purposes just decompile, change and recompile the DT in /boot/dtb using dtc. Since there will be no node labels you'll have to check the original DT for node names, i.e. I2C 1 node would be named "i2c@1c2b000".

A method the infrared reception and the infrared transmission for which lirc isn't used by this page is introduced.
http://feijoa.jp/laboratory/raspberrypi/infrared/
So I tried whether it work using OrangePi-PC.
It work fine.
 
$ cc scanir.c -o scanir -lwiringPi -lpthread
$ sudo ./scanir tv_on.ir
write file: tv_on.ir
scaning pin: 7 (wiringpi)
max keep time: 40(ms)
Infrared LED scanning start.
Pressed Ctrl+C, this program will exit.
Scanning has been done.
$ ls -l tv_on.ir
-rw-r--r-- 1 root root 476 Jun 26 07:56 tv_on.ir
$ cc sendir.c -lm -o sendir -lwiringPi -lpthread
$ sudo ./sendir tv_on.ir 1 14
read file: tv_on.ir
output pin: 14 (wiringpi)
unit: 26ms duty:9-17
send infrared signal.
send data.
done
 
 
scanir
The first argument is file name of output.
The second argument is The pin number of Infra red sensor.(The pin number of WiringPi, Default is 7.)
The third argument are the biggest duration. When infrared rays didn't light up more than this time, the biggest duration considers a transmission from a remote control to end, ends the reading and extracts a file.
 
sendir
The first argument is file name of read.
The second argument is repeat counter.
The third argument are The pin number of Infra red transmitter.(The pin number of WiringPi)
The fourth argument are Frequency of transmit signal.
The fifth argument are Molecule compared with duty
The sixth argument are denominator compared with duty.

Yeah, YS-IRTM is working ok using the OPI Zero UART (thanks armbian ), now I can control my TV.
 
The problem is that YS-IRTM works with NEC protocol only.
I actually need to control a Samsung AC unit which uses Samsung protocol.
 
YS-IRTM ==> https://www.aliexpress.com/item/5V-IR-Infrared-Remote-Decoder-Encoding-Transmitter-Receiver-Wireless-Module-IR-Decoder-Module/32528109291.html
 
http://www.datasheetcatalog.com/info_redirect/datasheet/nec/UPD6122G-002.pdf.shtml => UPD6121 ====> NEC only
 
Differences between IR remote protocols:
http://www.techdesign.be/projects/011/011_waves.htm
 
NEC:

 
SAMSUNG:

 
So, I was guessing that maybe GPIO can handle this kind of specific 1/0 switching and timing.
And should be great if does exist a library for this, because seems like something very standardized.
 
I'd expect something like:
Ir ir = new Ir() ir.setGpioPin(x) ir.sendSamsung(hexcode)  
But maybe it's all wrong

Looks like that module has a UART (serial) interface, not I2C
 
The aliexpress page doesn't say anything about how it communicates over the serial connection.
 
There's a forum thread here about it: https://forum.arduino.cc/index.php?topic=359707.0

uooohhhh!!!!!   What a tiny "big" CPD!!!!!  ;-) Thank you very much, guidol. It is a very good reference for me.  Now, I have moved my orange pi zero plus H5 to a very  open-space ( it was inside a very closed furniture before.... ). I have moved it behind my plasma TV ;-).  And now, almost idle, temperature is in normal values ( with 21C room temperature ):
 
root@zeus:~# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
22:02:28:  816MHz  0.36  10%   1%   1%   3%   3%   0% 47.2°C  0/2
22:02:33:  816MHz  0.33   4%   1%   2%   0%   0%   0% 44.4°C  0/2
22:02:38:  816MHz  0.31   2%   1%   1%   0%   0%   0% 45.0°C  0/2
22:02:43:  816MHz  0.28   2%   1%   1%   0%   0%   0% 42.2°C  0/2
22:02:49:  816MHz  0.34   2%   0%   1%   0%   0%   0% 44.3°C  0/2
22:02:54:  816MHz  0.31   3%   1%   2%   0%   0%   0% 45.3°C  0/2
22:02:59:  816MHz  0.29   2%   1%   1%   0%   0%   0% 46.2°C  0/2
22:03:04:  816MHz  0.34   2%   0%   1%   0%   0%   0% 43.0°C  0/2
22:03:09:  816MHz  0.32   6%   1%   5%   0%   0%   0% 47.2°C  0/2
22:03:14:  816MHz  0.29   2%   1%   1%   0%   0%   0% 44.5°C  0/2
22:03:19:  816MHz  0.27   3%   1%   1%   0%   0%   0% 43.9°C  0/2
22:03:24:  816MHz  0.25   3%   1%   1%   0%   0%   0% 45.4°C  0/2
22:03:29:  816MHz  0.23   2%   1%   1%   0%   0%   0% 44.9°C  0/2
22:03:34:  816MHz  0.21   5%   1%   3%   0%   0%   0% 45.4°C  0/2
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
22:03:39:  816MHz  0.19   2%   1%   1%   0%   0%   0% 44.2°C  0/2
22:03:44:  816MHz  0.17   2%   1%   1%   0%   0%   0% 44.6°C  0/2
22:03:50:  816MHz  0.16   3%   1%   1%   0%   0%   0% 44.3°C  0/2
 
I use my OP Zero for NAS Server ( samba/nfs ) and for p2p downloads with mldonkey.
 
You can see my brico-project with an old celeron heatsink ( I am very worried with temperatures, perhaps I am a little friki... ):
 

you could.... by reading this thread..

I think Xunlong should be able to make a Orange Pi Zero with 512MB RAM and Gigabit ethernet for around $10. If they did, would you buy it? Do you think it would be a good product?
 
The H2/H3/H5 is capable of gigabit ethernet, they just need an external ethernet chip that costs about $1.
If you think about it. To go from an Orange Pi PC which has 1GB RAM @ $15, to an Orange Pi 2E with 2GB RAM $35, thats more than double the cost to double the RAM.
But if you go from an Orange Pi Zero with 100Mbit ethernet at $9 to 1000Mbit ethernet at $10, that's only a 0.1X increase in cost for a 10X increase in performance. That means you get about 10.5x more value for money (performance) by upgrading the ethernet vs upgrading the RAM.

For many years Raspberry Pi (and alternatives) fans have wanted a low cost SBC with good IO capabilities. RaspberryPi has never delivered.
Now Xunlong have come and provided us the Orange Pi 2E (thanks to Tkaiser's suggestion), it's got gigabit ethernet, lots of RAM and 4 real USB ports. It's great.
But now if you want a cheap SBC with powerful IO, currently the only option is FriendlyArm NanoPi Neo2. But that board costs much more than necessary at $15 (if you just want IO) because it uses the H5 chip.
One application is a router. Routers need a lot of IO, but not that much RAM usually. But it depends. Some routers deal with massive IPsets and do deep packet inspection VPN, VoIP and all kinds of stuff.
 
So let's see who else thinks a Orange Pi Zero with 512MB RAM and Gigabit ethernet would be a good idea?

Also another suggestion is I've seen comments that the H2 supports about 130 GPIO's. But there are only a few of them exposed on the 40 PIN RbPi style GPIO header.
The new Orange Pi Zero can expose all the GPIO without much extra size as 0.1" spaced holes on the PCB, without increasing the cost much.
That's another very cheap way to increase the IO capabilities and make this product really competitive with other options for people who need IO.
To keep everyone happy, if the additional GPIO are placed at the end of the PCB, the few modders who care about a few mm of space and want a really tiny PCB can just cut the end off (at their own risk)

Edit:
I edited the questions so my answers got a bit messed up, but I won't edit the questions again.

Yes, for PC, https://github.com/duxingkei33/orangepi_PC_gpio_pyH3
For Zero, there someone who forked it and adjusted the mapping.h for few Zero pins differences, but I can't remember the link.
 
EDIT : I've finally found it for Zero : https://github.com/nvl1109/orangepi_PC_gpio_pyH3
 

Context: I implemented a GPIO driver in Golang for A64 running armbian using memory mapped registers leveraging /dev/mem. Will test on H3 as soon as I receive my board. The main improvement over sunxi-pio is that I implemented edge based triggering leveraging sysfs gpio, since interrupts are not accessible in user mode yet polling sucks.
 
I realized the /dev/gpiomem concept (at least as implemented by Raspbian) is not applicable on (some) Allwinner processors (at least on A64 and H3) because they require 2 separate sections to be memory mapped to access all the pins. GPIO belonging to group PB to PH use the registers located at 0x01C20800 and group PL uses registers located at 0x01F02C00. So I'll forget on this gpiomem idea for now. And since Pine64 has PL pins on its PI2 header, it's really important to be able to access this group.
 
That's annoying as this requires me to run my app as root for the foreseeable future, which is really a downer.
 
---
 
<random rant>
 
Allwinner CPUs has only a subset of pins supporting edge based triggering: in groups PB, PG, PH and PL, unlike bcm283x which supports it on all pins. On the other hand, you can query the current pull resistor on any pin on Allwinner, unlike bcm283x which is a black box. You can't have it all...

Hi guys!
After moving my project from Raspberry to Orange i`ve got an issue with gpio access.
I`m using Lighttpd as webserver and running python scripts from touching buttons there.  But on armbian it doesn`t work because of permissions settings.
here is screenshot of simple script that turns on led
tried lots of google finds, but without any success.
What is wrong?
oh, i`m using pyA20 library 

Thanks for pointing it out! I'll fix it today. --> fixed
 
 
 
See:
 

Interesting, I'll have a look at it this when I'm back at home (tested it on 3.4.113 Kernel weeks ago).  Would be nice to see a copy of the error but I'll try to reproduce your error (I've a OPi0).
 
The whole project started cause I wanted a lib which works without changing code between my OPi0s and my OPi+PC. Setup.py will have a cleanup in the future. 

The pyA20 gpio library is quite famous when people start to play with gpios , spi or i2c on sunxi boards but mapping needs often adjustments to work on your own board. This situation is not really friendly for 'beginners'.  pyGPIO should help to make armbian a little bit more 'IoT friendly'. 
I didn't touch the 'backbone' of pyA20, so the syntax should be similar to its original (except pinname when using port instead of connector). 
 
How can I use this library:
Cause all of this boards have (more or less) the same pinheader (sometimes other pins are deployed on the pinheader) pyGPIO tries to unify the mappings, so that code can be shared and deployed on all boards without touching the code. The mapping follows the pin naming of the RaspberryPi (it's not because I think their naming is perfect, but it should be the easiest way to port code from the 'RPi world' to Armbian.

What is done:
-Initial support for:
OrangePi Zero/PcPlus/Lite/Plus2E NanoPi Duo(with and without Minishield)/Neo Olimex Lime/Lime2/Micro (pins are not renamed PG10,PG11 etc. instead of GPIO2, GPIO3 etc. cause those boards doesn't have a 'RPi Pinheader' Templates for 24,26 and 40 'RPi compatible' pin header -Board detection (when using Armbian) to check if your board is supported
-Manual assignment when your board is not supported (yet) or automatic board detection fails
 
What is not done:
Testing testing testing! Documentation Meaningful examples (still the originals from olimex which wouldn't work anymore)  
What do you need to test the Library:
You need python-dev and the Library which you'll find on my GitHub page. The installation should be easy, just follow the instructions... 
sudo apt-get install python-dev git clone https://github.com/chwe17/pyGPIO.git cd pyGPIO sudo python setup.py install  
Testing is the part where I need help. I don't have most of the boards which are supported (only OPi0 and OPi Pc Plus). I tested I2C and GPIO on the OPi0, for all the rest, I need you as testers, bug hunters, and feedback.
 
Here are two short python snippets which should do the exact same thing (once with connector, you have to run them as root or with sudo otherwise it would not work!):
import os, sys if not os.getegid() == 0: sys.exit('start script as root') from pyGPIO.gpio import gpio, connector from time import sleep gpio.init() gpio.setcfg(connector.GPIOp7, 1) #pin 7 as output n = 0 while n < 5: gpio.output(connector.GPIOp7, 1) sleep(1) gpio.output(connector.GPIOp7, 0) sleep(1) n +=1 sys.exit('finished ;-)') and once with port:
import os, sys if not os.getegid() == 0: sys.exit('start script as root') from pyGPIO.gpio import gpio, port from time import sleep gpio.init() gpio.setcfg(port.GPIO4, 1) #gpio4 as output n = 0 while n < 5: gpio.output(port.GPIO4, 1) sleep(1) gpio.output(port.GPIO4, 0) sleep(1) n +=1 sys.exit('finished ;-)') Annotation: When using NanoPi Duo you've to possibilities with or without Minishield. Pin name is the same on both possibilities but when using port but pin numbering when using connector:
Minishield: 3.3V |1·| 5V GPIO2 I2C0_SDA |3·| 5V GPIO3 I2C_SCL |5·| GND GPIO4 |··| GPIO14 UART1_TX GND |··| GPIO15 UART1_RX GPIO17 SPI1_MOSI |··| GPIO18 GPIO27 SPI1_MISO |··| GND GPIO22 SPI1_CLK |··| GPIO23 SPI1_CS 3.3V |··| NC (on mini shield) Without (e.g. connector.J1p7 or connector.J2p5) : J1 J2 (UART0_RX) |1| microUSB |1| 5V (UART0_TX) |2| |·| 5V GND |3| |·| 3.3V GPIO3 (TWI_SCL) |4| |·| GND GPIO2 (TWI_SDA) |5| |·| GPIO4 (IR_RX) GPIO23 (SPI1_CS) |6| |·| GPIO18 (IOG11) GPIO22 (SPI1_CLK) |7| |·| DM3 D- GPIO27 (SPI1_MISO) |·| |·| DM3 D+ GPIO17 (SPI1_MOSI) |·| |·| DM2 D- GPIO15(UART1_RX) |·| |·| DM2 D+ GPIO14 (UART1_TX) |·| |·| RDN (CVBS) |·| |·| RDP (LINEOUT_L) |·| |·| TXN (LINEOUT_R) |·| |·| TXP (MICP) |·| |·| LED-LINK (MICN) |·| microSD |·| LED-SPD Buttons (bigger orange pi boards) are mapped, but I didn't test if it works (mapping here, if somebody is interested in testing them, see mapping.h of your board):
 
{"BUTTON", { { "BUTTON", SUNXI_GPL(4), 1 }, { { 0, 0, 0} }, } },