Link to the blog post with the background on why this was made : https://ericwbailey.website/published/you-must-listen-to-rfc-2119/

Based solely on this drawing – since I don’t have a datasheet for the PWM controller depicted – it looks like the potentiometer is there to provide a DC bias for the input Aux signal. I draw that conclusion based on the fact that the potentiometer has its extents connected to Vref and GND, meaning that turning the wiper would be selecting a voltage somewhere in-between those two voltage levels.

As for how this controls the duty cycle of the PWM, it would depend on the operating theory of the PWM controller. I can’t quite imagine how the controller might produce a PWM output, but I can imagine a PDM output, which tends to be sufficient for approximating coarse audio.

But the DC bias may also be necessary since the Aux signal might otherwise try to go below GND voltage. The DC bias would raise the Aux signal so that even its lowest valley would remain above GND.

So I think that’s two reasons for why the potentiometer cannot be removed: 1) the DC bias is needed for the frequency control, and 2) to prevent the Aux signal from sinking below GND.

If you did want to replace the potentiometer with something else, you could find a pair of fixed resistors that would still provide the DC bias. I don’t think you could directly connect the Aux directly into the controller.

Another example of 120: the California State Legislature is a bicameral body with 120 total members, with 80 in the Assembly (lower house) and 40 in the Senate (upper house).

And a related piece of trivia regarding fractional currencies: although the USD has been decimalized more-or-less since its inception, the USA stock markets continued to use fractional prices for shares up until 2001, down to 1/16 of a dollar.

are not audio drivers but PWM drivers

They can be both! A Class D audio amplifier can be constructed by rendering an audio signal into a PWM or PDM output signal, then passed through an RC filter to remove the switching noise, yielding only the intended audio.

That said, in this case, using the unfiltered PWM output would work for greeting cards, where audio fidelity is not exactly a high priority, but minimal parts count is.

This made me wonder if normal PWM controllers could be used to drive more power full LEDs.

What exactly did you have in mind as a “normal PWM controller”? There’s a great variety of drivers that produce a PWM signal, some in the single watt category and some in the tens of kilowatts.

Whether they can drive “more powerful” LEDs is predominantly a function of the voltage and current requirements to fully illuminate the LEDs, plus what switching frequency range the LEDs can tolerate. Some LED modules that have built-in capacitors cannot be driven effectively using PWM, as well as anything which accepts AC rather than DC power. You’d need a triac to dim AC LED modules, and yet still, some designs simply won’t dim properly.

My idea was to just remove the potentiometer and feed in music from Aux at that point.

You’ll have to provide a schematic, as I’m not entirely sure where this potentiometer is. But be aware that the output current needed to drive a small speaker is probably insufficient to light up a sizable LED, nevermind the possibility of not even having enough voltage to meet the required forward voltage drop of the LED.

Is there a chance of this working?

It might, but only if everything just happens to line up. But otherwise, it’s likely that it won’t work as-is, due to insufficient drive current.

Insofar as the skills hierarchy that software engineers develop well after learning to write in a programming language, I’m left wondering what scenarios or industries are the most “vibe coding” proof. That is to say, situations that absolutely require from day 1 a strong sense of design theory, creativity, and intimate knowledge of the available resources.

Musing out loud, history has given us examples of major feats of software engineering, from the Voyager spacecrafts, to retro console games squeezing every byte of ROM for value, to the successful virtualization of the x86 instruction set. In these scenarios, those charges with the task has to contend with outerworldly QA requirements and the reality that there would be no redo. Or with financial constraints where adding an extra PROM would cascade into requiring a wider memory bus, thus an upgraded CPU, and all sorts of other changes that would doom the console before its first sale. Or having to deal with the amazing-yet-arcane structure of Intel’s microchip development from the 80s and 90s.

It is under these extreme pressures that true diamonds of engineering emerge, conquering what must have appeared to be unimaginably complex, insurmountable obstacles. I think it’s fair to say that the likes of NASA, Sony and Nintendo, and VMWare could not possibly have gotten any traction with their endeavors had they used so-called “vibe coding”.

