Here’s a test rig for the ADB-USB Wombat board: my first-ever project whose sole purpose is to facilitate testing of another project. It uses spring-loaded pogo pins to create a bed of nails that fit into test points on the Wombat board. I can drop a new Wombat board onto the tester, clamp it in, and then program and test it with just a few button clicks. This is a huge improvement over my old manual testing method, which involved multiple cable connections and disconnections, and hand-verified keyboard/mouse emulation on two separate computers. That sort of test process is fine for building a few units, but something faster and easier is needed to support higher volume assembly.

Pogo pins contain tiny internal springs. When a Wombat board is pushed down onto the bed of pins, they compress a few millimeters in length. This helps to create a reliable electrical contact for each pin, even if the uncompressed lengths of the pogo pins are slightly different or they’re not perfectly aligned.

The tester has on-board ICs to open and close external loopbacks for the Wombat, so the I/O functions can be verified. It also has a power management IC that can supply the Wombat through two different interfaces, ensuring they both work. But the real value of the tester is that the power cable, PIC programmer, serial cable, ADB peripherals, and USB peripherals can all be permanently connected to the test board instead of plugged/unplugged from the Wombat for each test iteration.

Perfecting the tester took much longer than I’d expected, and it wasn’t until the third generation that it worked reliably enough to be useful. Given the size of that time investment, it’s unclear if I really achieved a net time savings, but I definitely learned a lot. Getting the mechanical aspects working smoothly was a challenge. Thinking about all the ways a Wombat could be broken was also a challenge, since I’m typically thinking about how things work instead of how they don’t work. With those possible failure modes in mind, I then needed to design circuitry to detect each failures.

If the test passes, the Wombat’s LEDs blink with a pulsing glow as shown in the video. If the test fails, the LEDs flash a variable number of times to indicate a two digit failure code. This code can be looked up on a reference sheet to see which sub-test failed, and which components are probably at fault.

Be the first to comment! 

Here’s a custom laser-cut case for the Macintosh LC family, Performa 400 series, and Quadra 605. By removing the internal floppy drive and fan, and replacing the internal SCSI drive with a SCSI2SD board, I was able to make a design that’s about half the size of a standard LC case. The pieces fit together loosely with tabs and slots, and then screws and nuts in T-slots provide extra support to make everything nice and solid. The finished case isn’t much bigger than my keyboard, which is neat. Here it is outfit with a Floppy Emu and an ADB-USB Wombat:

The logic board is screwed into the base piece, and the PSU is strapped down with zip ties. The case is a simple six-sided box, with the addition of a seventh interior piece that I call “the shelf.” This piece separates the rightmost interior region into lower and upper sections. The lower section houses any PDS plug-in card, and the SCSI2SD rests on top of the shelf in the upper section. Because of the way the SCSI cables are oriented, the SCSI2SD is mounted upside-down.

Here are the parts before assembly:

And the final product is shown at the top of this post. It’s an obnoxious shade of orange with a clear top. Who wants beige, anyway?

The speaker is taped to the inside of the case to prevent it from moving around, which is ugly. There’s not enough space for it to lie flat, so it’s propped up at a strange angle. I’ll hunt around for a smaller 16 ohm speaker to use in its place.

There’s a slot in the front where I’ve run a floppy ribbon cable, so I can hook up a Floppy Emu when needed.

The space above and below the shelf is very cramped, and I probably should have made it larger. Initially I couldn’t get my PDS ethernet card to fit, but after shaving a few millimeters by removing the metal shield from around the ethernet jack, it just barely squeezes in. The SCSI2SD was also a very tight fit. Using a SCSI cable with integrated strain relief, it wouldn’t fit, and I had to substitute a different SCSI cable without strain relief that’s a couple of mm thinner.

The case opening for the PDS card is fine, but without the metal shield, there’s a gap around the ethernet jack. Bonus ventilation! Here’s a photo of that, along with the right side vents:

With no fan I thought the computer might overheat, so I was prepared to take some temperature measurements. Stuffed with the guts of a Performa 475, I used an IR thermometer to take some readings at different spots inside the case, and I couldn’t find anything warmer than 112 F / 44 C. I was ready to mount a tiny fan inside, but that doesn’t look necessary now since the passive cooling is adequate.

