> Fourteen pins in two parallel rows carry every signal this panel produces to the rest of the vehicle. Automotive connectors are among the most common failure points in modern cars: corrosion, fretting, and thermal cycling work on these joints over years of use. One connector failure on a module this integrated takes out mirrors, windows, locks, and child safety all at once.
Pack that shit full of silicone dielectric grease, check it every year or two, and it should be good for decades.
This sounds like copy written by someone who hasn't actually spent a lot of time with the automotive world and in trying to sound like they have.
Electrical connectors on automotive harnesses are far, far more reliable now on modern cars than they ever have been in the past, even with the increase in number of such connectors.
Companies like Delphi and Amphenol put immense engineering effort into the way modern connectors are designed, with weather sealing and contact plating that is way better than anything pre 1990's-ish was. Plastics really got way better after the turn of the Millenium compared to what they were before- I remember working on 1980s cars in the early 2000s (so, 20 year old cars) where connectors would ofter crumble in your hands when disconnecting them, or have completely corroded terminals, terrible sockets that yield and wouldn't keep continuity, etc. Compared that to all the cars I've worked on in the last 20 years where connectors have just not really been a worry (among the brands I've work on, at least). The electronics / sensors / modules themselves are much more likely to fail than the connectors they attach with, in my current experience. The only time connectors seem to fail is when cycled roughly/wrongly by people doing service incorrectly. Failure in place? Rare.
Anyone who thinks automotive electronics were more reliable in the past, live a bit with the electrical systems of a car from the 1970's thru the mid 1990's and report back to me on how that goes. Bonus points if it's Italian or British.
I think the point is that all those "dumb" switches, terminals or cables that get worn out can be replaced relatively easily (ie you need a multimeter and some patience to find the bad one). But if something in the integrated module fails, well good luck repairing that. These things are probably designed to be replaced as a whole, which is fine if you can get a new one. But as the cars get older, this is going to be a problem.
Yes but specifically, in this article, the passage is written about a harness connector on a door window switch module as follows:
>Fourteen pins in two parallel rows carry every signal this panel produces to the rest of the vehicle. Automotive connectors are among the most common failure points in modern cars: corrosion, fretting, and thermal cycling work on these joints over years of use. One connector failure on a module this integrated takes out mirrors, windows, locks, and child safety all at once.
This just reads weird to me.
Corrosion on an interior module connector is not as much of a concern these days unless the car is in a flood or the door card sealing is broken due to something like a poor repair job.
Fretting? What would cause fretting on pins of a connector that never gets touched by a human after it leaves the factory. It is a static connection, it doesn't get plugged and unplugged.
Thermal cycling? It is inside a door panel... not near a hot exhaust or inside an engine. It sees normal interior temperature cycles.
An actual Closures Engineer would more likely call out vibration shock during door slam in a closures FMEA as a potential electrical window switch fault hazard resulting from the connector loosening if the chosen connector lacks sufficient mechanical fastening moreso than anything..
Saying that connectors themselves are "among the most common failure points in modern cars".... just sets of flags to me as overly flatulent, generated puff writing. "Oh I need to list three things about connectors (thinking).... Corrosion -Fretting- Thermal Cycling-!! and this makes connectors among the most common failures in modern cars (no sources cited)".
>Its driver door panel consolidates mirror adjustment, mirror fold, door locks, all four window controls, and child locks into a single networked module. That consolidation exemplifies BYD's vertical integration favoring fewer subassemblies, each designed in-house and dropped into place, with firmware determining how any of it behaves.
Integrated door switch modules have been more common than not on cars for easily the last 15 years now, and I don't think this in any way exemplifies BYD's "Vertical Integration" or "favoring fewer subassemblies" (these two things actually don't even necessarily imply each other!!). There are plenty of cars that use such assemblies and the companies outsource to tier 2's for the actual manufacturing - Mercedes and Valeo, for example. Because they don't actually take apart the module and look for, say, a logo on the silkscreen of the PCB, I don't think the author actually confirmed if BYD 'designs' (let alone manufactures) the complete switch unit in-house. They could. I'm not saying they can't. But...
But this whole article is written from a weird authoritative viewpoint when really I think it should back down a bit and just describe what the damn CT scans show.
"Four models. One topology — designed by Darren Myers, engineered by Bob Stadtherr. Driven from a state-of-the-art active power supply that delivers performance benefits no traditional transformer-based passive supply can match. Class A bias of 50 watts means your music spends 99% of its time in the most linear region of the amplifier's operation"
No; he clearly acknowledges that FLAC is lossless, so the audio is bit for bit identical to the original waveform.
The claim is that FLAC decoding digital hardware performs processing which causes noise ("computer hash") if it is not isolated from the audio paths. He gives an example of some hardware where isolation eliminates the problem, supposedly.
I'm skeptical of the claim. Not in the sense whatsoever that I suspect it being false (I don't), but in the sense that the same noisy hardware would produce some "computer hash" even if it were processing uncompressed waveform data. I don't know anything about FLAC, but cursory searches suggest that decoding it is very lightweight. Whether processing raw PCM samples, or decoding FLAC, the hardware would mostly be idle in between producing audio frames (unless it is an embedded processor that is very low in terms of computational power?)
Anyway, he's not simply an crackpot claiming that FLAC quality is inherently different from WAV.
No, the "alternative" approach looks strange in the 7 bit example.
1.0 lies on the right side of the bin 7. But 0.0 lies on the left of bin 0.
The standard approach assumes that we have centered samples: that zero is dead black, plus (and minus!) some uncertainty and so is bin 7.
If the sampling of the intensity is distortion-free (no clipping took place due to overexposure) then bin 7 represents a range of possible values centered around 1.0.
It is not a half-sized interval.
> This means that when converting floating-point values in the
[0,1] range back to integers, the extreme bins have effectively half the width of other bins.
Under any interpretation whatsoever of the image samples, there is latitude for interpreting the maximum value 255 as being distortion: clipping from an arbitrarily higher value. Shifting things by 0.5 doesn't fix this issue of not knowing whether 255 means that an intensity close to 1.0 is being represented (no distortion), or an outlier intensity of 37.49 (severely clamped). That could go the other way too.
In other words, there is a possible bias in the extreme bin. The signal could be limited such that the bin's full sampling range is not in effect, or the signal could be overwhelming, so that values far outside of the range are clipped and included.
The only way around this is to make the highest value a canary which represents "clipped value". That is to say, 255 means "clipped datum", so that only 254 and below is sampling of unclipped signal. Machine-generated image (e.g. 3D rendering) then avoid the 255 value, and camera sensors are calibrated so that it doesn't occur when technical images are being shot.
Doesn't work that way in Canada. In 2010, a 37-year-old male got 6 years for sucker-punching a 62-year-old male who made advances toward him in bar in the Vancouver west end (lotsa gays there). The 62-year-old fell, hit his head, and died as a result.
Best way to shorten a murder sentence seems to be to just do it with your car. It's crazy what people seem to get away even if they're clearly deranged, drunk, and blowing through red lights etc..
Oh, especially now in British Columbia with "no fault insurance". At-fault drivers cannot be sued by victims, unless they are convicted of a crime in connection with the incident.
If you can make the vehicular homicide look like an accident, you are scot-free, except for increased insurance premiums. No criminal charges, and no civil case to face.
152km/hr in a 60 zone, drunk, on film saying "I ain't stopping for no red lights", deliberately sped up as he was about the hit the guy, didn't stop afterward, left the scene, then called in to falsely claim the car was stolen, and had been previously convicted of sexual assault. 5 years less time served, 5 years after with no license. I guess the only way you could really top that list is if he continued on to say "hey lets hit that guy and see how far he goes"
I'm finding it hard to be motivated to continue on language dev work. I feel it may also have to do with AI. Not so much the predatory aspect of it, like this author, but something else: shall we say, certain revelations about the nature of the target audience.
You should not be seeing the same conflicts over and over again in a situation in which you are on a single branch, just rebasing your unpublished commits.
You might get conflicts regularly, if people are touching the same area of the code that you are touching, but not the same ones.
rerere mainly comes into play when people have to backport commits into multiple similar branches, due to having a heavily forked git landscape.
The point is that some organizations have a chaotic development process consisting of numerous similar branches. Often there is a main trunk, and then branches that were made for particular product variants (like piece of hardware or whatever) and cut at a particular point in time, in order to isolate from the trunk.
What then happens is that when a bug is found that affects all branches, it must be cherry picked into all of them. If that cherry pick runs into conflicts, it is often the same conflicts, over and over again on each branch.
Of course, the fix is not to do that, but it's easier to say that than to get away from that kind of workflow once you are steeped in it up to the chin.
> Often there is a main trunk, and then branches that were made for particular product variants (like piece of hardware or whatever)
I worked at a place that did this.
The code was written in C, and I always thought the better solution would have been to use #define/#ifdef to flag certain blocks of code out of the compilation.
A branch for each product was a nightmare when there were 10+ products, some with multiple variations, each on its own branch. Backporting a bug fix meant cherry-picking into 20+ branches. What made it especially stupid was office politics from each product having its own PM, and then the PM for one of the products would decide the bug wasn't significant enough to spend the time doing the cherry-pick and testing. This happened too often when it came to security fixes when a PM didn't understand the issue.
Yes; #ifdef and #endif is basically branching, but it's in one branch of the CM system.
The benefit that everything is integrated, so there are no games with having to cherry pick things this way and that and losing fixes.
The apparent downside is that there is no isolation. Inside some of those #ifdefs is code that you are not building. But changes you are making can break that code for someone else.
While this may seem risky, it's actually better. Breaking something now is better than someone cherry picking your fix 8 months later into their branch and then dealing with the breakage.
Fixes to common code never get left behind; everyone working off the trunk instantly gets them.
The #ifdefs are immediately and constantly visible, telling you where the code is that is or is not part of what you are doing, and reminding you of its existence. They greatly discourage refactoring parts that you cannot test.
There is pressure to keep those #ifdefs clean, whereas people go hog wild when they have their own branch, thinking they can rewrite whatever they want to suit what they are doing.
Pack that shit full of silicone dielectric grease, check it every year or two, and it should be good for decades.
reply