Moving day, projects on hold

The downturn in the economy has created some amazing deals in the housing market around me. Because of this I have purchased a new home and will be moving next week. This will of course put my projects on hold, I definitely have a lot of packing to do...

The really good news is that my new home has a huge basement which will allow me to have much more room for my current cluttered work area. :D

Recovering a HP 16500B Logic Analysis System From a Failed Hard Drive to a CompactFlash Drive.

In a recent auction I purchased two HP16500B logic analysis systems and one HP16500A system for pretty much next to nothing which had me very excited. I have been looking to upgrade from my current 1630D logic analyzer to something a little more powerful. My 1630D has been excellent and has worked perfect for many tasks, but I have been finding that I have needed a more powerful analyzer with a lot more memory depth for some recent hardware hacking projects i have worked on. I have wanted to buy a 16500B system as their prices are reasonable, but the hard drives that they use have scared me. These hard drive based systems are ticking time bombs. Once it's disk fails the device is useless unless you have the original system boot disks for it and a working floppy drive.

The price of these three systems I bought was next to nothing, and having local pickup as an option saved me a ton in shipping as these devices are by no means small or light. So even if they were all dead I wouldn't be that upset. Upon arrival home and powering them all up, one of the three worked. The 16500A has a power supply issue and will be looked at soon. I was really interested in the two 16500B systems which one worked perfectly while the other had the common 'HARD DISK FAILURE' error upon boot indicating a dead hard drive. Luckily both of these systems came with a full (unopened) floppy disk set of the system software which lets me boot the system with the failed drive from the floppy. While I was able to successfully boot the system, unfortunately many of the modules in it have been upgraded which my disk set didn't support leaving these feature modules useless.

These systems use a Quantum PI16A011 hard drive of 170MB capacity (at least both of mine did, later earlier or later models may have had different disks). Now while I probably had a box of these drives 10 years ago or so, I have since thrown them all away. I figured purchasing one would be easy but the only similar ones I found on eBay the sellers wanted a premium for them because they were 'vintage'. Whatever, I'm not paying you $40 for a 15 year old hard drive that will probably just fail again. Looking for a more permanent solution I decided to give a Compact Flash card a try in the device.

CF cards have the cool ability to mimic a hard drive in CHS mode ( cylinder / head / sector) . I have saved many failed firewalls and other embedded devices by replacing their failed hard drives with a CF card using a CF to IDE adapter card. You can find these adapter cards for around $5 to $10.

To get the data onto the new system I considered pulling the good drive out of the working 16500B and throwing it in a linux machine along with the CF card IDE adapter. I could then clone the disk using the 'dd' command to the CF card making an exact copy. Since I had already backed up all the data from the working 16500B to my network in fear the the working one would die, it was easier for me to just ftp this backup data over to the failed system.

Here is how I was able to recover my 16500B system with the failed drive by replacing it with a CompactFlash card:

1. I booted the good working system and configured the network interface for an IP on my network. This allowed me to ftp to the 16500B, logging in with the user 'control' and no password. I then copied over all files on the 16500B system via ftp get to my local computer. I now had a backup of all of the system software for safe keeping. (Note: If using an ftp application such as LeechFTP, or any other that allows threaded ftp functionality, make sure only one thread runs at a time. Trying to transfer more than one file at once will cause the 16500B to lock up) Note, Note! If you have a 16500B, back up it's software to your network! When that drive fails you will need this data to recover.

2. I purchased a CompactFlash to IDE adapter to use in the 16500B with the failed disk. I had to try several of them before I found one that worked with the 16500B. (Buy a quality one, not a cheap Chinese one. Make sure it also has a jumper for master/slave configuration and set it to Master).

