A new weapon in the war against Bugs and Photino Birds

Keil μVision 4 Debugger/Simulator. This is a small part of the larger (450MB, really guys?) μVision suite, but the only part I care about. With it I was able to debug my Task code, which is interesting given that I did not write or compile my code in μVision. Get the program and install it (it installs fine under Wine on Linux) and then bring up any example project, compile it, and get into debug mode. Then, right-click the disassembly window and select "Load Hex or Object File...". Now select the master .elf file that was compiled with GnuARM. It will load, and the simulated processor will be reset, so it starts at location 0 (of your code, apparently it skips the ISP).

And now for a word (or thousand) about tasks...

There's a little black spot on the sun today...

I saw it! I owed it to Captain Cook to make my best effort to see the transit (insert 100+ years, 2117, etc) and I did.

OK, I didn't directly see it, but I did the next best thing, see it with a projection system. I had my binoculars pointed straight at the sun, then held up a white (so as to see it) box (so as to not blow around in the wind) as a screen. I used the shadow of the binocs to aim, and then used the focusing knob to, well, focus. I have previously seen sunspots with this setup, but it was too cloudy to really see them today.

Speaking of which, today is a partly cloudy day here at St Kwan's, and I was clouded out of seeing ingress. These images are from about 00:10 UTC 6 Jun 2012.

SDHC USB Bootloader and Logging Firmware work!

I have the old Logomatic 2.3 working with the new SDHC USB bootloader. At first, FAT32 was not enabled. because the mass storage part doesn't even need a filesystem driver, the host takes care of it. However, In order to find and install FW.SFE, the bootloader needs FAT32 however, so this version has it.

Also, the old Logomatic firmware has been updated the minimum amount to use SDHC and FAT32.

All of this works for me, and generates log files, but it sometimes takes a LONG time to mount over USB (sometimes a minute or more).

So now I have put my code where my mouth is.
USB_SDHC_Bootloader.zip
Logomatic_SDHC_FAT32.zip

More on SDHC

So here's the problem. There are in fact two SD card drivers in the Logomatic firmware. Hey, by the engineering method, anything that works is good, and the Logomatic code works, but it's not great code. There are entire sections that are included but not used, like the USB driver in the main logging firmware. Now we have two pieces of code to do the same thing -- access the SD card. There is Roland Riegel's code used by rootdir.c and used by both the bootloader and main code to read and write the card, and there is the code used by the USB driver, which is entirely separate and entirely unready to do SDHC.

So, I am going to update the USB driver to use Roland's code. This just means mapping what the code is doing now to the various parts of sd_raw.c . Piece of cake, probably. We'll see.

Anyway, once this is done, I'll post a message about it on the Sparkfun forums, direct them here, and get literally some readers on this blog, rather than just myself like I get now.

No bragging until I can put my code where my mouth is.

By the way: I am doing all of this development on the Loginator 1.1, so the SD card slot and USB port work. Yay for me!

The LPC1768

It's sooooo close to being awesome. Cortex M3 with all the improvements (don't be scared by the word Harvard, the program-visible memory map is flat) and full pin compatibility with the 2368.

Almost.

This part has no SD/MMC port. Still, with SPI and DMA, maybe we don't need SD/MMC. The part is otherwise pin-compatible with the 2368, so the 2368 breakout board should work with a 1768 also.

I am going to get a 2368 talking to an SD card and sensor before I try messing around with the 1768.

Loginator2148 v1.1 is assembled

I have every confidence that the board is correct. I have tested that the known bugs in the old board have been eradicated. I have every confidence that the parts are properly placed and that all joints are good. I have tested the power supply, charge circuit, and lights.

So why am I not more confident in this board?

Is it live...

...or is it Memorex?

All of the switches and the battery terminal were partially melted/burned with hot air. The power switch is especially bad. Everything seems to work, though. It's just ugly. Next time, we bake the plastic parts. Maybe we bake everything. Maybe we salvage this board by lifting all the burned parts, replacing them, and baking it. Maybe we just don't make this board again. I would kinda like to get out of the 2148 business and into the 2368 business.

Update: The thing is alive, the Arduino terminal just doesn't know how to talk to it. I sent ? and saw 'Synchronized' on the logic analyzer (great device, I'll write a review some day). It just didn't show up in the serial terminal. This means that the controller is alive enough to communicate over serial, which means that the crystal and decoupling caps are on and the power is properly hooked up. The thing was running on battery when I tested this, so the whole battery part works too. Wow, I guess a lot is tested just with "Synchronized".

I wish these pictures showed the glorious royal purple and gold of the boards.

This is a NON-FLIGHT configuration. Not that the Loginator is ever intended to fly, anyway. This is just so that I can learn how to talk to the sensors and get the IMUinator working

11DoF is working

I finally put together an 11DoF. All sensors are on board, but I decided to forgo the OR gates until I see that I need them. That means that both solder bridges on the back are closed, and the board is subject to Analog silliness if it decides to show its head.