And looking forward, I can’t see how “vibe coding” could ever yield such “ugly”-yet-functional hacks like the fast inverse square root. A product of its time, that algorithm had its niche on systems that didn’t have hardware support for inverse square roots, and it is as effective as it is surprising. Nowadays, it’s easy to fuzz a space for approximations of any given mathematical function, but if LLMs were somehow available in the 90s, I still can’t see how “vibe coding” could produce such a crude, ugly, inspirating, and breathtaking algorithm. In the right light, though, those traits might make it elegant.

Perhaps my greatest concern is that so-called “vibe coding” presents the greatest departure from the enduring ethos of computer science, a young field not too tainted by airs of station. This field, I like to think, does not close its doors based on socioeconomic class, on the place of one’s birth, or upon the connections of one’s family. Rather, the field is so wide that all who endeavor for this space find room to grow into it. There is a rich history of folks from all sorts of prior occupations joining into the ranks of computer science and finding success. The field itself elevates them based on what they contribute and how they solve puzzles.

What strikes against this ideal is how so-called “vibe coding” elevates mediocrity, a simulacra of engineering that produces a result without the personal contribution or logic solving to back it up. It is akin to producing artwork that is divorced from the artist’s experience. It embodies nothing.

To be clear, the problem isn’t that taking shortcuts is bad. Quite the opposite, shortcuts can allow for going farther with the same initial effort. But the central premise of “vibe coding” is to give off the appearance of major engineering but with virtually no effort. It is, at its core, deceitful and dilutes from bona fide engineering effort and talent.

Circling back to the earlier question, in my personal opinion, something like the Linux kernel might fit the bill. It’s something that is now so colossally large, is contributed to by an enormous user and developer base, and fills such a sizable role in the industry, that it’s hard to see how “vibe coding” can meaningful compete in that space.

BTW, you might consider posting about your finished results at !micromobility@lemmy.world . We enjoy all things bicycle-related there, especially when it’s solving a unique problem or solving it in unique ways.

(sorry for the long delay)

From your description, I’m wondering if the internal pull-up from the bike computer might actually be an active output, and that the open-drain buffer is causing the bike computer to give up sourcing that pull-up voltage. That is to say, if a larger-than-expected current is drawn from the bike computer, it might trigger a protection mechanism to avoid damage to its output circuitry.

To that end, I would imagine that either: 1) an inline resistor to limit drain current, 2) a push-pull buffer, or 3) both, would help rectify the issue.

My suspicion is based purely on the fact that getting stuck low for an open-drain device could be an issue “upstream”. If it were stuck high, I wouldn’t normally suspect this path.

If you still have the original configuration, measurement of the drain current would be valuable info, as well as the current when the buffer is omitted (when the motor and bike computer are directly attached, a la factory configuration). That would indicate if perhaps the currents are too mismatched.

For your edit #2, can you post a schematic of the relevant part of the circuit? It’s a bit hard to imagine how things are arranged, especially where your pull up resistor at the output of the buffer is.

If I had to guess, perhaps the buffer circuit is going onto latch-up due to ESD spikes, which is then locking the open drain to conduct, which is why you’re seeing a LOW output.

When in doubt, I suppose you can tack on more decoupling capacitors nearby the buffer’s Vcc.

When the buffer gets into this glitch scenario, is the output stuck at high or low?

Switching noise is naturally the first place to look, when an IRQ is firing rapidly and unexpectedly. But have you verified that your IRQ handler is completely handling each interrupt event? And that another interrupt event while handling the prior one will not lead to unusual behavior?

It could very well be a rare, spurious interior firing due to noise, but then exacerbated by an IRA handler that doesn’t clear properly, leading to high speed sprioois events.

What are the approximate sizes for the internal and external pull-up resistors you’ve attached? And what is the impedance for the actual interrupt source, when it actually fires?

Yep, sometimes acetone will do that. But other times, another solvent like gasoline might do the trick. Or maybe a heat gun.

I see it as an engineering challenge, how to best remove intrusive logos from stuff. IMO, all this is part-and-parcel to the second part of: reduce, reuse, recycle. Also, sometimes certain logos can be clipped in very creative ways haha

