immutability

malvcr: I faced similar levels of frustration even with the trivial DS18B20 temperature sensors after moving it from a 5V arduino to Orange Pi about a year ago. There are some of my older posts in this thread. This is a small parasite-powered network of 3 sensors in our office, the longest cable being about 2 meters. I was able to make the network work mostly OK after switching to a 1k pull-up resistor but I was facing very odd surges on 2 of 3 sensors. The surges occurred several times a day and usually ranged from 0.25 to 0.6 degrees above the "true" reading and the troubling part for me was that the CRC was always correct so I was unable to filter these out-of-range values out. Sometimes (but more rarely) a surge of 1°C or even more would appear (less than once a day). I was unable to find the exact cause, I tried custom builds of the W1 driver to play with the bus timing etc but to no avail. Besides these random surges, there were others that usually appeared at time when the CPU temp also went some 10 degrees up - but again, I was unable to reproduce this when I tried to overload the CPU for testing. Anyway I gave up and my personal conclusion was to also use a dedicated ATtiny or something similar as the one-wire master to interface with the Pi for future projects. For this particular one, the last resort was to switch from a parasite-powered network to a regular power line and ever since then the temperature charts were absolutely smooth (see the attached before/after screenshots from thingspeak). But the most frustrating part was of course not being able to pinpoint the actual cause

Thank you for your patience with me I scanned through the application note and it all makes sense now. It reports correct temperatures with a 1k pull-up, 2k2 didn't work just like the 4k7. I'll keep testing and will see how it goes.

Thanks for the response! Now I'm a little confused - I thought this was possibly a software driver issue (the w1 module) rather than a hardware issue? I have the same HW setup working on the arduino with parasitic power (albeit on 5V and not 3.3V). And in this testing layout, there is a single sensor connected on very short leads. I don't really remember the low-level details of the OWI communication (it's been a while since I last fiddled with the protocol itself) but I thought it's mostly about the delays (but I may be completely wrong - it's been a few years).

Hello everyone! I have a question on using w1 sensors with parasitic power mode. I'm trying to replace an older setup with a network of dallas DS18B20 sensors (parasitic power, currently using arduino+ethernet shield) with a OPI Lite running Armbian. Since the OPI Lite is already deployed I'm testing this on a spare OPI PC+ running Armbian 5.25 with the legacy kernel. However, with the parasitic power mode, I'm always getting either false readings (failed CRC) or readings with a valid CRC but a temp value of 85000 (85°C). Here's what I did: enabled the following modules: w1-sunxi, w1-gpio, w1-therm, reviewed script.bin (using bin2fex) to verify the w1 pin. connected the DS18B20 with a regular powered wiring to 3.3V / GND and pin 37 (GPIO 20) for the data (plus the 4.7k pull-up) - verified it worked OK this way and reported valid temperatures by listing /sys/bus/w1/devices/28-xxxxx/w1_slave changed the wiring by shorting out the power/GND pins of the DS18B20, keeping the data line as before and connecting it to 3.3V through the 4.7k pull-up - device is still listed but no more temperature readings. I haven't changed the CPU frequency and lscpu lists CPU min as 480MHz. I'm aware of the 2 threads with w1 driver modifications here and here but I'm not sure if any of those changes have been merged into the "official" driver (I'm assuming not) and if the parasitic mode is even supposed to be working reliably with what's included without these modifications? Thanks for any hints. Here's my /proc/version and armbian-release output: PS: I've seen a control/power file under the w1 slave devices (the DS18B20) sensor so I was also wondering - do I possibly have to change some w1 bus settings in the driver to support the parasitic power mode? I googled but couldn't find any pointers.

@zador.blood.stained - thanks for these ideas! The first one, systemd-analyze blame, reported 1min 3.879s networking.service so I'm guessing it was waiting for eth0 all this time, as (according to the power consumption) the wireless was not being brought up until after the long wait (there's a visible spike in current consumption). So I tried commenting out eth0 in /etc/network/interfaces and voila! It went down to: 2.855s networking.service, and the overall boot time went down to about 12 seconds, excellent! I forgot to mention I'm booting from the internal eMMC but that's irrelevant now. Thank you so much again for all your help guys!

