Monitoring transverter output

Without a correspondant to try a QSO on the air, I had to test my 70 MHz transverter output with my own equipment.

First of all I used the RTLSDR dongle to record my output, so that I could easily play it back afterwards for a self-audio-quality check. Easily done, with the transverter transmitting into a dummy load in the shack.

Then I wanted to check for harmonics at 2x, 3x and so on: the RTLSDR tunes much higher than that. So I moved the output to the 70 MHz dipole and started calling CQ, while RTLSDR receiver was running on the computer screen. Look at what appeared:

That's the fundamental and two noticeable splatters about +/- 200 kHz away, about 30 dB below the center frequency. What the ...?!??

Checking at 140 MHz and 210 MHz the remaining signal was not too strong, spurs obviously following. If I transmitted in FM there was no splatter whatsoever, nowhere.

That's when I remembered an article by SM5BSZ about the (mis)use of ALC in the FT817 (search for "The abominable ALC"), which creates heavy splatters, especially at lowest power settings. While they are barely noticeable in the HF noise, they pop up in VHF and do annoy neighbouring stations!

So I checked the FT817 output at 144 MHz USB, 0.5 W output, and spurs were there. No surprise. My RTLSDR does not tune down to 29 MHz, my 4 m transverter IF output, but I bet the situation is not different.

Since you always have to doubt the bounty of your test equipment, and a 15 USD TV dongle should not be over estimated, I cross-checked with a true receiver: splatters are generated for real.

A quick check at 5 W output has shown that the FT817 doesn't behave acceptably better. One solution, that would improve my '817 in any case, is to change the ALC timing with a hardware mod. Otherwise I will have to drive the transverter with the IC706MKiiG, but SM5BSZ pages contain a warning about a full-power spike when PTT is pressed...

Transverter PA: self-oscillation solved

Fortunately it took little effort to tame the self-oscillation in the (PA?) 10-to-4 transverter. First troubleshooting action was decoupling the DC supply to the whole transverter board. I used a PI network composed of 2x100nF, 2x1nF and one VK200-like inductor.

The inductor goes in-line with the positive voltage. Then 1nF//100nF at each side of the RF impedance.

If you land on this page for a similar problem, don't go crazy looking for the VK200 choke. Try winding as many turns as they fit on an anonymous toroidal core recovered from some switching PSU, or a molded inductor or whatever will exhibit enough inductance and low enough DC resistance. I used disk ceramic capacitors.

But it is not the end of the story. [Note to the casual reader: what follows applies to this specific transverter board]

After correcting the self-oscillation, current drain was above 40 mA. Not bad, but I had measured 24 mA.
When I connected back the transverter PTT control to Arduino, the XV went into TX. This means that the 5V from Arduino is not high enough for the transverter circuitry. I added a BJT buffer and everything went back to normal. I just needed to update the sequencer firmware.

On-the-air test to follow!

Transverter boxed. PA self-oscillates

The Ukrainian 4m transverter has been installed into the final box, including IF relay and A*duino sequencer. The container is a repurposed manual KVM (Keyboard, Video, Mouse) switch and pre-drilled holes hold flanged BNCs just right. Also the VGA connector was a good a sturdy way to bring data from the FT817, pre-wired:

The smoke test did not produce actual smoke, but the current drawn is close to 1A. Considering the transverter should be in receive mode, that's not normal. Leaving it on a few seconds the Mitsubishi PA final warms up, so it is probably self-oscillating somewhere.

I have never troubleshoot a self-oscillating PA, just quickly read about it. I am thinking of two causes: either the DC supply cord is too long and lacks decoupling or the transverter board is too close to the box/ground.

System Noise-Figure Analysis for Modern Radio Receivers (link)

One guy at MAXIM Integrated has published an interesting paper about System Noise-Figure Analysis for Modern Radio Receivers. There is a little math and examples of measurement on DSB and SSB receivers.


And don't forget to check their Tutorials area (linked in the page above), with other interesting writings.

All well worth a read.

Transverter sequencer with Arduino

Even if not explicitly mentioned, I decided my 70 MHz transverter needs a switching sequencer. Any existing solution I could find online uses either discrete components and ICs or a microcontroller I cannot handle (PICxx series).

Given the widespread availability of Arduino derivatives, their low cost (< 10 USD) and their extreme flexibility, I preferred to go down this route. Besides, an Arduino board allows for easy firmware changes (just plug it to an USB port of a computer!) and can be programmed for CAT communication with the FT-817 and alike (FT-857, FT-897, FT-100).

The sequencer code uses a level change interrupt (on INT0) to monitor the PTT line output on the CAT port ("TX GND"). This line goes to logical low level when the PTT is pressed

Once a transition RX-to-TX is debounced and detected, the main loop switches in sequence the IF input attenuator (not needed in RX), the transverter PTT and enables RF output on the radio (pulling down the "TX INH" line). Small delays allow for each change to be applied by the involved circuitry, being the relay the slowest to react. The TX-to-RX transition reverses the sequence described above.

At startup the sequencer inhibits RF output and configures itself in RX mode.

This is not rocket science at all.

If another output is needed it is just a matter of adding few lines of code. An extension to the code should allow to switch the RTX to the IF center frequency (29.200 MHz USB in my case) as well as make sure the FT-817 RF power is the lowest possible. Then drive a status LED, monitor the transverter PA temperature, ...

Transverter 29/70 TX'es fine

In a careful hurry I checked the 4 m transverter if it is suitable for SSB traffic.

Since it must be driven with 100 mW, a 7 dB attenuator was built so that FT817 500 mW would not fry the mixer stage. A "real-world" 7 dB Pi-attenuator consists of a 2W 120 ohm resistor across, 47 ohm straight, 120 ohm across. I used standard carbon resistors and a quick check with MFJ-259 reported a 1.2:1 SWR max up to 170 MHz.

With full manual switching I listened to my whisper transverted to 70 MHz on a different receiver and it sounded good.

This was the "GO" signal to start planning for a sequencer (probably embedded into one of my I-F-R-K accessories) and a suitable box: this time I will have to do the mechanical work!!

Near Field Communication recycling

I have attended a speech at the local Linux Day 2013 about Mifare Ultralight NFC ("Near Field Communication") cards and implementation bugs that render the system vulnerable to some "attacks" (now fixed, too late ;-) ). They were at DEFCON 2013 too.

These cards operate at 13.56 MHz and can carry some data as well. They are being widely adopted as electronic tranportation tickets, access badges, ... Since they come with a factory programmed unique ID, some DIY recycle is possible at almost no cost.

The speaker has described the data memory map of those cards and explained how some bytes are one-time programmable: once a bit is set to "1" it cannot be returned to "0". That is how some transportation systems keep count of used/available tickets on the card. The data area remains rewritable and the unique ID cannot be changed.

Reading (writing) these NFC tags is pretty cheap (about 20 USD@2013) and can be done with a computer or an Arduino(-like) board. Of course some sort of software is needed to interact with the reader hardware and the card.

Since I am curious about this technology I have ordered a card reader/writer at least to see what kind of home applications can be tought of. A poor man's presence detection, for example, or an authorization system for you-never-know-what.

It is QRP afterall :-)