Saturdays Projects

Yesterday, Jeff - K07M stopped by and we worked on some projects.

Jeff wanted to practice welding. I have both TIG and MIG welders, so we spent some time "gluing" some Aluminium together with TIG, and then some steel with MIG. With a little practice Jeff was able to "lay down" a reasonable bead. Welding is a "art", therefore practice is almost always necessary to stay proficient.

We then moved into the E-shop where we diagnosed the failed BusPirate (see previous post), we quickly isolated the problem to one pin of the Microprocessor (PIC24FJ64GA). I suspect that the failure was the result of an ESD (Electrotatic Discharge). The failed pin is directly connected to a clip lead on the end of the test cable. I have been a little lax regarding ESD abatement in my E-shop. I need to acquire a bench-top anti-static mat and maybe some anti-static floor spray.

A last minute project before Jeff left, was to "fix" my long-wire antenna haul-up cord used for the end support over the tree. The long-wire has been up for two years and therefore the support cord has (most likely) cut into the limb, and then the tree has retaliated with pitch to glue it in place. Regardless of the tree's desire to hold the cord in place, I need it to be free for Antenna adjustment or configuration changes. I had attempted to bring down the Antenna before, but could not pull hard enough to break it loose.

Our goal was to pull until; the limb broke, or the sap let go, or the cord broke. After wrapping the cord around a 2x6, like oxen, we were able to pull it free. The cord is tied into a loop, so that I can pull-up or pull-down as necessary. To alleviate future problems, we inserted the cord into a twenty foot section of 1/4 inch Polypropylene Tube (refrigerator ice-maker tube), tied a knot and pulled the tube up and over the branches where the cord rests. Hopefully the 20 foot section of tube so draped over the branches will stay in place, and protect the cord from the tree.

The 300 foot long-wire is now again at about 90 feet AGL.

Thanks, Jeff, for the help !

---

UPDATE
When I wrote this blog entry, I did not realize Jeff had blogged the same project day, check it out at: http://goo.gl/LuZE0S  :-)

-

Minima - VFO Troubleshooting - Cont'd 3

After four days of extreme frustration, while troubleshooting my Minima VFO Module (see previous posts), there is success!

My friend Jeff - KO7M came by today with known working tools (BusPirate) and parts (Si570). We had been troubleshooting my VFO problem via e-mail and over the phone, but we were not getting anywhere.

Jeff at the Microscope

The problem came down to, two (2) simultaneous failures, one in my BusPirate (BP) and one in my VFO Module that I was testing.

1. My BusPirate fails to generate I2C SCL (clock) signals, even though many other functions seamed to work. Without an SCL signal data can not be received by a Device Under Test (DUT), even though the BP can receive Data using the same SCL wire from the DUT.

2. The failure of my VFO was the Si570 itself, it would not accept I2C data or commands, even though it produced RF on the output. It is DEAD.

Before Today

Before today, I had created an Si570 BreakOut Board (see previous post), with just the Si570 and Header pins. My intent was to verify that the BP was working as expected, but because there are also wires, clips and connectors that could have failed results were inconclusive.

Si570 Breakout Board

Si570 Breadout Board

At this point I still could not determine if the failure was in the BP or had I damaged another Si570. So, I built a second Si570 Breakout Board. But alas, still nothing seemed to work.

Today - Jeff to the Rescue !

With Jeff's known working BP we quickly determined my VFO Module (i.e. Si570) was bad. Other I2C devices; the two Si570 Breakout Boards and a Real Time Clock Module (RTC) all work as expected.

Because yesterday I had used my last Si570 on the second Si570 Breakout Board, I could not repair the VFO Module. but we could build an Si570 Breadout Board Adapter  that connects between the Breakout Board to the Minima CPU Module. I had previously designed and did a layout for the Adapter with DipTrace, for just such an occasion. We spent the rest of the afternoon building and testing the Adapter Board.

The Adapter Board tested correctly with Jeff's BP as we hoped. It also tested and worked with the Minima CPU Module.

Adapter Board Connected to the Minima CPU
and a Coax Cable, the Si570 Breakout Board in the Foreground

Stacked and Ready for Testing

Now all Minima Modules worked as expected, we checked for a varying frequency while tuning, we estimated on the oscilloscope 20MHz at the low end, and 50MHz and the high end while Tuning across the (0-30MHz) HF band (for a 20MHz IF).

