I’ve been investigating the calibration register of the RTC chip I used in the Binary Burst clock. While doing so, I discovered some design considerations that I didn’t manage to consider while laying out the board.

The RTC chip I’m using is from the MCP7941x family. I have the data sheet but it doesn’t show a recommended circuit. When doing some Googling about the chip I came across this application note (PDF) thanks to a post on Dangerous Prototypes.

Page 10 has an example schematic I would have like to use during my circuit design. The first thing that occurred to me is that I didn’t include a pull-up resistor on the Multi-Function Pin (MFP). This shouldn’t have mattered, since I didn’t route that pin. But now that I’m dealing with oscillator calibration I realize that I needed the pull-up resistor to make a frequency measurement.

Not a huge problem, you can see how I got past it in the image at the top of this post. I’m using a resistor to connect to a via on the VCC rail with one leg, and the MFP on the other leg. This is my pull-up and I’m using my multimeter to take a frequency reading from it (don’t mind the black probe clamp… my red one is broken but this is the meter’s positive input).

As you can see, I’m not getting the 32.768 kHz signal I was expecting. Time to use the calibration register, right? Maybe, but maybe not. There is a second test for frequency that outputs the calibration-adjusted clock signal. Nominally this is 64 Hz, and that’s what I get when I test that method. When I actually write to the calibration register with the correction calculated from the first test, I only get 59 Hz on the second test. Something doesn’t smell quite right.

So what’s the issue? I hit the application note again. Okay, I’ve included a decoupling capacitor as recommended, but two other things stick out. First, I neglected to lay out capacitors for the legs of the clock crystal. For some reason I thought this chip is designed to work without them. I also notice the protection and decoupling included on the Vbat line. Now the diode/resistor probably don’t matter as I think they’re meant for reverse polarity and over voltage protection. But the missing decoupling capacitor could be a cause for losing/gaining time when the chip is on battery backup or when the switch between Vcc and battery happens.

To tell you the truth, so far the thing runs reasonably well. I’m going look into more calibration testing and see where that gets me. The true test is to set and let it run for a month to see how much it drifts. But I will think twice before lay out for new parts without consulting the reference design, RTFM!

