A WSPR transmission starts on an even two-minute interval. So a WSPR Transmitter needs to be able to keep track of the real time. My earlier post about setting the time on an RTC isn’t suitable for my WSPR Transmitter as the process of getting the time isn’t automatic. The best choice is between using GPS or NTP. I chose NTP as my WSPR Transmitter will always be used where there is Wi-Fi available.
Choosing NTP has some ramifications. You need to provide Wi-Fi credentials and the most convenient way for this is to ask for them once and store them somewhere. You could just store them in the code but this isn’t secure.
You also need to use a chip that handles Wi-Fi. I normally use PIC chips but none of the ones I had contained a Wi-Fi radio. So I looked at alternatives and chose an ESP8266 based module called a D1 Mini. This module can be programmed using the Arduino IDE via USB. It’s a little larger than most PIC chips, but is still a reasonable size.
A D1 mini doesn’t have any EEPROM–all of its memory is flash-based. However, there are libraries available which emulate EEPROM. So this is what I used to store the Wi-Fi credentials.
Once the NTP server has been asked for the time you need to be able to keep track of the time locally. NTP isn’t really suitable to do this by itself. So a real-time clock module or RTC is used. Previously I had used a DS1307 which seemed fine, but it wasn’t available to buy so I bought a DS3231 instead. This module is driven via an I2C bus. The D1 mini module also has I2C built-in. However the ESP8266 runs on 3.3 V and the DS3231 uses 5 V. So a level shifter is also needed.
The code to get the time and maintain it is lengthy but not complex and everything is sequential. When the ESP8266 starts a pin is checked to see if the Wi-Fi credentials should be asked for via the UART. If so, they are stored in the emulated EEPROM. The stored credentials are used to connect to the Wi-Fi. Then a packet is sent to the NTP server and the response is parsed to get the minutes and seconds of the current real time. None of the other time details are needed. The minutes and seconds are stored in the RTC module via the I2C bus. The time in the RTC may drift so the code occasionally retrieves the current time from the NTP server and updates the RTC. The code then loops waiting for the start of an even two-minute interval and transmits the WSPR tones. More about this in a later post. I’ll post the code then too.
The switchable LPF for my WSPR Transmitter finally arrived and I’ve made some response graphs to test how it performs.
The obvious bit of test kit to check out the LPFs is my nanoVNA. I suggest you buy a nanoVNA from a reputable dealer as there are plenty of clones which don’t work as well as the original.
The test setup is above. The 27 V in the drawing can go as low as 13.8 V, but will not work at any lower voltage.
As I’ve mentioned before I find the small screen on the nanoVNA difficult to control with my clumsy hands. So I wrote another simple MATLAB script ajfLogMagS21 to drive the nanoVNA to get the response charts. The calibration done as before using my ajfCalibrate MATLAB script. The LPFs will attenuate the harmonics by 25 dB which will be enough for my feeble WSPR output.
The next step is work out how to drive the switching of the bands. First thoughts are to send commands via I2C and have something convert that to a 13.8-27 V signal on the appropriate pin. I2C is attractive as I already have an I2C bus in the WSPR Transmitter.
I have joined the ranks of the many who have built a WSPR Transmitter. Why? Mostly so I can have a bit of fun. The problem is difficult enough to be interesting but not so complex as to become boring. Having said that there’s a lot involved.
I can transmit WSPR with my TS590S and presumably any other off-the-shelf transceiver. But these all have fan noise so I wouldn’t want to run them overnight. So the transmitter will be able to be used to test propagation overnight.
But mostly I’ve made it to have the fun of making it.
The transmitter cycles through the amateur bands from 80m to 10m optionally transmitting on each band. An RTC module (DS3231 I2C Real Time Clock Module) is used to keep track of the real time. An AD9850 DDS Signal Generator Module produces the RF signal. Both of these are controlled by a D1 Mini ESP8266 Dev Board. The ESP8266 does all the encoding of the WSPR tones and decides when to send them. The signal from the AD9850 is run through a power amp (10W linear HF PA from QRP Labs) then through an appropriate LPF to the aerial.
Currently I’ve only had it on air on the 40m band as I only have a home-brew 40m LPF to hand. This works fine and the signals are being picked up in Europe ok. I’m getting a switchable LPF for the other bands but it’s taking a while to arrive from Russia. However the transmitter works on every band as my TS590S close to the transmitter can pick up the stray signals when I run it into a dummy load. The signals are decoded fine using WSJT-X.
More details later.
The Excel spreadsheet that my radio club CPSARC uses for activity weeks has changed. So I’ve updated my ADIF to CSV converter program. The program is written in the Racket language which means it can be executed on most platforms. It’s in this ZIP file.
In an earlier part of my life I spent my working days writing device drivers for things like printer mechanisms, disc drives and so on. What they all seemed to have in common was that they turned a motor. I was missing turning motors so when I came across a book “Robot Building for Beginners” by David Cook I pricked up my ears. The book leads you from knowing nothing about electronics to building a robot which will trundle along following a line drawn on the ground. This looked like fun so I thought I’d build it.
The technology that the book uses to construct the robot is purely analogue. The line is detected with photoresistors and the motors are simple DC motors with no steppers in sight. What makes the book stand out is the superb way the author explains how and why electronic components work. He explains through examples about resistors and voltage dividers, through LEDs and capacitors, and from comparators to motors. Now I didn’t start from scratch with my knowledge but it seems to be a extremely good way to learn from scratch. And you get a cool robot at the end. Even if it is made from a carry-out box.
I’d built the robot and it worked but the motors were turning too fast. Slowing down a motor is harder than it sounds as all the easy options — adding resistors for example have big drawbacks. I added a PWM-based control to the motor speed controlled by pushing buttons. Here’s the PIC code: http://fletch.scot/code/line-follow.zip. This took a little while as although I had spent my time turning motors I don’t remember using PWM, so I had to learn it. I was using an online copy of the book on the learning part of the IEEE website. I went back to SkillSoft to read the next chapter of the book and the IEEE had stopped using SkillSoft and I could no longer read the book. Luckily I found a paper copy of the book for sale online and bought that so I could continue the project. But it reminded me to not rely on things in the cloud.
Here’s a video of the first run of the robot in action.
Line following robot first run 480p IMG_1145.mov
As you can see the robot needs to be made more robust. One thing I learned from making it is that my usual technique for attaching wires to pins using wires taken from ribbon cable is not good enough (despite copious application of hot glue). This leads to lots of tweaking of connectors. So before I show the robot to my grandsons I’ll have to find a better connection method or they will destroy it with their youthful exuberance.
I’m going to use a real-time clock (RTC) in a future WSPR project so that I can start transmitting at the start of a minute. I’ve never used an RTC before so I thought I’d better fix that. I got a DS1307 RTC from Hobby Components. This module comes with an Arduino library to drive the I2C connection so I’m using a SEM01K Arduino Nano clone to drive it. As you can see the wiring is simple, just ground, 5V, and the two wires for I2C.
Typically you might set the time on an RTC using a GPS module or over the Ethernet from an NTP server. I don’t currently have either a GPS module or an Arduino Ethernet module so neither method is immediately available to me. But I do have a MacBook Pro whose time is set by a local NTP server. So I wrote a small Arduino sketch to set the RTC time from the Mac. The procedure to set the time is a bit manual but it only needs done once as the RTC is kept alive by a battery.
From the sketch:
// To run:
// 1) compile and upload this sketch
// 2) on a Mac terminal do: cat < /dev/cu.usbserial-14430
// where /dev/cu.usbserial-14430 is the Arduino device
// 3) on another Mac terminal do: date "+%y/%m/%d_%H:%M:%S" >> /dev/cu.usbserial-14430
// the date and time is output
// 4) Kill (^C) the cat.
To check that I could use the RTC after the date and time is set I also wrote a little demo sketch which turns on the Arduino internal LED for two seconds at the start of each minute.
The sketches are in this ZIP file.
I had thought that my SDRplay RSP2 was dead because none of my computers would recognise it. But I noticed that it was still drawing current from the USB port when attached and 50 mA seemed reasonable.
I got it to work under CubicSDR somehow, but it was not reliable. Luckily at some stage it was working (I was listening to a Classic FM broadcast) and I accidentally tapped the RSP2 and the dulcet sounds of the orchestra turned into a loud buzzing noise. I realised that it was a hardware problem and I tried to recover and nothing would work until I tried an old USB cable. The RSP2 works fine with this cable but not with any other!
Maybe I’ve lived a sheltered life but I don’t remember any device having a dodgy USB type-B socket. Micro- and mini-USB fails are common, but type-B?
Anyway, I’m happy now because I can monitor my VHF Q65 transmissions using the SDRplay.
If, like me, you use a Mac and both WSJT-X and JTDX for data modes you may run into a problem I had.
The problem comes about because both applications insert a property list into /Library/LaunchDaemons. These property lists are used by the MacOS to start background processes (or daemons) at system startup. But as far as I can tell there is no defined order in which the daemons are started.
I installed the SDRplay API which as part of the install puts a property list into /Library/LaunchDaemons. This must have affected the order in which MacOS started the daemons because suddenly WSJT-X failed to start with a shared memory error. This error persisted even after a re-install and configure of WSJT-X.
I looked at /Library/LaunchDaemons because as part of the WSJT-X install you put a property list there. Sure enough, JTDX does the same (as it is derived from WSJT-X) and the property lists clash because (at least on my system and my version of JTDX) JTDX makes the shared memory size smaller than WSJT-X likes.
So, I think I was getting away with this before I installed the SDRplay API because the WSJT-X property list was being processed after the JTDX one and the shared memory was made big enough for WSJT-X. But after my SDRplay API install the JTDX property list was being processed after the WSJT-X one and the shared memory size was too small.
I fixed this situation by deleting the JTDX property list com.jtdx.sysctl as it is redundant in this circumstance.
And all is well.
I was playing about with my FT290R and Q65 protocol and realised that I had to configure my SignaLink jumpers in a way different from how I had previously blogged.
So these are the settings that I now find ok. Apologies if you’ve been misled by my previous post.
To recap: this is a no-frills VFO intended as a drop-in replacement for a Colpitt’s oscillator in a Direct Conversion receiver. It allows the frequency to be changed within limits set in the code and allows the tuning to be toggled between fast and slow. An LED lights if a frequency limit is reached.
I decided what to use instead of the PICs I usually choose. The answer is: … more modern PICs! A lot of the competition are modules which makes them bigger.
I bought a PICkit 3 which seems to be a lot cheaper than when I last looked. This allows me to program a PIC12F1840 which is much smaller than a PIC16F887. So I have ported the PIC16F887 Si5351a VFO code to that PIC. I have improved the encoder turn handling. With the encoder I’m using I needed to debounce by adding capacitors to ground. The tuning speed is toggled with a button in the encoder. It may be nicer to have a switch instead, perhaps a DIP switch for the tuning as holding down the button while tuning is a bit clumsy.
The PIC12F1840 has a sleep instruction so the code now does all the encoder turn processing in the ISR. The main loop goes to sleep and all that is done in it is to change the frequency of the Si5351a. So the PIC is asleep nearly all the time. It only wakes up when the encoder is turned. The Si5351a is always on, though, as it is generating the clock that the received RF signal is beating against.
A separate button (or DIP switch) allows the user to change the amount the frequency changes each turn. The VFO uses 30 mA when sleeping and 40 mA when the encoder is turning. I don’t know what the Colpitt’s oscillator took.
Here’s the code.
While I was debugging the code I took the following screenshot:
The yellow and blue are decoder turn voltages. The pink is the LED used for debug. It goes high if the code is on the ISR. As you can see it enters the ISR at every encoder turn change. The reason I’d had to go to these lengths to see what was going on was that I’d assumed that the interrupt-on-change flag was for all changes, but it isn’t. There are separate flags for rises and falls. Moral: always read the data sheet!
The footprint of the VFO is only slightly larger than the Colpitt’s oscillator and if that used a beefier variable capacitor the new VFO would be smaller. I’m hopeful it will be useful in a lot of projects.