34.2MHz  (14.2+20) As Shown
with 10X Expanded Sweep Scale

Minima CPU Module and
Temporary VFO Module 

I am a happy camper - Thanks Jeff, for the help !


I can now continue my experiment Minima Transceiver Project.

I need to order a few more Si570's, and a new BusPirate (or troubleshoot and fix it).

--

Minima - VFO Troubleshooting - Cont'd 2

Well, that did not work, see previous post.

I created a Si570 BreakOut Board with minimal configuration to have something that I can test and verify my BusPirate. I got the same results with the new board, the I2C Address Scan returns nothing.

I must have something wrong with my use of the BusPirate.

The Si570 BreakOut Board that I created is a little different than previously posted, it now will fit in a standard 600mil socket. Which means that it is a little bigger than the original 500mil config, but should be more useful.

Here are some of the build details.

The New 600 mil Layout
As Designed with DipTrace

The size of the board is about 0.5x0.7 inches and is 0.032 inches thick, with four via's (40mil pads, 10mil holes).

You can almost see through the PCB material, the two sided image alignment is reasonable.

A Panel of 
Double Sided Toner Transfer PCB's after Etch
(Showing the Back Side)

This is the results after: Cut, Solder Wipe, Holes Drilled, and Parts Loaded.

The Finished Si570 BreakOut Board

When I get the BusPirate operational issue sorted out, this should provide a simple verification test. It will also be a useful part for ProtoBoard experiments.

--

Minima VFO - Troubleshooting

Last week I was on Jury Duty, and therefore there was little or no time for my Hobby Projects.

But now, I need to continue troubleshooting my Minima VFO which is reporting an error on the LCD display. The error at program reset is: "Si570 comm error".

As programmed, the Arduino Sketch seems to ignore the error and continues with normal execution. If I remove (unplug) the VFO Module the program "stops" and does not get past the initial start-up stage, and therefore it appears that there is "some" communication with the Si570 (or at least the Pullups work).

My friend Jeff - KO7M, suggested using my BusPirate to ensure that the Si570 was set on the correct I2C address as published and working as expected. This will be easy because of the modular construction that I am using, tests can be conducted on only the VFO Module. This testing would be much more difficult (but not impossible) if everything was built on a single board.

Minima VFO connected to the BusPirate

I am glad I blogged my previous use of the BusPirate, it helped me to remember the commands. I think I will expand that post to be more complete.

Well, maybe it is NOT so easy, because so far, I have not found the VFO problem. In fact, I do not seem to be able to do a simple "scan" for the I2C address.

More troubleshooting needed !

--

More Huff-n-Puff

I have been working several days, trying to get my Huff-n-Puff circuit to properly control the TCVCXO Oscillator, which is used as the Master Clock replacement for my Propellers.  When I started the experiment, I thought for sure it would be an easy task.

The plan was, to use a one second square wave from a GPS to compare with timing from the Propeller, the output would drive an Double Gang RC circuit, and that would provide a DC voltage to steer the TCVCXO to make the output Frequency as accurate as the received GPS. My goal was to use only passive components.

It worked, but much less than optimal.

For the Passive RC circuit to work correctly, components would have to be optimized:

• for RC filtering
• for low input impedance for the Charging Circuit
• for high output impedance to avoid Discharge
• yet, for low output impedance to provide drive to the TCVCXO

There were just too many things to consider while trying to make them all work during Startup and Stable Run conditions. I got just enough working to validate the Huff-n-Puff goal, but this circuit was not going to be successful.

To continue this approach, active components would be needed.

My new plan was to introduce two OpAmps, one to sample-n-hold the output from the comparator, a second to provide drive for the TCVCXO. This circuit could be contained within one chip, but I really did not want to build it.

Yet, another approach.

While working with another project (my UI) I had planned to provide control of the Backlight and Beeper Volume via a I2C POT. A simple I2C command sets the POT wiper value - sweet !

The I2C POT that I planned on using was a MCP4018. Late in the UI design and after ordering some parts. I noticed that you can NOT have more than one MCP4018 on a single I2C Bus (What?? only one I2C address??). I had to change the design to Quad I2C POT MCP4441, which contains 4 POTs, plus the chip provides address pins so as many as eight can be used on a single I2C circuit - very nice. My UI circuit design was modified.

