Jump to content

Orange Pi PC 1-Wire


sgarcia05

Recommended Posts

Hi all,

I have similar issue with DS18B20 on Orange Pi Zero (Armbian_5.24_Orangepizero_Debian_jessie_3.4.113)

I connect sensor (data PA10(pin 26), 3,3V (pin 17), GND (pin 25),

Enable /etc/modules (w1-sunxi, w1-gpio, w1-therm),

and I can see SN of sensor after reboot but CRC check fails as indicated by the word NO

 

I change the long wired sensor for a new TO92 DS18B20, same issue.

 

 

What is positive is the fact that

With the first sensor, I tried dozen of times.

 

The correct return happened two times only.

 

An other point is the fact that, immediately after a reboot, I can see the sensor with a NO CRC. If I check every few seconds, the return is the same. If I wait 30 second the 28-03168815dfff directory disapears! It requires a reboot the come back.

 

Sorry for my english.

 

Just yesterday versed with setting 1-wire at Orange Pi Zero, 1 had a similar situation from 15-20 times able to read the temperature sensor value in the remaining cases was CRC error. As we found out with the aid of logical bus analyzer, sensor responds correctly, but probably on the side of the reception Orange PI Zero passed incorrectly. Based on the time intervals in the diagram I had a hypothesis that because of the implementation of the pseudo 1-wire, when it is switched to the port after the transmission to the reception frequency and low CPU - 240MHz, the switching time is great enough to move the point of reading the data bit. Raising the minimum CPU frequency up to 480MHz, I got a stable and correct result of reading data from the sensor.

Accordingly, I advise you to try it.

Link to comment
Share on other sites

@ Man of war @ Martinavotte

 

Super, this way seems easier to implement compare with a workaround solution of additionnal script to stress cpu.

As newbie, I will find the way to speed up this frequency this weekend and be back for results.

Link to comment
Share on other sites

Hi folks!

sudo nano /etc/default/cpufrequtils
------------------------------------------------
eNABLE=true
MIN_SPEED=480000
MAX_SPEED=1200000
GOVERNOR=interactive
------------------------------------------------
dran@orangepizero:~$ sudo cat /sys/bus/w1/devices/28-03168815dfff/w1_slave
f1 00 4b 46 7f ff 0c 10 ac : crc=ac YES
f1 00 4b 46 7f ff 0c 10 ac t=15062

It works !

 

Thanks, have a good week-end

:)

Link to comment
Share on other sites

Some new

last armbian upgrade has broken my temp measurement system

After DHCP redirecting I recover the SSH link

My DS18B20 was still missing in /sys/bus/w1/devices

 

It seems that the upgrade has changed the /etc/modules-load.d/modules.conf

 

#gpio_sunxi
i2c-bcm2708
w1-sunxi
w1-gpio
w1-therm
i2c-dev
#sunxi-cir
xradio_wlan
xradio_wlan

 

Then I changed it as follow

 

#gpio_sunxi
#i2c-bcm2708
w1-sunxi
w1-gpio
w1-therm
#i2c-dev
#sunxi-cir
#xradio_wlan
#xradio_wlan

 

and it works now.

 

dran@orangepizero:~$ bash -x premscript.sh
++ head -2 /sys/bus/w1/devices/28-03168815dfff/w1_slave
++ tail -1
+ VarTemp='9a 00 4b 46 7f ff 0c 10 a2 t=9625'

 

An interesting point is the fact that I tried again a 240 MHz cpu frequency and it seems to works also.

The upgrade seems to solve this former issue.

 

File: /etc/default/cpufrequtils
ENABLE=true
MIN_SPEED=240000
MAX_SPEED=1200000
GOVERNOR=interactive

 

dran@orangepizero:~$ bash -x premscript.sh
++ head -2 /sys/bus/w1/devices/28-03168815dfff/w1_slave
++ tail -1
+ VarTemp='9a 00 4b 46 7f ff 0c 10 a2 t=9625'
+ VarTemp=9625
++ bc
+ VarTemp=9.625
+ echo 9.625