If anybody wants to build their own, or use this as a starting point for further experiments, take these files. There are two files: one for the bottom and sides, and one for the top and shelf, so you can have the two different sheets made in different colors. Upload the files to ponoko.com, and have each one cut on a P2 sized 3mm thick acrylic of your color choice. You can also use 3mm MDF wood if you want a different look. Along with the case pieces, you’ll need 11 M3x10mm screws with matching nuts. #4-40 size screws probably fit too, but I haven’t tried it. You’ll also want some plastic zip ties to strap down the power supply.

A few things I’d do differently, if I were going to do this again:

• Add about 3mm to the height under the shelf, to fit thicker PDS cards
• Add about 3mm to the height above the shelf, to fit thicker SCSI cables
• Integrate small feet into the side pieces, to elevate the case for better underside airflow
• Have fewer vents around the PSU, and more vents around the CPU and PDS card
• Cut the vent slots into the shape of an Apple logo
• Reposition the floppy cable slot, so it’s better aligned with the logic board’s floppy connector
• Add an opening for a power LED so I can tell when it’s on

Now back to playing with my little orange monster…

Read 5 comments and join the conversation 

The ESP8266 has exploded in popularity since its introduction a few years ago. With easy to use Arduino-compatible modules like the Wemos D1 Mini, it’s like having an Arduino that’s 5-10x faster, has 128x more memory, and has built-in WiFi, all for the ridiculously cheap price of $4. It’s pretty amazing stuff, really.

Like everyone else, I began my ESP8266 adventures with a temperature logging application. Using the D1 Mini, an OLED display shield, and an SHT30 temperature/humidity sensor shield, I was able to create a working temperature monitor in about 15 minutes. It shows the current temperature and humidity on the display, and also runs a basic web server for remote viewing of the data. The only hiccup was the heat generated by the ESP8266, which was enough to raise the temperature about 10 degrees F above ambient temperature when the SHT30 shield was plugged directly into the D1 Mini base. Separating the modules with hookup wires solved that problem. The result was something like this:

 
Logging and Displaying IoT Data

That’s great for a few minutes of work, but how can I make a single page that shows data from many sensors? Or historical data showing the temperature trend over the past 24 hours? Or a more attractive visualization UI than plain text? Or bidirectional control – the ability to switch some equipment at the sensor on/off? This is the realm of IoT data logging and display dashboard solutions, and there are many options.

One approach is to run a local server to do the job, like a Raspberry Pi or an old PC. There are lots of options for software packages you can install on the server, which will log the data and serve up nice-looking pages to visualize it. I didn’t explore this route, because I was too lazy. I also dislike the idea of connecting to a random 192.168.1.8 server address that changes every time my home network reassigns the address through DHCP. I’m sure there’s a way to give it a fixed address and name like “weather-info.local”, but I didn’t look into it.

There exist a dizzying number of cloud-based logging and visualization solutions. My ideal solution would would have a nice-looking historical graph of the data, with an adjustable time scale, like the example below from Weather Underground. And of course it would be easy to integrate into my ESP8266 software, and cheap or free to use.

I’ve yet to find any solution that I love. Here’s a quick run-down of the cloud-based options that I investigated.

 
Dweet.io and Freeboard.io

Dweet.io is the data logging service, and Freeboard.io is the dashboard display service. Judging from how frequently they’re mentioned in tutorials and instructables, they’re quite popular. You can also install Freeboard on a local server if you prefer. This setup is for data visualization only, and doesn’t allow for control over the sensor device.

The combination of Dweet plus Freeboard is easy to use, and it looks nice. It would be a great solution except for one shortcoming: there’s no real support for historical data. Freeboard can display sparklines, which are a sort of mini-chart where nothing is labeled and the history is retained in the chart widget itself. Close the web page and re-open it, and your history is gone.

There is an option for a Historical Graph Widget in Freeboard, but it requires upgrading to a paid Dweet Pro account for data storage. That’s only $2/month, but as far as I can tell it means you need to pay before you can try out the historical graph to see if it’s any good. From the screenshots I’ve seen of it, the time axis isn’t labeled and the time scale can’t be modified. It also appears designed to graph a fixed range of historical data, like June 10, rather than a window like past 24 hours.

Freeboard can be extended with plugins, and there are several attractive graphing plugins available. However, all of them appear to function like the sparkline, with the history retained in the graph widget instead of coming from the data source. There may be a solution to do what I need with Freeboard, but I couldn’t find it.

 
Blynk

Blynk combines the data logging and dashboard display into a single service. It also provides support for control over devices, in addition to displaying data received from them. Along with Freeboard, it seems to be one of the most popular IoT visualization solutions. It’s easy to use, and attractive.

