Converting .MPG to .AVI with Linux programs

I am trying to convert .mpg files from a sony camera into other, smaller versions for distribution. The files are in the mpeg2video codec, with a resolution of 720×480 at 29.97 fps. Normally, I’d use ffmpeg for this, but apparently “This program is only provided for compatibility and will be removed in a future release. Please use avconv instead.” Thanks Ubuntu, I’m sure that won’t screw up a few thousand people’s video conversion scripts.

Anyway, let’s see what man avconv has to say. I want no sound, and I want to start 55 seconds into the film, to cut off most of a boring first minute. Seeking into the video is -ss 00:00:55. The option -an drops the audio. So, avconv -i blue_ball.mpg -an -ss 00:00:55 blue_ball.avi should do it. And, in fact, it does.

Modkit Micro Alpha

Modkit Micro Alpha does not run on Ubuntu 12.04 64-bit without the user moving some directories around and installing ia32-libs.

It also does not save projects more than once per launch, or compile code at all, on Ubuntu or Mac OSX.

I appreciate that the point of Modkit’s Kickstarter campaign was not to sell a finished product, but to get the money to produce one. That said, people who have paid money for a thing may want that thing to work. Modkit is now in the uncomfortable position of having sold the moon, and being expected to deliver it.

ToyBrain Version 2 Firmware Troubles

I’ve started trying to load a bootloader onto the V2 hardware for the ToyBrains, as part of attempting to make a luminous fez for my girlfriend. I ran into a few problems.

The first problem I had was that the IC I’m using is the ATMega328, not the ATMega328P. So far, the only difference I can find between the two is their voltage range, but they have different ID strings. To get around this, I duplicated the chip definition for the 328P in avrdude.conf, and replaced the ID with the proper ID for a 328 (no P). This seemed to work for getting the Arduino IDE to burn the bootloader to my chip.

Unfortunately, I had made the Arduino boards.txt file description of my board by copying the Arduino Nano section. This includes a fuse setting for an external clock crystal. The toybrain boards don’t have a clock crystal, and use the internal RC oscillator of the Atmega328 instead. This meant that when the board was reflashed, it had no clock, and so not only could it not be programmed from the IDE, it also couldn’t be reflashed with a new bootloader using the USBTinyISP. The big symptom of this is that avrdude immediately fails to init, and if I used the -F (force, which you should never do) flag, it reported a part ID of 0×000000.

To fix that problem, I wired two small caps and a crystal to add an external oscillator to the board, tacked it to the appropriate pins, and reset the flags.

At this point, I think I have the bootloader installed, and the fuses at least mostly correct. The Lilypad Arduino with the ATMega328P uses these fuses: Low: 0xE2 High: 0xD8 Extended: 0×05, which mean that the clock is internal, and not divided by 8, so it runs at 8MHz. The bootloader settings set the size of the bootloader, which is the same as the one I am using (ATmegaBOOT_168_atmega328_pro_8MHz.hex), and the boot interrupt vector.

However, I still get a problem when I attempt to upload a program to the device. If I set the upload speed to 57600, avrdude beefs about the chip ID. If I set it to 19200, avrdude says the programmer is not responding.

My current guesses at the cause of the problem are these:

• My clock settings are slightly off, so the chip is running at the wrong speed for the bootloader. As a result, the serial data rate is bad, and the data that avrdude gets back is nonsense. This can be fixed by applying the above fuse settings via the USBTinyICSP.
• I have the reset vector or bootloader size setting wrong, and so the chip doesn’t start the bootloader correctly when it is reset. Again, this is a matter of fixing the fuses.
• Something else that I haven’t considered yet, e.g. there is something wrong with my hardware.

I’m going to work on it more tonight and see if I can get it going.

Robosapien Repairs

I got a Robosapien V2 on Craigslist for very short money, and started working on turning it into a robot. This doesn’t interfere with my other projects because the stuff I’m using to robotify it is the same codebase I’ll be using for brain hacks at Defcon and and a drink dispensing robot at future festivals. But I digress.

On powering it up, the Robosapien complained about a “low brain battery” and turned itself off. When I replaced the batteries, it failed to do anything at all. I checked a few forums, and it turns out that the problem is the wire insulation failure that struck a lot of the Robosapien V2s. The problem is that the insulation on some of the wires, particularly the ones that are single strands, rather than part of multi-wire cables, is bad. It becomes brittle and crumbly, and then flakes off when the robot moves. This causes the batteries to short out, and die quickly, if you are lucky. If you are not lucky, the Robosapien melts or catches fire.

In my Robosapien, the affected wires appear to be confined to the leg wiring harness, particularly the motor wires, battery leads, and wires from the foot switch PCB to the main PCB. To fix this, I’m going to extract the wires, and replace them with un-crappy ones. It’s kind of a tedious job, but I am actually kind of looking forward to it as a way to unwind at the end of the day. Have a beer, replace a bunch of wires, chill out.

IR Receivers

For a long time, I have been thinking about making a set of pin badges that signal to each other using an IR pulse, and blink with a visible light. If a few of them were together, they would synchronize their lights, like fireflies.

To do that, I’d want to detect IR, and reject IR that was not from one of the badges (like light from a fire or the sun). The IR receivers that go into TVs do that, and there are super-small versions available for surface-mount construction.

Osram’s SFH5410 looks perfect, but was discontinued, this time in 2010, and without a suggested replacement.

Sharp makes the GP1US30XP series in surface mount packages about 4x4mm. Their sensing direction is normal to the PCB, which is ideal for aiming them away from the wearer. This would be the ideal part, if but it was also discontinued.

For purposes of prototyping, I can use some larger parts that I already have, but the ultimate design will be very small. Someday, perhaps I’ll have them fabricated professionaly and give them away at Firefly.

