Re: 1-Wire Presence Pulse
Eloy Paris <peloy <at> chapus.net>
2012-06-16 20:27:39 GMT
Hi Phil,
On 06/16/2012 07:43 AM, Phil White wrote:
> On 13 June 2012 02:01, Eloy Paris<peloy <at> chapus.net> wrote:
>
>> All 1-Wire devices have this "presence pulse" feature that you mention
>> -- that's a fundamental part of the protocol, and all slave devices need
>> to generate a presence pulse right after they detect a reset pulse
>> generated by the master.
>
> My belief is that this statement is not correct - and it is this that
> has caused the confusion and prompted the original question.
I have no experience with the DS1990A and DS1990R, but after seeing your
comment that my statement above is incorrect, I read the datasheets for
both and I still see no indication of a slave that can act on its own,
i.e. without the master initiating communication first. A slave that can
do that (initiate communication on its own) would be speaking a protocol
different than 1-Wire, or a 1-Wire protocol extension that I have never
heard of.
> See the difference between the DS1990A and DS1990R (both of which are
> in active production). I have carefully compared the two datasheets,
> and there is almost no difference - except for these:
> "Upgrade of DS1990A Guarantees Presence Pulse on Contact"
> "Presence Detector Acknowledges When Reader First Applies Voltage"
> "The DS1990R is a fully compatible variant of the DS1990A. In applications
> where a presence pulse on contact is critical, the DS1990R should be
> preferred over the DS1990A."
Yes, I see these comments in the DS1990R datasheet, and I think they are
misleading (or confusing at best), especially the "Presence Detector
Acknowledges When Reader First Applies Voltage" one ("acknowledge" only
shows up *once* in the datasheet, so what do they mean by that??? It
definitely can mislead someone into thinking that these slave devices
have a mind of their own).
If you look at the "Initialization" section in both datasheets you'll
see that they are identical, and that the initialization sequence
"consists of a reset pulse transmitted by the bus master followed
by presence pulse(s) transmitted by the slave(s)". Additionally, figure
5 in both datasheets shows the protocol flowchart. I think is is
obvious, based on the flowcharts, that the devices will not generate a
presence pulse on their own; a reset pulse from the master needs to
happen first.
Now, there is obviously a difference between these two parts, and it has
something to do with a "guarantee that a reset pulse will be generated
on contact". I don't know exactly what they mean by that, but I suspect
(and this is just speculation on my part) that the difference is that in
the case of the DS1990R, its circuitry will collect enough power on
contact, i.e. after connection to the bus, to generate the presence
pulse after seeing the reset pulse from the master. This is in contrast
to the DS1990A, where I *assume* it needs to be connected to the bus for
a longer time so it can generate the presence pulse.
Note the difference in note #13 in the "ELECTRICAL CHARACTERISTICS" section:
DS1990R: Note 13: Presence pulse after POR is guaranteed by design, not
production tested.
DS1990A: Note 13: Presence pulse is guaranteed only after a preceding
reset pulse (tRSTL)
Basically, I think it boils down to: the DS1990R is guaranteed to be
ready to operate as soon as it is connected to the bus, but the DS1990A
is not (it requires some minimum time to be connected to the bus before
it is ready to operate).
Again, this is just my interpretation of the difference between these
parts. I could be wrong although nothing that I read in these datasheets
indicates that there is a variation of the 1-Wire protocol, or that
slaves can initiate communication on their own. If anyone has experience
with these devices, or knows for sure what they mean by "presence pulse
guaranteed on connect", I'd love to hear.
> Additionally, having watched i-button authentication in action, these
> devices sit on the bus for a very short amount of time. Is the
> controller constantly polling every (say) 125 milliseconds? If so,
> this would suggest I cannot mix an i-button lock on the same bus as my
> temperature sensors.
Good point. If the slave cannot initiate communications then polling by
the master is the only option, and you are right in that a reasonable
polling frequency will be necessary so the user does not experience a
boring waiting time.
Here's sample code to read a DS1990R (note the polling by calling the
OWTouchReset() function from the main loop):
http://www.electronics-base.com/index.php/projects/complete-projects/127-ibutton-avr-readout-example-project-used-with-ds1990r-f5
(This code polls 5 times per second.)
I still think you could mix your temperature sensors with these iButton
locks -- the temperature sensors will generate their presence pulses
after the reset from the master (say, 125 msecs), but that does not mean
that you have to read them; you could read them at some other (longer)
interval that is good for your application.
> This is my current plan - though my (lack of) free time is limiting
> my progress. As stated, it requires the DS18B20 to be powered, so I
> have been working on a suitable circuit and pcb. (I have not yet
> ascertained the best way of how I should deliver the power in, as I
> have a long bus length, and all the docs suggest that the use of
> adjacent wires has an impact on communication timing and
> reliability).
Check out this PCB:
http://www.digitemp.com/dt1a.shtml
Very simple PCB. I used his EagleCAD files and had a bunch made. I am
using them extensively throughout my house (I didn't put cat5 female
connectors on all and instead just soldered a small segment of cat5
cable directly to the PCB and attached a cat5 male connector to the
other side of the cable, and then into the jack on the wall). You can
try sending power through the cat5 cable; the above PCB supports that
(via configuration jumper).
Cheers,
Eloy Paris.-
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> It was simply referencing what I understood. As can be deduced from
> the preceeding posts, I know *** *** (absolutely nothing) about this -
I know just enough to be dangerous but I've spent sometime getting
myself familiar with the 1-Wire protocol since I created a
microcontroller-based 1-Wire slave that I am using in production around
my house, and coexisting with DS18B20s.
> I just have to rely on Dallas datasheets, which aren't very clear. The
> other problem I am noticing more and more is that URLs for datasheets
> etc. give a 404 error, so there is less info available.
Yup, the datasheets aren't very clear in some cases. I like the 1-Wire
flowcharts and 1-Wire timing diagrams in the datasheets, but the
datasheet that says that the presence pulse is "guaranteed on contact"
is a bit confusing for sure.
>>> this would suggest I cannot mix an i-button lock on the same bus as my
>>> temperature sensors.
>>
>> Good point. If the slave cannot initiate communications then polling by
>> the master is the only option, and you are right in that a reasonable
>> polling frequency will be necessary so the user does not experience a
>> boring waiting time.
>
> Good. Well, that's as good as a definite for me that a lock facility
> should be on a separate circuit. However, a switch sensor, which I
> only need to poll every minute, is quite feasible.
Good luck with your project! Let us know how things go.
Cheers,
Eloy Paris.-
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. 
RSS Feed