BMOW title
Floppy Emu banner

Electronic Junk Mail Teardown

I recently got some very surprising junk mail that contained a full-fledged embedded computer. This was a first for me, but I wonder if there will be more to come? Of course I couldn’t resist the temptation to tear it apart and see what was inside.

The mail was something related to “The New Arconic”, which appears to be a proxy fight over control of the Arconic corporation (formerly Alcoa, the Aluminum Company of America). They want me to vote for new candidates for the board of directors – blah blah boring. But instead of sending me a persuasive letter or glossy brochure, they mailed a purpose-built video player with a 3 inch TFT screen and control buttons built into a small cardboard envelope.

Nothing happened when I pressed the power button. Dead battery? I located a micro-USB connector on the side, plugged in a charger, and waited. After a few minutes, the distinct aroma of fried electronics began to fill the air, and the cardboard was extremely hot. Doh! Of course, the only thing left to do was tear the paper apart and see what was inside.

The guts contained a TFT display module, with a piece of paper glued to the back, and a small circuit board affixed to the paper. Everything was connected by point-to-point wiring, and appeared to be hand-soldered. A 500 mAh 1.85 Wh LiPo battery powered the system. Five standard 12 mm tactile switches were taped around the edges, and a circular element in the corner I’m guessing was a piezo speaker. The only component I couldn’t identify was a tiny circuit board containing a single 3-pin chip, attached to a 1cm circular metal disk. It’s labeled Q5, and I’m guessing it’s the transistor used to enable power to the main board. [It’s actually a magnetic relay that turns on the power when you open the box cover.]

The burnt part of the circuit was clearly identifiable, in a corner of the main board near what looked like two inductors.

The main board contained three large chips: a Toshiba FV194 14399AE, a Hynix _Y5DU561622DT-J, and an unbranded E200 GC137DA. The first letter of the Hynix part number was obscured by burnt crud. I couldn’t find any info on the Toshiba chip, but based on its appearance and by process of elimination I’m guessing it’s a flash ROM containing the video file to be played. The Hynix part is DRAM of some type, though I couldn’t find an exact match on the part. The E200 is a PowerPC based system-on-a-chip. While searching for info about it, I found this Hackaday article from 2014 describing a teardown of very similar hardware. It looks like this is a standard platform for disposable electronic advertising, and the Italian company that makes them is here.

Given that they mailed me a fire hazard that needs to be specially recycled, I’m not too sympathetic to New Arconic’s advertising.

Read 9 comments and join the conversation 

Retro USB in Reverse

This Retro USB conversion stuff is getting interesting. Last week I showed off my first working prototype of USB to ADB input conversion. After another week of tinkering, I’ve now got the reverse conversion working as well. I can use my early 80’s keyboard and mouse on my 21st century Windows desktop machine! It’s awesome, in a totally useless kind of way.

As entertaining as this is, I’m not sure it makes sense to include this feature in the final Retro USB design. While it’s not conceptually difficult to do the conversion in reverse, it complicates the software and hardware for a feature that’s basically just a novelty. It means a USB-B port would be required, along with some way of switching between it and the USB-A port that’s safe and idiot-proof. It also means the ADB port would either be a source of power, or a peripheral that needs to be supplied power. It’s not a huge problem, but it’s lots of extra fiddly bits to design and include in the hardware. I’m thinking it may be better to keep things simple and focus exclusively on USB-to-ADB, which would help keep the cost down too. Or maybe I could find a way to offer ADB-to-USB as an extra option for those who really want it.

Read 4 comments and join the conversation 

The Programming Board

Behold the Floppy Emu programming board! Normally when you read “programming board” on this web site, you’d think of some circuitry on a PCB, but this time it’s a 3/4 inch thick plank of poplar wood. Ah, that kind of programming board!

Sometimes I need to reprogram a large number of Floppy Emus, and this tool makes the job much easier. My old method was to connect the Emus one at a time to an Apple IIgs, turn on the computer, push buttons to begin a firmware update, and then wait ~30 seconds for the update to finish. It was a slow and inconvenient process when dozens or hundreds of Emus needed reprogramming. With the programming board, I can slap down one Floppy Emu into a bracket, start the firmware update going, and then rotate to the next Floppy Emu. Everything is powered from a USB supply, and I use a hub with individual lighted switches to turn on power for each Emu bracket.