Thanks for sharing those links, very good reading! For my project, I plan to power on the OPI only once a day to perform its task, send the data over (a photo, hence the choice of OPI with its budget CSI camera module) and power off (by disconnecting DC voltage). Controller would be an ATtiny in power-down sleep with RTC, so this way I hope to achieve the battery life in the weeks range, as this will be a birds nest in a remote location. So I'm not so concerned about the long-term idle consumption as long as it boots quickly, does it job, etc. That said - I don't want to get too off-topic, but what is the typical boot time for Armbian 5.16 on an Orange Pi? In my case it takes about 80 seconds to boot, but there seems to be an idle period between the 20 and 70 second mark. The logs look something like this: [ 7.074242] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=remount-ro [ 7.310713] Adding 131068k swap on /var/swap. Priority:-1 extents:1 across:131068k SS [ 7.772098] ip_tables: (C) 2000-2006 Netfilter Core Team [ 7.794153] nf_conntrack version 0.5.0 (16003 buckets, 64012 max) [ 7.843567] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 8.638005] systemd-journald[178]: Received request to flush runtime journal from PID 1 [ 8.919436] gmac0: probed [ 8.919755] gmac0 gmac0: eth0: eth0: PHY ID 00441400 at 0 IRQ poll (gmac0-0:00) [ 19.320045] eth0: no IPv6 routers present [ 71.261063] ADDRCONF(NETDEV_UP): wlan0: link is not ready

Thank you for pointing me to the thread and the commented armhwinfo example - this works nicely! Happy to have learned something new in the process. Edit: A small update - after taking some more precise readings, the actual "powered off" current on my OPI PC+ seems to be about 13 mA (the one I previously referred to as "near zero"). This value was taken using a DMM at the ground pin. My previous readings were from a simple Chinese USB "pass-through" meter.

Thanks tkaiser! I have enabled the firewall in the meantime so there was a bunch of other modules, but I have disabled it for this test and double-checked that lsmod only lists 8189fs. This time the idle current was 330 mA, but doing rmmod -f 8189fs took it down to 230 mA and - seeing this - I expected that doing a poweroff would reduce it to zero (and it did). So can there be anything done about this, or just stick with a workaround of scripting a rmmod before the poweroff?

I ordered OPI PC+ as a testing device for a potential battery/solar powered project (using OPI Lite/One later on) and while testing the built-in WiFi on OPI PC+, it seems it's not possible to power it off once enabled, or perhaps I'm doing something wrong. If the wlan0 entry in /etc/network/interfaces is commented out, the idle current is roughly 210 mA, and after issuing sudo poweroff, it drops to near zero. With wlan0 enabled, the idle current is roughly 310 mA, but after powering off, it drops to about 100 mA and stays that way until disconnected from DC. Attempting to do sudo ifconfig wlan0 down does not seem to change anything (wireless goes down, but the idle current remains at 310 mA and poweroff current remains at 100 mA). I'm not sure how other devices behave (I'm new to both Orange Pi as well as Armbian) but it doesn't seem OK. Is there a way to power off the on-board RTL8189 somehow, or could this be a potential bug? Thanks for any guidance in advance! Edit: I forgot to mention I installed the Jessie server 5.14 / kernel 3.4.112 image and then did sudo apt-get update followed by sudo apt-get upgrade so dpkg now reports 5.16 for the sun8i packages. The only hardware connected to the board is the GC2035 camera for testing, but the only module currently enabled in /etc/modules is 8189fs.

I know this is an older topic, but after facing very similar symptoms and spending frustrating hours trying to figure it all out, the forum search pointed me to this discussion. I was also encountering random failures to boot, and incidentally, it almost always worked when I moved to the living room and connected the HDMI. Just wanted to share my story in case it would help someone: In my case the issue turned out to be hardware related. On my desk, I was powering the OPI PC+ via the GPIO pins over some wires with crocodile clips while taking current readings. The contact resistance was enough to cause a brownout during boot, with the voltage at OPI dropping to some 4.3 V (voltage at the 5V/2A adapter was about 4.9 V). With the same adapter connected directly to the GPIO pins with no extra wires or crocodile clips, it works nicely.