Here we have the design...

And here is the physical implementation. Is reality ever as clean as design?

All of these sensors work, in that the I2C compass and baro/temp sensor actually work, and the SPI accel and gyro respond to SPI commands and return their proper chip IDs. I haven't tested full functionality on those guys yet.

So, do I start making and selling these things for $50 each? Or do I just release the design and say "have at it" yourself?

If the latter, here are the files:

11DoF Schematic (Eagle 6.x)
11DoF Board


Next version? There's always a next version. Both STMicro (makers of the L3G4200D) and Invensense (makers of the ITG3200 that I gave a glowing review to) have 6DoF sensors, and one of them even makes a 9DoF sensor with a magnetometer in the same chip as the accelerometer and gyro. The problem is that these parts are not yet available from Digikey, and therefore not really available at all. Also, the interfaces are ugly: Both parts have two SPI interfaces. The Invensense part has one for the gyro and one for the accelerometer, while the STMicro part has one for the gyro and one for the acc/compass. It is almost as if two devices are just crammed into the same case. I can cram together parts, in fact that's what the 11DoF board is. I want a 6/9DoF part to have a single SPI interface with a single chip select, and perhaps more importantly, I want the acc and gyro to sample at the same time and have one interrupt line.

Designing a large charlieplex

I saw a new cool way to design a charlieplex, one which is easy and obvious, even for an extremely large LED matrix. This was buried in a post below where I blather on about my own problems, so I broke it out into a post that Google is more likely to find.

Details Matter...

...and they seem to cost about $50 each.

The boards for Precision 1.1 arrived on Saturday, part of an ocean of purple boards. I had previously ordered all the electronics for it, so I was all ready to assemble it, except...

1. In Eagle, I copied the crystal from some other source, and it was still labelled 12MHz like it was from some LPC2148 board. Before, I had manually ordered parts, but this time I used add-digikey.ulp, which dutifully noted that the part was 12MHz and the same case as the Logomatic crystals, so it ordered a 12MHz crystal and I missed it.
2. I had decided to use 91Ω resistors to try to solve the "extra lights" problem, but after having the clock set up, I decided that brightness was more important than extra lights, so I decided back to use 47Ω resistors like with Precision 1.0

This wasn't that much of a problem, as I had a complete but unusable board from a previous forgotten detail, so I could lift the 47Ω packs and 16MHz crystal from it, without ruining the working front board I already had. This avoids the "one brief shining moment" problem, when you have something that kinda works, but you want to improve it and destroy it in the process. I still have a working Precision 1.0 front board.

Now for today's $50 detail. The primary features of Precision 1.1 are the green wire fixes from last time and a port for the UP501 GPS unit in place of the EM406 port from 1.0. Well, I was planning on using the back board from Precision 1.0 as-is, since it already has $50 of blue and green lights on it. However, it has the old GPS port on it, with certain pins grounded and certain pins connected to VCC - the wrong pins, as it turns out. One of the new 3.3V pins matches one of the old VCC pins, so there is a direct 1.7V short, which I'm surprised didn't completely burn out the FT232. Maybe it did partially burn it out, but there is no way to check right now. The new PPS pin is grounded on the old board, in a flood of polygon that is impossible to isolate. Even though the back board has no electronics on it, it still interferes. This is the $50 detail. Now I have to order a new set of lights. Or... I can lift the lights off of the old board, but that would create a brief shining moment problem. So, it will be new lights.

Program 66

Or: Chauffeur or Pilot?

I just got finished reading Digital Apollo, where one of the major themes is how much automation is the right amount. The author refer to the two poles as "Chauffeur", someone who just wants to get a job done, and "Airman" (I will say "pilot" from here on out) who flies for the joy of flying and personally controls a complicated machine. This debate can be easily seen in other machines, as well. For instance, do you like a manual or automatic transmission?

Are you worthy of the term "driver" if your idea of driving is getting on I-80, turning on cruise control, and doing only what is necessary to stay on the road and not hit anyone? Would you like to turn those tasks over to your car as well?

On the other hand, do you love choosing the exact shift points to get the most out of your car? Do you want to be able to do things in a manual that you just can't do in an auto, like a push start or engine braking? Why don't you use a manual choke as well as a manual transmission? Is there a manual timing adjust in your car? Fuel injector control? Theoretically, a manual transmission can be more efficient than an auto, but is it really more efficient in your hands?

I for one am squarely in the automation camp. I drive because I want to get somewhere. I program for the fun of it, the way that some people drive for the fun of it. After being around and fascinated by the aerospace business over my whole life, I finally discovered that I am not a pilot. I like the idea of space travel, and I wish I could do it, but I'm not one who likes to control my machines that much.

