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.
--
Friday, May 25, 2012
Tuesday, May 22, 2012
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:
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
--
 |
| Top |
 |
| Bottom |
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
--
Wednesday, May 16, 2012
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:
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.
--
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.
--
Monday, May 14, 2012
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:
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.
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.
--
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
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.
--
Saturday, May 12, 2012
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:
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;
Should return something like the following:
The "help" command is the "?" mark:
echo "?" > $D; sleep 1; echo
For my Real Time Clock testing:
Note: For the example, the above BP command requests the seven values from my DS3231M Real Time Clock and displays the results as:
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.
--
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:
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
--
Friday, May 11, 2012
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).
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
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.
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.
--
 |
| The Two New Parts |
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 |
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) |
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.
--
Friday, May 4, 2012
Murphy - My Consultant
Murphy and Assumptions as Consultants - will make projects more difficult.
Several weeks ago, I started designing a generic User Interface (UI) for my Propeller Microprocessor Projects (see previous post). The UI was planned to be an adaption of circuits that I am already using with current project (see previous post). The new adaptions included I2C Converters and stand-alone on-board 3.3V Regulator.
The UI board layout was sent for Manufacture on May 14 and was just received a few days ago. I was anxious to load a board with parts. My initial strategy was to load a board with as few parts as necessary to do some initial tests. But once I started loading, I decided to load all of the parts, starting with simple resistors and capacitors (what could go wrong? :-). Prior to installing the Major Expensive Components, I checked the LED circuits and did some simple resistant test - ALL looked good.
Then, In steps Murphy and Assumptions:
When I went to my parts storage bins for the 3.3V regulator, I could not find a SOT-89 3.3V regulator (similar to my often used L78L05 5V SOT-89 regulator). Maybe I have never had one, or maybe they do not exists with the foot print I used in the layout. But my board, as designed, defiantly needs one. When I laid out the board, I assumed they were in the bin. Now I will need to check availability and order something that will work.
When I went to my parts storage bins for the MCP23017 Dual I2C I/O Expander (16 pins of GPIO), I could not find them. I know they exist, and I thought I had order several, but I could not find them. My board as designed needs two. For this design and layout, I decided to use the Dual I2C I/O Expanders (similar to the previous used single expanders). They require less space for the available output pins, and they require one less device address on the I2C bus. So, now I need to order even more parts, to finish the build.
Most of the parts are installed, on the new UI board and is ready to test, but now must wait for the last few parts to be ordered - Thanks Murphy and Assumptions !
This iteration of the UI board was never planed to be the final form, it was just a functional test. I knew some modification maybe necessary. But that is the way it is, when building without breadboarding first.
UPDATE
I found the SOT-89 3.3Volt Regulators at Mouser, and they will be on order soon, along with a few other parts.
-
Several weeks ago, I started designing a generic User Interface (UI) for my Propeller Microprocessor Projects (see previous post). The UI was planned to be an adaption of circuits that I am already using with current project (see previous post). The new adaptions included I2C Converters and stand-alone on-board 3.3V Regulator.
The UI board layout was sent for Manufacture on May 14 and was just received a few days ago. I was anxious to load a board with parts. My initial strategy was to load a board with as few parts as necessary to do some initial tests. But once I started loading, I decided to load all of the parts, starting with simple resistors and capacitors (what could go wrong? :-). Prior to installing the Major Expensive Components, I checked the LED circuits and did some simple resistant test - ALL looked good.
Then, In steps Murphy and Assumptions:
When I went to my parts storage bins for the 3.3V regulator, I could not find a SOT-89 3.3V regulator (similar to my often used L78L05 5V SOT-89 regulator). Maybe I have never had one, or maybe they do not exists with the foot print I used in the layout. But my board, as designed, defiantly needs one. When I laid out the board, I assumed they were in the bin. Now I will need to check availability and order something that will work.
When I went to my parts storage bins for the MCP23017 Dual I2C I/O Expander (16 pins of GPIO), I could not find them. I know they exist, and I thought I had order several, but I could not find them. My board as designed needs two. For this design and layout, I decided to use the Dual I2C I/O Expanders (similar to the previous used single expanders). They require less space for the available output pins, and they require one less device address on the I2C bus. So, now I need to order even more parts, to finish the build.
 |
| Prop UI |
 |
| UI With Traditional LCD Display ( Blue, Purple and Green Boards, who's idea was that? Murphy!! ) |
 |
| UI With Alternate Display |
UPDATE
I found the SOT-89 3.3Volt Regulators at Mouser, and they will be on order soon, along with a few other parts.
-
Tuesday, May 1, 2012
Salmoncon 2012 - Fox Hunt
This is the Salmoncon 2012 Fox Hunt Invitation/E-mail sent to the Puget Sound QRP (pQRP) Group.
UPDATE: I added some selected follow-up.
--
UPDATE: I added some selected follow-up.
Hello All,
This is a survey of people who are planning to attend Salmoncon 2012, and interested in a HF Fox Hunt.
If interested, please respond with the type of portable HF Receiver(s) that you will use for the Hunt?
Salmoncon Pavilion - MAP: http://goo.gl/6DywX
Our Current Plans:
The current plan is to hold the Main Fox Hunt Events on Saturday July 14th.
We may also hold several warm-up events.
For the Hunt, you may find; a loop antenna, camera, headphones, portable GPS, and/or compass, very useful for some of the events.
Rules, Frequency and other details will be provided the day of the events.
Prizes will be awarded !
Several event reminders will follow on this list.
BTW: Hardware or Item Donations for the Event Prizes are encouraged.
Regards,
Eldon Brown
72 - Eldon - WA0UWH
Eldon,
I would really enjoy a fox hunt, but have neither an antenna or (I don't think) an appropriate receiver.
Sounds like we might solve the antenna problem as a group. A great project!
Maybe you could give us an idea as to what band(s) your looking at to do this on???? I'm thinking right now that my IC-706 would work but be rather heavy and awkward. Maybe a homebrew rx is in the cards.................
Alan K6ZY
Alan, and ALL
For the HF Fox Hunt, we will be in Near Field area of the FOX, and therefore shielding is almost more important than a good Antenna. Although with a well shielded Rig and a Loop Antenna, and using triangulation obtained from the Null (through the center of the Loop) should help provide good directional information, and using field strength as a indicator of proximity. Another suggestion would be use something like a KX3 or FT-817 with a dummy Load at the antenna, using your body for shielding to get direction and proximity.
Personally, I would use a cheap (or small) radio within an Aluminum Foil wrap, with a very short exposed antenna, which could be shielded with my body. Others may have better suggestions.
Some of the most successful Near Field Hunters, use the least sophisticated gear, others that are real "DF Hounds", use very extensive gear on Long Distant Driving Hunts. This is a short, near field hunt.
We will have several FOX Hunt events, so different techniques can be tried.
This is a "HF" FOX Hunt, but I would plan for maybe something around 20, 30, 40 meters. Most P&C and Salmoncon attendees have seen how small and low power my transmitters can be, and therefore should maybe expect some very weak signals.
To be fair, I can not provide any more details until the event.
Happy Hunting !
BTW, with all of my talk and preparations, Tess has become very interested in this event. She can not wait to see the FOX, maybe it will be as exciting as her Ball. Unfortunately, I think she will be disappointed :-)
Regards,
Eldon Brown
--
Subscribe to:
Posts (Atom)