Updating three Floppy Emus in parallel is a big improvement, but there’s also another trick here that makes the process even better. With the old method on the IIgs, some fiddling with cables was necessary every time I connected or disconnected a Floppy Emu. Things would slide around on my desk, and I’d waste time getting the connectors lined up. The programming board uses metal pegs at each bracket to hold the Floppy Emu centered, so a short 4-inch ribbon cable can drop down perfectly aligned with the connector every time. Here’s a close-up of the alignment pegs:

If you’re wondering about those green lights on the bottom two power adapters, they’re not status indicators, but just simple power lights. I accidentally bought some high-brightness LEDs, and even with under 10 mA current they’re so bright that it’s irritating. They’re dazzling to the point of being blinding. Fortunately the LED in the top-most power adapter didn’t work due to my lousy soldering job. I covered the bottom two with 5 layers of paper, which cuts down and diffuses the brightness enough to be tolerable.

Read 2 comments and join the conversation 

Reflow Soldering Re-re-re-revisited

This was my 6th *@#&% attempt to assemble some ROM-inator II PCBs using reflow soldering, instead of my normal drag-soldering with an iron. I may not be too bright, but at least I’m persistent. All of the previous attempts failed in slightly different ways, resulting in boards with multiple solder bridges that needed to be cleaned up manually with an iron. This time I altered the way I created a frame for the board being reflowed, and it almost worked. It was certainly the best result so far, but still not good enough.

You can read about the previous reflow attempts here:

1. Reflow with hot air
2. Switched to a hot plate
3. With an aluminum pie pan
4. New solder paste and aluminum sheet
5. Using a stainless steel stencil

My reflow soldering adventures have been a challenge for two reasons:

1. The ROM-inator II PCB has two chips with 0.5mm pin spacing, which is very small. If my boards had larger components with more forgiving pin spacing, my earlier attempts would probably have gone much better. 0.5mm might be approaching the limit of what can be done at home without special equipment.

2. I need the PCB to be 100% perfect after reflow, with no manual touch-ups required to fix solder bridges. If this were a one-off prototype, a few solder bridges would be no big deal. But since my goal is to develop a new process that’s faster than hand-soldering, I can’t afford the time needed to do manual touch-ups after reflow.

 
Floating Stencils

In my previous attempt, I used purpose-made plastic framing pieces to hold the PCB while I applied solder paste with the stencil. These plastic pieces were a tiny bit thicker than the PCB, resulting in the stencil floating above the surface of the PCB instead of resting on it. The amount of float was less than 0.3 mm, but it was still enough to cause problems. This time I used extra PCBs to create a frame, so the thickness was an exact match with no float. The solder paste application looked pretty much spot-on, as you can see here:

Placement of the chips is still difficult. I’m doing it by hand with a pair of tweezers, and the best I can do is to drop the chip within a couple of millimeters of the correct position. Then I slide it around until it’s in the right spot, smearing a bit of the solder paste in the process. Here’s how things looked after chip placement:

After reflow on my hot plate, the results were pretty good, but unfortunately there were still several solder bridges. Here’s a typical example. It all looks decent, except for those two pins at the far left. The chip also didn’t snap to the correct alignment, as I’d been led to believe would happen thanks to the surface tension of liquid solder. The alignment is pretty good, but not quite centered, and there’s a bridge at pin 1:

I assembled ten boards this way, with two chips per board, and two sides to be soldered per chip, making a total of 40 sides. The good news was that 14 of the 40 sides had zero solder bridges. The bad news was that about half the sides had 2+ solder bridges, and I never assembled a PCB that didn’t have at least one solder bridge on it somewhere. This was the final score:

0 solder bridges: 14 sides
1 solder bridge: 7 sides
2 solder bridges: 7 sides
3 solder bridges: 3 sides
4+ solder bridges: 9 sides

I discovered that I needed to wipe both sides of the stencil clean after each use, otherwise the solder paste application grew progressively messier with each new PCB. I also found that I wasted a lot of solder paste. Dispensing the minimum possible amount from my syringe was still too much, and resulted in a lot of leftover paste on my plastic scraping tool. It was hard to reuse the paste stuck to the scraper. When I tried it a couple of times, using another scraper to clean off the first scraper, the results weren’t good.

 
End?

