[0x402DF854]

I've bought ~100 of these sensors from ali and ebay and 9/10 had troubles reporting temperatures in passive mode reliably. However simply repeating requests until sensor reports a valid value (!=+85C and !=-127C) works fine. Rarely I've seen sensors not working in passive mode at all.

Still, I always recommend running an extra +VDC wire (3 wires vs 2 wires isn't a big inconvenience). When running large 1-wire buses (>100m long, dozens of sensors each), a dedicated power line is always a must.

Another funny use for these sensors is a source of nonce/id. Weirdly, every single DS18B20 I've bought had a unique ROM address, even when I got large batches. I still PTSD about that batch of PCIE network cards with identical MAC addresses...

[metaphor]

> However simply repeating requests until sensor reports a valid value (!=+85C and !=-127C) works fine.

You know you're dealing with counterfeits and you know they're unreliable, but you've somehow convinced yourself that despite all the uncovered variance sitting on the table, if you keep poking long enough until the component returns some non-edge-case value, then it "works fine".

I must have hopped on the sanity train quicker than I should have because it seems like I'm missing something critical in the narrative here.

[yjftsjthsd-h]

> You know you're dealing with counterfeits and you know they're unreliable, but you've somehow convinced yourself that despite all the uncovered variance sitting on the table, if you keep poking long enough until the component returns some non-edge-case value, then it "works fine".

Yes? Because it usually does? If you test a bunch of fakes and they tend to be either basically accurate xor really inaccurate, and your project isn't super critical, why not? It's like unit testing; if you trust your tests, then any function which passes is probably fine to use. I wouldn't do it for something mission-critical, but for fun hobby stuff I probably would.

[user5994461]

Are these SMT components that have to be soldered for testing? Hardware is not as trivial as software to test and replace.

[metaphor]

"usually"..."basically"..."probably"...that's a lot of handwaving. Your usecase is both your prerogative and your folly to embrace; that's not the point.

I poke fun at the OP because his qualifier for "works fine" is an indeterminate definition of eventually establishing some semblance of compliant 1-wire communication with a counterfeit component without even so much as batting an eye to question the accuracy of the sensor measurement being read in, let alone:

  a) environmental constraints
  b) electrical constraints
  c) timing constraints
  d) system integration considerations
  e) counterfeit variance/unpredicability

No, this is not even remotely asymptotic to the implications of software unit testing. This is physical hardware which manifests real variance "vetted" by some half-baked functional "test" that completely ignores every parametric spec without discrimination. Without questioning implementation merits, your software unit tests operate on hash-replicable code...at the silicon level, such a luxury doesn't exist.

[yjftsjthsd-h]

I think the difference here is that you're taking this from the perspective of an actual engineer, and I'm a hobbyist (and I assumed the same of OP; I hope Real Engineers aren't getting parts off eBay). Which means that, yeah, I'm happy to handwave a lot. By software analogy, I write a lot of shell scripts and python, which is passable but hardly rigorous; if I wanted it to be Correct, I'd break out coq or write in Ada or something, but I just want something that usually works because the stakes are so low. Of course counterfeit parts aren't reliable, but if failure is an option then they're good enough.

[0x402DF854]

You are indeed missing something here :)

Long 1-wire networks are notoriously unreliable [1]. Something that works fine today can stop working tomorrow. That doesn't mean that they shouldn't be used anywhere. They have their niche.

If I want my heating system monitor to report temperatures once per hour and it takes me 5 tries and 10 seconds to read a sensor, I call it good enough. If monitor doesn't succeed after 20 retries, it sends an alert to replace the sensor (so far that only happened due to damaged wiring, not the sensor itself).

It is possible (and quite fun) to build reliable systems using somewhat reliable components :)

[1] https://www.maximintegrated.com/en/design/technical-document...

[metaphor]

Thanks for the perspective. 2 points in which I disagree: on design and on reliability.

First, on design. In your cited app note, Maxim explicitly denotes from the onset:

> Operating a 1-Wire network beyond the limits or disregarding advice given in this document may result in unreliable network performance.