Link to comment
Share on other sites

I did the kernel upgrade to 3.4.113-sun8i on my Orange Pi One three days ago and did not have any problems.  I don't have the i2c driver in my modules.conf file and don't think it was there in the initial Armbian install.  Do you know if your old Orange Pi Zero install included this line?  The following is the contents of my modules.conf:

 

# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
 
8189es
#gpio_sunxi
w1-sunxi
w1-gpio
w1-therm
#gc2035
Link to comment
Share on other sites

Hi,

 

I have a OrangePI Plus 2 board and 2xDS18B20 sensors. All is Ok with kernel 3.4.113-sun8i, but yesterday I build a image with last dev kernel 4.10.

 

After modprobe w1-gpio and w1-therm I don't have any w1 device :(

 

I must patch dtb file like here https://forum.armbian.com/index.php/topic/993-ds18b20-temperature-sensor-in-lamobo-r1/#entry7584 ?

 

I think fex file is ok, I have 

 

[w1_para]
w1_used = 1
gpio = 20

 

There is a patch somewhere for this board?

 

Thank you.

Link to comment
Share on other sites

Hi!

 

I managed to setup up my orange pi zero and i can see temp sensor at  /sys/bus/w1/devices/

 

I have a DS2406 two channel switch which is displayed too, but I can't switch its PIO's.

 

Is it possible to config OWFS in order to see the devices under file system in a mounted folder?

(I have a tplink router with DS9490R master device, and a 8 channel switch (DS2408), and I can switch its PIO's by editing one file in the mounted directory. I hope if I can use OWFS on Orange pi zero, i can also change DS2406 PIO's...)

 

Thank you in advance.

Link to comment
Share on other sites

I use "ARMBIAN 5.25 stable Debian GNU/Linux 8 (jessie) 3.4.113-sun8i"

I manually added CONFIG_W1_SLAVE_DS2406=m to config-3.4.113-sun8i file, but there's nothing happens. 

 

I got these:

root@orangepizero:/sys/devices/w1_bus_master1/12-00000097477a# ls -la
total 0
drwxr-xr-x 3 root root    0 Apr 15 21:15 .
drwxr-xr-x 5 root root    0 Apr 15 21:15 ..
lrwxrwxrwx 1 root root    0 Apr 15 21:41 driver -> ../../../bus/w1/drivers/w1_slave_driver
-r--r--r-- 1 root root 4096 Apr 15 21:41 id
-r--r--r-- 1 root root 4096 Apr 15 21:41 name
drwxr-xr-x 2 root root    0 Apr 15 21:15 power
-rw-rw-rw- 1 root root 4096 Apr 15 21:59 rw
lrwxrwxrwx 1 root root    0 Apr 15 21:41 subsystem -> ../../../bus/w1
-rw-r--r-- 1 root root 4096 Apr 15 21:15 uevent
 

But with OWFS on my router (and DS9490R) it is:

