Custom PCB for Toshiba TCM8230MD Camera

I recently purchased a few small TCM8230MD CMOS cameras made by Toshiba from SparkFun. I plan on using the camera for some machine vision experiments as they are controlled by an I2c bus and have an 8 bit parallel video out with sync and clock. This makes them very microcontroller interfacing friendly. I plan to use a higher end PIC micro to receive the picture data and process the received video frames. The only issue is that I didn't realize how small these cameras actually are until I tried to use one.

My first attempt at soldering didn't go so well as the solder pads on this device are extremely small. Since no breakout board is available and the lead spacing on this device appears to be non-standard, I went for a custom PCB design.

I made the initial pattern in Eagle using the dimensions from the datasheet to space the solder pads for it, than drew simple traces to solder pads for two headers. I then used the instructions here to transfer the trace layout to a copper PCB.


A nice thing about this simple board is that I didn't have to worry abut mirroring the layout when printing as the orientation of the camera doesn't matter. Once the board was etched in Ferric Chloride, it looked like this:


Not bad for a quick design, there was one weak trace that was etched too much but a little solder will fix that. One note about etching, It took much longer to etch than anticipated. About 20 minutes was needed with me agitating the board for the last 10 minutes.

A reflow procedure was used to solder the camera down, I did it with an electric skillet. After reflow, a quick test showed no shorts and inspection of the pins to pads looks good. I plan on starting to use it tonight.

Now that I have made the board, I would have changed a few things. I should have made pin 1 on the camera line up with the standard pin 1 location on the board. I should have also made all the header pins along one side of the board instead of two so I could use right angle headers to mount the camera vertically. I also didn't forget to drill the holes in the board for the headers, I purchased new PCB drill bits online and they have not arrived yet. I'll just solder jumpers to the pads for now. Yes i'm impatient.

Automatic plant watering system, Part II

Last summers automatic plant watering system worked well, but it never ended up leaving the breadboard. So as I already have my pepper plants planted for this year, I wanted to get a more permanent system up and working. I took the design from last year and built it on a Rabbit Flex dev board I have had laying around since I had used the rc3400 I built last years on for a separate project. One of the nice parts of this board is that it has on-board Ethernet which I plan to take advantage of.

This version will have a web based interface to allow me to control the watering times remotely. Along with the rain detector that was built last year, it will also have temperature and humidity sensors that will allow me to adjust watering accordingly based on current conditions. Ideally it will also be able to show how much water I am using per day once I calculate the flow rate of my system.

Design:


The basic system is operational right now along with the external sensors, the web interface is the last step of the project, along with a case to mount the project in.

Quadrifilar Helix Antenna for NOAA APT Reception

Since most of my previous attempts of NOAA APT live weather imagery reception have resulted in rather poor quality images, I finally decided to give it a real try this summer. I started with purchasing a serious receiver, the icom IC-R7000. With continuous coverage of 25Mhz all the way to 2Ghz, it is probably one of the best scanner / receivers I have ever used. It has the Japan built quality of electronics that you just don't find anymore and the feel of a very solid piece of electronics. Along with this I purchased a registered copy of WXtoImg, which is definitely the best APT decoding software available. I have used several of the free APT decoding applications, and while they work... they just don't have the image clarity that WXtoImg offers. WxtoImg also can control tuning of my icom IC-R7000 via rs-232 which is very nice as well.

The final missing piece I need is a good antenna. Here is an example of an APT capture using a dipole antenna with ground plane tuned to 137 Mhz:


The image is excellent just above my location ( indicated by the yellow + sign ) but image quality decreases as noise increases quickly outside of my location. What is needed is an antenna with a much better gain from a high speed moving satellite that doesn't have signal fade caused by the orientation of the propagated wavefront. While many people have had good results using basic dipole whip antennas, discone antennas, turnstile antennas, and more exotic Lindenblads, nothing seems to perform as well as the Quadrifilar Helix Antenna (QHA) .

Looking at the QHA, it is initially somewhat hard to understand it's design. It is a pair of circularly polarized, half turn, half wavelength helical antennas designed for reception of low-earth polar orbiting satellites. Reading into the documentation for the actual NOAA polar orbiting satellites, they actually use this exact same antenna design for APT transmission on the satellites themselves. After some research, I came across an excellent calculator for designing the antenna. I recently built this antenna using measurements from the calculator and ended up with this:


It's not perfect, but it is designed to specifications. I used thick 4mm copper grounding wire instead of small copper pipe that other designers of these antennas use mostly for ease of assembly. Also in the picture is the RF choke balun, which converts the balanced signal from the antenna to an unbalanced coaxial cable. It is simply four turns of RG-8 around the antenna mast as close to the feed point as possible. For extra gain, I'm using a mini-circuits ZFL-1000LN low noise amplifier between the antenna and receiver. Overall antenna parts cost was about $30 and assembly time took about two hours. I plan on testing the antenna this weekend and I'm looking forward to some good satellite imagery.

