Emerging Drake

GPS for Nikon D7000 (or D90)

2011-10-02T11:17:00.000-07:00

I recently bought a D7000, and noticed it had a GPS input. Since I already had the GPS module (see the GPS label) I was wondering if I could connect the two. It turned out to be easier than expected: the GPS module accepts 4-6V (and the D7000 outputs 5.9V) so no regulation is necessary. The GPS output is 3.3V, and my Nikon D7000 accepts that without any problems (I've read reports of other Nikons that need a higher voltage, in which case you can use the 74HCT125 as mentioned in this schematic.

The trickiest bit is finding which cables to connect, however, there are enough resources online, like this blog for the D90, that explain it rather accurately.

I put the GPS inside a mini Altoid box, and will probably use the foot that I had for my Minolta project. To activate the GPS on the camera you need to go to the GPS menu. On the LCD display you can see the status: if it is blinking it means you connected everything correctly, but the GPS hasn't locked on yet. If it is solid, it is in use. Note that the Nikon stops listening to the stream if the data isn't being used for a while, but it keeps powering the GPS (I believe even when the camera is turned off, so you may wish to unplug if you want to save the batteries).

PS2 to MIDI converter

2011-03-19T23:59:00.001-07:00

Recently I purchased an EMT-10E (Yamaha sound extender) which was meant for the Clavinova to increase the different sounds you could make. I bought it for the project I mentioned earlier on this blog, so I would have something to hook the toy piano with MIDI to once I was done. However, due to issues with the switches the toy piano still doesn't have MIDI, and I still wanted to play with the EMT-10E. So I decided to make a PS/2 keyboard to MIDI converter. Since a PS/2 keyboard already sends key press and release commands it would be just a matter of converting the protocol and assign a note value to each key.

As this didn't seem to difficult, I decided to give myself another requirement, which was that it had to look nice. As you can see on the picture, I think I succeeded. Initially I decided to use a wood box, but the PS/2 connector that I got from Jameco was too narrow for wood, so I needed something thinner, but still strong. After walking around in Lowes for a while I discovered that an light switch box with a blank plate would work very well. I also bought a 1/2" drill bit for the holes, and it turned out it was quite easy to put everything together.

I once made a servo controller for Brian Asman, and I already had converted that board for MIDI output. It turned out it had the right size for the box, and I therefore only had to add the PS/2 connector (I connected the data line to PORTB bit 4, and the clock line to PORTA bit 2. You also should connect +5V and ground. Wikipedia has a very clear diagram of the connector, but make sure you have the right mirror image (initially I connected it wrong, reversing the voltages. My keyboard was quite lenient, though). You'll know when you have the right connections if you see the keyboard's LED blink. To hook up the MIDI you need two 220 Ohm resistors for use in the data line and the +5V line. The data line should be hooked up to the TX pin of the PIC16F690 (you can also use a PIC16F688, if you want something smaller). The EMT-10E conveniently has a 9-12V output, which I use to power the box.

You can see and hear the box at work here:

The EMT-10E has a "split keyboard" mode and allows transposing up and down for several octaves, and it has a number of different instruments (no drums, unfortunately). The only problem remaining is that a PS/2 keyboard has auto-repeat on keys, which is undesirable if you want to play notes for a longer period of time (it also causes some notes to become "stuck", possibly because more press events are received than release events).

Here is the first version of the source code, which basically reads a key from the keyboard, converts it into a note value, and either plays it or stops playing it, depending on whether it is a key press or a key release.

If you're interested in this project you can always contact me and I can provide more details if needed.

Weighted Companion Cube

2011-03-15T14:55:00.001-07:00

On a different note I decided to make a weighted companion cube a while back, as I was enjoying Portal a lot. As you can see it came out rather well, although the silver paint might be too shiny, and the sculpey turned out to look a bit like teeth.

Attempt at creating my own simple MIDI controller

2010-11-28T18:06:00.000-08:00

I started on a new project, converting a cheap toy piano into a MIDI keyboard. The toy piano has 23 keys, which it reads using a 4x6 grid of scanlines. The resistors are already in place, and fortunately there are places for me to solder my wires to. The PIC16F690 should have enough pins (I only need 10, it has 20), and I already have MIDI code for my Beethoven playing box, that I described earlier. Hooking up a MIDI output is very easy as well: just connect +5V to pin 4 of a 5-pin female DIN plug with a 220 Ohm resistor, and hook up the TX pin of the PIC16F690 to pin 5. The step I forgot before is that pin 2 definitely needs to be grounded, so don't forget that. You can of course also use sketch one or sketch two, or any of the others found on the Internet.

I used the Pic kit 2 to try different voltages, and the MIDI works with my CASIO keyboard even at 2.5V. Since the piano has a 3V battery, I was glad to see this. Using 3V of course makes it not entirely MIDI compliant, but I'm sure most pianos will behave just fine with it.

Heart rate monitoring 10

2010-10-04T14:12:00.001-07:00

This is another walk from that same trip, this time steeply uphill and downhill, to the Bumpass hell from lassen volcanic national park.

As you can see, the uphill part had a significantly higher heart rate than the downhill part, with a slight break in between, where I discovered I had cell phone reception and sent and received some text messages.

Heart rate monitoring 9

2010-09-20T14:15:00.001-07:00

It has been a while, but in August I went to Vancouver with my parents, and hiked in various national parks on the way. Here is the graph from the second hike, which was through a forest, on level ground. The forest was beautiful, but there wasn't much variation in heart rate.

.

Heart rate monitoring 8

2010-07-12T14:44:00.001-07:00

This month the "An analytical approach to club dancing" classes started, and I decided to measure them as well. As you can expect, the analytical approach (green) is a lot lower than the beginning hip hop (red):

.

Heart rate monitoring 7

2010-06-25T08:43:00.001-07:00

Because of the heart rate monitoring, Anna Botelho asked me to check my heart rate during another class of hers called "Dancing around the world". It doesn't focus on the moves at all, and involves many different dance styles, most of which were quite confusing. Here is the graph comparing it with Shaira Bhan's class, of that same week:

The only clear difference is the start, which is partly due to me being on a treadmill (since Dancing around the World is at the gym) and partly because the Bollywood class (the red line) has a longer warming up (I think this is because people generally show up in the middle of the Dancing around the World class, which means warming up makes less sense). However, if you look at the details you can see that the activity level during the Dancing around the World class is higher (the green line is more often above the red line than the other way around). The software stated I burned 1323 kCal during the Dancing around the World class, but as I stated in my previous post, this should probably be 20% lower. It is still the highest of all activities so far.

For completeness, here is a comparison between "Beginning Hip Hop" and the "Dancing around the World" class:

It isn't difficult to guess that the Beginning Hip Hop is in red. I guess some would say that my heart rate peaking at 190 bpm is not a good thing, and an average of 171 bpm is not a good thing either. However, I feel fine. I'm in far more pain with certain flexibility requiring moves than I have with continuous jumping.

And finally, a more relaxing graph: me sleeping.

The graph looks busy, but the scale is actually quite narrow. I like the part where my heart rate drops down to 51 bpm. I'm also impressed how quickly it can go from 60 to over 100 (this usually happens when I stand up, so I guess I got out of bed at that time).

Heart rate monitoring 6

2010-06-24T09:29:00.000-07:00

A day later, and now I can compare two Beginning Hip Hop classes from Anna Botelho with each other:

You can clearly see each time she explains things, and each time we're practicing that particular move. The green graph is the latest class, which was a little bit more intense than the previous one.

The software calculated 677 kCal burned, however, I was told these numbers are a bit high, so I checked how they are calculated. It seems that without knowing my VO2/max it is impossible to get a proper number, however, the software clearly things my VO2/max is higher than it actually is. So it is likely you have to reduce the numbers by 20%. I'll see if I can establish my VO2/max value at some point.

Heart rate monitoring 5

2010-06-23T11:36:00.001-07:00

With another week came more dance classes. First there was another class with Shaira Bhan, which allows me to compare two weeks of classes in one graph:

Green is the most recent dance class. As you can see, this time we didn't get our rest period practicing jumping up in sequence. The knee jumping was present (and brought my heart rate up to 188 in the second part, where we had to move the hands in the opposite direction of usual) and the circle "boot camp" was more intense as well. The end result was a total of 1113 kCal burned, which is higher than last time.

The turret project

2010-06-22T10:24:00.000-07:00

Just to let you know what I'm currently working on (apart from editing my book): getting the ISD4002 to play sound. I hooked it up to a PIC18F2450 (first time I'm using an 18F series microcontroller, but getting it to work was relatively easy). My first issue was that the ISD4002 uses 3V, but I used an LM 317 equivalent to create a separate 3V supply. 3V into the miceocontroller is no problem (2V is considered 'high'), but the output needed to be scaled down. There was a solution on the Internet using a resistor network with a 1.5k and 1k resistor, but I decided to just toggle the TRIS register and have a pull up resistor to 3V, making the output switch between 0V and 3V.

I thought I had everything coded correctly, but recently understood that the CLK can't have a frequency higher than 1,000 kHz (which some interpret as 1 kHz, but I think it means 1000 kHz). Since I'm clocking at 10 MHz, I might need to slow things down a bit, still. I'll try later with a shorter delay.

The biggest problem is that I can't test what fails: I have to first record something, and then play it back. So I never know whether the recording or the playing back goes wrong. I might have to look at the responses from the chip to see if that indicates something.

Heart rate monitoring 4

2010-06-17T09:25:00.000-07:00

Yesterday I went to the "Beginning Hip Hop" class again, with Anna Botelho. This is a fun class, and although there is some exercise involved, it certainly isn't the same as Shaira Bhan's class. And this is quite visible in the heart rate graph:

Green is the Bollywood class, discussed previously, and red is the Beginning Hip Hop class, where we practiced turns. Focusing on proper execution of dance moves is clearly less intensive (although, in my opinion, far more difficult) than letting yourself go in Bollywood mayhem. The software that came with the watch agrees: I "only" used 677 kCal during this class.

Heart rate 3

2010-06-16T09:08:00.000-07:00

I wanted the heart rate monitor mostly to see what my heart does while I'm dancing, and I finally have a usable data set from my Bollywood class, with Shaira Bhan:

As you can see, my heart gets a lot to do during this class. 185 might be considered too high for me, but I don't notice it and I'm having fun. The 185 peak was during the sequence of jumps where you lift your knees and move your elbows towards the knees. As you can see there is also a very odd dip, at about 21 minutes in, where my heart rate went down to 115. Here we practiced jumping up from a sitting position while keeping your head down and moving it up in a "cool" fashion. As you can see, we didn't do very well, as it took several minutes before we started dancing again. The software that came with the monitor calculated I burned 1076 kCal during the dance session (I assume it uses my weight and my heart rate to calculate this).

I also gathered more data of me cycling, so I updated the script to allow comparison of two graphs. It now requires additional parameters url2 and offset. Here are two days of cycling, I tried to match up the peaks (which are overpasses).

.

As you can see the second time (in red) I had to wait for the traffic light at the bottom of the US-101, which meant the peak isn't as high. Here is the same chart comparison for the way back:

Here there is a distinct difference in the beginning, which is easily explained. The red graph starts with me sitting in a chair at Google, working on my feature. The green graph starts with me leaving my Bollywood dancing class. This is also why the green graph is shorter: the dancing class is in a building that is closer to my house.

Heart rate monitoring 2

2010-06-15T08:34:00.000-07:00

Here we have me resting:

It looks as if a lot is happening, but if you look at the scale you can tell it is actually quite low. I tried measuring myself while sleeping, but the problem with that is that the watch keeps beeping (despite me having beeps off) which wakes me up. You'd imagine my heart rate while resting and while bathing are very similar, but this is not the case:

while bathing my heart rate is much higher, even though I feel quite relaxed. Maybe this is because the water is hot? Finally, here is an actual exercise session, including 10 minutes cycling, followed by lots of walking and running on a treadmill. The peak, where my heart rate is 182, is when I'm going 8 miles/hour on a slope of setting 1.

Heart rate monitoring

2010-06-11T09:48:00.000-07:00

I'm not sure if this should be posted as "Emerging Drake" or as "Occlusion Culling"... It fits in both categories. But since I might create more projects regarding heart rate monitoring, I decided to post it here.

My mother recently gave me a heart rate monitor, which has the option of uploading the data to a website. Fortunately there are various ways of retrieving the data yourself, and processing it. I wrote a little script, that, when provided with an url= parameter (try "cashimor.xml") plots the data from the file. I'm not sure if this is a generic file format, or whether it only applies to the Timex Ironman with data xchanger. Anyway, here is the first graph:

It shows me having breakfast (it seems reading books causes my heart rate to drop below 65) and then, about 14 minutes after the start of the measurements, carrying the bike downstairs and cycling to work. At 27 minutes in you can see the bridge over the US-85, causing my heart rate to go up to 135, and then down to 100 as I glide down the other side and wait for the traffic light. At 34 minutes in you see the bridge over the US-101, which is longer, steeper, and more scary (I need to cross a lane of traffic). It goes down more gradually because the light was green. Near the end you see me climbing into the parking lot of Google. Here is the second graph:

It shows the part after the cycling, where I sit in my chair and code. There's a small peak when I went for tea (13 minutes in). And here is the third graph:

Where I cycle back. Since the most resources claim my ideal heart rate for exercise is 127, this looks pretty good.

iDrake schematic, version 1

2010-03-16T22:15:00.000-07:00

It seems most requests are for the iDrake with LCD display, so that is the first one I'll build. To make a PCB, I first need a comprehensive schematic. This isn't one, but it is the beginning of one. I'll work on it more tomorrow... Or the day after... Or whenever I'm not working on my novel.

iDrake™

2010-01-29T10:08:00.000-08:00

Just in case Apple is going to move into the Drake space next, I present the iDrake™ in this blog post. The iDrake™ is now for sale for $49.99. You can Email me for more information. So far I have sold one. The specifications are very open, but should fall within the range of the other drakes presented here. There are optional add-ons (GPS, GSM, et cetera) that would make it more expensive. Feel free to discuss these things with me.

Adding a segment: the middle vertical bar

2009-12-02T15:55:00.000-08:00

My first idea for a segment to add is the middle vertical bar. This will not be split in two, but instead will be the whole length. This makes some letters better (B, D, |) and other characters possible ($, +, T, M, W, w, m, x, X). As you can see, there is still a lot of room for improvement.

7 segment font

2009-12-01T16:56:00.000-08:00

I've been playing with fonts for a while, and I've always wondered about the least number of bits that is needed to display a character set. One option is to use a 7 segment display, as shown in this picture. Sadly, it doesn't handle all characters, and a lot of them are messed up. On wikipedia there is a 14 segment display, which does handle most characters correctly, but 14 bits seems a bit excessive. I'll see if I can find some alternatives that use less segments, but still produce acceptable results. If you have ideas, please let me know.

GTA-316 blue screen fix

2009-11-15T17:59:00.001-08:00

I recently got a GTA-316 digital photo frame (I know, about three years later than most people) and after installing my first set of JPG images it turned out that it had crashed, because the first JPG was not in a format it liked. This problem was permanent: when you turned the device on, it would immediately load the picture, try to display it, and fail. All it would show was a blue screen (see figure 1), and none of the buttons would work anymore (not even the one that turns it off). Basically it turned into a paper weight. I was planning to use the LCD screen for my own purposes, but I was not going to let a software error like this get the better of me either. I fixed the problem, and here is how I did it.

Warning/disclaimer: this procedure involves messing with hardware. It is unlike to cause problems, but I do not guarantee anything. Your results may vary. The GTA-316 might stop working forever. The computer attached using the USB might blow up. If the USB connection has issues, you might get an electric shock. In other words: do the following steps at your own risk.

If this fix worked for you, or does not work for you, or if you have an easier way to fix it, please let me know. I welcome comments.

First I opened the GTA-316. This is relatively simple, there are four screws (two hidden behind the battery panel). Figure 2 shows you how to access these screws. You'll need a very small screwdriver to unscrew them, but it is easy. I had to use a magnet to find the screws afterwards, so be prepared to store them somewhere safe. It is best to remember how you take things apart, so you can put it back together more easily later.

Once open, lay out the components as shown in figure 3. You can detach the front panel and the plexiglass completely, the front panel holds a microphone, but this is rather loose. Now you need to follow the following steps:

1. Use a large pointy metal object and scrape a few times along the address lines of the EEPROM inside the GTA-316 (see picture) to remove any coating.
2. Connect the USB of the computer to the GTA-316.
3. Press the "on" button of the GTA-316. This is marked in the picture with a red arrow.
4. Wait until the cute and compression distorted animation starts.
5. Press the large pointy metal object against the address lines of the EEPROM inside the GTA-316 (see picture) to short circuit them. Hold it there until the display shows an error message ("PICTURE FILE ERROR" or something like this). If this message does not appear, but instead the blue screen appears, read the next paragraph.
6. Remove the large pointy metal object.
7. Your computer should now recognize the GTA-316 as an unformatted USB drive.
8. Allow the computer to format the drive (this gets rid of your bad JPG files). If instead the computer shows the folder with the bad JPG files, delete them.
9. Use the "safely remove hardware" option of your computer.
10. Disconnect the GTA-316.
11. The GTA-316 should now be in working order. Make sure you follow the instructions and use the included conversion program (or hints on other websites) to ensure no bad JPG files make their way on the GTA-316.

In case the GTA-316 gives a blue screen instead of an error message you did not touch the correct lines. Sadly I was unable to find a data sheet of the particular chip, and I pressed the object randomly against the lines. Circled in figure 4 are is the area where most address lines are located, which gives you the highest chance of success. I had to do it four times myself. Make sure the pins are properly scraped and the metal object is not greasy. In case you get the blue screen, disconnect the USB and start again at step 1 in the paragraph above.

More animations

2009-07-04T15:30:00.000-07:00

I finally settled into my new place in Sunnyvale, so you can expect more posts here. I added some animations to the LED cube: a heart beat, an elevator, a cube drawing and a slow glow effect. Especially the glow effect is impressive (you can't see the LED blink) and only possible due to the way the cube was wired. Other effects are trickier, though, hopefully I can define one of the trickier ones tomorrow.

LED cube video

2009-04-26T13:36:00.001-07:00

And here is the video showing the result.

Source code for LED cube control

2009-04-26T11:55:00.001-07:00

The source code for the LED cube control is now available. Basically PORTB and PORTC of the PIC16F57 (which is actually a low end device) are used to control the output. I'm looping one bit through PORTB and one bit through PORTC to address all LED.

Fourth layer picture

2009-04-26T11:50:00.000-07:00

This is the LED cube with the fourth layer completed. It worked immediately: I wrote a small program to test individual control of the LED and was succesful at lighting each one individually. Now it is time for the hard part: creating animations.

Fourth layer

2009-04-25T16:55:00.000-07:00

The fourth layer is finished, but not attached yet. Hopefully that will happen tomorrow, together with my first animation. Video should be provided.

Third layer

2009-04-12T16:51:00.000-07:00

And here is the third layer of the cube. I also rewired the connections so the cathodes and the anodes are each on their own port. One more layer, which doesn't need any more connections, and the circuit is finished.

Pattern

2009-03-30T23:07:00.001-07:00

I succeeded in creating a two part pattern loop. An issue was that blanking the image in between each shift caused the LED to be less bright. By adding a delay the impact of the blank could be reduced, however, initially there was too much delay and the pattern seemed to be blinking. The correct code is as follows:


PatternDelay
  call Blank
  movf p1,w
  movwf PORTC
  movf p1+1,w
  movwf PORTB
  call SmallDelay
  call Blank
  movf p2,w
  movwf PORTC
  movf p2+1,w
  movwf PORTB
  call SmallDelay
  decfsz delay+1,f
  goto PatternDelay
  decfsz howlong,f
  goto PatternDelay
  retlw 0

Here the two patterns are in p1 and p2. As you can see it is relatively easy to extend to more patterns. The next step would be to write an application that can find the minimum sets needed to display a certain pattern.

Figures

2009-03-29T22:33:00.000-07:00

Today I tried to create the first figure on the LED cube, an O. In order to do this I had to switch between two patterns, two dots at the bottom in the middle and at the top in the middle, and two dots to the left in the middle and at the right in the middle. The trick was ensuring that the screen is blank in between, because any transistion LED will seem lit as well. The code became:


Display
  call Blank
  movlw 96
  movwf PORTC
  movlw 6+96
  movwf PORTB
  call Blank
  movlw 144
  movwf PORTC
  movlw 9+144
  movwf PORTB
  goto Display
Blank
  movlw 240
  movwf PORTC
  clrf PORTB
  retlw 0

Next step would be to have the delay loop automatically switch between two patterns... Although I might need more than two for complex figures. At 20 MHz it is completely invisible that such switching is taking place, except for the LED being slightly dimmer. Biggest problem is still that the bottom LED make it seem like the LED at the top are slightly lit. I might need to reduce their transparancy somehow.

Second layer of LED cube

2009-03-28T13:27:00.000-07:00

After the set back I finished the second layer of the LED cube, which you can see in action here. A small problem is that the second layer of LED actually responds to the light of the lower layer. It creates a strange effect, but maybe won't work really well... We'll have to see once it's finished.

LED cube problem

2009-03-23T18:04:00.001-07:00

I woke up in the middle of the night (which usually doesn't happen) with the thought that my idea of reversing the polarity of the LED in the matrix to double the number of LED I can control wouldn't work. I drew a small version on a piece of paper, and indeed: it doesn't work. There is no combination of control signals that will allow me to turn on only one LED. It's fortunate that I discovered this now, instead of after soldering the next layer of LED. I can still control the cube with 16 lines, but I'll have to use a matrix of 8x8 divided in 4 4x4 segments rather than using two 4x4x2 segments. There will be a switching issue, but at 20 MHz this shouldn't create a big problem.

2009-03-22T21:48:00.000-07:00

Here is the first attempt at getting the cube to work. One line of one layer only, but the rest should follow quickly: the other lines are only three wires away, and the second layer is a matter of just adding the LED. Then I will have to repeat it for the next layer.

Processor board

2009-03-22T15:32:00.000-07:00

After I cycled against and with the wind to Radioshack (the closest, but not the cheapest supplier of PCB in my area) I was able to start soldering together the board shown. It is the typical board I make, with a 6 pin ICSP for connecting the Pickit 2, a 8-12V power supply input using a 2.1mm jack (standard) and a 20 MHz resonator (not very accurate, but accuracy seems not very important in a LED cube. The speed is useful for making special effects, which I'll probably never write). As said I'm using the 16F57, mostly because I had one around and it has two full ports (PORTB and PORTC) that can be used to control the cube. PORTB will have to share bits with the ICSP, but that shouldn't be a problem. After soldering the board I tested it, and it didn't immediately work, but that was because I didn't realise the PIC16F57 is actually not a 16-series PIC, but a base model PIC. After switching the programming software to recognize base PIC, it all worked fine. My voltage meter is running out of power, so it was giving the clearly wrong voltage of 6.3V from USB and the 7805. I'll have to buy a new battery for it.

LED part 2

2009-03-21T15:49:00.000-07:00

I know, progress is rather slow, but here is the next part, and basically the ground floor of the LED cube. I also added the required resistors. I didn't have a PCB so I couldn't hook it up yet, but I did decide on the PICmicro to use: the rather obscure PIC16F57 which happened to be in one of the boxes that I got for winning the Microchip Innovation competition. I need to check on it, but it has 28 pins so I'm pretty sure I can use two full PORT for outputting the data, which would reduce the requirement for quick switching between patterns. I already tried lighting one of the LED, and they burn rather brightly, and are visible from the side as well. I'm still not sure if the next layer should face up as well, but it is probably best if they do.

LED part 1

2009-03-12T22:39:00.000-07:00

The LED arrived, and they were nicer than I thought: they actually look transparent, which is much more useful for the cube idea. I started soldering them together, here are the first 8. I'll probably need to devise some plastic covering to ensure that the wires don't cross once I start bending the whole thing into a proper shape.

Places to order parts

2009-02-28T13:13:00.001-08:00

In my previous post I referenced Futurlec as a place where you can order parts. Note that they are slow, but they are inexpensive and they have some very unique items. I really like their "LCD8X2", which is the smallest LCD display I have found so far that can still display 16 characters on two lines, and is controlled by a normal HD44780.

If I needs parts quickly, I usually go to Jameco, which is around the corner of my work place. They are more expensive, but they have very good service: you can just walk in, and walk out with your parts within 15 minutes. If you order them over the phone, they can even make them ready for pick up.

For the actual PIC microcontrollers I used to use Glitchbuster, but unfortunately they disappeared. I currently still have a large amount of them from winning the grand prize of the Microchip innovation competition but dread the moment that I would actually have to order more, as none of the websites I mentioned so far carry a good assortment. I might just order them directly of Microchip's website.

Finally, for all sorts of odds and ends, like soldering irons, solder, wirewrap wire, and various PCB, I tend to visit the local Radioshack. Do not buy parts here, as they are very expensive, and inferior in quality. Just look out for those things that will make your life better.

3D LED cube

2009-02-28T13:09:00.000-08:00

Of course I will be continuing with the ZX-jen project, but I'm also working on a display consisting of 4x4x4 LED. I ordered 10mm big LED and will soon put them together. Using a grid with two LED (opposite polarity) per crossing you can control 72 LED with 12 lines, but I think it is wiser to control two groups of 32 LED with 8 lines each, for a total of 16 lines. This way the control of each group can be done with a single PORT, allowing all LED to change at the same time without intermediate values, which could cause the display to blink LED that should remain off. This could still happen, but is a lot less likely with the new configuration. I'll write more once the LED have come in, I used Futurlec for the order, which is notoriously slow, but has nice products for an inexpensive price.

MIDI module

2009-02-17T21:45:00.000-08:00

At some point I found this box, and decided to turn it into a MIDI module. MIDI is a bit obsolete nowadays, but I still have a keyboard and an pseudo-analog synthesizer that use it, so I thought to create something. So far it can play Beethoven, but it can't record yet. This is something I'll still need to work on, but after my recent experience with the GPS module, this should be a lot easier.

At least it looks nice, though a few lights would of course make it more interesting.

Acey Ducey working

2009-02-15T17:06:00.000-08:00

"Soon" was a bit later than I thought. The first thing that became troublesome was the encoding of strings as {length,character,character,character,...}. Parsing strings like that requires making sure the length is always kept correct, and given the large number of different parse routines for skipping digits, skipping characters, skipping whitespace and various other tokens the length rarely was correct. Instead of hunting down this error I thought it was more robust to change the encoding of strings as {character,character,character,...,0} which is the usual way strings are encoded in C. This means that 0 can no longer be used as a character, but since this was not something you could input on a keyboard anyway it wasn't very relevant. Of course, changing the code this way was not entirely insignificant, but fortunately everything was structured well enough so the switch was done in an hour or so.

The next issue that I ran into was the keyboard input. The keyboard handling is currently done without an interrupt, disabling and enabling the keyboard using the clock line whenever character input is required. This worked well. However, I also want to check for the "Esc" key during program execution, so the user can interrupt the program if so desired. In order to do this I occasionally release control of the clock line and look if a character comes in. If it does, I read it and checked whether it was "Esc". This worked well, however, if keyboard input happens for a normal reason during execution (in this case, to enter the bet of the player) the last scan code ("Enter key released") will be stalled due to the clock line being pulled low, and will appear as the next character. The routine checking for "Esc" finds this scan code, and assumes that the user entered something and will wait for input, but obviously the user just released the "Enter" key and no characters are forthcoming. This means the program seems to hang. I fixed it by having two versions of the getKeyboard routine (using a status bit), one in case I do want to wait until input takes place, and one which will return after the first scancode has been recognized.

But after that, the Acey Ducey game from the classic computer games website started working. Of course, there were some bugs in this BASIC program, and some minor conversions that were needed, but in general it works, as you can see from the screen shot. Typical conversions include adding % to indicate that the variables are integers, adding LET in front of assignment statements, using RND(number) instead of number*RND(1) and splitting the PRINT part of an INPUT statement, as well as a PRINT statement that prints both constants and variables. Finally some of the constant strings needed to be shortened in order to fit the screen.

I'm happy that the game is running, but obviously I don't want to enter it over and over again. I therefore will have to devise a way to store the program somewhere, and retrieve it. There are two ways: I can add an additional 24LC512 chip and compress and store the code in there, or I can use the upper part of the current 24LC512 for storage. Currently a program can use lines 1-2047, storing it at the top would reduce this. Of course, an alternative would be to use an SD card for storage, allowing easy exchange with a PC as well. Or a serial interface/USB interface for storing it in a PC.

Apart from this a lot will need to happen with the code. String handling. Array handling. Negative number input. Fortunately it is using much less than 3K so far, of the 4K that is available. So a lot of features are still possible, although I might have to divert from usual BASIC syntax in certain cases. For arrays I'm tempted to use square brackets, for example, to distinguish them from functions. For strings I'll probably resort to the ZX-81 method of treating them as arrays to begin with. And it is likely an array like DIM A%(10) will have element A%[1] overlap with variable B%, as the RAM of a PICmicro is, after all, tiny (less than 400 bytes, of which many are used for processing).

Partial LIST

2009-02-13T09:07:00.000-08:00

Partial LIST now works. You can specify a line number, and it will only show the code from that line number. I also limited the length of the list displayed, as there is no way to control this otherwise. I then started implementing one of the examples again, and discovered that the 9 was not handled correctly, which I fixed. Soon the first game will be working...

Subtract

2009-02-09T20:50:00.001-08:00

And now subtract works in expressions. Again only a few minutes of coding, but by coding a few minutes a day, I slowly get to where I want to be. The next step will be more attention to the user interface, as showing the entire listing is unacceptable. LIST 10-100 and such commands need to be understood and functioning, or there needs to be a delay between moving back to the top of the next page.

RND

2009-02-08T16:12:00.001-08:00

As I'm trying to get the programs at the classic basic games webpage to run on the ZX-jen I needed the RND() function. Unlike the old RND() functions, which return floating point numbers, which would require me to add floating point or at least fixed point methods to my code, I decided to create an integer version of RND() in which the parameter indicates the limit to be returned. So if RND(14) is called, it returns a random number between 0 and 13. It actually accepts an expression between the parenthesis, although since the PICmicro has only 8 depths of recursion it could go wrong at some point. Soon I will be able to show you the first program running under the ZX-jen.

Upon attempting to enter the first program I discovered that I need to implement the - operation, as well as some form of delay, because the screen is small and often scrolls over before everything is displayed. Of course, I can code the delay manually, but then GOSUB suddenly becomes important.

INPUT

2009-02-05T23:08:00.000-08:00

I'm pretty sure you'll believe that INPUT now works without me showing a screen shot. INPUT accepts only a variable name (and an integer variable only, even) and causes a ? to be displayed, after which the user can enter a number. The number gets converted and can then be used for processing. It was relatively easy, although I had to distinguish i-nput from i-f. There was one bug: as you know I disable the keyboard while the program is executing, in order to avoid characters getting lost (I know, an interrupt routine to gather keystrokes would work, but that is just postponing the problem, makes the code more complicated to debug, and doesn't use the hardware to its fullest extent, as a keyboard has a built in 15 character buffer). When I called the getSentence() code I forgot to enable the keyboard. So it seemed the system just froze. Easily found, and easily fixed.

Now all I need is an random function and some other easy mathematics and I can start porting simple BASIC games. At that point it will probably become useful to write an inport/export feature that allows me to store the written programs. Of course, I could just take the memory chip out and insert another one, preserving the code that way, but that seems rather involved and expensive. An interface to a PC or SD card might be better.

IF...THEN

2009-02-01T12:57:00.001-08:00

Instead of FOR...NEXT I thought IF...THEN might be a much better option. As shown, IF...THEN now works. It can do comparisons <, =, >, <>, <=, >=, and, as a bonus, == (same as =, obviously). As my parser only checks for positive cases and not for negative cases, you can also write IF...GOTO. Because this work was done during the weekend, and therefore during the day, you can even see me taking the picture in the reflection of the television as well as my messy desk on the background. I discovered several things still need to improve: number printing should leave out leading zeroes, and it should handle negative numbers, as these might show up soon. Regardless, this introduces the important concept of flow control into the system which means it might actually start doing something useful in the near future.

Source code for alphabet applications

2009-01-30T23:16:00.000-08:00

On the PIClist someone asked about an example for controlling a LED display to show characters. I referred to my clock at the time, but I wrote a simpler application for a children's night light which also contained an alphabet. If you click on this link, it will lead you to the source code, which includes the character set. The usual copyright notice, found elsewhere in this blog, applies.

Addition!

2009-01-29T20:28:00.000-08:00

As you can see from this screen shot, addition now works. In fact, I now have a CMRreadexpression routine that reads an expression, parses it and executes it. It can differentiate between variable names and numbers, as well as handle the + symbol. It can be easily extended to handle other operations as well, though parentheses will be another hurdle, if I am going to implement those at all. Making it a separate function will make it very easy to include it in the next challenge, the FOR instruction. So hopefully I will be able to say things like:

FOR a%=b%+1 TO 0 STEP -1
...
NEXT a%

In the screen shot you can see additional debug statements that identify the operator ('+') but this will be removed soon, probably. Despite what the screen shot seems to imply, the print bug of virtual semicolons has not been fixed: I just added a few spaces to the end of the line.

Slow ZX-jen progress

2009-01-26T21:50:00.000-08:00

Another short program, demonstrating progress in the handling of variables. You can now assign integer variables with let, and assign them a number (other operations will be implemented in the future) and print them, either with ; (means no newline will print) or without. The output contains the usual debug statements, l for 'let' and p for 'print'. As you can see there is still a slight bug in the print command where it doesn't check the length of the read sentence, and thereby it assumes that line 40 ends with a ;. It used to, in the past, but it was erased. Unfortunately, this was not yet realised by the program. This will need to be fixed. But lots of things need to be fixed still. At least it seems like it is doing something.

I decreased the size of the image here. If you want to see a blown up version of the screen shot, look at the previous post. It will show approximately how the screen is built. Also, thank you for the comment on that post... I always enjoy comments.

ZX-jen screen shot

2009-01-25T21:02:00.000-08:00

Here is a screenshot from the "ZX-jen" project, or the Drake-TV mentioned earlier in this blog. The cursor is '>' and the screen continues at the top after it ends at the bottom, instead of scrolling. The square block is the cursor and indicates the current position. Before that is the executing of the program, which is:

10 print "Hello world!"
20 let a%=3

As you can see the result of the execution is:

pHello world!
l%

The "Hello world!" is the actual output, the "p" and "l" are debug indicators: they are the first letter of the command being executed, so "print" and "let". The % sign is the type of variable being read, in this case an integer, which indicates that the let statement was correctly interpreted. The only other command that is currently available is "goto". The "Esc" key can be used to interrupt a program. The next step will be to allow printing of a%, although for that to happen the assignment should actually store the value in memory. After this various simple operations, like + and - should be implemented. After this I will consider the "for" and "next" statements.

As you can see the system supports "run" and "list" commands, but also "new" to wipe the memory. The program is stored in an external 24LC512, so even if the power fails the program will be available. Program lines can be entered by just preceding something with a line number, and deleted by providing a line number with no data. Overwriting is possible too.

Debugging the clock

2009-01-24T09:26:00.000-08:00

Most likely due to the fact that I took pictures of it for this blog, one of the many wires connecting the LED had broken. This is the disadvantage of wirewrap wire: it breaks easily. After looking at the clock, I discovered that last vertical line failed completely, and the vertical line 7 before that. So using my own schematic it was clear that the D0 line from the PIC16F877A had failed, but not immediately: going from the 7th row of LED to the 14th row. So it was easy to locate the wire that was loose and resolder it. The clock works now, again.

In other words: glad I documented things in this blog. Otherwise I wouldn't have had the schematic. Of course, if I hadn't documented it, it probably wouldn't have broken either...

LED clock source code

2009-01-19T19:10:00.000-08:00

The source code of the LED clock is not very tidy, but it does the job. It first contains the definition of the hands of the clock, for one quarter. These are given by move up and move right markers, two bits at a time. I also added tables for mapping X coordinates and multiplying a number with 5, which, together with a bit shift, is convenient for also multiplying with 10. Then there are the routines for drawing digits. Digits have been optimized for the least amount of LED needed to display them, as displaying fewer LED allows brighter LED. The "second hand" is actually a single LED that moves in a square around the clock, and its table defines that movement. Initialization is as usual, with the A/D converter for reading the temperature.

The drawing routine has a memory bank that retains the image, which is rebuilt every time a display is made. For this rebuilding separate routines exist, one to display a single pixel, ones that draw entire digits, and ones that draw hands. A cursor keeps track of where things are currently being drawn. There is a separate set of routines to allow a scroll text on the clock, which is used to announce birthdays (not completely implemented yet) and a help text (which currently randomly enables itself). Then there are routines to display the temperature graph over the last 15 minutes, 15 hours and 15 days. Each LED position is 2 degrees Celcius. Not very accurate, but still interesting to see. Actually displaying things is done by "RefreshDisplay" which draws all the LED that are on. It skips LED that are off, to ensure that the remaining ones are brighter (this means that a display with more LED on will have these LED dim a bit).

Then there are routines to handle the two buttons, which are used to navigate through the different menus and submenus, including the setting of the alarm time and the alarm count down options. Updating the clock is also done this way. I also started on a teddy bear mode where it would display certain animals as pictures, but this has not completed yet.

Powering the LED of the clock

2009-01-18T13:45:00.000-08:00

Obviously the hardest part of the clock was all the LED. For a display of 21x15 you already have 315 LED that need to be powered, and even the large 16F877A has only 40 pins. The first step to simplify things is to group the LED in groups of 7, with a shared cathode. At that point you can select a group of LED by setting the cathode to 0V, and light a specific LED by setting its anode to 5V. LED burn very brightly at 5V, but can handle this only for a short duration of time (the so-called duty interval). For the LED I used the duty interval was 1/16th, but because of the amount of LED I stayed well below that. To select a group of LED I used the 74LS154, which demultiplexes a 4-bit input into 16 separate lines that can be individually pulled low. Attaching these to each of the cathodes would allow the control of 16 groups of LED. As they are grouped in groups of 7, this meant approximately 1/3rd of the LED could be controlled this way. Using 3 74LS154 the entire board could be controlled (in the schematic not all LED are drawn, one has to imagine the missing LED in between). To make things easy the 74LS154 allows you to individually select which 74LS154 is active at a given time, so with only 7 lines you can control all cathodes, and with 7 additional lines all anodes. With 45 cathodes, this means the duty cycle is, at best, 1/45th. However, it turned out that the drain on the 74LS154 is not high enough to power 7 LED at the same time, and it has to be split in 2 groups (one of 3 LED, one of 4 LED). This means the duty cycle became 1/90th. It turns out that even at 1/90th the LED burn quite brightly and are well visible.

The anodes could obviously be powered directly from the PIC16F877A, as it can output 25mA per line. However, it can only output 100mA in total, and it is therefore recommend to add the 74LS125 buffer chip, which can output 35mA per line. Do not forget to add the 0.1uF decoupling capacitors at every IC used: in this case there are 3 74LS154, 2 74LS125 and 1 16F877A that need decoupling. The result is a display that can be used for many purposes, but was used, in this case, for a clock. Alternatively the LED could be all put in a long line, making a scroll text display.

Temperature measurement for clock

2009-01-17T15:56:00.001-08:00

The reason why I added a thermometer to the clock was because I had an LM335 lying around, which I bought at a website that doesn't exist anymore. It was relatively easy to connect (as you can see from the schematic). The resistor is pretty lenient, as the whole system needs to be calibrated on the PIC microcontroller that is attached. Unfortunately this also means that the system is very sensitive to the voltage that is applied: I currently have 6V attached to the system, which is not enough to properly prime the 7805 I use for power (a minimum of 6.6V is needed) which means that attaching a higher voltage source (like a 9V adapter) causes the temperature display to behave erratically. This can, of course, be easily avoided by just having enough power. Still, it is likely that for each different 7805 it has to be adjusted separately. This can be done externally by hooking up a 10K potentiometer to the ADJ pin of the LM335, however, since this was a one-off implementation I decided to just leave it the way it is.

2009-01-15T21:52:00.000-08:00

And here is the backside of the clock. As you can see, I took a few days wiring up all the LED on the front. It was a bit tedious, but also fun to see the result. I tested each line I added separately with a test program, to make sure everything worked well before continuing.

The wire used is actually wirewrap wire. It is very thin, and therefore has a higher resistance, but if you keep them relatively short this will not affect the circuit. They place themselves easily, but unfortunately will break if you move them too often. Easiest is to cut them to the correct length first, then strip them with pliers, then solder two spots together on the board and then push the end into the existing solder. This way you get a pretty solid connection to anywhere.

Clock

2009-01-13T17:33:00.001-08:00

Another interesting project I completed last year was a clock, that uses 5x7 segment displays in a 21x15 configuration to form a display, on which a clock is displayed. The clock also measures temperature, keeps graphs over time and has a scroll text explaining its function. It is controlled by two buttons. On the picture you can see the normal display, with the clock set to approximately 5:30 PM (the LED in the corner indicates the PM). It also shows the current temperature in Celcius as well as the date (13th). The clock uses a PIC16F877A, mostly because of the large number of outputs that is needed to control all the LED. Most time was the soldering of all these connections, I'll include a picture of the back later, which shows how this was done. There are some IC to ensure proper power to the LED (although it is still lacking, occasionally). It uses the DS1307 for the time. The DS1302 with capacitor would've been better, but unfortunately I had none available, so I used the DS1307 with a separate battery.

Current project: Drake-TV

2009-01-11T14:42:00.001-08:00

My current project is Drake-TV, a new version of the Drake that is hooked up to a PS/2 keyboard and the television, and works on a 9V adapter. It contains the various circuits described on these pages: the power supply (using a 7805), the video output (this time using a 16F688 instead of the 16F628A), the main processor (the 16F690) and the "external" memory EEPROM (24LC512). The audio has not been connected yet, but will undoubtedly be connected in the future.

TV card output

2008-12-10T18:09:00.000-08:00

The output to the TV from the PIC microcontroller is a very simple circuit. For the audio, it is merely a 0.47uF capacitor, to avoid DC current bias. For the video, it is two resistors. The actual values should be 450 Ohm and 900 Ohm, but 1k Ohm and 470 Ohm are close enough, and work really well. These are used to generate the appropriate voltages (low threshold, black, white and gray). Gray could be used for two levels of output, but due to the speed limitations of the microcontroller this state is not used. Basically the 1k Ohm pin is used the generate the threshold voltages for syncing, and the 470 Ohm pin is used to generate the actual black and white values in the output. The circuit assumes the TV has an internal resistance of 50-75 Ohm, which is generally the case, to generate 0V, 0.4V and 1.2V levels.

2008-12-10T18:02:00.000-08:00

This is a copy of the text on the other website, to ensure that it is preserved in case it goes down.

Version 0.1

Version 2, with its old-style joystick interface, desparately needed a TV interface as well. I therefore started working on this. After some experimenting with an old television, I discovered that at 20 MHz it is quite possible to get 14 characters on one line without any real problems. You can also get quite a few characters vertically, but memory of a 16F628 is limited, so I decided on 10 characters, making a grand total of 140 characters. The memory is set to two segments, one starting from A0-F4, the other from 20-58. Each byte represents one character. If the top bit is set, it is assumed to be a regular ASCII character (see picture for the entire set).

Version 0.2

If the top bit is not set, it is assumed to be a user defined character, and retrieved from the local EEPROM. A next version will implement a three-byte code that can be sent over RS-232 in order to change memory and EEPROM locations.

Version 0.3

I then continued developing the "low resolution graphics option" which allows a
screen of 56*20 pixels, shown in the picture. This can be configured per line, so you can have one line of text, and 56*18 pixels, if desired. I originally planned on also have a line-by-line configurable 28*40 resolution, but am probably going to make that a global setting.

Currently I'm working more on the RS-232 interface, which understands the following commands:

Sequence Effect
0 1 2 Sync sequence. Send this if you're not certain if the chip is in sync with its RS-232 communication.
128 A0+14*Y+X V Prints character V at location X,Y. This works for lines 0-5. To print an ASCII character, set bit 7 of V. To print a user defined character, reset bits 0, 1, 2 and 7. This leaves a choice of 16 user defined characters. You can "scroll" through the user defined graphics by changing the lower three bits.
128 20+14*Y+X V See above, for lines 6-9.
128 106/107 V Defines which lines will be text, and which lines will be 56*20 graphics. The bits of 106 define the first eight lines, the lower two bits of 107 define lines 9 and 10. A 0 means text, a 1 means graphics. V is the value assigned.
129 Y*8+X V Defines a user defined character. Y (0-15) defines which user defined character is changed, X (0-7) defines which line in the user defined character is changed. V is the value assigned. Changing a user defined character takes time: do not send multiple changes in rapid succession or some changes might be lost.
130 .. .. Similar to commands starting with 128, but instead the value is XORed instead of assigned. Sending this sequence twice would result in no change.
132 255 0 Set speed to 1200 bits/second.
132 129 0 Set speed to 2400 bits/second (default).
132 129 1 Set speed to 9600 bits/second.
132 64 1 Set speed to 19200 bits/second.
132 32 1 Set speed to 38400 bits/second.
132 21 1 Set speed to 57600 bits/second.
132 3 0 Set speed to 76800 bits/second. This exceeds the maximum processing speed of the device. Do not send data continuously.
132 10 1 Set speed to 115200 bits/second (not continuous).
132 4 1 Set speed to 250000 bits/second (not continuous).
132 0 0 Set speed to 312500 bits/second (not continuous).
132 1 1 Set speed to 625000 bits/second (not continuous).
132 0 1 Set speed to 1250000 bits/second (not continuous).
132 111 4 Odd times: disables fake interlace (makes screen more stable, but makes dark lines inside letters visible), even times: enable fake interlace.
128 126 V 130 111 8 Change all locations on the screen to V. This can be used as a clear screen (with 0xA0 in text mode and 0x00 in graphics mode). V needs to be set only once, and defaults to 0xA0.
128 121 L 128 122 H 130 111 1 Play a musical note through the television. L,H=65536-(15660/frequency). To turn the note off, send 132 111 1 again.
Version 1
TV I built the first daughterboard version (see picture) and discovered that the bytecode is way to slow to even send a continuous 2400 bits/second data stream, let alone higher bit rates. I therefore decided to code some of the commands in bytecode (in fact adding a "TV mode") which worked well, until I tried higher speeds. It turned out I didn't call HandleRS232 often enough, and had to change that. It can now run at 9600 bits/second, and tonight I'll start trying higher speeds. Hopefully I'll get the 57600 bits/second that I promised myself earlier on this page. And yes, the system works also without the LCD display, and only the TV daughterboard connected.

TV Game Update: the speed is now up to 78600 bits/second continuous, where it belongs. To the left you can see a picture of a conversion of the "Version 1" meteor game to TV. The space ship has pixel level (two TV line level) up and down movement, and the meteors are moving quite fast compared to its speed. This is still in the beginning stages, but development goes quite well.

Version 1.01

Version 1.01 now has the Drake v2.0 logo when it boots. I also modified the output not to be on cables, but on the PCB itself. A good picture of the board is now available on this page as well. The final version of this system will be on a smaller board, but will still have three outputs (though it is still mono: the two sound outputs are provided with the same stream). TV Card

Version 1.02

Here is a picture of the current font of the TV card. It includes the suits of cards, a ball, an overscore, a solid block and a grayed block, four triangles in four corners and a number of digraphs (and ...) which allow more characters to be squeezed on a line, improving the amount of text that can be displayed on one line.

Version 1.03

To show how the digraphs help in increasing the number of characters per line, you can see a text in the picture on the right. The content is a Dutch song which has been roughly translated into English. As you can see, the digraphs allow a lot more characters per line than would normally be possible. This is version 1.03 because the digraphs are different from the ones in version 1.02. As you can see, the largest number of characters on one line in this example is 21, which is 50% more than the normal 14. The only line with less than 14 characters is "first had", this line still has six regular spaces left. The average line length is 16.6 characters, almost a 20% increase.

Version 1.04

This is the first picture of the version using the 16F628A. The 16F628A has the unfortunate aspect that disallows reading from the EEPROM while it is being written to (the 16F628 had no problems with that). I'm still working on making tbhe meteor pattern more random, which is more difficult than it seems. The random generator might need more work. I'm also working on porting the application to the 16F688. This will increase the amount of user defined characters to 32, and the number of characters in the character set to 256. However, it will disallow user defined characters and regular characters to appear on the same line.
Purchasing
If people are interested in buying this TV card, which can easily be used in other Microcontroller/PC projects, I would be welcome to send it to you. It can be configured to your desires, will come unassembled with a preprogrammed PIC16F628A, and will be $10 excluding shipping. Features:

* 14*10 character resolution
* 56*20 graphics mode, selectable on a per line basis
* 16 user definable characters, can be combined on a pixel line basis
* Communication speed up to 250000 bits/second (3 bytes/charater)
* 1 voice audio with frequencies up to 15660 Hz
* Fast clear screen operation
* Special character set with digraphs for an average of 18 letters/line

Drake TV daughterboard

2008-12-10T17:53:00.000-08:00

The Drake TV daughterboard is a very simple circuit, based around the PIC16F628A, although I made a version using the PIC16F688 as well. The board uses a composite video and RCA audio output, has the usual 78L05 power regulator and uses a 9-pin sub D connector to hook up to the old Drake motherboards, which will be described at another time. The daughterboard accepts specially coded input of characters, and outputs them as a signal to the TV, also handling audio.

The choice for a PIC16F628A was very deliberate, and the resulting code ONLY runs on this device. A larger memory actually causes the timing to go off, and such a device would actually have less functionality (which is the case for the PIC16F688). 18F devices could of course perform similarly, but they would be more expensive. With the current circuit you can output TV from your product for less than $2.

Old drakes

2008-12-10T17:50:00.000-08:00

Note that the old drakes are still available. I will undoubtedly republish that content here, but I wanted to make sure the link was posted as well.

Calculator software

2008-12-09T18:56:00.000-08:00

No diagram of how the PIC16F877A was actually connected: the only special things were the ceramic resonator that I used to keep it at a specific frequency (the PIC16F877A unfortunately does not have an internal clock) and the diode that I used to share pins with the ICSP circuitry.

This article concerns the code for the calculator I built.
By now a lot of features of my code should be recognizable. The initialization of the system is generally the same, both of the LCD display as well as the rest of the system. The code starts defining icons used on the display: the HD44780 allows user definable characters, and here they are defined and read. Then there is the keymap, which maps the scanlines of the keyboard to actual values. After initialization, the following steps happen:

1. Day and month are read by sending their locations in the DS1302 and calling TIMERead which retrieves that value.
2. In the birthday loop ROMretrieveword is used to retrieve the next birthday, which is then compared with the current date to see if the name associated with this birthday should be displayed.
3. After this done it waits for a random key to be pressed, indicating that the birthdays have been viewed. After this the birthdays are not displayed until the calculator is turned off and on again.
4. At this point it reaches the MainLoop where the menu is displayed and the user can use a key to select an item from the menu. The menu has groups of 3, representing the lines on the keypad. This interface has failed in all my user tests, but it works for me. You might want to find a better organization, though. The menu options are 1 to display the time, 2 to set the time, 3 to use the calculator and 4 to use the address book.

The addressbook starts at MainContacts:
1. The LCD display is cleared.
2. ROMretrieveword is used to skip the birthday.
3. If this was the last contact, go back to the main menu.
4. Display the first line of the contact (which is the name).
5. Wait for a key press.
6. If it is 2, skip the next parts of the address and continue at 2.
7. Show rest of address and return to main menu.

The calculator starts at MainCalculator. The menu works the same as the main menu. Some of the keys on the keyboard (backspace, +, +/- and =) have short cuts. At any point # can be used to access a menu with additional features. The most remarkable aspect of the calculator is the method of storage: the numbers are stored as they would be displayed, in the decimal system. All calculations are done using the decimal system as well, using the mechanisms that are taught to children. Not efficient in either memory and space, but quite readable and very easy to convert between keyboard input and display, which was my biggest concern.

A few other routines that require mentioning are the keypad read routine, which always checks for *. If * is pressed, the system jumps to the main menu, regardless of what state it is in. This is a very useful shortcut for the user, but is a good example of how code should not be written. Another aspect of the keypad that is interesting is how it debounces. The other interesting aspect is the way data is stored. The data is not stored in an external memory, like with the GPS system, but
uses the main memory of the PIC16F877A. It has 8K of 14 bit wide memory, and using clever tricks we can store 12K of address data and birthdays in this memory. I wrote a separate JAVA program to cover this address compression.

Keeping time and date

2008-12-09T18:50:00.000-08:00

Keeping time and date is relatively simple if one uses an external component. It is in principle possible to use the PIC microcontroller itself, moving it into sleep mode, giving it a 32.768 kHz crystal, et cetera. However, the head aches are not worth it if you have the space for a 8 pin DIP, like the DS1302. The DS1307 is another option if you wish to use I2C. This circuit was meant for my calculator, mostly to keep the date so it would tell me of birthdays that I might otherwise miss.

Connecting a DS1302 is pretty simple: just connect the 3 wires to the PIC microcontroller, connect the X1 and X2 to an appropriate crystal (these crystals have very small pins, so if a socket is used for the DS1302, something I would recommend, you can add the crystal to the same socket, and not solder it) and connect the power. Do not forget the 0.1uF decoupling capacitor, although in this case it might be less important, because the DS1302 is supposed to work using a backup battery. The DS1302 can charge this backup battery, so the ideal choice is a super capacitor. The value in the circuit is no joke, I used a 1F capacitor for this purpose. They are slightly bigger than a watch battery and can NOT handle voltages larger than 5V. However, most of the time it will not charge over 2V, which is still sufficient for the DS1302 to work. It has never lost time in my application, even with the power being off for weeks. The hardest part of the DS1302 is the software, but fortunately you can just copy the pieces of code that I wrote.

Calculator switchpad

2008-12-08T19:29:00.001-08:00

Today I got my first comment on this blog, and I appreciate it a lot. Hopefully more comments follow.

The switchpad of the calculator came from Jameco, and was basically 16 switches in a grid, as displayed in this schematic. To connect them to the PIC16F877A was simple: on the read side the voltage is pulled up to a known voltage (5V makes perfect sense) using a resistor network. The values of these resistors are arbitrary. I like 100k Ohm because this reduces power consumption. Speed does not really matter as they are switches anyway, and their fastest response time is 10ms. On the scan side you just connect the pins to the PIC16F877A. To read it is a matter of setting a particular line to 0V and see if any of the receiving ports detect it. If this is the case, that particular switch was pressed.

The software is slightly more complicated, because switches tend to "bounce" a bit, and it needs to be debounced, preferably over a 20ms range. So if there are changes faster than 20ms, these should be ignored, and the system should wait until the signal is stable for over 20ms. This is relatively easy to code as well, though.

Version 2 GPS software

2008-12-08T19:03:00.000-08:00

Version 2 of the GPS had a new program, although some of the old software is still recognizable.

It first initializes the variables, and the LCD display. It also sets the serial port for 4800 bps communication, which is what is needed for the GPS module. This means output to the PC will also be in this speed. The LCD activation sequence is always the same, as the R/W line is pulled down, we need to have maximum delays (160uS and 5ms respectively). Finally the software displays a . on the display to indicate that something is happening.

During the start loop it reads from the GPS until a valid string is read. If the button is pressed during this time, it is remembered so that the location can be recorded.

During the main loop it continues to read from the GPS and makes sure that a valid sentence is stored separately for later recording. The SendString routine sends the GPS string from the sentence that is at location Number. This is used to display relevant information for each screen.

There are a number of states, that can be cycled through using the button. In one state it works normally, displaying the location and recording locations and pictures in case the camera triggers the flash port. In various other states different information is displayed. In the sending state it displays "Sending..." and sends the complete memory to the PC over the serial port.

Other routines handle the storing in external memory, the reading from external memory, the writing and reading from the serial port, and the recognizing of a valid sentence and skipping all the other information from the GPS module.

The detecting of the switches is done with a separate routine, which sets a flag when it happens. This routine is called as often as possible, to make sure no button presses are missed.

Serial port for the new GPS

2008-12-08T18:21:00.000-08:00

Version 2 of the GPS has a more complicated serial port interface, as it has two functions. The original only had to read from the GPS, and store the results in memory, the new version also has to be able to send the result to a PC. Unlike version 1, which used an external GPS and therefore used a regular serial input, version 2 uses an actual GPS module. The second version also has to be able to output to a PC, something that was not covered at all in the first version.

The connection to the GPS module has some intricacies, because the GPS module, despite having a 4-6V input, had only a 3.3V output. Glancing through the data sheets of the PIC16F628A this might seem to be no problem, until one notices that the serial input port of this microcontroller uses Schmitt Trigger inputs, which means the minimum voltage for a '1' is 4V. To do the conversion I used a 74HCT125, which accepts a large range of input voltages, and converts them to whatever voltage is set on Vcc. Of course it is a bit of a waste of the other 3 buffers inside this chip, but it works and makes it very unlikely to damage the GPS module. An alternative would be to run the PIC16F628A on 3.3V, but this would cause other difficulties, for example with the interface to the LCD display, which needs 5V. Apart from the buffer, the connection to the GPS is very simple, as there is no other conversion necessary.

To connect to the PC we would officially have to output +12V and -12V signals. Clearly this is not easy with 5V power, and even if we used the 9V battery power we would still run into trouble with negative voltages. Fortunately there is the DS275. This small component leeches voltage from the RS232 interface of the PC and uses that voltage to send the messages to the PC. Of course, a PC might not have the right voltage (in fact, often they do not) but you would expect a PC to be able to read its own voltage levels back. The DS275 covers the -12V, for the +12V it uses Vdrv, which in this case is still connected to +5V. As the RS232 specification states that anything above +3V should be considered legal, +5V is fine, though barely. Hooking up the DS275 is very staightforward. As you can see it handles reads as well, but in this case it is not used. However, on the PC side the read should still be connected to allow access to the voltage levels. Note that if you decide to use the DS275 for sending AND receiving you should realise the component is NOT full duplex. You can either send or receive, but not both at the same time. If you need to do this, you might want to consider the Maxim 232 range of devices, which will be covered at another time.

Of course, you can see the decoupling capacitors of 0.1uF everywhere in the schematic. The GPS, the DS275 and the 74HCT125 all need them. Also, the plug used for the serial port is female, in this case, and this is why pins 2 and 3 were swapped compared to the previous schematic.

More power (on voltage doubling)

2008-12-07T13:58:00.000-08:00

The calculator uses 2 AAA batteries. However, so far all my circuits use 5V, and even the HD44780 LCD display requires 5V. Initially I decided to use 4 rechargeable AAA batteries (1.25V each, 5V total) but this was too cumbersome and heavy.

I had already used the ICL7660A to invert a voltage. This time I decided to use it to double a voltage. The circuit above comes straight from the documentation, and it works. However, as you can see, there is a diode involved, which causes the voltage to drop by 0.7V. So the 3V becomes 5.3V. Clearly there is a risk involved here: if the batteries are exceedingly fresh, they will deliver over 1.5V each and the 5.5V threshold of the PIC microcontroller could be reached. However, this has not happened yet. Also, rechargeable batteries don't work well in this configuration, because they have too little voltage to properly power the LCD display.

In the schematic the +5V is not 5V that is applied, but actually the voltage that comes out of the circuit. The battery is hooked up to the 3V input. Despite the odd configuration of the capacitors, they are correct.

A more ideal way to create the 5V is to use a bucket converter, but that will not be covered in this post.

Software licensing

2008-12-07T13:34:00.000-08:00

In this blog there are many references to software I published using google documents. As you can tell from the source files, this software is copyrighted. This post is to clarify the nature of this copyright.

First of all, you can always contact me regarding the use of a specific file. In fact, I appreciate people contacting me. You can contact me for other things as well. So if there is any doubt, just send me an Email.

PERSONAL USE: Next is the use of the files. Obviously, if you want to try the code, that is fine. There is no warranty: if this file blows something up, it's not my fault. They are on the blog merely to explain how I did certain things for myself.

OTHER USE: If you use the source code (or a modified version) to create something and it stays in a quantity less than 10, there will be no objection from me (but again, telling me would be nice). The moment things become more commercial (even if you plan to give them away) you need to contact me first.

MODIFICATIONS: If you want to modify the code, this is usually fine too, though I would appreciate it if you told me, and sent me an updated version.

DISTRIBUTING: Unless I give permission (which I most likely will do), you are not allowed to distribute the source code, or a modified version of it. Obviously you can create a patch file, and publish it together with a link to my code. Even in that case, it would be best to let me know. In general, I just would like to be aware where my code is going.

Hopefully this explains things. This is version 1.0, if you need a reference. If there is a later version, it will void this one, except for those cases where this one was used before the other one appeared.

My calculator

2008-12-07T13:18:00.001-08:00

On the piclist I recently posted that I would publish my calculator here. So here is the first installment, with picture.

As you can see, the calculator uses a weird keyboard that I found in the catalog of Jameco. It used an even smaller one first (with only 12 keys) and later I replaced it with the current one. It uses a PIC16F877A microcontroller to do basic arithmic operations, has an HD44780 display and works using 2 AAA batteries (and has worked on the same batteries since 2006). There is a LED to indicate it is on, as well as an on/off switch. I've started making a cover out of it (using a cat litter container) but this is not finished yet. The software for the calculator is available.

Features of the calculator are:
* Keeps time and date
* Alerts of birthdays
* Stores addresses
* Basic arithmetic (multiply, divide, addition, subtraction, random number)
* 0.00000001 to 99999999

Microcontroller LCD interface using HD44780

2008-11-20T17:51:00.000-08:00

This is doubtless the most simple way of hooking up a character based LCD display with a built-in HD44780 controller (and almost all character LCD displays are like this). The Vcc and Vdd are connected as usual, with the 0.1uF decoupling capacitor. For the contrast voltage a 10k potentiometer is used. Normally this has to be calibrated once, so a tiny one that you set with a screwdriver is good. The R/W is grounded, ensuring that the connection is write only (do NOT use a resistor for this. Quite some current goes through this pin, and not grounding it will cause the I/O ports to occasionally go into read mode, which will destroy your microcontroller, even if it is a PIC). The RS and E(nable) lines are hooked up to arbitrary pins on the 16F628A, and the D0-D3 are left disconnected. D4-D7 are connected to half a port of the microcontroller, in this case PORTA (RA0-RA3). Pins 15 and 16 are sometimes absent and are used to control the backlight. Regardless, they are left disconnected too.

Controlling this uses the 4-bit interface with maximum delays (it is not possible to use shorter delays, as it is a write only connection and there is no way of knowing whether the sent nybble has arrived). The software should show how it works. The initialization sequence is crucial, and I recommend copying it from the code, as it is easy to get wrong. When you see no characters appear, also fiddle with the contrast setting, as this could be set such that nothing displays.

Camera GPS official version

2008-11-19T18:46:00.000-08:00

The final version of the camera GPS had to be smaller. In fact, a number of things needed to happen: smaller, lighter, own GPS module, PC connection and an LCD display. The picture shows the final version. Still slightly bigger and heavier than a flash module, with a rather clumsy 9V battery (which should clearly be replaced with a LiIon one) and a serial output port (which should become a USB port, which can also charge the LiIon battery). On the picture you can see the GPS module (the square at the top left) the LCD display (2x8 characters, on the right), the battery, the 6-pin ICSP connector, a white button, an on/off switch (at the bottom) and an RS-232 output (at the top). The system still uses the PIC16F628A and the 24LC512 memory. The circuit seems a bit awkward because of the attached flash port at the bottom. I did not yet make an enclosure for it.

On the picture you can see the GPS in operation. The display shows the number of the last picture taken (40) as well as the direction in degrees, the quadrant that we are in (NW) and the movement speed. Another picture, below, shows the actual coordinates, although the display is too small to show the smallest values: this is something that still needs to be addressed in the new version of the GPS software.

7 segment displays

2008-11-18T18:07:00.000-08:00

Seven segment displays are basically 8 LED in a pattern. The most convenient way of connecting would be to hook up each LED to one pin of a port, but usually this is not possible because ports have different uses and there is always a certain port you wish to use for a certain purpose. In this case the RX/TX pins in PORT B are used for the serial input, and RA4 is used for the I2C communication. This means we have to select other pins. This design avoids fancy PWM output to the LED and just allows them to be on and off. To avoid the LED dying from current drain I added 330 Ohm resistors. For a brighter result one can go as low as 220 Ohm, to save power you can go as high as 1k Ohm. The part of the software for controlling the LED display is very simple in this case: it just consists of subroutines that send the appropriate output to the port. Normally one would not do it this way, as this is inefficient. A lookup table would be better. In this case, however, there are a limited number of values, and it was meant as a prototype anyway.

Note that it might seem attractive to use a single resistor on the ground pin of the LED display. This, however, will cause the brightness to fluctuate and can even cause damage to the display, and is therefore not recommended.

I2C EEPROM microcontroller connection

2008-11-17T14:52:00.000-08:00

Hooking up an I2C device, like an EEPROM, is relatively simple. I2C uses a 2-pin bus, with labels SCL (clock) and SDA (data). In case your microcontroller has a built in I2C controller, it is wise to hook these two lines to that port. However, I generally write it in software, because the hardware is slightly more complicated than needed (it handles clock skewing, master/slave configurations and multiple devices) in this case. It also does not give you the nice three byte buffer, which the UART (serial port input) does. If you do write it in software, it is best to hook the data input to the so-called "open collector" port. On most older PIC microcontrollers, like the 16F628(A), this is RA4 (port A bit 4). Note that both lines need pull up resistors. The values of these resistors depend on the speed that you wish to transmit data over. The disadvantage of low values is the current drain on the system. 1k Ohm works well. Note that the 24LCxxx (xxx indicates the memory in bits, a 512 module therefore has 64K of memory) needs its own decoupling capacitor, which as usual I chose to be 0.1uF. The write protect line and the address lines can all be grounded, unless you plan to have more than 64K of memory: you will need to configure different addresses for each of the EEPROM in that case.

Reading the EEPROM runs at 400 kHz. Not very fast, but suitable (and it seems most of them allow you to go up to 700 kHz, if needed). Writing is slower: you can send up to 256 bytes to the EEPROM without any delay, but after that a wait is needed (so-called ack-polling) until the EEPROM is available again for other operations.

Serial port for input

2008-11-16T12:56:00.000-08:00

To allow a microcontroller to read from a serial port (but not write to it) is relatively simple. In principle it is a matter of hooking up a 10 kOhm resistor from the output of the serial cable to any pin of the microcontroller, at which point the microcontroller can read the incoming data using software (note that this could push the microcontroller outside of its specification, as you're using the protection diodes for another purpose). Usually, however, one does not want to rely on software to do the reading, as this is slow, time consuming and prone to errors. Most PIC microcontrollers, including the PIC16F628A, have a so-called UART, which handles the reading and writing of serial ports. Unfortunately you can not use the resistor trick in this case, as the signal is inverted and the UART can not handle an inverted serial signal. Fortunately a simple RTL circuit can solve two issues: the illegal use of the protection diodes inside the microcontroller and inverting the signal so it can be properly read, and this with only one additional transistor and resistor.

The provided circuit can handle almost any serial port, even if the voltage is out of specification. It assumes a male connector, for a female connector it needs to connect to pin 3 (as this is a read operation there is no problem if you make a mistake). Note that transistors are much slower at inverting than regular inverters, and that you should therefore not use very high baud rates.

Camera GPS

2008-11-15T18:13:00.000-08:00

Another project I work(ed) on was the camera GPS. The idea is that when you take a picture, your camera tends to send a signal to the flash port, which could trigger the flash if necessary. A very simple flash port just has an on/off switch, which could be hooked up to a GPS to record the current date, time and place so that you can later associate the picture with this information. The board shown here actually used to be a prototype for the servo controller featured elsewhere in this blog, but was modified to communicate with a gps. On the board you can see a 7-segment LED display in green, an on/off LED, a 24LC512 external EEPROM to store the results, a PIC16F628A microcontroller, an RS-232 input port that would hook up to the GPS, the usual 6-pin ICSP and a 74HC125, which seems useless but was used to hook up a smaller GPS module that worked on 3V. There is also the obvious 7805 power supply with 9V clip. This, as well as the software for the GPS camera controller, will all be explained in more detail in later posts, first another picture of the prototype hooked up to a camera (a Minolta X700 in this case, which worked really well).

Servo controller in action

2008-11-15T18:08:00.000-08:00

Here is a short video that shows the servo controller working. As my 9V NiCd battery was still charging I used a regular alkaline one, which actually was better for the video as it made the servo motor respond slower due to the lower maximum current.

Servo controller software

2008-11-13T18:25:00.000-08:00

The software for the servo controller is simple: it initializes the analog input AN0, it ensures that the internal clock is running at 8 MHz, and sets the servo motor port to output. The main loop then reads the value of the potentiometer using the ReadPotentiometer routine, and calls DoThisNow to start the pulse on the servo motor control that will cause it to move to the correct position. A servo motor expects a 1ms pulse that is on, then 0-1ms that is on (which determines the position) and finally at least 20ms of offtime. It can therefore change 50x each second, however, it is usually slower in responding.

The software implementation allows a value from 1-511 to define the second 1ms, thereby having a good resolution. A final version of this software would allow storing the values from the potentiometer in either internal EEPROM or external memory, thereby allowing you to replay it. It should also allow for multiple servo controllers. An example of this is my older version of servo controller software, which stores the different settings using macros in program memory, allowing easy control using POSITION and LINEAR macros. This was the version used by balloon manor in 2007 in Rochester, NY.

Potentiometer and servo motor connections

2008-11-12T23:11:00.000-08:00

To connect a potentiometer to a PIC microcontroller is very simple. The circuit here is copied from the circuit that is on the PicKit 2's demo board (except that that circuit uses a 330 Ohm resistor, and this one uses a 1k Ohm resistor), and the software that comes with this board can be used to read it. In this case it is hooked up to AN0, which is also the programming input, but because of the high resistance this will not affect the programming of the microcontroller. In addition to the capacitor inside the microcontroller it is wise to keep an external one to avoid fluctuations in the readings.

Hooking up the servo motor is even simpler: a servo motor has 3 wires. Red is the main voltage line, which ideally is at +5V with at least 200mA, although at peak it could use over 500mA. Black is the ground and white is the control wire. The control wire can be hooked up to a PIC16F688 (or most other PIC) directly. Due to the very low frequency needed to control a servo motor there is no need to use PWM hardware, should this be available.

ICSP for PIC microcontrollers

2008-11-11T18:16:00.000-08:00

Microcontrollers are modified by a so-called "programmer". The first programmers you use usually have a socket that allows you to insert the microcontroller, after which you can update its internal memory. It is, however, much more convenient to leave the microcontroller in the circuit, and program it by hooking up the programmer to your circuit. This is called ICSP and relatively easy when one uses a PicKit 2 (I believe there is a PicKit 3 too, but I have little experience with it). The PicKit 2 accepts a regular 6 pin socket, so a simple header pin suffices. The schematic shows how to hook it up. If you align the pins with the PIC16F688 (or PIC16F690, or any other "modern" PIC) you only need to add two wires: Vdd (+5V) and MCLR.

Make sure that the end is marked, so the user can match the white triangle on the PicKit 2 correctly. Note that you should put a 0.1uF decoupling capacitor over the microcontroller, as marked in the circuit. If you are using some of the pins that are used by the ICSP, make sure they do not draw a lot of current away from the PicKit 2 (or other programmer that you might be using). Also avoid hooking up components that are sensitive to higher voltages, as you can't be certain what voltage will come out of the programmer.

Power

2008-11-10T22:52:00.001-08:00

All designs require power. Here I cover the simple design that I use for most power supplies. As you can see from the schematic, most of the work is done by a component that is called the 7805. The 7805 model is the biggest version, and recognizable by its large heat sink, which has a hole so it can be attached to an even bigger heat sink. The 7805 model can output 5V at 1A, which is quite a lot and suitable for projects involving motors, like my servo controller. A smaller model, the 78M05 gives 500mA, and is therefore not very useful. I include it more as a warning: avoid the 78M05. The smallest model is the 78L05, which looks more like a simple transistor. The 78x05 series is inexpensive in terms of money, but not entirely cheap in terms of power consumption. They regulate power quite well, ensuring that their output is 5V (the 05 in their name is this voltage, a 7812 would output 12V) with very small fluctuations. They do require that the input voltage is higher than their output voltage, though, and the difference is converted into heat (hence the heat sink). For 5V output the input needs to be at least 6.6V (or higher, check the data sheet of the particular model you acquired). There are other options, and I will discuss some later in other posts to this blog.

Note that the component does not limit the current to the value specified. All it does is try to maintain the output voltage. I have had a 78L05 output over 1A at 5V. The problem here is mostly the heat: exceeding the output current will cause the component to grow hot, to the point where it will burn you, or even destroy itself. It is therefore wise to know what the current consumption of your circuit will be, and choose the appropriate component.

As you can see from the schematic, there are two other components, both of them capacitors. At the input side I have a 10uF capacitor. This is to ensure that fluctuations in the input voltage are filtered out, as well as moments where the target circuit has peaks in the demand. It generally does not hurt to increase this capacitor: values up to 470uF are quite acceptable. Note that this capacitor has polarization and will therefore need to be inserted correctly. On the output side I usually suffice with a 0.1uF capacitor. Obviously it is possible to add a larger capacitor on this side too, but the ceramic capacitors are much faster than the electrolytic ones, and response time is generally more important. Apart from the one in the power circuit I also put the 0.1uF capacitors near all the current consuming components on the board. This is called "decoupling" and without them you might experience very strange behavior, as voltages might drop below operating requirements. If you feel that ceramic capacitors are not fast enough you could switch them for tantalum. However, tantalum capacitors have polarity, which is why I tend to avoid them.

In the circuit above I assume that it is hooked up to the mains using a wallwart. However, frequently I use batteries. As you need to exceed 6.6V my preferred method is a 9V battery. For high current applications this has to be a NiCd battery, as these give a lot more current than other batteries. This might seem odd, given that a 9V NiCd battery generally has "160mAh" written on it, which implies a small amount of current compared to a NiMH battery (300mAh). However, the C (charge/discharge rate) of a NiCd battery is 5C-10C, so it can actually provide 800mA-1600mA, whereas a NiMH usually doesn't exceed 0.5C, which means it would only provide 150mA. Of course, the NiCd battery only provides this power for 6-12 minutes, whereas the NiMH would last 2 hours. I'm not a fan of batteries that can not be recharged, because I sometimes forget to disconnect them which renders them useless, and because they are not good for the environment and difficult to dispose of.

Servo controller

2008-11-09T20:08:00.000-08:00

One of the more recent projects I did was a servo controller. In the past I already designed two (which undoubtedly will feature on this blog too) but because of the new Balloon Manor in Rochester this month I wanted to design one with a higher resolution. It was never used, and this was a very simple prototype, but it did increase the resolution to 512 steps, which is twice the number of the previous version.

As usual with servo controllers the tricky bit is the power supply. As this controller was only controlling a single servo I could suffice with a single 7805 (do not use the 78L05 or the 78M05, as these give too little power, 100mA and 500mA respectively). Again because this was a prototype I hooked it up with a 9V battery clip. As battery it is required to use a NiCd rechargeable battery, because those are the only batteries that would supply the power used by the servo motor. In the end product it is recommended to use either over 7.5V worth of AA batteries, or even D batteries, or use a wallwart to hook it up to mains. As you can see in the circuit board I put a 10uF capacitor (it doesn't hurt to make this bigger) over the input voltage, and a 0.1uF (tantalum is preferred for speed, but ceramic works well and is easier to use, as it doesn't have polarity) capacitor at both the servo motor connector as well as the microcontroller.

As microcontroller I used a PIC16F688, mostly because it is so nice and small, and modern, allowing it to be easily programmed using the PicKit 2 (you can even program it in the PicKit 2 demo board: even though it is made for the 16F690, it fits the 16F688 equally). I used the usual 6 pin programming connector, which, if mounted as displayed, is really easy to hook up: the three pins next to the PIC16F688 (pins 3-5) can be connected directly. The fourth pin (6) is left floating. 2 is connected to the top pin on the other side, as this is the other voltage, and 1 is connected to the reset line, which is the middle pin on the other side of the Microcontroller. For this I use a white wire, so it is quite recognizable on the board, so I can match the triangle of the PicKit 2 with the white wire and do not mistakingly connect it the wrong way.

The final two components are the potentiometer, which is connected to the analog port of the 16F688 and is used as input for the servo motor, and the servo output. On the servo output pins 1 and 2 are connected to the power directly, and 3 is connected to the output pin of the microcontroller that is used to control the servo. Obviously multiple servos can be attached using different pins of the microcontroller. Note that once you exceed two servos, a separate power circuit is needed for the next two. The ground will need to remain the same, to ensure proper functioning of the control line.

The software that I wrote for this servo controller is very basic: it measures the potentiometer and moves the servo motor accordingly. The plan was to include a system that registers the sequence of movements of the potentiometer in memory. This is not very difficult to develop, but the higher resolution of 512 values as well as the limited storage of 256 bytes inside the 16F688 made this trickier. I was contemplating using the difference between two settings and storing it in a 4 bit value, but never got to implement this.