Category: Complaning

IoTiocy

I may be the first to come up with this terrible neologism, but the time for it is certainly at hand. There have been a number of high-profile incidents where the security of stuff that was connected to the Internet was neglected in the rush to get it connected, or highly dubious design decisions were made in order to get an IoT “thing” to market.

The term originally came up when I was discussing this widget with a friend of mine. The NodeMCU boards are pretty sweet, and are based on the ESP-8266, which is also pretty sweet. The motor driver chip they used is from the 1970s, and there are far better ones available. The VNH2SP30 is a beast, and can supply 10x the current of the L293D, although you’d need two of them for dual motors, so there may be a horses for courses argument to be made there.

The DDoS that took out Krebs On Security, though, doesn’t really have a similar argument going for it. IoT security is hard because the devices don’t have a great interface for users to tighten up their security settings (if indeed, they have any security settings), and users don’t expect to have to tighten up the security of their appliances. As a result, insecure IoT stuff just kind of hangs out in dubious parts of the web, waiting for someone to make it a questionable offer of employment.

To the people who make things incomplete, weak, or insecure, I dedicate this new word:

IoTiot noun, informal

  1. A person or company that creates IoT devices lacking security, solid design, or even a purpose, usually in order to make a quick grab for cash.
  2. Any such device, once it starts behaving as it was designed (which is to say “badly”).

Similarly: IoTiotic, IoTiots, IoTiocy

 

ROS and OpenCV will fite u, m8

I recently wanted to do some computer vision stuff using OpenFace, which is a collection of face-processing computer vision algorithms and tools to use them. It uses OpenCV 3.0.something, which uses, among other things, vtk6, and friends libvtk6-dev and python-vtk6.

Normally, this wouldn’t be a problem, but I use ROS Indigo, as does the lab I work in. ROS Indigo uses some previous version of vtk, and so attempting to install OpenCV 3.0 blows away my ROS install, and makes apt freak out when I try to install it again. The actual error was something like “you have broken held packages”, only I didn’t actually have held packages OR broken packages.

Apt just gives up at this point. Aptitude, on the other hand, proposes removing the offending VTK packages and proceeding with the ROS install. Only time will tell if I’ve trashed my OpenCV install, but if I have, I can just go back to an older OpenCV version.

A Word of Warning

My PhD work (TinyRobo) uses a USB-Serial converter to talk to the ESP-8266 modules in the tiny robots. Normal FTDI cables have a cable that ends in a 0.1″ 6-pin header with this pinout:

  1. Black – Ground
  2. Brown – CTS
  3. Red – VCC
  4. Orange – TX
  5. Yellow – RX
  6. Green – RTS

It turns out that esptool can manipulate the DTR and RTS lines to reset the chip in bootloader mode, which is great for uploading code to it. It also means I can get away with not having any parts on the TinyRobo boards to handle the reset, which is great because it lets me keep the board small. Unfortunately, the FTDI cable I have doesn’t expose the RTS line, so I got a converter module for cheap off Amazon. The particular module I got is this one:

2016-04-15 14.10.13

I added that red wire and cut a trace so that the pins would be:

  1. DTR
  2. RX
  3. TX
  4. VCC
  5. CTS
  6. Ground

So far, so good, but I can’t upload with it. I threw a scope on the lines, and it looks like instead of swinging from VCC to ground like well-behaved TTL serial lines, they swing from VCC to VCC minus some tiny voltage, less than a volt. Adding pull-downs on the lines doesn’t seem to have helped. It could be that the timing is of, but I suspect that somewhere, some cheapskate saved some fraction of a cent on this board, at the expense of it doing the one thing it was supposed to do (YOU HAD ONE JOB).

KiCad is Still a Shitshow

Six months ago, I designed a schematic and circuit board in KiCad. Yesterday, I tried to open it and got a list of errors so long that it didn’t fit on my screen from top to bottom. The reason is that KiCad loads the footprints of the parts you use from Github, so when (not if) the KiCad devs change how they store footprints, your install of KiCad breaks. In other words, installing KiCad gives the KiCad devs permission to break your workflow for no reason.

I fixed my KiCad package list by writing a little python script that goes through the KiCad github repo and generates a new footprint list based on however they happen to be organized and whatever they happen to be called today. Copy that over my previously working footprint list, and the error message went away.

However, since the last time I used it, my install of KiCad has stopped rendering in CVPCB. No error message or anything, just doesn’t render the copper layers, parts, etc. I got part of the ratsnest, and that’s it.

Clearly, the thing to do is to install the newest version of KiCad from the developer’s PPA.

Nope, that returns a 404.

Clearly, the thing to do is to install using the script the devs wrote to install and build KiCad.

Nope, the script fails because they use a version of WXWidgets that like no one else on earth uses.

So let’s recap: No method of installing KiCad works, and just LEAVING YOUR WORKING INSTALL ALONE is not sufficient to ensure that it continues to work.

Since I’m designing a small PCB, CadSoft’s Eagle is looking more and more tempting. Limited PCB sizes aren’t a problem if you’re making something small.