[Owfs-developers] Problem with 1-Wire USB Adapter

[Klaus Weglehner]

Hello all,

I was working on an application using the owfs c api.

The target platform is a raspberry pi with a DS9490 USB adapter
connected. There are about 15 DS18B20 mostly in a star topology.

At first everything seems to work fine.
Then i tried to force cache updates while my application is idle by
reading the uncached entries in turn. So i can access the cached values
fast if needed. This works also.
But after a few minutes the Sensors starts disapearing.

Because i suspect my application code, i tried to replicate this
behaviour with owfs tools.

I start the Server:

owserver -r --foreground -u --debug 2>owserver.log
DEBUG MODE
libow version:
2.9p1

And on another Machine:
while true; do owread -s heizung uncached/28.5F74E2040000/temperature;
done

Indeed are the Sensors disapearing after a few Minutes.

I will attach the debug Output of the Server. "error.log" is one of the
failed transactions. But i expect the interesting parts are earlier.
In owserver-cut.log.gz i cut down a large stderr logfile. It begins
with the Start of the Server, i deleted the logs of many successful
querys and leave some before the point where things go wrong.

I would be very glad if somebody can tell me what is going on here.

I would not be surprised if there are transmission errors on the 1-wire
bus. But why can't the server recover from this? As soon as i restart
the server, everything is fine again for a few minutes.

