20 April 2015

FSQCall on 60m


I've been playing around a little with FSQCall on Linux. It runs fine under wine, although I've never tried using the CAT control as I used vox via a G4ZLP soundcard interface with my KX3.

The only real issue I faced was a problem with the display of the RTF formatted help text on the Rules and Syntax pages, which showed the raw RTF markup.

I thought winetricks might provide a solution and I was right.  Rather than fiddling around I went straight for the scattergun approach and installed all of the packages that mentioned RichEdit, as shown in the picture below.


This fixed the issue.  The only other UI quirk is the brightness slider, which is apparently falling back to a basic widget rather than one that matches the rest of the UI.  There might be a winetricks  solution for this too, but I've not bothered looking for that yet. Another minor oddity is that two audio sinks and sources show up in pavucontrol for each running instance of FSQCall.  I set them both to the same device (or null sink).  This is a minor irritation as I have so many sound devices that having pointless ones in the lists marginally complicates the chore of manually assigning audio inputs and outputs.

I've worked a few european stations on 30m (10.144MHz dial)  and 40m (7.044MHz dial), but have gravitated towards operation on 60m, where the de facto spot seems to be a dial frequency of 5.3675MHz.  The nice thing about this spot is that the main spot for Olivia, 5.3680MHz, fits in the receiver passband below the FSQ waveform, as long as the Olivia users aren't running wider than 500Hz.

There are presently two variants of FSQCall.  The US version is the one I find most interesting, as it offers features for message relaying, and has slightly more right-click context menu entries.  The ZL version provides an image transmission scheme. The picture below was my first attempt at receiving an image from GW8ARR.



Some have noted on 60m that FSQCall isn't as robust as Olivia, and I would tend to agree.  Perhaps a little FEC would cut down some the errors.   I don't really think of FSQCall as a QSO mode though.  It seems more like an IRC for HF, suitable for chatting.

There are presently two variants of FSQCall.  The US version is the one I find most interesting, as it offers features for message relaying, and has slightly more right-click context menu entries.  The ZL version provides an image transmission scheme.

I have 2 pieces of advice for new FSQCalll users:
  1. Always enter your callsign in lower case. The modem is optimised for this, and the SELCAL is case-sensitive, so other users will know that you didn't RTFM before trying it, even after you subsequently edit your callsign, as they will see both versions in their heard list.
  2. If you adjust your receivers pass-band filter, you will notice that the SNR meter varies.  With a pass-band width of 500Hz, it will show about 0dB SNR on background noise. You need to click in the SNR meter to set the squelch level just above the background noise level, for two reasons. Firstly, to squelch the modem and supress spurious characters and secondly, to let the CSMA-like channel access mechanism do its job properly in SELCAL mode.  If you don't set the squelch threshold appropriately, you will find that you cannot transmit.

I've not been on 60m for a few days now, as there has been a new addition to the shack, in the form of an ANAN-100D.  It's arrival has been highly disruptive and has caused a significant refactoring of the distributed shack architecture here.  More on that subject to follow.  First impressions are however, very positive, even without resorting to running Windows software.






10 March 2015

First contact on 60m and the meaning of QSW?

I have just made my first JT-65 contact on 60m with Alexandar, LZ2FP and there was some panic here when I realised where the UK band segment edge actually was.  Alex was calling CQ with the low edge of his signal on 5.358097MHz and that UK band segment is from 5.354MHz to 5.358MHz.

It pays to remember these things!   If you forget, the latest band plans are here.

After a little while (spent facepalming at my ineptitude) I managed to coax Alex down to 5.357800MHz by sending "WORK SPLIT?" and we made the contact.

Whilst sending "WORK SPLIT" via JT-65 I had more than enough to time to visit wikipedia and discover that sending "QSW?" would have probably been more conventional:

QSW? - Will you send on this frequency?

My KXPA100 has arrived and is working nicely.  I needed a few more watts of  grunt to compensate for my somewhat short transmitting antenna. Happy days!
 

I've only just noticed that it took nearly half an hour to make that QSO!  Still, I find it best not to rush things.

Update:  Philip, G0ISW, has a nice article about doing this the right way.


17 February 2015

Rx antenna switching with the KX3, Wellbrook Loop and a modified MFJ-1707

My new Wellbrook ALA1530PE receiving loop has been performing very nicely, feeding my KX3 and FCD-Pro+ though a combiner, but so far I have been carefully avoiding any transmitting in order to avoid destroying the loop amp and SDR dongle.

I procured an MFJ-1707 thinking that this might be a reasonable solution, as it is mentioned in the RadCom article on the Wellbrook loop.

I decided to try it out with a dummy load connected as the receiving aerial, and my wire antenna as the transmitting aerial and see what happened.

With power not applied to the 1707, the KX3 was hearing through the wire antenna, as expected.  With power applied to the 1707, the rig went deaf, using the dummy load for an antenna.  So far so good.  My plan was to use the KX3's keyline output as a control line to the 1707.

I had also purchased an Elecraft KX3-PCKT cable set for the KX3, so I had the ACC2 module which allowed me to use a mono phono cable to hook up the KX3's keyline output to the 1707 directly.

However, when I connected it to the powered 1707, the relay in the 1707 de-energised immediately, switching back to the transmit antenna despite the fact that the KX3 was not transmitting.  I puzzled over this for a bit, and then got out my DVM.  Sure enough, the centre of the phono socket on the ACC2 module measured 0V with respect to the 13.8VDC supply line whether the KX3 was transmitting or not.  This had me confused.

