Recently I was intrigued by a Hack A Day post regarding a low-cost development platform for their MSP430 line of microcontrollers. I’ve long wanted to toy with an Arduino, but with many other projects currently under my belt, I’ve jut not had the time. When I heard the Launchpad was only $4.30, I figured I might as well pick some up for future use.

To make the shipping worthwhile, I ordered 3 of the boards from DigiKey. Unfortunately they were on back-order, but less than a month later – I got my purchase in the mail:

A couple Texas Instruments MSP430/Launchpads.The 3rd I gave to my brother

Each box contains the Launchpad Development board, USB cable, pin headers, a crystal, and two MSP430 chips. The online wiki contains links to a couple IDEs for use in the Windows world – and Hack A Day has a good writeup on using the msp430-gcc compiler in the Linux world.

Acting like an impatient kid, I put schoolwork and other projects on hold for a couple days to dig into the Launchpad. First mission – the basic “RC Car modification”.

Only modify full sized Police Cars.

To disassemble a real police car, first remove a couple tires.

After mapping out the pins on the H-Bridge of the RC Car, I decided to do something I’ve always wanted to do – buy a Radio Shack Electronics Learning Lab and brush up on what little I know.

The RadioShack Electronics Learning Lab. This circuit is a pacemaker for the human heart (from page 32)

This is something I should have had by the time I was in high-school – if not by 5th grade. The Electronics Learning lab contains 2 lab manuals (one covering Basic Electronics, the other Digital Logic), about 20 ICs, a handful of transistors, numerous resistors and capacitors, and jumper wires (among a few other things). The console itself has numerous built in potentiometers, LEDs, a relay, a transformer, a buzzer, speaker, DPDT switch, and many other components ready to use. Each of the built-in components uses springs to make contact. There’s also a built in breadboard.

The two included lab manuals.

Each lab manual contains background information on each of the various components, as well as example circuits that you can build. Each circuit contains a standard schematic, step-by-step instructions, as well as a checklist to help the user build an error-free circuit. The explanations on how many of the circuits work are lacking – requiring the user to do additional searching and reading to get a full understanding of what’s going on. (But seriously, that’s how it should be: You buy the lab to learn, doing additional reading should be encouraged)

If you look closely, you'll see an acrostic poem.

Which circuits you build and in what order you build them is entirely up to the user. Each manual is structured so that learning is incremental: You learn how resistors work, you learn how capacitors work, you learn many different ways in which resistors and capacitors can work together.

My goal is to work through each book page by page (I’m only just over halfway through manual 1). Each manual is about 96 pages long so this can easily be done in a long weekend (or a few in my case).

I really wish my high-school had offered an electronics class. My limited knowledge had been enough to get me by for basic projects, but the labs I’ve done so far have really bolstered what I know. And at $70, this is a real deal.

Next up: After completing all the labs, go back to the RC Car modifications and explore the possibilities of a TI Launchpad.

I’ve really been enjoying the feedback on the free wireless access from my neighbors. As always, everytime I start a new hobby, I end up with a handful of new toys – and I got one just today:

The Wi-Spy 2.4x

The Wi-Spy 2.4x is a portable USB spectrum analyzer for the 2.4Ghz range (They have other models that cover 900mhz and 2.4/5Ghz). The 2.4x model includes an external antenna (SMA), whereas the 2.4i has an internal antenna only.

The Accompanying Chanalyzer software

With the use of a wireless card, one can overlay SSID’s atop the channels in the Topographical  graph and determine what radiation  belongs to which Access Point. The bottom graph (Planar view) allows one to view which Zigbee channel, wifi channel, or frequency range is most in use.

There’s a similar device on the market which is substantially cheaper, the Airview,  manufactured by Ubiquiti Networks (~$39 vs. ~$160), but from what I’ve seen, the Chanalyzer sofware in use with the Wi-Spy appears to have more features (the ability to record your captures, the ability to overlay RF “fingerprints” of various devices atop your captures), etc. The Airview software is written in Java (Read:  supported in Linux), whereas Chanalyzer is written in .NET (good luck with that one under WINE).