Now, while thinking about my Huff-n-Puff problem, it came to me that I could replace all of the above planed active OpAmp circuits with just one MCP4018 I2C POT, that would be controlled by the Propeller (I only need one POT for this test). The POT has wiper value storage and the proper output impedance to drive the TCVCXO, via a simple RC and resister divider circuit (similar to the original passive circuit, but smaller values). The comparing, filtering and tracking will all be done in software - easy to do.

CircuitLab

The new I2C POT Huff-n-Puff was installed, and checked with the Bus Pirate. A little change to Propeller SPIN code (and I2C driver) was all that was needed to make the circuit work! The I2C driver needed to be modified because, the MCP4018 does not use internal Register addresses, only one address byte followed by one data byte.

Success

It is now fun to watch the I2C POT adjust the voltage on the TCVCXO to correct the Frequency of the Propeller's Master Clock, and then continue to stay locked onto the GPS. The I2C POT wiper's numerical position is displayed on the LCD.

Tomorrow night I plan to take this new circuit to Jack's Amateur Radio Homebrew Meeting where a Frequency Standard is available and can be compared. I hope this all works as planned. If my calculations are correct, my Propeller Master Clock should now be within +/-50 ppb of GPS Standard Frequency.

I do not expect this effort will do anything to correct inherent PLL jitter, it will only improve the Output Frequency Accuracy.

--

Linux and the Bus Pirate

The last few days, I have been using the Bus Pirate (BP) to debug and test my I2C User Interface for the Propeller.

After reading all of the Doc's and suggestions on how best to use the Bus Pirate on a Linux system (I use Ubuntu), I was under whelmed. The current suggestions include running; a  "minicon" Terminal Window connected to the USB port (i.e., /dev/ttyUSB0).

Some Terminal Windows are kind-of-dumb (not all), they do not know how to properly support "tabs", making the results from the BP kind-of useless. Especially the results from the BP I2C "v" command

And, as a Linux user, I want an easy-to-use BP command history recall stack. There is nothing worst than attempting to re-type (or cut-n-paste) a previous long BP command.

I wanted something easier - and there is something for free; (assuming you do not mind some supporting text around your BP command).

On your normal Command Line Window, at the Prompt, type the following. In this example, the Bash Shell is being used:

$   D='/dev/ttyUSB0'; cat < $D & stty 115200 < $D

This "cat" background task reads and displays data from the BP.

Then anything you direct to the "$D" port, is executed by the BP as a command;

$ echo "v" > $D; sleep 1; echo

Should return something like the following:

Pinstates:
1.(BR) 2.(RD) 3.(OR) 4.(YW) 5.(GN) 6.(BL) 7.(PU) 8.(GR) 9.(WT) 0.(Blk)
GND    3.3V   5.0V   ADC    VPU    AUX    CLK    MOSI   CS     MISO
P      P      P       I     I      I      I      I      I      I
GND    0.00V  0.00V   0.00V 0.00V  L      L      L      L      L

The "help" command is the "?" mark:

echo "?" > $D; sleep 1; echo

For my Real Time Clock testing:

$   echo "[0xD0 0][0xD1 r:7]" > $D; sleep 1; echo

Note: For the example, the above BP command requests the seven values from my DS3231M Real Time Clock and displays the results as:

I2C START BIT
WRITE: 0xD0 ACK
WRITE: 0x00 ACK
I2C STOP BIT
I2C START BIT
WRITE: 0xD1 ACK
READ: 0x20 ACK 0x22 ACK 0x07 ACK 0x04 ACK 0x10 ACK 0x05 ACK 0x12
NACK
I2C STOP BIT
I2C>

The values decode as: Time= 20:22:07, WeekDay= 04, Date= 10/05/12

If you want to re-execute the command, it is in the normal Unix Shell History command recall stack.

This makes my life easy, and it does not require a special minicom Terminal window to configure.

When finished; remove the "cat" command with normal Unix "kill" commands, or just close and reopen the window.

Yes, . . I know, for the non-Unix type people, the above looks like gibberish, but it works, and it works well.

---

UPDATE
I replaced the "cat" line above with the following, which makes the output much easier to read by breaking the lines into individual commands. Note: the "]" (stop) is no longer displayed, it is replaced with a Newline.

D='/dev/ttyUSB0'; cat < $D | tr "]" "\n" & stty 115200 < $D 

 --