Can this be a specific problem of the usb hostadapter which may go away
by changing to an i2c interface? (I've considered this anyway)
Or is it a pure 1-Wire bus problem?

Thank you very much in advance!
Klaus

[Jan Kandziora]

Post by Klaus Weglehner
There are about 15 DS18B20 mostly in a star topology.

This is near worst-case. You could make it only worse by having some of
these bus-powered. There is no way to have this working reliable.

If you can't help building a "star" because the sensors are laid out
that way, use lobes instead of single wires so the actual topology is a
bus. Length doesn't matter with onewire, bus topology does.

Post by Klaus Weglehner
But after a few minutes the Sensors starts disapearing.

First check if your kernel has support for the "w1" sensor bus. That is
onewire the kernel way, mostly for Li-battery control chips found in
some laptops. There is also a "ds2490" module which is accessing a USB
onewire host. The kernel and OWFS get in the way of each other when they
both try do access the adapter.

You may disable the "ds2490" kernel module by removing/blacklisting it
and keep all the internal onewire hosts (I2C and bitbanging) working
with the w1 kernel module.

Post by Klaus Weglehner
I would not be surprised if there are transmission errors on the 1-wire
bus. But why can't the server recover from this? As soon as i restart
the server, everything is fine again for a few minutes.

That's because the USB adapter is re-initialised when you start
owserver. Disconnect and reconnect it from usb while owserver is
running. Do the onewire devices reappear? (try scanning "uncached" twice
or three times in a row)

Post by Klaus Weglehner
Can this be a specific problem of the usb hostadapter which may go away
by changing to an i2c interface? (I've considered this anyway)
Or is it a pure 1-Wire bus problem?

The DS9490 usually makes no problems in my networks - dozens at various
locations.

If you are going for I²C, use two DS2482-800 so you get away from the
star topology. Beware that scanning for chips is very slow with the I²C
adapters, as the host CPU has to control it. The USB adapter has some
algorithm inside to do that independendly of the host CPU.

In general, I²C is only a bit better than bit-banging onewire with most
host boards, as the I²C host is often realized with bit-banging, too.
Some embedded boards may have a I²C shift register, but that still means
one interrupt each millisecond for just one I²C/Onewire byte.


Kind regards

Jan

[Colin Reese]

Hello,

This is a very interesting topic. I've used ds9490s forever in various topologies wired individually with RJ and never had an issue with finding devices, using maxim's drivers on windows and owfs on Linux. It definitely gets slower as the number of devices increases, but no problems other than that. For cost, I've just implemented a DS2483 on I2C, which is $0.60 vs. $27 for the DS9490. I have not yet tested it extensively. I had assumed that the 2483 would perform better as it doesn't rely on the serial bus and is a newer device. Is this not the case, and what performance difference and limitations should I expect? I'm on raspbian on an RPi.

Thanks,
Colin

Post by Jan Kandziora

Post by Klaus Weglehner
There are about 15 DS18B20 mostly in a star topology.

This is near worst-case. You could make it only worse by having some of
these bus-powered. There is no way to have this working reliable.
If you can't help building a "star" because the sensors are laid out
that way, use lobes instead of single wires so the actual topology is a
bus. Length doesn't matter with onewire, bus topology does.

Post by Klaus Weglehner
But after a few minutes the Sensors starts disapearing.

First check if your kernel has support for the "w1" sensor bus. That is
onewire the kernel way, mostly for Li-battery control chips found in
some laptops. There is also a "ds2490" module which is accessing a USB
onewire host. The kernel and OWFS get in the way of each other when they
both try do access the adapter.
You may disable the "ds2490" kernel module by removing/blacklisting it
and keep all the internal onewire hosts (I2C and bitbanging) working
with the w1 kernel module.

Post by Klaus Weglehner
I would not be surprised if there are transmission errors on the 1-wire
bus. But why can't the server recover from this? As soon as i restart
the server, everything is fine again for a few minutes.

That's because the USB adapter is re-initialised when you start
owserver. Disconnect and reconnect it from usb while owserver is
running. Do the onewire devices reappear? (try scanning "uncached" twice
or three times in a row)

Post by Klaus Weglehner
Can this be a specific problem of the usb hostadapter which may go away
by changing to an i2c interface? (I've considered this anyway)
Or is it a pure 1-Wire bus problem?

The DS9490 usually makes no problems in my networks - dozens at various
locations.
If you are going for I²C, use two DS2482-800 so you get away from the
star topology. Beware that scanning for chips is very slow with the I²C
adapters, as the host CPU has to control it. The USB adapter has some
algorithm inside to do that independendly of the host CPU.
In general, I²C is only a bit better than bit-banging onewire with most
host boards, as the I²C host is often realized with bit-banging, too.
Some embedded boards may have a I²C shift register, but that still means
one interrupt each millisecond for just one I²C/Onewire byte.
Kind regards
Jan
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Owfs-developers mailing list
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Jan Kandziora]

Post by Colin Reese
This is a very interesting topic. I've used ds9490s forever in
various topologies wired individually with RJ and never had an issue
with finding devices, using maxim's drivers on windows and owfs on
Linux.

I do, even with a bus topology. When I scan continously for new chips I
will certainly get misreadings (a certain chip is errorneously not
found) after a few seconds. It gets worse when there are long leaves.

What is your cable length on individual leaves?

Post by Colin Reese
It definitely gets slower as the number of devices increases,
but no problems other than that. For cost, I've just implemented a
DS2483 on I2C, which is $0.60 vs. $27 for the DS9490. I have not yet
tested it extensively. I had assumed that the 2483 would perform
better as it doesn't rely on the serial bus and is a newer device. Is
this not the case, and what performance difference and limitations
should I expect? I'm on raspbian on an RPi.

The BCM2835 I²C master has a four-byte fifo which is used for writing
and reading which is at least a bit better than what other boards with
I²C hosts have. The i2c-bcm2708 driver makes use of that fifo.

BUT, as the DS2483 requires busy polling before issuing the next
command, you cannot make much use of that fifo. For writing a single
byte that's only two bytes in a row, then the write-read-turnaround
clears the fifo. Relevant code is at module/owlib/src/c/ow_ds2482.c:646-653

For scanning the bus, this is especially bad, as it requires 64 times
write byte+read byte per chip on the bus, meaning 128 interrupts in 12ms
(64 * 3 onewire bit times of 60µs, I²C timing neglectable). When you
have a network with a dozen chips *and* want to scan a lock on it three
times a seconds for an iButton, this is just an endless stream of
interrupts.

I had this use case and because of it being unfeasibly slowing down the
whole machine, Paul and me implemented the simultaneous/single_ds2400
node just for checking for a single DS2401 chip independly of the other
chips and the scanning mechanism. It's more reliable, too.


Kind regards

Jan

[Colin Reese]

Post by Jan Kandziora

Post by Colin Reese
This is a very interesting topic. I've used ds9490s forever in
various topologies wired individually with RJ and never had an issue
with finding devices, using maxim's drivers on windows and owfs on
Linux.

I do, even with a bus topology. When I scan continously for new chips I
will certainly get misreadings (a certain chip is errorneously not
found) after a few seconds. It gets worse when there are long leaves.
What is your cable length on individual leaves?

Depends. Typically one to five feet off a main wire that's 20-30' long. Ds18b20s usually, although I'm about to get into a more diverse family.

Post by Jan Kandziora

Post by Colin Reese
It definitely gets slower as the number of devices increases,
but no problems other than that. For cost, I've just implemented a
DS2483 on I2C, which is $0.60 vs. $27 for the DS9490. I have not yet
tested it extensively. I had assumed that the 2483 would perform
better as it doesn't rely on the serial bus and is a newer device. Is
this not the case, and what performance difference and limitations
should I expect? I'm on raspbian on an RPi.

The BCM2835 I²C master has a four-byte fifo which is used for writing
and reading which is at least a bit better than what other boards with
I²C hosts have. The i2c-bcm2708 driver makes use of that fifo.
BUT, as the DS2483 requires busy polling before issuing the next
command, you cannot make much use of that fifo. For writing a single
byte that's only two bytes in a row, then the write-read-turnaround
clears the fifo. Relevant code is at module/owlib/src/c/ow_ds2482.c:646-653
For scanning the bus, this is especially bad, as it requires 64 times
write byte+read byte per chip on the bus, meaning 128 interrupts in 12ms
(64 * 3 onewire bit times of 60µs, I²C timing neglectable). When you
have a network with a dozen chips *and* want to scan a lock on it three
times a seconds for an iButton, this is just an endless stream of
interrupts.
I had this use case and because of it being unfeasibly slowing down the
whole machine, Paul and me implemented the simultaneous/single_ds2400
node just for checking for a single DS2401 chip independly of the other
chips and the scanning mechanism. It's more reliable, too.

How does one make use of this? I've really only set up python to read a default owfs installation directory. Never had misreads with ds9490. Have noticed sensors appearing and reappearing on the 2483. I don't need to poll that often, so if I can code around it asynchronously with error correction I'm into that.

Thanks,
Colin

Post by Jan Kandziora
Kind regards
Jan
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Owfs-developers mailing list
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Jan Kandziora]

Post by Colin Reese
How does one make use of this?

The simultaneous/single_ds2400? Simply by reading that node. But I gave
it only as an example what I had to do to make the whole thing work for
me. Batteries included wasn't good with the I²C hosts and my application.

Post by Colin Reese
I've really only set up python to read
a default owfs installation directory. Never had misreads with
ds9490. Have noticed sensors appearing and reappearing on the 2483. I
don't need to poll that often, so if I can code around it
asynchronously with error correction I'm into that.

Sure, just read again on error when you have the time to do it. When you
don't rely on continuous scanning, that should be a no-issue. Same for
polling temperature values, as they don't change that fast.

Kind regards

Jan

[Colin Reese]

Is there a need and a way to disable the w1 kernel function elsewhere mentioned?

Thanks,
Colin

Post by Jan Kandziora

Post by Colin Reese
How does one make use of this?

The simultaneous/single_ds2400? Simply by reading that node. But I gave
it only as an example what I had to do to make the whole thing work for
me. Batteries included wasn't good with the I²C hosts and my application.

Post by Colin Reese
I've really only set up python to read
a default owfs installation directory. Never had misreads with
ds9490. Have noticed sensors appearing and reappearing on the 2483. I
don't need to poll that often, so if I can code around it
asynchronously with error correction I'm into that.

Sure, just read again on error when you have the time to do it. When you
don't rely on continuous scanning, that should be a no-issue. Same for
polling temperature values, as they don't change that fast.
Kind regards
Jan
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Owfs-developers mailing list
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Gregg Levine]