Digital Apollo is mostly about the struggle between the computer and software engineers, who just wanted to get the job done, and the astronauts who wanted to actually fly in space, rather than just ride. In the late 50's and early 60's, it was becoming increasingly difficult to justify human controllers. For instance, no US rocket has ever been manually flown from the ground into orbit. Ascent guidance was developed for ballistic missiles which obviously couldn't carry a pilot, and this guidance was adapted to launch vehicles targeting orbit instead of targeting flaming death on our enemies.

Even if a human was to control a rocket, they would not be able to navigate or guide it. Navigation is done by the inertial measurement unit (IMU) and some software to integrate its measurements. Guidance is done by some complicated formulas which take the current and target state vector as inputs and produce a vector to align the thrust to. All that a human would be able to do is point the rocket in the direction that the automatic system already calculated.

All this brings us to the most complicated maneuver ever attempted in space, deorbit and landing on an airless world at a particular target in a safe spot. Surveyor performed landings, but had an error ellipse on the order of tens of miles, and it landed directly from an impact orbit. Apollo was a complicated coordination of humans and machines, each doing what they were best at. The program was broken up into several major modes:

• P63 was called Braking, and lasted from before powered descent initiation (PDI) to the "high gate", where the landing site came into view. P63 was basically full automatic, where the only job of the astronauts was monitoring. Its job was to get from orbital speed, about 1.8km/s, at about 16km altitude, to almost stopped, only 200m/s or so at 3km altitude, in the most fuel-efficient way possible, and without hitting the ground. Calculus of Variations provides a unique trajectory, which the guidance system attempted to follow. It carried an approximation of this trajectory, perhaps similar to the powered explicit guidance routine. Early in the descent, the surface of the moon was too far out of range for the landing radar, so the guidance source was the inertial platform. After descending lower, the radar became active and the Kalman filter navigation system used the radar and inertial observations to produce its estimate. The guidance equations took the Kalman filter output as its estimate of where the vehicle is, and calculated the correct descent engine pointing to fly the best approximation of the optimum trajectory from the current location to the high gate.
• P64 was the visual approach. At this point, the lander tipped over so that the commander could see the landing site through the windows. Before this point, the vehicle was pointed almost level, with the standing astronauts' feet towards the direction of travel and faces straight up into space. P64 was targeted to a low gate point, and flew the best trajectory it could, with the constraint that the commander could see it through the window. It also calculated where it would land if allowed to land automatically, calculated where in the window that would be, and displayed the Landing Point Designator (LPD) angle, which the lunar module pilot read aloud. The commander would use the angle scale engraved on the windows to see where the vehicle thought it was going to land, and could change this point with the rotational controller. If the commander did so, the program would recalculate the location of the low gate, so that guidance would fly to the new point instead of the old. This is an example of cooperation between manual and automatic processes. The commander used his senses, particularly vision, to evaluate the landing site. The machine can't see at all, it is basically a blind machine with a radar as a white cane. The human chooses and evaluates a landing site, and the machine figures out the best way to get there.
• P65 was the automatic landing program. After passing low gate, the program nulled the horizontal speed and followed an altitude versus vertical speed profile to land. At this point, there was no targeting involved. The program was committed to the last LPD in P64, and just used the radar to measure altitude and run the vertical speed profile, and to measure horizontal speed to null it. No mission was ever landed with P65. During P64, the commander always switched to...
• P66, altitude rate control. In this mode, the commander chose a descent rate, and changed it by clicking a switch up or down. He also chose the attitude by using the rotational controller. The machine calculated whatever thrust was necessary to hit the commanded descent rate, controlled the descent engine throttle, and calculated but did not control horizontal velocity. It displayed that on the cross pointers on the commander's instrument panel, and left it up to the commander to control horizontal rate. This is almost always referred to as the commander taking manual control, but as we can see, again there is a strong automatic assist, the machine doing the calculating, the human doing the guidance. Horizontal speed and position was controlled similar to a helicopter, by pitching the correct direction to use some of your thrust to add or subtract to your horizontal speed. It was up to the commander to make sure that by the time the vehicle was on the ground, its vertical speed was slow enough and its horizontal speed was close to zero. All Apollo missions were landed with P66. There was also...
• P67, Full manual. The machine used the radar to calculate altitude, vertical and horizontal speed, and so forth, but only to display them. The commander had full control of the throttle and attitude. This mode was never used.
• Actual attitude control, even in the semi-manual and full manual modes, was provided by the digital autopilot, in what we would now call fly-by-wire. This program figured out which RCS jets to fire, based on inputs. The autopilot itself could be driven by the guidance system, which calculated the best way to get to a chosen attitude (KALCMANU routine) and drove the jets that way. It could go on semi-automatic Rate Command, where when the commander moved the rotational controller, the machine would figure out the axis the commander wanted, then use the jets to get the vehicle rotating around that axis at a given rate. As the commander held the rotational controller, the vehicle would continue to rotate, with the jets quiet, since the vehicle is now up to speed. When the commander released the controller back to center, the digital autopilot would stop the vehicle rotation. There was also an almost full manual mode, where the jets were on as long as the controller was moved. This is most similar to the native Orbiter mode.

