Can’t Print PDF to HP LaserJet 4050?

If you can’t print a PDF file to an HP LaserJet 4050 in Windows 7 or Windows 10, perhaps via a JetDirect network card (for a 4050N, but this probably doesn’t matter), here’s a possible solution to this frustrating problem:

  1. Open your printer properties
  2. Select the Device Settings tab
  3. Find the option called Postscript Passthrough
  4. Set it to Disabled
  5. Hit Apply

This will cause the print driver to parse the incoming PDF file (which is made of PostScript internally), and then re-write new PostScript to send to the printer. This makes it work because Adobe has endlessly fiddled about with PostScript, especially for PDF files, and compatibility can sometimes suffer. Hope this helps someone!


LIFX Color 1000 Teardown and Repair

LIFX Color 1000

LIFX Color 1000

I had a LIFX Color 1000 smart bulb that was giving me problems. It would intermittently become unresponsive, and did things that made me suspect it was resetting itself after detecting some error condition. (If so, good on you LIFX for including a watchdog timer!) Intermittent problems are the worst to track down, and after months of juggling every possible option, including firmware updates, moving the bulb to different sockets, fiddling with WiFi stuff, and more, I decided it was actually the bulb and had LIFX replace it under warranty. Their support was fantastic, by the way.

LIFX Color 1000 LED PCB

LIFX Color 1000 LED PCB

Since I now had a defective bulb, I figured I’d do a teardown. So I did, and posted it on as well! I discovered during the teardown that the LED PCB was not fully-attached to the metal case (which acts as a heatsink). I’m re-attaching it using a good thermal epoxy. With any luck, this will cure the bulb of its intermittent connection problems and I may be able to put it back into service.

Found some fun debug headers in the bulb, too, but didn’t have time to apply the JTAGulator…

LIFX Color 1000 Hack Opportunity?

LIFX Color 1000 Hack Opportunity?

Check out the teardown guide for detailed photos.


Building and Installing Erlang 18 on a Beaglebone Black

This writeup documents the process I used to install Erlang 18.3 on a Beglebone Black, building for ARM (armv71) architecture.


The Beaglebone has Debian Wheezy installed, 7.9, from the latest Wheezy image available on the beaglebone site at the time I set it up. I had a terrible time getting Jessie to install cleanly, and I recommend you avoid it for now (may write about those woes elsewhere).

Debian 7.9 (BeagleBone, BeagleBone Black, Seeed BeagleBone Green – 4GB SD) 2015-11-12 sha256sum: f6e67ba01ff69d20f2c655f5e429c3e6c2398123bcd3d8d548460c597275d277

First off, I do this via the serial console, so that I can see all the good stuff that may end up there as the system runs. Plenty of ways to connect, like using a standard 3.3V FTDI cable and the screen command. Handy tip – figure out the rows/cols size of your terminal window, and then throw them into this command to get everything sized right:

root@beaglebone:~# stty cols 150 rows 70

The rest of this is written assuming you are logged in as root.


The Debian image provided on the Beagleboard site has most of the deps already in place, but we need to install the ncurses development files. Also, due to use of newer atomic operations constructs, we need gcc 4.7 to avoid performance issues.

root@beaglebone:~# apt-get install libncurses5-dev
root@beaglebone:~# apt-get install gcc-4.7
root@beaglebone:~# apt-get install g++-4.7

After installing gcc 4.7, it will be living along side version 4.6, so we need to switch things around. The update-alternatives command takes care of symlinking and stuff for us:

root@beaglebone:~# update-alternatives –install /usr/bin/gcc gcc /usr/bin/gcc-4.6 60 –slave /usr/bin/g++ g++ /usr/bin/g++-4.6
root@beaglebone:~# update-alternatives –install /usr/bin/gcc gcc /usr/bin/gcc-4.7 40 –slave /usr/bin/g++ g++ /usr/bin/g++-4.7
root@beaglebone:~# update-alternatives –config gcc
root@beaglebone:~# gcc –version
gcc (Debian 4.7.2-5) 4.7.2

