CW contesting with the HL2

[Matthew]

I did a session in CQWW using the HL2 this year. For software I was using linhpsdr. I had intended to use it for the whole contest, but linhpsdr kept crashing when I was changing frequency over CAT to a cluster spot from my contest logger (tlf). With some of the settings not being saved for HL2 configuration (Apollo filter to enable PA) after each crash I had to redo the settings. I eventually got fed up and went to non-SDR. I need to set aside some time to get stuck into gdb with linhpsdr and try to fix this.

HL2 was performing well at 30 wpm, not a single HL2 crash. I have to be honest I did get rather tired of the relay clicking, but given the radio is designed to not be at the operator desk I can't really complain. I may look at replacing the relay with some solid state switching. I think someone on the group previously mentioned they had a design for such a thing that could drop in place of the relay?

I found the performance of the HL2 receiver to be really good in a contest environment. Switching back to my Kenwood TS570, I did find the Kenwood much more fatiguing on my ears (plus I lost the waterfall capability!).

I had to use sidetone from the buzzer in a K3NG type keyer. This wasn't great. No one seems to have created a linux winkeyer daemon with sidetone on the PC, in the modern world of remote radio I find this odd. There are various winkeyer daemon applications that I have looked at modifying, I'm most comfortable with Python, so I have a very rough proof of concept with audio added to this https://github.com/drewarnett/pywinkeyerdaemon I'll try and do some more work on this at some point and make a pull request to the author.

I think the HL2 would be a really good remote contest radio for Linux users with a few tweaks I hope to find time to make in the coming months.

73 Matthew M5EVT.

[Steve Haynal]

Hi Matthew and Group,

One item on my list is to have remote CW for the HL2. This is what I am currently thinking:

** Enable CWX in PowerSDR as a start.

** Connect a CW key or paddle to the host PC via MIDI. This can be done with a <$10 arduino or teensy and this library. There are lots of hits and examples if you google arduino teensy and MIDI. the MIDI infrastructure is tuned for low latency. I use a musical MIDI (USB) keyboard at home with sound produced by the PC and latencies are not noticeable. If they were humanly noticeable, people would not use virtual MIDI instruments. SparkSDR already knows about MIDI. 

** Create a small program on the host to generate the side tone and send UDP packets. The side tone would use ASIO or equivalent low latency audio drivers. I would like to open another ethernet port on the HL2 to accept simple side traffic to the HL2. It is a lot of overhead to support the full protocol and I would like to be able to send things like CW key down/up/dot/dash via an asynchronous side channel still using UDP while other software runs. The user side tone experience at the PC should still have unnoticeable latency. The actual CW reaching the HL2 may have ~30ms latency, but compare that to 66ms for radio waves to travel half way around the earth.

** In the longer term, I'd like to develop this simple side channel to accept TX information such as amplitude, frequency, phase and duration of a tone. This would allow us to send WSPR and FT8 at a low level so that enough information is present in the HL2 to null out harmonics. I did experiments along these lines years ago and would still like to develop this. Imagine no N2ADR filter board required for some modes of operation. This would also allow use to shape the CW tone sent to the HL2 and offload that task from the HL2 while providing the flexibility of software.  

I have stopped work on any local sidetone at the HL2 using PWM and the circuitry on the front panel. It is a step towards forcing an operator to sit in front of the HL2 that I would like to avoid, plus it is a half measure without mixing/headphones, etc, that will never truly satisfy someone who wants to sit in front of the HL2. There are other solutions if you really really want to operate in front of your HL2.

It is all a matter of time and priorities so I won't make any promises for delivery dates. I have too many irons in the fire. If you or anyone wants to work along these lines, I am happy to provide help and assistance.

In my opinion, this is what *software* defined radio is about: moving as much functionality from hardware to software as can sensibly be done. Also, it still keeps the Hermes-Lite *Lite* and true to the original objective.

73,

Steve

kf7o

[Graeme Jury]

Hello Steve,

I like the way that you are thinking. Some years ago I was using software called sdrShell which was a shell over dttsp and it had a cw module which worked really well. I don't know where to find the project online now but if you are interested in having a look at what they did I can see if any of my historical backups have a copy.

I still believe that a dsp server connected to a ddc/duc radio and a thin client console would be a great asset and provide the versatility for add on modules. The dsp server would help relieve demands on the FPGA if done right.

73, Graeme ZL2APV

[Raj, N2RD]

I like this 'radio remote' approach.

One way to do CW could be to start with a Midi key to generate sidetone audio (single frequency) that could be treated as SSB on the radio.  This is the SSB CW idea that has been discussed off and on.  If the mixing is good and the side tone is pure, there should be no distinction between that and keying the carrier.  

Raj, N2RD

[Roger Critchlow]

https://github.com/recri/keyer has most of the code to implement this if you're willing to put up with my Tcl/Jack/Linux/Teensy implementation. 

-- rec -- ad5dz --

--
You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/782e2090-c90b-47da-88ce-d70a02b78cbf%40googlegroups.com.

[Steve Haynal]

Hi Roger,

Thanks for the reminder. This is a great reference.

73,

Steve

kf7o

To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite+unsubscribe@googlegroups.com.