Is this the end of my reflow soldering saga? I think so, at least for this particular PCB. I don’t think I can improve further on these results without more effort than can be justified, yet the speed and quality of the process isn’t good enough to replace my current method of drag-soldering with an iron. I’ll revisit this again the next time I have a new PCB to assemble, and I’ll try to stay away from 0.5 mm pitch parts in my designs.

Read 7 comments and join the conversation 

Managing Multiple Power Supplies

I’ve been investigating ways to handle multiple supplies and consumers of +5V 500mA power in a single project, and it’s surprisingly complicated. My circuit may have up to three simultaneous external connections: a device needing +5V power at “A”, an external +5V supply at “B”, and something at “C” that might either supply +5V power or need +5V provided to it, depending on what mode the circuit is operating in. Any of these three could be present or absent, and the external +5V supplies could possibly be connected but turned off and not delivering power.

The simple solution would be to directly connect all of those +5V lines within my circuit. That would work, and maybe it’s what I’ll do, but it presents some risks of unintended current backflow into a supply. Imagine if B and C are both connected, with C configured as a supply. If one is turned off, the other would feed +5V into it. Depending on what that supply is and how it’s designed, feeding external +5V back into a device that’s turned off may cause weird behavior or damage. A similar problem could arise if a poorly-designed device on A actually powers the +5V line instead of drawing power from it, because it has batteries or an independent supply of its own.

I’m willing to handle the bidirectional nature of C with a physical switch. But I still need something that ensures current only flows in the intended direction in/out of A, B, and C, as shown in the diagram above. The ground connections aren’t shown, but they are all tied together. Current direction arrows mean diodes, right? I think diodes would theoretically work, but probably aren’t the best choice. A diode would cause a substantial voltage drop between the supply and whatever it was powering, and you need a diode that’s physically large in order to handle significant amounts of current.

A better solution might be a transistor. From studying similar circuits, a good choice might be a power MOSFET. These have a very low resistance when switched on, resulting in only a small voltage drop. A small-sized MOSFET could also handle all the 500mA current I need for this project. But I don’t have any experience working with single MOSFETs in this kind of application. I get a bit bogged down in discussions of N and P type, enhancement and depletion, high-side and low-side switching, and so forth. I’m not completely confident I’d know which specific MOSFET to select for my purpose, and how to connect it in the circuit, and what limitations or unexpected behaviors it might have.

An even better and simpler solution might be a power distribution switch IC, like the Microchip MIC2005A. This is basically a MOSFET, but one that’s designed for this specific purpose, with some extra features like soft start, current limiting, and thermal protection. And in the SOT-23 package I’d likely use, it’s not much more expensive than a generic MOSFET.

Power distribution ICs are designed to conditionally enable a power supply, and they have an /ENABLE pin to determine when to energize OUT from the supply at IN. But I would be using them always enabled, just to get the reverse current protection feature. Maybe that means this is the wrong tool for the job, and a different solution would be better?

A second question is whether a power distribution IC like the Microchip MIC2005A actually provides reverse current protection. It has terminals labeled IN and OUT, but it’s not clear if anything prevents current flowing from OUT to IN if OUT is energized by something else. I skimmed the datasheet, but couldn’t find any mention of this.

A final question is whether connecting the OUT terminals of several MIC2005A chips would cause problems. That’s what I’d need to do, if both B and C might function as +5V supplies. I can imagine this might cause a problem if one of the MIC2005A chips finds its OUT terminal at +5V even though its IN terminal is at 0. Or it might be a problem if both B and C were turned on at the same time, both delivering “5 volts”, but one was 4.9V and the other 5.1V. I didn’t see anything in the datasheet that addresses this either.

I’m trying very hard to keep the total cost of this solution low, like 50 cents or less. There are more complex power management ICs that might simplify things, but cost $2 or more apiece. Add the cost of assembly, and a retail markup sufficient to get acceptable margins, and the final sales price of the product would have to be increased by an unacceptable amount. I would probably choose to eliminate functionality instead, or just use the “connect all +5V supplies” approach, before I made a significant increase in product price just to support power management.