root@OpenWrt:/mnt/1-wire/29.034706000000# ls -la
drwxrwxrwx    1 root     root             8 Apr 16 09:49 .
drwxr-xr-x    1 root     root             8 Mar 16 21:26 ..
drwxrwxrwx    1 root     root             8 Apr 16 09:49 LCD_H
drwxrwxrwx    1 root     root             8 Apr 16 09:49 LCD_M
-rw-rw-rw-    1 root     root             1 Apr 16 09:49 PIO.0
-rw-rw-rw-    1 root     root             1 Apr 16 09:49 PIO.1
-rw-rw-rw-    1 root     root             1 Apr 16 09:49 PIO.2
-rw-rw-rw-    1 root     root             1 Apr 16 09:49 PIO.3
-rw-rw-rw-    1 root     root             1 Apr 16 09:49 PIO.4
-rw-rw-rw-    1 root     root             1 Apr 16 09:49 PIO.5
-rw-rw-rw-    1 root     root             1 Apr 16 09:49 PIO.6
-rw-rw-rw-    1 root     root             1 Apr 16 09:49 PIO.7
-rw-rw-rw-    1 root     root            15 Apr 16 09:49 PIO.ALL
-rw-rw-rw-    1 root     root            12 Apr 16 09:49 PIO.BYTE
-r--r--r--    1 root     root            16 Mar 16 21:26 address
-rw-rw-rw-    1 root     root           256 Mar 16 21:26 alias
-r--r--r--    1 root     root             2 Mar 16 21:26 crc8
-r--r--r--    1 root     root             2 Mar 16 21:26 family
-r--r--r--    1 root     root            12 Mar 16 21:26 id
-rw-rw-rw-    1 root     root             1 Apr 16 09:49 latch.0
-rw-rw-rw-    1 root     root             1 Apr 16 09:49 latch.1
-rw-rw-rw-    1 root     root             1 Apr 16 09:49 latch.2
-rw-rw-rw-    1 root     root             1 Apr 16 09:49 latch.3
-rw-rw-rw-    1 root     root             1 Apr 16 09:49 latch.4
-rw-rw-rw-    1 root     root             1 Apr 16 09:49 latch.5
-rw-rw-rw-    1 root     root             1 Apr 16 09:49 latch.6
-rw-rw-rw-    1 root     root             1 Apr 16 09:49 latch.7
-rw-rw-rw-    1 root     root            15 Apr 16 09:49 latch.ALL
-rw-rw-rw-    1 root     root            12 Apr 16 09:49 latch.BYTE
-r--r--r--    1 root     root            16 Mar 16 21:26 locator
--w--w--w-    1 root     root             1 Apr 16 09:49 out_of_testmode
-rw-rw-rw-    1 root     root             1 Apr 16 09:49 por
-r--r--r--    1 root     root             1 Apr 16 09:49 power
-r--r--r--    1 root     root            16 Mar 16 21:26 r_address
-r--r--r--    1 root     root            12 Mar 16 21:26 r_id
-r--r--r--    1 root     root            16 Mar 16 21:26 r_locator
-r--r--r--    1 root     root             1 Apr 16 09:49 sensed.0
-r--r--r--    1 root     root             1 Apr 16 09:49 sensed.1
-r--r--r--    1 root     root             1 Apr 16 09:49 sensed.2
-r--r--r--    1 root     root             1 Apr 16 09:49 sensed.3
-r--r--r--    1 root     root             1 Apr 16 09:49 sensed.4
-r--r--r--    1 root     root             1 Apr 16 09:49 sensed.5
-r--r--r--    1 root     root             1 Apr 16 09:49 sensed.6
-r--r--r--    1 root     root             1 Apr 16 09:49 sensed.7
-r--r--r--    1 root     root            15 Apr 16 09:49 sensed.ALL
-r--r--r--    1 root     root            12 Apr 16 09:49 sensed.BYTE
-rw-rw-rw-    1 root     root            12 Apr 16 09:49 set_alarm
-rw-rw-rw-    1 root     root             1 Apr 16 09:49 strobe
-r--r--r--    1 root     root            32 Mar 16 21:26 type
 

If I edit the PIO.BYTE I can change the switch state.

 

