Charging an EV currently means making sure you find a station with the right plug. SAE International has now published what could be the end to the mishmash of standards in North America with the J3400 North American Charging Standard.
The SAE J3400TM North American Charging Standard (NACS) Electric Vehicle Coupler Technical Information Report (TIR), which just rolls off the tongue, details the standard formerly only available on Tesla vehicles. We previously talked about the avalanche of support from other automakers this year for the connector, and now that the independent SAE standard has come through, the only major holdout is Stellantis.
Among the advantages of the NACS standard over the Combined Charging System (CCS) or CHAdeMO is a smaller number of conductors given the plug’s ability to carry DC or AC over the same wires. Another benefit is the standard using 277 V which means that three separate Level 2 chargers can be placed on a single 3-phase commercial line with no additional step down required. Street parkers can also rejoice, as the standard includes provisions for lampost-based charger installations with a charge receptacle plug instead of the attached cable required by J1772 which leads to maintenance, clutter, and ADA concerns.
Now that J3400/NACS is no longer under the purview of a single company, the Federal Highway Administration has announced that it will be looking into amending the requirements for federal charger installation subsidies. Current rules require CCS plugs be part of the installation to qualify for funds from the Bipartisan Infrastructure Bill.
Over the years, we’ve seen a good number of interfaces used for computer monitors, TVs, LCD panels and other all-things-display purposes. We’ve lived through VGA and the large variety of analog interfaces that preceded it, then DVI, HDMI, and at some point, we’ve started getting devices with DisplayPort support. So you might think it’s more of the same. However, I’d like to tell you that you probably should pay more attention to DisplayPort – it’s an interface powerful in a way that we haven’t seen before.
The DisplayPort (shortened as DP) interface was explicitly designed to be a successor to VGA and DVI, originating from the VESA group – an organization created by multiple computer-display-related players in technology space, which has previously brought us a number of smaller-scale computer display standards like EDID, DDC and the well-known VESA mount. Nevertheless, despite the smaller scale of previous standards, DisplayPort has since become a hit in computer display space for a number of reasons, and is more ubiquitous than you might realize.
You could put it this way: DisplayPort has all the capabilities of interfaces like HDMI, but implemented in a better way, without legacy cruft, and with a number of features that take advantage of the DisplayPort’s sturdier architecture. As a result of this, DisplayPort isn’t just in external monitors, but also laptop internal displays, USB-C port display support, docking stations, and Thunderbolt of all flavors. If you own a display-capable docking station for your laptop, be it classic style multi-pin dock or USB-C, DisplayPort is highly likely to be involved, and even your smartphone might just support DisplayPort over USB-C these days. Continue reading “DisplayPort: A Better Video Interface”→
Last November, Tesla open-sourced parts of its charging infrastructure, not-so-humbly unveiling it as the North American Charging Standard (NACS). It’s finally taking off with a number of manufacturers signing on.
Companies launching “standards” based on their previously proprietary technology in opposition to an established alternative usually leads to standards proliferation. However, with recent announcements from Ford, GM, and Rivian that they would begin supporting NACS in their vehicles, it seems a new dominant standard is supplanting CCS (and the all-but-dead CHAdeMO) in North America.
As Tesla already has the most extensive charging network on the continent and has begun opening it up for other EVs, it makes sense that other marques would want to support NACS, if nothing else to satiate customer demand for a dead-simple charging experience. Dongles are annoying enough for plugging in an external monitor. Having to mess with one while handling high-power electrical connections is less than ideal, to say the least.
Well, we guess it had to happen eventually — Ford is putting plans in place to make its vehicles capable of self-repossession. At least it seems so from a patent application that was published last week, which reads like something written by someone who fancies themselves an evil genius but is just really, really annoying. Like most patent applications, it covers a lot of ground; aside from the obvious capability of a self-driving car to drive itself back to the dealership, Ford lists a number of steps that its proposed system could take before or instead of driving the car away from someone who’s behind on payments.
Examples include selective disabling conveniences in the vehicle, like the HVAC or infotainment systems, or even locking the doors and effectively bricking the vehicle. Ford graciously makes allowance for using the repossessed vehicle in an emergency, and makes mention of using cameras in the vehicle and a “neural network” to verify that the locked-out user is indeed having, say, a medical emergency. What could possibly go wrong?
Anyone who has ever made a living writing code has probably had some version of the following drilled into their head: “Always write your code so the next person can understand it.” Every single coder has then gone on to do exactly the opposite, using cryptic variables and bizarre structures that nobody else could possibly follow. And every single coder has also forgotten the next part of that saying — “Because the next person could be you” — and gone on to curse out an often anonymous predecessor when equally inscrutable code is thrust upon them to maintain. Cognitive dissonance be damned!
It’s a tale as old as time, or at least as old as programming has existed as a profession. And by 1975, poorly written code was enough of a problem that an outfit called Edutronics put together the animated gem Critical Program Reading: Structuring an Unstructured Program. It’s apparently Part 1 of a larger series on structured programming techniques, and comes to us by way of [Alec Watson], host of Technology Connections on YouTube, by way of his second channel, the delightfully named Technology Connextras.
The film’s three minimally animated characters, each of whom could have been the villain in an episode of Scooby Doo, are tasked by a stern-sounding narrator to analyze a fragment of pseudocode that’s written in a concoction of COBOL, PL/1, and a bunch of other languages. The code is a hot mess, but our heroes muddle through it line by awful line, making it more readable by guessing at more descriptive variable names, adding structured elements, and making logical changes to improve the program’s flow. The example code is highly contrived, to be sure, but the business logic becomes much clearer as our team refactors the code and makes it far more approachable.
For as much as languages have changed since the 1970s, and with all the progress we’ve made in software engineering, the lessons presented in this film are still surprisingly relevant. We loved a lot of the little nuggets dropped along the way, like “Consistency aids understanding,” and “Use symbols in a natural way.” But we will take exception with the statement “Wrong means poor structure” — we’ve written seen plenty of properly structured code that didn’t work worth a damn. We also enjoyed the attempt at socially engineering a less toxic work environment: “Use tact in personal criticisms.” If only they could learn that lesson over at Stack Overflow.
It’s not clear where [Alec] found this 16-mm film — we’d sure like to hear that story — but it’s a beauty and we’re glad he took the time to digitize it. We’re consistently amazed at his ability to make even the most mundane aspects of technology endlessly fascinating, and while this film may be a bit off from his normal fare, it’s still a great find. Continue reading “Retrotechtacular: Critical Code Reading, 70s Style”→
I’m probably as guilty as anyone of reinventing the wheel for a subpart of a project. Heck, sometimes I just feel like working on a wheel design. But if that’s the path you choose, you have to think about whether or not it’s important that others can replicate your project. The nice thing about a bog-standard wheel is that everyone has got one.
The case study I have in mind is a wall-plotter project that appeared on Hackaday this week. It’s a really sweet design, and in many ways would be an ideal starter project. I actually need a wall plotter (for reasons) and like a number of the choices made. For instance, having nearly everything, including the lightweight geared steppers on the gondola makes it easy to install and uninstall — you just pin up the timing belt from which it hangs and you’re done. Extra weight on the gondola helps with stability anyway. It’s open source and based on the Arduino libraries, so it should be easy enough to port to whatever microcontroller I have on hand.
But the image-generation toolchain is awkward, involving cutting and pasting into a spreadsheet, which generates a text file in a custom plotting micro-language. Presumably the designer doesn’t know about Gcode, which is essentially the lingua franca of moving machines, or just didn’t feel like implementing it. Where in Gcode, movement commands are like “G1 X100 Y50”, this device expects “draw_line(0,0,100,50)”. They’re essentially equivalent, but incompatible.
I totally understand that the author must have had a good time thinking up the movement commands and writing the spreadsheet that translates SVG files into them. I’ve been there and done that! But if the wall plotter spoke Gcode instead of its own dialect, it would slot instantly into any number of graphics processing workflows, which would make me, the potential user, happier.
When you are looking at reinventing the wheel, think about your audience. If you’re the only person likely to see the project, go ahead and scratch whatever itch you’ve got. You’ll learn more that way. But if you want to share the project with as many people as possible, adhering to the most widely used standards is a good choice for your users, even if it is less fun than dreaming up your own movement language.
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
Technology moves quickly these days as consumers continue to demand more data and more pixels. We see regular updates to standards for USB and RAM continually coming down the pipeline as the quest for greater performance goes on.
HDMI 2.1 is the latest version of the popular audio-visual interface, and promises a raft of new features and greater performance than preceding versions of the standard. As it turns out, though, buying a new monitor or TV with an HDMI 2.1 logo on the box doesn’t mean you’ll get any of those new features, as discovered by TFT Central.