Hi,
*Optimistic duration of conversion:*
Of course , it could be safer to allow some margin (900ms ?) before reading
back but usually datasheet are correct.
ds1820 announce 500ms max,
both ds18B20 ds18S20 announce 750ms max,
After correction of calculation, when issuing a 12 bit convertT command, the
poll convert function report the following duration :
> DEBUG: ow_1820.c:FS_poll_convert(895) BUS_transaction done after 560ms
>
Who is less than maximum in datasheets.
Maybe some user have experience with other models that take longer sample
time?
Anyhow, with the 3 retry method implemented in OW_22temp(), the risk is
minimal as fall-back retries are allowing successively 1000ms and 1500ms max
duration.
*Regarding bus utilisation during conversion
*I personnaly measured the correct behaviour only on ds18b20. (I don't have
other ds18x20 to verify)
However, even the earliest model ds1820 state explicitly this behaviour is
intended.
see this old datasheet http://www.systronix.com/Resource/ds1820.pdf at page
3 top right.
> *...Another method of supplying current to the DS1820 is
> through the use of an external power supply tied to the
> VDD pin, as shown in Figure 3. The advantage to this is
> that the strong pull–up is not required on the I/O line, and
> the bus master need not be tied up holding that line high
> during temperature conversions. This allows other data
> traffic on the 1–Wire bus during the conversion time. ...
> *
Reported problems in the link you mentioned seems related to mixed powered /
unpowered situations. This is precisely the condition that has to be
determined before deciding to lock the bus for the duration of conversion.
Also, determining if some chips are not powered could allow master to really
issue a strong pullup instead of only waiting without generating traffic.
*Determining if non-powered chips are presents:*
Using the simultaneous technique for reading powered status seems to me the
intended way to go.
The datasheet for ds18b20 describe the "READ POWER SUPPLY [B4h]"* *usage on
last paragraph of page5.
*... In some situations the bus master may not know whether the DS18B20s on
> the bus are parasite powered
> or powered by external supplies. The master needs this information to
> determine if the strong bus pullup
> should be used during temperature conversions. To get this information,
> the master can issue a Skip ROM
> [CCh] command followed by a Read Power Supply [B4h] command followed by a
> “read time slot”.
> During the read time slot, parasite powered DS18B20s will pull the bus
> low, and externally powered
> DS18B20s will let the bus remain high. If the bus is pulled low, the master
> knows that it must supply the
> strong pullup on the 1-Wire bus during temperature conversions. ...*
>
However, I traversed owfs sources to find others devices sensible to 0xB4
command and found:
- ds2436 where 0xB4 initiate a convertV command.
- ds2438 where 0xB4 initiate a convertV command and maintain the bus low
for the duration of the convert (only if read cycles are issued).
- ds2482 where 0xB4 is an i²c command that is not impacted.
So querying globally the power supply state could have side effect of
initiating a voltage conversion on present ds2436/38 devices. But this
should not harm any project. The only issue will be false presence of
unpowered temps sensors and thus forcing the waiting. which is allways
working.
Sorry for this long post :-/
Pascal
2010/1/28 Paul Alfille <[email protected]>
>
>
> On Thu, Jan 28, 2010 at 2:28 PM, Pascal Baerten
> <[email protected]>wrote:
>
>> Hi,
>>
>> I'm also concerned by responsiveness of temp readings.
>> Here my experience:
>> First, the ds18b20 chips are not continuously converting temperature
>> themselves , they only start a measurement when they receive a convertT
>> command from the master. The conversion require up to 750ms for at 12 bits
>> resolution and consume power.
>> So after issuing a convertT command (for example with "echo 1 >
>> owpath/simultaneous/temperature"), you have to wait the end of conversion
>> before the result is availlable.
>>
>
> It seems that the 750 msec is optimistic, despite what the datasheet says.
> Most 1-wire programs (digitemp, public domain kit) use 1 second. The number
> of errors (85C readings) improved when we made the change to the longer
> conversion times.
>
> Powered vs not powered chips:
>> The ds18b20 are able to work from externally powered source or from
>> parasite power. It is important to remember that using parasite power
>> require the master to maintain strong pullup on DQ during whole conversion
>> process and thus avoiding any bus activities during the conversion.
>> To avoid locking the bus by the strong pullup, you have to power
>> externally *all* temperature chips.
>>
>> I've verified that when ds18b20 chips are powered, they continue
>> conversion even if the master communicate to other devices on the network.
>>
>
> That's very interesting. I had originally designed the system that way,
> (bus communication allowed during powered conversions) but there was
> contrary information as documented here:
>
> http://article.gmane.org/gmane.comp.file-systems.owfs.devel/3200/match=powered+temperature+conversion
>
>
>> Owfs *should** *allow bus master to accept bus communication to other
>> devices during conversion.
>>
>>
> It would be easy to do (since it's the old behavior, and we specifically
> lock the bus and the slave separately to allow independent access), but I'm
> not sure if it actually works in 1-wire.
>
>
>> This is the case on my particular configuration based on a DS2482-800
>> master.
>> Here is a simple test done in php/ownet on my nslu2 with latest svn with
>> all ds18b20 present powered.
>> The last value is the measured duration in seconds that the command needed
>> to finish.
>>
>> Reading directly temperature after a simultaneous command force the master
>> to wait end of conversion before returning the result. -> we lost precious
>> time (1.20 second) waiting conversion.
>>
>>> connect to ownet 0.00356793403625
>>> set /bus.3/simultaneous/temperature=1 0.0554330348969
>>> read temperature for /uncached/bus.3/28.D1729B010000/temperature =
>>> 3.1875 *1.20092391968*
>>>
>> The next lines show that bus activity is possible without delays during
>> conversion:
>>
>>> set /bus.3/simultaneous/temperature=1 0.0292129516602
>>> set /bus.3/05.878C33000000/PIO 1 0.245070934296
>>> read /uncached/bus.3/05.878C33000000/sensed=0 0.104848861694
>>> set /bus.3/05.878C33000000/PIO 0 0.146059989929
>>> read /uncached/bus.3/05.878C33000000/sensed=1 0.100878000259
>>> ...
>>>
>> after at least 0.7 second, converted temp could be read without delay
>>
>>> read temperature for /uncached/bus.3/28.D1729B010000/temperature =
>>> 3.125 *0.182569980621*
>>> done
>>>
>>
>>
>> However, this work correctly only on specific DS2482-800, for any other
>> adapter, the bus remain locked for the duration of conversion.
>>
>>
> Right. Independent bus masters are be handled completely separately. The
> DS2482-800 is essentially 8 independent bus masters (except that some global
> settings apply to them all.)
>
>
>> here the same test done on i386 platform with an ds2490 usb master.
>>
>>> connect to ownet 0.00307703018188
>>> temperature for /bus.0/28.2DDB01020000/temperature =
>>> 20.4375 0.767754077911
>>>
>>
>>
>>> set /bus.0/simultaneous/temperature=1 *0.658293962479 *(simultaneous
>>> blocks on poll_convert)
>>> set /bus.0/12.B31F5F000000/PIO.B=1 0.174618005753
>>> read /uncached/bus.0/12.B31F5F000000/sensed.B=0 0.0654580593109
>>> set /bus.0/12.B31F5F000000/PIO.B=0 0.100481033325
>>> read /uncached/bus.0/12.B31F5F000000/sensed.B=1 0.0521919727325
>>> ...
>>> temperature for /bus.0/uncached/28.2DDB01020000/temperature =
>>> 20.5 0.113564968109
>>> done
>>>
>>
>> Paul,
>> in ow_simultaneous.c, the function FS_w_convert_temp() could handle other
>> adapter in the same way than DS2482-800. However this should be conditional
>> to whether all temp chips are powered or not. However I don't know how to
>> verify easily if this conditions is met.
>>
>>
> It gets complicated. Clearly we could have a command line switch ( but that
> goes against the simple configuration aesthetic). We could ask each chip,
> and remember the answer (which would work well as long as new slaves don't
> pop up). It's possible that we could use the same technique used for
> simultaneous conversion -- ask all the bus, but I'd have to investigate
> whether the command codes collide with other chip designs.
>
>
>>
>> Pascal
>>
>>
>>
>> 2010/1/28 Sophana K <[email protected]>
>>
>> When you "set the simultaneous convert", do you mean you write 1 to
>>> the top/simulaneous/temperature?
>>>
>>> something like this?:
>>> echo 1 > simultaneous/temperature
>>> cat 1F.C4DC03000000/aux/28.C4027E010000/temperature
>>> cat 1F.C4DC03000000/aux/28.0D337E010000/temperature
>>>
>>> This doesn't work for me, it is slow.
>>>
>>> Are you driving the "local" simultaneous files (like
>>> 1F.C4DC03000000/aux/simultaneous/temperature)
>>>
>>> What version of owfs are you using?
>>> Do you think I should upgrade?
>>>
>>> I'm also running a hvac system which currently has period of about 20
>>> seconds. Which is still ok for now.
>>> But I'm going to extend it with about 10 more sensors, and I would
>>> like it to be more reactive when driving the 4 way valves.
>>>
>>> What platform are you using? I'm considering upgrading to an low power
>>> intel atom (or d510) based PC or maybe dedicating a sheeva plug for
>>> the hvac. My current router (asus wl500g deluxe) doesn't have a real
>>> time clock so I need the internet at boot time just to get the time
>>> for my hvac system to work.
>>>
>>> Thanks for your help
>>>
>>> On Wed, Jan 27, 2010 at 6:30 PM, Jerry Scharf
>>> <[email protected]> wrote:
>>> > Sophana,
>>> >
>>> > First, I drive my sensors from python through owserver, so a simple
>>> > example probably won't help you. I don't think that "on their own
>>> > segment" is enough because the sensor can't know that, but this is
>>> > beyond my level of knowledge about 1-wire.
>>> >
>>> > What I do is set the simultaneous convert and then read the sensors
>>> > sequentially. The master can only do one thing at at time, so I didn't
>>> > see much value in doing any threading for my simple problem. The timing
>>> > definitely shows that they are not doing the conversion at read time.
>>> > It's easy to compare by just skipping the simultaneous and doing the
>>> > sequential read.
>>> >
>>> > I'm running a HVAC system, so readings every 30 seconds is fine. Not
>>> > what I would call a high speed operation.
>>> >
>>> > hope that helps,
>>> > jerry
>>> >
>>> > Sophana K wrote:
>>> >> Hi
>>> >>
>>> >> I made the tests on powered sensors.
>>> >> Some other sensors are not powered but they are "alone" on their own
>>> >> hub segments.
>>> >> You don't need to write to the simultaneous/temperature file?
>>> >> Just do parallel access to owserver?
>>> >> Or do you do both?
>>> >> Can you give an example of access sequence you are doing?
>>> >> Does owfs on top of owserver limit parallel access to the values?
>>> >> Should I try directly with threads inside my python program to access
>>> >> owserver in parallel?
>>> >>
>>> >> Thanks
>>> >>
>>> >> On Wed, Jan 27, 2010 at 5:10 PM, Jerry Scharf
>>> >> <[email protected]> wrote:
>>> >>> Sophana,
>>> >>>
>>> >>> I am sure this works. I have a hub (not a switch) and do simultaneous
>>> >>> reads for my 30+ temp sensors. Do you have separate power or are you
>>> >>> running in parasitic mode. I am fairly certain you can not do
>>> >>> simultaneous reads with parasitic power.
>>> >>>
>>> >>> jerry
>>> >>>
>>> >>> Sophana K wrote:
>>> >>>> On Mon, Jan 11, 2010 at 4:35 PM, Paul Alfille <
>>> [email protected]> wrote:
>>> >>>>
>>> >>>>> It's easy to do if the segments are on different bus masters. Just
>>> read in a
>>> >>>>> different thread or program since only the bus master is locked. An
>>> >>>>> asynchronous read property for temperature is also possible.
>>> >>>> I tried this, but it doesn't seem to work.
>>> >>>> I made the test through owfs on top of owserver -u with a small
>>> script
>>> >>>> making simultaneous accesses to different sensors. It is as slow as
>>> >>>> reading the sensors sequentialy.
>>> >>>> Are you sure about this feature?
>>> >>>>
>>> >>>>
>>> ------------------------------------------------------------------------------
>>> >>>> The Planet: dedicated and managed hosting, cloud storage, colocation
>>> >>>> Stay online with enterprise data centers and the best network in the
>>> business
>>> >>>> Choose flexible plans and management services without long-term
>>> contracts
>>> >>>> Personal 24x7 support from experience hosting pros just a phone call
>>> away.
>>> >>>> http://p.sf.net/sfu/theplanet-com
>>> >>>> _______________________________________________
>>> >>>> Owfs-developers mailing list
>>> >>>> [email protected]
>>> >>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>> >>>
>>> ------------------------------------------------------------------------------
>>> >>> The Planet: dedicated and managed hosting, cloud storage, colocation
>>> >>> Stay online with enterprise data centers and the best network in the
>>> business
>>> >>> Choose flexible plans and management services without long-term
>>> contracts
>>> >>> Personal 24x7 support from experience hosting pros just a phone call
>>> away.
>>> >>> http://p.sf.net/sfu/theplanet-com
>>> >>> _______________________________________________
>>> >>> Owfs-developers mailing list
>>> >>> [email protected]
>>> >>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>> >>>
>>> >>
>>> >>
>>> ------------------------------------------------------------------------------
>>> >> The Planet: dedicated and managed hosting, cloud storage, colocation
>>> >> Stay online with enterprise data centers and the best network in the
>>> business
>>> >> Choose flexible plans and management services without long-term
>>> contracts
>>> >> Personal 24x7 support from experience hosting pros just a phone call
>>> away.
>>> >> http://p.sf.net/sfu/theplanet-com
>>> >> _______________________________________________
>>> >> Owfs-developers mailing list
>>> >> [email protected]
>>> >> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > The Planet: dedicated and managed hosting, cloud storage, colocation
>>> > Stay online with enterprise data centers and the best network in the
>>> business
>>> > Choose flexible plans and management services without long-term
>>> contracts
>>> > Personal 24x7 support from experience hosting pros just a phone call
>>> away.
>>> > http://p.sf.net/sfu/theplanet-com
>>> > _______________________________________________
>>> > Owfs-developers mailing list
>>> > [email protected]
>>> > https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>> >
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> The Planet: dedicated and managed hosting, cloud storage, colocation
>>> Stay online with enterprise data centers and the best network in the
>>> business
>>> Choose flexible plans and management services without long-term contracts
>>> Personal 24x7 support from experience hosting pros just a phone call
>>> away.
>>> http://p.sf.net/sfu/theplanet-com
>>> _______________________________________________
>>> Owfs-developers mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>>
>>
>>
>>
>> --
>> Pascal
>>
>>
>> ------------------------------------------------------------------------------
>> The Planet: dedicated and managed hosting, cloud storage, colocation
>> Stay online with enterprise data centers and the best network in the
>> business
>> Choose flexible plans and management services without long-term contracts
>> Personal 24x7 support from experience hosting pros just a phone call away.
>> http://p.sf.net/sfu/theplanet-com
>> _______________________________________________
>> Owfs-developers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>>
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the
> business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Owfs-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
--
Pascal
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
