wcunning

Lots of automotive OEMs want that specific kind of information for generic reasons (how many of what model made it to what mileage under what circumstances) that are entirely reasonable. Lots of them also want that info for warranty related reasons (you've hit the mileage limit and we won't do anything for you anymore). But, my state of Michigan is starting a program to evaluate replacing registration fees with mileage charges to account for the additional wear and tear on the roads from EVs that don't pay gas taxes to fund road repairs. This would require some kind of verification of mileage, which we can't currently do during emissions testing, since it doesn't exist here. Legally required data retention is becoming a bigger and bigger issue, particularly in light of the driver monitoring requirement starting in MY27 vehicles by the Bipartisan Infrastructure Act terms. That will presumably be integrated into any black box recording in a crash and probably subpoenaed in any dispute going forward.

In other news, I think I'll be taking a trip to somewhere down south to find a nice, used 1999 F350 dually with a manual transmission, since they're going to cease to exist shortly...

The issue is less the wear and tear of the battery and motors and more the wear and tear of everything else -- suspension and brake components are going to need replacing, along with radar and ultrasonic modules, etc. These parts will be at least partially end-of-life and hard to get by the end of that 20 year period. Federal law requires some amount of parts availability for 10 years + some release of part designs to the aftermarket after that, but I have a hard time getting parts for 21 year old Ford designs that were less than popular, so I would be surprised if early Tesla models are having an easy time 20 years on. This gets much much worse as you start to look at the number of abandoned EV models from the Big 3, the abandoned/dead/dying companies (Fiskar, Lucid, Lordstown, etc). That doesn't hit the vast majority of all EVs, which are just Tesla, but it does put a dent/makes the buying decision harder. Now expand that to not just Tesla, but what does Tesla do with a Cybertruck? Like all things, the specific product decision matters a lot, and this is a new area (even at 14 years old) so there will be lots of people who optimized for cost and not maintainability.

Location: Detroit, MI

Remote: Yes

Willing to relocate: no

Technologies: Embedded systems, automotive, machine learning, signal processing, data science, real time computing, safety processes (MISRA, ISO26262, etc), MATLAB, FPGA.

Resume: LinkedIn -- https://www.linkedin.com/in/wcunning

Email: wdocunningham \@\ gmail.com

Background: Masters in control theory and signal processing, working in the auto industry for the last 7 years, first on low level powertrain software then the last year or so on LIDAR/computer vision for autonomous vehicles. I've done the most work in C, but I'm now contributing to safety development work with the Rust consortium and Ferrous Systems through my current employer.

Currently doing software defined vehicle software architecture with a focus on fail-safe and fail-operational, loosely coupled, distributed systems. This includes some standards contributions and work with high level suppliers like Nvidia and Renesas for next-generation software/hardware system co-development.

Primary skills include hard real time embedded systems, safety critical applications, firmware development, system integration and complex hardware/software interaction debugging, along with detailed data analysis problems.

Side interests include machining, 3D printing, embedded system development, coffee roasting and furniture making.

Location: Detroit, MI

Remote: Yes

Willing to relocate: no

Technologies: Embedded systems, automotive, machine learning, signal processing, data science, real time computing, safety processes (MISRA, ISO26262, etc), MATLAB, FPGA.

Resume: LinkedIn -- https://www.linkedin.com/in/wcunning

Email: wdocunningham \@\ gmail.com

Background: Masters in control theory and signal processing, working in the auto industry for the last 7 years, first on low level powertrain software then the last year or so on LIDAR/computer vision for autonomous vehicles. I've done the most work in C, but I'm now contributing to safety development work with the Rust consortium and Ferrous Systems through my current employer. Recently had to read the Linux kernel source and use the BCC tool suite to find a subtle issue in the network stack causing high latency on sensor data for AV, also coincidentally fixed most of the network timing infrastructure.

Currently doing software defined vehicle software architecture with a focus on fail-safe and fail-operational, loosely coupled, distributed systems. This includes some standards contributions and work with high level suppliers like Nvidia and Renesas for next-generation software/hardware system co-development.

