Found at Goodwill: WebPad 1001 Prototype

I found this strange looking device at Goodwill yesterday. Originally, owing perhaps to the bright blue color, I thought it was some sort of educational or kids device. It had no branding on it, so overall, something of a mystery. At first, it didn’t even have the button membranes installed, just exposed raw button switches, more on that shortly.

What really caught my eye, and definitely made the sale, was the clear prototype labeling on the back. So, all of $6 later, I was headed home with a project. “Not for sale” be damned.

It didn’t come with a power adapter or even any kind of labeling about what it needed, so I had an immediate problem there. A standard barrel plug socket was apparent on the side, but the polarity and voltage would need to be determined. It would be a shame to release the “magic smoke” on this mystery device with some sloppy experimentation, so I wanted to tread lightly. I also still had no real idea what I was dealing with, so some disassembly was in order.

Getting it apart was very simple. The metallic blue cover on the bottom of the back was held on by two standard Phillips screws, and the rest of the chassis was held by seven of the same screws. It certainly seems like someone was interested in simplicity here. Notably, I found those silicone button membrane pieces under that metallic ‘battery cover’, and promptly installed them.

Another note about this battery compartment, that strange looking jack on the back appeared to have been hacked in for an external power source. It’s wired directly to what I’d assume is the battery connector.

Slightly inconveniently, the main chassis screws only freed the front fascia, so some further disassembly was necessary to acess the interesting bits. Eventually, I got to the main logic board.

Immediately apparent is the Cyrix x86 processor and chipset. These are flanked by an empty RAM socket, an empty PCMCIA slot, and a third unique type of slot that I didn’t recognize at first but was filled.

That turned out to be a solid-state DiskOnChip DIMM. Looks like this one is 32mb.

Some simple work with a multimeter confirmed that the power socket was center-positive. A datasheet of a power regulator chip found on the board suggested an input voltage range of 4-14V. With this, I was comfortable enough to start experimenting with an actual power source.

It’s alive! 9V seems to do the trick. It relatively quickly booted into a very spartan Linux installation, featuring only a software keyboard and the Netscape web browser. There isn’t much more to poke around at than that at the moment, despite my attempts. No networking hardware is currently installed. I would take an educated guess that the PCMCIA slot was intended for an early Wi-Fi network card.

This is backed up by some stuff I found on the internet while googling various permutations of Cyrix, National Semiconductor, and WebPad. Looks like the WebPad was a reference design developed by Cyrix for a late-90s era wireless internet appliance. If you’ll forgive the simplification, this was the first iPad in an era where people didn’t even know that internet could be wireless.

TV Show including a segment about the WebPad prototype: https://archive.org/details/CC1634COMDEX

So, that’s what I have so far. I’ll continue to explore what I can do with this device, and maybe I’ll have an update with more at some point.

Thanks for reading! If you’ve got any information or ideas about this device, don’t hesitate to reach out.

Setting up a Raspberry Pi for Swifty IoT

I recently gave a talk on implementing an Internet of Things bridge in Swift using a Raspberry Pi. If you’re interested in following in my footsteps, here’s a quick abridged guide on how to set up your Pi. Many smart people have done the heavy lifting here, I’ve just put the building blocks together. Where appropriate, steps link out to these external tutorials with more information.

Prerequisites:

  • Raspberry Pi 3
  • 8GB+ SD Card
  • HDMI Display
  • USB Keyboard and Mouse
  • A way to connect your Pi to the internet (WiFi or Ethernet)

1. Install Ubuntu

The best distribution of Linux for running Swift on Pi is Ubuntu Mate. Version 16.04 is recommended for compatibility with Swift. You can find instructions for installing it on your Pi here.

2. Install Swift

Swift is open-source and supports Linux as a platform for running the compiler. Getting the whole thing standing up on a Pi is a bit complicated, but luckily Umberto Raimondi has provided an amazing service by hosting precompiled Swift binaries for the Raspberry Pi 3. Instructions for installing those are available here.

3. Start a Vapor project