So I would like to use Domoticz but only the DS18b20 are present, the DS2406 is missing :( I hope if I managed to setup OWFS it appears in Domoticz.

Link to comment
Share on other sites

On 2017. 04. 16. at 4:22 PM, martinayotte said:

If the CONFIG_W1_SLAVE_DS2406=m was not already present in config-3.4.113-sun8i file, this means you have to compile a new kernel to get ds2406.ko modules.

Adding it to config-3.4.113-sun8i file doesn't do the job.

 

I upgraded to nightly and changed the kernel to dev 4.x, but after it I can't see any 1-wire devices :(

 

[gpio_para]
gpio_used = 1

 

[w1_para]
w1_used = 1
gpio = 10


/etc/modules

w1-sunxi
w1-gpio
w1-therm

 

lsmod

Module                  Size  Used by
sunxi_cir               3825  0
evdev                   9979  0
xradio_wlan            92375  1
sun8i_codec_analog     13766  0
snd_soc_core          115473  1 sun8i_codec_analog
mac80211              325145  1 xradio_wlan
snd_pcm_dmaengine       4221  1 snd_soc_core
snd_pcm                70145  2 snd_pcm_dmaengine,snd_soc_core
cfg80211              192770  2 mac80211,xradio_wlan
rfkill                 10928  2 cfg80211
sun8i_ths               3134  0
cpufreq_dt              3522  0
thermal_sys            43232  2 cpufreq_dt,sun8i_ths
gpio_keys               8517  0
uio_pdrv_genirq         3354  0
uio                     8012  1 uio_pdrv_genirq
w1_therm                5237  0
w1_gpio                 3195  0
wire                   20756  2 w1_gpio,w1_therm
fuse                   70718  1

 

Can you help me?

Link to comment
Share on other sites

Thanks all for the help!

 

 

 

I added to /boot/ambianEnv.txt:

overlays=w1-gpio
param_w1_pin=PA10 #because I'm using GPIO10

 

I have these dtbo files:

README.sun8i-h3-overlays    sun8i-h3-pps-gpio.dtbo       sun8i-h3-uart1.dtbo
sun8i-h3-analog-codec.dtbo  sun8i-h3-pwm.dtbo            sun8i-h3-uart2.dtbo
sun8i-h3-cir.dtbo           sun8i-h3-spdif-out.dtbo      sun8i-h3-uart3.dtbo
sun8i-h3-fixup.scr          sun8i-h3-spi-add-cs1.dtbo    sun8i-h3-usbhost0.dtbo
sun8i-h3-i2c0.dtbo          sun8i-h3-spi-jedec-nor.dtbo  sun8i-h3-usbhost2.dtbo
sun8i-h3-i2c1.dtbo          sun8i-h3-spi-mcp2515.dtbo    sun8i-h3-usbhost3.dtbo
sun8i-h3-i2c2.dtbo          sun8i-h3-spi-spidev.dtbo     sun8i-h3-w1-gpio.dtbo
sun8i-h3-i2c-ds1307.dtbo

 

At reboot I can see:

Applying kernel provided DT overlay sun8i-h3-w1-gpio.dtbo

 

After reboot, I can see DS18B20 and I can read the temperatures, and I can see DS2406 but the situation is the same as with the stable armbian version -> the PIO. files are still missing.

root@orangepizero:/sys/devices/w1_bus_master1/12-00000097477a# ls -la
total 0
drwxr-xr-x 3 root root    0 Apr 18 15:58 .
drwxr-xr-x 5 root root    0 Apr 18 15:58 ..
lrwxrwxrwx 1 root root    0 Apr 18 15:59 driver -> ../../../bus/w1/drivers/w1_slave_driver
-r--r--r-- 1 root root 4096 Apr 18 15:59 id
-r--r--r-- 1 root root 4096 Apr 18 15:59 name
drwxr-xr-x 2 root root    0 Apr 18 15:59 power
-rw-r--r-- 1 root root 4096 Apr 18 15:59 rw
lrwxrwxrwx 1 root root    0 Apr 18 15:59 subsystem -> ../../../bus/w1
-rw-r--r-- 1 root root 4096 Apr 18 15:58 uevent

 

dmesg | grep w1

w1_master_driver w1_bus_master1: Family 12 for 12.00000097477a.09 is not registered.

 

 /boot/config-4.10.3-sun8i

#
# 1-wire Slaves
#
CONFIG_W1_SLAVE_THERM=m
CONFIG_W1_SLAVE_SMEM=m
CONFIG_W1_SLAVE_DS2408=m
CONFIG_W1_SLAVE_DS2408_READBACK=y
CONFIG_W1_SLAVE_DS2413=m
CONFIG_W1_SLAVE_DS2406=m

 

How can I register the DS2406?

Edited by kzkz
add info
Link to comment
Share on other sites

Additional info:

I added w1-2406 to /etc/modules and the not registered error message is disappeard!

 

lsmod:

Module                  Size  Used by
evdev                   9979  0
xradio_wlan            92375  1
mac80211              325145  1 xradio_wlan
sun8i_codec_analog     13766  0
cfg80211              192770  2 mac80211,xradio_wlan
snd_soc_core          115473  1 sun8i_codec_analog
rfkill                 10928  3 cfg80211
snd_pcm_dmaengine       4221  1 snd_soc_core
snd_pcm                70145  2 snd_pcm_dmaengine,snd_soc_core
sun8i_ths               3134  0
cpufreq_dt              3522  0
gpio_keys               8517  0
thermal_sys            43232  2 cpufreq_dt,sun8i_ths
uio_pdrv_genirq         3354  0
uio                     8012  1 uio_pdrv_genirq
w1_ds2406               1869  0
w1_therm                5237  0
w1_gpio                 3195  0
wire                   20756  3 w1_gpio,w1_ds2406,w1_therm
usb_f_acm               4871  1
u_serial                8725  3 usb_f_acm
g_serial                3737  0
libcomposite           34692  2 g_serial,usb_f_acm

 

But I still can't see PIO files. I have a new output file in the list:

root@orangepizero:/sys/bus/w1/devices/12-00000097477a# ls -la
total 0
drwxr-xr-x 3 root root    0 Apr 18 17:03 .
drwxr-xr-x 5 root root    0 Apr 18 17:03 ..
lrwxrwxrwx 1 root root    0 Apr 18 17:04 driver -> ../../../bus/w1/drivers/w1_slave_driver
-r--r--r-- 1 root root 4096 Apr 18 17:04 id
-r--r--r-- 1 root root 4096 Apr 18 17:04 name
-rw-rw-r-- 1 root root    1 Apr 18 17:04 output
drwxr-xr-x 2 root root    0 Apr 18 17:04 power
-r--r--r-- 1 root root    1 Apr 18 17:04 state
lrwxrwxrwx 1 root root    0 Apr 18 17:03 subsystem -> ../../../bus/w1
-rw-r--r-- 1 root root 4096 Apr 18 17:03 uevent

 

There is an error line at Domoticz log:

Error: 1Wire: Device not yet supported in Kernel mode (Please report!) ID:12-00000097477a, family: 12

 

After installed owfs and owserver:

owfs --w1 -m /mnt/1wire --allow_other --debug
DEBUG MODE
libow version:
        3.1p1
CONNECT: owfs.c:(102) fuse mount point: /mnt/1wire
CONNECT: ow_dnssd.c:(81) Zeroconf/Bonjour is disabled since dnssd library isn't found
   CALL: ow_parsename.c:(104) path=[]
  DEBUG: owlib.c:(77) Global temp limit 0C to 100C (for fake and mock adapters)
CONNECT: ow_w1_bind.c:(54) [Protocol not supported] Netlink (w1) socket (are you root?)
  DEBUG: ow_w1_monitor.c:(65) [Protocol not supported] Netlink problem -- are you root?
  DEBUG: ow_net_client.c:(28) Called with localhost:4304 default=4304
]*$> compiled to 0xb6f51764g Ex expression <^ *([^ ]+)[
]*$> compiled to 0xb6f51784g Ex expression <^ *([^ ]+) *: *([^ ]+)[
]*$> compiled to 0xb6f517a4g Ex expression <^ *([^ ]+) *: *([^ ]+) *: *([^ ]+)[
  DEBUG: ow_regex.c:(154) Not found
  DEBUG: ow_regex.c:(201) 0: 0->14 found <><localhost:4304><>
  DEBUG: ow_regex.c:(201) 1: 0->9 found <><localhost><:4304>
  DEBUG: ow_regex.c:(201) 2: 10->14 found <localhost:><4304><>
  DEBUG: ow_regex.c:(74) Reg Ex expression <^$> compiled to 0xb6f516a4
  DEBUG: ow_regex.c:(74) Reg Ex expression <^all$> compiled to 0xb6f516c4
  DEBUG: ow_regex.c:(74) Reg Ex expression <^scan$> compiled to 0xb6f516e4
  DEBUG: ow_regex.c:(74) Reg Ex expression <^\*$> compiled to 0xb6f51704
  DEBUG: ow_regex.c:(74) Reg Ex expression <^[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}$> compiled to 0xb6f51724
  DEBUG: ow_regex.c:(74) Reg Ex expression <^-?[[:digit:]]+$> compiled to 0xb6f51744
  DEBUG: ow_parse_address.c:(60) Text <localhost>
  DEBUG: ow_parse_address.c:(120) First <localhost>
  DEBUG: ow_parse_address.c:(125) Second <4304>
  DEBUG: ow_parse_address.c:(57) Num <4304> 4304
  DEBUG: ow_net_client.c:(85) Called with [localhost:4304] IP address=[localhost] port=[4304]
CONNECT: ow_net_client.c:(147) [Connection refused] Socket problem
CONNECT: owlib.c:(108) Cannot open server at localhost:4304 -- first attempt.
  DEBUG: ow_net_client.c:(28) Called with localhost:4304 default=4304
  DEBUG: ow_regex.c:(154) Not found
  DEBUG: ow_regex.c:(201) 0: 0->14 found <><localhost:4304><>
  DEBUG: ow_regex.c:(201) 1: 0->9 found <><localhost><:4304>
  DEBUG: ow_regex.c:(201) 2: 10->14 found <localhost:><4304><>
  DEBUG: ow_parse_address.c:(60) Text <localhost>
  DEBUG: ow_parse_address.c:(120) First <localhost>
  DEBUG: ow_parse_address.c:(125) Second <4304>
  DEBUG: ow_parse_address.c:(57) Num <4304> 4304
  DEBUG: ow_net_client.c:(85) Called with [localhost:4304] IP address=[localhost] port=[4304]
CONNECT: ow_net_client.c:(147) [Connection refused] Socket problem
CONNECT: owlib.c:(113) Cannot open server at localhost:4304 -- second (and final) attempt.
DEFAULT: owlib.c:(52) No valid 1-wire buses found

 

Edited by kzkz
Link to comment
Share on other sites

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:

  1. enabled the following modules: w1-sunxi, w1-gpio, w1-therm, reviewed script.bin (using bin2fex) to verify the w1 pin.
  2. 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
  3. 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:

Quote

Linux version 3.4.113-sun8i (root@devel) (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) ) #10 SMP PREEMPT Thu Feb 23 19:55:00 CET 2017

 