Primary skills include hard real time embedded systems, safety critical applications, firmware development, system integration and complex hardware/software interaction debugging, along with detailed data analysis problems.

Side interests include machining, 3D printing, embedded system development, coffee roasting and furniture making.

Location: Detroit, MI

Remote: Yes

Willing to relocate: no

Technologies: Embedded systems, automotive, machine learning, signal processing, data science, real time computing, safety processes (MISRA, ISO26262, etc), MATLAB, FPGA.

Resume: LinkedIn -- https://www.linkedin.com/in/wcunning

Email: wdocunningham \@\ gmail.com

Background: Masters in control theory and signal processing, working in the auto industry for the last 7 years, first on low level powertrain software then the last year or so on LIDAR/computer vision for autonomous vehicles. I've done the most work in C, but I'm now contributing to safety development work with the Rust consortium and Ferrous Systems through my current employer. Recently had to read the Linux kernel source and use the BCC tool suite to find a subtle issue in the network stack causing high latency on sensor data for AV, also coincidentally fixed most of the network timing infrastructure.

Currently doing software defined vehicle software architecture with a focus on fail-safe and fail-operational, loosely coupled, distributed systems. This includes some standards contributions and work with high level suppliers like Nvidia and Renesas for next-generation software/hardware system co-development.

Primary skills include hard real time embedded systems, safety critical applications, firmware development, system integration and complex hardware/software interaction debugging, along with detailed data analysis problems.

Side interests include machining, 3D printing, embedded system development, coffee roasting and furniture making.

This is going into the next Wifi standard specifically to get this data off of normal wifi traffic.

The much much much more concerning part of this bill in my opinion is the part that applies this expectation to CNC machining equipment. This means that there will be some ugly consequences to running real industry out of New York state. Probably heavy import and cross shipping delays (lots of German machining equipment passes through the port at NY/NJ, so could theoretically be subject to this, even if eventual delivery is to Texas, for instance). The reasoning behind things like the old "receiver is the only part of the gun to be serialized and tracked" and "80% AR Lower Receiver" were to prevent impact to non-gun industries. Block of steel with random holes is not a gun is an important concept. My only conclusions are: 1) very glad I don't live in New York, 2) buy my used VMC sooner rather than later to avoid this stupidity. Much like continuing to drive my 2010 Miata a lot longer since it doesn't have all this terrible new technology that prevents maintenance (VIN locked modules, no home programming software to replace things, etc etc).

The Friends of the Wanamaker Organ society is doing work with the new owners towards preservation. I doubt it's going anywhere, but concerts will be sporadic for a while.

The biggest thing is what kind of "coffee" you mean by coffee -- cold brew in particular tends to be a much higher extraction % since the bitter notes you get on higher extractions are less noticeable at colder temperatures. The rest is what the sibling responses mention -- time of day and speed of absorption in the digestive system can have big impacts.

James Hoffman did some interesting videos on that -- espresso is a more efficient extraction method than Aeropress, but less complete than a very high water to coffee ratio pour over for the same weight of ground coffee. Extraction of caffeine is very directly tied to contact time and temperature, so two double shots of espresso (40g coffee) can actually be less caffeine extracted than a single large pour over (25g coffee) when the pour over is upwards of 22% extraction (typical of 20:1 water to coffee ratios and modern zero-bypass brewers). Similarly, there are large differences in beans, so 22% extraction on weak caffeine beans might be way less than 18% extraction on much higher caffeine beans. This is most obvious in the fact that Robusta has much higher caffeine on average than Arabica. Also, 22% extraction has a lot more unpleasant bitter compounds, not just more caffeine, so it's not my preference for taste in general.

Location: Detroit, MI

Remote: Yes

Willing to relocate: no

Technologies: Embedded systems, automotive, machine learning, signal processing, data science, real time computing, safety processes (MISRA, ISO26262, etc), MATLAB, FPGA.

