Håkan Elmqvist | 1 Oct 22:24 2014

Repairing DS9490Rs hit by thunder

So here I was on my island with three dysfunctional DS9490R probably destroyed by a thunderstorm we had recently and no way to get any new ones. I hope this note may help somebody with the same problem.
In all three the DS9503 chip was blown. I removed the chips and soldered in 0.45 mm wires between 1-6 and 2-5 shorting out the ESD-protection. With a 30 W iron this was no easy task. Remember to use a heatsink when making the second connection otherwise you will lose the first. Pressing a tiny screwdriver against the middle of the wire will do.
To replace the ESD-protection I had no zeners or similar so I use the emitter base junction of small NPN transistors which will have a zener breakdown around 5.5 volts. Two transistors with the base shorted to the collector connected back to back for each adapter. I put these outside the adapter and hope it will work, No way to test but the adapters seem to work normally.
Note: to open the adapter you must remove the label and use a T5 TORX screwdriver or brute force.
Håkan
--
Håkan Elmqvist
Sunnerdahlsv 7
167 62 Bromma
Telefon: +46 (8) 80 18 81, +46 (704) 56 74 81, +46 (176) 84 077
epost: hakelm <at> smeden.org
Kryptera mera!
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Owfs-developers mailing list
Owfs-developers <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Jerry Scharf | 1 Oct 20:04 2014

how many 18b20s on a bus

Hi,

I am looking at using 18b20s to measure some load resistors and a couple 
other things. This is for a large bank of unit under test. The thing is 
that there are 300 load resistors plus 20-30 other channels to track. 
Then again, if we do a second monitor point, that's another 300 sensors. 
>From my experience with 30 sensors, having 300 is going to take a number 
of buses to be able to poll in finite time.

How many buses make sense? What type of bus masters should I choose? We 
will have some type of monitor computer, probably a linux box.

thanks in advance,
jerry

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
Chris Green | 28 Sep 16:00 2014
Picon

How to tell if 1-wire hardware is plugged in?

I have a 1-wire installation which I am trying to diagnose remotely.

A few days ago I had to replace the Beaglebone Black that was running
with another one becuase I corrupted the memory on the original one
and didn't have the ability to fix it there and then.

So, I'm fairly sure I plugged in the 1-wire USB interface to the new
system and also connected the two temperature measuring devices to it.

However I'm now not seeing any file system mounted on /mnt/1-wire.  I
have copied the /etc/owfs.conf file from the old system to the new one
so that should be right.

I have restarted the owserver process but nothing appears at the mount
point.

This is what I see in syslog when the owserver is restarted:-

Sep 28 15:41:52 odin owserver[5312]: Starting 1-Wire TCP Server: owserver.
Sep 28 15:42:36 odin owserver[5363]: Stopping 1-Wire TCP Server: owserver.
Sep 28 15:42:36 odin kernel: [879024.179714] usb usb2: usb auto-resume
Sep 28 15:42:36 odin kernel: [879024.179780] hub 2-0:1.0: hub_resume
Sep 28 15:42:36 odin kernel: [879024.179989] hub 2-0:1.0: state 7 ports 1 chg 0>
Sep 28 15:42:36 odin kernel: [879024.180634] hub 2-0:1.0: hub_suspend
Sep 28 15:42:36 odin kernel: [879024.180709] usb usb2: bus auto-suspend, wakeup>
Sep 28 15:42:36 odin kernel: [879024.183283] usb usb2: usb auto-resume
Sep 28 15:42:36 odin kernel: [879024.183336] hub 2-0:1.0: hub_resume
Sep 28 15:42:36 odin kernel: [879024.183512] hub 2-0:1.0: state 7 ports 1 chg 0>
Sep 28 15:42:36 odin kernel: [879024.183669] hub 2-0:1.0: hub_suspend
Sep 28 15:42:36 odin kernel: [879024.183733] usb usb2: bus auto-suspend, wakeup>
Sep 28 15:42:37 odin owserver[5370]: Starting 1-Wire TCP Server: owserver.