POCSAG and FLEX pager reception and decoding

Browsing the 900Mhz band last week, I came across the distinct sound of pager protocols on a handful of frequencies. Years ago I began listening to pagers on the 138Mhz band as my scanner at the time only reached the 500Mhz band as it’s highest frequency. With my ICOM-R7000, I am able to easily browse through the entire 900Mhz band where I have found most of the pager frequencies are located.

The two main protocols used by pagers are POCSAG and FLEX. Both protocols support tone only, numeric and alphanumeric pages at various bit rates. POCSAG uses FSK modulation with a +- 4.5Khz change of the carrier frequency. A +4.5Khz tone is a 0 and a -4.5Khz is a 1. Bit rates of 512 ,1200, and 2400 bits per second are supported. FLEX is another protocol which is newer and also uses FSK modulation. Bit rates are available at 1600, 3200, and 6400 bits per second. A key note to make about both of these protocols is the fact that their data is transmitted in clear text.

The only requirements to decode pager transmissions is a scanner / receiver capable of receiving FM on pager frequencies, ( the low 900Mhz band seems to be the most active) and software that is capable of decoding pager transmissions. The software I use is called PDW, and is freely available. It is capable of receiving both POCSAG and FLEX transmissions in all bit rates including a handful of other protocols.

For an antenna I’m using an outdoor wide-band antenna that has coverage in the 900Mhz band. I’m also utilizing a mini-circuits ZRL-2400LN wide band low noise preamp to help pull in any distant signals, even though it really isn’t necessary as these pager transmissions are fairly strong.

There are several interface methods available; the first is connecting your scanners audio output directly to the input of your sound card. The second involves taking he discriminator output of your scanner and connecting it directly to your soundcards input. The last method involves making an FSK to rs232 level decoder that takes the scanners audio output or discriminator output and converting it to serial data. I have actually had really good results with using the discriminator output of the R7000 and tying it to my sound card.


The ICOM-R7000 does not have a discriminator output, but it is an easy modification to add. The R7000 actually has a ‘spare’ rca connector on the back that can be used for any additional mods you wish to add, and tapping into the discriminator is an easy operation to do. There are instructions all over the place to do this so I won’t describe it here. The discriminator output is key since it provides access to the FSK pager audio before it is passed through filters on the scanner that usually destroy the signal.

I am passing this discriminator output directly to my soundcard line input and have had excellent results. Many people mention that this won’t work for the higher bit rates, but I am successfully decoding FLEX pages even at 6400 bps using this method. I used to use the audio output form my old scanner to my sound cards input with poor results. At best I was able to decode POCSAG at 512 bps. I would still like to make a 2 level or 4 level FSK converter, but I really find it isn’t necessary.

Finding the pager frequencies is fairly easy. There are many lists available around that I found from some searches, although I found many of them to be old and out of date. I had my best results by simply searching around and hearing them. This is better to perform during the day as I found pager transmissions are much more active than at night. I usually start right at 900Mhz and begin tuning up 5Khz at a time. Pagers are easy to find as the tone has a very distinctive sound. Several passes over the band may be required as some of the frequencies will be idle when no transmissions are present. I found the following frequencies to be very active by me:

940.870, 929.295, 929.620, 929.720, 931.340, 929.670, 929.545, 929.845, 931.345, and 929.495.

This may be different in your area, but most of these I believe are nationwide pager networks. Here are some of my results:

( I removed actual names and modified phone numbers as I have no interest in displaying real personal information. )

