Circuit Break Podcast #407: Holy Static Hazard Batman!

Podcast Title: Holy Static Hazard Batman!

Release Date: December 5, 2023

Episode: #407

Parker and Stephen discuss a recent article exploring how electrostatic discharge damage isn’t the only kind of static hazard your digital designs can face, and possible solutions to such problems, a recent report that CHIPS for America published, entitled “The Vision for the National Advanced Packaging Manufacturing Program” (NAPMP), which elaborates on goals and investment areas to establish U.S. leadership in advanced packaging and provide the technology needed for packaging manufacturing in the U.S, a rumor about Raspberry Pi and how Tesla released service documentation for its original roadster, addressing some commentary by Discourse Community members, Todd_Zebert and Pdp-1, 1960s Batman stuff, and much more!

Podcast Audio:

Podcast Notes:

@Parker_Dillmann I’ve had two swings with LiFePo backed solar vehicle systems in the last year. First with dotting I’s and crossing T’s for gremlins on a 12V Victron system (with online inversion) for my father in law’s boat, and second co-designing a 48V + 12V dual DC rail system for a friends RV.

Right now, most of the RV people are using a 48V LiPo rail to top up the existing 12V infrastructure in their coaches (slides, heater blowers, jacks, etc.). They are also keeping the 12V charging of the prime mover.

My friend’s coach, and similar ones that we’ve been inspired by, use solar mppt and genset to maintain the 48V string. The 48V string then keeps the 12V system topped up, and the 12V system acts as a vampire load for maintenance of the 48V string.

Victron is presently letting my friend test the combo of their Orion 48V → 12V isolated DC-DC buck ( Orion-Tr DC-DC Converters Isolated - Victron Energy) and Orion 30A charger (12 or 24v input). They are concerned about inrush from the charger to a single Orion DC-DC buck. You can parallel the bucks, as needed.

The other side of this equation, managing split-phase shore power against an inversion system, has two parallel paths (online vs offline). It would be a novel to type, or probably a whole podcast episode.

Please let me know if the above triggers questions for your box truck.

Also, let me give a plug for Victron. Too complicated for normies to set up, but really nice integrated ecosystem. Also consistently impressed with the price point and performance. Would be my first choice with a future system of my own.


My friend’s coach is Renogy Solar and MPPT. EG4 48V batteries (0.5C rated), Magnum 48V inverters, Onan 8KW genset, Precision Circuits RV distro panel. Miscellaneous ATS, DC disconnects, fusing, monitoring, etc.

The final product has the domestic (AC only) fridge, roof AC/Heat pumps (with soft starts), and all general small 120V loads on the dual 4KW magnum inverters.

Previously the coach had 12V Magnum inverters running some AC loads and no solar. Since the 48V Magnum inverters are drop-ins WRT form/fit/function, adding a 48V string was easiest in the Magnum ecosystem.

I haven’t watched the video you guys mentioned in the podcast about mounting a turbine in from if your car. I can readily believe your conclusion, but one aspect of the explanation sounds bogus, or “boooooooogus” as Click and Clack would have said. Let’s say the turbine “consumes” ALL that 50 MPH wind and its exhaust is 0 MPH. Let’s also imagine an imaginary car whose front profile is exactly the same shape and area of the turbine (a Weinermobile?). So yeah, the turbine is eating up all the drag and the car experiences zero. BUT, the car is now pushing an extra load represented by the that drag — assuming this turbine is physically attached to the car and not self-propelled.

There could still be a drag reduction (I’m way outside my field here), but it doesn’t just cancel out. Let’s say you mounted a sleek streamlined fairing in front of your car. That would cut drag, and present almost still air to the car’s regular blunt-ish front end. But the car is physically attached to the fairing so it still has to push this reduced load. That’s trading wind drag for plain ole force, but can still be more efficient than no fairing.

But a turbine doesn’t push aside the air, it collects the air and then puts it to use spinning the blades. I’m hard pressed to see how that is going to be “sleeker” than the regular front end of a car, but maybe. But even if the turbine presents MORE wind drag than the plain car does, I can still believe there can still be a positive benefit WRT to gas mileage. Using the car’s engine + drive train to tow (push) a certain number of extra lbs in order to generate 1000W of electricity could quite conceivably be more efficient than making that same electrical power from the alternator.

One other factor in all this, from my layman’s knowledge, the drag vs air speed is very non-linear. You’d have to study such a scheme across a range of velocities to make sure it still holds true for your driving speeds of interest.

I’m glad you guys covered the static logic post. I saw that going around social media but didn’t get a chance to read it.

It turns out that on my recent Mega IIe project, I ran into a static logic issue, but I had no idea what the problem was.

This logic analyzer trace shows the issue—the Address bus (in light blue) changes from 0x0107 to 0xC002. However, there are intermediate states which I believe are from static logic. The result is the KSEL bus (3-bit) also changes states. They’re reacting to the changes in the address bus.

The trace is from a chip called the Mega-II. It’s a very-large-scale-integration of a massive amount of generic logic from the original Apple II. (It’s supposed to be an “Apple IIe on a chip.”)

When the CPU (a 6502) is changing states, occasionally, the static logic matches the decode logic for the KSEL bus, so KSEL briefly changes states.

The original computer using this chip was the Apple IIGS. Those signals were gated by another chip called Keyboard GLU. From what I can tell, it gates KSEL based on a clock.

However, in my project, I was recreating an Apple IIe, so I only had the Mega-II. I didn’t use any of the GLU chips. To decode KSEL, I used an RP2040’s PIO. However, the PIO effectively ignored the clock because I (initially) assumed KSEL was properly gated. This led to other problems. (The solution was to add a latch before the PIO to properly gate the KSEL signals.)

Long story short. I encountered a static logic issue and didn’t realize it.

@Parker_Dillmann you didn’t dream it, there was news/hints about an RP2040 successor: Eben Upton Hints at an RP2040 Successor, Promises a Raspberry Pi Compute Module 5 in 2024 -

Re: recent use of discrete logic, i still use it for example if i need a level converted complementary version of a signal, with equal propagation delay, i’ll throw in a dual xor gate in there

PS: I’m one of those that loved doing Karnaugh maps;-) Perhaps it was the conceit that it made everything look and work like ideal digital circuits without all the analog paranormal activity (“Robin, … pass me the proton pack”).

I am not totally crazy then!

Yeah I like doing them cause I was good at them in college :smiley:

Correct! Just slapping a turbine doesnt make the car sleeker but if you need to generate power, doing it with the turbine is more efficient then pulling from the alternator.

Here is the video:

Also Chris Gammel talked to the RPi HW team over at the AmpHour podcast.
I think they mentioned an update to the Pico.

#648 – The RP1 and beyond with the Raspberry Pi Hardware team | The Amp Hour Electronics Podcast

Dang, I have been trying to get someone from the RPi HW team on the podcast for a while now without success. Guess we just dont have the brand recognition :slight_smile:

Missed opportunity… You could have named it Circuit Hour instead. Or Amp Break!

With Chris Dillmann and Stephen Gammell

1 Like