Resume: LinkedIn -- https://www.linkedin.com/in/wcunning

Email: wdocunningham \@\ gmail.com

Background: Masters in control theory and signal processing, working in the auto industry for the last 7 years, first on low level powertrain software then the last year or so on LIDAR/computer vision for autonomous vehicles. I've done the most work in C, but I'm now contributing to safety development work with the Rust consortium and Ferrous Systems through my current employer. Recently had to read the Linux kernel source and use the BCC tool suite to find a subtle issue in the network stack causing high latency on sensor data for AV, also coincidentally fixed most of the network timing infrastructure.

Currently doing software defined vehicle software architecture with a focus on fail-safe and fail-operational, loosely coupled, distributed systems. This includes some standards contributions and work with high level suppliers like Nvidia and Renesas for next-generation software/hardware system co-development.

Primary skills include hard real time embedded systems, safety critical applications, firmware development, system integration and complex hardware/software interaction debugging, along with detailed data analysis problems.

Side interests include machining, 3D printing, embedded system development, coffee roasting and furniture making.

This is mostly a function of the markets for used EVs and used ICE vehicles being the same and the used EV purchaser is not a target market for EVs in general.

Not that many people can afford a new car now at all, and of those who can, they're getting luxury end cars, generally. Luxury vehicles depreciate faster than non-luxury vehicles, generally. People who want used cars are frequently people who can't afford new cars, thus they want something that works in their area in their situation with their stuff as it stands. Many of these people live in places with poor charging networks or rent and cannot install a charger. Used EVs don't come with a free charger like new ones often do. EVs were also being priced and purchased based on the tax credit for quite a while, which meant that price was a little... soft? On top of that, many EVs that fit into this data are selling for less for real reasons, like the uninsurability of Cybertrucks and the range loss on the Bolt EV. This all drives demand down or shifts the curves and lowers prices. It's just a small market for now.

Thus the starting out part. Certifications, years of experience, skills in terms of welding exhaust or the like all raise that, but mechanics get screwed on their rate regularly, which is why they're dropping out. See one of the other top level comments about "shortage -> low wages."

The impression I got from seeing the demonstration was that this was the result of years of negotiating and arguing to get to something fair. Ford doesn't love it, dealers don't love it, but no one can really come up with a major improvement.

$20 is starting as I understand, and goes up quite high for master mechanics with certifications. That's how I meant that to be read.

I started out my automotive software career with Ford, and as part of the new college hire training program, I actually got to see the process of how "book rate" is determined. They take a brand new car, straight off the assembly line and give a master mechanic a process sheet (head gasket remove and replace, for instance). He has a tool cart with a computer next to it, about 6 feet away from the vehicle. For each step he starts a timer on the computer for that step, picks up the necessary ratchet and socket or whatever, loosens the next bolt, walks the ratchet and socket back to the tool box, puts it away and then finally stops the timer. He probably practices the procedure a few times before the timed run, but basically this prevents the company from setting the time to do a job super crazy low.

He's also not allowed to take any shortcuts from the book procedure, which there frequently are a few available (use a long wobble extension bar and a universal joint and you can get in without taking off all of the stuff above that bolt, whatever). On the other hand, this is the warranty rate (meaning new cars, largely less rust, etc). Independent/non-dealer mechanics will typically charge more time than the warranty time estimate from the manufacturer to account for things like rusty vehicles with harder to remove bolts and such, though this is usually in the rate book they subscribe to from whatever information source they pay for (warranty + 20% or so).

The issue is that the estimated time for a job is probably a high estimate for a brand new car and probably a low estimate for a several year old car, and the risk of that is on the dealership. The dealership then pays mechanics an hourly wage ($20+, fairly high for well certified master mechanics) and assumes that the hours listed on the job from the manufacturer are accurate, leaving the mechanic to take the risk if it goes over. Generally, the dealership loses on this proposition too, since they lose out on business/bay/electric/heat/etc for the lost time, so they don't like warranty work. They can upcharge/charge for more time/etc on a job for a customer, not for warranty repair due to contractual obligations to the OEM. This is particularly bad for Ford, since they currently lead the industry in recalls and warranty spend, meaning that their dealership networks are getting a lot more of that kind of work with limited profit and no ability to turn it down.