Similarly, the Space Shuttle guidance system could do deorbit braking, entry, descent, and landing all the way to touchdown, all on automatic. The only thing it couldn't do automatically was lower the landing gear. This was for safety so that the gear was not lowered in space, since they could not be raised once lowered.

The shuttle was flown in autopilot through 134 of 135 entries, but 0 of 135 landings. The commander and pilot always flew the final approach, from near or in the HAC to touchdown.

The automatic entries are a little bit surprising, as in Orbiter, I like to fly space shuttle entries on almost full manual, and I don't even like to fly. Skidding across the atmosphere at mach 25, 40deg nose up and 80deg banked, may be some of the most fun and exciting flight possible. I use the Glideslope MFD to see the reentry corridor, but stay on it myself. I'm not just flying to pre-calculated needles either, like I would in an ascent. I am actually doing what pilots do - flying by the seat of my pants.

There was a proposal to do a fully automatic unmanned landing of the lunar module, but among other things the astronauts hated it. I think the same thing happened with the shuttle. If the full auto system is proven, then why do we need pilots?

Automation is your friend, not your master. Besides, if you are the one building the automation, then it is the friend you built. I have heard it said that you can program a computer to dance and Irish jig, but only if you know how to dance an Irish jig. I would add further that while you have to know how to do it, you don't have to be able to do it yourself.

If you are buying your own car or plane, for the fun of driving or flying it, be my guest and have it however manual or automatic you want. If you are flying for me, whether I am a passenger on the aircraft with you or just a taxpayer paying for your ride, you are obligated to do whatever will maximize the chance of mission success. If that's full manual, so be it. If full auto, so be it. Some combination? Choose the right combination. Don't be like some astronauts who thought that they were destined to fly a lunar module and wanted as little automation as possible, to prove how macho they were as pilots. You are there in support of me, the science-consuming public. We did not spend billions of dollars so that you could fly. We spent it so that we would get the mission results.

Loginator2368

By the time you finish one invention, you're preoccupied with your next.
--Dee Dee to her brother Dexter

That's me. I haven't finished the old Loginator, even though I respun the board. I am now fascinated by the LPC2368 as described below. The Loginator2368 is my increasingly less compatible Logomatic clone/extension. This one has the same form factor as the Logomatic, and same 20 pins on the one edge, but the similarity ends there. The LPC2368 is vastly superior at recording digital events, and vastly inferior at recording analog ones. It also has six PWM outputs and a port for the 11DoF, so it is a good candidate for a robot brain, if I were interested in making those any more.

Goodbye, AVC

A couple of days ago, I formally cancelled my plans to compete in this year's AVC. I was on backorder, and hadn't even started my robot yet.

So, I guess I can spill my secret plan now. If anyone wants to run with it, fine. I don't even need credit.

I was going to build a biped. The design is based on the little wind-up ducks you can get that waddle along on two feet. The feet are designed such that the device is stable without active balancing.

My idea was to use a four-bar parallelogram linkage, with two stepper motors to make sure they always turned in sync. A third motor was at the knee of one of the legs, to do steering.

It is not designed for speed, but for coolness. I didn't want to do another robot built into an RC car. That has been done to death, and I couldn't do it last time anyway.

LPC2368

I have a new favorite microcontroller: the LPC2368. It programs similar to the LPC2148 but is much more "digital" and much less "analog". It has four UARTs, three SPI ports, three I2C ports, something called I2S, two CAN ports (maybe I can talk to my car, or more like listen to it), two USBs, an ethernet port(!) and so on and so on. One big deal is a hardware SD/MMC port. My previous new love was the 2468, but that one has 208 pins and probably wouldn't fit on the Logomatic footprint, much less the stick IMUinator.

This guy has exactly 100 pins. The one big feature that the 2368 lacks is an external memory interface. That and a lot more GPIO pins. For two main reasons, the 2368 is more convenient to work with than the 2148:

1. More pins means less overlap between functions. Several of the peripherals have dedicated pins (Ethernet, one I2C) so there is no problem with overlap. PWM and UART still overlap, but there are enough pins and two choices for each overlap that you can use all 6 PWMs and all of the UARTS.
2. Fewer analog inputs, so those don't take as many pins.

The last is the only place where a 2148 is superior. The '2368 has six A/D inputs, but I use one of them for battery voltage, one for current, one for reference, and one is covered up by the USB Vbus input, leaving only two for use. You can sacrifice the voltage reference to get another channel, and I should think about doing the same for battery level and current sensing. It may also be possible to use another plain GPIO pin as Vbus, freeing up another A/D.

All the sensors I plan on using now and in the future are digital anyway, so to me, losing A/D is no big loss.

Also, all the peripherals except I2C have DMA, which I think means you can hand them a big block of data (or tell them to listen for a big block of data) and then the peripheral will take care of itself, while the core continues its programs. No more busy waits for the SD card.