My diagram shows five current direction arrows, so potentially I would need five MOSFETs or MIC2005As. But I don’t actually need one on the line to the “circuit” cloud, because there’s no possibility of current flowing the wrong way. And the two arrows at C could probably be collapsed into a single arrow, if I used a DPDT switch that reversed the connections to the MOSFET or MIC2005A terminals. And I maybe don’t really need the arrow at A. If a device at A were to backflow +5V power, it would turn on the circuit, and possibly also supply power to C depending on the switch setting. That would be unexpected, but I don’t think it would harm anything. Applying all those simplifications, I might be able to get away with as few as two MOSFETs or MIC2005As, squeaking under my arbitrary $0.50 budget.

Read 21 comments and join the conversation 

RetroUSB Happy Progress

Good news from my RetroUSB project! I finally have a working proof-of-concept, connecting a modern USB keyboard and mouse to a classic 1980s Macintosh SE computer. A microcontroller and small pile of related components perform the necessary conversion between USB and ADB, acting as a USB host and translating the input events into the Apple Desktop Bus protocol used by the Macintosh. It’s still a long way from being a finished design, but the hardest part is done, and I’ve proven that this approach can work.

Reading and writing ADB bus traffic is implemented entirely in software, checking and setting I/O pin values using hard-coded delays. The USB side of the converter uses the built-in USB functionality of the PIC32MX microcontroller. In order to avoid impacting the hard-coded delays in the ADB routines, interrupts are disabled whenever listening for or responding to ADB bus commands. These periods where interrupts are disabled can last for several milliseconds, and at first they caused major problems for USB communication, which I detailed in my previous post.

With the help of a logic analyzer, I eventually determined that the problem was caused by sending USB packets too late during the USB frame, so that they weren’t finished before the end of the frame. This was a side-effect of re-enabling interrupts midway through a USB frame, causing the PIC to start sending packets even though the 1 millisecond USB frame was almost over. Fortunately the PIC has a USB setting to handle this: U1SOF, the start-of-frame threshold. If the number of bit times remaining in the current USB frame is less than U1SOF, no new USB tokens will be started until after the next SOF has been transmitted. Through experimentation, I found that doubling or tripling the default U1SOF value eliminated the USB errors I was experiencing. Here’s a figure from the datasheet:

So the basic functions of a USB to ADB converter are now working, as you can see in the video. I can simulate multiple ADB keyboards and mice, complete with ADB collision detection and address remapping. And I can read up to eight USB keyboards and mice at the same time, directly connected or through a USB hub. I can also log traffic and statistics over the serial port for debugging. Now there are a million smaller details to address:

Brownouts. The ADB bus directly powers the whole collection of hardware, including the USB hub, keyboard, and mouse. It draws about 120 mA from the Macintosh SE, which is well within the 500 mA spec. Yet I measured the 5V line drooping as low as 4.3V, and the 3.3V supply for the PIC drooping as low as 2.6V. Sometimes the PIC’s supply voltage gets low enough to trigger a brownout reset. I’m not sure what’s going on here. Maybe my breadboard wires and hand-soldered ADB connector have a few ohms of resistance, causing a voltage drop.

Mouse Sensitivity. Initially the USB mouse was super sensitive, and only a tiny movement was needed to send the Mac’s mouse pointer all the way across the screen. I’m now dividing the mouse movement vectors by 4, but that makes motion less smooth.

Mouse Axis Mapping. An Amazon Basics brand optical mouse works fine, but a Dynex brand mouse appears to have its movement axes mapped weirdly. X and Y axis movements are combined and reported on the wheel axis, while wheel movements are reported on the X axis. This must be a software bug in the HID report parser.

Keypress Handling. I’m not truly handling USB keypresses properly, because a single USB key event is being translated into two separate down and up events for ADB. At present, it won’t correctly recognize when you press and hold a key.

Double Keypresses. Sometimes when I press a key once, it will be reported twice. Probably due to the dodgy keypress handling.

Power Button. Real ADB keyboards have a power button used to turn on the computer. This is a physical switch that completes a circuit between a dedicated ADB pin and ground. I’ll have to add a hardware button to my breadboard somewhere to act as the power switch.

Read 12 comments and join the conversation 

« Newer PostsOlder Posts »