Fix to get CW sending working again

[vu3rdd]

The CW Daemon/HL2 related changes had broken CW sending for HPSDR. These commits fix them and also provides better defaults for CW.

[m5evt]

Unfortunately, this breaks cwdaemon/remote CW (with the HL2). I am confident a solution can be found for everyone.

For Anan/HPSDR radios how does the user enable PC sent CW (seemingly called CWX by PowerSDR users?), is this also with Bit 0 of C1 when C0 = 0x1E?

[vu3rdd]

@m5evt Oh. :-( Is the design for remote CW/CWDaemon described somewhere? I can try to come up with something that works for everyone. Wondering if we can offload parts of the function to be a runtime function (via function pointers) that can be selected based on the user input on which radio they are using?

I believe PowerSDR CWX would also use the C1|bit 0 (internal CW enable/disable) when C0=0x1E.

[m5evt]

The remote CW/CWDaemon continues to be an experiment created my me that is not very well documented. Graeme zl2apv kindly wrote up some notes for a user here:

https://raw.githubusercontent.com/wiki/softerhardware/Hermes-Lite2/docs/CW_and_Logging_on_linHPSDR.pdf

I've just been looking at the Hermes verilog - to enable CWX (PC sent CW via I[0] of IQ stream) C1 bit 0 is set to 1, this is the same as the HL2.

My thinking of the logic of the code around line 1522 of protocol1.c was that the user either has remote CW (controlled by MIDI/cwdaemon etc) or FPGA controlled CW. Recently I've since realised these are enabled by the same bit state.

The internal keyer can be set to 1 AND remote CW can be enabled. The PC will produce sidetone for remote CW, but this will not be sent to the HPSDR audio codec. The HPSDR (non HL2) radio will produce a sidetone, but this will not be sent to linHPSDR? There is potential for conflict between remote CW and a paddle connected to the front panel of the HPSDR radio, but I guess the HPSDR FPGA gateware handles this?

By default cw_keyer_internal is set to TRUE, so I guess CWX is enabled on the HPSDR radios by default in linHPSDR (if the FPGA gateware allows for it)?

With CWX enabled (cw_keyer_internal set TRUE), with I[0] of IQ stream = 1 what stops the radio transmitting (when you don't want it to)?

[m5evt]

A feature of cwdaemon in linHPSDR that is not described in the document is that logging software can send keyboard/macro CW (via cwdaemon server, then by CWX to the radio). This works with cqrlog, tlf and yfktest. Hopefully it is fairly intuitive to try it out with cqrlog.

[vu3rdd]

The remote CW/CWDaemon continues to be an experiment created my me that is not very well documented. Graeme zl2apv kindly wrote up some notes for a user here:

https://raw.githubusercontent.com/wiki/softerhardware/Hermes-Lite2/docs/CW_and_Logging_on_linHPSDR.pdf

Thanks.

I've just been looking at the Hermes verilog - to enable CWX (PC sent CW via I[0] of IQ stream) C1 bit 0 is set to 1, this is the same as the HL2.

I just verified it in the Metis.v file. (Warning: I am not a verilog/fpga programmer, I can barely read the code..)

assign  CWX = (IF_I_PWM[0] & internal_CW);

and then this is passed to the iambic.v module where it would just do nothing (and keeps looping?) and sets the keyout wire value to 1. That would in turn produce the side tone.

My thinking of the logic of the code around line 1522 of protocol1.c was that the user either has remote CW (controlled by MIDI/cwdaemon etc) or FPGA controlled CW. Recently I've since realised these are enabled by the same bit state.

The internal keyer can be set to 1 AND remote CW can be enabled. The PC will produce sidetone for remote CW, but this will not be sent to the HPSDR audio codec. The HPSDR (non HL2) radio will produce a sidetone, but this will not be sent to linHPSDR? There is potential for conflict between remote CW and a paddle connected to the front panel of the HPSDR radio, but I guess the HPSDR FPGA gateware handles this?

I guess that assumption about PC producing sidetone is correct when both the options are enabled (based on the above understanding of the Verilog code). The sidetone is directly sent via the audio codec on the Mercury board to the headphones. The way I am using the HPSDR boards, the PC only acts as a processing unit and UI. Audio/CW in and out are directly via the direct connection to the hardware.

May be this can be an "either-or" setting in the linhpsdr configuration UI? i.e. One can only enable internal CW or remote CW at any given point of time?

By default cw_keyer_internal is set to TRUE, so I guess CWX is enabled on the HPSDR radios by default in linHPSDR (if the FPGA gateware allows for it)?

On HPSDR, the internal keyer is a configurable option (C0 = 0x1E, C1| bit 0).

With CWX enabled (cw_keyer_internal set TRUE), with I[0] of IQ stream = 1 what stops the radio transmitting (when you don't want it to)?

The HPSDR fpga code certainly does not stop it. I think that is intentional? For instance, you want to send CQ CQ via CWX but without pushing any buttons on UI, also want to use the key to answer anyone or respond to the station who answered your CQ?

Not sure if my comments are very sensible or not. I am just thinking aloud. I am new to linhpsdr code (was using PowerSDR until recently, but I no longer have access to a Windows computer and am not going to bother getting one - so getting linhpsdr in a shape that is usable as a daily driver is very important to me, so I just started reading the code). I unfortunately don't have an HL2. But perhaps we can test each other's changes. I don't have the CW daemon setup yet. But I can do that and do some testing. I will have to do that anyway.

I just realized that

[vu3rdd]

@m5evt are your unixcw change, part of upstream? Would be great if they are upstream, that way it would be fairly easy to install a regular cwdaemon from OS package manager and use it in the future.

[m5evt]

My concern was that a packet sent from linHPSDR to the radio could trigger CWX to engage when it was not wanted. However, I have inspected the code and looked at packets with wireshark. I am content that in CW and USB, linHPSDR sends 0's to radio (protocol1_iq_samples() in protocol1.c). My concern is not valid.

Therefore, I think that the single line I described here:

#70 (comment)

Fixes this whole issue with CW at the radio and cwdaemon still works. Can you confirm this?

My unixcw changes are now in the repository that I forked, but the maintainer does not plan to release to OS package managers for a while yet.

P.S. is your HPSDR radio capable of diversity? I would like some beta testers on the diversity code I am working on for linHPSDR.

[vu3rdd]

Sorry for the late response @m5evt. Since we talked, I have managed to burn the finals of my 20W PennyWhistle and also the 1/2 Opamp amplifier that sits on the Penelope board. I have spares for the Penelope board parts, but not the MOSFETS. So, I hope to get Penelope back in shape this weekend. I will test the change you suggested once I fix the hardware.

[m5evt]

Do you have any update on whether the single line I reference fixes this bug?

I believe you need to edit the following line:

https://github.com/g0orx/linhpsdr/blob/master/protocol1.c#L1557

to be:

  if(radio->tune || radio->vox || !radio->cw_keyer_internal) {

And ensure that cwdaemon is turned off in the makefile.

If this works I will add it to #109 and we could close this PR?

P.s. I have completely re-worked the PC generated CW for linHPSDR in my fork and I believe this should better allow for HPSDR radios with an audio codec and the HL2 to coexist. I would welcome any feedback.

[andreasdotorg]

Unsure about that one. Would need testing on whether this fixes things.