0389996 00:08:13 20-05-09 FLEX-A ALPHA 6400 MSN 019 hello Message from NOC PCB. 1510016
1424219 00:09:31 20-05-09 FLEX-A ALPHA 6400 THIS IS A TEST PERIODIC PAGE SEQUENTIAL NUMBER 7829
0769357 00:09:33 20-05-09 FLEX-C ALPHA 6400 0769357 00:09:46 20-05-09 FLEX-C ALPHA 6401 es 40 pts, 6 rebs, 4 ast vs. Carmelo Anthony's 39 pts, 6 reb, 4 ast...010243590 00:09:48 20-05-09 FLEX-A ALPHA 6400 801221234545020519203005192245005
010243590 00:10:03 20-05-09 FLEX-A ALPHA 6400 902051234545990519203005192245015
0186743 00:10:03 20-05-09 FLEX-C ALPHA 6400 MONTGOMERY, NJ (SOMERSET) *2ND ALARM* 16 HAMPTON CT. 2ND ALARM REQ ON ARRIVAL FOR THE F/I DWG W/POSS ENTRAP. NJ2
011156517 00:10:22 20-05-09 FLEX-A StNUM 6400 281 555-9405
011319993 00:10:22 20-05-09 FLEX-A StNUM 6400 213 555-4758
0000001 00:10:22 20-05-09 FLEX-A ALPHA 6400 MSN 030 hello Message from NOC PCB. 1111111111
010239056 00:11:39 20-05-09 FLEX-C ALPHA 6400 38767:Host:png,pBg_fcsw_4.png.com Event:nodedown [nvasp] [58]
010248578 00:14:13 20-05-09 FLEX-C ALPHA 6400 Feeder 07Q85 opened 05/20/09-00:03. 3 of the 24 feeders are out of service at FLUSHING NETWORK . [57]
0186742 00:41:01 20-05-09 FLEX-A ALPHA 3201 DV. BULK OF FIRE K/D. CO'S GOING INT FOR SEARCH & O/H. NJ2
0186743
002816630 00:41:37 20-05-09 FLEX-A SH/TONE 3200 520
003951995 00:44:05 20-05-09 FLEX-A ALPHA 3201 MSGW02MOM" CPU is running at 5.50 percent This event was generated by the script: "Exchange ... [88]
003435545 00:48:11 20-05-09 FLEX-A ALPHA 3200 HARD WATER IN CONDENSATE. CALL THE POWERHOUSE 3-7038. PAMS_24.Unack HARD WATER IN CONDENSATE *ALM* High [78]
003951995 00:43:11 20-05-09 FLEX-A ALPHA 3200 Store timed out at the 30 seconds threshold Exchange Server:"MOBMSPF05" MDB:"SG1 (MOBMSPF05)\SG1_Priv1_(MOBMSPF05)" Mailbo
003951995 00:43:22 20-05-09 FLEX-A ALPHA 3201 x:"MOBMSPF05MOM" CPU is running at 2.97 percent This event was generated by the script: ... [82]
002116131 00:07:43 20-05-09 FLEX-C ALPHA 6400 PATIENT - EMERGENCY
SAME
HER EYE WAS OPERATED ON LAST MONTH AND SHE HAS
EXTREME PAIN NOW


The message displayed in PDW consists of the pagers cap code (unique address), time, date, protocol, page type, bit rate, and finally the message. The cap code is the unique id set to each pager. All pagers on a certain frequency receive all pages on that frequency, but they only display pages where its cap code matches the code in the messages. I am seeing pages from a local hospital, sports scores, news, tower information transmissions, business nagios server alerts, other miscellaneous data, and of course pager numbers. It’s quite interesting to see how much information is easily received and decoded.

Remote GPS tracker + Accelerometer

This summer there are a few projects I have planned. One of the first is a model rocket tracking / data-logging system for some launches I am planning on performing this summer. I recently came across a good supplier of F and G series rocket engines for a very reasonable price. Some of these engines have as long as a 7.8 second burn making them very exciting to see take off.

The idea of this project is to be able to record all acceleration of the rocket throughout the the entire launch. The tracker will also have a GPS receiver that can log it's maximum altitude as well as track its decent to aid in finding it's landing location in the event of a launch where the rocket landing ends up not being visible. This GPS data will be transmitted through a long range Xbee tranceiver.

The basis of the performance data is an Analog Devices ADXL accelerometer. These accelerometers are very cheap and very accurate. They are available in different models with varying degrees of g resolution. The model I am using here is the ADXL330, a three axis +- 3g accelerometer.

The +-3g of resolution is fine for testing, for the actual rocket launch I will be using a +-18g accelerometer to capture launch and decent data.

The ADXL is a pretty small SMD device, so soldering was a little tricky:

The prototype I am making here is a testing base that will be used for debugging and developing the base station receiving software. I envision making a simple and cool app that will control and display all functions of the rocket from launch to landing. The design is based around a PIC18 series microcontroller. Initial performance testing and range testing will be performed by mounting this prototype to a remote controlled truck to gather data.




The tracker under development on my bench:


The finished prototype:

Please note that this device is much too big and heavy for use in a rocket. The final version will be made mostly of SMD devices on a PCB I design using Eagle. Lithium Polymer batteries will be used to save weight as well as using a smaller GPS receiver. I need to be able to save every gram of weight possible.



The device is currently working flawlessly as I have tossed the device around outside my home and been able to capture the data from it. Truck testing will occur this coming week or two, I will be able to display actual data at this time.

Long Range XBee PRO

Digi recently released a new series of XBee wireless long range transmitters which I have been very excited to play with. The XBee-PRO 900 series has up to a 6 mile range using a high gain antenna! Some other features from the XBee site:

• Fast 156 Kbps RF data rate
• Point-to-multipoint networking ideal for low-latency applications
• Support for large, dense networks
• 128-bit AES encryption

Jim cam over this past weekend to help me perform some basic ranging tests with these modules to see what type of distance can be achieved in an urban area. The plan was to set up a base station and send messages out to a mobile XBee PRO as a repeater and see how far away we can get without dropping any packets.

