Part Quest

On some of my projects I have used a DS3231M Realtime Clock (RTC) which needs a voltages supply to maintain itself during equipment power down.

3012 Coin Cell Clip

The 3012 Coin Cell Clip is small, easy to install, and use.  The two small solder tabs are used to attach the clip to the PCB

The exposed clip is positive (+) and a user supplied pad on the PCB is negative (-).

DipTrace 3D

An example of usage and required negative pad can be seen on the DipTrace 3D layout.

CR1632

The clip will hold a CR1632 3.3Volt Cell. Other clip sizes are available to fit other batteries.

Note: The included links are to Mouser pages, but other vendors may have the same part. Other sources can be found via FindChips. I am not associated with Mouser, I am just a happy user.

--

Part Quest

I have been trying to find the part number of the Crystal Pin Socket for the Propeller. I want to use similar pin sockets for my small add-on Huff-n-Puff TCVCXO daughter board (see previous posts).

My daughter board was designed to fit existing holes on the Propeller Protoboard. Three of the five pin (holes) already have the correct Voltages/Signals present ( +3.3v, GND, and Xtal Input), only the two I2C lines will be jumpered as necessary.

Use of the very short Crystal Pin Socket will allow for a very low daughter board profile. In the past, I have used salvaged machined DIP socket/pins that stood up about 1/10 inch above the board, their hight make the daughter board a little wiggly.

Crystal Socket - H3153-50
http://goo.gl/NrRrf

I asked the folks at the Parallas Propeller Forum if anyone could provide the exact part number that was used in production. Several user suggestions were provided, and then with a lot of minuet specs comparing, I think I have found an acceptable part - I now have several on order.

Only receipt of the order will confirm. Note: the photo suggests the part is longer than its specs (perceived aspect ratio) . The part fits into a 1.0mm hole and its over all length is only 3.61mm. The Pin Socket accepts a 0.51mm wire pin, similar to those found on small crystals, at 0.47mm dia (measured).

This will be a great (but very small) part to be added to my collection, for this and future projects.

I enjoy chasing/tracking down "small and interesting" parts for my projects. I have blogged about many other parts in the past, maybe it is an expression, or a long lost need, of a "hunter/gatherer". I may make this a re-occurring theme on my blog - Part Quest.

--

TCVCXO PCB Received from OshPark

I received my TCVCXO PCB back from OshPark.com (see previous post) This board with be used with the Parallax Propeller as a Crystal replacement. It is a Tiny board, only 0.365 x 0.650 inches (0.062 inch material). The PCB layout for this project was created using the DipTrace Schematic Capture and PCB Editor.

I attempted to take photos with the same origination as the previously posted 3D models (which proved to be more difficult than I thought :-) Here is the results. More "Light" is needed - I think I would like to build a "photo shoot light box" for taking future photos.

Top Side

Bottom Side

Now it is time to load and test this thing.

---

UPDATE:
OK, now I am envious, I just read Dave Richards -AA7EE,  post of his gorgeous Photos of the Air Variable Capacitor. Thanks Dave, I learned a few things!

