NEMA Releases Standard For Vehicle-to-Grid Applications

Vehicle-to-grid (V2G) has been hailed as one of the greatest advantages of electrifying transportation, but has so far remained mostly in the lab. Hoping to move things forward, the National Electrical Manufacturers Association (NEMA) has released the Electric Vehicle Supply Equipment (EVSE) Power Export Permitting Standard.

The new standards will allow vehicle manufacturers and charger (EVSE) suppliers to have a unified blueprint for sending power back and forth to the grid or the home, which has been a bit of a stumbling block so far toward adoption of a seemingly simple, but not easy, technology. As renewables make up a larger percentage of the grid, using the increasing number of EVs on the road as battery backup is a convenient solution.

While the standard will simplify the technology side of bidirectional charging, getting vehicle owners to opt into backing up the grid will depend on utilities and regulators developing attractive remuneration plans. Unfortunately, the standard itself is paywalled, but NEMA says the standard “could put money back in electric vehicle owners’ pockets by making it easier for cars to store energy at night or when turned off and then sell power back to grids at a profit during peak hours.”

We’ve covered some of the challenges and opportunities of V2G systems in the past and if you want something a little smaller scale, how about using a battery that was once in a vehicle to backup your own home?

Cyanotype Prints On A Resin 3D Printer

Not that it’s the kind of thing that pops into your head often, but if you ever do think of a cyanotype print, it probably doesn’t conjure up thoughts of modern technology. For good reason — the monochromatic technique was introduced in the 1840s, and was always something of a niche technology compared to more traditional photographic methods.

The original method is simple enough: put an object or negative between the sun and a UV-sensitive medium, and the exposed areas will turn blue and produce a print. This modernized concept created by [Gabe] works the same way, except both the sun and the negative have been replaced by a lightly modified resin 3D printer.

A good chunk of the effort here is in the software, as [Gabe] had to write some code that would take an image and turn it into something the printer would understand. His proof of concept was a clever bit of Python code that produced an OpenSCAD script, which ultimately converted each grayscale picture to a rectangular “pixel” of variable height. The resulting STL files could be run through the slicer to produce the necessary files to load into the printer. This was eventually replaced with a new Python script capable of converting images to native printer files through UVtools.

On the hardware side, all [Gabe] had to do was remove the vat that would usually hold the resin, and replace that with a wooden lid to both hold the UV-sensitized paper in place and protect the user’s eyes. [Gabe] says there’s still some room for improvement, but you wouldn’t know it by looking at some of the gorgeous prints he’s produced already.

No word yet on whether or not future versions of the project will support direct-to-potato imaging.

DataSaab mainframe

DataSaab: Sweden’s Lesser-Known History In Computing

Did you know that the land of flat-pack furniture and Saab automobiles played a serious role in the development of minicomputers, the forerunners of our home computers? If not, read on for a bit of history. You can also go ahead and watch the video below, which tells it all with a ton of dug up visuals.

Sweden’s early computer development was marked by significant milestones, beginning with the relay-based Binär Aritmetisk Relä-Kalkylator (BARK) in 1950, followed by the vacuum tube-based Binär Elektronisk SekvensKalkylator (BESK) in 1953. These projects were spearheaded by the Swedish Board for Computing Machinery (Matematikmaskinnämnden), established in 1948 to advance the nation’s computing capabilities.

In 1954, Saab ventured into computing by obtaining a license to replicate BESK, resulting in the creation of Saab’s räkneautomat (SARA). This initiative aimed to support complex calculations for the Saab 37 Viggen jet fighter. Building on this foundation, Saab’s computer division, later known as Datasaab, developed the D2 in 1960 – a transistorized prototype intended for aircraft navigation. The D2’s success led to the CK37 navigational computer, which was integrated into the Viggen aircraft in 1971.

Datasaab also expanded into the commercial sector with the D21 in 1962, producing approximately 30 units for various international clients. Subsequent models, including the D22, D220, D23, D5, D15, and D16, were developed to meet diverse computing needs. In 1971, Datasaab’s technologies merged with Standard Radio & Telefon AB (SRT) to form Stansaab AS, focusing on real-time data systems for commercial and aviation applications. This entity eventually evolved into Datasaab AB in 1978, which was later acquired by Ericsson in 1981, becoming part of Ericsson Information Systems.

Parallel to these developments, Åtvidabergs Industrier AB (later Facit) produced the FACIT EDB in 1957, based on BESK’s design. This marked Sweden’s first fully domestically produced computer, with improvements such as expanded magnetic-core memory and advanced magnetic tape storage. The FACIT EDB was utilized for various applications, including meteorological calculations and other scientific computations. For a short time, Saab even partnered with the American Unisys called Saab-Univac – a well-known name in computer history.

These pioneering efforts by Swedish organizations laid the groundwork for the country’s advancements in computing technology, influencing both military and commercial sectors. The video below has lots and lots more to unpack and goes into greater detail on collaborations and (missed) deals with great names in history.

