I wish this entire Stealerships industry just vanishes and this reason (crazy ADMs) alone is enough. There is enough tacit collusion in the industry that makes it unnecessarily difficult to get around being ripped off.
It still is. City of SC (silicon valley power) charges $0.13/kWh vs north of $0.4x/kWh from PGE. It's simply impractical to charge EV at home regardless of which plan you pick at PGE, due to aggressive tier limits and the intentionally crippled "EV plan". PGE is legalized robbery.
To me (a C++ daily driver and Rust hobbyist) this "DAG of strongly-connected" tiered graph system is sane and maps well to practice --- tightly couple your impl details however you want, then expose a clean interface at the crate level. It encourages you to split your code to separate files as you write _without immediately forcing you to untangle the dependency_, and then as "islands" of code organically form, which pieces belong to a separate crate becomes naturally evident.
Contrast this with C++ where the DAG relationship is enforced at much lower levels (e.g. Bazel cc_library, CMake target, which in normal cases correspond to a cc/h pair), shifting the friction (of having to deal with deps) much earlier in the dev cycle, which then discourages you from (incrementally) splitting a file at all. I've seen too many times this resulting in 5000+ LoC cc file.
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)
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
> 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.
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.
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.
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.
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.
I like Zettelkasten / bunch-of-markdown-files tools because more often than not they _expand_ on this simple idea, offering additional structure on top without aiming to destruct anything.
- Obsidian: FS dir -> FS file (plain text) = Obsidian Page (automatic ordering) -> headers in the page (manual ordering + level)
While I agree in principle that some non-leaf node should be allowed to have content, really you can see that headers/sections in Obsidian map well to the OneNote page-level organization. I wish I got a choice though...
[^1]: Out of the box. OneNote also has a major plugin bundle known as OneTastic.
[^2]: OneNote has _cosmetic_ headers in textboxes which isn't very useful.
