When companies design products a major concern seems to be what the reviewers will have to say about it. For any product of significant value the users are unable to perform any reasonable test before buying, for a casual user some problems may only be apparent after weeks of use so professional reviews are important to many people. The market apparently doesn’t want reviews of the form “here’s a list of products that are quite similar and all do the job well, you can buy any of them, it’s no big deal” which would be the most technically accurate way of doing it.

So the reviewers compare the products on the criteria that are easiest to measure, this lead to phones being compared by how light and thin they are. I think it’s often the case that users would be better served by thicker heavier phones that have larger batteries but instead they are being sold phones that have good battery life in a fresh installation but which don’t last a day with a full load of apps installed.

The latest issue with bad reviews driving poor product design is electric cars. For a while the advocates of old fashioned cars have touted the range of petrol cars which has become an issue for comparing EVs. I have been driving cars for 35 years and so far I have never driven anywhere that’s out of range of the current electric charging network, even with the range of the LEAF (which is smaller than many other EVs). If I ever felt the need to drive across the Nullarbor Plain then I could rent a car to do that and the costs of such car rental would be small compared to the money I’m saving by driving an EV and also small when compared to the premium I would have to pay for an EV with a larger range.

Some of the recent articles I’ve seen about EVs have covered vehicles with a battery range over 700Km which is greater than the legal distance a commercial driver can drive without a break. I’ve also seen articles about plans to have a small petrol or Diesel motor in an EV to recharge the battery without directly driving the wheels. A 9KW Diesel motor could provide enough electricity on average to keep the charge maintained in a LEAF battery and according to the specs of Diesel generators would take about 55Kg of fuel to provide the charge a LEAF needs to drive 1000Km. The idea of a mostly electric hybrid car that can do 1000Km on one tank of fuel is interesting as a thought experiment but doesn’t seem to have much actual use. Apparently a Chinese company is planning to release a car that can do 1400Km one one tank of fuel using such technology which is impressive but not particularly useful.

The next issue of unreasonable competition is in charge speed. Charging a car at 2KW from a regular power socket is a real limit to what you can do with a car. It’s a limit that hasn’t bothered me so far because the most driving I typically do in a week is less than one full charge, so at most I have to charge overnight twice in a week. But if I was going to drive to another city without hiring a car that has better range I’d need a fast charger. Most current models of the Nissan LEAF support charging speeds up to 50KW which means fully charging the battery in under an hour (or slightly over an hour for the long range version). If I was to drive from Melbourne to Canberra in my LEAF I’d have to charge twice which would be an annoyance at those speeds. There are a variety of EVs that can charge at 100KW and some as high as 350KW. 350KW is enough to fully charge the largest EV batteries in half an hour which seems to be as much as anyone would need. But there are apparently plans for 1MW car chargers which would theoretically be able to charge a Hummer (the EV with the largest battery) in 12 minutes. One obvious part of the solution to EV charging times is to not drive a Hummer! Another thing to note is that batteries can’t be charged at a high rate for all charge levels, this is why advertising for fast chargers makes claims like “80% charge in half an hour” which definitely doesn’t mean “100% charge in 37.5 minutes”!

There are significant engineering issues with high power applications. A 1MW cable is not just a bigger version of a regular power cable, there are additional safety issues, user training is required and cooling of the connector is probably required. That’s a lot to just get a better number in the table at the end of a review. There is research in progress on the Megawatt Charging System which is designed to charge heavy vehicles (presumably trucks and buses) at up to 3.75MW. Charging a truck at that rate is reasonable as the process of obtaining and maintaining a heavy vehicle license requires a significant amount of effort and some extra training in 3.75MW charging probably doesn’t make much difference.

A final issue with fast charging is the capacity of the grid. A few years ago I attended a lecture by an electrical engineer who works for the Victorian railway system which was very interesting. The Vic rail power setup involved about 100MW of grid connectivity with special contracts with the grid operators due to the fact that 1MW trains suddenly starting and stopping causes engineering problems that aren’t trivial to solve. They were also working on battery packs and super capacitors to deal with regenerative braking and to avoid brownouts in long sections of track. For a medium size petrol station 14 bays for fuelling cars is common. If 6 such petrol stations were replaced with fast charging stations that can charge cars at 1MW each that would draw the same power as the train network for the entire state! There is a need for significant engineering work to allow most cars to be electric no matter how it’s done, but we don’t need to make that worse just for benchmarks.