BOARD=orangepipcplus
BOARD_NAME="Orange Pi PC +"
VERSION=5.25
LINUXFAMILY=sun8i
BRANCH=default
ARCH=arm
IMAGE_TYPE=stable
 

 

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.

Link to comment
Share on other sites

8 minutes ago, immutability said:

if the parasitic mode is even supposed to be working reliably

Not with a 4.7k pull-up and especially not with multiple sensors. In these setups using a strong pull-up is recommended, but AFAIK it's not implemented by the driver.

For further reading: https://pdfserv.maximintegrated.com/en/an/AN4255.pdf

Link to comment
Share on other sites

31 minutes ago, zador.blood.stained said:

Not with a 4.7k pull-up and especially not with multiple sensors. In these setups using a strong pull-up is recommended, but AFAIK it's not implemented by the driver.

For further reading: https://pdfserv.maximintegrated.com/en/an/AN4255.pdf

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).

Link to comment
Share on other sites

7 minutes ago, immutability said:

I thought it's mostly about the delays (but I may be completely wrong - it's been a few years).

1-wire is about delays, but pull-up resistor value influences:

  • low->high transition curve
  • voltage drop during CONVERT_TEMP operation, especially if it is done by multiple sensors

If voltage doesn't rise fast enough during communication or if it drops low enough during conversion operation, you won't have a reliable setup.