My biggest complaint about Blynk is that visualization and control is accomplished entirely through mobile apps. There is no facility for viewing your data in a web page – everything happens on your phone or tablet. For some people that might be fine, but I strongly prefer a regular computer with a larger screen and easier control over a complex UI.

The Blynk historical graph widget does almost exactly what I want, with an adjustable timescale showing anywhere from the past 1 hour to past 3 months. But the graph is tiny, and can’t be zoomed or enlarged. It also lacks a cursor feature to display the exact value from some time in the past – you have to eyeball the graph and estimate it. When the whole point of the temperature logger dashboard is to dig into the historical data, it’s disappointing.

Blynk uses an “energy” metaphor that I find to be confusing and silly. Each type of widget added to your dashboard requires a different amount of energy, which must be paid for with an in-app purchase. I would prefer a more straightforward monthly subscription model, with the cost based on things like the number of dashboards and amount of data stored. Charging 2x the energy for a data field display with units vs one without units has no correlation to the developer’s actual costs, and makes me feel like I’m playing Farmville.

 
Adafruit.IO

Adafruit.IO is technically still in beta, although it’s open to everyone and has been around for a couple of years. Like Blynk it combines data logging and display, and provides support for both data display and device control. But like Freeboard it’s web-based rather than mobile. Could this be the perfect solution?

From my limited testing it looks promising. The historical graph widget works as expected, and my only gripe is that the time scale must be chosen when the graph is created, so you can make a “past 60 minutes” graph or a “past 24 hours” graph, but not a single graph with an adjustable time scale.

I’m uncertain what the future holds for Adafruit.IO, or whether it’s still being actively developed and maintained. Since the service is completely free, and has been in beta for over two years, it has the feel of a project that was created with great enthusiasm but was left to languish when the developers moved on to something new. Assuming it doesn’t unexpectedly break or get shut down, it looks like a nice solution.

 
Cayenne

Cayenne is another web-based logger and dashboard like Adafruit.IO. It was recommended in a recent Sparkfun blog post, but I couldn’t find many examples of people using it. Unlike the other services I’ve mentioned, Cayenne appears to be an “app builder” whose goal is to avoid needing to write any code. Instead you use a web GUI to define what type of microcontroller you’re using, what kinds of sensors, and how they’re connected, and then it spits out a complete sketch you can paste into the Arduino IDE. You can probably guess that I’m not too enthusiastic about this approach. Under the hood, the auto-generated code appears to use something very similar to the Blynk API for communicating with the Cayenne server.

I stopped short after reading some Cayenne docs and videos, and never actually tried to integrate it. Maybe I should give it another try, as screenshots of its graphing functions look quite nice. If I can ignore the app builder and auto-generated code, and just use it as a normal API, it might be OK.

 
A few other alternatives I looked at only very briefly:

Thingspeak – Somehow related to MATLAB, and geared towards doing extensive analysis of the collected data. Might be OK? Most of the references I found were several years old, and I have the impression it’s been eclipsed by some of the newer alternatives.

Emoncms – Looks somewhat promising, but I think it’s only for local server installs and doesn’t have a cloud service.

Losant – Appears geared towards large scale businesses, not makers and home temperature loggers.

Easy IOT – Didn’t make a great first impression – many typos in documentation, complicated setup compared to the other options.

Analog.io – Minimal information on the web page, links to a Hackaday project that hasn’t been updated in a couple of years.

Have you ever used these tools or others like them? I’d love to hear from you – leave a note in the comments.

Read 10 comments and join the conversation 

Poor Apple, they never did get on board with having more than a single mouse button. That complicates ADB/USB conversion for USB Wombat. When converting USB to ADB, how should it handle the extra buttons on a USB mouse? What about the mouse wheel? And when converting ADB to USB, how can it generate Windows right-click events from an ADB mouse?

With firmware 0.2.0, I’ve added multi-button mouse support. Here’s how it works:

USB mouse wheel movements send up/down arrow events to the host. This works remarkably well for open file dialogs and document scrolling.

The USB mouse right button can operate in one of two modes:

1. Macintosh mode (default): right click sends control + left click event to the host. Works for context menus in Mac OS 8 and later.
2. NeXT mode: right click sends a true right click event to the host.

Toggle between Macintosh and NeXT modes by clicking the USB mouse wheel button (button 3).

