X-Phase — More theory

The advert is from Practical Wireless February 1987.

In my last blog I tried to explain how a QRM Eliminator works. Here’s some more information.

Suppose the signal you are trying to hear is a sine wave (shown in blue). The signal as received (shown in red) will have some noise added as it travels to you.Original noise

The QRM eliminator allows you to pick up the noise with your noise aerial and phase shift by 180º. As shown in this chart.

Noise

If you add the blue and red signal together you’d get a zero signal. So if you mix the inverted noise with the noisy signal as received you’ll recover the original signal.

Recovered

Of course reality is different and the recovered signal won’t be as clean as that. Also if you don’t match the noise and main signal amplitudes properly, you’d then get something like this.

Recovered loud

These charts were made with MATLAB using this script.

X-Phase QRM Eliminator

I bought an X-Phase QRM eliminator a while back, tried it out with a receiver and was quite impressed with its performance. It’s only recently that I’ve connected it to a transceiver because without care it is easy to damage the unit when transmitting.

QRM eliminators have been around for many years. I was recently looking at an old Practical Wireless from 1989 and S.E.M. were selling one then in the adverts at the back of the magazine. (And, yes, we used dots in abbreviations back then). If you were to be picky you might say it should be called a QRN eliminator, but it isn’t. I quite like the idea of an actual QRM eliminator though I’m not sure how you could implement it. 

Advert for QRM Eliminator

A QRM eliminator works like this: signals from the main aerial are mixed with signals from a noise aerial. The signals from the noise aerial can be shifted in phase. The idea being that you mix the main signal with the noise signal 180º out of phase. If the signals are the same you’ll just get a zero signal. But if the main signal comprises a good signal and some noise signals and the noise signal is predominantly the noise signals, you’ll end up with just the good signal. Of course, to make this work you need to be able to make the noise signals from the main and noise aerials be the same amplitude so the QRM eliminator has controls to adjust the gain of each. As you want the signals to be 180º out of phase there is also a control to adjust the phase.

front of X-Phase

The three blue knobs in the photo are these controls.

There are several QRM eliminators on the market. I got mine from Poland on eBay from the seller urbania2. The unit is solidly built in a neat aluminium box with pleasant to use control knobs and strong connexions on the back. 

The instructions are in a quaint mixture of Polish and English but I found them understandable enough as a circuit diagram is included.

I have done some quick tests on 20m with the unit and it seems to be able to reduce the background noise by about 3 S-points as shown on my TS590S transceiver. I also made some measurements using received FT8 signals. This showed an increase of about 4dB in the signal strength of CQ signals as reported by JTDX over 15 minutes with the QRM eliminator being on each even minute and off each odd minute. None of this testing was particularly scientific though. I was using a 4m length of loudspeaker wire as the noise aerial, just lying on the floor of the shack.

connexions at back of TS590S

I mentioned that it’s easy to damage the unit when transmitting. It has three wires. Red and black are for the DC supply, and the yellow wire is for the PTT. When grounded the eliminator passes the main signal straight through avoiding the damage.

This Is how I connected my TS590S. The EXT-AT connector on the TS590S provides a nominal 13.8V DC. So I used pins 1 and 6 to power the Eliminator. I got the EXT-AT plug from an eBay supplier asia_uk.

TS590S EXT AT Connection

The remote connector on the TS590S isn’t particularly well documented, but connecting the yellow wire from the Eliminator to pin 4 works, but only if menu 53 on the TS590S is set to 2. Pin 2 on the remote connector, the common terminal needs to be grounded so I connected it to pin 3 on the EXT-AT seeing it was spare. I got the required 7-pin DIN plug from RS Components.

TS590S Remote Pinouts

Graphs of coronavirus cases doubling times

I’ve added some graphs to the coronavirus cases graphs I mentioned earlier. These graphs plot how many days it takes for cases to double. So the higher the number the better.

When the peak of the cases has been reached the graphs show the number of days for the cases to halve. It does this by showing the days as negative numbers. 

I suspect that at the peak the graph will jitter quite a lot. 

I’ve suppressed the figures for the first 100 cases as the figures probably wouldn’t make any sense. Suppressed figures are set to zero.

Of course, as the governments change how they test cases the graphs will be harder to interpret.

Anyway, here’s the latest graphs. 

 

 

 

 

The MATLAB code is here.