Hello!
This comes up from time to time, Colin. Look at your distribution's
methods of loading modules. It should contain a set of files for
blacklisting modules. On mine I have the IPv6 one blacklisted because
my DSL device is, ah, too old.

Put in your blacklist one where your system possibly put others, put
there the one for w1.
-----
Gregg C Levine ***@gmail.com
"This signature fought the Time Wars, time and again."

Post by Colin Reese
Is there a need and a way to disable the w1 kernel function elsewhere mentioned?
Thanks,
Colin

Post by Jan Kandziora

Post by Colin Reese
How does one make use of this?

The simultaneous/single_ds2400? Simply by reading that node. But I gave
it only as an example what I had to do to make the whole thing work for
me. Batteries included wasn't good with the I²C hosts and my application.

Post by Colin Reese
I've really only set up python to read
a default owfs installation directory. Never had misreads with
ds9490. Have noticed sensors appearing and reappearing on the 2483. I
don't need to poll that often, so if I can code around it
asynchronously with error correction I'm into that.

Sure, just read again on error when you have the time to do it. When you
don't rely on continuous scanning, that should be a no-issue. Same for
polling temperature values, as they don't change that fast.
Kind regards
Jan
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Owfs-developers mailing list
https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Owfs-developers mailing list
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Klaus Weglehner]