It doesn’t work for backpacks that might have the company name embroidered on, but for cheaper print-on-demand items like hats and water bottles, acetone will cause the logo to dissolve or shift.

That says, I have personally removed embroidered logos from clothes before, when the product itself is excellent but aesthetically ruined by a logo. It’s very finnicky work with a seam ripper, and has gained me a lot of nice thrift store finds.

Well, since I’ve already linked to two of my not-quite-a-lathe projects, I might as well link to the one which started it all: https://sh.itjust.works/post/16087080

This one does have a motor, but not a conventional one at all. And this only worked because the thing I’m turning would need a center hole drilled through anyway.

Thank you for the kind words! All of the tools I used were things that were laying around. I’m marginally better at woodworking than metalworking, so that’s why the jig holding the bar was all wood.

I did think about attaching the motor from a disused drill press to spin the bar, but that seemed like it would invite all manner of complexity.

Lathe is in my future, but I kinda want a CNC first. But a CNC lathe would be god-tier.

I am a big fan of makeshift lathes, for tasks that don’t necessitate a full metal workshop. Though I do hope to have a small lathe one day.

The datasheet for the IRF1404Z does indeed show that the TO-220 package variant has a limit of 120 A continuous at 25 C. It should be noted that the junction temperature is rated for up to 175 C, which might provide a lot of headroom for, but we’ll see.

The minimum dimensions for the drain and source leads are 0.36 mm by 1.14 mm. This gives us some 0.41 mm^2 cross sectional area. Assuming the leads are made of aluminum – I’m on mobile and can’t quickly check the composition for the generic TO-220 package – which has a resistance of about 60 Ohm per km, and with the lead being a maximum length of 14.73 mm, the resistance of either lead will be some 0.88 mOhm.

At 120 Amps, the resistance heating would be about 12.6 Watts. That’s quite hot for a short lead, and there’s two of them. But the kicker is that these aluminum leads are also thermally conductive, either into the package towards the junction, or away and into a generous PCB layer or to suitably-sized copper wires.

Either way, that will sink a fair amount of heat, although the thermal resistance for the package legs is not given in this datasheet. It may be defined for generic TO-220 packages though.

As a practical matter, to operate a MOSFET ar 120 A would likely require active cooling, and their test jig plus all reasonable implementations will have a fan. Moderate airflow over the leads will also wick temperature away, which might bring the leads down to a “hot but not fire-inducing” levels. But an EE or thermal engineer would need to sit down to do that simulation.

It’s worth keeping in mind that metals can get quite hot and still maintain their structure, although the NEC (electrical code in the USA) ampacity charts would suggest that 14 AWG (~2.5 mm^2) is only good for 15 A. Building wiring is a different beast, and those charts are written by fire engineers, whose job is to avoid the preconditions for house fires. Hence, extremely conservative for temperature rise. Whereas electronics in a metal box with active airflow can take substantial liberties with metal’s current carrying ability.

I’m reminded of Matt Parker demonstrating recursion in Microsoft PowerPoint:

https://www.youtube.com/watch?v=b-Fa6HtvGtQ

For timekeeping, you’re correct that timezones shouldn’t affect anything. But in some parts of law, the local time of a particular place (eg state capital, naval observatory, etc…) is what might control when a deadline has passed or not.

If we then have to reconcile that with high speed space travel, then there’s a possibility of ending up in a legal pickle even when the timekeeping aspect might be simple. But now we’re well into legal fanfiction, which is my favorite sort but we don’t have any guardrails ground rules to follow.

Up until the astronaut part, I was fully convinced that this is a law school theoretical question for an inheritance class, because that’s exactly where the vagaries of “is she my sister?” would also arise.

Then again, if we include time dilation due to near-lightspeed travel, we then have to deal with oddball inheritance cases like if your sister dies mid-travel but then you also die. The Uniform Simultaneous Death Act adopted by several US States would only apply if the difference in time-of-death is within 120 hours, but the Act is silent as to which reference plane will be used, especially if your sister is considered to be traveling “internationally” due to being in space, thus not being in the same US state or time zone as you might be in.

So maybe the entire question is a valid inheritance case study after all.