Hi Phil, On 06/16/2012 07:43 AM, Phil White wrote:
> On 13 June 2012 02:01, Eloy Paris<[email protected]> 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/ _______________________________________________ Owfs-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/owfs-developers
