WSPR: Arduino versi M1GEO
Sumber: https://www.george-smart.co.uk/wiki/Arduino_WSPR
Arduino WSPR
This page details my experimental AD9851 WSPR transmitter. Visit the WSPR page for my standard WSPR tests. These pages are also related to this, and may be of an interest to you: Arduino AD9851 Arduino RTTY Arduino QRSS 1W PA for 10MHz
This page assumes that you already have an Arduino board and AD9851 DDS chip in some form, for example the DDS-60 board by AmQRP. See the Arduino AD9851 board for my solution.
Source Code for AD9851 Simple WSPR Transmitter You'll need to generate your own data, as detailed in the text.
Theory of the WSPR Protocol
This section is the theory of how WSPR works. You do not need to understand any of this in order to make a WSPR transmitter. I worked through it because I was interested in the theory and maths. But I guess most people are not! :)
The first thing I did was see what frequencies were needed to be transmitted. This can be done with the WSPR program from the command line. Read the manual, WSPR Instructions found here. Most importantly the section entitled GENERATING A LIST OF TX TONE FREQUENCIES. This section describes making custom hardware or MCU solutions to transmit WSPR - exactly what I was trying to do! Wikipedia also has an interesting section, WSPR Protocol Specification, which contains some information.
WSPR has a fixed standard message of the station's callsign, 4-digit QRA locator and signal power in dBm. My example would be "M1GEO JO01 20 where M1GEO is my callsign, JO01 is the first 4 digits of my QRA locator and 20dBm (is roughly 100 mW). In total, 50 bits are used (28 for the callsign, 15 for the locator, and 7 for the power).
Using a high convolution code of length 32 and rate 0.5 as parameters for the forward error correction (messages are encoded in a redundant way, so the loss of information, here bits, has a greatly reduced impact on the quality of the message received) allows for a very redundant code.
If we expand this out, we can work out the number of binary symbols required to send this data. This convolutional encoding is explained mathematically here. Binary channel theory is explained here too. You don't need to understand these, just to know it happens is enough. This is the theory of why it works, how averaging the noise, redundant encoding (FEC) and other measures will help our cause. Here, just believe me, this is how it works out - our original 50 bits become the following number of symbols:
<math>N_{sym} = 2(B + [K-1]) = 2(50 + [32-1]) = 2(81) = 162 \; bits</math>
The protocol specification http://physics.princeton.edu/pulsar/K1JT/WSPR_Instructions.TXT states:
Each tone should last for 8192/12000 = 0.682666667 seconds, and transitions between tones should be done in a phase-continuous manner.
This is a pre-chosen value, 8192/12000, (simplifies to 256/375) which was chosen because it works out nicely. Transmissions are a reasonable length of time, a computer sound-card can work with this value well.
Inverting this tone length, we get the tone separation:
<math>F_{sep} = \frac{1}{T_{tone}} = \frac{1}{\frac{256}{375}} = \frac{375}{256} \approx 1.46 \; Hz.</math>
as specified in the protocol. Next we know that we're using MFSK-4 (4 frequencies) with a separation of 1.4648 Hz, such that we can send our pseudo-random synchronisation vector. We work out the total occupied bandwidth,
<math> BW_{tot} = T \times F_{sep} = 4 \times \frac{375}{256} = \frac{375}{64} \approx 6 \; Hz</math>
The 162-bit seudo-random synchronisation vector (PRSV) serves to help the receiver to synchronise. It affords the receiving station some data that it knows to expect. It is able to find this pattern mixed in with your message (callsign, locator, power) and has therefore found your signal too. The 4 tones, mentioned above in our bandwidth calculation can be used to represent 1-bit of the PRSV and one bit of the message (00, 01, 10, 11). One of these four tones is called a channel symbol, and conveys one sync vector bit (LSB) and one data message bit (MSB). We send two bits at a time, hence 4 tones.
From here, we can work out the transmission time,
<math> N_{sym} \times T_{tone} = 162 \times \frac{256}{375} = \frac{13824}{125} \approx 110.6 \; s</math>
The protocol also specifies that transmission timeslots start one second into the even UTC minute.
Using The WSPR Binary to Generate Tone Data
For a starting position, I decided to use the WSPR binary application to generate the tone data. I am only really interested in the tone numbers (second column). In case you skipped the theory section, the protocol specification is set out here: http://physics.princeton.edu/pulsar/K1JT/WSPR_Instructions.TXT and describes the many options to do with the WSPR binary command line. Here I just get the computer to generate my callsign, locator and power, 100 mW (M1GEO JO01 20). Note you need to use the WSPR.exe program or the wspr0 binary under Linux. Using the script just starts the WSPR GUI.
$ ./wspr0 Tx 0 0.0015 0 M1GEO JO01 20 11
WSPR generator
The power here shows 17 dBm. It was changed later to 20 dBm
The output data, tells you the bit number, and they're to be transmitted in this sequence. The next column tells you the tone number, 0-3, and the final column shows the frequency for the offsets you have entered in the two values after the Tx argument.
If you're running a Linux or Unix based system, running the command below will create you a list of tone numbers, separated by commas. If you're running Windows, I'm sure there are ways to do this (one of which is doing it yourself). I can't offer you any advice. Sorry.
$ ./wspr0 Tx 0 0.0015 0 M1GEO JO01 20 11 | awk '{print $2}' | sed ':a;N;$!ba;s/\n/,/g' 3,3,0,2,2,0,2,0,1,0,2,0,1,1,1,0,2,2,3,0,2,1,2,3,1,3,1,2,0,2,0,2,0,2,3,2,0,1,2,1,2, 2,0,0,2,2,3,2,1,1,2,2,3,1,2,1,2,2,0,3,3,2,3,0,2,0,2,1,3,2,3,2,3,0,3,0,1,0,2,3,2,2, 3,0,3,3,0,0,2,1,1,0,1,0,3,0,2,2,1,0,0,2,0,2,1,0,2,3,0,0,3,3,1,0,3,1,0,0,1,3,0,3,0, 0,2,3,3,1,2,0,0,0,0,1,0,1,2,2,3,1,0,2,0,0,2,2,2,3,3,0,3,0,3,1,2,2,0,3,1,0,2,2
This data can then be input into your Arduino Code as a data array.
Simple WSPR Transmitter
You can use this data to transmit WSPR very simply. Putting this data into an array allows for easy recall in a sequenced manner. Here, I add the data into an array as you would expect to find in a C program. This is for Arduino v1, but is very universal. You can see how creating the comma separated list in the step above helped a lot!
byte WSPR_DATA[] = {3,3,0,2,2,0,2,0,1,0,2,0,1,1,1,0,2,2,3,0,2,1,2,3,1,3,1,2,0,
2,0,2,0,2,3,2,0,1,2,1,2,2,0,0,2,2,3,2,1,1,2,2,3,1,2,1,2,2,
0,3,3,2,3,0,2,0,2,1,3,2,3,2,3,0,3,0,1,0,2,3,2,2,3,0,3,3,0,
0,2,1,1,0,1,0,3,0,2,2,1,0,0,2,0,2,1,0,2,3,0,0,3,3,1,0,3,1,
0,0,1,3,0,3,0,0,2,3,3,1,2,0,0,0,0,1,0,1,2,2,3,1,0,2,0,0,2,
2,2,3,3,0,3,0,3,1,2,2,0,3,1,0,2,2};
The line breaks are for looks only. You could just as easily leave all the data on one single line. Make sure the end of each line ends with a comma, as this signifies that the data continues.
A simple way to read this data out of the array is to create a for-loop:
void wsprTX() {
int i = 0;
for (i=0;i<162;i++) {
wsprTXtone( WSPR_DATA[i] );
delay(683);
}
frequency(0);
}
Here you can see that the loop goes from the 0th element to 161st element sequentially incrementing the variable 'i'. I in turn feeds into our array, picking the next element from WSPR_DATA[#] each time it is updated. This value is passed by compound statement (the value WSPR_DATA[#] returns is input directly as the argument) to the function wsprTXtone(t) which translates this tone number into an actual frequency.
void wsprTXtone(int t) {
if ((t >= 0) && (t <= 3) ) {
frequency((WSPR_TXF + (t * 1.4648)));
}
}
When the wsprTX(void) function calls wsprTXtone(t) it is passed a number, as discussed representing the tone required. The first thing we do is to check the tone is valid (0 <= t <= 3). If it is, we can simply calculate the required tone offset by multiplying the passed parameter, t, with the tone offset, 1.4648 Hz. This value is added to WSPR_TXF in this example which is the absolute offset, defined elsewhere as 10,140,200 Hz. The frequency() function, as you might expect, sets the frequency of the DDS.
The last issue to tackle is the timing. As the protocol specifies, the transmission is to begin at 1 second into the even minute in UTC. For this there are a few options: DCF77 or WWVB time signals; An accurate Real Time Clock, or; GPS timing. There exists other possibilities to make the MCU clock very accurate in order to keep time inside the Arduino's MCU. I will opt for the GPS as it is the easiest solution. DCF77 reception is poor in my area due to electrical noise. GPS signals will work well.
As a proof of concept, I wrote the code such that I could trigger the transmission myself in order that I be able to verify the data and transmission side of things. I am happy to report that my very first test was a success:
WSPR Reception of First Attempt!
I hooked the simple WSPR transmitter up to a 2N7000 class-E HF power amplifier and set the output for a modest 200 mW. Adjusting the reported power output as necessary, I transmitted a few WSPR frames throughout the morning on both 40- and 30-metres. Below is a map of where I got on 200 mW.