Excellent, the gcc link now points at the correct version.

Building Erlang 18.3

Download the source tarball from the Erlang downloads page, unpack it, delete the tarball to save some space, and jump in:

root@beaglebone:~# wget
root@beaglebone:~# tar -xvf otp_src_18.3.tar
root@beaglebone:~# rm otp_src_18.3.tar
root@beaglebone:~# cd otp_src_18.3/

The next steps are from the Erlang build instructions. You should read that page before you proceed, so you can tweak your build to suit your needs.

root@beaglebone:~/otp_src_18.3# export ERL_TOP=`pwd`
root@beaglebone:~/otp_src_18.3# ./configure
…lots of configure output, make sure it looks good…
root@beaglebone:~/otp_src_18.3# make
…lots of make output, make sure it looks good…
…grab coffee…
…maybe lunch…
root@beaglebone:~/otp_src_18.3# make release_tests
…and more building, not quite as long…
…refill the coffee…

Testing Your Erlang Build

Always good to run the tests when available, and especially when building for a less-common platform. Again, these command still come from the Erlang build docs linked above.

root@beaglebone:~/otp_src_18.3# cd release/tests/test_server
root@beaglebone:~/otp_src_18.3/release/tests/test_server# $ERL_TOP/bin/erl -s ts install -s ts smoke_test batch -s init stop
…runs tests, get more coffee…

Finally we need to check the results of the tests. These are delivered up in a nice interactive HTML page, which would be unfortunate to read on a text console. So, let’s toss a link into the www directory and tweak permissions, then we can see it in a graphical browser over the network.

root@beaglebone:~# ln -s /root/otp_src_18.3/release/tests/test_server /var/www/erlang
root@beaglebone:~# chmod 755 /root

You may want to chmod 700 /root when you are done. You can now access the test results at http://YOUR_BBB_IP_HERE:8080/erlang/ – look them over carefully.

A few tests failed for me. Three in the time suite, univ_to_local, local_to_univ, and consistency. Apparently these only work if the system running them is set to CET timezone where the main Erlang build box lives, and where I don’t live, so no worries here. Also, t_gethostnative in inet suite failed, but reading the test case code it seems to check some odd Windows behaviour. When I test the call by hand in an erl shell, it works fine. Meh, good enough!

Installing Erlang

This is as easy as can be:

root@beaglebone:~/otp_src_18.3# make install
…lots of make install output here, look it over to see if it worked…

And test:

root@beaglebone:~# erl
Erlang/OTP 18 [erts-7.3] [source] [async-threads:10] [hipe] [kernel-poll:false]

Eshell V7.3 (abort with ^G)
1> io:format("It Lives!~n").
It Lives!

Enjoy your fresh new version of Erlang on Beaglebone Black!


Buffalo Unconference 2016 Talk

I gave a talk at Buffalo Unconference today (April 16, 2016). It was this:

Internet of Robots
Beyond the Internet of Things is the Internet of Robots. Let’s discuss the state of the art of IoT/M2M, artificial intelligence, and Robotics, where we are heading, and how to get there.

The gist of it was, some of our biggest challenges are not having good tools (for hardware especially), and existing tech not being able to scale to the forecasted number of devices. In discussion, also touched on the information security nightmare we’re about to see.

You can see the slides on GitHub, if you like:



Many moons ago, in the early 1990’s during high school, my friends and I somehow came across three ancient laptops. Back then, we acquired all kinds of weird and wacky stuff, and being poor students, would press anything into service we could manage. I don’t recall the model exactly, but they were something much like a Toshiba T1100, if not one of these exactly, pictured here:

Toshiba T1100

By Johann H. Addicks – own photo, deriving from Gallery, CC BY-SA 3.0,

Of course, the first thing to do was get DOS running. Having abandoned DR-DOS a few years prior, we whipped out our ever-handy MS-DOS 6.22 disks and set to work. No problem! Worked first go. Remember when it was that easy? Not so much any more… Of course, the next thing on our agenda was to connect them all together.