... and this is my owfs.conf file:-

# Sample configuration file for the OWFS suite for Debian GNU/Linux.
#
#
# This is the main OWFS configuration file. You should read the
# owfs.conf(5) manual page in order to understand the options listed
# here.

######################## SOURCES ########################
#
# With this setup, any client (but owserver) uses owserver on the
# local machine...
! server: server = localhost:4304
#
# ...and owserver uses the real hardware, by default fake devices
# This part must be changed on real installation
server:
#
# USB device: DS9490
server: usb = all
#
# Serial port: DS9097
#server: device = /dev/ttyS1
#
# owserver tcp address
#server: server = 192.168.10.1:3131
#
# random simulated device
#server: FAKE = DS18S20,DS2405
#
######################### OWFS ##########################
#
mountpoint = /mnt/1-wire
allow_other
#
####################### OWHTTPD #########################

http: port = 2121

####################### OWFTPD ##########################

ftp: port = 2120

####################### OWSERVER ########################

server: port = localhost:4304

Any ideas what mught be wrong and whether my 1-wire is connected?

--

-- 
Chris Green

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
Johan Ström | 19 Sep 08:57 2014
Picon

Issues with FTDI based USB-Serial dongle & DS2480B

Hi,

I've noticed some problems using a FTDI based USB serial dongle together
with a DS2480B based adapter (also known as DS9097U).
On startup the device was not recognized at all, complaining about wrong
responses. Anyone else seen these issues?

I've debugged the problem and found the cause.
On startup, this is what happens:

  DEBUG: ow_ds9097U.c:(287) Attempt 0 of 3 to initialize the DS9097U
TRAFFIC OUT <write> bus=0 (/dev/cua-labdesk)
Byte buffer anonymous, length=1
--000: C1
   <.>
  DEBUG: ow_ds9097U.c:(381) Send the initial reset to the bus master.
TRAFFIC OUT <write> bus=0 (/dev/cua-labdesk)
Byte buffer anonymous, length=1
--000: 71
   <q>
TRAFFIC OUT <write> bus=0 (/dev/cua-labdesk)
Byte buffer anonymous, length=1
--000: 0F
   <.>
  DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds
TRAFFIC IN  <NETREAD> bus=0 (/dev/cua-labdesk)
Byte buffer anonymous, length=1
--000: 70
   <p>
  DEBUG: ow_tcp_read.c:(114) read: 1 - 0 = 1
  DEBUG: ow_ds9097U.c:(459) wrong response (70 not 00)

After each TRAFFIC OUT byte above, a COM_Slurp() is issued to read and
remove the response.

The response to the 71 command should be 70.. Which is what we see..
except that it fails to slurp those bytes, it's actually
reading them as the response to the next command.

After some further debugging and added printf statements, I realize that
COM_slurp fails to read the bytes, and instead just timeouts (1ms).
I've been working on my pure-ftdi-branch for the LinkUSB, where I've
learned that the FTDI chips by default have a 16ms timeout for small
transfers, making them not very efficient when dealing with few bytes
like this.
Manually changing my USB-serial dongle's setting to 1ms with libftdi,
together with a slurp timeout of 2ms, seems to fix the problem. However,
the slurp still times out, so I guess the accompanying COM_flush does
the trick.. Running with default 16ms FTDI setting, and a slurp timeout
of 100ms, DOES succeed with reading the slurped data [1], and all works
fine.

The "proper" way to solve this is probably to actually read the bytes we
expect, not just hope that slurp catches them. However, this might be
problematic when changing bitrates etc?
The solution used above would  be to give the slurp a longer timeout.
Besides that device init would take a few ms longer, would this have any
other side effects?
>From the DS2480B code at least, it does not seem to slurp anywhere
except on device init.