UPDATE:
Dang! . . . I got the pin hole alignment wrong, I need to re-layout the board, again  :-(

--

Prop UI Progress

It has been a grueling 18 days since my last post. The Propeller UI Board that I have been working on has provided some real challenges. All of the UI Board peripherals on wired to the same I2C Bus. Which means my standard method of debugging the code via a working a Display was not available. The Bus Pirate and a new VGA Display was necessary, which had to be configured which added to a already steep learning curve.

UI Board Installed on the Prop ProtoBoard

Coordinating and developing the Objects for the six UI peripheral was a challenge The task was a little easier thanks to Jeff - KO7M, who helped with the I2C Bus to Parallel Expander Code, and the necessary modification to his I2C LCD Driver.

Currently ALL six UI peripherals, which are on the same I2C Bus, are working in concert with each other without perceivable delays for; the two Rotary Encoders, four Push Buttons, eight LEDs, a Realtime Clock (RTC), and the LCD Display. Also there are the Sound (beeper) and the three I2C POTs that control the LCD Backlight Brightness, LCD Contrast, and Sound Volume - all working seamlessly together.

One of the Software Driver Goals is make moving the Programmed Display from LCD to VGA (and back) without difficultly, other than the obvious which are the Number of Lines and Number of Characters Per Line.

Note: my new I2C Huff-n-Puff board (see previous blog) will also be added to that same I2C Bus (external to the UI).

I had to learn a few new Propeller SPIN tricks to make it all work. Specifically how to coordinate and use "Locks" for Objects and COGs.

Only a few modifications were necessary to the UI PCB. I have already started the re-design with modifications for the next PCB. I will be adding more Pull-ups, and 0-Ohm Jumpers to make separation of circuits easier for future development and debugging.

I have several ideas and better organization of the current code, but that will wait for another day.

It has been a lot of fun. Now on to some projects that will use the Prop UI Board.

First, on the list to port are; my QRSS and WSPR Beacons, Jeff's Keyer, the Huff-n-Puff Freq Standard, and several other Prop Projects that are planned to use the new UI.


--

UI Project Update

Readers of this blog know that I have a Propeller UI Project in progress. The custom board that I created for that has been received and loaded with parts. Some simple parts of the board appear to function as can be seen, tested, and exercised with a clip on Bus Pirate. That is, the Real Time Clock (RTC) and the LED driver seem to work as expected.

The major elements of the board; which include the LCD Display and Knobs, have NOT been tested yet. Their control is complex enough that it will be necessary to tested them in conjunction with the Propeller processor. The eight interface wires for the connector have been installed on the Prop board.

Normally testing a new peripheral device is not difficult, but when the test and debugging involves the Display, which is used to Display the test results, it is problematic. It is a classic "Chicken and the Egg" problem.

To solve this dilemma, I am waiting for an ordered KVM connector for the Propeller (which should be here today). The KVM connector will allow the Prop to be connected to a dedicated VGA Monitor for display of debug information without the need of the LCD or Knobs.

Actually, I have been a little lax here, I could have used the USB TTY connection to do debug and testing, but in my Ubuntu Workstation environment using a single interface path for both; Prop Programming, and Displaying debug information, is a pain. Therefore I have been waiting for the KVM. And, I have also been diverted off to other projects and responsibilities.

My goal is to have UI working for Show-n-Tell at the next pQRP P&C meeting.

--

New TCVCXO PCB with OnBoard I2C Control

With the very good results of the TCVCXO Propeller Master Clock experiments (see previous post), I decided to rebuild the PCB to include the I2C Pot and Filter Caps on the same board. This is the expected results when produced:

Top

Bottom

Note: This board is very small, it is only 0.365 x 0.650 inches. The above images are local screen prints of DipTrace 3D output.

I often use Homebrew Tone Transfer Method to produce my PCB's, but I use DorkBotPBX to produce my manufactured boards.

Laen (the owner of DorkBotPBX PCB) is now using a new web site: OshPark.com and using a new interactive process for submitting PCP designs. The new web site was introduced at the Bay Area Maker Faire 2012.

The site accepts Eagle and Generic ZIP'd Gerbers (as exported from DipTrace). The interactive process receives the ZIP'd file and renders the design, showing the individual layers and what the board will look like when finished (in Laen's standard Purple color). Very Cool.

The price is the same, $5.00 per square inch for a set of three, two sided boards.

Check it out at: OshPark.com

--

The Results Are In

 . . . . I think.

Last night I took my Huff-n-Puff driven Master Clock for the Propeller Microprocessor to Jack's Homebrew Amateur Radio Meeting, to compare it with his GPS Disciplined 10MHz Standard (see previous post).

Jack had problem getting his equipment ready, the 10MHz Standard was questionable and he had not built the Phase Comparator/Detector as of yet. We proceeded anyway to look at his and my 10MHz signal on his Dual Trace Scope.

I had previously miss-adjusted my TCVCXO to a slightly lower frequency, so that we could watch the Huff-n-Puff circuit in action. Jack's 10MHz signal was connected to one Scope Channel (and driving the Sync), my signal was on the second channel.

With the Huff-n-Puff still turned OFF, it was obvious that my signal was  marching across the Scope screen, right to left (indicating a lower freq). We waited a short period to allow my GPS to be acquire it's satellites, and then I turned ON the Huff-n-Puff function.

Like magic my Scope signal slowed down its march across the screen as the Huff-n-Puff derived TCVCXO correction voltage was being applied. The I2C POT displayed value went from 0 (wiper center) to +12 in about 45 seconds. After a little more settling, it stopped on +14, the two 10MHz signals were almost the same, But not perfect.

At this point Jack's Standard was still suspect, because we could not verify that it was working with the internal GPS receiver and in Sync with the satellites. We were not familiar with the computer program that provided information and therefore unsure. We were just going to assume that it was working.

Jack did not have his detector built, so we did the next best thing. We put the the scope in "Signal Add" mode, so I could count the "in and out" of phase condition by observing the screen.

With Jack's stop-watch, I counted 50 nulls in 141 seconds:

50 / 141 / 10M = 0.0000000354 => 35 ppb

At his point, the best that we could do was; state that we were close in Frequency, by 35 ppb (parts per billion) or 35 x 10^-9 (I think I have the math correct).

This morning I received an email from Jack, stating that he has learned more about his Standard and its operation, and now he thinks his 10MHz Standard was probably working with the GPS and therefore we can assume it to be correct, or within reported/stated accuracy In either case, we will do the experiment again, maybe next month.

If our initial results are correct, then my Huff-n-Puff has Out Performed my expectation by 15 ppb, as suggested on my previous post were I had calculated 50 ppb.

I am a happy camper :-)

I really should rename this circuit, because it is NOT a traditional active/passive Huff-n-Puff circuit, it is mostly in Software (with only a small computer controlled POT). Maybe, I should  call it a: Software Defined Huff-n-Puff - or SDHnP !

With this configuration I should be able to provide very accurate WSPR and QRSS signals - That is the GOAL.

---

UPDATE
The method used to compare the standard with my TCVCXO did not take into account the direction (sign) of the drift between the two, and therefore the "absolute" frequency may be better than the reported 35 ppb. About half of the time my TCVCXO signal appeared to change directions relative to Jack's Standard. More experiments and some research is necessary to understand what was observed.

--

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 

 --

Parts Received and some Shop Work

I received parts from Mouser to complete the Propeller User Interface (UI). I was missing two I2C I/O Expanders and 3.3V Regulators (see previous post).

The Two New Parts

So far, I have been using the BusPirate to test the four devices on the I2C circuit, the LEDs and the Real Time Clock (RTC) works as expected.

The LCD and the Knobs which are on one of the I/O Expanders will require some new wiring on a new Propeller USB Protoboard that I plan to use. Software is about the only way to do real tests here.

The one part that I can not get to work is the I2C POT, which will control the Backlight and sound volumn, the POTs are not necessary to do the initial checkout. And, maybe I just have not found the magic that makes it work.

More testing needed.

A Day of Shop Work

Parts being Cut

While looking for my photos of the UI build progress, I found some photos that I had taken a few days ago. I helped my Son cut-out some parts using my PlasmaCAM. It was a long day, we cut about 96 square feet of parts out of 3/16 inch sheet steal. It is a fun process to watch.

When working correctly, the PlamaCAM creates a lot of dark smoke, which tends to collect on everything (nasty stuff). I was wondering what the smoke actually is? The only ingredients in the process are "Electrons, Air and Steel".  Although, at 10K degrees, almost anything could be being created.

Lots of Sparks and Smoke
(more smoke, less sparks,
makes for cleaner/better cuts)

I took some of the Smoke (black dust like stuff) that had settled on a surface, to my Lab where I could look at it under the Microscope at 30X. The smoke dust looks like very small, perfectly formed, black spheres (like ball barrings). They seem to be magnetic.

Later, I discovered they are very thin hollow spheres! Smashing a single sphere releases something that effect others in close proximity. Maybe they contain compressed gas, or maybe they release an electric charge, or collapsing magnetic field.

More investigation needed.

--