Hardware PTT and Key Interaction

[James Ahlstrom]

Hello Group,

Could someone else please test this? I am working with the HL2 3.5 mm phone jack at CN4. I assert PTT, then without releasing it, I assert the key. When I release both PTT and the key, the PTT bit  C0 bit zero stays high if the mox bit is set. In this state, the HL2 sends a steady CW carrier. I thought the returned PTT bit would just follow the hardware state, not follow the mox bit.

This results in lockups. When PTT is asserted, Quisk sends the mox bit to transmit SSB. The user then hits the key and releases it. The HL2 sees the mox bit as set and transmits a CW carrier forever. Quisk never releases the mox bit because it sees the PTT bit high.

Jim

N2ADR

["Christoph v. Wüllen"]

Since I use the HL2 with a keyer (that sets PTT and KEY at the 3.5mm jack) without problems,
it seems odd to me. So I did the experiment:

- start piHPSDR, use CW mode, "CW handled in radio"

- A. connect GND of 3.5mm jack with PTT:
==> TRX relay clicks, PTT bit is sent to piHPSDR which goes into TX mode

this connection is being held.

- B. connect GND of 3.5mm jack with CW:
==> a CW carrier is sent

- disconnect GND of 3.5mm jack from CW:
==> CW carrier stops

not no relay clicking etc. while connecting/disconnecting CW input

- disconnect GND of 3.mm jack from PTT:
==> relay clicks, pihpSDR goes RX (which means PTT bit in HPSDR stream
is cleared).

So far, all perfect.

Now the other experiment:

step A and B the same, but then:

- disconnect PTT while CW active
==> NOTHING happens

- disconnect CW:
==> CW carrier drops, relay clicks, pihpsdr goes RX

I my view everything is exactly as it should be.
And this also applies if I switch to USB mode etc.

So can you tell me the exact setup?

> --
> 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/31310a98-5c95-4b80-811d-1fc89f124fb4n%40googlegroups.com.

[James Ahlstrom]

Hello Christoph,

Thanks for looking into this. Please try this:

Start piHPSDR, set full duplex mode to see the transmitted waveform.

Set mode to SSB.

Ground the 3.5 mm jack PTT.  The PC sends the mox bit as 1. The HL2 starts to transmit SSB.

Ground the 3.5 mm jack CWKEY. The HL2 sends a CW carrier, not SSB.

Ground and release the 3.5 mm jack CWKEY: The CW carrier is continuous, not keyed. The key bit sent from the HL2 to the PC does change 0 and 1 correctly.

Release the 3.5 mm jack CWKEY. The HL2 still sends a continuous CW carrier. The key bit is zero and is correct.

Release the 3.5 mm jack PTT. The CW carrier continues and there is no change. The PTT bit sent from the HL2 to the PC is 1, and should be 0.

This is a lockup. But if the PC changes the mox bit to zero, the HL2 returns to Rx after a delay. 

Jim

N2ADR

["Christoph v. Wüllen"]

(See at the bottom firmware gurus: I think the "CWX" condition in the
firmware needs correction)


OK, in addition, I added debug code to old_protocol.c that logs
all *changes* in the PTT/DASH/DOT states *received* from the HL2
and the MOX state *sent* to the HL2.

a) mode=SSB
b) ground PTT connector of Jack

==> PTT bit goes HIGH, pihpsdr goes TX, MOX bit set

c) ground CW connector of Jack

==> CW carrrier sent, DOT bit goes high

d) disconnet CW connector of Jack

==> CW carrier stops (!), DOT bit goes low, pihpsdr stays TX

e) disconnect PTT connector of Jack

==> PTT goes low, pihpsdr goes RX, MOX bit cleared

This is as it should be. I should add that I have no Mic connected for the
test, so there was "silence". Possibly the least significant bit of
the IQ samples are interpreted as CWX?

To check this, I repeat the experiment but use a "local microphone"
that is actually connected and picks up the background noise in my lab.

a) go SSB

b) go "MOX" manually. A very weak signal is transmitted (no deflection
on the dummy load/watt meter), but when I whistle into the
microphone, I can see the watt meter needle moving

c) remove manual mox

d) ground PTT input

==> PTT bit goes HIGH, pihpsdr goes TX, MOX bit set

e) ground CW input

==> CW carrier sent

e) release CW input

==> CW carrier stays although DOT becomes LOW

f) disconnect MOX input

==> CW carrier stays, PTT bit stays high

g) hit MOX manually

==> back to normal operation


So the diagnosis is clear: When triggering CW, the HL2 goes to "CWX" mode and keeps interpreting the
least significant IQ bits as the key-up/down info. Note this happens no matter if the "internal CW"
bit (C1 bit 0 when C0=0001 111x) is set or not (I added test code).

So your "constant carrier" is caused by mis-interpreting the Mic noise floor as CWX data.

If this problem does not occur with other radios, perhaps the firmware should do the
following

if (cw_internal bit set) {
look at CWX
} else {
// do noting
}

Yours,

Christoph

> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/2902aa34-ab20-43ca-90fe-e57056f4ffa5n%40googlegroups.com.

[James Ahlstrom]

Hello Christoph,

Thank you for your great detective work! I never suspected CWX. Now I have to find a way to work around this. I have a very complicated state machine to control Rx/Tx since keying can come from a button, vox, the key, external hardware, midi; and all for many types of hardware besides HL2.

Jim

N2ADR

[Graeme Jury]

Hello Jim and Christoph,

I have been following your tackling of this problem with great interest and must congratulate you both for your tenacity Jim with not letting this one go and to you Christoph for your very clever analysis of the problem. I had been having lockups in the past which was a source of mystery to me and I noticed them coinciding with using the sound from SofterHardware CW Keyer and I was suspecting a memory leak in the keyer's audio software. However I have installed the new version of Quisk and so far so good. I used the 4.1.95 version of Quisk last night for a CW contest and disabled the microphone input sound device which fixed the problem. I might add that when in SSB mode I had the habit of tapping the dash paddle to check my SWR when QSY to make sure that I was still at an acceptable level thus raising the possibility of the problem. I have some associated things to say about the SofterHardware CW Keyer but I will keep them out of this thread.

73, Graeme ZL2APV