Location: Detroit, MI

Remote: Yes

Willing to relocate: no

Technologies: Embedded systems, automotive, machine learning, signal processing, data science, real time computing, safety processes (MISRA, ISO26262, etc), MATLAB, FPGA.

Resume: LinkedIn -- https://www.linkedin.com/in/wcunning

Email: wdocunningham \@\ gmail.com

Background: Masters in control theory and signal processing, working in the auto industry for the last 7 years, first on low level powertrain software then the last year or so on LIDAR/computer vision for autonomous vehicles. I've done the most work in C, but I'm now contributing to safety development work with the Rust consortium and Ferrous Systems through my current employer. Recently had to read the Linux kernel source and use the BCC tool suite to find a subtle issue in the network stack causing high latency on sensor data for AV, also coincidentally fixed most of the network timing infrastructure.

Currently doing software defined vehicle software architecture with a focus on fail-safe and fail-operational, loosely coupled, distributed systems. This includes some standards contributions and work with high level suppliers like Nvidia and Renesas for next-generation software/hardware system co-development.

Primary skills include hard real time embedded systems, safety critical applications, firmware development, system integration and complex hardware/software interaction debugging, along with detailed data analysis problems.

Side interests include machining, 3D printing, embedded system development, coffee roasting and furniture making.

Two double shots of espresso and straining is a thing of the past, regardless of diet.

There has been a move to get the FTC to start labeling these net carbon numbers as misleading advertising because it always includes a bunch of purchased offsets unrelated to the company. Further, there have been some real and complicated situations where carbon credits were sold more than the actual amount of offset carbon -- meaning for example BigCorpA and BigCorpB buy the same "green energy infra" credits from projects that are in construction and then never actually meet their listed goals, but both companies claim to be carbon neutral because of the claims for several years before that comes out. Matt Levine had a very interesting column on forestry in the US Southeast talking about places getting paid to not cut down trees far in excess of the number of trees that could realistically be harvested. Google might be frontrunning some of those arguments. Or might have done the real audit of the claims and realized that they had been less carbon offset than they thought, so safer to just pull the whole pledge at least in the short term.

Location: Detroit, MI

Remote: Yes

Willing to relocate: no

Technologies: Embedded systems, automotive, machine learning, signal processing, data science, real time computing, safety processes (MISRA, ISO26262, etc), MATLAB, FPGA.

Resume: LinkedIn -- https://www.linkedin.com/in/wcunning

Email: wdocunningham \@\ gmail.com

Background: Masters in control theory and signal processing, working in the auto industry for the last 7 years, first on low level powertrain software then the last year or so on LIDAR/computer vision for autonomous vehicles. I've done the most work in C, but I'm now contributing to safety development work with the Rust consortium and Ferrous Systems through my current employer. Recently had to read the Linux kernel source and use the BCC tool suite to find a subtle issue in the network stack causing high latency on sensor data for AV, also coincidentally fixed most of the network timing infrastructure.

Currently doing software defined vehicle software architecture with a focus on fail-safe and fail-operational, loosely coupled, distributed systems. This includes some standards contributions and work with high level suppliers like Nvidia and Renesas for next-generation software/hardware system co-development.

Primary skills include hard real time embedded systems, safety critical applications, firmware development, system integration and complex hardware/software interaction debugging, along with detailed data analysis problems.

Side interests include machining, 3D printing, embedded system development, coffee roasting and furniture making.

Student housing near the engineering campus at University of Michigan is about 1/2 mile away from the reasonably close Kroger grocery store. When I started there in 2009, the carts didn't have the locking wheels and many people would take the cart all the way back to their apartment complex -- this meant that the Kroger store manager had to rent a moving van every so often and go collect them all as the carts cost $500~1000 new, so replacing them when they're 1/2 mile to a mile away wasn't good economics. Eventually this got so bad (never a cart at the store when you wanted one, had to go get them all the time) that they switched to the geolocking wheels, which was a pain because the geolock frequently false detected if you were at the back of the annoyingly small parking lot, so there were always carts stuck in the back ~20 spots.