There are Linux tools for use with the Wi-Spy (Spectrum-Tools) which I can defnitely appreciate,  but again the recording/playback and fingerprinting along with SSID overlays really make Chanalyzer nice. (For the record, you can actually record the data using one of the tools in the Spectrum Tools suite… I don’t believe you can playback easily though)

Spectrum Tools: from the author of Kismet

I’m supposed to be working on a number of other things at the moment (studying for an exam being the major item on my to-do list) so unfortunately this post is more of a “guess what I just got” as opposed to a “look at what this can do”.  In the next few weeks, I plan on picking up an AirView also, and will provide a side-by-side comparison of the two.

In the meantime, check out this video advertising the Wi-Spy, and if you have any experience, recommendations or thoughts on it or the AirView – hit me up in the comments.

I’ve done quite a bit in the past few months with the neighborhood wireless project.

First off, I’ve moved everything from the Linksys WRT-54GTM devices to an Engenius EOC-2610. The system Atheros AR2315 based. (More pictures here)

An Engenious Naked. Totally hot.

The firmware is still OpenWRT kamikazee (I dumped DD-WRT a while ago on the 54G’s), with a patched version of the NoDogSplash captive portal  (to prevent the graceful exit when a null token is submitted, also to support a “Magic token”, since I don’t truly care about it being the same one issued during the pre-authentication phase).

The only lingering issue relates to my version of the hardware not handling a reboot, which is a known issue apparently related to the kernel’s watchdog driver. There’s already a patch out there, and I plan on implementing it soon. (At present, an “init 6″ will simply cause the unit to stop responding – requiring an actual powercycling) The good news is that I’ve never had to actually reboot the device for any reason.

Other installed packages include NProbe for Netflow export and  SNMP for monitoring/graphing purposes. In all honesty, the build is rather simple but effective. It’s also waterproof – the Engenius EOC-2610 is built for outdoor use – complete with waterproof housing and PoE support (albeit based on the warnings on the PoE injector, I don’t believe it’s 802.3a[ft] compatible)

As of this morning, we’re up to 13 users in the neighborhood. Shortly, I’ll be lighting up the Eastern portion of the neighborhood, which will provide access to a larger number of users.

Oh, and there’s a new look to the portal:

The new Midtown WiFi Theme

The new look is a slight modification to the Lorea Hub Theme, with additional imagery from istockphoto.com.

As if I don’t have enough going on already (school, lab, work, numerous hobby projects, cigars and Tom Waits), I’ve begun modifications of one of those small radio-controlled helicopters using a PIC16f628A microcontroller.

I’ve done something similar with an radio-controlled car in the past (very basic “go forward, turn, go forward, back up” stuff though), but that was 5+ years ago.  My goal this time is to code a program allowing the helicopter to lift-off, turn in search of the brightest source of light, and follow it. (Have you ever seen Sea-Monkeys go crazy over a flashlight? That’s my goal here, but with a helicopter)

A lot has changed in 5 years.  The last time I worked on a project like this (as basic as it really is), I was using a PIC IDE on Windows 2000 (something I’ve since misplaced). I was also using the PIC16f84A then, a chip that’s since become less than favorable (less memory, needs an external oscillator)

Having migrated entirely to the Linux operating system (aside from a dual-boot laptop for school), I went in search of a decent C compiler and simulator – and I really lucked out.  SDCC and GPSIM were exactly what I needed. (I have to give Micah Carrick a big thanks for his article that steered me in this direction)

My Desktop running GPSim and some test code

SDCC is simply a Small Device targetted C compiler, so I’m not going to go into in depth  here (see Micah’s great article above).  BUT I did have a major issue getting it set up initially:

The problem I experienced with SDCC was that the Gentoo Portage distributed version is 2.5.6 (as of March 2010).  Unfortunately, memory locations for individual pins on PORTA and PORTB on the PIC16f628A aren’t defined in the header files in 2.5.6. Usually, one can access them via RB[0-7], etc… So my advice is this – use the subversion distributed version of SDCC (which is presently 2.9.7)

My second issue getting set up  was with GPSIM. I’ve not had a chance to delve into the reasons, but for some unknown reason the version 0.23.0 and 0.24.0 wouldn’t play nice with any controller I tried:

gpsim -p16f627 -c testcode.stc

gpsim – the GNUPIC simulator
version: Release 0.23.0

type help for help
**gpsim> SimulationMode:51
FIXME gui_breadboard.cc Build
WARNING: command line processor named “16f627″ is being ignored
since the .cod file specifies the processor
WARNING: Ignoring the hex file “testcode.asm”
since the .cod file specifies the hex code
RRR gui_breadboard.cc:createLabel p16f627 11 42
Disabling WDT
FIXME: HLL files are not supported at the moment
**gpsim> running…
attempt write to invalid file register
address 0x10a, value 0×1
could not decode trace type: 0×0
0×0000000000000066 p16f627 0x00FC 0x008A movwf pclath
Read: 0×0001 from W
Invalid Trace entry: 0×0

After flailing around trying to make gpsim happy, I finally downgraded to 0.22.0, finding that I had no issues with it.

GPSIM has some nice features – stopwatch, available breakpoints,  simulated oscilloscope probes, the ability to lay out basic logic circuits, simulated LEDs and pushbuttons, etc

Simulated Scope Probes

Ok, so now I’m all set to develop. I’ll post videos of the helicopter before and after modifications, as well as a before and after test-flight shortly.

Update: 3/28/2010:

Rob Pearce has infomed me that the issue above (regarding 0.2[34].0) has been now been fixed in subversion.  While writing this article on the road, perusing the bugtracker (or reporting the bug) somehow slipped my mind – my bad. Kudos for the quick response time (once someone actually bothered to report it).

In any event, this article is meant to point out an excellent tool. Have a look at it.

I’ve been planning on building an APRS beacon into my car for some time, initially contemplating using a WebPadDT + XASTIR to do the work, but that idea quickly posed an issue – the WebPad was too big to reasonably it in the car with another passenger (at least in my car).

Yes, I’m well aware that APRS is not really meant as a vehicle tracking device, and in many circles it’s frowned upon.

I’ve enjoyed working with PIC microcontrollers since I was first introduced to the 16f84A years ago. But in all honestly, I’ve not done more than “blinky lights” and very basic modifications to an RC car with them. (Take a look at a great article to get started working with PICs)

Byonics has a cool kit – the Tiny Track3+. Figuring I’d use it as a chance to exercise my soldering skills (which need a bit of work), and liking the fact that I wouldn’t have to hunt for each individual component on my own, I picked one up (with GPS unit).

The project build steps are extremely well documented. Literally, every step along the way is fully explained along with color images in the downloadable PDF. Build time takes under 1 hour (actually closer to 30 minutes, although I incorrectly soldered the female DB9 connector to J2 and had to waste time de-soldering it).

Prior to installing the accompanying PIC16f628A chip, I made sure to back up the currently running software (these chips are dirt cheap, and I’m not entirely sure Byonics will just give me the software if I ever have to replace the chip) Looks like my old serial programmer still works (remember – the USB to serial adapters generally don’t put out enough voltage to program a chip, so make sure you have on-board serial):

Old serial PIC programmer

After backing up the code, I pop the chip into place on the TinyTracker, and voila -the finished product looks like this:

TinyTracker3+ Fully Assembled (I'm using Lysol in my coffee since I'm out of Half and Half)

The Byonics crew have also written software to configure the TinyTracker. Luckily it runs under WINE so I didn’t have to reboot. To configure, power the J1 DB9 connector with a 9volt battery.

TinyTracker3+ in it's case, being configured serially

And run the configuration program (again, it’s fairly well documented in the manual):

After being hung-up in customs (and a brutal snowstorm), I finally got the radio component of my APRS system – the FD-150A (It took almost a month to get here from Hong Kong)

The output voltage  on the FD-150 battery is ~6.25V, too low to power the TinyTracker3 (which requires 7+V). A voltage multiplier would probably fix that, but my overall goal is to encase all components in a NEMA style box, powering it off the car.  So for the rest of the testing period, I’m using an external power-supply.

Hopefully in the next few weeks, I’ll have time to finish the entire setup. Keep checking back, I’ll post updates when I can.