I started to wonder about writing to the Elecraft list to ask about this, but then I began to fiddle with the ACC2 IO setting in the menu.  I wondered if I could set up a physical transmitter inhibit interlock.  I quickly bodged together a 3.5 mm mono jack plug wired as a short and confirmed that it would enable the transmitter inhibit function.  I went back to check the status of the Keyline output of the KX3 with the transmitter inhibit enabled, and was surprised to note that it seemed to be operating normally now, pulling down to 0V when the KX3 attempted to transmit and back to floating with the KX3 in receive mode.  More interestingly it now did this whether the transmitter inhibit was active or not.

Swiftly forgetting about the anomaly with the formerly always asserted keyline output of the KX3 I wondered about the prospect of a closed-loop solution, using the auxiliary contact closure output on the 1707 to manipulate the KX3's Tx inhibit line via the ACC2 IO.

With the MFJ-1707 un-powered, the Tx antenna is selected and the Aux output is left floating.  When the 1707 is powered, the relay selects the Rx antenna and grounds the Aux output.  When the keyline control from the KX3 asserts, the relay switches back to the Tx antenna and lets the Aux output float.

By connecting the Aux output to the KX3 and configuring the ACC2 IO menu option to "LO = Inh", the KX3's trnamsitter is inhibited whenever the receive antenna is active and the trasnmitter becomes dis-inhibited when the transmit antenna is selected.

On the face of it, this looked like a great solution, but something troubled me.  I realised that if the ACC2 stereo 3.5mm plug was pulled out of the KX3, the keyline wouldn't switch the 1707's relay and the ACC2 IO input would float hi,, dis-inhibiting the transmitter and probably blowing up the Wellbrook loop's amp during transmission.

I didn't like that at all.  The stereo 2.5mm plug for the I/Q output on the KX3 had come adrift enough times during rats-nest manipulation to make me consider the alternative solutions.

I mulled over the notion of bodging in an open collector stage between the aux contact on the relay and it's phono socket, as it would invert the aux-output logic for the Tx inhibit function and it seemed safer than the other alternative I'd imagined which involved strapping the other side of the aux contact to 12V instead of 0V.

A 2N2222A was handy.  It's emitter was strapped to ground and the base pulled up to 12V with a 10k resistor. The base was also connected to the pad where the aux phono plug's centre had previously been connected.  The aux phono plug's centre was now connected to the collector of the transistor.

It looked like this:








Now with the KX3's ACC2 IO set to "HI = Inh", whenever the KX3's keyline out asserts, the 1707's relay switches to the Tx antenna,  Aux output pulls the ACC2 IO input down and the KX3's transmitter is dis-inhibited.  If the ACC2 stereo plug falls out of the KX3, or the keyline and/or Aux/Tx-Inhibit cables become disconnected at either end, or their conductors fail, the KX3's transmitter remains inhibited.  I liked this.

The only unexpected result of the mod was that without power applied to the 1707, the KX3's transmitter was dis-inhibited.  I hadn't expected this, but I suppose there's enough leakage to pull down the  ACC2 GPIO line.  I like this also.  Without power applied to the 1707, the transmit antenna was selected so there was no need for the KX3's transmitter to be inhibited.

I've tested it thoroughly with a dummy load in place of the Wellbrook loop, and it seems good.  I'm pretty happy with this solution.

Now, the biggest risk seems to be the idiot wearing the headphones.  If I somehow modify the ACC2 IO menu option, I could blow up the Wellbrook loop.  I think I'll ask Wayne at Elecraft if he would consider modifying the ACC2 IO option to make it locked, requiring a long press of the RATE button on the KX3 to unlock it.  Then I'd feel really safe.

Now this is all done, I suppose I should get on and make some QSOs.  It has been a while.

17 January 2015

New Wellbrook loop reveals significantly more contesters.

Here's a pic of the professionally installed new Wellbrook Loop here.


I nailed a spare mast post into the ground with a mallet and duct-taped the loop to it.  Some self-amalgamating tape applied to the coax connector and it was good to go.


This pic shows some of the contesters on 40m, being received on the new loop.


The change in the waterfall shows what happens when I switch back to the Diamond BB6W wire antenna.  The loop is mounted at ground level and is underneath the wire antenna.

The next screen shot shows the power spectrum with the BB6W feeding the SDR gubbins, which incidentally has my KX3 at the front end thanks to ghpsdr3-kx3-server.


The results are equally if not more impressive on other bands, but less significantly so on 15m and up.


I'm very impressed so far.  It really is good!

More pics. Now of 60m.  You can see an Olivia transmission with an RSID start up in the middle of the spectrum.  This one shows the power spectrum from the loop.


 This one shows it for the BB6W.


Note that the power spectrum is un-calibrated and that the waterfall adjusts its gain automatically.  I tend to crank the gain up on the KX3 with the preamp to lift the noise base up above the artefacts of the sound card, so I don't get distracted by them in the waterfall.

The next shot is a different instance of QtRadio, coincidentally also on 60, but this one is using my FCD-Pro+, also fed from the Wellbrook loop and has an instance of fldigi decoding the Olivia.


Some more pics from 80m.  This one is the power spectrum for the loop.


And the BB6W on 80m next.



31 December 2014

ghpsdr3-kx3-server available on github

Having fiddled with fcdpp-server.py to add a ppm offset option before Xmas, I'd been wondering about bodging it to work with my KX3 as an I/Q source.

I had a go earlier this afternoon.  It took all of 10 minutes of python hacking to get something that functioned.  A few more minutes were spent adding command line options.  Now ghpsdr3-kx3-server is available on github.

I hope someone finds it useful, although it is receive only.

Happy new year, everyone.