3. Buy a CompactFlash card and place it in the adaptor. I used a 64MB card in my 16500B successfully. These cards follow the basic CHS (cylinder / head / sector ) format of older hard drives so it works fine. Avoid cards larger than 256MB as the 16500B may not recognize them ( I haven't tested, just my assumption. I do know for sure that my 64MB card works perfect).

4. Place the adapter in the 16500B with the CF card installed. You will need to come up with your own mounting system to hold the new CF adapter in place where the hard drive was located. Connect the IDE cable and power connector to the adapter. Make sure it doesn't short out to the chassis ground.

5. Power on the 16500B and boot it via the system floppy disk. During boot, it will still report the 'HARD DRIVE FAIL' error message, this is normal.

6. In the 'system' menu, select 'hard disk' then select 'format' and press 'execute'. It will prompt you twice to confirm and format within a few seconds. If you have any errors here try a different CF card or adapter. Again, I had to try a few different ones to find one that worked.

7. Configure your 16500B's network adapter for a free ip on your network. Place an AUI media adapter on the 16500B and hook up to your network. It now should be pingable from another computer.

8. FTP to the 16500B's ip and login with user 'control', no password. You should login successfully. Now copy over all of the HP16550B's /system files from your backup to the 16500B with the CF card. If your CF adapter has an LED activity light, it will be blinking showing the data is indeed being copied. This may take up to 15 minutes to complete. If you only have the backup floppy disks, copy them to the CF card via the 16500Bs interface. I find it much faster to copy the floppies to a computer and ftp over all the data. The /system directory is the important one you will want to copy over.

9. Once all files are copied, remove the 16500B's floppy disk and power cycle. Upon boot, the hard disk should pass the self test and it should be immediately booting. Your 16500B is now ready for use!

Now CF cards do have a limited lifespan as well in regards to the amount of writes they can do, but since my 16500B just reads the card to boot, it should last a very long time. I'll still have to compare the CF card to the hard drive to see if there is any speed benefit in boot time to using the CF card. These are very powerful and excellent logic analyzers that are well worth converting to CF cards to increase their lifetime. Remember, if you have a working 16500B system, back up it's software before it's too late!

CPU From Scratch

I haven't been posting too much lately, mostly because I have taken on a very ambitious project. I have decided to create an entire CPU from scratch using only TTL based logic. This project has been in the works for about two months now and I finally have something to show for it. Because this project is going to be more in-depth than most I have dedicated an entire wiki to it which can be located at bradthx.net.

As it stands now I have an 8-bit CPU that is able to load and store instructions into address and instruction registers from memory. This proves (along with a lot of additional debugging) that my design seems solid and I can begin designing my opcode and burning it to eproms. I will update this blog when I make major milestones, but all the technical data will be located at bradthx.net.

Power Supply Reverse Engineering

I recently came across a crazy good deal on eBay, a Scientech SP1000 precision balance / scale. For $15 I couldn't refuse the purchase of a retail $2000 precision scale even though I knew the power supply was not included with the unit. I figured I could just reverse engineer the circuitry to create my own external power supply ( $100 retail value for the power supply from Scientech) to be able to use the scale, and after an hour on my bench my assumptions were correct.

I have wanted a simple scale for awhile now to measure the weight of rocket components to be better able to predict it's performance with my addition of GPS / accelerometer payloads. There are a ton of cheap scales on eBay (mostly from Chinese suppliers) but I knew I wanted something better and more precise than the average drug dealer who purchases these cheap items. After some research I discovered Scientech was one of the leaders in precision balances and began to search for them. I was very happy to find one for very cheap with the absense of a power supply. This is where my reverse engineering began. The scale had a 5-pin din connector for power. Knowing that this was not going to be completely simple, I tore the unit apart.

To reverse engineer it's power input, I first located it's ground pins. I did this by locating known ic's and metering their ground pins to a pin on the power connector. Also noticing large ground planes on the board helped as well. There ended up being two grounds pins on this board. Two pins down, three to go. Once the two ground pins were identified, I went for non-ground voltages. The first I discovered was a +5v line. I traced the pins back through taces from some known 7400 TTL logic ic's and was able to identify a +5v input. So one pin from the power supply provided +5v.

Moving forward I was lucky to find a label on the board indicating -12V. I followed this trace back to the power connector and identified one pin as being definitely -12V. Another pin from strictly an assumption would be +12V. I followed the traces from this last pin around and discovered they followed the -12V traces to a regulator, indicating that my assumption was probably correct. Time to power up.

After making all connections to my power supply, i powered up the +5V line first. Pressing the power button resulted in the display turning on with '-----'. A good start. I set my +12V and -12V supplies to current limit at .1A as to not burn it out if I was wrong, and slowly raised the voltage on each. Once about 10V on each was hit, the device came to life. I had a working scale with the exception of some errors on display. With some testing I discovered it was just pissed because the measuring tray did not have the full tray on it (applying a certain amount of weight). Placing an object, pliers in this case, on the scale are powering back up it turned on completely and successfully. I just now need to design a high quality linear supply for it for +5V, -12V and +12V voltages.

It's interesting to note that this small wire-wrap wire:

Weighs a whole .053 grams. :D (uncalibrated of course, so give or take +-.01 grams)

One sweet ADC, National Semiconductor ADC08100

I spent this weekend playing with a few analog to digital convertors I have been meaning to try out, one of which is the National Semiconductor ADC08100. The ADC08100 is an 8 bit 100Msps ADC with very low power operation. To test it out I have it clocked from a PIC18F4520 running at 40Mhz and has the output being displayed on a pair of HP hexadecimal displays. Input is coming from a small Murata pot whose voltage can be adjusted over the set range of 0V to +3V.

I plan on using these ADCs for everything from video capture in basic machine vision systems to any type of ADC that needs high speed accurate conversion that can offload the ADC operation from the microcontroller itself.

Texas Instruments TMP100 Temperature Sensor

When looking for cheap and accurate temperature sensors for the next up and coming near space balloon project, I came across this great little device from TI. The TMP100. Tonight I interfaced these little devices with a PIC18F4520 via I2C and everything is working perfectly.

Some basic info about this sensor:

Resolution: up to 12bit

Temperature range: -55 to +125 degrees Celsius

I plan on using two of these to monitor temperature, one for the inside electronics temperature and one for the outside environment temperature.

TCM8230MD Camera Images Within Reach

Last night I was able issue a start command over I2c to the TCM8230MD camera module to have it start sending images. I'm now receiving valid YUV 422 data off of the 8 bit bus along with the necessary clock and sync pulses.



This camera is definitely not the easiest thing to work with. The datasheet is not as clear I would have liked and the timings necessary for the startup sequence took a little bit longer to figure out than I had expected.


The next step will be to be to send the camera a few more control codes to lower the frame rate and resolution to get the data rate to a more manageable level for the pic. I'm hoping to capture and display my first usable image over the weekend.

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.