Link to comment
Share on other sites

22 minutes ago, zador.blood.stained said:

1-wire is about delays, but pull-up resistor value influences:

  • low->high transition curve
  • voltage drop during CONVERT_TEMP operation, especially if it is done by multiple sensors

If voltage doesn't rise fast enough during communication or if it drops low enough during conversion operation, you won't have a reliable setup.

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.

Link to comment
Share on other sites

Hello.

 

Two DS18b20 on OrangePi Zero (H2+)

ARMBIAN 5.35 user-built Ubuntu 16.04.3 LTS 4.13.16-sunxi

 

What did the trick for me:

- armbian-config, enable 1wire, which added w1-gpio to the list of overlays in /boot/armbianEnv.txt ; it's probably possible to add it manually without running armbian-config

- add param_w1_pin=PA10

- add 10k resistor between +3.3 and PA15(MOSI)

- reboot.

 

Did not need to change anything in /etc/modules* or anything else not mentionned above.

 

Raw logs:


 

# cat /etc/default/cpufrequtils
ENABLE=true
MIN_SPEED=240000
MAX_SPEED=1200000
GOVERNOR=ondemand

# cat /boot/armbianEnv.txt
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

# ls /sys/bus/w1/devices
28-0517023468ff  28-0517025727ff  w1_bus_master1