Toy Helicopter Hacking

This Christmas, my parents gave me a palm-sized toy helicopter (Avatar Z008), and my girlfriend’s parents gave me a slightly bigger toy helicopter with a video camera (Egofly Spyhawk). I also have one that I bought myself (Syma S107). All of them are gyro-stabilized, coaxial-rotor helicopters, which basically just means that they automatically don’t roll, and are easy to fly.

I had hoped to convert one of them into a tiny drone. I opened up the S107 this morning to take a look at the internal PCB. The IR signal from the remote goes to an unmarked 14-pin IC. The gyro (which I assume to be the little metal can mounted on a daugther board from the main PCB) is marked, with “C 146″ and “Y2373″. One pin of the gyro is grounded, one, marked “TLY” is connected to the unmarked IC, and one goes to Vcc. That is pretty clearly power, ground, and a signal pin.

This means any control that the system is doing based on the gyro is done by that unmarked IC. Chances are that re-implementing the gyro control would be amusing, but much harder than simply adding whatever drone control I decided to add “on top of” the existing hardware.

An easier approach would be to take advantage of work that other people have done on reverse-engineering the IR protocol, and add my own control circuit that sends IR control signals to the existing board. That way, the existing board would take care of driving the motors and keeping the helicopter balanced, while my board would add autonomy.

Downward and front facing versions of SpeckleSense could be used to give the helicopter a sense of its movement in the world, which might be good enough for dead-reckoning navigation over small distances.

Mindflex EEG Hacking

I got a Mindflex Duel for Christmas. The Mindflex Duel is a toy that uses a pair of EEG headsets to read signals from the users, and then send those signals to a base unit that contains a blower and a little sliding cart to move the blower. The users try to concentrate to control the cart, moving a little ball suspended in the air jet from the blower into a goal.

Needless to say, I gutted it.

The base unit has a little PCB with a 2.4Ghz radio on it, and a little hardware to control the blower and cart motors. The headsets are the really interesting part. Each one has a single-channel EEG and a wireless radio. I took the radios out and replaced them with BlueSmiRF bluetooth-to-serial links so that I could connect them to my laptop. The hardware part of the replacement is below, the software part will be in another post.

The guts of one of the headsets. The 2.4 Ghz radio is the top daughter board, the EEG hardware is the bottom daughter board.

I desoldered the original radio. It works in the same band as Bluetooth, and consumes power, so there was no need to have it there.

The red and black wires supply power for the BlueSmiRF. It can take up to 5 or so volts, but the headset runs on 4.5v, so it is fine to hook it up like this. The red wire is connected to the power switch, rather than V+, so that the power switch also turns off the bluetooth radio.

The white wire goes from the pin labeled “T” on the EEG board to the RX pin on the BlueSmiRF. The T pin of the EEG board is a serial line, which transmits the EEG data to the BlueSmiRF.

Glue the bluetooth radio into place with hot glue. The LEDs on the BlueSmiRF are covered by black paint on the inside of the Mindflex headset, but I scractched away the paint in little circles so the BlueSmiRF status lights would shine through.

The finished product looks stock, until you turn it on. That red light on the side is not normally there.

Toybrain further improvements

I populated one of the Toybrain V2 boards and gave it a bit of a shakedown. I still have to test the motor driver, but I’ve at least fixed the backwards ICSP header and the reversed TX/RX lines. I did add a LED for debugging, but then hooked it up to a ADC line, so lighting it up means losing an analog pin.

For those as don’t know, you can get the analog pins on an Arduino/ATMega168/ATMega328/whatever to act as a digital GPIO by treating it like one, using the aliases “A0″ through “A5″. Full instructions are here.

The V2 boards also have a reset button, which is very useful.

I’m already working on V3, which is going to be smaller. The V2 has headers for power, ground, and data for each pin, which I think is a bit much. I want that room back to build a voltage regulator and some filtering onto the board. The microcontroller can run at 1.8 to 5.5 volts, so the filtering is a bit more important than the regulation. However, some toys surely run at 6 volts or more, and would ruin the microcontroller, which is a SMD device.

So V3 will include filter capacitors, probably SMD, on the power rails, and a 3.3V regulator (The Micrel MIC5209-3.3 in SOT233 package looks good) or the option to short around it. The regulator only supplies the power for the microcontroller, so it won’t need to be very high power.

ToyBrain V2 Ordered

I’ve ordered the boards for the second version of the ToyBrain project. These boards are smaller than the originals, and should correct most of the problems (swapped TX/RX lines, put the ICSP header in right, etc.) I’m planning to outfit them with ATMega328s.

If these work and are all correct, the next version will be done in black, possibly with gold for looks. After that, perhaps I’ll make a kickstarter of it and see if I can’t sell a few boards.

Cider started

A while back, Sami and I made two gallons of hard cider. When we were doing that, we made two errors as well. The first is that we put in the ginger, cloves, and cinnamon that we wanted to flavor it with when we pitched the yeast. Cinnamon and cloves are both antifungals, so they probably contributed to the yest dying off. We also used normal bread yeast, which isn’t very hardy. The resulting cider tasted fine, but it was very sweet, because the yeast died before it had a chance to convert much of the sugar into alcohol.

My new batch of cider is 5 gallons of cold-pasteurized (with UV light, apparently) cider from Bolton Spring Farm, one packet of SN9 yeast, 5 tsp. of yeast nutrient, and about two pounds of sugar. I started it earlier this morning, and the yeast appears to be working already, forming carbon dioxide and lifting itself in the cider. My plan is to let it run until the yeast poisons itself and settles out, and then flavor the cider with cinnamon and cloves and bottle it. If I go with cinnamon and cloves, I probably won’t do a second fermentation to get it to be carbonated.