This is why I voted No on the last Right to Repair ballot question

Josh Siegel, an assistant professor of engineering at Michigan State University who studies connected-car security, says the automakers might be right, and the system envisioned by the law may not be technically doable. Siegel says the ballot measure may have been “well intentioned,” but it wasn’t written “with a full understanding of the complexity of automotive telematics systems.” Those systems give access not just to data about what’s broken and why but also to the driver-assistance systems that enable emergency braking and elements of the drive-by-wire system that helps drivers control their cars. Asking the automakers to pull together a safe and open telematics system in just a few months wasn’t realistic, Siegel says.

“I think that they could create a platform that would meet some of the requirements of what the legislation is calling for,” he says, “but I wouldn’t want it in my own car.”

Source: A fight over the right to repair cars turns ugly | Ars Technica

Engineers Are Upset They Have to Actually Read

“For I2C, you’ve got 100KHz and 400Khz versions, and often there will be conflicting addresses on the bus that need to be dealt with, requiring the engineer to actually read the data sheets.”

Source: The Trouble with Sensor Interfaces | FierceElectronics

<sarcasm>This is terrible engineers actually having to read a data sheet.</sarcasm>

I get it, management, like the guy quoted above, would like to be able to use closer to minimum wage illiterate bumpkins rather than well paid literate engineers to help the bottom line. Gee I wonder if this kind of thinking is a source of why the quality of engineered products just keeps getting worse.

Windows 10 device descriptor request failed

Yesterday I encountered the error in the post title when moving my StarTech 4 Port USB to Serial Adapter from a 10 year old PC (that finally died) to my current engineering workstation. I’d never experienced that particular error before so I Googled it and read about a dozen articles with suggestions for fixing it and none of them helped.

Being an engineer of electronic instruments I realized I needed to step back, assume nobody posting on the internet really has a full grasp of how USB works, and think about the system and how to methodically troubleshoot the problem. I soon realized that I’d skipped what should always be the first tests, cables. I have the USB/Serial box mounted at the test bench and it’s connected via a long USB cable and extension back to my workstation. To make a long story short, I learned that this device is less tolerant of using excessively long (out of spec long) USB cables than other USB 2.0 devices I use. For convenience I was using an existing run that made the total distance 8 meters. Swapping the 4.5 meter extension cable for a 2 meter extension cable fixed the problem.

BTW – looking back on this problem where I wasted at least an hour of my time I noticed there was a clue on the product page. The Accessories tab lists one single item, 15 ft USB 2.0 Active Extension Cable.

Disable Serial Mouse Detection

Microsoft Windows’ backwards compatibility with ancient hardware is usually nice to have but sometimes it detects other serial devices as a serial mouse. This happens whether the device is connected to a real TIA-232 port or a Universal Serial Bus (USB) to TIA-232 adapter. Some USB connected devices, e.g. GPS receivers, have USB to TIA-232 convertors built right into the device.

  1. Tap the Windows key to begin a start menu search
  2. Start typing regedit and when the menu entry for Registry Editor App appears
  3. Right click the menu entry and choose Run as administrator
  4. When the, Do you want this app to make changes to your device?, prompt appears choose the Yes button
  5. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\sermouse
  6. Since Windows 10 updates will sometimes change this value back to the default, bookmark this entry so you can get back to it easily in the future.
  7. Change the value of the Start key from 3 to 4
  8. Close Registry Editor and reboot the PC

I learned which registry key to change and its setting options from here and here.

If you want to retain the capability of using a serial mouse and just disable it for on one port see here.


Microchip Support is Amazing

We had one of our Microchip ICD3‘s fail last week so I put in a support ticket via the web site. I figured I wouldn’t hear back for a couple days because Microchip is right in the thick of their annual Masters engineering event. To my surprise they called me soon after to ask about the issue, find out if it was urgent (it wasn’t we keep a spare on hand) and to apologize in advance for possibly slower than normal responses due to the Masters event. Today I got a notice that a replacement ICD3 has been sent out.

Wow even with the event going on they still were able to get this all done in less than one week. Thank you so much Microchip your customer service is amazing.

PS – Their products are great too!

Windows 7 Desktop Shortcuts and USB COM port problems solved

A while back (I’ve been too busy to blog much for almost a year) I was puzzled to find some of my desktop shortcuts disappearing seemingly randomly. A page in the Microsoft Knowledge base explained why it was happening. In my particular case the shortcuts where pointing to network shares and documents and neither of the proposed solutions was right for me. Then in a flash of inspiration I realized that if I put those shortcuts inside of a folder on the desktop the System Maintenance troubleshooter doesn’t touch them.

