Saturday, October 13, 2012
Monday, September 24, 2012
MSK is basically FSK with the shift set to ½ the baud rate. Realistically this is the smallest shift you can use without trading off transmission speed. At 31.25 baud in MSK your keying frequency shifts are 7.8125 either side of your transmit center frequency. If you think of the phase of a carrier that is 7.8125 below the transmit center frequency, it will lag by 90 degrees after 32 mS, and at 7.1825 above, it will lead by 90 degrees after 32 mS, so MSK appears to be functionally equivalent to BPSK while using +90 and -90 degree shifts instead of 0 and 180.
I like MSK/FSK when it comes to transmittter design as there is no amplitude modulated component to the signal, greatly simplifying transmitter design as non-linear techniques can be utilized. I wonder however if there is a price to be paid on the receiver side when trying to decode the signal at low signal levels and in trying to keep simple receiver designs locked onto the signal.
Sunday, September 16, 2012
PSK31 is a digital communications mode which is intended for live keyboard-to-keyboard conversations, similar to radioteletype. The data rate is 31.25 baud (about 50 word-per-minute). PSK31's ITU emission designator is 60H0J2B. It uses BPSK modulation without error correction.
Instead of traditional frequency-shift keying, the information is transmitted by patterns of polarity-reversals (sometimes called 180-degree phase shifts). One way to think about this would be to swap antenna terminals on each phase reversal.
The 31.25 baud data rate was chosen so that the system will handle hand-sent typed text easily. There is a problem with PSK keying, namely the effect of key-clicks. If hard keying of phase reversals were done, the result would be a very broad emission. The solution is to filter the output or to shape the envelope amplitude of each bit, which amounts to the same thing.
In PSK31 a cosine shape is used. Phase reversals are done at the minimum amplitude points. The spectrum during a continuous sequence of polarity reversals at 31 baud will consist of two pure tones at +15/-15 Hz from the center frequency and no splatter. A binary 0 is represented by a phase reversal and a binary 1 by no phase reversal.
My initial implementation will be to generate PSK at audio frequencies and later to investigate strategies to generate at RF frequencies. The audio tone chosen is 1 KHz constructed from 32 eight-bit samples at full amplitude per cycle. The period of a 1 KHz tone cycle is 1 millisecond. Each of the 32 samples per cycle has a period of 31.25 microseconds. The audio samples are eight bit values from $00 - $FF with the zero crossing value at the midpoint $80.
The PSK31 character bit time is 32 ms constructed of 1024 samples. A binary zero is represented by a phase reversal while a binary one is presented by the absence of a phase reversal. Characters are encoded with a variable bit length code (varicode) where the length of each character is inversely proportional to the frequency of use. Characters are encoded with a bit pattern where there are no sequential zero bits. Two zero bits in a row signify the end of a character.
In order to implement the ramp up/down scenarios at phase reversals, I have constructed a couple of tables of sinusoid information. The first consists of 512 table entries defining the 16 cycles of ramping up from zero to full amplitude. I have plotted the data in Excel as follows:
Once I get up to full amplitude, I use a separate 32 eight-byte table consisting of a single sinusoid. For a binary zero, I ramp down (512 samples) by processing the above table in reverse, reverse the phase and immediately ramp back up again (another 512 samples), this time processing the table in the forward direction. For a binary one, I use the 32 eight bit sample table below and repeat it 32 times for 1024 total samples.
The PSK31 engine is a PASM module that runs continuously in its own cog. Once started, it will begin playing a series of double zeros (continuous phase reversals) indicating there is no data to send until the cog is stopped or a data string is passed to it. A string buffer is passed to the cog with the first four bytes containing the length of the string, the data bytes following immediately.
The audio output is generated using PWM generated from the cog's counter in Duty mode. The zero crossing point is represented by a 50% duty cycle. A simple RC low pass filter is used to clean up the audio before amplification. Alternatively an external operational amplifier could be used to accomplish the same task. I am using a Propeller demo board which has a nice fixed gain stereo headset amplifier connected to pins 10 and 11 of the Propeller board. This configuration works quite nicely. Here is a partial schematic showing this setup:
I have completed the PSK engine with the exeption of the ability to pass in a string to send. For now I have hard coded a CQ message for testing purposes. I have been able to decode the audio using several PSK applications on both Windows and Macintosh platforms. A little more code and I think this little beacon will be ready to integrate with my collection of other beacons. I have implemented a $00 - $7F varicode table to translate ASCII characters into varicode before transmission.
Next I hope to investigate the possibility of implementing an RF solution rather than an audio solution.
Saturday, August 25, 2012
Sunday, August 19, 2012
So, I took the weekend off and spent most of it sleeping. Tried to get the plane out and do some flying, but I just didn't feel like I had gotten sufficient rest to be safe about it, so the cub stayed in the hanger. Maybe next weekend.
I have to dig out the shack and un-bury it from all the crap that has stacked up around me. Hopefully I can get back to building things again.
Friday, May 18, 2012
Opening the box we find an accessories tray with power cord, USB cable, CW paddles, allen wrenches and so forth. Elecraft does a nice job packing things up for shipment. In one of the envelopes was a "Packed with care by Stephanie" slip. :) Thanks Stephanie!
Carefully wrapped in a plastic bag as well as bubble wrap, surrounded by cardboard spacers was the KX3.
As they say on the EEVBlog, "Don't turn it on! Take it apart!" Here we can see the soul of the machine and a pile of AA cells later, we fired 'er up! I love how it comes up on all the QRP CW frequencies out-of-box.
Spent a little time just tinkering with the receiver last evening. This is one sweet ride of a CW rig. Today hooked up the paddles and spent some time adjusting them and practicing with the sidetone only. Hope to put it up on the air sometime this evening or this weekend at the latest.
Thursday, May 3, 2012
Wednesday, May 2, 2012
This is a 60 KHz WWVB time receiver module and the associated loop antenna. I plan to play around with this as an alternative time source to a GPS receiver for syncing beacon signals such as is needed with WSPR. This was obtained from the good folks at PV Electronics in the UK. If anyone has any experience with these modules, I would appreciate any insights as I am going at it totally cold.
Tuesday, May 1, 2012
I got to do a bit of SWLing but had nothing with which to transmit. Probably ok given my 18 hour day work schedule.
I am off to Florida Thursday for my son's college graduation and then travel should slow down for a bit.
Jet lagged in Seattle...
Wednesday, April 25, 2012
Not much antenna to work with (about 8-10 metres of wire) but having fun in OH-land. I will be sure to bring along a QRP rig next time I come to Europe and give those fun airport security folks something to quiz me about.
Monday, April 23, 2012
Thursday, April 19, 2012
Thursday, April 12, 2012
Saturday, April 7, 2012
The clock is wired to pin 27 and the data to pin 26, to allow the standard keyboard library to be used.
Realistically speaking, it is difficult to type blind on a keyboard, especially when you can type faster than the morse code is sending without visual feedback as to what you are typing. It would be more realistic to implement some sort of LCD display to show keyboard input, allow backspacing, while the keyer is sending the buffer. However, I have not yet implemented those components though I have all the necessary pieces.
I took the morse code tables from my QRSS beacon and added all the defined punctuation characters so as to have a complete implementation. I will be sharing a new version on github as soon as I have the code completed and tested sufficiently.
I have implemented the ability to change the morse code send speed from the keyboard. The up/down arrows change the speed by 1 WPM whilst the left/right arrows change the speed by 5 WPM range limited for 5 WPM to 60 WPM.
I plan to add memories for canned messages that can be sent with a function key press stored in EEPROM which will include serial/sequence number substitution for contest work.
Ran across this little gem today in the Dairy Queen parking lot. Pretty cool, huh?
Thursday, April 5, 2012
After spotting it on 10.140.200 MHz I captured my WSPR decode and as you can see in the last spot after touching up the pot a little, I am spot on frequency (10.140.200) and zero drift. Yeah! The waterfall display shows me swinging the pot through its range over several samples.
The board has a nice, though a little touchy pot to net the frequency where you want it. It currently has a range of about 100 Hz. In the final version, I think this will be tweaked to slow the tuning down to about 1/2 that amout or so. Once adjusted it stays put and doesn't seem to be affected by temperature as expected.
The oscillator output looks like this:
So, I am quite pleased with this little modification to the propeller proto board.
Monday, April 2, 2012
Thursday, March 22, 2012
The grabber will be online most of the time except when I decide to grab the 7200 for other purposes. It can be found at http://www.qsl.net/k/ko7m//grabber/. My pal Eldon has his grabber back online now as well. He is about 35 miles north of my location.
Sunday, March 18, 2012
All the pre-calc work is done and the SGP4 calculations have completed. The post processing code has some problems that I am working on, but now it is time for sleep.
Friday, March 16, 2012
I could really use some insights into how to validate the results. I can of course always compare results against the version I am converting from, but who is to say that it is correct? Ideally there would be a standard test kep set and a standard observation location that would create known results that could be validated.
The SGP4/SDP4 specification does speak to this a bit, but my understanding of it is not yet adequate to evaluate. If anyone has insights here, I could use some advice.
Wednesday, March 14, 2012
I have been working on implementing satellite tracking algorithms (SGP4) on the propeller device as previously posted. I now have a new propeller board that I will be using to drive az/el servos to move an antenna in sync with a satellite pass. This little board can be used drive up to 16 servo motors. If you need more than this, you can daisy-chain two of them together and control up to 32 servos. (I foresee an atonomous flying vehicle in my future, but that is another post for another day...)
I am working with small hobby servos that are capable of moving up to 8 lb of antenna hardware. The pan mount can take 150 lb on top of the mount and 200 lb of side load at the shaft. The tilt mount can handle 8 lb of load.
This is sufficient for my small arrow antenna which is only 20 oz and is giving me some experience in driving servo motors. I could also velcro my solar panel array to it and have it track the sun to recharge my batteries whilst operating off the grid. The pan mount can rotate up to 450 degrees while the tilt mount can rotate 135 degrees. So, this should be fun for some garden experiments with satellites as well as making a fun pan/tilt camera mount.
Future projects of course will scale this up to handle large antenna arrays.
Monday, March 12, 2012
Thus far, I have gotten the receiver to pick up some birdies, but have not heard any actual signals through it. The crystal filter appears to be doing its thing as I am getting about 300 Hz to 3000 Hz passing through it with nice roll-off on the top and bottom ends.
Using the propeller as a local oscillator, I am able to tune the device, but I just don't hear anything other than what sounds like birdies. If I set the propeller to the IF frequency, I get a very strong tone. So, everything downstream of the first mixer appears to be working as expected. But for whatever reason, I don't get any off-the-air signals through it.
I will use another propeller device to inject a signal other than at the IF frequency into the front-end and see if I can hear it. That will have to wait for another day however as I am quite fatigued tonight.
Sunday, March 11, 2012
I have built an object that will parse this data out into its constituent values using the coprocessor. The output from this test looks like this:
1 28375U 04025K 12068.46137681 +.00000200 +00000-0 +72724-4 0 02147
2 28375 098.1341 038.4897 0084202 346.8009 013.0981 14.40905486404267
It is interesting to note the effect of a 32 bit floating point value used to hold this data. Since only 7.2 significant digits are available, values like epoch have been truncated to fit in 32 bits. I parse out 12068.46 for a value that should be 12068.46137681.
At best only an approximation is going to be possible with 32 bits for SGP4 calculations, which given the beamwidth of my antennas is likely to be sufficient. In any event is is an interesting chip to work with.
With 128 floating point registers available and the ability to store user-defined functions on-chip, I am hopeful that the calculations can be done completely on-chip. In an ideal world, I would pass in the kep of the satellite of interest as a string and would get back azimuth, elevation, aquisition/loss of signal times, etc. In a more ideal world, I would get back only the necessary information to move an az/el rotor system to the correct point in space. We shall see how it goes...
Saturday, March 10, 2012
There is also a 64 bit version of this device at $25 that I have placed on order. There are contributions in the Parallax Object Exchange for the 64 bit device as well.
Here is my current lash-up for testing:
The schematic of this hookup is as follows. This is straight out of the Parallax Object Exchange FPU32 objects. The demo code included is useful to get one familiar with how to talk to the FPU.
P │ 10K │
P3├4─>───────────────────────────+──── R ────+
R │ │ │
P4├5─>───────────────────┐ │ │
O │ │ │ │
P5├6─<>───+─────>─┐ │ │ │
P │ │ 12 16 1 │
│ ┌──┴──────┴───────┴──┐ │
1K R │ SIN SCLK /MCLR │ │
│ │ │ │
│ │ AVDD├18──────+
│ uM-FPU 3.1 │
The CS pin(4) of the FPU is tied to LOW to select SPI mode at Reset and
must remain LOW during operation. For this demo the 2-wire SPI connection
was used, where the SOUT and SIN pins were connected through a 1K resistor
and the DIO pin(6) of the Propeller was connected to the SIN pin(12) of
' On Propeller On FPU
'Sym. A#/IO Function Sym. P#/IO Function
_MCLR = 3 'Out FPU Master Clear --> MCLR 1 In Master Clear
_FCLK = 4 'Out FPU SPI Clock --> CLK 16 In SPI Clock Input
_FDIO = 5 ' Bi FPU SPI In/Out --> SIN 12 In SPI Data In
' └─────────────────via 1K <-- SOUT 11 Out SPI Data Out
So thus far, I have been able to get the chip interfaced and able to run the demos for arithmetic, matrix, and FFT operations. Next will be to write some useful code to exercise the chip a bit. Ultimately I want to implement the SGP4 algorithms for satellite tracking.
Simplified perturbations models are a set of five mathematical models (SGP, SGP4, SDP4, SGP8 and SDP8) used to calculate orbital state vectors of satellites and space debris relative to the Earth-centered inertial coordinate system. This set of models is often referred to collectively as SGP4 due to the frequency of use of that model particularly with two-line element sets produced by NORAD and NASA.
More to come...
Wednesday, March 7, 2012
After a few minutes the surface temperature has stabilized at about 55,4 C or 131,7 F.
I fired up my QRSS beacon code and gave it a bunch of text to send. The initial results results are not encouraging:
When I turn off the heat source, the expected drift back upwards begins. I saw more than a 150 Hz change in frequency from heat on (50C) to heat off (20C).
One thing I notice is that the crystal is removable and therefore there is considerable mechanical instability in the crystal socket and the associated change in circuit capacitance and resistance that goes along with these connections being able to move. I noticed that as the board heated up there were more small excursions in frequency as evidenced by the jitters in the waterfall display of the line than there are when the board is at room temperature where the jitters tend to disappear.
So, I supect there is not much I can conclude here other than I have an incredibly crude setup for this kind of testing. My intuition and the deep dive of the frequency with the heat on indicates to me that it is likely that whilst the surface temperature appeared to have stabilized, the internal temperature of the chip may not have yet stabilized. I need a proper environmental chamber that can maintain temperature tolerances more closely and need to give the device sufficient time to completely heat up. I also need to address the crystal socket issues as it appears to introduce a lot of instability as it heats up.
More head scratching whilst I figure out a better setup.
Tuesday, March 6, 2012
From this, I should be able to calculate an error offset for the oscillator over the entire frequency range once the error correction at any given frequency is known for the particular propeller board.
Drift on this particular board at 10 Mhz appears to be around 2 Hz over 2 minutes time, which represents a typical WSPR transmission. My next set of experiments with drift control will be to temperature stabilize the propeller chip at about 50 degrees C and see how this affects drift.
Monday, March 5, 2012
I am working on interfacing it to the propeller and plan to do band switching automatically based on the frequency chosen. This board will easily handle up to 100 watts of power. You can see plots of the filter response here.
Saturday, March 3, 2012
Rev 1.1 - Thanks to Eldon, WA0UWH for pointing out a logic flaw in my
Rev 1.2 - Updated to make into a proper object. Implemented get/put methods.
Rev 1.3 - Implemented Iambic A and Iambic B modes and one element memory.
Made Iambic B mode default
Rev 1.4 - Added bug mode (dits are automatic, dahs are not)
Added straight key mode (dit key input keys transmitter manually)
Added initPins(dit, dah, key, rf) to allow setting of pin assignments.
Defaults to 0, 1, 2, 27
Added public method swapPaddles to allow switching dit and dah paddles
I think the keyer is in pretty good shape now. I welcome any feedback on version 1.4 from anyone that may find it useful. Reminder that with the addition of proper low pass filters, this code functions as a full fledged CW transmitter for ham radio usage. Power output is approximately 5-7 mW putting it squarely in the QRP category. See my previous blog post for a simple amplifier to raise the output power sufficiently for beacon or CW operation.
I keep the LCR metre and signal tracer close at hand. Nice to have one place to do close work again. I cannot stress sufficiently my opinion that purchasing whatever equipment you need in order to be able to clearly see what you are doing is critical to your ability to enjoy electronics and ham radio hobbies.
Tuesday, February 28, 2012
What I have implemented is a very simple direct conversion receiver based on the NE602 Gilbert Cell mixer and a LM386 audio amplifier. The circuit is based on the famous sudden receiver design from the Rev George Dobbs G3RJV many years ago and looks something like this:
My implementation removes all the tuned circuit stuff from pins 6 and 7 of the NE612 (NE602 in my circuit) and injects the RF generated by the propeller via a blocking capacitor directly into pin 6 to set the receive frequency.
Here is a photograph of the lash-up with the receiver built manhattan-style on a little 5x7 cm PCB scrap.
Right now I am sitting here listening to a 75 metre net running on 3.98 MHz LSB (The Oregon Emergency Net).
Obviously, I have a lot of work to do on user interface code...
Now as you might well imagine, there are a number of problems with playing at RF frequencies with bits of wire lashing all the bits and pieces together stuck into protoboards. For example, I had to move the RF pin as far from the encoder pins as I could in order to not confuse the encoder code. The frequency kept changing on its own until I turned off the RF. There is a fair amount of "hash" in the receiver audio being generated by the LCD controller chip. But as far as a proof-of-concept impelementation, I could not be happier.
With this success, I plan to put together a complete (simple) all-band transceiver using a propeller as the controller as well as RF generation component for both the transmitter oscillator as well as the local oscillator for the receiver.
Monday, February 27, 2012
So far the LCD driver is working nicely for both I2C displays and parallel displays. Eldon seems to have switched over to using mine.
I will next work up some code to use the encoder for frequency selection. Everyone else is well beyond this point, but I have focused mostly on the WSPR encoder solution whilst everyone has been continuing on with UI and other concerns. I will catch up here soon...
Sunday, February 26, 2012
This work is largely completed at this point although there is some clean-up work to be done. One of the dilemmas I face is the question of how to implement cursor positioning. It is simple enough to envision an API that sets the cursor to some row/column pair, but should those rows and columns be zero-based or one-based values?
I have worked forever on systems wherein all such values are zero based. There does appear to be however some precident for using one-based values. For the moment, I have implemented two APIs, one that is zero-based and the other one-based. Perhaps that is an acceptable, albeit confusing solution.
I welcome any thoughts anyone might have on the topic.
Saturday, February 25, 2012
Let me know if you "hear" it on the air.
Thursday, February 23, 2012
The RTC was a complete no-brainer, it just works. I plan to use it to allow atonomous operation of my beacons that need accurate time information such as WSPR.
The LCD however was a bit of a problem as I am not happy with the display drivers that are out there and have not found an acceptable I2C implementation for any display that I care for.
So, I ported the driver I was using for Arduino to spin and have it working now at least at a macro level. I have not tested the functionality fully yet. I am quite pleased with the initial performance.
The plan is to make a rather comprehensive driver that will work with either I2C or parallel mode, though I only will be using I2C. Above you can see it driving my 20 character by 4 line display. The I2C bit is implemented in the driver via bit-banging. This allows the driver to be independent of any other I2C library. The SDA and SCL pins can be specified with the default to share the I2C pins with the EEPROM.
On other fronts I am putting together a low pass filter module that uses six relay selectable low pass filters for the HF Bands 160 - 10 metres. 10 bands are covered with 6 filters. Attenuation in the stop band should exceed -40dB. I anticipate using an 8 bit I2C I/O expander, six bits of which will be used select the appropriate filter for the following bands: 160, 80, 60/40, 30/20, 17/15, 12/10 metres. I anticipate using the remaining bits for transmit/receive switching and antenna auto-tuner control. More to come on this.
Saturday, February 18, 2012
I have updated the code to fix this error. At the same time, at Eldon's suggestion, I have also updated the code to make it more of a spin object. I have added start and stop methods that allow it to run on a separate cog. I have also made most of the keyer parameters externally readable and writeable by adding get and put methods for each. For example the frequency can be read or written with getFreq/putFreq. Have a look at the code for the entire list of get/put functions. I also renamed the file from keyer.spin to ko7mKeyer.spin in order to try and avoid naming conflicts.
Eldon has implemented a UI in front of this code using a propeller USB prototype board. Here is his implementation. Pretty nice, I think. He can change the frequency and keyer speed through his rotary encoders and display everything on an LCD. Nice little transmitter, Eldon.
Wednesday, February 15, 2012
The device sports a standard 3.5mm stereo audio jack on the top.
Hookup is completely trivial with only I2C SDA/SCL pins, VDD/VSS power connections. Four wires and you are done. Could not be simpler, no soldering involved unless you want to.
Fun little project, if you want immedicate success, give it a go! I leave it playing in the background whilst I work on other programming projects. The product information page at the Parallax site is here where you can find all the documentation as well.
Sunday, February 12, 2012
To use as a keyer, set Frequency to zero and attach a keyer circuit to the pin defined by keyPin. I suggest using a 2N7000 or VN10 to drive most modern commercial CW transmitters. Something like this should be adequate. The code supports active high or active low keying.
A speaker can be used on RFPin in this mode to allow hearing a sidetone if desired. By default a 600 Hz tone should be heard. A two paddle key is attached between ditPin/dahPin and ground. I use P0, P1 for the paddle, P2 for the keyer output and P27 for RF/Speaker output. Please change to suit your needs.
To use as a transmitter, set Frequency to the transmit frequency. A 600 Hz offset is used by default to allow the transmitter to be heard in the receiver as sidetone. Change the toneFreq constant if you wish to have a different offset. Change ErrorOffset to correct for any transmit frequency error your propeller may experience. This tuning to set the ErrorOffset value should only need be done once by zero beating a frequency standard such as WWV.
A low pass filter for the transmit frequency should be connected to RFPin in order to clean up the square wave output sufficiently to meet regulations about signal purity. I recommend a minimul of a 5 pole filter as described in earlier posts.
Currently only Iambic Mode A is supported. Future versions will include the ability to set the keyer parameters such as keying speed, character speed, frequency and RF pin assignments as well as changing Iambic modes via the paddles.
Here is a photograph of the current lash-up with my Vibroplex paddles hooked to P0 and P1.
The source code can be obtained from https://github.com/ko7m/Keyer. As always comments and suggestions are solicited.
Thursday, February 9, 2012
See the uM-FPU64 datasheet for details.
See the uM-FPU64 datasheet for details.
Tuesday, February 7, 2012
I have decided not to release my WSPR encoder for Propeller on the Object Exchange at the Parallax web site and instead I created a Github project repository for it. I am releasing it free of charge under the same MIT License that is used at the Object Exchange however.
You can obtain the files at https://github.com/ko7m/WSPR. Looking at this web page, you will see the following:
By clicking on any of the files you can examine them or you can get it all in one go by clicking on "ZIP" near the top and it will bundle up a zip archive and push it down to you.
As always, I welcome feedback or questions. I hope you find it useful.
Monday, February 6, 2012
Saturday however was one of those phenomenal clear sky, million-mile visibility days with low wind speeds. I decided that if I had to hire someone to fly me, I was going to take to the skies.
Fortunately, a good buddy of mine has a 1948 NAvion L-17-B and had a shout out to anyone wanting to ride along. Sold! My poor little super cub will have to stay in the hanger a little longer until my head is more clear I am afraid.
We left our home field (Harvey Field - S43) in Snohomish, WA and flew to the Olympic Penninsula and cruised the length of Hood Canal stopping for lunch at Shelton (KSHN) at the cafe in the parachute jump centre.
Hood canal runs against the east side of the Olympic Mountains, which I think are particularly beautiful.
After a nice lunch, we decided to head on out to the Pacific Ocean coast and head north. We flew the length of the Washington coast from about Pacific Beach all the way to Neah Bay.
The wind was a bit brisk onshore as evidenced by the breakers on the shallow beach.
We had to circle a few islands off the coast. Pretty rugged coastline with very few options for an emergency landing.
Here we are rounding the bend around Tatoosh Island off Cape Flattery. This is the most north-western point of the United States. I am actually surprised that any of these pictures turned out because as we made this turn, we were just getting slammed around by the wind. Thousands of miles of Pacific Ocean winds from Canada and the Washington coast converging and trying to stuff through the Straits of Juan de Fuca. We picked up a lot of ground speed as we turned east down the Straits.
Looking back south down the Pacific Coast. Sun is dropping towards the horizon.
Crossing Puget Sound from the West, Mt. Rainier in the distance about 10 miles from Harvey Field. On days like this, there is no finer place to fly than the Pacific Northwest.
If you would like to see all of my pictures of the trip, here is a link. About three hours of flying and endless beauty.