Continue reading “DataSaab: Sweden’s Lesser-Known History In Computing”

Demonstration of the multichannel design feature, being able to put identical blocks into your design, only route one of them, and have all the other blocks' routing be duplicated

KiCad 9 Moves Up In The Pro League

Do you do PCB design for a living? Has KiCad been just a tiny bit insufficient for your lightning-fast board routing demands? We’ve just been graced with the KiCad 9 release (blog post, there’s a FOSDEM talk too), and it brings features of the rank you expect from a professional-level monthly-subscription PCB design suite.

Of course, KiCad 9 has delivered a ton of polish and features for all sorts of PCB design, so everyone will have some fun new additions to work with – but if you live and breathe PCB track routing, this release is especially for you.

Continue reading “KiCad 9 Moves Up In The Pro League”

A Web-Based Graphics Editor For Tiny Screens

These days, adding a little LCD or OLED to your project is so cheap and easy that you can do it on a whim. Even if your original idea didn’t call for a display, if you’ve got I2C and a couple bucks burning a hole in your pocket, why not add one? Surely you’ll figure out what to show on it as the project develops.

But that’s where it can get a little tricky — in terms of hardware, adding a screen just takes running a few extra wires, but the software side is another story. Not only do you have to contend with the different display libraries, but just creating the image assets to display on the screen can be a hassle if it’s not something you do regularly. Enter Lopaka, a graphics and user interface editor for electronic projects created by [Mikhail Ilin].

Continue reading “A Web-Based Graphics Editor For Tiny Screens”

Multitasker Or Many Monotaskers?

In Al Williams’s marvelous rant he points out a number of the problems with speaking to computers. Obvious problems with voice control include things like multiple people talking over each other, discerning commands from background conversations, and so on. Somehow, unlike on the bridge in Star Trek, where the computer seems to understand everyone just fine, Al sometimes can’t even get the darn thing to play his going-to-sleep playlist, which should be well within the device’s capabilities.

In the comments, [rclark] suggests making a single button that plays his playlist, no voice interaction required, and we have to admit that it’s a great solution to this one particular problem. Heck, the “bedtime button” would make fun project in and of itself, and it’s such a limited scope that it could probably only be an weekend’s work for anyone who has touched the internals of their home automation system, like Al certainly has. We love the simplicity of the idea.

But it ignores the biggest potential benefit of a voice control system: that it’s a one-size-fits-all solution for everything. Imagine how many other use cases Al would need to make a single button device for, and how many coin cell batteries he’d be signing himself up to change out over the course of the year. The trade-off is that the general purpose solution tends not to be as robust as a single-tasker like the button, but also that it can potentially simplify the overall system.

I suffer this in my own home. It’s much more a loosely-coupled web of individual hacks than an overall system, and that has pros and cons. Each individual part is easier to maintain and hack on, but the overall system is less coordinated than it could be. If we change the WiFi password on the home automation router, for instance, I’m going to have to individually log into about eight ESP8266s and change their credentials. Yuck!

It’s probably a matter of preference, but I’ll still take the loose, MQTT-based system that I’ve got now over an all-in-one. Like [rclark], I value individual device simplicity and reliability above the overall system’s simplicity, but because our stereo isn’t even hooked up to the network, I can’t play myself to sleep like Al can. Or at least like he can when the voice recognition is working.

The Perfect Pi Pico Portable Computer

[Abe] wanted the perfect portable computer. He has a DevTerm, but it didn’t quite fit his needs. This is Hackaday after all, so he loaded up his favorite CAD software and started designing. The obvious choice here would be a Raspberry Pi. But [Abe] didn’t want to drop in a Linux computer — he was going for something a bit smaller.

An RP2040 Pico would be a perfect fit. Driving a display with the Pico can be eat a lot of resources though. The solution was a PicoVision from Pimoroni. PicoVision uses two RP2040 chips. One drives an HDMI port, while the other is free to run application software. This meant a standard HDMI screen could be used.

The keyboard was a bit harder. After a lot of searching, [Abe] found an IR remote designed for smart TVs. The QWERTY keyboard was the perfect size but didn’t have an interface he could use. He fixed that with an adapter PCB including an I2C GPIO expander chip. A bit of I2C driver software later, and he had a working input keyboard.

Hardware doesn’t do anything without software though. The software running on the handheld is called Slime OS, and the source is available at [Abe’s] GitHub. It’s a launcher, with support for applications written in python. [Abe] has a few basic demos working, but he’s looking for help to get more features up and running.

Although it wasn’t quite what [Abe] was after, our own [Donald Papp] came away fairly impressed when he gave the DevTerm a test drive back in 2022. Something to consider if you’re looking for a Linux handheld and not quite ready to build one yourself.

Continue reading “The Perfect Pi Pico Portable Computer”