Hearing aids

ALMA! Check your battery!

In which we make a MaxBotix sonar speak properly over a serial connection.

Recently I hooked up a MaxBotix MB1220 XL sonar to an FTDI breakout board to do some experimenting, and I ran in to an issue I had discovered before but thought was an artifact of the processor I was using.  You see, previously (a couple years ago) I had connected a MB1220 to a Fez Panda II and discovered a wonderful stream of gibberish flowing from my brand new sonar.  At first I assumed I had connected it improperly.  There are only three wires that need to be connected to make the sonar transmit over the serial port - power, ground, and TX - but just maybe I had accidentally hooked up to the analog voltage instead of TX.

No dice.

All connections secure? Check.
Are we using 5 volts? Check.
Is the processor 5 volt tolerant? Check.
Is the TX from the sonar connected to the RX of the processor? Check.
9600 baud 8N1? Check.

Still no luck.

Still just gibberish.

At some point while reading about TTL versus RS232 serial connections it occurred to me that perhaps

... the Pin 5 output delivers asynchronous serial with an RS232 format, except voltages are 0-Vcc.

could mean the levels were inverted rather than being out of range.  In other words, what my processor thought was high the sonar thought was low and vice versa.

Not having a hex inverter (or even a single inverter) handy, I flipped through some old notes about logic gates and found a simple inverter made from a couple of resistors and a transistor, parts I had on hand.

Below is what I threw together on a breadboard.


R1 = 1K
R2 = 10K
Q1 is a generic NPN transistor out of a pack from Radio Shack.

With this in place, R121 flashed across my LCD display.

Success!

Flash forward two years, and we are back to me hooking up the MB1220 to an FTDI breakout board.  The breakout board was set to 5v.  The sonar was being powered by 5v from the breakout board.  Putty was up and set for a serial connection with 9600 baud 8N1.

The result?

Gibberish.

I then wired up the above circuit on a breadboard, connected the sonar and the breakout board, and presto, the range information I expected to see.

If like me, you connect a MaxBotix sonar to a processor, FTDI chip, or anything else over serial and find gibberish, you probably should invert the signal with something like the circuit above… or stick to their I2C line.

Transcode FLV to MP4

On a recent business trip to Kuala Lumpur and Dubai, I had a 16 hour flight and thought I would watch some old Udacity videos.  I downloaded some lectures from Udacity[1] for offline viewing and discovered they were in FLV format.  Unfortunately, the media player built into Windows 8, Windows Media Player, does not play FLV videos out of the box.  There are many solutions to this problem from installing various codecs and alternative video players to transcoding.  I chose to do the latter, and this is my story.

I know there are many different programs that promise to take care of transcoding for you, but I prefer to install as few unknown/untrusted bits of software as possible.  As a quick method to bulk convert the files, I wrote the Python script below. You will need two things to run this script:

  1. Python - I wrote this using version 2.7.5 from the Anaconda package[2]
  2. ffmpeg[3]
from os import listdir, remove
from os.path import isfile, join
import subprocess

vid_path = '[PATH TO VIDEOS]'
ffmpeg_path = '[PATH TO ffmpeg.exe]'

vids = [f for f in listdir(vid_path) if isfile(join(vid_path,f))]

for vid in vids:
    file_name = vid[:-4]
    subprocess.call(ffmpeg_path + ' -i ' + join(vid_path,vid)
        + ' -qscale 0 -ar 22050 ' + join(vid_path,file_name)
        + '.mp4', shell=True) 
    remove(join(vid_path,vid))

This script is quick and dirty.  It simply loops over all files (hopefully just .flv videos are present) in the vid_path directory specified and uses ffmpeg to transcode them to mp4.  Be sure to set ffmpeg_path to the path of ffmpeg.exe on your system.  After a video is transcoded, it is deleted. One very import note: beware of shell=True in subprocess.call().  In some cases, this can be a security risk.  Please see [4].

Possible improvement opportunities for the reader:

  • make removing the original file conditional
  • only join vid_path and vid once
  • filter discovered files so that only .flv files (or the target type of your choice) are processed
  • traverse nested directories looking for files
  • research the arguments ffmpeg accepts and provide a way to change them


[1] Udacity
[2] Continuum Analytics
[3] ffmpeg.zeranoe
[4] subprocess.call()