DoubleHP
-
Posts
46 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by DoubleHP
-
-
WORKS FOR ME
It was my VERY LAST try before giving up completely:
https://www.uugear.com/portfolio/read-dht1122-temperature-humidity-sensor-from-raspberry-pi/
fix the ping to 7 (instead of 3 in the source), compile with
cc -Wall dht.c -o dht -lwiringPi -pthreadand it does the job:
Quote./dht
Raspberry Pi DHT11/DHT22 temperature/humidity test
Humidity = 46.0 % Temperature = 23.5 *C (74.3 *F)
Humidity = 37.9 % Temperature = 27.4 *C (81.3 *F)
Data not good, skip
Data not good, skip
Data not good, skip
Data not good, skip
Humidity = 37.5 % Temperature = 27.2 *C (81.0 *F)
Data not good, skip
Data not good, skip
Humidity = 37.7 % Temperature = 27.2 *C (81.0 *F)
Data not good, skip
Humidity = 37.6 % Temperature = 27.2 *C (81.0 *F)
Humidity = 37.6 % Temperature = 27.2 *C (81.0 *F)
Data not good, skip
Data not good, skip
Data not good, skip
Data not good, skip
Humidity = 37.6 % Temperature = 27.2 *C (81.0 *F)
Data not good, skip
Humidity = 37.7 % Temperature = 27.2 *C (81.0 *F)
Humidity = 37.6 % Temperature = 27.3 *C (81.1 *F)
Data not good, skip
Humidity = 37.7 % Temperature = 27.3 *C (81.1 *F)
Data not good, skip
Data not good, skip
Data not good, skip
Humidity = 37.6 % Temperature = 27.2 *C (81.0 *F)
Humidity = 37.6 % Temperature = 27.3 *C (81.1 *F)
Data not good, skip
Data not good, skip
Data not good, skip
Humidity = 37.7 % Temperature = 27.3 *C (81.1 *F)
Humidity = 37.6 % Temperature = 27.3 *C (81.1 *F)
Data not good, skipAccording to other forums, 60% misses is ordinary for this probe.
Note that the very first value is completely wrong; I did not read anything about this, but I am not surprised. CO2 probes need 15 pre heat; and this is the very first successfull read of the probe, so some miss-configuration or badly initialised variable are likely. So, on production line, I will take care to ignore the first 3 values after service start/reboot.
-
For example, I see a /lib/modules/./4.13.16-sunxi/kernel/drivers/iio/humidity/dht11.ko , how can I try using this ?
-
Hello.
First, I have an LTS board that provides only 3.05 on the 3.3 pins. Is it normal ?
Anyway, in case this was the issue, I have built a new voltage regulator, and now supply the DHT22 and pullup resistor with 3.60V
My issue is simple: when plugged on normal 1W bus, the DHT22 kills the bus, and makes other devices non working. I have moved all other devices on a new bus, leaving the DHT on a bus I know works fine. Some people mentionned the DHT is not compliant with official 1W libraries, and can not be recognised with normal timings, so, special libs are required. I have removed param_w1_pin=PA06 for the hysical pin 7, and installed new software.
I have a very bad experience with python, and I have never been able to make any python lib/project, on any board of any brand; I always get some error at some point.
The only non python lib/app for DHT22 I have found is
https://github.com/pilkch/climbatize
but after heavily patching it (to fix various bugs), the app still seems unable to communicate with the probe.
I have checked more than 12 times the sensor is connected to the so called pin 7 (PA06), pin 2 in WiringPi, and changed the physical sensor (paid for a new item).
Who can help reading this probe ? I am just running out of ideas.
The only issue that bothers me is that I am not physically 100% certain that Climbatize manipulates pin7. I have entered the loop that manipulates some pin, but at some point it's calling wiringPi, and my multimeter always shows 3.6V on the pin; I don't have a scope to check the pin goes down, and applying a LED on a pulledup pin will not produce a perceptible OFF time. I would need to solder an inverted gate to transform the logic, but even then, the light pulses may be too short for my eyes.
I really dont think 3.60V could burn the oPi board; and 3.05 could be a huge reason for the DHT22 to refuse to work. I could plug a lab regulated supply, but I think it would be overkill.
I do have spare/new/unused boards; but all my LTS boards deliver 3.05. (yes I have some boards left in 2022; I had bought *MANY* spare ones years ago).
-
Hello; on OrangePi Zero LTS I have completely stupid values for CPU temperature. They were all reasonable for pre-LTS boards. I have read somewhere that this is a known bug. A kernel patch is probably available, but even if it's the case,I can not update my kernel. Where can I find the algorythm to compensate the value ? It's easier for me to fix the issue in userland code, rather than updating kernel.
How can I distinguish between pre-LTS and LTS boards ? Maybe MAC address for LTS are always in a given range ? I have a legacy board with MAC 12:42:98:f9:c8:XX, and a LTS with 12:42:3a:63:04:XX (unfortunately the LTS has a lower MAC :/ does not seem chronological )
-
Yes, much better:
# ls -lha /var/log | grep -e syslog -e message drwxrwxrwx 11 root syslog 660 Oct 19 19:46 . -rwxrwxrwx 1 root root 6.7K Oct 19 20:43 syslogThanks
-
21 hours ago, olivluca said:
I think you have to activate the gpio before loading the modules
I also would perform a sleep 1 or sleep 3 between the two. GPIO handling may take some time, on chipset side. If the pins we talk about are power, or ENABLE pins for the client, even longer time may be required (for internal firmware to startup).
Before complaining /dev/video0 does not appear, you need to report the output of dmesg, which gives details about what driver found ... or not.
Also check 10 times your sunxi line; many tuto may give wrong addresses; and sometimes even for the same board, different libs may use different numbering schemes ... (had the issue on rPi).
-
# df -h | grep log
armbian-ramlog 50M 5.7M 45M 12% /var/log# ls -lha /var/log | grep -e syslog -e message
drwxrwxr-x 11 root syslog 660 Aug 11 22:26 .
-rw-r----- 1 root root 0 Aug 11 22:15 syslog# systemctl status syslog
● rsyslog.service - System Logging Service
Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2019-08-11 22:25:49 CEST; 9min ago
Docs: man:rsyslogd(8)
http://www.rsyslog.com/doc/
Main PID: 1042 (rsyslogd)
CGroup: /system.slice/rsyslog.service
└─1042 /usr/sbin/rsyslogd -nAug 11 22:25:49 opi-06-app-c13 systemd[1]: Starting System Logging Service...
Aug 11 22:25:49 opi-06-app-c13 systemd[1]: Started System Logging Service.# ls -lha /var/log.hdd/ | grep -e syslog -e message
drwxrwxr-x 11 root syslog 4.0K Aug 11 22:25 .
-rw-r----- 1 root root 0 Aug 11 22:15 syslog
-rw-r----- 1 root root 28M Mar 4 06:25 syslog.1
-rw-r----- 1 root root 212K Mar 3 06:25 syslog.2.gz
-rw-r----- 1 root root 2.9M Mar 2 06:25 syslog.3.gz
-rw-r----- 1 root root 1.9M Mar 1 06:25 syslog.4.gz
-rw-r----- 1 root root 791K Feb 28 06:25 syslog.5.gzit probably worked at some point ... forgot what I did to break it ...
-
I have completely reinstalled the system.
Beh ... I don't understand the difference.
image: Armbian_5.75_Orangepione_Debian_stretch_next_4.19.20.7z
BOARD_NAME="Orange Pi One" BOARDFAMILY=sun8i VERSION=5.75 PRETTY_NAME="Debian GNU/Linux 9 (stretch)" NAME="Debian GNU/Linux" VERSION_ID="9" VERSION="9 (stretch)" ID=debian Linux opi55 4.19.20-sunxi #5.75 SMP Sat Feb 9 19:02:47 CET 2019 armv7l GNU/Linux# aptitude install rcconf sqlite3 sed awk bc munin-node netcat bc socat facter xinit xserver-xor g-video-all xserver-xorg-video-fbdev xinit xserver-xorg-video-all xserver-xorg-video-fbdev aterm xterm wmaker eterm xfonts-base xserver-xorg x11-utils x11-xserver-utils xinput-calibrator xinput dillo munin-plugins-extra zip # startx & # export DISPLAY=":0.0" # cvt 800 480 50 # 800x480 49.69 Hz (CVT) hsync: 24.70 kHz; pclk: 24.50 MHz Modeline "800x480_50.00" 24.50 800 824 896 992 480 483 493 497 -hsync +vsync # xrandr --addmode "HDMI-1" 800x480_50.00 # cvt 800 480 60 # 800x480 59.48 Hz (CVT) hsync: 29.74 kHz; pclk: 29.50 MHz Modeline "800x480_60.00" 29.50 800 824 896 992 480 483 493 500 -hsync +vsync # xrandr --newmode "800x480_60.00" 29.50 800 824 896 992 480 483 493 500 -hsync +vsync # xrandr Screen 0: minimum 320 x 200, current 1280 x 720, maximum 8192 x 8192 HDMI-1 connected primary 1280x720+0+0 (normal left inverted right x axis y axis) 697mm x 392mm 1280x720 60.00*+ 50.00 59.94 1920x1080 60.00 50.00 59.94 1920x1080i 60.00 50.00 59.94 1280x1024 75.02 1440x900 74.98 59.90 1024x768 75.03 70.07 60.00 800x600 72.19 75.00 60.32 56.25 720x576 50.00 720x480 60.00 59.94 640x480 75.00 72.81 60.00 59.94 720x400 70.08 800x480_50.00 49.69 800x480_60.00 (0x6d) 29.500MHz -HSync +VSync h: width 800 start 824 end 896 total 992 skew 0 clock 29.74KHz v: height 480 start 483 end 493 total 500 clock 59.48Hz # xrandr --addmode "HDMI-1" 800x480_60.00 # xrandr -s 800x480_50.00 # xrandr --output HDMI-1 --mode 800x480_60.00Both last commands work ... do not return error.
With the 3.5" LCD, in all 3 cases, I have an image (not fitting edges, but that's offtopic).
And now my 19" monitor also works, but with a trick:
- run xrandr to have an eye at things
- unplug old monitor
- run xrandr to have an eye at things, and check that less resolutions are listed (the only ones left are the current one, and the two manually added ones)
- plug monitor; it may not produce any image
- ask xrandr again to show supported resolutions
- run xrandr -s to set any resolution, even the current one, and then, an image will appear.
5" LCD also worked immediately.
So, the main difference I can see between the two attemps is the image used, and kernel. 3.4 vs 4.19
-
What's the difference between gtf and cvt ?
# gtf 800 480 60 # 800x480 @ 60.00 Hz (GTF) hsync: 29.82 kHz; pclk: 29.58 MHz Modeline "800x480_60.00" 29.58 800 816 896 992 480 481 484 497 -HSync +Vsync cvt 800 480 60 # 800x480 59.48 Hz (CVT) hsync: 29.74 kHz; pclk: 29.50 MHz Modeline "800x480_60.00" 29.50 800 824 896 992 480 483 493 500 -hsync +vsync # xrandr --newmode "800x480_50.00" 24.50 800 824 896 992 480 483 493 497 -hsync +vsync xrandr: Failed to get size of gamma for output default root@orangepione:~# xrandr --addmode "default" 800x480_50.00 xrandr: Failed to get size of gamma for output default xrandr: cannot find mode "800x480_50.00" # xrandr xrandr: Failed to get size of gamma for output default Screen 0: minimum 1280 x 720, current 1280 x 720, maximum 1280 x 720 default connected 1280x720+0+0 0mm x 0mm 1280x720 0.00*How to addmode 800x480 ?
BOARD_NAME="Orange Pi One"
Image: Armbian_5.75_Orangepione_Ubuntu_xenial_default_3.4.113_desktop.7z
I have a correct image using a 3.5" HDMI LCD (without using GPIO/SPI at all); but when I plug a 5" or 19", they say "no signal". I am surprised by two facts:
- pi unable to probe monitors correctly over HDMI
- 5" LCD designed for rPi unable to accept a modline the opi sends (a modline that is 100% acceptable for the 3.5").
-
Mike R9FT, I have huge doubts ... you claim to be able to make things work with Armbian_5.27.170521_Orangepione_Ubuntu_xenial_dev_4.11.1.7z , but you quote "overlays=spi-spidev" which is a kernel v3 specific option, and ignored by kernels v4 ...
After adding sun8i-h3-spi-ads7846.dts , my /dev/fb0 goes away.
orangepi zero
4.14.18-sunxi
user_overlays=myili9431
-
On 3/28/2019 at 9:43 AM, r3mu5 said:
Hi! Did anybody solved the problem with gc2035?
At last, I have found something that works, and produces images. In short, use ubuntu_lxde_desktop_OrangePipc_v0_9_1.img . Long story is here: http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=4270&page=1&extra=#pid25253
Edit: I also suceeded with image Armbian_5.75_Orangepione_Ubuntu_xenial_default_3.4.113_desktop.7z
-
-
On 3/28/2019 at 9:43 AM, r3mu5 said:
Hi! Did anybody solved the problem with gc2035?
$ uname -a
Linux orangepipcplus 4.19.20-sunxi #5.75 SMP Sat Feb 9 19:02:47 CET 2019 armv7l armv7l armv7l GNU/LinuxIn short, there is no hope to get the camera working on 4.x kernels, because they don't have CSI support ATM. I did not get it to work yet, but, first, grab something using 3.4.x kernel. Spent 3 days on it, still stuck.
Also, try gc_2035 ... just in case ... or with dash ... not sure.
-
dd
I am not. Many other people have issues with armbianEnv.txt, and with other files dues to sync issues.
After fixing the issue for this file using my scripts, I don't encontour any other issue on oPi0.
-
Here are core parts of my service:
Makefile:
TARGET = /etc/cron.d/armbian_env_txt_checker all: install install: $(TARGET) $(TARGET): Makefile bash -c "echo -e \"# file generated by $$(pwd)/$<\" >$@" bash -c "echo -e \"@reboot\troot\t/srv/doublehp/share/armbianEnv_txt/armbianEnv_txt_checker.sh\" >>$@" touch $@/srv/doublehp/share/armbianEnv_txt/armbianEnv_txt_checker.sh
#!/bin/bash [ ! -f /usr/sbin/armbian-config ] && exit 0 sleep 90 ref=/srv/doublehp/share/armbianEnv_txt/armbianEnv.txt.ref file=/boot/armbianEnv.txt loc="${file}.local" backup="${file}.backup.$(/bin/date +%Y-%m-%d_%H-%M-%S)" broken="${file}.broken.$(/bin/date +%Y-%m-%d_%H-%M-%S)" previous="$("ls" "${file}.backup."* | sort | tail -n1)" # is current file valid ? #cat "$file" | grep -e "overlay_prefix=sun8i-h3" >/dev/null && { cat "$file" | grep -e "rootdev=UUID=" >/dev/null && { #file is good. # create local ref if none [ ! -e "$loc" ] && { cp -a "$file" "$loc" } # create backup if none [ "$previous" = "" ] && { cp -a "$file" "$backup" } diff "$file" "$previous" >/dev/null || cp -a "$file" "$backup" true } || { # File is bad [ -e "$previous" ] && { cp -a "$file" "$broken" cp -a "$previous" "$file" reboot exit 0 } [ -e "$loc" ] && { cp -a "$file" "$broken" cp -a "$loc" "$file" reboot exit 0 } # Fallback on ref ... cp -a "$file" "$broken" cp -a "$ref" "$file" reboot } -
On 3/22/2019 at 2:31 AM, pzw said:
Filesystem corruption it can be... Power supply / SD cards are all the same? Have you tried one node with another SD card / power supply?
It could by a bad SD, or broken ext4 ... but fact is ... I had this issue on 100% opis, and, only on this specific file. So, yes there is an issue with ext4; but there is an issue with the way this file is modified. This file is savagely altered by boot or initscripts, without any check. To the point the things introduce twice the same line. The issue may even be in how temp files is handled.
-
On 3/18/2019 at 5:11 PM, Magnets said:
How can I regenerate armbianEnv.txt without doing a reinstall?
edit: pulled it from the .img
Backup the whole system after install.
For this specific file, I keep local backups with dates, and diff them after each reboot. When it looks corrupted, the script restaures the last BU.
-
Hello.
Armbian_5.35_Orangepizero_Ubuntu_xenial_default_3.4.113.7z
Orange Pi Zero 256
I am rading the bootlog via serial console.
[FAILED] Failed to start Load Kernel Modules. See 'systemctl status systemd-modules-load.service' for details.
# systemctl status systemd-modules-load.service â systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; static; vendor preset: enabled) Drop-In: /lib/systemd/system/systemd-modules-load.service.d ââ10-timeout.conf Active: failed (Result: exit-code) since Sun 2018-12-30 00:20:40 CET; 3min 8s ago Docs: man:systemd-modules-load.service(8) man:modules-load.d(5) Process: 167 ExecStart=/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE) Main PID: 167 (code=exited, status=1/FAILURE) Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. Warning: systemd-modules-load.service changed on disk. Run 'systemctl daemon-reload' to reload units. # journalctl -f -b _PID=167 -- Logs begin at Sun 2018-12-30 00:20:45 CET. -- Dec 30 00:20:45 opi-06-app-c13 systemd-modules-load[167]: Failed to insert 'xradio_wlan': Connection timed out Dec 30 00:20:45 opi-06-app-c13 systemd-modules-load[167]: Inserted module 'g_serial' Dec 30 00:20:45 opi-06-app-c13 systemd-modules-load[167]: Inserted module 'xradio_wlan' ^C # cat /etc/modules #w1-sunxi #w1-gpio #w1-therm #sunxi-cir xradio_wlan g_serial xradio_wlanIf I remove any xradio_wlan, then wlan0 is not available at boot.
Is there a way to fix the boot error message, without loosing wlan0 ?
Obviously, some one is aware of an issue, because some dev has put the same line twice in modules ...
-
Random tips :
- orange pi zero all have 2 SPI bus: one in the main GPIO port, and one for the flash on the back side. If you don't have the plus model, you can unsolder the FLASH and use the port. FLASH is port 1, so, GPIO is port 1. This is very important when you follow tutorials written for other opis
- before you start following a tutorial, you need to understand which kernel you are using. If the turial is written after jan 2017, and mentions adding an overlay in armbianEnv.txt, then it's for kernel 4; if the tuto is before feb 2018, and does not mention altering armbianEnv.txt for SPI compatibility, author is using kernel 3. This is critical.
- I got adressable LEDs working on both kernels, 3 and 4. Easier on 4.
- SPI LCDs work only on kernel 3; I have spend days on kernel 4, just forget them; drivers exist, but they are broken.
- con2fbmap is required only on kernel 3
- to get X working, you need to create /etc/X11/xorg.conf.d/99-fbturbo.conf
- check your FB number with a command like this: dmesg | grep ili | grep graphics | grep -i fb . I have seen people using 0, 1 and 8.Now, I have ili9486 working perfectly fine ... with image Armbian_5.35_Orangepizero_Ubuntu_xenial_default_3.4.113 (kernel 3.4.113).
-
What's your distribution and kernel ?
-
Previous time I asked where to report bugs:
New bug:
It's an old bug, met by many people, already reported and fixed by several distros, but, I still had it on a fresh new install:
The problem and the fix:
https://www.raspberrypi.org/forums/viewtopic.php?f=82&t=218609&p=1406567#p1406567
known bugs:
https://bugs.launchpad.net/ubuntu/+source/watchdog/+bug/1448924
https://bugzilla.redhat.com/show_bug.cgi?id=1259816
# systemctl status watchdog.service â watchdog.service - watchdog daemon Loaded: loaded (/lib/systemd/system/watchdog.service; static; vendor preset: enabled) Active: inactive (dead)
echo "WantedBy=default.target" >> /lib/systemd/system/watchdog.service systemctl daemon-reload systemctl enable watchdog reboot # wait 2 mn, because it needs to reboot twice.
# systemctl status watchdog.service â watchdog.service - watchdog daemon Loaded: loaded (/lib/systemd/system/watchdog.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2018-12-21 03:02:14 CET; 58s ago Process: 1122 ExecStart=/bin/sh -c [ $run_watchdog != 1 ] || exec /usr/sbin/watchdog $watchdog_options (code=exited, status=0/SUCCESS) Process: 1120 ExecStartPre=/bin/sh -c [ -z "${watchdog_module}" ] || [ "${watchdog_module}" = "none" ] || /sbin/modprobe $watchdog_module (code=exited, status=0/SUCCESS) Main PID: 1126 (watchdog) CGroup: /system.slice/watchdog.service ââ1126 /usr/sbin/watchdog Dec 21 03:02:14 opi-06-app-c13 watchdog[1126]: int=1s realtime=yes sync=no soft=no mla=5 mem=0 Dec 21 03:02:14 opi-06-app-c13 watchdog[1126]: ping: no machine to check Dec 21 03:02:14 opi-06-app-c13 watchdog[1126]: file: /var/log/syslog:0 Dec 21 03:02:14 opi-06-app-c13 watchdog[1126]: pidfile: no server process to check Dec 21 03:02:14 opi-06-app-c13 watchdog[1126]: interface: no interface to check Dec 21 03:02:14 opi-06-app-c13 watchdog[1126]: temperature: maximum = 80 Dec 21 03:02:14 opi-06-app-c13 watchdog[1126]: temperature: /sys/class/thermal/thermal_zone0/temp Dec 21 03:02:14 opi-06-app-c13 watchdog[1126]: test=none(0) repair=none(0) alive=/dev/watchdog heartbeat=none to=...ce=no Dec 21 03:02:14 opi-06-app-c13 watchdog[1126]: watchdog now set to 10 seconds Dec 21 03:02:14 opi-06-app-c13 watchdog[1126]: hardware watchdog identity: sunxi-wdt Hint: Some lines were ellipsized, use -l to show in full. -
I got an XPT2046 / ILI9486 working on Orange Pi Zero, in portrait mode:
Be carefull: XPT2046 describes the touch layer; it's shared by many many many different LCD that use ... a huge variety of LCD chipsets: ILI9486, ili9340, and many many many more.
-
Update:
I have bought
https://www.fasttech.com/products/0/10020192/5321900-3-5-320-480-tft-lcd-display-touch-board-for
Sold with the following specs:
Quote# SKU MPI3501
# SKU 5321900
# XPT2046
# ILI9486which seems to me very similar to
https://www.amazon.fr/gp/product/B06X191RX7/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1
I started with image Armbian_5.35_Orangepizero_Ubuntu_xenial_next_4.13.16.img
And then, ran the following commands to get the LCD working on oPi0:
aptitude dist-upgrade vim /root/myili9431.dts # see previous message reboot aptitude install linux-headers-next-sunxi armbian-add-overlay myili9431.dts reboot modprobe fbtft_device custom name=fb_ili9486 gpios=dc:18,reset:2 speed=16000000 busnum=1and now I have a console in portrait mode.
# cat /root/myili9431.dts /* author: Adrian Brzezinski: adrb at wp.pl, adrian.brzezinski at adrb.pl */ /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target-path = "/aliases"; __overlay__ { spi1 = "/soc/spi@01c69000"; }; }; fragment@1 { target = <&spi1>; __overlay__ { status = "okay"; spidev { compatible = "spidev"; reg = <0>; spi-max-frequency = <50000000>; }; }; }; };To get X:
# Some of the following packages may be facultative. aptitude install startx xinit x11-xserver-utils xinput-calibrator xinput xserver-xorgxserver-xorg-video-all xterm x11-utils startx # gives a black console # or xinit # gives a white consoleMouse does not work very well. Did not try keyboard. No touchpad (I don't need it, so, no time to loose on this).
Rotation of screen works, but produces crappy output.
# Need reboot each time modprobe fbtft_device custom name=fb_ili9486 gpios=dc:18,reset:2 speed=16000000 busnum=1 rotate=90 modprobe fbtft_device custom name=fb_ili9486 gpios=dc:18,reset:2 speed=16000000 busnum=1 rotate=180 modprobe fbtft_device custom name=fb_ili9486 gpios=dc:18,reset:2 speed=16000000 busnum=1 rotate=270 # 90 and 270 produce a rectangle in landscape orientation; unusable in neither console or X. # 180 works fine.Bed time; more tries later.
Some tips to make conf persistent:
-
I was wrong ... I just found a corruption on my wifi master AP opi, an opi that never does scanning, since it's always in master mode:
# cat /boot/armbianEnv.txt.backup.2018-11-17_22-14-09 verbosity=1 logo=disabled console=both disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=usbhost2 usbhost3 w1-gpio param_w1_pin=PA15 rootdev=UUID=ebe9dacf-124f-486c-b6c1-08749e209374 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u # cat /boot/armbianEnv.txt | hexdump 0000000 6576 6272 736f 7469 3d79 0a31 6f6c 6f67 0000010 643d 7369 6261 656c 0a64 6f63 736e 6c6f 0000020 3d65 6f62 6874 640a 7369 5f70 6f6d 6564 0000030 313d 3239 7830 3031 3038 3670 0a30 766f 0000040 7265 616c 5f79 7270 6665 7869 733d 6e75 0000050 6938 682d 0a33 766f 7265 616c 7379 753d 0000060 6273 6f68 7473 2032 7375 6862 736f 3374 0000070 7720 2d31 7067 6f69 700a 7261 6d61 775f 0000080 5f31 6970 3d6e 4150 3531 720a 6f6f 6474 0000090 7665 553d 4955 3d44 6265 3965 6164 6663 00000a0 312d 3432 2d66 3834 6336 622d 6336 2d31 00000b0 3830 3437 6539 3032 3339 3437 720a 6f6f 00000c0 6674 7473 7079 3d65 7865 3474 000a 0000 00000d0 0000 0000 0000 0000 0000 0000 0000 0000 * 0000120 0000 0000 0000 0000 0000 0000 0000 7500 0000130 6273 7473 726f 6761 7165 6975 6b72 3d73 0000140 7830 3532 3733 303a 3178 3630 3a36 2c75 0000150 7830 3532 3733 303a 3178 3630 3a38 0a75 0000160 7375 7362 6f74 6172 6567 7571 7269 736b 0000170 303d 3278 3335 3a37 7830 3031 3636 753a 0000180 302c 3278 3335 3a37 7830 3031 3836 753a 0000190 000a 0000191Tricky one ... was not visible in cat, only in vim ...
OrangePi Zero LTS vs DHT22
in Beginners
Posted
In case the other website goes down, I will duplicate their original code here. Don't forget to fix your PIN number.
My WiringPi lib is probably https://github.com/zhaolei/WiringOP (not 100% certain).