The base station is simply an XBee PRO linked to my bench machine through it's serial port via a MAX232.



The mobile module is simply an XBee PRO with it's TX and RX lines wired together forming a basic echo repeater. Lithium polymer batteries are being used through a 3.3v regulator. This is simply in basic mode as well, no API mode.



Using Digis' useful X-CTU application for range testing, we were able to get some impressive results. We were not able to get anywhere near a 6 mile range, but with the fact that we were using only the on board whip antenna on these modules instead of a high gain antenna, it was expected. Our testing environment significantly limited the range as well because of the amount of concrete structures in the area. With all of this we were still able to reach a range of several thousand feet before packet loss. A standard XBee would never reach this range.


Range was very limited to line-of-sight. If there was a building in between the source XBee and repeater XBee, packet loss would occur in a very predictable manner. This was all happening from the source transmitter being on my bench inside my home, so there was already an initial structure blocking it's signal path.

Our next tests will occur in a more open area which will allow more line-of-sight testing. I am confident that we will reach several miles in this scenario and will report our findings.

HO scale train layout signal dispatch panel

My dad has a pretty good sized HO scale model train layout that he has been working on for the past year or so. The last time I came to visit I realized that he was in serious need of a signal control panel. A few years ago when he started planning his new layout, I had told him that he needed to upgrade all of his target signals that then used grain of wheat light bulbs to LEDs. Previously, you had to put very small light bulbs in each signal whcih ran on 12 volts. While they have always worked fine, they did have several disadvantages. First, they produced a lot of heat. Often your signal would get very hot just from operating. Second, each target of the signal was limited to a single color ( unless you were able to stick two light bulbs side by side in the same target light ) which was difficult to do and never looked very good. Finally, they were usually very bright, bright enough to illuminate the entire section of track in front of the signal which is very unrealistic.

A typical target signal you see in the midwest ( pretty much the only style signal you see in Michigan ) is this:


This signal is typically in a two or three target configuration where each light can produce Red, Yellow, and Green light. To have a convincing signal on a model layout you need to have signals that have the same effect, which is where LEDs come in. A bi-color red / green LED can produce the exact effect needed for this. Power the LED and you get green, reverse the voltage you get red, provide fast alternating current ( faster than the persistance of vision ) and you get yellow.

My dads model layout has approximately 30 signals on it, so a cool control panel is definitely in order. I have always been all about things with lots of lights and switches. So after my dad upgraded all of his signals to LEDs, I began work on the control panel. First I needed a simple circuit to control the LEDs to provide the three colors necessary from a two-lead LED. I came up with the following circuit to allow their operation:


A 555 timer provides a simple clock at a 50% duty cycle set by the 1K adjustable resistor. The switch on the far right is a single pole double throw toggle switch with a center off. Based on it's poistion of up or down decides on the color of the LED. Up is green, down is red. In the center off position the 555 provides the fast switching current provided by the invertor to the LED producing a yellow color. The exact shade of yellow can be adjusted by changing the duty cycle of the 555 by adjusting the variable resistor. I have a single 555 providing the clock to all my LEDs through this simple circuit. I have a bunch of buffers in line from the clock not shown in the schematic driving each LED. This also allows me an easy upgrade path to a logic based solution in the future where I can have a microcontroller controlling all of the LEDs as well.

On to the panel assembly. I started by creating a schematic of the layout and creating a template on a 4' by 6" length of 3/8" plexiglass.


Once the layout of the panel was complete it was time to start drilling. Knowing a hand drill would not provide adequate and consistent holes, I bought a small 10" drill press which I have been wanting for a long time anyway. The drilling begins.


Another thing I found out is local hardware stores do not carry metric drill bits. I had to buy 5mm drill bits online to make sure the LEDs had a perfect fit. After drilling was completed, I peeled off of the protective paper and painted the back of the plexiglass black. It gave the front of the panel a nice look. Then assembly began.

Once the 62 switches and 62 LEDs are mounted and glued in place the wiring began. I also installed two 4' U channel peices of aluminum on the back of the panel to give it some rigidity and stability. Now time for the wiring. I decided to not use any PCBs when buliding for sake of time saving, but the amount of wiring necessary soon became very regrettable. I did use a perf board for all of the logic driving, but the resistor and diode networks became a bit much.

The logic portion was much easier.

There are still many wires to run from here, but that was finished after this picture was taken. Now the front of the control panel needs to have the layout schematic placed on it. For this I used this vehicle pin striping which is cheap and very easy to work with.

And finally the finished product.


With the lights off.

Mostly red signals shown here with a few greens and yellows. All of these LEDs are the same bi-color device. The last step is to install the panel in the layout and wire all of the actual signal LEDs in parallel to the LEDs on this control panel. Once installed I will have pictures to show the final result.