Later, my girlfriend told me that the specialty foreign foods store near the Big Lots she worked at in a different Detroit suburb would intentionally come steal the Big Lots carts, rather than pay for their own (see above, expensive), so the Big Lots clerks would occasionally get sent on a mission with a moving van to get a bunch of their carts from the next shopping center over's parking lot. I think they might not have ever paid for the geolocking wheels, since Big Lots is low margin and those options are pretty expensive, but you can see the incentive to do so.

Also they've been bought out by private equity an prices have shot through the roof -- Vegas is seeing massive downturns in tourism and from my cursory following of the problem, it's all price increases on food, booze, travel, hotels on the Strip making people uninterested in going.

I think a lot of people feel the same way. Not to say that I'm in a comparable situation -- I also want to leave, but there are good days and bad days and I don't feel nearly as economically comfortable as I'd like to leave, etc etc.

I guess a response question to you, OP, how bad is the job if you just start doing less? It's not like you care about promotion chances or long term outcomes, so just do exactly what's assigned and nothing more.

Location: Detroit, MI

Remote: Yes

Willing to relocate: no

Technologies: Embedded systems, automotive, machine learning, signal processing, data science, real time computing, safety processes (MISRA, ISO26262, etc), MATLAB, FPGA.

Resume: LinkedIn -- https://www.linkedin.com/in/wcunning

Email: wdocunningham@gmail.com

Background: Masters in control theory and signal processing, working in the auto industry for the last 7 years, first on low level powertrain software then the last year or so on LIDAR/computer vision for autonomous vehicles. I've done the most work in C, but I'm now contributing to safety development work with the Rust consortium and Ferrous Systems through my current employer. Recently had to read the Linux kernel source and use the BCC tool suite to find a subtle issue in the network stack causing high latency on sensor data for AV, also coincidentally fixed most of the network timing infrastructure.

Currently doing software defined vehicle software architecture with a focus on fail-safe and fail-operational, loosely coupled, distributed systems. This includes some standards contributions and work with high level suppliers like Nvidia and Renesas for next-generation software/hardware system co-development.

Primary skills include hard real time embedded systems, safety critical applications, firmware development, system integration and complex hardware/software interaction debugging, along with detailed data analysis problems.

Side interests include machining, 3D printing, embedded system development, coffee roasting and furniture making.

@yankcrime posted it above: https://www.brendangregg.com/blog/2024-03-24/linux-crisis-to...

That's where you start down the eBPF rabbit hole with bcc/biolatency and other block device histogram tools. Further, the cache hit rate and block size behavior of the SSD/NVME drive can really affect things if, say, your autonomous vehicle logging service uses MCAP with a chunk size much smaller than a drive block... Ask me how I know

Literally did miracles at my last job with the first book and that got me my current job, where I also did some impressive proving which libraries had what performance with it again... Seriously valuable stuff.

There was a big thing about this a few years ago -- companies didn't want class actions (too expensive in lawyers, primarily), so they forced binding arbitration agreements into their EULA. Then a big law firm filed thousands of binding arbitrations on behalf of what was basically the class. The company had to pay $1000's/arbitration in fees to the arbitration company, which also didn't have an incentive to reduce the number of arbitrations when the company tried to get out of it. Turned into an incentive to not put binding arbitration clauses in agreements...

That’s actually the standard in automotive and industrial applications — likelihood of failure vs consequences of failure, set the “acceptable” risk low and show proof that you’re not any higher than that level. Medical devices actually have a much higher “contributes in any way to any patient harm” risk analysis.

We had one of those in an underground parking garage for autonomous vehicle testing at a previous job, but it was a naturally really well shielded room, and it was just repeating surface signals so no one would complain.