5 ms·

On a related tangent: I'm really puzzled by these PWM-based _digital_ signaling protocols --- more so (apparently in this case) where the period isn't even fixe

On a related tangent: I'm really puzzled by these PWM-based _digital_ signaling protocols --- more so (apparently in this case) where the period isn't even fixed. The most prominent example is probably the WS2812 RGB LED, a.k.a. NeoPixel. I can get it when a PWM line carries an analog-ish duty cycle signal, but using positive and negative _widths_ to signal bit-for-bit when you control both sides of the link doesn't make sense to me engineering-wise --- if not for speed (think USB3+), not for robustness (think something like Ethernet), and not for impl simplicity (think I2C/SPI/SDIO), then for what? Maximum pain when implemented by a third party? (/s but not really)

deleted 4y ago
[deleted]
aix1 4y ago
Is it this protocol we're talking about? https://cdn-shop.adafruit.com/datasheets/WS2812.pdf https://cdn-shop.adafruit.com/datasheets/WS2812.pdf (Your comment piqued my curiosity and I looked it up.) I think the desire to only use a single wire for signalling is understandable, at least in setups where there are physical wires, rather than tracks on a flex PCB, running from LED to LED. Since every rising edge is the start of a new bit, encoding each bit with an H followed by an L makes the signal self-clocking. With this, the two sides don't need very accurate -- or shared -- clocks. With the tolerances specified in the datasheet, to tell a zero from one the receiver only needs to tell whether a pulse is shorter (T0H) or longer (T1H) that 0.5us. T0L and T1L are indistinguishable (their allowed durations overlap) and don't need to be measured by the receiver. That said, I do agree that it's weird that they weren't chosen such that T0H+T0L=T1H+T1L at the centre of the tolerance range.
- userbinator 4y ago
  That said, I do agree that it's weird that they weren't chosen such that T0H+T0L=T1H+T1L at the centre of the tolerance range. It's likely they intended them to be the same, but for whatever reason the design characterisation discovered the distribution of periods are actually slightly different from the ideal design, so instead of trying to do a potentially very expensive redesign, they just documented the reality and left it at that.
NobodyNada 4y ago
The article mentions the protocol is very similar to the 1-Wire protocol, and links to the Wikipedia article, which provides some helpful clues: https://en.wikipedia.org/wiki/1-Wire https://en.wikipedia.org/wiki/1-Wire > To send a binary number "1", the bus master sends a very brief (1–15 μs) low pulse. To send a binary number "0", the master sends a 60 μs low pulse. The falling (negative) edge of the pulse is used to start a monostable multivibrator in the slave device. The multivibrator in the slave reads the data line about 30 μs after the falling edge. The slave's internal timer is an inexpensive analog timer. It has analog tolerances that affect its timing accuracy. Therefore, the pulses are calculated to be within margins. Therefore, the "0" pulses have to be 60 μs long, and the "1" pulses can't be longer than 15 μs. The other “simple” protocols you mention all require a clock line, whereas 1-Wire/IDBUS do not. UART comes closer, except it requires both devices maintain their own independent, reasonably accurate clocks. (How do you tell whether that long high pulse was 4 or 5 1-bits in a row if your clock is terrible?) If you’re trying to design a very simple system that needs to work with wildly inaccurate clocks, you need some kind of self-clocking protocol, like this, where the difference between a 1 and a 0 bit is an order-of-magnitude difference in pulse width. When I was a teen, me and a friend built a device (for a competition) that could encode and decode messages onto a roll of receipt paper by moving the paper across a reader/writer head (a sharpie attached to a servo, and a photosensor) to draw and read lines. Clocking turned out to be by far the hardest problem, because the speed at which the paper moved was too unpredictable and inconsistent (it depended on battery level, inconsistencies in the motor, how heavy the roll was, how hard the marker was making contact with the paper, etc), We spent many hours designing, testing, and tweaking the software and hardware until we arrived at basically this exact encoding scheme — plus a Hamming code based on letter frequency since we were encoding English messages. We felt very proud of this elaborate way to encode text — until we realized we had just reinvented Morse code.
- NobodyNada 4y ago
  (correction: we used a Huffman code based on letter frequency — though we did also use a Hamming code for error correction).
murderfs 4y ago
This looks very similar to 1-Wire, which is for ultra-low power devices that communicate on and are powered by the same wire. The reason the pulse widths are different is that the falling edge of the pulse kicks off an oscillator-based timer that triggers a read of the value of the line at some point between the two durations.
jrmg 4y ago
The WS2812 protocol is simpler than it first appears. Here's a great blog post about it: https://wp.josh.com/2014/05/13/ws2812-neopixels-are-not-so-finicky-once-you-get-to-know-them/ https://wp.josh.com/2014/05/13/ws2812-neopixels-are-not-so-f...
gswdh 4y ago
I think others have covered it in other posts but I’d just like to add that this protocol is only for negotiation, everything continues in the native protocol afterwards.
- sterlind 4y ago
  good catch, vouched. you're shadowbanned for some reason, fyi.