Thank you for your reply!

On Thu, 26 Sep 2013 01:33:59 +0200

Post by Jan Kandziora
This is near worst-case. You could make it only worse by having some of
these bus-powered. There is no way to have this working reliable.

Hm, the Star-rays are only 1-3m long. I thought this would be no
problem.

Anyway, i have tested another USB Host controller on the raspberry pi
with only one direct DS18S20 attached. It shows the same errors after a
few minutes while accessing the uncached entrys repeatedly fast.

Interestingly on my linux host-pc the same 1-wire controller with it's
sensor works flawless. Even the owfs source i compiled from is exactly
the same.

Again this is what happens:

CALL: data.c:(145) Read message
CALL: data.c:(104) DataHandler: parse
path=uncached/10.557A48010800/temperature CALL: ow_parsename.c:(99)
path=[uncached/10.557A48010800/temperature] CALL: data.c:(145) Read
message CALL: data.c:(104) DataHandler: parse
path=uncached/10.557A48010800/temperature CALL: ow_parsename.c:(99)
path=[uncached/10.557A48010800/temperature] CALL: data.c:(145) Read
message DATA: ow_ds9490.c:(813) USBsendback control error
CONNECT: ow_select.c:(111) Select error for DS18S20 on bus 1:8
CONNECT: ow_select.c:(111) Select error for DS18S20 on bus 1:8
CONNECT: ow_select.c:(111) Select error for DS18S20 on bus 1:8
CONNECT: ow_select.c:(111) Select error for DS18S20 on bus 1:8
CALL: data.c:(104) DataHandler: parse
path=uncached/10.557A48010800/temperature CALL: ow_parsename.c:(99)
path=[uncached/10.557A48010800/temperature] CALL: data.c:(104)
DataHandler: parse path=uncached/10.557A48010800/temperature CALL:
ow_parsename.c:(99) path=[uncached/10.557A48010800/temperature] CALL:
data.c:(104) DataHandler: parse
path=uncached/10.557A48010800/temperature


What does "USBsendback control error" mean?

At this time there was a syslog entry concerning usb:
kernel: [564749.208882] usb 1-1.3.3: usbfs: USBDEVFS_CONTROL failed cmd
owserver rqt 64 rq 1 len 0 ret -71


Any ideas? It looks like this failure is related to running owfs on the
raspberry?


Thanks in advance,
Klaus

[Jan Kandziora]

Post by Klaus Weglehner
Anyway, i have tested another USB Host controller on the raspberry pi
with only one direct DS18S20 attached. It shows the same errors after a
few minutes while accessing the uncached entrys repeatedly fast.

Have you checked for the w1 kernel functions? I have the same problems
(chips are sometimes missing) when the ds2490 kernel module is active.
These problems disappeared immediately after unloading that module.

Post by Klaus Weglehner
What does "USBsendback control error" mean?

Some command could not be sent to the DS2490 because libusb replied with
an error.

Post by Klaus Weglehner
kernel: [564749.208882] usb 1-1.3.3: usbfs: USBDEVFS_CONTROL failed cmd
owserver rqt 64 rq 1 len 0 ret -71

Error code -71 looks like a kernel/hardware related problem. Do you use
a hub? I had a lot of USB hubs which have been rubbish.

Kind regards

Jan

[Klaus Weglehner]

On Fri, 27 Sep 2013 01:43:57 +0200

Post by Jan Kandziora
Error code -71 looks like a kernel/hardware related problem. Do you use
a hub? I had a lot of USB hubs which have been rubbish.

It looks like you got it.

I replaced the hub by another one and now it is running without errors
a few hours already.

Thank you for this hint!


Klaus