Plotting Local Coronavirus Cases

Here in Scotland (and in England) the governments publish coronavirus data daily. But they do not show the data in a particularly useful way as it is simply a count of cases confirmed so far. These counts are useful as they can show whether the health service is likely to cope with the outbreak or not today, but they do not show the history of the pandemic.

Jason Leitch Flattening

I believe the important information is to see a graph of the confirmed cases to allow you to judge if the wanted flattening of the curve is happening or not. This curve is explained here by Scotland’s National Clinical Director, Jason Leitch. Also what matters to most people is what is happening locally to themselves and their loved ones.

So I’ve knocked together a MATLAB script to plot some graphs for the Lothian Health Board and the Greater Glasgow and Clyde Health Board in Scotland and the East Sussex Healthcare NHS Trust in England. The script gets its data from Tom White’s GitHub page. As Tom says, this data should be made available officially but does not appear to be published yet in a usable format. Thanks for the data, Tom!

I’m not a MATLAB guru and I’m sure my script could be written better and be more robust. But it works for me. Here is the code. MATLAB is quite expensive (I use it for playing about with radios and electronics) but the script could probably be rewritten in Octave with something replacing the TimeSeries variables. Spreadsheets would  work too but I’m even less a guru in them than MATLAB.

And the grim results, no doubt to become much grimmer due to the expected exponential growth of cases. Early days yet.

Lothian

Glasgow

Esussex

Remember to wash your hands!

SignaLink Jumpers for FT290R

Here’s how to set the jumpers in a SignaLink USB when connecting a Yaesu FT290R.

FT290R Front

I found the jumper instructions on the Tigertronics website just a little too general, so this may save some time.

Signalink jumpers for FT290R IMG 1043

The SignaLink works fine with PocketPacket on a Mac mini. ‘Use Vox for PTT’ was set in the PocketPacket Audio Modem preferences. The SignaLink delay knob was turned fully anticlockwise.

Using this setup I could receive and decode signals from a local packet test GM7RYR-10. I transmitted to the ISS packet digipeater but didn’t see any of my packets digipeated. However, I received my packets locally on my Yaesu FT60 and decoded them on a Raspberry Pi via Direwolf by WB2OSZ and Xastir.

PTT for FT290R

I bought an FT290R (thanks Bob!) a few months back and have finally got around to trying it with packet. The PTT circuit I used for the FT60 Raspberry Pi 3B+ works fine so all it needed was to connect up a plug for the front socket as shown here.

Scribbled Pinout

I tested it with Direwolf and Xastir and it seems to work fine. Here’s an audio clip FT290R Packet Audio.flac of a packet being sent from the FT290R. I recorded it using Audacity from my Alinco DJ-C6.

I had hoped that the extra power (25W) from the FT290R would allow the ISS to hear my packets but I’ve had no joy in the couple of passes I’ve tried so far. I can hear packets fine, but the ISS doesn’t digipeat the ones I’ve sent. I changed the APRS path to just ‘ARISS’ having read this aprs.fi blog but that didn’t help either. Perhaps the ISS needs to be at a higher elevation. Or perhaps my rather ramshackle Cebik Moxon aerial needs tweaked.

Bit Banging on PIC12F683

The PIC12F683 Microcontroller comes in a useful 8 pin DIL package. I favour this over smaller devices as it allows my ageing eyes to cope with connecting it to the rest of the circuit.

However, this PIC does not come with a UART and so any text debug needs to be output using ‘bit-banging’. I needed to debug a PWM motor drive so I tried to find an existing implementation of bit-banging on this or similar PICs developed in C but couldn’t find any. So here’s my solution.

This code allows communication at 9600 baud only. This is a reasonable speed for text debug as it allows fairly rapid output but won’t be too fast for any modern computer. The output is digital high and low on the GP0 pin. So highs will be at the supply voltage (Vdd) and lows will be at 0V. For this PIC Vdd is from 2 to 5.5V. I did all my testing with a 5V supply. The communication is 8-bit, no parity and one stop bit (8N1 for short). The remote UART used in testing was a Dangerous Prototypes’ Bus Pirate. The text was displayed on a Mac mini terminal using GNU screen: screen /dev/tty.usbserial-A9048DB4 115200,cs8,-parenb,-cstopb,-hupcl.