The independent security researcher Adam Gowdiak has published an extensive report on flaws he found in some eUICCs (the chips used to store eSIM profiles within the GSMA eSIM architecture). While the specific demonstrable exploit was in a product of one specific CardOS Vendor (Kigen, formerly part of ARM), the fundamental underlying issue is actually an architectural one.

The Oracle Javacard [memory] safety architecture relies on a so-called bytecode verifier which is a program that you run after compiling an application, but before executing the code on the Javacard. The specifications allow for both on-card and off-card verification. However, the computational complexity of this verifier is generally assumed to exceed the resources available inside many microcontrollers used to implement java cards. Such microcontrollers often are ARM SC000 (Cortex-M0 based) or SC300 (Cortex-M3 based) based, with only tens of kilobytes of RAM and hundreds of kilobytes of flash.

Javacard was originally developed for use cases within the banking/payment industry. In that industry, the card-issuing bank is the sold entity that has the keys to load java applets onto a card. That entity is of course interested in the security of the card, and will hence always run an off-card bytecode verifier. In a world of physical SIM/USIM cards issued by a single mobile operator, the situation is the same: The card-issuing MNO/MVNO is the only entity with key materials to install additional java applets on the card.

This fundamental problem became already apparent by earlier findings by Adam Gowdiak in 2019, but at least in terms of public responses by Oracle and Gemalto back then, they mostly did hand-waving and/or made lame excuses.

However, when the industry represented in GSMA standardized the eSIM architecture, this changes. Suddenly we have various eSIM profiles of various different operators, each holding key material to install Java applets on the shared card. In such an environment, it is no longer safe to assume that every MNO/MVNO can be trusted to be non-adverserial and hence trusted to run that off-card bytecode verifier before loading applets onto the card.

If the Javacard runtime on the existing card/chip itself cannot autonomously perform those verification tasks, I don't see how the problem can ever be solved short of completely removing/disabling Javacard support in such eUICCs. Luckily it is an optional feature and not a mandatory requirement for an eUICC to be approved/accredited. Sadly many MNOs/MVNOS however will mandate Javacard support in their eSIM profiles and hence refuse to install into an eUICC without it :(

In my opinion, the solution to the problem can only be to either make the GSMA require full on-card bytecode verification on all eUICCs, or to remove Javacard support from the eUICC.

We have to keep in mind that there are hundreds if not thousands of MVNOs around the planet, and all of them are subject to whatever local jurisdiction they operate in, and also subject to whatever government pressure (e.g from intelligence agencies).

In hindsight, anyone familiar with the 2019 work by Gowdiak and an understanding of the fundamental change to multiple stakeholders in an eUICC (compared to classic SIM/USIM) should have arrived at the conclusion that there is a serious problem that needs addressing. I think the 2019 work had not been publicized and covered significantly enough to make sure that everyone in the industry was made aware of the problems. And that in turn is mostly a result of Oracle + Gemalto downplaying the 2019 findings back in the day, rather than raising awareness within all relevant groups and bodies of the industry.

Here’s a clever hack. Simple, elegant, and eminently cost-effective: using an SMD capacitor to hold your flash media in place!

This is a hack that can pretty much be summed up with just the image at the top of the page — a carefully placed SMD capacitor soldered to a routed tab makes for an extremely cost effective locking mechanism for the nearby SD card slot. There’s just enough flexibility to easily move the capacitor when its time to insert or eject your media.

It’s worth noting that the capacitor in this example doesn’t even appear to be electrically connected to anything. But there’s also no reason you couldn’t position one of the capacitors in your existing bill of materials (BOM). This form of mechanical support will be much cheaper than special purpose clips or mounts. Not a big deal for low-volume projects, but if you’re going high-volume this is definitely something to keep in mind.

If you’re just getting started with SMD capacitors then one of the first things to learn is how to solder them. Also, if you’re hoping to salvage them then try to look for newer equipment which is more likely to have SMD components than through-hole. If you’re planning to use your capacitors for… “capacitance” (how quaint), you can start by learning the basics. And if you want to know everything you can learn about the history of capacitors, too.

Thanks to [JohnU] for writing in to let us know about this one. Have your own natty hacks? Let us know on the tipsline!