I am working on a Loginator2368 which is increasingly less pin-compatible with the Loginator, but still roughly the same shape and size. Who knows if it can be made to fit on a Stick IMUinator?

Un-Drat!

I lifted, or burned up and buried in burnt rosin is more like, one of the pads that I needed to connect one of the short green wires to, across U601, so that the USB could listen to the ATmega. Double drat. I NEED that connection.

Well, I start doing an inventory in my mind... I have an extra copy of this board, enough of almost all the parts I need, and a hot air rework to pull parts off of the old board. I have everything I need to build a new copy of the top board (with all the logic on it, not the LEDs yet). The only thing I lack is another FT232, and that is easy enough to get from Sparkfun. I don't buy them out this time (and they restocked their ATmega's the same day).

A little of this, a smidgen of that, find the old parts template, and boom. No, it didn't explode, it in fact worked after I changed the software to use the right lines.

Here's what I have learned so far about surface mount soldering:

1. It is possible! Really, you can do it.
2. It's harder than it looks.

My process is as follows. First, design the board, send the .brd file to Laen and send a gerber of the cream layer to Pololu. Yes, you want a stencil. Yes, even for one board. Also make sure you have all the electronics you are going to use.

After the parts arrive, including the components you are going to place, gather everything up. I like to make two sets of paper documents. One is a placement sheet, showing where each component goes. I make Eagle make me an .svg file, then suck it into Inkscape. A bit of cleanup, then highlight all of one kind of component, say all the 100nF 0402 capacitors. Then, make a copy of the drawing, lowlight the highlighted parts from the previous step, then highlight the parts from the next step. There were 24 steps on the Loginator, and each part went from gray to white to black in turn, until all the parts were black.

The other one I do by hand with a pencil. I draw a grid on a clean sheet paper, with the same number of cells as there are steps above. I then get the right number of each component from my stores, and put them in the right square for the step.

For stores, I have one of those plastic boxes with lots of little drawers. It has 6 columns and 10 rows, for a total of 60. Each drawer has a divider, so I could store up to 120 different kinds of parts. I number the drawers from 0 to 59, and label the front half A and the back half B. I have a spreadsheet inventory, but it is gradually going out of sync, mostly as I use parts.

Anyway, I number the boxes, and write the value, package, schematic part number, and drawer, in the corners of each box. The drawer is so that I know where to get another 0402 capacitor after one springs out of my tweezers on a magical voyage through space and time, never to be seen again.

After all the parts are out, it is time to stencil. Pololu stencils come as an 8.5x11 sheet of plastic. DO NOT cut the stencil! Big is OK. I made a mistake and cut the middle part out of the Precision stencil. Small sheets of plastic tend to curl and lift off the board, making things hard to work with.

Now, a tip from the guys at Sparkfun. Tape a couple of old circuit boards to your bench, such that your new board is framed and immobilized. Two is usually enough for a rectangle, but for the circular board for Precision, I used three rectangles. Now CAREFULLY lay your non-cut stencil on the board. I'm right handed, so I securely hold the stencil down with my left hand. Even with a transparent plastic stencil, it is easy to see when the stencil is perfectly lined up. Make sure that the stencil is lined up with the pads on diagonally opposite corners simultaneously. Also make sure that you are looking straight down on the stencil. Stand up if you have to.

I use a square-nose X-acto blade as my squeegee. It's about half an inch wide. I get my soldering paste in a syringe, but had no luck with the tips, so I just uncork the syringe and squeeze some out on one end of the stencil. Careful here, solder paste is so viscous that it keeps coming out for a little while after you stop squeezing it. Now I use the X-acto blade to spread the paste out. Press hard enough that most of the paste is carried along, and the stencil is mostly clean and transparent after the blade passes. Make sure that all the holes are filled. Sometimes they are easy to miss, and sometimes they are so big that one pass doesn't fill the holes. Don't be afraid to make multiple passes.

Now use your right hand to pull the stencil tight. This will lift it straight up off the board. Lift with your right hand until you are sure you are well clear of the board. Only then can you move your left hand. If everything went well, you should have a nice little square box of solder paste sitting on top of each pad. If not so well, use some rubbing alcohol to clean the board and do it again. The solder paste doesn't have to be exactly in the middle of each pad, but it isn't good to have a bridge either.

Now, use some sharp tweezers to place each part. For me, especially on the small 0402 parts, they invariably end up sticking to the tweezers, and I use this to my advantage. I can pick up a part, then let the tweezer tips separate. The part will stick to one and not fall off, so I use just that tip. I place the part all the way down, so that the solder paste sticks more to the part and pulls it off my tweezers.

For larger parts, I usually drop them from about 1mm up, then gently nudge the part as needed for accuracy. Precision counts! Align things up as well as you can, to avoid bridges.

