Monday, February 8, 2016

Interactive Modemspeed - SSH like it's 1995.

A couple of years ago I created a simple python program to simulate various modem speeds when you piped a command through it.  Easy, fun, but of limited use.

So, I revisited it and made the read portion non-blocking so that it can be used interactively.  The aim is to have a script I can pipe SSH through to make the remote connection act like it's behind an oldschool modem.

$ ssh remotehost | /path/ speed

Substitute /path/ with the location of the script.
Substitute speed with the speed (in bits per second) you want to experience. 

If you omit speed, you get 300 bits per second.   

Did your friend leave a terminal unlocked?  Why not have some fun?

$ function ssh() { /usr/bin/ssh "$@" | /path/interactive-modemspeed 2400 ;}

(Make sure to put the absolute path to the ssh binary so you don't create a bash fork loop.  :-P)

Now they'll wonder why all their new SSH sessions feel like they're on a BBS in 1989.

Here's the code:


import fcntl
import os
import sys
from time import sleep

def modem(text, speed):
  # Assume speed is in bits/sec, and we're running at 8,N,1
  # So, 10 bits per character.  (1 start, 8 char, 1 stop)
  delay = 1.0 / (speed / 10)  # = seconds per character
  for char in text:

if __name__ == "__main__":
   if len(sys.argv) > 1:
     baud = int(sys.argv[1])
     baud = 300
   # open stdin in non-blocking mode so we can read 1 character at a time
   fd = sys.stdin.fileno()
   fl = fcntl.fcntl(fd, fcntl.F_GETFL)
   fcntl.fcntl(fd, fcntl.F_SETFL, fl | os.O_NONBLOCK)

   while True:
       c =
       modem(c, baud)
     except IOError:
       continue  # Resource temporarily unavailable

Monday, January 18, 2016

Generic $5 128x64 OLED SPI display with Arduino Pro Micro

I bought a couple of ~$5 generic 128x64 graphic OLED displays on eBay to play with.  It took some trial and error to figure out how to get the Arduino Pro Micro to talk to them, and there's lots of different information on the net about doing so (probably owing to the wide variety of implementations of these displays and generic controller chips.)

This particular one uses the SD1306 controller and is wired for a 4-wire SPI interface.

I used the u8glib library to talk to it.  The "gallery" page on the library repo provides lots of examples of people's various combinations to make these work.  This particular one wasn't shown, but by perusing through the different examples I was able to find a combination that worked.

I'm using the SW SPI function of u8glib, so I don't have to use the ARM chip's native SCK or MOSI pins.  I found that this device will accept data without the CS pin connected (pulled low instead), so I left that out to save an output pin.  (You'd want to use CS if you were trying to use the same SW SPI bus to talk to multiple devices.)

I wired it as shown:

Arduino Pin -> OLED pin
  15 ----> SCK
  14 ----> SDA
  16 ----> RES
  10 ----> DC

Then, in the u8glib "Hello, World" example, I used the following definition:

// SW SPI Com: SCK = 15, MOSI = 14, CS = N/C, A0 = 10, RESET = 16
U8GLIB_SSD1306_128X64 u8g(15, 14, U8G_PIN_NONE, 10, 16);  

Note: The "RESET" pin was the crucial one I was missing in my initial attempts, as it's not defined in the SD1306 example configs in the source.  I had even tried tying the RES line high or low to no avail.

With those four lines, though, it works fine!  I'm not sure what the eBay auction page means by "only needs two I/O pins from Arduino."  Maybe they copied that from the I2C version.  :-P

 - K.C.

Wednesday, November 11, 2015

Installing mitmproxy on a Raspberry Pi / Raspbian Jessie

This post is a quick list of the steps it took to install mitmproxy on a vanilla Raspbian Jessie install on a Raspberry Pi.  The compile steps take quite a while, which made the trial-and-error method of figuring out which libraries were missing to be a painful process.  Hopefully this post will make it easier for anyone else trying to do the same thing.