For the record, the DS2480B works perfectly fine with my STLab 2 port
dongle (MosChip mos78x0 chip).. except that the stable FreeBSD-10 kernel
panics when setting baud rate 0, which happens sometimes in OWFS when
trying to forcefully reset. This was patched in
https://github.com/freebsd/freebsd/commit/120a212c4b16b5137d6acc436b8f5702a5f5bf35
but until the fix hits the mainline kernel, I'll have to go with another
dongle.

Regards
Johan

[1]
This is how a proper session looks, with the responses slurped (FTDI
chip 16ms, COM_slurp timeout set to 100ms):

  DEBUG: ow_ds9097U.c:(287) Attempt 0 of 3 to initialize the DS9097U
TRAFFIC OUT <write> bus=0 (/dev/cua-labdesk)
Byte buffer anonymous, length=1
--000: C1
   <.>
TRAFFIC IN  <slurp> bus=0 (/dev/cua-labdesk)
Byte buffer anonymous, length=1
--000: CD
   <.>
Slurp timeout 100000 us..
  DEBUG: ow_ds9097U.c:(381) Send the initial reset to the bus master.
TRAFFIC OUT <write> bus=0 (/dev/cua-labdesk)
Byte buffer anonymous, length=1
--000: 71
   <q>
TRAFFIC IN  <slurp> bus=0 (/dev/cua-labdesk)
Byte buffer anonymous, length=1
--000: 70
   <p>
Slurp timeout 100000 us..
TRAFFIC OUT <write> bus=0 (/dev/cua-labdesk)
Byte buffer anonymous, length=1
--000: 0F
   <.>
  DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds
TRAFFIC IN  <NETREAD> bus=0 (/dev/cua-labdesk)
Byte buffer anonymous, length=1
--000: 00
   <.>
  DEBUG: ow_tcp_read.c:(114) read: 1 - 0 = 1
  DEBUG: ow_com_read.c:(83) COM_read, read 1 bytes.
read_get=16302.000000us, tcdrain=0.000000us: 1

------------------------------------------------------------------------------
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
Loren Amelang | 15 Sep 01:30 2014
Picon

Re: unruly temperatures - Vol 100, Issue 6

Hakan,

I had an episode (on a BBB with I2C connection) where for a couple of weeks
the temperature resolution would randomly drop from 12-bit to 1/2 degree C.
Looking at the owserver presentation of all of the various bit resolutions,
sometimes the lower resolutions were not proper representations of the
higher-bit values. I couldn't tell if some values were delayed, or just
plain offset, but depending on which resolution happened to get written into
my filesystem where my logger reads them, the temperature could appear to
jump by 1/2 degree. I verified that the values in the filesystem files were
being logged correctly. It would happen for a few minutes or a few hours,
and then fix itself. And then without me doing anything at all, it just
stopped happening!

Looking at your graph, it appears you usually get full resolution gradual
changes on either side of your 1/2 degree steps. My graphs were always more
like the later part of your blue line - chattering by 1/2 degree where there
should have been a smooth transition.

I have no clues why this started or stopped...

| Loren Amelang | loren <at> pacific.net |

On Saturday, September 13, 2014 at 10:29 PM,
owfs-developers-request <at> lists.sourceforge.net wrote:

> 1. unruly temperatures (H?kan Elmqvist)
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 12 Sep 2014 17:18:53 +0200
> From: H?kan Elmqvist <hakelm <at> smeden.org>
> Subject: [Owfs-developers] unruly temperatures
> To: "OWFS (One-wire file system) discussion and help"
> <owfs-developers <at> lists.sourceforge.net>
> Message-ID: <54130EDD.5070503 <at> smeden.org>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Suddenly my temperature readings have started to jump up and down about
> 0.5 degree C at infrequent but random points of time. See:
> http://smeden.org/jumps.jpg
> (the green trace is the temperature of my watermaker, the blue sea- and
> the red outdoor-temperature)
> I have had this system since 2005 but not seen this behaviour before.
> Today I am using owfs 2.9p5. The sensors are a mix of old and new ones.
> Has anyone seen this behaviour? Is there any explanation?

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
Håkan Elmqvist | 12 Sep 17:18 2014

