TV card output

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.

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.