• 4 Posts
  • 115 Comments
Joined 2 years ago
cake
Cake day: July 2nd, 2023

help-circle
  • I did indeed have a chuckle, but also, this shouldn’t be too foreign compared to other, more-popular languages. The construction of func param1 param2 can be found in POSIX shell, with Bash scripts regularly using that construction to pass arguments around. And although wrapping that call with parenthesis would create a subshell, it should still work and thus you could have a Lisp-like invocation in your sh script. Although if you want one of those parameters to be evaluated, then you’re forced to use the $() construction, which adds the dollar symbol.

    As for Lisp code that often looks like symbol soup, like (= 0 retcode), the equal-sign is just the name for the numerical equality function, which takes two numbers. The idea of using “=” as the function name should not be abnormal for Java or C++ programmers, because operator overload allows doing exactly that.

    So although it does look kinda wonky for anyone that hasn’t seen Lisp in school, sufficient exposure to popular codebases and languages should impart an intuition as to how Lisp code is written. And one doesn’t even need to use an RPN calculator, although that also aids understanding of Lisp.

    Addendum: perhaps in a century, contemporary programmers will find it bizarre that C used the equal-sign to mean assignment rather than equality, when the <= arrow would more accurately describe assignment, while also avoiding the common error of mixing up = and == in an if-conditional. What looks normal today will not necessarily be so obvious in hindsight.



  • But could this comparison not be done with some hysteresis?

    It can, but analog design is also not my forte.

    The part count is not important as long as the parts aren’t terribly expensive, since this is exclusively for my personal use

    In that case, the original suggestion of using an ADC and an op-amp would be the most flexible for software. You would, however, need to do some research on wiring an op-amp to amplify the sense voltage to something your microcontroller’s ADC is capable of resolving.



  • Ah, I entirely missed the sense pin when skimming the datasheet.

    That said, using a shunt for an inductive load like a motor may have to contend with the corresponding spikes caused when switching the motor. This just means the thing doing the sensing needs to tolerate the spikes. Or mitigate them, with either a snubber or a flyback diode (is this actually doable with an H bridge?).

    As for the op-amp and ADC, if we already accept the additional of the op-amp part, it is also feasible to instead use a comparator with a reference voltage set for the max safe current. The digital output of the comparator can then be fed directly to the microcontroller as an interrupt, providing fast reaction without the sampling time of an ADC. But this would be so quick that the spikes from earlier could get picked up, unless mitigated. It also means software will not know the exact current level, other than that it’s higher than the threshold set by the reference voltage.

    Still, these solutions are adding to the part count. If that’s a concern, then I’d look for a motor driver with this functionality built in.


  • In that case, I would suggest looking at a different motor driver. The driver you’ve specified doesn’t seem to have any provisions to detect a motor stall, which is something that other drivers can potentially do. Ideally, the driver would detect the back EMF from the stall and inform the microcontroller, which would then decide to stop movement.

    An external current sensor might work, but that’s adding to the part count and might not be as capable as built-in functionality within the motor driver. Plus, fancier motor drivers have some neat features that you could take advantage of as well. I think it would be more prudent to consider a different driver before adding additional parts.


  • I don’t think there’s a good way to adapt this circuit to provide current limiting on the 18v rail. Supposing that it was possible, what behavior do you want to happen when reaching the current limit? Should the motor reduce its output torque when at the limit? Should the 18v rail completely shut down? Should the microcontroller be notified of the current limit so that software can deal with it? Would a simple fuse be sufficient?

    All of these are possible options, but with various tradeoffs. But depending on your application, I would think the easiest design is to build sufficient capacity on the 18v rail so that the motor and 5v converter inherently never draw more current than can be provided.



  • I suppose the first question is whether you had the baud rate set correctly. The photo of the “cleaned up signals” (not entirely sure what you did, compared to the prior photo) seems to show a baud rate of 38400, given that each bit seems to take about 25 microseconds.

    As for the voltage levels, the same photo seems to show 5v TTL. So it doesn’t seem like you would need a level converter from 15v RS-232 levels. This is one of the few times where the distinction between a “serial port” and an RS-233 port makes a difference, but a lot of data center switches will deal using 5v TTL, because the signals aren’t having to travel more than maybe 5 meters


  • Methodology:

    To determine the bath, shower and bidet hotspots around the world, we calculated the percentage of hotel bookings in each country, state and city that have showers, baths or bidets.

    We used Booking.com to determine the total number of accommodations (hotels, apartments, holiday rentals, etc.) in each geography and then found the number of accommodations in each geography that have either baths, showers or bidets using Booking.com filters.

    I was unable to find an option for “baths, showers, or bidet” in the booking.com filters, let alone options for each of those individually. So I’m not sure about the exact data used for this infographic.




  • I’ve changed the setting to prevent the behavior, but the prompt is still missing.

    You’ve disabled the automatic switching based on HDMI CEC, and yet the TV still automatically switches and without a notification/option in advance? This just sounds like a firmware update for the TV introduced a bug.

    I’m in the same camp with the other commenter who suggested never attaching a so-called smart TV to the Internet, for then it can never perform an unwanted update. Because for whatever neat features an update may bring, it rarely can be reversed if proven to be undesirable. I’m staunchly in the “own your hardware” camp, so automatic-and-non-undoable updates are antithetical to any notion of right-to-repair principles, and will inevitably lead to more disposable and throwaway electronics.

    [gets off soapbox]

    Your best bet might to try attempting a manual software downgrade using a USB stick.



  • 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.



  • 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.



  • (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.