What? Network these ancient beasts? And who did that for funsies at home in 1992?? You see, we got into this whole network thing early, being nerds and all. Dialup, Gopher protocol, all that fun stuff. I fondly recall the days spent with Dave trying to make a pair of ISA Ethernet cards work. Thinnet 10Base-2 stuff, RG-58 coax, T-connectors, and terminators… We even had to compile IPX/SPX drivers using some Novell Netware floppies. Massive pain in the ass. Why did we go to all this trouble? Well, it was the classic motivator for any youngins to learn them some high-tech toys – To play Hexen on a LAN in co-op mode, of course. It was worth every second of effort. =) We ended up re-playing Heretic as well, and moved on to Descent. Oh my, I still get vertigo thinking of that game, and I’m not one to suffer from vertigo! So good…

ISA Ethernet

It looked something like this. But crustier. Image by Klaus Eifert – Own work, CC BY-SA 3.0,

And before that Ethernetty goodness that we lucked into, we all had our machines wired up with serial cables, between rooms, and between floors of the house. It was tiring having to sneakernet files between machines all the time, and (at the time) damn near impossible when one was a DOS-based 8086 (actually an NEC V30 or V40, the cloned and souped-up version) and the other a Macintosh SE running System 6.0.8. Of course, we would shuffle connections when it was time to fire up the modem (which was ALL the time, duh! MOM! Hang up the phone!!). And that sucked.

So when it came time to network our new-found “laptops”, I got crafty. I figured, well hey we have three of these things, and some desktops we may want to get in the mix, so why not connect them all together at once? Mind you, at the time, Ethernet was still exotic, expensive, and well out of our reach with that one notable exception for Hexen. (Heck this may predate that event; it’s all a bit fuzzy) But, I was pretty handy with RS-232 and RS-422, thanks to a PC, a Mac, and a modem.

So I created SPRINGNet! This stood for Serial Packet Ring Network. Machine A would send to B, which would send to C, which would send back to A. Or however many we had in the ring. Mind you, this was before I had ever even heard of Tokenring, and just seemed the thing to do. Well, it worked! For what applications, you ask? Well, for the roleplaying game engine that we wrote in QuickBasic 4.5. It wasn’t a game by itself, but it facilitated AD&D sessions like a champ (2nd edition FTW). Started out by extending the codebase with the SPRINGNet protocol, which was little more than a message format and an source/destination address, but hey what more do you need?

SPRINGNet diagram

SPRINGNet diagram

After that I extended it to a separate TSR driver that would do the same thing, so that any application could use it. Worked well, but we never made much use of it, primarily because those ancient laptops really sucked. I had big plans to build some hardware accelerator modules for the protocol, since it wasn’t nearly as fast as I’d like for transferring files, implementing all the address detection and packet decoding in software. It was going to be simple, and would simply be a chip that would watch for the address byte, and if it matched the address of the machine/adapter, it would switch the data stream into the serial port instead of pass it on. (We’re talking basic logic chips here, not microcontrollers.) We didn’t have any kind of TTL counter to prevent loops, but would just have the originating machine look for it’s own address as the sender, and drop the packet if it saw it.

Never got around to building the hardware, and moved on to other things. But SPRINGNet lives on fondly in my memories! Even had some door sensors, buttons, and other fun stuff hooked into the ports, what with all those DSR CD CTS etc wires hanging out unused. (RI? Who ever used RI anyhow??) Yes kids, back in the day, our things were all on the Internet (or some kind of net). Take THAT, IoT!


Delicious IoT Coffee, Part 3 of 3

My third of three guest articles has gone live on Texas Instruments’ e2e site Launch Your Design blog!

Kinoma IoT Coffee

Kinoma IoT Coffee

The last of the three installments discusses how to compose data services into a data flow graph, and then some thoughts on iterating the design and porting it to BeagleBone Black.

See also Part 2, and the original writeup.