For ADB-to-USB conversion with firmware 0.2.0, ADB mice and trackballs with more than one button can now use the extra buttons under Windows, OSX, or Linux. Generic multi-button ADB devices using extended Apple mouse protocol should work. I’ve also added vendor specific support for the 4-button Kensington Turbo Mouse 5 model 64210. Other multi-button devices using proprietary protocols may not work. If you’ve got some multi-button ADB mice from MacAlly, Kensington, Logitech, MicoSpeed, Mouse Systems, or others, please give them a try with firmware 0.2.0 and share your results.

Read 3 comments and join the conversation 

Yesterday’s post mentioned some hypothetical marsupial-themed hardware: WiFi Wallaby, Video Platypus, and others. While these were meant as a joke, they got me thinking about what exactly a “Video Platypus” and friends might do, and I’m outlining some possibilities below. These are all tied loosely into vintage Macintosh hardware, although other ideas of interest to the general Arduino/RPi audience would be nice too.

 
Video Platypus

This might be a way of providing video out for compact Macs like the Plus and SE. I’ve discussed a few potential methods for doing this before. One approach is to directly tap the CRT video and synchronization signals and resample/convert them to a standard format. Another possibility is sniffing the address and data bus to watch for CPU writes to the framebuffer region of main memory, then use that to construct a new video signal.

Video Platypus could also be a converter or upscaler for the Mac II series and later machines. VGA adapters for these machines are inexpensive and easy to find, but VGA itself is a slowly dying standard. It would be nice if I could get a direct HDMI or DVI-D output from my 680X0 or PowerMac. Probably this wouldn’t need to be Mac-specific – it would just be a VGA to HDMI converter with a different physical connector to support the Mac. Something like this must surely exist already?

 
Disk Kangaroo

An external fileserver would be nice for old Macintosh computers: a device you plug into the computer and that appears as a large local or remote disk. Floppy Emu already serves this purpose when it’s configured in HD20 hard disk mode, but only a small number of Macintosh models support HD20 and have the necessary external floppy connector.

Disk Kangaroo could be something like a Floppy Emu for LocalTalk. Just plug it into the Mac’s LocalTalk port (the printer port), and it would appear as a fileserver. You wouldn’t be able to boot from it the way you can from Floppy Emu, but it would work on virtually every Mac model and system software version. The I/O speed would be about the same as Floppy Emu, I think.

The same idea could be applied to a SCSI disk instead, so the device would appear as a local disk and the computer could boot from it. This would be similar to SCSI2SD, except instead of formatting the whole SD card as a Macintosh disk, the SD card would contain a library of disk images to choose from, just like Floppy Emu. This would make it easier to set up and use for file transfers to and from an internet-connected PC.

Both the SCSI and LocalTalk disks could also use remote storage instead of an SD card. The files could be served from a PC on the same LAN, which would might require some special software on the PC, or the device could potentially do Appletalk-to-Samba translation. Or files could be served directly from a cloud storage account like DropBox.

 
WiFi Wallaby

Everybody loves the ESP8266 for connecting oddball things to WiFi. What might this do for a vintage computer? Most old Macs are capable of Ethernet networking, although many require an add-in networking card that’s now rare. I’m not sure if it’s easy or even possible to go from that to a wireless network connection.

What might you use this wireless connection for – general web surfing, email, and FTP? Or for connecting to other vintage Apple computers and printers wirelessly with Appletalk?

Maybe this could be like a WiFi version of Farallon PhoneNet. Connect a WiFi Wallaby to each of your computers and printers and they’ll auto-connect and form an Appletalk network. Same idea as the phone cables in PhoneNet, but wireless.

 
Printer Koala

A clever microcontroller board with the necessary physical connector could emulate an Imagewriter II or other 80’s – 90’s Apple printer. What would be the point of that? Maybe it could act as a print server or translator, enabling the old Macs to use modern printers. The need for printer drivers could make that difficult, though. Or maybe “printing” could perform another function like converting the document to PDF and storing it on an SD card or on a cloud-based server. Or it might implement a print-to-Facebook or print-to-Twitter feature.

Working in the opposite direction could be interesting too: a device that connects to an Imagewriter II or Stylewriter or LaserWriter. The device could put these classic printers on a network so that modern computers could print to them from Windows, OSX, or Linux. There would be a question of printer drivers again, but for relatively simple printers like the Imagewriter that might be doable.

Read 8 comments and join the conversation