# Why are there sensors that encode their readings as serial sequence of PWMs?

This is a comment of @CuriousCat, but I think it deserves the attention of an actual question:

The sensor used in the original question outputs a serial PWM-style signal like this:

What's the advantage for a sensor to encode its output in this way rather than the more conventional 4 to 20 mA (I'm used to seeing process sensors use this all the time) converted to digital at the receiving end?

Is this more accurate?

Alternatively why not go HART / PROFIBUS etc. ?

Follow-up questions moved to separate question: Are there standards for digital sensor links?

• Great answer: Some follow up questions: Is there any standard encoding that has evolved on the digital encoding side? Just as 4 to 20 mA is de facto standard on the analog side especially in process control? – curious_cat Nov 30 '16 at 12:41
• @curious_cat see separate question electronics.stackexchange.com/questions/272361/… – Marcus Müller Nov 30 '16 at 15:08

the more conventional 4 to 20 mA

More conventional is a very relative term, and it seems you might be coming from a process control background, where sensor signals are often processed and converted to a current internally in the sensor. Let me assure you that it's not the most common thing in the world.

What's the advantage […] rather than […] converted to digital at the receiving end?

Well, having an ADC in the microcontroller is a luxury. The sensor in question has a 14 bit output; finding a microcontroller with a 14 bit ADC will increase your material cost.

Is this more accurate?

Yes. 14 bit means $2^{14}$ possible values. Let's say the voltage signal would have a full amplitude range of 0 V to 5 V. In that case, your voltage step would be $5\cdot2^{-14}\,\text V\approx0.3\,\text{mV}$. That's very little! Interference, temperature variations and noise in your ADC will be a multiple of that, unless you can very closely control a lot of things, which will make your system very, very complex and expensive.

So: Whenever you need digital values at the end, convert analog to digital as early as technically feasible.

Alternatively why not go HART / PROFIBUS etc. ?

Because buses like these are really complicated to implement on both the sensor and the controller, and if you're really just attaching the sensor to a microcontroller on the same PCB, why make things complicated, and costly?

The four-states state machine I showed that is able to receive this kind of signal might seem complicated to someone not overly used to embedded development, but imagine you'd have to write a full PROFIBUS endpoint. Good luck!

• Is it also about the rapidity of change? i.e. In most process control applications the time constants of the underlying process are pretty slow. e.g. In (say) controlling a distillation column you may very well have an old school DCS system that polls the temperature sensor only a few times per sec. Is 4 to 20 mA more suited for this sort of change but couldn't cope up with a signal that's changing rapidly (say) thousands of times a sec? – curious_cat Nov 30 '16 at 12:44
• So I wonder, in applications where rapid change is crucial, say airplane control, avionics etc. what sort of protocols have become the convention? Do they use 4 to 20 mA or PWM or dedicated buses? – curious_cat Nov 30 '16 at 12:45
• Off topic, but I wonder what application finds use of a "cheap" yet "high-resolution" sensor, like in the original question. I mean sure it's cheap to provide 10^14 possible values but what's the smallest value-jump over which one would actually find the output of this sensor repeatable or accurate. i.e. Could the application actually trust the difference of two sensor outputs that differed 100 psi / 10^14 pressure units (encoded) as anywhere close to significant? PS. Your answer is excellent I'm just going off on a tangent questioning excessive resolution. – curious_cat Nov 30 '16 at 13:02
• @curious_cat added this to q/a above. Please don't ask this many questions in comments – better go and ask a full question! – Marcus Müller Nov 30 '16 at 13:02
• @MarcusMüller, might also be worth a footnote mentioning that these simple PWM encodings also have the benefit of having a constant and equal number of rising and falling edges, something that RS-232 does not have. This is favourable in some applications (noise / crosstalk management in high speed systems, and for 1-wire as you said which needs this for the vampire current source). – user98663 Nov 30 '16 at 13:12

The advantage of the indicated approach is that it purely digital and can thus be opto-isolated easily, but does not require any kind of precise time base in the transmitter nor receiver. A conventional UART would generally require that the combined uncertainty of the transmit and receive clocks be less than 5% (depending upon sampling jitter, it may need to be better than that). Transmitting a value of 0x00 would pulse the wire low for nine bit clocks; transmitting 0x80 would pulse it low for eight. A receiver would need to know the transmitter's clock speed fairly accurately in advance to distinguish between those byte values.

If the amount of delay on rising and falling clock edges were consistent and the transmitter's first byte always had the low bit set, the receiver could measure the length of the first low pulse and infer the baud rate from that. If the data is going through an opto-isolator or other such interface, however, that could distort the pulse length enough to cause problems. Further, a receiver would need to be able to measure pulse lengths accurately and adjust the baud rate instantly. Such things are not impossible, but are not easy either.

By contrast, with the indicated PWM transmission approach, even very crude pulse-width measurements would allow reliable transmission. A receiver which sampled the input at a rate of 4.5x or more could count the lengths of low pulses and determine which bits were ones and zeroes from that. An automatic baud rate UART would need to measure the start bit length within a few percent, which would imply much more frequent sampling.