Once all the parts are placed, it's time to bake. I am using a convection toaster oven which can get to 230°C (425°F) without turning on the broiler. That isn't really as hot as I wanted, but the EP256 solder paste I have has a peak of 210-225°C, so it's probably alright. I got convection because I really want to do the soldering with hot air, not direct radiation. Hot air will get heat sinks as hot as the boards, maybe hotter.

This is the exact procedure I use. Once a board is stuffed, it is put on top of the small cookie sheet that came with the oven. I put the rack in the middle, and put the board as close to the convection fan as I can. The temperature dial is set at 450°F and the timer is set to "Stay on" which turns the oven on.  So, I watch for the solder to melt, which is a very visible and sharp change from dull gray to quicksilver. I then count to 20, then open the door and turn the oven off. This consistently takes 5 minutes 20 seconds.

Now it's off to the microscope to check all the connections visually. This isn't conclusive, it finds bridges but not disconnects. So, I use the schematic and board layout to check continuity between each of the 32 ATmega pins and where they are supposed to be going. All the charlieplex pins should have 47 ohms from the ATmega to the Q signals, since they are going through one current limiting resistors.

Now for the green wires. One from D11 to P01, to the corner of one of the resistor packs. That is a very small target to solder, so I have to use the stiffness of the wire to hold it in the right spot (basically use the wire itself as the third hand to hold it). D13 goes to P16, also a corner. On this second copy, the 10k resistor pack didn't solder on one whole side, and I lifted the whole component (but not any pads) trying to fix it, so I put in PTH resistors between the through-holes on the side. Now that I think about it, it is good that part did lift, since D11 and D13 were being pulled up by those resistors. Only reset and D12 need to be pulled up now.

Do the same Arduino bootloader as last time. Oh drat, the red light doesn't blink. Not worth fixing, I probably got that one backwards.
I got the green wire soldered to the corner resistor P01... once. It was looking awful fragile and hanging-by-a-thread-like, so I smothered it with hot glue to hold it in place. Guess what... So, now I have two 100Ohm resistors twisted together to approximate 47 ohms, soldered directly from D11 to Q01. P16 is still hanging on, under it's blob of glue. It's ugly, and definitely does not have the Ipod-like  polish I am looking for, but it works, and confirms that the next spin of the board will work.


Once the software is ready to use the new pins, the charlieplex works! I think that these 17 60 lights excercise all of the signals, so everything is great! The little out-of-turn pulses I think will go away as I install more lights and complete the Charlieplex.

Drat!!!

Lights 4 and 5 on the back of the second board (where I am installing the blue lights) won't light. As it happens, neither will any of 54-59, but we'll save that part of the story for later.

I remember the solder bridge between two pins, and one of those pins, A7, is involved with the lights that don't work. So, we carefully measure pin A7 and conclude that no matter how we program it, it acts like a high impedance. The natural conclusion is that it is burned out. So, run to Sparkfun, buy their last three ATmega328s, and a hot air rework station to pull the old chip. Carefully remove the old chip, taking care not to scorch the white paint on the board or blow away any of the passive components. When the chip comes off, it comes off great. Put in a new chip, verrrry carefully check continuity between each pin to make sure there are no bridges or missed joints. Fix a couple of missed joints. Guess what. The board acts exactly as it did.

So, that theory is shot. I might have burned out pins on this chip, but exactly the same pins? I think not. Now time to gather more evidence for another theory. Write up a program that listens for commands on the serial port and turns individual signals high or low, with the rest at high-Z. Signals 1 and 16 are both no good. What is going on?

The Arduino documentation says that you can use the analog input pins A0... as normal digital pins with the syntax pinMode(A0,OUTPUT); digitalWrite(A0,HI); etc. Which is in fact true, but only to a point. On an ATmega328, pins A6 and A7 are internally called ADC6 and ADC7, not PB...(ADC6) or anything like that. They are dedicated input pins. I had been planning (as in had a circut board made) to use A6 and A7 as Charlieplex lines 1 and 16. Guess which Charlieplex lines don't work... And guess which signals lights 4 and 5 (and 54-59) use...

I have no one to blame for this but myself. It was right on the Eagle schematic symbol the whole time that all the other A0... pins were secondary uses of GPIO pins, but A6 and A7 were only labeled as ADC. I guess the weird part is that the crystal inputs and reset line are alternate uses of GPIO lines, but A6 and A7 are not.

So, here's the plan. Lots of green wires, hot air, and razor blades, to hack D11 and D12 into P1 and P16. This will require giving up two multiplexers, which completely hashes my plan to use the GPS. At least this will let me test the charlieplex. Then, order 16 more blue lights, another FT232 and a correctly wired board which uses the crystal pins as two more digital outputs, allowing me to use D11 and D12 as multiplexer controllers on the next rev. NO getting a new board until all the green wires are fixed. Don't even touch Eagle until the last green wire is in place and CharlieTest works. Consider putting a LiPo battery power supply on the next board as well.

The moral of the story is keep working the problem until you find the problem, and don't guess. I have a nice new hot air rework station which works really well, and costs more than the LEDs combined. Oh well.

