It is a beautiful sunny warm summer day in Seattle. Been out this morning enjoying the sun and running errands. I have fired up the Raspberry Pi and thought I would try to update the blog from the Midori web browser included in the Wheezy build.
Spent way too many hours yesterday in the print shop getting an order out last evening and today Joan is off to eastern Washington to pick up a Fjord pony so I thought I would play a bit with the Raspberry Pi.
I ordered a couple 32 gig memory cards and will be trying to get a couple of different distributions working on them.
It is good to be working again after being laid off from Microsoft back in January. I am now working at Dynon Avionics in Woodinville doing software for their avionics product line. Happy to be employed again!
We have had one of those fantastic weeks of sunshine here in the northwest that make it one of the best places to live. When the sun is out in Seattle, there is nothing better. Unfortunately, there are a whole lot of grey sky days in between.
I am currently scheduled to go pick up my airplane Tuesday after it's rather lengthy annual inspection. However, it is looking like the weather may not hold until then. We shall see.
Sunday, May 5, 2013
Sunday, March 24, 2013
Ham Radio Presentation, Raspberry Pi and WSPR
Hello out there. It seems that I have slowed down sufficiently on the job search to play a little this afternoon with radio related stuff. I had an opportunity last Monday to give a talk on Ham Radio to the Community Club in Ocean Shores Washington. Pretty high level stuff, but had a number of hams in the room as well as about 20 mostly retired folks from the Ocean Shores Community. It was a lot of fun and seemed to be well received by the audience.
I was also asked to visit the high school and meet with a group of students and talk about aviation and software. I met with the students in the morning and gave my talk around noon to the community club. All-in-all a very nice day for me.
I have been busy in the screen print shop, but this afternoon decided to play around a little with the Raspberry Pi machine and get it up and running on WSPR. It really was a non-event as the work all seems to have been done for me by others.
I booted Debian Linux off an SD card and found that I could not connect to my wireless network as the Netgear Ethernet bridge I am using had not been reconfigured to use my updated network settings. Once I got that sorted out, the Pi booted up and internet access was now working.
I updated the Debian release to the latest stable and installed Git as well as updated my gcc release. I then cloned the WSPR code from github and built it on the Raspberry Pi machine. It is now up and running and transmitting on 10.140.200. I am able to hear it on my Grundig G6 portable receiver and it seems to decode fine using Joe Taylor's fine WSPR software.
So not terribly earth-shattering news from KO7M, but it is fun to get back to doing something with ham radio again. My buddy Eldon seems to be having trouble with this as he is complaining of AC hum issues, so I think I will take my setup with me and go pay him a visit.
I was also asked to visit the high school and meet with a group of students and talk about aviation and software. I met with the students in the morning and gave my talk around noon to the community club. All-in-all a very nice day for me.
I have been busy in the screen print shop, but this afternoon decided to play around a little with the Raspberry Pi machine and get it up and running on WSPR. It really was a non-event as the work all seems to have been done for me by others.
I booted Debian Linux off an SD card and found that I could not connect to my wireless network as the Netgear Ethernet bridge I am using had not been reconfigured to use my updated network settings. Once I got that sorted out, the Pi booted up and internet access was now working.
I updated the Debian release to the latest stable and installed Git as well as updated my gcc release. I then cloned the WSPR code from github and built it on the Raspberry Pi machine. It is now up and running and transmitting on 10.140.200. I am able to hear it on my Grundig G6 portable receiver and it seems to decode fine using Joe Taylor's fine WSPR software.
So not terribly earth-shattering news from KO7M, but it is fun to get back to doing something with ham radio again. My buddy Eldon seems to be having trouble with this as he is complaining of AC hum issues, so I think I will take my setup with me and go pay him a visit.
Sunday, January 20, 2013
More time on my hands...
Well, it seems I will be having more time to melt solder and sort things out in my shack as I recently lost my job due to reductions in force. Going to take some time off and decompress after 26 years, but will be looking for the next adventure.
Saturday, November 10, 2012
Saturday, October 13, 2012
Monday, September 24, 2012
PSK vs. FSK/MSK
In thinking about BPSK vs. FSK or more accurately, MSK (Minimum Shift Keying) I found myself pondering whether they are functionally equivalent.
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.
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.
Sunday, September 16, 2012
Propeller PSK31 - Updated
Working on PSK31 encoder that will eventually become part of a new beacon mode for my set of Propeller beacons.
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.
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.
Subscribe to:
Posts (Atom)