The key operator that I see here is "beyond the limits", to which Maxim engineers appear to have done a fair job of specifying. Indeed, there's a lot of fine print in the published datasheet[1] alone on "parasite power mode", but a first pass suggests this is nothing more than a nuanced design challenge, not one of questionable reliability. If your long 1-wire network works today but not tomorrow, then it's difficult to swallow attribution of the issue to a singular authentic component constrained by documented performance specs rather than the system's overarching design.

Second, on reliability. Since practicing engineers don't have the leisure of independently validating every bit of specified electrical minutae, we generally have to extend some level of trust to what the component vendors specify in datasheets unless presented with evidence to the contrary (because bugs). I poke fun at your "works fine" remark above because it reads like what you care about is some semblance of establishing trivial, intermittent communication while handwaving the accuracy of the reported temperature measurement, especially given all the effort to demonstrate and document that the physical implementations of these counterfeits are clearly different...which renders the reference datasheet null and void in its entirety...which I therefore conclude nothing about these counterfeit sensors can be trusted in any application with meaningful skin in the game. To describe these counterfeits as "somewhat reliable" strikes me as somewhere between naively optimistic and outright delusional.

But hey, your hardware, your problems...just saying. :)

[1] https://datasheets.maximintegrated.com/en/ds/DS18B20.pdf

[0x402DF854]

I am having troubles understanding your reply. You're saying that these counterfeit sensors cannot be used for anything critical with "meaningful skin in the game", which is an obvious statement. In fact, depending on definition of "critical" and "skin in the game", one can make an argument that authentic DS18B20 sensors also aren't good enough. So what?

This whole story about not using things where they shouldn't be used is like saying "don't use an arduino on a chemical plant". Thanks, we get it.

> The key operator that I see here is "beyond the limits", to which Maxim engineers appear to have done a fair job of specifying

Except that limits are not well specified since they depend on too many factors (ambient temperature, parasitic cable capacitance, noise pickup, etc). These are recommendations on improving reliability, not hard guarantees. I'd recommend actually reading that note.

> If your long 1-wire network works today but not tomorrow, then it's difficult to swallow attribution of the issue to a singular authentic component constrained by documented performance specs rather than the system's overarching design.

This is again a trivial statement. Where did I claim the opposite?

If a weather monitor equipped with 1-wire devices has intermittent communication issues, do you immediately replace the entire system? Good luck with that proposal :)

If you replace your 1-wire driver on the above mentioned system to the one with active pullup and issues go away, do you still scrap the system because it's "out of spec" according to recommendations?

> Since practicing engineers don't have the leisure of independently validating every bit of specified electrical minutae, we generally have to extend some level of trust to what the component vendors specify in datasheets unless presented with evidence to the contrary (because bugs).

Again not sure what's the point of this trivial statement. Yes, bugs. I, "practicing engineer", have the leisure to independently validate datasheets when required. I also rely on them when I can. So what?

> especially given all the effort to demonstrate and document that the physical implementations of these counterfeits are clearly different...which renders the reference datasheet null and void in its entirety...

I invite you to research re. FDTI-gate and its widespread use, including medical devices.

Are you comfortable using light bulbs purchased from amazon in your kitchen without looking at the reference datasheet?

If I need an accuracy of +/- 5 degrees for not critical monitoring purposes, can I use "counterfeit" DS18B20 sensors?

If I need an accuracy of +/- 0.1 degrees for critical monitoring purposes, can I use "authentic" DS18B20 sensors?

Answers are as obvious as your statement.

> which I therefore conclude nothing about these counterfeit sensors can be trusted in any application with meaningful skin in the game

Your subjective "meaningful skin in the game" doesn't tell much. What sensors do you trust? Do you require calibration certificates traceable to a secondary standard for each component for them to be blessed for "application with meaningful skin in the game"?

[stickfigure]

"If a straight line fit is required, only sample two points."

[paulie_a]

Some medical equipment works the same way in my experience. A nurse or I will routinely ask to redo a reading because the value "didn't seem right"

And sure enough that happens about 1/3 of the time regardless of equipment or facility.

So "just doesn't feel right" is something that absolutely happens in the real world. Not taking that into account is sloppy engineering