It's alive!

I finally invent something that works!
-- Dr Emmett Brown

Well, I have just built an honest to goodness Arduino, a round one connected to the most elaborate Charlieplex I have ever heard of... but no light on D13, so I can't even test it with the Hello World for microcontrollers, blinking a light. So, I used the ASCIITable example, to see if I can get code on the machine and have it run.

I made (at least) one mistake in the board design, and had to run what may be the shortest green wire ever. The FT232 datasheet clearly states that the TEST pin must be grounded, or the device will go into test mode and not show up on USB as expected. Well, I didn't ground TEST on the circuit board, and the device didn't work as expected. However, there is one bit of good news. The pin right next to it is ground. So, one bridge removed from the ATmega, and one added to the FT232, and we are ready to go.

First, load the ArduinoISP onto the Nano 3.0 I have.

Next, connect it to Project Precision, while the Nano is unplugged.

Neither of the Arduinos involved look like this

I cleverly broke out the six pins needed to do this on Precision, so it just needs a ribbon cable from a breadboard to the connector on Precision. I used individual jumper wires to connect the pins on the Nano by label to the correct wire in the ribbon cable.

Next, plug everything in. First carefully check that the ribbon is plugged in right, then plug the Nano into USB.

Now run the bootloader instructions. All four lights on the Nano will light up simultaneously (something I hadn't seen before) and blink like crazy (except the blue power light).

Board the device and bring it to life!

Finally, pull the plug on the Nano and plug in Precision. I thought about writing a literal "Hello World" program, but it was just easier to run the ASCIITable sketch.

ASCII Table ~ Character Map
!, dec: 33, hex: 21, oct: 41, bin: 100001
", dec: 34, hex: 22, oct: 42, bin: 100010
#, dec: 35, hex: 23, oct: 43, bin: 100011
$, dec: 36, hex: 24, oct: 44, bin: 100100
%, dec: 37, hex: 25, oct: 45, bin: 100101
&, dec: 38, hex: 26, oct: 46, bin: 100110
', dec: 39, hex: 27, oct: 47, bin: 100111
(, dec: 40, hex: 28, oct: 50, bin: 101000
), dec: 41, hex: 29, oct: 51, bin: 101001
*, dec: 42, hex: 2A, oct: 52, bin: 101010

and so on for all 94 printable characters.

I wasn't happy with the stencil and solder paste on the edge of the board, So, on to soldering 240 surface mount LEDs by hand!

Desktop Microscopy and Charlieplexing

One of the things I used to have to do with all my custom boards is take them into the lab at work. There they have a really nice optical microscope. This one looks at things instead of through things, so it is appropriate for electronics (funny that, being in an electronics lab). It doesn't have an eyepiece as much as it has a facepiece. The end you look through has a screen (pure optical, no electronics or cameras involved) about 5 inches wide. It gives you a stereo view with a single objective lens, because each of your eyes is looking through a different optical path in the same set of lenses.

I have been searching for something like that and finally restricted myself to something I could actually afford, a USB digital microscope. I ended up getting this microscope.

Here's what I got it for - finding solder bridges

Really short depth of field. Do you want the top of the chip in focus...

...or its leads?

The subject of this particular set of pictures is Project Precision. For about five years now I have had a design in the back of my mind for a digital handed clock with an hour hand, minute hand, second hand and third hand (1 third = 1/60 second. Yes, really. Isaac Newton used thirds in the Principia.). I had a design using all 7400 series logic, a PIC and less 7400 logic, but finally came across the concept of charlieplexing. With 16 pins, I can control 240 LEDs. Only one at a time can be on, but I only need four on at a time, so I can strobe through those quickly enough.

The thing is USB powered with no battery. It uses an ATmega328 as the core and an FT232 for USB-UART conversion. This basically makes it an Arduino. It has a port for a GPS receiver as well, and a couple of multiplexers to connect the ATmega, FT232, and GPS in any combination.

What I'm most proud of is the layering. I needed 60 LEDs for each hand, and with four hands, I needed the front and back of two boards. I figured out a way to make these boards identical, so when I got three copies, I had enough, and didn't have to order three copies of two different boards.

Charlieplexing involves pairs of LEDs, pointing in opposite directions. If you set one end of this combo to VCC and the other to ground, one of the pair will light. If you do it the other way, the other will light. What I have done is put half of each pair on one board, and the other half on the other board. All the LEDs on the board with the logic will point outward, while the LEDs on the other board will point inward. It's almost fate that 16 signals can control 240 LEDs, the exact number needed for four hands. 16 was the exact number of signals left on the ATmega after I accounted for the UART, clock, multiplexer controllers, etc.

Now for the tedious task of picking and placing 240 diodes... Fortunately I only have to do them 60 at a time.

No, I will not make one for you, not for any price. Well maybe, but it would have to be a lot. Better is to make one yourself.

Loginator and SDHC progress

1. All purely computing parts of the Loginator have now been tested. The power supply, USB, SD card slot, RGB light, and BOOT button all work. The charger circuit itself works, but I installed the LED backwards.
2. None of the analog parts have been tested. The current sensor was originally too hot to touch when the board was on. I tried to remove it, but in the process of hitting it with the soldering iron I must have fixed it, either that or it is burned out completely. Won't know until I test the analog part. I also realized that I should have gotten the 100V/V part instead of the 20V/V part. This is fixable without any board modification.
3. I may have made a foolish decision in relation to the RGB light: you can't run the lights as lights at the same time as you use the UART ports. Honestly it's not my fault. There are six PWM pins, but four of them are shared with TX and RX on the two UART ports, one is shared with the chip select pin for the card reader, and one is AD6. Right now I just use the blue and green lights, which overlap UART0. The red one overlaps TX on UART1.
4. I put into the Logomatic main firmware code some compiler switches so that it can be switched to be Loginator with one switch. This controls where the code looks for the lights and STOP button. With this switch set, the Sparkfun firmware now runs on the Loginator. It is even bug compatible - the first log file is LOF01.TXT. Next is to get Logomatic Kwan adapted the same way.
5. The SPI port with the SD card on it works, but I haven't tested the other SPI port or either of the I2C ports. I made a silly mistake and wired a pullup resistor to SCK1 (SPI) instead of SCL1 (I2C). I2C0 is fine, but the 11dof port uses SPI1 and I2C1, both of the affected busses. This is fixable with a green wire and a cut trace. The board modification does not require a new stencil.
6. I jumped in face first with the SDHC patch and got burned. The Logomatic code now no longer creates log files. I have seen through the serial port that the code is reading the configuration file, but cannot or will not write the log file. What I will do is back out the FAT32 part and just use the new SDHC part, to start with. Once the Logomatic with SDHC works, I will update the bootloader similarly, then actually try it with an SDHC card.
7. I have been looking at the LPC2468 chip. It has a purpose built SD port, DMA everywhere, USB, Ethernet if I ever wanted to use that, lots of cool new features. It's even cheaper than the LPC2148. The only problem is that it is a 208 pin chip, and I don't know if I will ever be able to solder down such a chip. Also its 28x28mm, so it may not even fit in the Logomatic board footprint. DMA is cool because it is like an arbitrary-length FIFO for every device, anywhere in memory I want it.

Memory Dumping

I mentioned below that I had developed a method of attaching all the source code to the firmware and then having that very firmware dump itself to its log. The problem is that it takes a long long time to do this. Partly this is due to the one per second packet dump rate, and partly because hexadecimal coding doubles the data size and adding packet headers adds yet more data.

So, here's what we do. For binary packets, we just do it. Dump 64 bytes at a time into a header with 8 bytes of overhead.

For NMEA packets, we do something smart. We use Base85 encoding. This is a method of encoding 4 bytes of arbitrary binary data with no restrictions, into 5 characters carefully chosen to all be printable. Base 85 is the smallest base where 5 symbols can be used to encode the 4Gi combinations possible from 4 bytes. There are 94 printable characters, so base85 will work. Base84 won't encode 4 bytes, and Base86 doesn't gain anything.

Postscript standard Ascii85 has a couple of cool features but also a couple of drawbacks. They just use the number calculated plus 33, so as to use characters from "!" to "u". If four consecutive zero characters are transmitted, these are compressed to a single "z". If four consecutive spaces are transmitted, this goes as a "y". There are several more characters that can be used, but one of the drawbacks are that "," and "*" are used. Comma is not a killer, but star is, since it marks the end of the packet.


Since there are 94 printable characters, we can decline to use certain characters like comma and star, to fit the NMEA structure. So, one thing to do is to switch out star, and might as well do comma as well. Star turns to "v" and comma turns to "w".

The compression mentioned above is nice, but since the LPC uses NAND flash, "empty" areas are actually filled with 0xFF, not 0x00. So, we will steal "x" for encoding 4 consecutive 0xff.

Another alternative is to just make an array of 85 characters in any order that we want. We have already given up Postscript compatibility, so why be constrained by it? The Wikipedia article mentioned above mentions RFC1924, which uses 0-9, A-Z, a-z and !#$%&()*+-;<=>?@^_`{|}~ in that order. It refrains from using ("',./:[]\) since those are harder to escape. We could choose one of those in place of star, and several other for compression.

SDHC - How do we test it?

1. Compile original Logomatic firmware and install it, and see that it runs on a fat16 SD
2. Compile original USB bootloader, install it, see that it runs on fat16 SD
3. Modify Logomatic firmware to use new library, see that it still runs on fat16 SD
4. Modify USB bootloader, install it, see that it runs on fat16 SD
5. Put an SDHC card in, see if it is visible over USB
6. Put a blink firmware on the SDHC and see if it is installed
7. Put Logomatic firmware back on the SDHC, install it, see if it runs
8. Success!