unruly temperatures

Suddenly my temperature readings have started to jump up and down about 0.5 degree C at infrequent but random points of time. See:
http://smeden.org/jumps.jpg
(the green trace is the temperature of my watermaker, the blue sea- and the red outdoor-temperature)
I have had this system since 2005 but not seen this behaviour before. Today I am using owfs 2.9p5. The sensors are a mix of old and new ones.
Has anyone seen this behaviour? Is there any explanation?
Thanks in advance
H

--
Håkan Elmqvist
Sunnerdahlsv 7
167 62 Bromma
Telefon: +46 (8) 80 18 81, +46 (704) 56 74 81, +46 (176) 84 077
epost: hakelm <at> smeden.org
Kryptera mera!
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Owfs-developers mailing list
Owfs-developers <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Stefano Miccoli | 12 Sep 00:40 2014

allow independent installation of perl5/php/python in ownet

Hi:

you all know that there are 2 sets of perl/python/php bindings:

*) one based on swig in module/swig/{perl5,php,python} that accesses the 1wire bus directly
*) one based on the owserver protocol in module/ownet/{perl5,php,python}

The problem with the current configure script is that disabling swig or one of the swig bindings
(./configure --enable-swig=no  or ./configure --enable-owperl=no --enable-php=no --enable-python=no) also prevents the installation of the corresponding ownet binding. This is really a nuisance, since it is often useful to install just the bindings from ownet, without being forced to compile/install the whole swig thing. 

The enclosed patch tries to solve this by decoupling the --with-python --with-perl5 --with-php options from the corresponding --enable-ow{perl5,php,python} options.

So, considering for example python, if this patch is applied:

--with-python=no disables both module/ownet/python and module/swig/python
--enable-swig=no disables the whole module/swig
--enable-ownet=no disables the whole module/ownet

--enable-owpython=no disables only module/swig/python

This latter options is somehow redundant with my patch: in fact  --with-python --enable-swig and --enable-ownet are clearly orthogonal to each other, while --enable-owpython lies in the space spanned by --with-python and --enable-swig. However I was unsure if it would be acceptable to drop this well known option.