My old XP box finally died so I had to move my USB to EIA-232 adaptors to my Win 7 box. Shuffling the devices around between various USB ports and hubs I saw the old problem of new COM port numbers being assigned to the adaptor with each USB port change. This of course rapidly leads to having to deal with COM10+. I vaguely remembered that there was a way to remove the extra ports so that once the adaptors where in their final USB destinations they’d have the low numbers I like. Searching around I found this excellent page with instructions.

See Also:
Device Manager does not display devices that are not connected to the Windows XP-based computer, from Microsfot
How to Find Hidden COM Ports, from Adafruit
USBDeview, from NirSoft

3/16/2015 Update: Updated the URL, added other reference URLS

An Insanely Intrusive EULA

UPDATE Feb. 29, 2012 – A new version of MPLAB X has been released and they removed the auditing clause completely. That makes this old post no longer applicable.

Thank You Microchip

On the Microchip forum somebody read the license agreement for their new free IDE, “MPLAB X” and found this in section 1c.

Microchip’s authorized representatives will have the right to reasonably inspect, announced or unannounced and in its sole and absolute discretion, Licensee’s premises and to audit Licensee’s records and inventory of Licensee’s use of the Software, whether located on Licensee’s premises or elsewhere, at any time, in order to ensure Licensee’s adherence to the terms of this Agreement.

What! They demand the right to enter a companies or persons premises unannounced because someone clicked yes on a EULA! It turns out this is not all that new for Microchip, a post from June 2009 says that this is also in the dsPIC dev kit EULA.

This could be a huge problem for my work, I can’t imagine the company lawyers are going to allow me to use MPLAB X with this onerous of a EULA. Thankfully all current Microchip based projects are using MPLAB 8 and their Hi-Tech C Pro compiler which do not have this condition on usage. The problem will be in five or more years when MPLAB 8 is gone and we still need to support our products (our average life cycle is 20 years). I’ll just have to remember to keep a copy of MPLAB 8 around so that I can still use their debuggers and programmers when needed in the future.

I hope they change their tune and remove this onerous clause. If they do not change this I will be forced to no longer consider Microchip processors for new projects :-(.

Thanks to Alan on the PIClist for pointing this out.

Concentricity vs. Runout

What is the relationship between concentricity and runout? I keep seeing this question come up on the net and very few places seem to give the correct answer. Usually the discussion gets bogged down and confused by people adding in circularity and/or parallelism of 3D objects and somehow people end up saying that they are numerically equivalent or no conversion is possible.

The correct answer is concentricity is one half of the runout value. Don’t believe me, here’s how George Schuetz of Mahr Federal Inc. explains it in his paper “TIR Versus Concentricity for Coaxiality“.

Simply put, and ignoring any error in form or alignment, the TIR check bases its coaxiality reading on diameters, while the concentricity check calculates radii.

See, it’s diameter versus radius, one half. Still don’t believe it, see if this description makes more sense to you.

Although it is never written this way, concentricity is a bilateral measurement (+/-). Think about it, a shaft and attached disc centered at the origin with a concentricity error on the disc of +1 unit. When you rotate the shaft 180° the error is now -1 unit. However TIR is always a unilateral measurement, so the +/-1 becomes +2/-0.

Still not grokking this, then look at this 2D graphical representation (click image for full size).


Hopefully this clears up the confusion, and you get the basic geometric rule. Concentricity error is exactly one half of the runout error. Still don’t believe it, then try it for yourself in your favorite CAD program or with a physical 2D model.

2021-11-06: A reader has informed me that the error of concentricity is properly referred to as eccentricity. Since eccentricity is the antonym of concentricity that makes sense to me, but since the post has been up for 11 years I’m leaving the main body as is.

Warning about Green Laser Pointers

The NIST has just released a report and warning about a serious safety issue with some green laser pointers.

Late last year, the research team purchased three low-cost green laser pointers advertised to have a power output of 10 milliwatts (mW). Measurements showed that one unit emitted dim green light but delivered infrared levels of nearly 20 mW, powerful enough to cause retinal damage to an individual before he or she is aware of the invisible light.

NIST’s researchers have devised a simple test that you can do yourself to make sure your green laser pointer is safe (see the full report).