# dmesg | grep -i -e w1 -e wire
[   15.291623] Driver for 1-wire Dallas network protocol.

# cat /etc/modules /etc/modules-load.d/*
g_serial
g_serial

It may be possible to use 1W on other pins that MOSI, but RaspberryPi forums recommend to use MOSI because for rPi it's the fastest pin, and the only one able to stand high bitrate. Some devices may refuse to communicate at low bitrate, making usually impossible to use any other pins.

 

I agree that 1W may be sensible to CPU frequency scaling, but I never had any issue around this.

Link to comment
Share on other sites

Just, in case somebody have the same problem I am working with.

 

This thread name is "Orange Pi PC 1-Wire" ... but really it must be "Temperature sensors on Armbian using 1-Wire".

 

I have been working with Bananas, Oranges, Raspberry and even Arduino devices using 1-Wire iButton devices for authentication procedures.  In the Arduino world that part is "almost" ready, but in the Linux world (including Armbian) it is not a complete story.

 

Trying to have a complete scenario to work with, I have been checking the 18b20 case, being a well documented one in Linux.  However, in real life, this is very different than the ds1961s iButton I am working with now.  For example, the thread indicates that the w1_therm must be loaded, but that driver "only" recognizes the temperature 1-wire devices.  For the others, a different driver must be loaded.

 