Stefano

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Owfs-developers mailing list
Owfs-developers <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Howell, Larry (Contractor | 10 Sep 17:43 2014

code not able to access owfs

Our project is developing an embedded system running Linux 2.6.35 on an i.MX53.  Fuse is built in to the kernel.  The system utilizes plugin devices that store configuration data on internal DS2505s.  We’re using owfs-2.8p15 and writing application code based on the owcapi.  The system uses a DS2482-800 bus master and the initialization parameters are ‘i2c=/dev/i2c-2:0 –m mnt/1wire --allow_other’.  The filesystem mounts with expected permissions, and non-root users can access the filesystem with no problem from the bash shell.  However, the application code fails all attempts at filesystem access with a ‘permission denied’ error.  Searching the owfs man pages hasn’t provided any clues about this problem.  Any pointers or suggestions would be greatly appreciated.

 

Thanks for your help!

 

Larry Howell

 

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Owfs-developers mailing list
Owfs-developers <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Mick Sulley | 6 Sep 00:53 2014

DS2413 Power

Just testing a Sheepwalk dual channel IO board, based on DS2413 and it 
does not have a 'power' register.  Is there any way to tell if it is 
running parasitic or has a 5v supply?

Thanks
Mick

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
Colin Law | 4 Sep 22:25 2014
Picon

Owserver hang on TPLink WR703N with OpenWRT

Hi

I have put OpenWRT (AA) on a TPLink WR703N and installed owserver from
the openwrt repository (owserver version 2.8p13-1) with remarkably few
problems.  Using a LinkUSB all seems well initially.  Unfortunately
after a few minutes operation owserver hangs.  Running with log level
9 the log contains:
....
 CALL: ow_parsename.c:FS_ParsedName_anywhere(95)
path=[/28.601DE1020000/temperature12]
  DEBUG: ow_cache.c:Cache_Get_Device(927) Looking for device 28 60 1D
E1 02 00 00 C4
  DEBUG: ow_cache.c:Cache_Get_Common(1083) Search in cache sn 28 60 1D
E1 02 00 00 C4 pointer=0x77c8f900 index=0 size=4
  DEBUG: ow_cache.c:Cache_Get_Common(1099) Value found in cache.
Remaining life: 4 seconds.
  DEBUG: ow_presence.c:CheckPresence(76) Found device on bus 0
  DEBUG: ow_read.c:adjust_file_size(329) file_length=12 offset=0 size=1
  DEBUG: ow_cache.c:Cache_Get_Common(1083) Search in cache sn 28 60 1D
E1 02 00 00 C4 pointer=0x77c79130 index=0 size=8
  DEBUG: ow_cache.c:Cache_Get_Common(1115) Value found in cache, but
expired by 99 seconds.
  DEBUG: ow_cache.c:Cache_Get_Simul_Time(986) Looking for conversion
time 28 60 1D E1 02 00 00 C4
  DEBUG: ow_cache.c:Cache_Get_Common(1083) Search in cache sn 00 00 00
00 00 00 00 00 pointer=0x77c8f8f8 index=0 size=0
  DEBUG: ow_cache.c:Cache_Get_Common(1119) Value not found in cache
  DEBUG: ow_cache.c:Cache_Get_Internal(956) 28 60 1D E1 02 00 00 C4 size=4
  DEBUG: ow_cache.c:Cache_Get_Common(1083) Search in cache sn 28 60 1D
E1 02 00 00 C4 pointer=0x77c78290 index=-2 size=4
  DEBUG: ow_cache.c:Cache_Get_Common(1119) Value not found in cache
  DEBUG: ow_select.c:BUS_select(66) Selecting a path (and device)
path=/28.601DE1020000/temperature12 SN=28 60 1D E1 02 00 00 C4 last
path=00 00 00 00 00 00 00 00
  DEBUG: ow_select.c:BUS_select(79) Continuing root branch
  DEBUG: loop.c:Ping_or_Send(112) Taking too long, send a keep-alive pulse
  DEBUG: to_client.c:ToClient(56) payload=-1 size=0, ret=0, sg=0x0 offset=0
  DEBUG: to_client.c:ToClient(63) Send delay message
  DEBUG: loop.c:Ping_or_Send(112) Taking too long, send a keep-alive pulse
  DEBUG: to_client.c:ToClient(56) payload=-1 size=0, ret=0, sg=0x0 offset=0
  DEBUG: to_client.c:ToClient(63) Send delay message
  DEBUG: loop.c:Ping_or_Send(112) Taking too long, send a keep-alive pulse
  DEBUG: to_client.c:ToClient(56) payload=-1 size=0, ret=0, sg=0x0 offset=0
  DEBUG: to_client.c:ToClient(63) Send delay message
... ad infinitum  (or at least ad nauseam).

It fails on two different 1-wire networks and two LinkUSB adaptors,
one of which has been running with owserver on a Sheeva Plug for
several years.

Any suggestions gratefully accepted.

Colin

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
Stefano Miccoli | 28 Aug 13:00 2014

bug in owlib/src/c/ow_net_server.c

Hi,

commit 2e36ac0ecefb45ff4b741a9afe4d33a40025e346
Author: Paul Alfille <paul.alfille <at> gmail.com>
Date:   Tue Aug 26 15:23:36 2014 -0400

    Coverity changes
    
    Not sure if these are really issues, but making changes for Coverity
    scanning error.


The above commit introduces a Coverity induced bug!

in file module/owlib/src/c/ow_net_server.c memory cleanup belongs to the child thread (routine ProcessAcceptSocket) and not to the calling routine (ProcessListenSocket).

In fact pthread_create returns before processing in ProcessAcceptSocket is ended, so struct asd must not be freed in the calling routine.

A patch that undoes the modification is enclosed.

Stefano

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Owfs-developers mailing list
Owfs-developers <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Gmane