I found that the easiest way to get a Vapor project started is to just clone a simple sample project and build off it. Here’s a good starting point, git clone this to a directory on your Pi.

4. Add Dependencies

My project used additional libraries, SwiftyGPIO and vapor-apns. To install these, add the following dependencies to the Package.swift file:

        .Package(url: "https://github.com/uraimo/SwiftyGPIO.git", majorVersion: 0),
        .Package(url: "https://github.com/matthijs2704/vapor-apns.git", majorVersion: 2)

Then, run a swift package install

5. (BONUS!) Install Dataplicity

If you want to access your Pi from outside your network, Dataplicity hosts a remote access service designed for Raspberry Pi, and it’s currently free for one device! I can’t recommend them enough, they even provide an externally resolvable hostname for your Pi to use, so you can connect to it from the internet. Here are instructions for setting up Dataplicity

The End!

That should be it! You should now have everything you need to do cool, Swifty IoT things with your Raspberry Pi!

If you have any questions or concerns, feel free to reach out on Twitter: @huebnerob

Scheduling courses in MATLAB.

Screen Shot 2013-09-08 at 2.53.57 PM

First up, a little background about me: I studied computer science at NYU for three years, then I transferred to Stevens to pursue mechanical engineering for another two. It’s all part of a dual-degree program between both schools that essentially allowed NYU to appeal to engineers while having no engineering department or school whatsoever (at least back when I entered). Suffice it to say Stevens filled the gear-shaped hole in NYU’s heart, until NYU went and bought a little place in Brooklyn *cough*NYUPoly*. Either way, I enjoyed the benefits of both schools, both the breadth of a city university and the closeness of a college campus in Hoboken. If for nothing else, it was often an interesting contrast.

Scheduling is hard.

At NYU, class sections tended to follow patterns in their scheduling. They would meet either Monday/Wednesday or Tuesday/Thursday, for the same 75 minute time period each day. Recitations and labs could meet later in the day, or on Friday, and there were plenty of choices for all. My transfer to Stevens was what taught me that I had been taking this sanity for granted; schedule chaos reigned supreme across the Hudson river in Hoboken, and for reasons still unclear…

More

It’s in the Data: TRANSient Beta.

transient banner

My text editor doesn’t spoil many secrets, its title bar simply glows “stop_times.txt – nycsubway”. Below that, lines of gibberish seem to cascade downward endlessly, patterns coyly exposing themselves in streaks of data as I scroll down violently. In one file hides every single stop, made by every single train, running along every single route of the MTA New York City Subway. There are a few other files in the folder that can help describe some nuances, but stop_times.txt reigns supreme in its overwhelming size. One text file that *is* the entire Subway. At last count, it’s 522,670 lines long. I could spend my entire summer just scrolling that far, surely rubbing the pads of my fingers down to the bone in the process, but my plans are slightly more ambitious, slightly less crazy.

More

ADAPTiD

Image

Aesthetic Design Algorithm for Public Transit Information Diagrams, ADAPTiD for short.  As of yet, it’s just a dinky line simplifier that has been fed data from NYC’s PATH rail system, which connects Manhattan with points west across the Hudson.  Yes, giving such a project an acronym already is perhaps akin to publishing my work on “Hello World”.  This is true, but there’s no one out there to deny my request to acronym-ize myself so soon; perhaps I’ve abused this liberty.

So why does the world need a program that can automatically generate subway maps? Well if you’re anything like me and you live in a city, public transit is how you get around.  You refuel not at a gas pump but at a MetroCard machine.  You laugh as drivers kill each other over parking spots.

But then there are those times you’re left standing on a train platform — you’re waiting for a train that you must eventually admit will never come. Transit maps are designed to be accurate at one time: rush hour on a weekday.  Every other second (which is a lot of seconds), you need to know what the exceptions are and what they mean.  And when you start considering planned and unplanned service disruptions, that map might never be accurate.  So keep on waiting, that train’s not coming, not today.

But what if you could design a subway map that’s always right? It would look at the day and time and show you only the service that’s running.  If you’re lucky, it would even check for reroutes and suspensions, and adjust itself accordingly. I think we have the technology.