The code uses timer 1 as a counter to work out how long to keep the signal high or low. This means the timing of the code you are debugging will be way off as the code does a lot of looping to check the counter registers. But if the code being debugged is timing critical you shouldn’t be using text debug anyway. In that case you are better off simulating, flashing LEDs or looking at signals with a ‘scope or logic analyser.

The meat of the bit-banging code is in the putcharGP0 function. This sets or resets the GP0 port depending on the value of the bit to be transmitted. After each set or reset the code loops waiting for 1/9600 = 104µs. This loop is in the ‘WAIT_SYMBOL_TIME’ macro. This macro takes an argument which allows the loop to be adjusted allowing for the time taken to run the code between each bit. The macro is called ‘WAIT_SYMBOL_TIME’ as in this case each symbol is a single bit. Each character has a start bit, 8 data bits and a single stop bit. 

The code is built using this make file which uses Microchip’s xc8 C compiler and programs the PIC using a PICkit2.

Preparing MP3s for an Evoke 3 Radio

I use an Evoke 3 radio made by Pure to listen to music. It has a very good sound — at least to my cloth ears. One of its features is that it plays MP3s from an SD card. But its firmware is quite old-fashioned perhaps because of technical limitations. It displays the song information but can only understand ID3v1 tags. The world has moved on and ID3v2 tags are now the default for most devices. Also the Evoke displays all files even those which are hidden on computers by having a dot as the first character. This makes the display of the folders and songs messy.

I used to deal with the tagging by using a very good application called kID3 to copy the ID3v2 tags to ID3v1 tags in its GUI. I have recently been reading “The Art of Unix Programming” by Eric Steven Raymond and it prompted me to write a script to do the tagging. I’ve since seen that kID3 can be driven from a CLI so that may be a better way to do the tag copying. 

Kid3 screenshot

I looked for command-line utilities to copy tags and couldn’t find any. But the good folks in the Perl community provide a library called MP3::Tag which allows easy manipulation of MP3 tags — as long as you can write in the Perl language. The library is available on CPAN but I used the MacPorts version. Many moons ago I could write Perl in my sleep so I decided to dust off the necessary neurones and write a Perl script. 

The Perl script ‘mp3-tag-convert.pl’ is not new and exciting but may help as an example for whatever you want to do. The script looks at all the MP3 files in a folder and copies the ID3v2 tags to ID3v1 if they don’t already exist. It will also copy the ID3v1 tags to ID3v2 if they don’t already exist. 

For my purposes I needed some other scripts. I had already written a shell script ‘tidy-mp3s’ to tidy MP3 folders of extraneous files that MacOS leaves lying about for its own purposes but that show on the Evoke 3 cluttering up the display.

I also needed a script to put it all together. ‘mp3s-to-evoke.ksh’ is a script which tags the MP3s in the way that suits the Evoke 3 and then copies them to the Evoke 3.So when I decide to change the songs on the Evoke 3 (it only handles a 2GB disc) I can just call the script in each MP3 folder on my computer and it will get copied to the Evoke 3.

 

Screen Shot of Evoke script runThe scripts are in this compressed file: evoke-scripts.zip.

I use Korn shell (ksh) for scripts because that’s what I grew up with. I think the scripts should run under Bash if that’s what you prefer.

So now my Evoke 3 screen is nice and clean.

Evoke 3 Running MP3s

Cebik Moxons in the Attic

I now have both 2m and 70cm Cebik Moxons in the attic separated using a HA8LFK diplexer. After trying out the 70cm aerial it is clear that it needs a preamp to pick up any signals. Partly this is due to the poor coax I’m using and I should replace it with something better. So I’ve added an M-100 preamp powered from a shack PSU through a pair of bias-tees.

I tried bypass the M-100 with a relay but I haven’t been able to source a relay that works well at UHF. Usually the non-connected path is only 20 or 30 dB down on the connected path. This is not safe enough to protect the preamp, so that’s another reason for giving up transmitting for now. I’m pretty sure the aerials will not be good enough for decent transmissions and I would end up being the recipient of pleas from an OM: “I got the Mike, Zero and Yankee, your callsign again again please…”.

The setup looks like this scribble from my lab book:

Scribble form lab book

Unfortunately the M-100 draws 55mA which is 5mA too high for the built-in bias-tee in the SDRplay RSP2. The RSP2 is my receiver of choice at the moment. More on that later.