These are the currently included 1-Wire drivers in the 4.4.18 Kernel: (

    w1_ds2405 - "Driver for 1-wire Dallas DS2405 PIO."

    w1_ds2406 - "w1 family 12 driver for DS2406 2 Pin IO"

    w1_ds2408 - "w1 family 29 driver for DS2408 8 Pin IO"

    w1_ds2413 - "w1 family 3a driver for DS2413 2 Pin IO"

    w1_ds2423 - "w1 family 1d driver for DS2423, 4 counters and 4kb ram"

    w1_ds2431 - "w1 family 2d driver for DS2431, 1kb EEPROM"

    w1_ds2433 - "w1 family 23 driver for DS2433, 4kb EEPROM"

    w1_ds2438 - "1-wire driver for Maxim/Dallas DS2438 Smart Battery Monitor"

    w1_ds2760 - "1-wire Driver Dallas 2760 battery monitor chip"

    w1_ds2780 - "1-wire Driver for Maxim/Dallas DS2780 Stand-Alone Fuel Gauge IC"

    w1_ds2781 - "1-wire Driver for Maxim/Dallas DS2781 Stand-Alone Fuel Gauge IC"

    w1_ds2805 - "w1 family 0d driver for DS2805, 1kb EEPROM"

    w1_ds28e04 - "w1 family 1C driver for DS28E04, 4kb EEPROM and PIO"

    w1_smem - "Driver for 1-wire Dallas network protocol, 64bit memory family."

    w1_therm - "Driver for 1-wire Dallas network protocol, temperature family."

On 4.16.rc1 only the w1_ds28e17.c ("w1 family 19 driver for DS28E17, 1-wire to I2C master bridge") is extra included.

 

So ... in my case, no family 33 ( ds2432 - ds1961s) is ready to use, so I would need to choose the most similar one and derive my own kernel driver from that.

 

The ds1961s is an iButton with 1Kb EEPROM and SHA-1 Engine, "maybe" similar to the ds2431 (family 2d in the storage part).

 

 

For extra information about 1-Wire families, check this : http://owfs.sourceforge.net/family.html

 

And ... why ds1961s? ... Well, it has "advanced" characteristics that help me to develop very difficult to copy hardware key devices, that can't be worked with temperature devices or with the simple ds1990a iButton (family 1 ... neither supported natively in Linux).

 

Link to comment
Share on other sites

On 2/12/2018 at 10:11 AM, malvcr said:

The ds1961s is an iButton with 1Kb EEPROM and SHA-1 Engine, "maybe" similar to the ds2431 (family 2d in the storage part).

 

My mistake .... the ds1961s it is completely different to the standard eeprom iButton devices because the way the memory it is used, restricted by "secrets".  This happens because it is a security enhanced device.

What I am doing now it is to have it "naked" and to work with the "rw" raw data access facility and no particular kernel module.

Something else it is important.  I can't use 4.7K resistors but 2.2K ones, because the device has different electricity needs than the temperature sensors.  So, before trying to apply any other 1-Wire device, check carefully the particular information before becoming crazy :-) ...


My only definitions, by now are in the /boot/armbEnv.txt file:

overlays=w1-gpio
param_w1_pin=PA20

: this is not for an Orange but for a Banana Pi, but the idea is the same (just the GPIO are not 100% compatible as described by TKaiser):

 

Link to comment
Share on other sites

According to https://www.armbian.com/orange-pi-zero/

 

Quote

1-Wire protocol, reading out DHT11/DHT22 sensors or S/PDIF requires setting the minimum CPU frequency to 480MHz or higher

 

My way to do it is crontab:

 

* *      * * *  root    /usr/bin/cpufreq-set -f 1200MHz ; /usr/bin/cpufreq-set -g performance

Of course, editing /etc/default/cpufrequtils sounds much better.

 

Link to comment
Share on other sites

I will be sincere ... after weeks trying to make the DS1961S to work on an SBC and having partial results, I gave up with this.

Now I have an almost completely functional prototype working with an Arduino that it is connected to the SBC.

 

What I think is that the logic behind a security device, as the DS1961S it is not a good candidate to work as a driver, neither to use through the OneWire basic Linux interface.  It seems that the Linux basic driver it is very unstable for that.

 

As the Arduino it is an almost "naked" device, it is easier to control that OneWire device in a more precise way, having the opportunity to create more complex usages with less effort than trying to do everything directly with the SBC.

 

Maybe, in the future, I could try again to use directly an SBC, as the Orange.  Let's see how this thing evolve --- and --- although everything can be done directly with an SBC with Linux, sometimes there are better methods to achieve the expected goals.

Link to comment
Share on other sites

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 :) 

Screenshot 2018-03-15 14.50.59.png

Screenshot 2018-03-30 14.05.37.png

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines