HL2 CW firmware problem

["Christoph v. Wüllen"]

Hi all,

I spotted a problem with HL2 that indicates a firmware
problem.

Observation: when in USB mode (in piHPSDR), and connecting
the tip and the sleeve of the KEY/PTT jack, the HL2 emits
a CW carrier and this does not stop if the tip is disconnected.
Furthermore, the HL2 report "PTT on" constantly to the SDR
application.

One can stop this behaviour by zeroing out the TX IQ samples
(this is the result of a hefty debug session).

I think this is a firmware problem for the following reason:

- in USB mode, internal CW is disabled. In HL2 speak this means
bit ADDR=0x0F bit=24 is *not* set. This bit is called in the HL2
protocol "Enable CWX, I[0] of IQ stream is CWX keydown".

I think this should disable the CW input. But it comes even worse:
it seems that pulling down the CW input enables CWX unconditionally,
and then the HL2 continues to emit RF forever since in USB mode, there will always be a
microphone noise floor and hence I[0] will be set almost all the time.

I ask you to confirm if this happens with other SDR software as well,
if so, this should be corrected in the firmware. It is of course possible
that I did something wrong, but I have checked it fairly well.

Yours, Christoph DL1YCF.

[G4ZAL]

Hello Christof,

I made a short test in Thetis and Quisk - both in a Windows 10 PC.

I made a quick 3.5mm stereo plug with a wire connected to the tip and can manually short it to the sleeve.

In Thetis for HL2, in USB (or LSB) mode, shorting the 3.5mm plug puts the HL2 into Tx with 5w constant output and Thetis MOX button is indicated for Tx.

Unkeying the 3.5mm plug and the HL2 stays in Tx with constant 5w output and MOX button stays engaged.

Closing Thetis or clicking the Power button, releases the HL2 from Tx.

Using Quisk in USB (or LSB) mode, shorting the 3.5mm plug puts the HL2 into Tx with 5w constant output and Quisk Tx button indicates Tx. 

Unkeying the 3.5mm plug stops the HL2 from Tx and Quisk Tx button does not indicate Tx (and goes back to normal Rx operation).

HTH

Nigel

G4ZAL

[Max]

Must be specific to Thetis. I have SDR Console and see exactly the expected behaviour regardless of mode, that is, tip initiates CW carrier, releasing stops carrier and releases T/R relay after the CW hang time specified in SDR Console. SDR Console also allows some variation in TX power out when in CW mode. Range of this is limited due to using the small range of gain control inside the HL2 as in "front panel" CW mode there is no control over signal via I/Q obviously.

Ring works totally independently as manual PTT so that optionally, PTT can be initiated with a separate (foot) switch in CW mode prior to keying the TX. I often use the footswitch when operating slow CW to prevent unwanted reversion back to RX. It was made this way intentionally back in 2020 by Steve as requested by myself for exactly that reason. As far as I recall originally the ring PTT would stop power out during "front panel" CW mode if using the tip. You can see the history of this development in this thread. Hope it clears things up. I believe that Steve changed the PTT behaviour to my request from 70p2.

https://groups.google.com/g/hermes-lite/c/EjJmbZZ6aqY/m/r5csPN08AAAJ

73

Max

On Friday 22 December 2023 at 15:46:51 UTC "Christoph v. Wüllen" wrote:

[DL1YCF]

> Am 24.12.2023 um 15:38 schrieb Max <radi...@mail.com>:
>
> Must be specific to Thetis. I have SDR Console and see exactly the expected behaviour regardless of mode, that is, tip initiates CW carrier, releasing stops carrier and releases T/R relay after the CW hang time specified in SDR Console. SDR Console also allows some variation in TX power out when in CW mode. Range of this is limited due to using the small range of gain control inside the HL2 as in "front panel" CW mode there is no control over signal via I/Q obviously.
>

I have now two reports that are consistent with the observation that „release tip“ only stops CW carrier
if the IQ samples are zero (most likely, it is bit0 of I that matters). I have also tested this with
modifiying the code. So the problem occurs if you are in SSB mode and you have a microphone attached.
Then, the audio noise floor keeps CW going.

The other question is, whether tip should initiate CW carrier if in SSB mode. I say „no“.



I have not problem with the PTT contact („ring“).

> --
> 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/f269a756-85f1-413d-b807-019d839bc4c6n%40googlegroups.com.

[Max]

Apologies. I went back and re-tested in SDR Console. What you have described is totally correct analysis. If there is an active audio source connected to mic input with SSB mode selected then exactly the behaviour you describe is observed.

How you get around this I am not sure? And also the question is why be in SSB mode for CW operation using the front panel jack? Maybe there is a reason I didn't think of?

73

Max

[John Williams]

Not sure about SSB but I rely on being in AM mode and getting CW with the key. I use this to excite my plate modulated AM transmitter and use Thetis for RX. The transmitter actually keys the HL2 from the sequencer as a part of the PTT sequence.  See my QRZ page for more info.

W9JSW 

Sent from my iPhone

On Dec 24, 2023, at 11:35 AM, Max <radi...@mail.com> wrote:

Apologies. I went back and re-tested in SDR Console. What you have described is totally correct analysis. If there is an active audio source connected to mic input with SSB mode selected then exactly the behaviour you describe is observed.

--
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/5c7542d4-b663-415f-b8cc-6bf19c81db97n%40googlegroups.com.

[K7MDL]

Regarding the question asked earlier   "The other question is, whether tip should initiate CW carrier if in SSB mode. I say „no“.

For VHF weak signal and contesting CW in SSB is very handy when stations you hear on voice do not year you on voice (weak, QRM, QRN).  The frequency can get very busy with locals and being distant requires something different.  Contacts are short and when needed can send CW in SSB without playing with radio dials, even more important as a Rover.  Often the called station comes back in SSB, many stations I know do not even have a Key.  

In a nutshell we operate a fair amount in mixed mode. Being in CW mode, often with having an offset, the filters are not good or hearing a voice response.  Some radio will transmit on the carrier and not shift up so the SB station can hear you.  If I have to take the time to tweak the mode and filters then I can miss the contact.   I find this is a VHF thing mostly.  

Bottom line, when possible, such things can be configurable.  On the K3 for example, you change to CW mode, enable VOX then back to SSB mode.  CW in SSB then works and is remembered per band.   I think the Icom IC-905 has a setting called CW in SSB or similar.  It will shift the frequency by the pitch amount so it is not on the carrier and missed by a voice stations.  My IC-706 does not do that, was always a pain.

Mike K7MDL

[John Williams]

We should be asking how the Anan functions. It has a key jack on the front. Hermes board as well. 

---

From: herme...@googlegroups.com <herme...@googlegroups.com> on behalf of K7MDL <k7...@hotmail.com>
Sent: Sunday, December 24, 2023 2:05 PM
To: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: HL2 CW firmware problem

 

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/1b50fdbf-b8f0-4ba9-a8a4-c36d436009can%40googlegroups.com.

[Steve Haynal]

Hi All,

Which version of gateware exhibits this problem? The most recent "testing" one with the change for TX inihibit, or both "testing" and "stable?"

73,

Steve

kf7o

[DL1YCF]

Of course you can think it is an operator error. BUT:

if your are in SSB and unconciously hit the Morse key,
you simply do not expect the rig emits a carrier and
nothing stops it except explicitly removing VOX or so.

I clearly think the firmware should not behave this way.

> --
> 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/5c7542d4-b663-415f-b8cc-6bf19c81db97n%40googlegroups.com.

[DL1YCF]

The main problem is not that the HL2 goes CW. As I said it is
a matter of taste whether hitting the key should have an effect
when *not* in CW mode.

The real problem is that it then
starts to interpret bit0 of the I samples as „CWX“, and this means
releasing the (physical) CW key does not stop transmission.

> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/B6C3BA54-4C87-4434-9AE6-17BB4989F2C4%40gmail.com.

[DL1YCF]

I have the most recent one with TX inhibit, but I can volunteer to check
other firmwares as well.

Note the „SSB problem“ only occurs if you have a microphone attached,
the problem is that all of the sudden bit0 of I is interpreted as „CWX“.

With a huge debugging effort, I have verified that *only* zeroing out
the IQ samples will stop the CW.

> Am 25.12.2023 um 02:17 schrieb Steve Haynal <softerh...@gmail.com>:
>
> Hi All,
>
> Which version of gateware exhibits this problem? The most recent "testing" one with the change for TX inihibit, or both "testing" and "stable?"
>
> 73,
>
> Steve
> kf7o
>
>
> On Sunday, December 24, 2023 at 1:01:36 PM UTC-8 John Williams wrote:
> We should be asking how the Anan functions. It has a key jack on the front. Hermes board as well.

> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/27fd2308-e86b-48bf-adcb-e79cd368123cn%40googlegroups.com.

[Alan Hopper]

Hi,

I've not tested this for ages but I believe it all works as it should in spark, maybe this is because iq is zero'd when tx stops, i.e. mic data is replaced with a silent iq stream when no ptt.

73 Alan M0NNB

["Christoph v. Wüllen"]

Dear Steve, dear all

I have tested several gateware images, namely

818b1f9b8d49dfc8dee96ce9ba85f65f ./bitfiles/stable/20210730_73p2/hl2b5up_main/hl2b5up_main.rbf
fee738911b93869c26e69b5914f1c218 ./bitfiles/testing/20220109_73p3/hl2b5up_main/hl2b5up_main.rbf
339f7b9b9b3ea677c9fb27720c236ee2 ./bitfiles/testing/20231208_74p1_a0bcd34/hl2b5up_main/hl2b5up_main.rbf

each line starts with a MD5 checksum, and then the name of the file
as it can be found in the repository

https://github.com/softerhardware/Hermes-Lite2

(so now it should be crystal clear which firmware I took).

The problem is absolutely the same with all three firmwares,
and since there were questions, I repeat the setup. I have
tested it with piHPSDR but got reports that Thetis
behaves the same way.

Setup: mode = USB, 20m band

when *no microphone source* is selected the HL2 shows the following
behaviour: periodically connecting/disconecting the tip and the
sleeve of the Key/PTT jack emits a periodic CW signal. This is
more or less OK.

when a microphone source is selected, then the HL2 starts to emit
a CW signal upon first connect of tip/sleeve and then stays in
transmit if you disconnect. This is clearly not what it should do.

I digged into this, and the "never ending" CW signal transmission
comes from the noise floor of the microphone, which induces a
noise floor in the the transmitted IQ signal, so very often
bit0 of the I samples will be set.

So my impression is that, as soon as the HL2 "goes CW" when
connecting tip/sleeve, it starts to interpret bit0 of I as
a CWX signal although the CWX bit is not set.

This conjecture is supported by the following crucial experiment:

with a modified version of piHPSDR where bit0 of the I samples is
always zeroed the "stay in CW" problem does not occur.

I think the gateway gurus should look at the FPGA code.


Yours,

Christoph

> --
> 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/C5DE6708-3ECC-4723-BFAD-50A00757B198%40darc.de.
>

[James Ahlstrom]

I think the fix for this problem should be in the SDR software, not the gateware. The problem does not occur in Quisk or Spark. The HL2 does not know the mode, and CWX is part of the protocol.

Jim

N2ADR 

[Max]

Did occur to me....... how does the HL2 know the mode? It can't. Glad I'm not going mad!

So presumably solution that at any instance/moment that tip of CW jack is grounded IQ samples are silenced in the software? Jim, if you could confirm in programming terms exactly what is required then as far as SDR Console is concerned I will let Simon know or alert him to this thread (assuming he is not reading this himself which he may well be).

Max

[James Ahlstrom]

We could either fix the gateware or fix the SDR software. Christoph has argued that the gateware is at fault because the CWX bit is not set and yet the gateware is using CWX. I agree, but changing the gateware is a pain and mostly falls to Steve. I think the SDR software is at fault because it is sending non-zero Tx samples to the HL2 even though it is not transmitting anything. That is, it is sending mic I/Q samples in SSB mode even though PTT is not active.

Recall that the Hermes protocol always sends Tx samples even if the SDR is not transmitting. The fix on the SDR side is to send Tx I/Q samples equal to zero when not transmitting.

Jim

N2ADR

[Clifford Heath]

On Fri, 29 Dec 2023, 02:25 James Ahlstrom, <jah...@gmail.com> wrote:

We could either fix the gateware or fix the SDR software. Christoph has argued that the gateware is at fault because the CWX bit is not set and yet the gateware is using CWX. I agree, but changing the gateware is a pain and mostly falls to Steve.

I hope to be able to reduce this dependance on Steve to fix such things, but I don't yet have good enough knowledge of the Hermes protocol to have an opinion on the best way to proceed in this case. I'm away from my computer for another week or more, but it doesn't look like you have agreement on how to proceed yet anyway. 

Clifford Heath 

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/fc81d546-c819-4c59-94b1-e8d6d4bdaea9n%40googlegroups.com.

[Steve Haynal]

Hi Christoph and Group,

Thanks for finding this bug. There is a way for the state machine to enter CW mode via key and then incorrectly respond to cwx bits even if cwx mode (part of Thetis and PowerSDR) is not enabled. I think the gateware should be fixed. I have committed a one line fix to the github and will try to test and release this weekend, unless someone else beats me to that.

73,

Steve

kf7o

[Steve Haynal]

Hi Group,

Please find testing release 74p2 at:

https://github.com/softerhardware/Hermes-Lite2/tree/master/gateware/bitfiles/testing/20231230_74p2_883a338

This should fix this bug, but I'd appreciate testing and reports from others.

73,

Steve

kf7o

[G4ZAL]

Hi Steve, et al,

I tested the new gateware 74p2 and can confirm it now releses/unkeys in Thetis for HL2 (also works fine in Quisk v4.2.28).

This is using the same software and procedure as my original post.

Thetis reports 'FW v7.4' whereas Quisk more accurately reports 'Code version 74.2'

Will test normal operations and report any issue here... but so far, all seems OK.

Nigel

G4ZAL

------------------------------------------

ORIGINAL POST...

I made a short test in Thetis and Quisk - both in a Windows 10 PC.

I made a quick 3.5mm stereo plug with a wire connected to the tip and can manually short it to the sleeve.

In Thetis for HL2, in USB (or LSB) mode, shorting the 3.5mm plug puts the HL2 into Tx with 5w constant output and Thetis MOX button is indicated for Tx.

Unkeying the 3.5mm plug and the HL2 stays in Tx with constant 5w output and MOX button stays engaged.

Closing Thetis or clicking the Power button, releases the HL2 from Tx.

Using Quisk in USB (or LSB) mode, shorting the 3.5mm plug puts the HL2 into Tx with 5w constant output and Quisk Tx button indicates Tx. 

Unkeying the 3.5mm plug stops the HL2 from Tx and Quisk Tx button does not indicate Tx (and goes back to normal Rx operation).

[Hamish Kellock OH2GAQ]

Hi Steve and others,

I made a quick test of the new gateware covering basic operation and those features concerned with the transfer of TxInhibit / CN8, using pihpsdr development version 2.3 from 18.12.2023 as the sdr program. Haven't found any strange issues so far, will let you know when I have finished my testing.

Hamish, OH2GAQ

[Max]

Tried to provoke rogue behaviour in SDR Console as previously observed in LSB/USB mode. Now seems totally fine. CW keys perfectly from front panel jack with no "sticking" in all modes even with strong audio simultaneously injected into audio chain. 

Many thanks for the fix.

73

Max

On Sunday 31 December 2023 at 01:38:25 UTC softerh...@gmail.com wrote:

[Steve Haynal]

Hi Max and Hamish,

Thanks for testing!

73,

Steve

kf7o

["Christoph v. Wüllen"]

> Am 01.01.2024 um 21:01 schrieb Steve Haynal <softerh...@gmail.com>:
>
> Hi Max and Hamish,
>
> Thanks for testing!
>

I can confirm the findings. Here the outcome of my experiment:


a) temporarily removed the workaround in piHPSDR that makes it
immune against the problem

b) started piHPSDR with HL2 and 74p1 firmware: problem present
as described, that is:

- mode = USB, band=20m, local microphone on
- shortly connect KEY/PTT jack sleeve with tip
==> CW carrier is emitted and does not stop

c) started quisk with HL2 and up-loaded 74p2 firmware

d) started piHPSDR with HL2 and 74p2 firmware: problem went away,
that is: CW carrier vanishes as soon as sleeve/tip connection
is removed

So the conclusion is: problem solved. Nevertheless, I shall keep
the "workaround" in piHPSDR for the time being, such that there
are no "surprised" for users with firmware < 74p2.

Yours,

Christoph

[Takashi.K]

Hi Steve,

 

PowerSDR v3.4.9 can automatically switch to CW mode when CW keying in SSB mode, but Thetis cannot,

so I have thought it was a problem with SDR software.

 

However, after applying this update, even when I used exttune.v in the main repository in my shack,

the problem of getting stuck in the transmit state after completing the ATU tune was resolved.

I don't really understand the logic behind this, but I'm very happy about this.

 

I would like to push ak4951 variant's .rbf file and the updated files to HL2 main repository according to HL2 rules,

but I also need to update the common file exttune.v.

Therefore, I would like to confirm whether it is okay to push the attached exttune.v as well.

 

< Background of updating exttune.v >

To realize "Select tune or bypass in 'Enable Filters' checkbox (PowerSDR)" described in ATU operation instructions (https://github.com/softerhardware/Hermes-Lite2/tree/master/hardware/enclosure/endcaps/kf7o/hl2_40b#atu),

it's necessary to change "bypass <= cmd_data[17] ; " to "bypass <= cmd_data[18]" on line 69 of exttune.v.

Because cmd_data[18] is apollo filter bit.

 

73,

Taka,  JI1UDD

 

[Steve Haynal]

Hi Taka,

I'm glad this change is helpful. If I remember correctly, we moved away from using bit 18 as it caused someone problems. There is some discussion here:

https://groups.google.com/g/hermes-lite/c/qnselynGLYE/m/tfkG4OSmAAAJ

Most software supports use of bit 17 now. I think even Thetis might. I don't want to change this HL2 ATU protocol given the history and adoption. I encourage you to stay compatible with the HL2 ATU protocol, but if you insist on using bit 18, then please use a Verilog AK4951 define or parameter so your change only applies to AK4951 builds.

You should still have commit privileges to the github repository. If not, please let me know via private e-mail.

73,

Steve

kf7o

[tak.k...@gmail.com]

Hi Steve,

I understood that use of bit 17 is correct and  the description in ATU operation instructions is old.

I think that use of bit 17 is suitable to avoid  user confusion.
I pushed two rbf files for ak4951 variant to the HL2 git repository. Please understand that there are now two variants of ak4951 to accommodate two types of ak4951 boards.

BTW, Thetis customized for HL2 does not seem to have a GUI to enable or disable ATU yet.

On the other hand, PowerSDR v3.5.0 customized for HL2 has ATU GUI using bit 18 (see attached jpeg). I hope this will be fixed to avoid user confusion if possible.

73,

Taka,  JI1UDD

2024年1月8日月曜日 4:12:50 UTC+9 softerh...@gmail.com:

[Steve Haynal]

Hi Taka,

Hopefully Reid will read this and see that Thetis doesn't have this AH-4 ATU support. He may not be motivated to support this as most IO interfacing support is moving to the new IO board by N2ADR, which I agree is the right thing to do moving forward. Maybe someone will add AH-4 support to the IO board.

73,

Steve

kf7o

[tak.k...@gmail.com]

Hi Steve,

OK. Could you fix the description of ATU Operation ? 

73,

Taka,  JI1UDD

2024年1月14日日曜日 8:50:49 UTC+9 softerh...@gmail.com:

[KP4RX - Ramon]

Team, there's code on Jim's repo to control the AH-4 with the I/O Board, Reid's branch of Thetis V 2.10.3.4 beta 3 Includes support for the specific registers. I don't own an AH-4 so I can't confirm it is fully working but at least I've used some of the library's functionality for my needs and it is working flawlessly. For Thetis to send the tune request register and use the functionality you need to click Ctrl + tune.

73 de KP4RX - Ramon

[Reid Campbell]

Sorry, I have not been following this until now but the latest Thetis does set the tuner bit in the protocol when TUN is used. It was removed in early releases as it caused the HL2 to drop carrier briefly while tuning.

Now that an ATU protocol has been established using Ctrl + TUN for the I/O Board. It might be possible to include the protocol bit in the ATU protocol in future releases.    

Cheers

Reid
Gi8TME/Mi0BOT

--

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/53ac6b1d-4b1f-4b64-93cc-fb9873dd3708n%40googlegroups.com.

[Steve Haynal]

Hi Reid,

Dropping carrier briefly is the intended behavior. Per the wiki, successful tuning results in tune, brief drop (required by protocol) and then the carrier is reestablished. Unsuccessful tuning will stop the carrier.

73,

Steve

kf7o

[Reid Campbell]

OK Steve , understand. I may change things in the future so that the bit in the protocol is only set on a Ctrl+TUN.

Cheers

Reid
Gi8TME/Mi0BOT

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/8b178625-4862-4bb3-99bc-afc0987f315dn%40googlegroups.com.