That’s just one of the many jobs they posted during the development of semi. They also have “real” drivers that put a ton of hours shuttling Tesla cargo from NV to CA and vise versa.
Not to mention the author is from the EU. Trucking in the U.S is vastly different. I drove in both regions during my time in the USAF.
In your honest opinion. Do you think they just developed the semi without gathering/soliciting feedback from real truck drivers?
That a very opinionated yet empty statement. Please elaborate and share your experience driving long haul semi trucks in U.S. interstates and city streets.
I am responding to the challenge that Musk doesn't ignore all sense and advice and feedback and established best practices in favor of simply what he thinks is cool.
Anyone following this as a guide: The calculations about potentiometer current are incomplete, although the selected part appears to be fine for this application.
The current in all three potentiometer terminals is limited to 25 mA. The terminal with the maximum current is not the wiper, but the end terminal which carries both the wiper current and the end-to-end current. So the part needs to handle 15 mA, not 10 mA.
It is also good to calculate the power dissipated by the potentiometer. By inspection, the Thévenin equivalent circuit of the indicator is a 12 v supply in series with (1800/2+300) = 1200 ohms. The maximum power transfer with occur when the potentiometer is also presenting 1200 ohms. This is not at either end of travel!
Going through the algebra it looks like 1200 ohms (greatest dissipation) happens at 40% of the potentiometer's travel. It's still only 124 mW, so this part is well within its 1 W absmax.
- The indicator is ratiometric and the exact supply voltage doesn't matter. If it works acceptably well down at the +5 V USB bus voltage, the circuit would get a lot simpler.
- I suspect that driving the circuit with a variable voltage is sufficient, and the potentiometer is unnecessarily. Then a DAC or PWM with a plain old opamp would do the job.
Thanks for pointing out my error in reading the data sheet on how the max terminal currents are defined. I've corrected this in my post.
On the power, I get a maximum power dissipation through R(AW) and R(WB) of 130 mW at R(AW) = 432 Ohms and R(WB) = 5000 - R(AB) = 4586 Ohms. Work is on my post.
The meters don't work well below about 18 Volts. The needle just doesn't quite make it all the way to open. My theory is the current is too small at lower voltages to completely overcome the force of the spring that pulls the needle to the out-of-range position when powered off. If the internal 300 Ohm resistance of the meter could be changed easily, then a lower voltage could work.
And yep, a DAC or PWM with an op amp with some gain would certainly work. For a lot of my past meter projects where the voltages required were 5 Volts or less, I've gone the PWM route with great success.
Welcome here! I'm always amazed by your work and have a sweet spot for custom USB devices like the DIP Switch USB stick or the knob box.
One question: is there any way to match such a device to an UI element in Windows, so that a physical knob can change the value of a slider element or a physical gauge showing a value for a software gauge/progress bar?
There used to be tools that allowed to click UI elements in a different program and change properties of these, e.g. setting a disabled UI element to enabled or reading out a value from a password field. That was 20 years ago though, so it might be possible that Windows is separating different programs more strictly these days.
Thanks! I'm working on a three-wire DC Selsyn landing gear and flaps indicator next. Just did a bunch of rework to convert it from a self-powered device to a USB bus-powered device. Hoping to get a blog post up about it in a week or two.
I need to work on a C# app to demonstrate the landing gear and flaps indicator next though. It's working in Linux using a CLI but the Windows GUI makes the demo videos easier.
I'm not aware of any way to access dialog box elements using an API but I'm also not really a Windows developer either. I thought back in the day COM was supposed to enable sharing app elements and data using OLE and ActiveX. But all that Windows tech is beyond me.
Closest thing I can think of would be a bar code reader always having focus of one particular box on a form but I don't know how that works.
Very interesting! Most people who've lived in NYC know what overheated steam-fired apartment heating feels like in the winter, but I don't think many people know the backstory here.
I can spend as much time as I like writing comments or design documentation or whitepapers or commit messages, but nobody reads it. Maybe they will set up a meeting for me to read it to them.
That's probably about right. But it's not isolated to developers. Most people skim or skip most instructions, documentation, warnings, etc.
When I write documentation I hope that people will never talk to me because the information they need is already written down. But more often it's so I can redirect them to the documentation and implicitly require that they read it before they continue to talk to me. In other words, documentation doesn't usually prevent an interruption as much as it minimizes the interruption.
I've noticed that for years in embedded (where we use "Intel HEX" formatted files) but I ascribed it to a field full of eccentric loners doing idiosyncratic things, or some kind of DOS 8.3 brain damage.