NEW PRODUCT: Adafruit Triple Matrix Bonnet for Raspberry Pi
_____________________________________________________________

You can now create large, dazzling LED matrix displays with your Raspberry Pi with the Adafruit Triple Matrix Bonnet for Raspberry Pi. This boards plugs into your Raspberry Pi with 2×20 header, and makes it super easy to control three parallel strings of HUB75 RGB matrices such as those we stock in the shop and create colorful scrolling displays or mini LED walls with ease.

Unlike our single-panel Matrix Bonnet, this board can drive 3 panels in parallel, also known as “active3” pinout. This means it can handle approximately 3x as many panels/pixels. However, as a trade-off, the power management is not done on-board. Instead you will have to provide the 5V 10A+ power separately! We recommend two power distribution bus bars, they’re good for many amps and make wiring easier.

• “Bonnet” boards work on Raspberry Pi with a 40-pin GPIO header — Zero, Zero W/WH, Model A+, B+, Pi 2, Pi 3, Pi 4, Pi 5 They do not work with older 26-pin boards like the original Model A or B. Note with the Pi Zero, you may need to solder a header on the Pi board; it’s normally unpopulated on that model. For best performance we recommend a Pi 4 or Pi 5.
• For Pi 0, 2, 3, and 4 we recommend the rpi-rgb-matrix driver, with C and Python bindings. It works great, just select the standard/active3 pinout.
• For Pi 5+, we recommend using our PIO-based matrix driver which supports up to 3 panels – check the guide for the demo code for the triple bonnet
• By default the bonnet has a slim 2×20 header on it. If you need to ‘lift’ the bonnet above an enclosure, pick up a 2×20 riser header.
• If you want to get access to GPIO while the bonnet is installed, pick up a 2×20 stacking header – the pins will slide through the socket and you can plug something else on top.

This bonnet will make your mega-matrix projects super easy and avoid wiring complexity and mistakes:

• Simple design – plug in IDC cables, provide separate power to each panel, run our Python code!
• Onboard level shifters to convert the RasPi’s 3.3V to 5.0V logic for clean and glitch free matrix driving
• Fully assembled compact design no soldering required! Plugs onto any Raspberry Pi with a 2×20 connector, and you’re ready to glow.

Works with any of our 16×32, 32×32, 32×64, or 64×64 RGB LED Matrices with HUB75 connections. When using with 64×64 you can select whether the Address E pin is on the 4’th or 8’th IDC pad with an on-board switch. Want even more lights? No problem, chain multiple matrices together for a longer display. The bigger the display the harder it is on the Pi, so keep that in mind if you’re using a lower-powered Pi Zero.

Please note: this Bonnet is only for use with HUB75 type RGB matrices. Not for use with NeoPixel, DotStar, or other ‘addressable’ LEDs.

Each order comes with a fully assembled and ready to go bonnet with all parts assembled. RGB Matrix is not included, please check out our fine selection

In stock and shipping now!

Shared by greenribbit on Thingiverse:

I wanted a way to keep my DuPont wires together and organized but wasn’t a big fan of the big clunky comb-style organizers. So I made my own!

This organizer can hold about 20 to 22 wires at a time. The wires I have are about 195mm long (excluding the plastic connectors). Fully packet, the organizer has a foot print of roughly 25mm by 125 mm.

Keep in mind I print with a 0.8mm nozzle @ 0.4mm layer height. So, this model is optimized for that configuration. It should print fine if you use a different nozzle diameter and layer height, but no guarantees!

There is a slight technique to inserting the wires into the organizer. Basically, hold the organizer in one hand, and press the wire against the slot with the thumb on that hand, while using your other hand to kind of “wind” the wire around the curve. I know, I know…trust me it is easier than it sounds and it keeps your wires nice and snug!

Download the files and learn more

Every Thursday is #3dthursday here at Adafruit! The DIY 3D printing community has passion and dedication for making solid objects from digital models. Recently, we have noticed electronics projects integrated with 3D printed enclosures, brackets, and sculptures, so each Thursday we celebrate and highlight these bold pioneers!

Have you considered building a 3D project around an Arduino or other microcontroller? How about printing a bracket to mount your Raspberry Pi to the back of your HD monitor? And don’t forget the countless LED projects that are possible when you are modeling your projects in 3D!