Naturally, do
$ sudo apt-get update && sudo apt-get upgrade 
first to bring everything up to date.

Missing libraries:

  • python-dev
  • libxslt1-dev
  • libxml2-dev
  • libffi-dev
  • libssl-dev

Fairly simple, just do:

$ sudo apt-get install python-dev libxslt1-dev libxml2-dev libffi-dev libssl-dev 

Out-of-date library:

mitmproxy requires pyasn library >= 0.1.8.  
(As of this writing, the latest in the repo is 0.1.7)

Check your installed version:

$ dpkg -l | grep pyasn                                    
ii  python-pyasn1                         0.1.7-1   (...) 

If the version is >= 0.1.8 you're fine.  If, like above, it's version 0.1.7 then you'll need to replace it with a newer version.  The pip repo contains 0.1.9, so I used that.

$ sudo apt-get remove python-pyasn1              
$ sudo pip install pyasn1                        

If all the above went well, you should now be able to download, compile, and install mitmproxy (and its included dependencies) using pip.  (Note:  This will take 30+ minutes on a standard RaspPi B)

$ sudo pip install mitmproxy                           

If all goes well, you should now be able to run mitmproxy.

Have fun!

Sunday, September 20, 2015

Rebuilding the Jada Toys 2006 Camaro

We've had this cool inexpensive Jada Toys "2006 Camaro" R/C car for several years now. The batteries are worn out, the controller doesn't work well anymore and it had been relegated to just being a regular "toy car" for my four year old.

I was cleaning my electronics bench yesterday and realized I probably had enough spare parts from my other R/C ventures to gut and rebuild the Camaro with more modern parts.  Sure, the parts probably cost more than the car did, but I already had them so why not?

The first order of business was assessing whether the existing mechanisms in the car are serviceable at all.  After removing the 13 required screws to get the body off the chassis, we get a good view of the inside:

The brushed motor / gear-differential assembly (right) are probably either usable as-is or not usable at all, so I decide to keep them intact and try just driving them with a brushed motor speed controller.

The receiver / control combination circuitboard in the center looks surprisingly antique for something from the mid-2000s. (close-up) It's a totally analog 27 MHz radio receiver circuit, apparently made by the toy division of Huawei.  It's all thru-hole components and a couple of relays.  Honestly, it's shockingly reminiscent of the circuitboards that were in my childhood toys in the 1980s.  It was probably designed in that era.  Yeah. That has to go.

But what of that "steering" mechanism?  This car was fast and fun as it was originally built, but one thing I always hated about it was that the controls weren't proportional.  It had about two speeds, and the steering had three positions:  Hard left, center, hard right.

Taking apart the steering mechanism we see why:

So the steering mechanism is a geared brushed motor connected to a set of contactors that close when the steering is in the "R" or "L" position.  It's like a motorized switch for selecting between "L" and "R".

The underside of the mechanism mates with the steering crossbar with a 5mm peg:

I momentarily consider removing and re-using that disc, but decide that just putting a similar sized plastic peg on the end of a standard servo arm is probably easier.

Here's the resulting chassis steering mechanism minus the legacy control parts:

It looks thankfully simple and straightforward.  I need to fabricate a mount to hold a standard servo in a position where the arm can actuate that steering crossbar.  So, I measure and design a similar shaped peg for a servo arm and then a mounting bracket it suspend it from those two "towers" where the old, bulkier system used to be.  (Part designs are here:

Servo with servo arm & fabricated peg and 3D-printed mounting adapter:

New steering mechanism mounted in the chassis:

Here's a video of a function test.  It works surprisingly well for a first attempt!!

I used the receiver from a Hobbyking GT-2 TX/RX combo, and a Hobbyking X-Car 45A Brushed Motor ESC as the motor driver.  They were straightforward to install.  I replaced the battery connector with an XT-60 since I have lots of XT-60 equipped LiPo batteries already.

Here's a chassis / electronics "before/after" combo:

The original system ran on a 9.6V NiCad battery.  So we decide that either a 2S Lipo battery for "medium speed" or a 3S Lipo battery for "Turbo Speed" will probably work.

Sure enough, with 3S it's fast as lightening and can drift, spin-out, and do donuts.  I don't have any great videos of it driving yet, as Miles isn't terribly skilled at either driving or videography, and I can't do both at the same time.   I'll make a video with my GoPro and post it soon.  In the mean time, here's a basic video (with a 3S 1300 mAh battery) to show that the conversion worked.  (Yes, he stopped just prior to the wall.  Whew!)

It works great, and it's fun to drive!   Here's a complete parts list:

"Donor Car":  Jada Toys 2006 Camaro Radio Control Car

Fabricated Parts:
Steering knuckle & Micro Servo Mounting Adapter

Purchased Parts:
HobbyKing X-Car 45A Brushed ESC
HobbyKing HK-GT2 TX/RX combo
Turnigy TGY-50090M Analog Metal Gear Servo

That's it!

Sunday, August 16, 2015

Programming a generic STM32F103C board in Arduino

A while back I purchased some generic STM32F103C8T6 development boards on eBay for about $4 each.  I initially had some limited success programming them using the GCC ARM Embedded (eabi) toolchain and a generic STM32 loader program.  Since then I've discovered a project to get them working with the Arduino 1.5+ toolchain.

There's a lot of different information about the various STM32 boards out there.  I'm documenting my notes here mostly for my own sanity since I don't play with these boards often.  Maybe you'll find it useful too.

Arduino hardware library for these boards:

"Support" forum:

The USB port
The generic boards do not have a meaningful USB bootloader.  The USB port is only useful for power.  (TODO: Flash the "Maple Mini" bootloader onto them for future ease of use?)

Arduino Board Selection & options
Tools -> Board -> Generic STM32F103C
Tools -> Variant -> "STM32F103C8 (20k RAM. 64k Flash)"
Tools -> Upload method -> "Serial"

FTDI / Serial connection
Connect 3.3V FTDI USB -> Serial programmer as follows:

  • STM32 UART0 TX pin A9 -> FTDI RX
  • STM32 UART0 RX pin A10 -> FTDI TX

I use the GND and 3.3 pins on the 4-pin header for power, but the ones on the IO pads work fine too.

Program / Run Jumper
  • Run mode:  Both jumpers at "0"
  • Program Mode: Jumper 0 (top) at "1"

With J0 set to "1", press "reset" just before hitting "upload" in Arduino to flash firmware.  Program will run immediately after flashing, but won't run after power-cycle until you set Jumper 0 back to "0".  (??)
I have no idea what the bottom jumper is for.

PC13 LED seems to be wired from +3.3V to the PC13 pin.  So setting the pin low lights the LED, and setting it high extinguishes it.

That's it!  With any luck, after loading the above library and following these notes you can push Arduino sketches to your super-cheap, 72MHz STM32 ARM board.


Sunday, July 26, 2015

Arduino-based barometric altimeter / altitude deviation alerter

While working on my instrument training, it occurred to me that I had everything I needed in my parts bin to build a device to help alert me to deviations in altitude. So, I built MonkeyAltimeter.

It started off on a breadboard while I worked on the code:

Then, I took it for a flight test (primarily to see how accurate it was in the cabin and see if my VSI routine worked):

Finally, I designed and printed a simple case for it:

The details,  parts list, operation manual, &etc are here:

The source code is here:


Thursday, April 9, 2015

My comments on FAA NPRM for "Operation and Certification of Small Unmanned Aircraft Systems"

have finally submitted my comments to the FAA's NPRM for model aircraft. After reading the proposed regulations, reading the responses from various advocacy groups, and considering both sides I have submitted the following. If you would like to comment to the FAA as well, the link is here:!docketDetail;D=FAA-2015-0150
The deadline for comments is April 24th, 2015.


I am a computer engineer, r/c model enthusiast, private pilot, and aircraft owner. I am writing in response to the FAA's proposal to regulate small unmanned aircraft systems, including model aircraft.

I support the exemption of recreational model aircraft from the regulation of unmanned aircraft systems.

I understand the critical need to maintain separation of the increasing proliferation of radio control and hobbyist unmanned aircraft ("model aircraft") from other aircraft in the national airspace system. I do not agree that trying to interpret model aircraft as being subject to the existing aircraft regulations is a productive way to accomplish this. Model aircraft have more in common with the existing (exempt) classes of amateur rockets, balloons, and even ultralight human-occupied aircraft than they do with the aircraft regulated under 14 CFR.

I agree with the Academy of Model Aeronautics points about the proposed regulations regarding model aircraft. Specifically, with my concerns added after each one:

AMA point:
• Rigidly defining a requirement to operate within visual line of sight and that calls into question the use of a specific technology or equipment, namely first-person view (FPV) goggles. The language of the 2012 statute concerning "within visual line of sight" indicates how far away a person should fly the model aircraft, not what method of control may be used for the recreational experience. The proposal for commercial unmanned aircraft acknowledges that an observer (spotter) can be used to ensure airspace safety, just as the AMA's community-based safety guidelines do.

My comments:
Many operations of "FPV" flying and equipment are done in close proximity to the ground, and in places where incursion with other aircraft in the national airspace system are impossible. The FAA should not preclude this fast growing activity, as it poses no threat to the nation's airspace or aircraft.

AMA point:
• Narrowly interpreting the words "hobby or recreational use." You should not regulate people who are flying model aircraft in connection with the hobby just because they receive payments. For decades, enthusiasts have participated in contests and competitions that have cash prizes, have been paid to instruct others on how to safely fly models, and have received compensation for aerobatic displays. These payments incidental to the hobby do not change the underlying recreational purpose of the activity or make the hobby any less safe, and regulating these activities would be highly disruptive to the hobby without any benefit.

My comments:
The adoption of advertisement driven technology has also blurred the line between "for compensation" and not. Hobbyists naturally want to share their love and enthusiasm for their activities, and in doing so will use "free" computer platforms like online blogs, YouTube, social networks, and other "cloud" based services. Many of these services are supported by "monetizing" the content, that is to say- selling advertisement space capitalizing on the popularity of the user-driven content. The FAA's guidelines for what constitutes "commercial" or "for hire" operations does not take into account this corner-case, and as such has been interpreted multiple (inconsistent) ways.

I recommend that the FAA more broadly accept model aircraft operation by hobbyists as "non-commercial."

AMA point:
• Making model aircraft subject to airspace requirements such as air traffic control clearance, that have never been applicable in the past and with which it is impossible or impractical to comply. Congress indicated the maximum obligation, which is actually stricter than what the FAA's guidance has been for the past 34 years: notifying the airport when operating within five miles. That is the most that model aircraft hobbyists should have to do.

My comments:
I support the FAA's efforts to keep the national airspace system safe for all operations within it. We need a clear, concise definition for what is and isn't allowed for hobby model aircraft. This may (by necessity) include airspace restrictions, airport proximity restrictions, and altitude restrictions. I encourage the administration to consider both sides carefully, and avoid blanket restrictions (on either side) that are difficult to interpret or comply with.

It's easy (and possibly convenient) to say "no operations within Class Bravo airspace." 
Consider that most model aircraft are operated within a few hundred feet of the ground, though, and much of the Class Bravo "Surface Area" actually becomes safely usable by the model aircraft community. I think there is a middle ground between what the AMA recommends and what the FAA has proposed, and I hope we are able to find it for the sake of both communities.

Thank you for providing us the opportunity for comment.

Kenneth C. Budd
AOPA Member # 03890068
EAA Member # 1132133
AMA Member # 1050433