deleted 4y ago

[deleted]

aix1 4y ago

Is it this protocol we're talking about? https://cdn-shop.adafruit.com/datasheets/WS2812.pdf https://cdn-shop.adafruit.com/datasheets/WS2812.pdf (Your comment piqued my curiosity and I looked it up.) I think the desire to only use a single wire for signalling is understandable, at least in setups where there are physical wires, rather than tracks on a flex PCB, running from LED to LED. Since every rising edge is the start of a new bit, encoding each bit with an H followed by an L makes the signal self-clocking. With this, the two sides don't need very accurate -- or shared -- clocks. With the tolerances specified in the datasheet, to tell a zero from one the receiver only needs to tell whether a pulse is shorter (T0H) or longer (T1H) that 0.5us. T0L and T1L are indistinguishable (their allowed durations overlap) and don't need to be measured by the receiver. That said, I do agree that it's weird that they weren't chosen such that T0H+T0L=T1H+T1L at the centre of the tolerance range.

userbinator 4y ago
That said, I do agree that it's weird that they weren't chosen such that T0H+T0L=T1H+T1L at the centre of the tolerance range. It's likely they intended them to be the same, but for whatever reason the design characterisation discovered the distribution of periods are actually slightly different from the ideal design, so instead of trying to do a potentially very expensive redesign, they just documented the reality and left it at that.

NobodyNada 4y ago

The article mentions the protocol is very similar to the 1-Wire protocol, and links to the Wikipedia article, which provides some helpful clues: https://en.wikipedia.org/wiki/1-Wire https://en.wikipedia.org/wiki/1-Wire > To send a binary number "1", the bus master sends a very brief (1–15 μs) low pulse. To send a binary number "0", the master sends a 60 μs low pulse. The falling (negative) edge of the pulse is used to start a monostable multivibrator in the slave device. The multivibrator in the slave reads the data line about 30 μs after the falling edge. The slave's internal timer is an inexpensive analog timer. It has analog tolerances that affect its timing accuracy. Therefore, the pulses are calculated to be within margins. Therefore, the "0" pulses have to be 60 μs long, and the "1" pulses can't be longer than 15 μs. The other “simple” protocols you mention all require a clock line, whereas 1-Wire/IDBUS do not. UART comes closer, except it requires both devices maintain their own independent, reasonably accurate clocks. (How do you tell whether that long high pulse was 4 or 5 1-bits in a row if your clock is terrible?) If you’re trying to design a very simple system that needs to work with wildly inaccurate clocks, you need some kind of self-clocking protocol, like this, where the difference between a 1 and a 0 bit is an order-of-magnitude difference in pulse width. When I was a teen, me and a friend built a device (for a competition) that could encode and decode messages onto a roll of receipt paper by moving the paper across a reader/writer head (a sharpie attached to a servo, and a photosensor) to draw and read lines. Clocking turned out to be by far the hardest problem, because the speed at which the paper moved was too unpredictable and inconsistent (it depended on battery level, inconsistencies in the motor, how heavy the roll was, how hard the marker was making contact with the paper, etc), We spent many hours designing, testing, and tweaking the software and hardware until we arrived at basically this exact encoding scheme — plus a Hamming code based on letter frequency since we were encoding English messages. We felt very proud of this elaborate way to encode text — until we realized we had just reinvented Morse code.

NobodyNada 4y ago
(correction: we used a Huffman code based on letter frequency — though we did also use a Hamming code for error correction).

murderfs 4y ago

This looks very similar to 1-Wire, which is for ultra-low power devices that communicate on and are powered by the same wire. The reason the pulse widths are different is that the falling edge of the pulse kicks off an oscillator-based timer that triggers a read of the value of the line at some point between the two durations.

jrmg 4y ago

The WS2812 protocol is simpler than it first appears. Here's a great blog post about it: https://wp.josh.com/2014/05/13/ws2812-neopixels-are-not-so-finicky-once-you-get-to-know-them/ https://wp.josh.com/2014/05/13/ws2812-neopixels-are-not-so-f...

gswdh 4y ago

I think others have covered it in other posts but I’d just like to add that this protocol is only for negotiation, everything continues in the native protocol afterwards.

sterlind 4y ago
good catch, vouched. you're shadowbanned for some reason, fyi.