[via: http://jumptuck.com/]

I just wrote about a project over at Hackaday where a 16×4 character LCD was used to play Conway’s Game of Life. I’m fond of the game, and have dabbled in programming it myself. I thought it would be fun to take the idea and make the game board a bit bigger.

I’ve divided each character into two pixels by using custom characters. Originally I wanted to use four pixels per character, but the HD44780 protocol only allows for 8 customs and that’s not enough to map every possible combination of four pixels.

But what I ended up with works quite well. I used an Arduino with the LiquidCrystal library which comes with the IDE. The rows and columns wrap so that the game keeps going when it reaches the edge of the screen. I do seem to have one bug in my code which keeps generating garbage at column 0. I’m probably not going to take the time to squash this. It’s not a huge deal, and it keeps the game from becoming stagnant.

Check out my code repository if you’re interested.

[via: http://jumptuck.com/]

I finally got around to taking some pictures and shooting some video of my assembled clock project. Above you can see it displaying time. Minutes are tracked by the blue LEDs in binary code. Each spire has three digits, when the inner and outer digits are lit it shows a binary five and the next spire starts counting. Hours are displayed as a red LED corresponding to the positions on an analog clock. Here it is 12:54.

After the break you can see the video of the clock in action, as well as a description of what went into the build. You’ll also find some close-up pictures and a bit more info.

The assembled hardware

Here you can get a pretty good look at the assembled clock. If you didn’t see my last post, I made a fast-motion video when soldering the board. I intended to do the same thing with the spires but unfortunately I somehow lost the video I made.

Testing the board before soldering LEDs

On thing I made sure to do before I started soldering the LEDs was to test the board. I programmed the ATtiny44 and then used this little module that I made to test all of the connections.

Since each spire connects to a 1×5 grid of 0.1″ pitch holes a pin header worked perfectly for testing. I just soldered four small LEDs in the same electrical orientation as the multiplex on the PCB. The test code I used lights each LED in sequence, pausing 300 milliseconds before moving tot he next.

The components:

On the front of the board I have two tactile switches at the top. These will be used primarily for setting hours and minutes, but I plan to use long-press, and pressing both at once to add functionality. I think there is room for a couple different display techniques (mimicking analog clock hands, etc.). I also want to add control for the intensity of the LEDs. These look just fine during the day, but at night they seem way too bright.

To the left there’s a 2×3 pin header for ISP programming. At the center of the board is the ATtiny44/84 that drives the clock, and to the bottom right there’s an I2C pin header and power header. Also on this side are the four PNP transistors that are used for multiplexing, and an ill-advised status LED pad. This LED has not been populated because it shares a pin with the minutes button. The two cannot be used at the same time without damaging the microcontroller.

The back side of the board hosts the RTC hardware, sink driver, and USB connector. The USB is only for 5V regulated power, and provides no connectivity. The sink driver (STP16CP05) is my new favorite part. It’s constant current so you just set one resistor value and it takes care of the rest. This greatly simplifies the multiplexing since I’m using two different color LEDs that have different voltage drops.

The RTC hardware includes the chip itself (MCP7940) uses a CR1220 backup battery and a 32.768 kHz clock crystal to keep time. It seems to be running a little fast but there’s a calibration register I’ll look into as I work more on the code.

PCB, parts, and code

I developed the board using Kicad. This was my first Kicad project and I have to say I like it a lot more than Eagle, with which I’m already well versed. I orderd the PCBs from Seeed Studios. It was a great experience and I’m sure I’ll use the service again in the future.

All of the board information, as well as source code is available from my Github repository.

Next project:

I think my next project should probably be to build some type of camera tripod. I’ve shot the last couple of videos at the bench using the setup seen here. It a chunk of scrap wood tied to some stools and the shelf above my soldering station. I use a quick clamp to mount the Flip camera in place. It works, but it’s not very adjustable.

[via: http://jumptuck.com/]

Woohoo!

So, I spent the last few days tweaking my feedback loop to incorporate phase matching as well as tempo matching.See, before, my code would simply match the motor speed to a designated speed, but it could be completely off beat otherwise.I tried a few different methods for achieving this, and I think I found one that works.

Measurement Methods

Earlier, I measured speed by simply starting a timer at the beginning of every cycle and reading it at the end of every cycle.Similarly, for beat measurement, I start a phase timer as soon as a certain command is sent to the unit and reset it when it runs down to zero.This timer continuously runs down and resets until I tell it to stop.The idea is that the circuit keeps a local copy of the song’s timing so that it doesn’t need constant input from an outside source.

To get it started, I simply let it measure the time elapsed between certain commands that are triggered by my laptop.If I trigger those commands every song beat, it will have an accurate measurement of the song’s BPM.In the future, the beat-detection circuit will send those signals.

The minimum length of time that the timer can measure (as currently implemented) is around .4 milliseconds.With this level of granularity, you’d expect that it could measure the BPM of a song accurately enough such that once synced up, it won’t drift during the length of the song.What I found is that it would rapidly drift away such that it was noticeably off beat within 10-20 seconds.

I believe this is due to unpredictable delays that occur somewhere between my laptop and the circuit.Remember that this signal is being sent through a USB-RS-232 dongle.There’s a lot going on.RS-232 commands are not considered to be time-critical, so the dongle adding delay is likely not outside of its operation spec.

My future BPM detection circuit will be able to send commands with much higher precision, but in the meantime, I simply sent the timing command every single beat so that I effectively manually reset any drift that the circuit might be experiencing at the start of every beat.A little bit of a pain, but tapping a button on my keyboard isn’t too difficult.

The goal of my feedback control system is to get the period of each cycle as close to the target time as possible and to get the phase timer as synchronized to the cycle timer as possible.At the beginning of every cycle, my code looks at the phase timer.If the phase timer is very close to zero, that means that the beat is leading the wipers by a small margin.If the phase timer is very close to its maximum value, that means that the beat is trailing the wipers by a small margin.

Simple Proportional Feedback

If you remember from my last post, I had a feedback loop that looked something like this:

The idea is to calculate how far you are off your target and adjust proportionally to bring you closer to your target.Adding phase control makes it look something like this:

Look familiar?

There’s an important point to be made about this system.Because you only care to be on some beat, you always have the option to speed up or slow down to get back on beat.Because of this, the subtraction of measured phase to desired phase is considered to be subtraction from the closest beat.

Looking at these two loops, you’d expect this problem to be no harder than the previous problem as there are two isolated systems.The issue is that the systems aren’t quite so isolated.

For example, let’s say the system’s timing is correct, but the phase is trailing by a small amount.I could compensate by speeding up slightly, but then the system sees that the speed is too high and tries to slow it down.This throws the phase off again, so the same adjustments are made again and again.The result is an oscillatory system.

Here’s a graph of the process.The x axis is cycles and the y axis is period (measured in units of .4 milliseconds).

In this plot, the “phase” measurement is actually the absolute value of the phase error and is trying to approach zero.

The speed error gain was a lot higher than the phase error gain, so you can see that the system favors speed to phase especially when it’s first starting out and appears to be ignoring phase altogether.This quickly sets it into oscillation, and the system never really settles down as it continues to oscillate upwards of 30 cycles later.

So, what happens if we lower the gain of the phase by a lot?I re-wrote the firmware so that it restricts the gain to either +1 or -1 on the motor’s speed settings (of which there are 255; about 150 or so are reasonably fast).This should prevent oscillations as even at its worst, the speed can only be altered a small amount to account for the phase.Here’s a plot:

As you can see, there are a lot fewer oscillations this time around.You can also see that the phase is being matched very gradually taking tens of cycles.Keep in mind that each of these cycles takes upwards of a second.It could take even longer if the phase was further off to begin with.

The plus side of this method is how stable the system is once it finally settles down.

To speed up the settling, I decided to take the advice of a friend who suggested a slightly smarter feedback system.

Match Speed then Phase

The entire point of doing this feedback system is that I don’t know exactly how fast the wipers will move when given a certain speed setting command.There are a lot of variables that can interfere with the wiper speed such as window wetness, battery voltage, wind, dirt, etc.Because of these, I need to guess a certain speed, and then evaluate how good the guess is before guessing again.

If I knew exactly how fast the wipers would move at a certain speed setting before doing any tests, I could do what’s called a “feed forward” system where I could basically predict the future.

The thing is, once my code has found the speed setting that brings about the desired wiper speed, it’s safe to assume that the same speed setting will produce close to the same speed in the future so long as there aren’t any major changes in atmospheric conditions that can interfere.

This lets me do what is essentially a feed-forward system.I designed my code to take advantage of two facts:

• The wiper setting that produced a speed will likely produce the same speed if used again.
• Wipers take negligible time to accelerate.

Basically, once my wipers are satisfied that their speed is correct enough, they can stop entirely and just wait for the beat to catch up.As soon as the beat catches up, they can start immediately at the previously determined speed setting and not be two far off in speed or phase.

So my code now has three parts:First, it completely ignores phase error and tries to match speed.Second, it pauses and allows the beat to catch up.Third, once the beat is caught up, it starts again and uses the feedback method described above.Remember that that method was very stable, it just took too long to get there.With all of the hard work done, it’s perfectly adequate to maintain the already near-perfect beat.

Here’s a plot:

As you can see, the phase drifts wildly for the first 13 cycles or so and then rapidly drops to zero and stays at zero.

Testing

It was warm out today, so I had a chance to test my new algorithm on the real thing:

I was excited to find that the far end of the wiper cycle appears to be directly in the center of the ends time-wise.This came as good news because otherwise, I would need to adjust motor speed mid-cycle and try to guess the location of the far end of the cycle as the wiper motor only provides feedback for the parked position.

I was less excited to see that the parking switch appears to be slightly out of place.Humans are incredibly perceptive to mismatches in beat, so try as I might to ignore it, I couldn’t help but notice that the beat of the song was coming slightly before the beat of the wipers going down.

While it would be convenient if the parking switch were to be moved by a few degrees, I’ll probably have to make some considerations in the future to add an appropriate time lead or lag to counteract the misalignment of the parking switch.These considerations could be made on either the motor driver itself or on the device sending the signals to the motor driver.Either way, I’ll deal with it later.

Conclusion

I am very satisfied with how well this all turned out.Though I’m only part of the way there, getting the motor control down was a major stepping stone and honestly the one I was most worried about.All I need to do to properly finish up this step is to find a way to securely mount the motor driver in the engine bay and test how well it stands up to hot environmental conditions.

Now that the hardware part is more or less completed, what comes next is a bunch of audio processing and coding.Not exactly my favorite thing in the world, but at least it can be done from the comfort of my chair rather than in out in the parking lot.

[via: http://ch00ftech.com]

I took a trip to a junk yard this weekend and got a bunch of awesome stuff!

All for $30!

Salvage

Firstly, let me say that junkyards are exactly as cool as you might expect.There were literally piles of cars to pick through organized by brand.I moseyed over to the Toyota section and set to work.

The first thing I did was grab a bunch of those connectors that I was looking to buy.They were the easiest part to extract, so I figured I’d grab a few.I also grabbed a wiper fluid pump because mine broke like six years ago.I’m not sure if it’s compatible with my car, but I can’t imagine there are too many different types of wiper fluid pump in a single car brand.

Lastly, I wanted to grab a wiper motor.The one in my car works fine, but I thought it would be convenient if I could use the motor inside during development rather than having to do all my coding outside in the cold.

Extracting a wiper motor isn’t super easy.It also doesn’t help when the bolts are likely to be rusted and you don’t own a socket set.The real issue is maneuvering whatever tool you’re using around all of the engine parts.

I found that a rule of junkyards is that there is always a car somewhere that has exactly what you need.For example, a wiper motor out in the open:

“Where is the engine?” you might ask?

Probably in a number of places.

Everything Old is New

When I got the motor home, I was excited to see that it worked!I was less excited to see all the caked up grease, rust, and dirt falling off the motor every time I touched it or turned it on.I suspected this dirt was partly responsible for the spurious data I was getting from the parking switch contacts.They started out working fine, but after a few hours of testing, I had some really gross looking waveforms coming out.There was also a squeaking sound that got louder as time wore on.After years of sitting immobile, a lot of grime had settled that I was suddenly stirring up.

Because I wasn’t looking to use this motor in any real application, I figured it’d be safe to take it apart and see if I could clean the contacts.Using a T-20 Torx driver and careful force from a chisel, I managed to separate the back panel of the motor:

That right section houses the contact brushes and disk.The plastic part you see has a small plastic nub that hooks on to the rotating section opposing it.It wasn’t super easy to get access to the disk.Instead of a bolt holding it down, there was some kind of plastic harpoon-tip style piece that looked like it wasn’t intended to ever be removed.

This tip isn’t needed when both halves are assembled though; everything is held together pretty tightly by the outside housing.I figured it was safe to remove the tip by boring it out with a drill.

No wonder I was having problems.That’s a pretty gross disk.Using some dish soap, an old tooth brush, and some elbow grease, I think I cleaned things up pretty nicely.

I took some of the clean grease that never really got spread out properly (the blue blob on the top right) and applied it evenly to the metal disk to prevent the now-clean contacts from wearing out.

After slapping it all back together, I found that not only are the contacts a lot cleaner, but it also stopped squeaking!

I’ve very rapid progress programming with the help of this motor, but it’s getting late, so I’ll have to clue you in on my new code in another post.

[via: http://ch00ftech.com]