Re: Software Support for New CW Keyer

["Christoph v. Wüllen"]

>
> Just a minor comment on your keyer software. There is an ever so slight delay on side tone when one of the paddle is first pressed. I assuming that this is something to do with PTT process before the side tone output. For me it's just about perceptible.
>

That is the "PTT lead-in" time of the keyer. You can set this to zero or disable PTT in the keyer and it is gone. The default setting is
150 msec which is about what you need unless you run the SDR program in duplex. The idea is that you send "PTT" to the SDR program,
then wait a little so it can shut down the receivers and start TXing. Then start sending key-down events. In piHPSDR I need this because
the "PTT request" is queued in the "input events queue" of the GUI, while the key-down request is processed immediately to get
neat timing.


> The other thing I was expecting was that the side tone would be mixed with the Rx audio rather than a complete cut-off of the audio. I other applications, I could see this as a problem for QSK operation. This may be not a keyer issue but a audio shield configuration.
>

The side tone is mixed with RX audio in the sense that you hear RX audio *between* the dots and dashes. It is true that
*during* the dots and dashes the side tone *replaces* the RX audio. This can easily be changed. I never ran into this because
I usually operate the SDR program such that there is no audio during TX. Do you think one should (mathematically) add
side tone and RX audio? Would be easy enough to do.

Loosely related but not important for your concern:

There is one option that lets you mute the RX audio when CW-PTT is active. This is "off" by default, you need it
if your radio produces a side tone that is delayed and cannot be switched off.

EXAMPLE: I use this to key my 50-year old FT101 (without CW filter),
and then the RX output of the FT101 goes into a sound card, gets some
digital filtering in the computer, and then goes to the Teensy with a horrible delay (1* soundcard in and 1* soundcard out).
This is a typical situation for the "mute rx audio during cw ptt" option.


> Cheers
>
> Reid
> Mi0BOT/Gi8TME
>
> On 04/02/2022 08:19, "Christoph v. Wüllen" wrote:
>> So it seems from the side of the KeyerShield and its software, we can do
>> very little at the moment.
>>
>>> Am 03.02.2022 um 21:32 schrieb Reid Campbell <scumballc...@gmail.com>:
>>>
>>> Got a bit more of a play this evening. Used a Windows 11 machine (An HP something or other) and installed WSJT-X on it. The CM6206 Chipset and Teensy played nice, I was able to use both together while using WSJT-X.
>>>
>>> Got an old laptop running Windows 10 (Dell Precision M6500, I like my Dells) and updated to the latest WSJT-X. The CM6206 Chipset and the Teensy didn't play ball when I started WSJT-X. I was able to receive on the CM6206 Chipset but the Teensy wouldn't act as an output sound card for Windows. This is the same as my main machine.
>>>
>>> I did check the Teensy forums to see if anybody else has an issue with sound card incompatibility but didn't see any comments.
>>>
>>> So it looks like it's a Windows 10 issue or a Dell issue. I have an even older Dell that has Windows 10 on it, so I'll try it as well.
>>>
>>> Cheers
>>>
>>> Reid
>>> Mi0BOT/Gi8TME
>>>
>>>
>>> On 02/02/2022 21:47, Reid Campbell wrote:
>>>> Hi All,
>>>>
>>>> Got the SB USB interface and tested it with my CM6206 Chipset and they play nice together. I also tested the Teensy with the SB USB sound card and they play nice as well. It is only when the CM6206 is actively used by a program that the Teensy stops outputting. I have to unplug/plug the Teensy to get it to output again after a program has finished with CM6206 chipset card.
>>>>
>>>> Could the Teensy not be enumerating something correctly with the Windows sound system and using a default channel that the CM6206 thinks it has control over or is it the CM6206 that is at fault?
>>>>
>>>> Cheers
>>>>
>>>> Reid
>>>> Mi0BOT/Gi8TME
>>>>
>>>> On 02/02/2022 14:07, Reid Campbell wrote:
>>>>> Hi Simon,
>>>>>
>>>>> 2nd class signed for should be 2/3 days, so posted on Monday, should get it by Thursday. I have reference numbers but all they say is that it is in transit and will update when it's delivered.
>>>>>
>>>>> I'm picking up a Sound Blaster to night, so that will be another reference point.
>>>>>
>>>>> Cheers
>>>>>
>>>>> Reid
>>>>> Mi0BOT/Gi8TME
>>>>>
>>>>> On 02/02/2022 13:59, si...@sdr-radio.com wrote:
>>>>>> Reid,
>>>>>> Sadly not arrived today.
>>>>>> Simon Brown, G4ELI
>>>>>> https://www.sdr-radio.com
>>>>>> From: Reid Campbell <scumballc...@gmail.com>
>>>>>> Sent: 02 February 2022 09:09
>>>>>> To: Steve Haynal <st...@softerhardware.com>
>>>>>> Cc: Simon Brown <si...@sdr-radio.com>; Christoph v. Wüllen <DL1...@darc.de>; Graeme Jury <gvj...@gmail.com>; Roger Critchlow <rogercr...@gmail.com>; Matthew Balmer <bal...@gmail.com>; Alan Hopper <al...@samsararesearch.com>
>>>>>> Subject: Re: Software Support for New CW Keyer
>>>>>> Discovered that Fldigi does it as well, so not sure what's going on.
>>>>>>
>>>>>> Simon, if you have access to several USB sound cards, could you do a quick test with WSJT-X with two cards plugged in at the same time?
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Reid
>>>>>> Mi0BOT/Gi8TME
>>>>>>
>

[Reid Campbell]

Hi Christoph,

On 04/02/2022 13:20, "Christoph v. Wüllen" wrote:
>> Just a minor comment on your keyer software. There is an ever so slight delay on side tone when one of the paddle is first pressed. I assuming that this is something to do with PTT process before the side tone output. For me it's just about perceptible.
>>
> That is the "PTT lead-in" time of the keyer. You can set this to zero or disable PTT in the keyer and it is gone. The default setting is
> 150 msec which is about what you need unless you run the SDR program in duplex. The idea is that you send "PTT" to the SDR program,
> then wait a little so it can shut down the receivers and start TXing. Then start sending key-down events. In piHPSDR I need this because
> the "PTT request" is queued in the "input events queue" of the GUI, while the key-down request is processed immediately to get
> neat timing.

So setting the PTT lead-in time to zero will remove the delay but if a
system required 500msec lead-in, then there would be 1/2 second until
side tone was produced, if I have gotten it right. I'm not a CW operator
but that doesn't feel right. If possible, I think the keying to
side-tone should have zero delay and lead-in handled under the covers,
transparent to the operator.

>
>
>> The other thing I was expecting was that the side tone would be mixed with the Rx audio rather than a complete cut-off of the audio. I other applications, I could see this as a problem for QSK operation. This may be not a keyer issue but a audio shield configuration.
>>

An option to control mixing or blanking might be the way to go.

Cheers

Reid
Gi8TME/Mi0BOT

[Mike Lewis]

I believe you will find a flag to mute RX audio on TX.

In the current config.h file of TeensyWinkeyEmulator this define is now commented out.
In my old build I have embedded into my piHPSDR this is an active and working feature.

https://github.com/dl1ycf/TeensyWinkeyEmulator/blob/5124152f7473aaf11863bbe758bfa20739f005c2/config.h

//#define MY_MUTE_OPTION 0 // set to 1 then RX audio is muted during CW PTT

The comments above suggests this no longer applied to the new shield.

- Mike

>>>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.sdr-radio.com%2F&amp;data=04%7C01%7C%7Cf1ddb31a8d084a14735508d9e8347ffe%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637796134444557377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=M6IIT0bPRl16s4ThdV5wUT5fBRb6KtBwaO4kQ3fC4Aw%3D&amp;reserved=0

>>>>>>> From: Reid Campbell <scumballc...@gmail.com>
>>>>>>> Sent: 02 February 2022 09:09
>>>>>>> To: Steve Haynal <st...@softerhardware.com>
>>>>>>> Cc: Simon Brown <si...@sdr-radio.com>; Christoph v. Wüllen
>>>>>>> <DL1...@darc.de>; Graeme Jury <gvj...@gmail.com>; Roger
>>>>>>> Critchlow <rogercr...@gmail.com>; Matthew Balmer
>>>>>>> <bal...@gmail.com>; Alan Hopper <al...@samsararesearch.com>
>>>>>>> Subject: Re: Software Support for New CW Keyer
>>>>>>> Discovered that Fldigi does it as well, so not sure what's going on.
>>>>>>>
>>>>>>> Simon, if you have access to several USB sound cards, could you do a quick test with WSJT-X with two cards plugged in at the same time?
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>> Reid
>>>>>>> Mi0BOT/Gi8TME
>>>>>>>

--
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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fhermes-lite%2F8084ca49-b880-3f92-1e39-12d3c8d95e43%2540gmail.com&amp;data=04%7C01%7C%7Cf1ddb31a8d084a14735508d9e8347ffe%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637796134444557377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=MEaiiSufrlHoE4OjBzhpGZIChRx7CkkSu%2FMablcwgHU%3D&amp;reserved=0.

[DL1YCF]

As to the lead-in time: what you propose is that one „records“ all the incoming key-down and key-up events
with their time stamps in a ring buffer, then
activates PTT and then „replays“ all the key-down and key-up events with the lead-in delay.

OK, I simply do not want to implement this but everyone feeling this is necessary is invited to do so.

For hardware rigs required lead-in is usually only up to 50 msec,
it is only the WDSP engine taking so long to shut down the receivers which requires larger times for
some SDR consoles. I can live very well with 150 msec delay only for the first element of a transmission.

As to the mixing:

I think your suggestion boils down to have a „mixing parameter“ A in the range 0-127 (to be compatible
with MIDI) and then calculate


OutSignal = (A * RXsignal + (128-A) * SideTone) / 128;

is this what you are proposing? (easy enough to implement).

> --
> 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/8084ca49-b880-3f92-1e39-12d3c8d95e43%40gmail.com.

[DL1YCF]

Well you can activate or deactivate this feature by incoming MIDI commands.
The compile-time option only determines the initial state, that is, how the
KeyerShield behaves until it gets its first command by the MIDI controller.

Personally I do not use such a controller (I even do not know if such a
program has been finalized yet). This flag is only needed if your radio
produces a side tone which you cannot mute.

[Reid Campbell]

Hi Christoph,

On 05/02/2022 11:28, DL1YCF wrote:
> As to the lead-in time: what you propose is that one „records“ all the incoming key-down and key-up events
> with their time stamps in a ring buffer, then
> activates PTT and then „replays“ all the key-down and key-up events with the lead-in delay.

That would be one way of doing it or add a delay line on the MIDI
output. Yes, more programming and would only be beneficial for longer
delays. The RF delay feature in the HL2 probably covers most along with
the delay in the keyer.

>
> OK, I simply do not want to implement this but everyone feeling this is necessary is invited to do so.
>
> For hardware rigs required lead-in is usually only up to 50 msec,
> it is only the WDSP engine taking so long to shut down the receivers which requires larger times for
> some SDR consoles. I can live very well with 150 msec delay only for the first element of a transmission.
>
> As to the mixing:
>
> I think your suggestion boils down to have a „mixing parameter“ A in the range 0-127 (to be compatible
> with MIDI) and then calculate
>
>
> OutSignal = (A * RXsignal + (128-A) * SideTone) / 128;
>
> is this what you are proposing? (easy enough to implement).

Yes, I think that would work well and cover all conditions.

Cheers

Reid
Mi0BOT/Gi8TME

>
>
>

[Steve Haynal]

Hi All,

In my opinion it defeats the purpose of a low latency keyer if the keyer will add latency to the tone to satisfy the radio hardware or software. There are two latency paths: key-to-ear and key-to-antenna. The idea of this keyer is to decouple the two paths. The key-to-ear latency should be as low as possible and independent of any hardware or software. The key-to-antenna latency must be there and will be longer but should be handled independently. The HL2 gateware should have all the delays in place for proper switching from RX to TX.

73,

Steve

kf7o

[Matthew]

Hi Steve,

I have only this week started thinking properly about (and using) this project but I agree with you and I see this keyer providing a solution for me to reduce key-to-ear latency.

73 Matthew M5EVT.

[Alan Hopper]

Hi All,

I am at a similar point to Simon in thinking how to best integrate it.  I had not thought about the keyer producing ptt as well as key signals as spark already handles this for keyboard cw or much simpler midi keying, so I need to think this through.  I wonder if creating a list of use cases might be useful to see which options need to coexist.

some that come to mind:-

Mixture of keyboard cw from Spark(or other sdr) and keyer cw -  Where should the side tone be generated for  keyboard cw, spark already has a efficient low latency route for the rf side of this and going via the keyer will add a delay.

Mixture of keyer cw and external program via serial - at first thought this should be straight forward but I have no experience so may be missing something.

Deeper integration between sdr program and keyer e.g.using spark cw macros, should the keyer trigger them in spark or should spark upload them to the keyer.

I wonder if there is a use for a sidetone on/off message from sdr sw to keyer that triggers sidetone without sending key or ptt signals.

73 Alan M0NNB

[Steve Haynal]

Hi All,

It is great to great to see interest and discussion on various possible support for this keyer. I'd be very happy with basic first order support of the keyer. More sophisticated uses may come later. Also, sorry that the keyer firmware is still in flux and not 100% ready for software. For basic support, I have in mind:

1) SDR Software recognizes and passes to the HL2 the keydown/up messages for both paddle and straight key.

2) External and internal MEMs microphones are working with keyer-based PTT for SSB with SDR software and HL2.
3) Keyer provides 4 basic controls via the 4 POTs, low latency sidetone mixed with any audio from software, USB sound to headphone and speakers.

73,

Steve

kf7o

["Christoph v. Wüllen"]

I think it is important to add:

And, if you know how to program, you can dedicate one of the pots
to the "Mic input level", sacrificing one of the other adjustments.
There is no "hardware connection" between the pot and its function.

> --
> 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/cfd9d3ce-3601-46b1-9bc7-5446e6176549n%40googlegroups.com.

[Alan Hopper]

Hi cw operators,

Spark already has a wpm speed control for keyboard cw would you want this to be linked directly to the keyer speed control or are there cases when you would want separate control of each?

73 Alan M0NNB

[Alan Hopper]

Hi keyer producers,

in the case of the spark keyboard cw wpm being tied to the keyer wpm this ideally wants to be two way, ie. you can adjust it on screen or from a knob on the keyer.  This has some issues with the use of pots on the keyer as they cannot move to represent the value set  onscreen, if they were encoders this would not be an issue.  The value set could simply be the last change detected i.e an onscreen change would be reverted to the absolute value of the pot it the pot were changed, this could have issues if the pot is just on the edge of a lsb change, maybe a few bits worth of change could signal 'go back to pot mode'.  I've not studied any of the keyer source, has this been allowed for?  

This obviously applies to other controls as well as wpm.  Control from the sdr sw is desirable for builds that have no pots and it makes sense to me to keep it when there are post.

73 Alan M0NNB

["Christoph v. Wüllen"]

> Am 07.02.2022 um 13:25 schrieb 'Alan Hopper' via Hermes-Lite <herme...@googlegroups.com>:
>
> Hi keyer producers,
> in the case of the spark keyboard cw wpm being tied to the keyer wpm this ideally wants to be two way, ie. you can adjust it on screen or from a knob on the keyer. This has some issues with the use of pots on the keyer as they cannot move to represent the value set onscreen, if they were encoders this would not be an issue. The value set could simply be the last change detected i.e an onscreen change would be reverted to the absolute value of the pot it the pot were changed,

exactly, "last one wins". This is not new: if you have a "MIDI DJ controller" with knobs, and assign one knob to the AF volume, then the following happens:

- turn the knob ==> AF volume changes AND slider in the GUI of the SDR console moves
- move the slider in the GUI ==> AF volume changes but MIDI knob stays, AF volume is not in sync with the knob
- turn the knob again ==> AF volume changes AND slider moves

If this is not a problem for (normal) MIDI consoles, it is also not a problem for MIDI keyers.
I should say "last one wins" and "ignore the problem".

Yours,

Christoph DL1YCF

[si...@sdr-radio.com]

Agreed.

Simon Brown, G4ELI
https://www.sdr-radio.com

[Steve Dick]

I can't comment software-wise but as a CW operator using the popular
logging software N1MM+ that can talk to a winkeyer, one can set up N1MM+
so that the keyer speed can be set in N1MM+ with the keyer speed knob
synced to the N1MM+ software or made independent of the N1MM-defined
keyer speed. Some ops like to sync them, others want to keep the speed
knob independent which can override the N1MM+ set speed. This is also
true of the popular logging program N3FJP. With regard to other comments
about pots and buttons, I agree with Christoph, DL1YCF that pots that
are set once should be done via small trimmers, and just have a single
pot, the speed pot. As far as buttons for memories, most CW operators
I've seen in major contests such as Field Day, including myself, never
use the buttons for stored memory messages. They use keyboard macros
for message storage, run on the host computer's logging software via
function keys. These macros are a lot more flexible than hard-coded
messages. I suppose this capability could be incorporated in the Teensy
softwre but that would be redundant with capabilities already in the
logging software. I have rarely found a single button useful when
running the frequency to call CQ only as a backup to a computer failure
when operating for many hours and you start getting tired. Otherwise I
never use them. They should be made an option for people who feel
strongly about them, and not provided as a default. To me, they just add
cost and more points of failure and are rarely mechanically a pleasure
to use. The real WKUSB winkeyer has nice buttons with square button caps
in a nice enclosure but many keyers have no buttons or even a speed
pot, such as the K1EL WKmini, which does not have speed pot or message
buttons, and depends on the host's logging program for these functions.

-Steve K1RF

------ Original Message ------
From: "Christoph v. Wüllen" <DL1...@darc.de>
To: "Alan Hopper" <ahop...@googlemail.com>
Cc: herme...@googlegroups.com
Sent: 2/7/2022 8:18:43 AM
Subject: Re: Software Support for New CW Keyer

>
>

>--
>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/EDAB50A2-0B04-4DDB-AAA3-D0FDBC68AD39%40darc.de.


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

["Christoph v. Wüllen"]

I fully agree. Note that a K1EL winkey compatible device has
two modes, the "standalone" and the "host mode". If
a speed is set in "host mode" it overrides the Pot setting.
If it *seems* that the speed in "host mode" follows the pot
this is simply that the host program (N1MM logger or whatever)
reads the speed pot and then sets the host speed accordingly.

It is also true that during contesting, everything is done
via the logging program, but this may be different for small
portable operations.

Note that my simple-minded stripped-down Winkey emulator
does what one needs most, for the full features

- programmable via the paddle
- messages to be sent via push-buttons

one must use the full-fledged K3NG "WinKey clone", and I do
not plan to duplicate that program. When all is settled down,
the K3NG keyer will be supported by the CWKeyerShield, since
this is a prerequisite for making use of buttons.

[Alan Hopper]

Hi All,

I have two way 'last wins' working nicely for things like sidetone frequency. I notice midi message for things like this are sent straight back from the keyer, this involves a little work to prevent endless loops of messages happening, this is not a problem but does increase cpu usage.  Could the keyer only send these messages if the change is caused by something other than midi or is there a good reason for the echoes that I've not thought of?

73 Alan M0NNB

[Roger Critchlow]

Hi Alan --

hasak echoes everything that gets set when it gets set.  This includes setting the built-in defaults or saved settings from eeprom at startup, or when hasak is told to reset to defaults or to eeprom settings, or when an enabled pot changes a setting, or when a controller sets a value, or when hasak is told to perform a roll call.  This is done so the controller can know what the settings are and display the current settings to the user.  It also confirms to the controller that its commands are being performed and only its commands are being performed.   There are also some commands which are purely informational, the value they echo back is the only way you find out what the value is.  Finally, and unintentionally, the echoing also provides feedback to the controller about how fast it is demanding changes to the keyer parameters.

Changing sidetone frequency or level only takes effect between buffers, and buffers are 32 samples long, and at 48000 samples/second, that's 2/3 of a millisecond per buffer.  If you change frequency or level faster than that, all you're doing is overwriting the previous change before it took effect, and generating echo messages to yourself.  Similarly, you can't change the keyer speed faster than the current dot clock time, 60ms at 20WPM, all the extra messages just overwrite the previous setting before the keyer had a chance to use it, and generate an echo.  And you'd need to back off from those rates to give the operator enough samples or dits to hear the change.

Thanks for bringing this up, I was thinking in terms of throttling the rate of control changes by some general one size fits all scheme, but now I see that the different controls have natural minimum update rates.  I'll have to roll that back into the pot sampling rates, too.

And I haven't been following the last set wins discussion closely enough.  Is there general agreement about how it's going to work?

 -- 73 -- rec -- ad5dz --

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/bb83f578-1fa1-4e7a-9674-9afe89748e13n%40googlegroups.com.

[Roger Critchlow]

Then, again, I might be all wrong.  I just visited the hasak sidetone oscillator and it's pulling frequency and level on each sample.

-- 73 -- rec -- ad5dz --

[Alan Hopper]

Hi Rodger,

thanks for the info, I had not given update rate limiting any thought.  I guess the highest will be when dragging sliders with the mouse, I'll check how fast this is.  So far I've only tested with  TeenseyWinkeyEmulator , two way last setter wins seems to work fine as long as the pc side avoids re echoing the echoes, if you don't do this it is possible to make it go a bit crazy. I still wonder about noise on the pot adcs wrestling control back from the pc if left just on the edge of a lsb change but I've not been able to make this happen in practice.

73 Alan M0NNB

["Christoph v. Wüllen"]

So you describe the following:

- MIDI controller sends speed change to the keyer
- Keyer reports back speed change to the controller

Is it this you wnt to suppress?

Agreed, this should not happen, we can prevent this. On the other hand,
if you turn a pot, there will be messages sent back in most cases.

There is a flag "midi_response" that can be set/cleared via MIDI
commands, and that suppresses most messages except those that are
meaningful in the SDR console, that is, all except Key-down,
PTT, speed and pitch change.

> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/bb83f578-1fa1-4e7a-9674-9afe89748e13n%40googlegroups.com.

[Alan Hopper]

Hi Christoph,

yep it is those messages, It would be simpler if they were suppressed and it saves some cpu at both ends but it is not a big problem if there are other reasons to keep it.  So my logic would be :- if a message comes over midi don't send it back over midi, if a change comes from any other source (pot, serial etc) do send it over midi.

I'm now pondering a nice ui to set all keyer options, is there a way to query the current state of each setting?

73 Alan M0NNB

[Reid Campbell]

Hi All,

I'm going to put my head above the parapets here and say, are we making
the keyer to complicated?

I'm concerned that we are moving away from simple MIDI notes messages to
a situation that turning a knob on the keyer produces four MIDI
messages. My experience is only limited to PowerSDR and Thetis. They
have been designed and coded to map MIDI noted to various functionality.
This is designed so a DJ controllers's knob can be mapped on to VFO, a
slider to volume, etc.

One of the aims of this project was to produce a low latency CW sidetone
for use with SDRs and be available to a wide audience. I think we are
reducing that audience by complicating the MIDI interface. The non HL2
Thetis will not do MIDI keying, it's something that I added.  If there
is a demand for it, it would be relative easy for the main Thetis
developers to add that functionality but they will want the simple
interface that currently exists to use DJ controllers. If it's made
difficult for them, they will move on.

I'm not saying that there can't be a more enhanced MIDI interface but we
need to do the basic as well. Here what I think we should be shooting
for in a Alpha version of the keyer:

Accurate dots and dash streamed using a MIDI note of velocity 127 to
work with existing PowerSDR software.
Reporting of speed by a single note using velocity.
Basic WinKeyer functionality using the serial interface as that is what
all programs that that will want to interface with the keyer will use.

The final unit should also work out of the box, as a keyer, without any
configuration. I can see this group swamped with messages for support
unless things are kept simple.

I'm sure that there is more that should be in there but it's a start.
Maybe I'm not seeing the whole picture here and something's are
confusing me like the mention of a MIDI controller. I'm not sure of it's
purpose.

So there you are, fire extinguisher at the ready.

Cheers

Reid
Mi0BOT/Gi8TME

["Christoph v. Wüllen"]

Exactly my opinion. Look at the K3NG keyer which is heavily suffering from "over-feature-ness".


I use the keyer every day (and for quite some time, since I built a prototype from the very beginning)
and I am very happy with it.

I just cannot understand the desire for MIDI control. Any serious CW op is well accustomed to
the (serial line) WinKey protocol and used to control the keyer that way. For my side, I have never
sent a single MIDI command *TO* the keyer.

As to the MIDI commands *FROM* the keyer: Key-down and PTT are mandatory,
side tone frequency is nice to have and speed is an optional feature.

You do not need more.

> --
> 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/00de1bde-727c-a26f-4db4-70b018158e3b%40gmail.com.
>

[Alan Hopper]

Hi,

 I fully agree that stage 1 has to be to keep it simple and get the basics working with common sdr software.  The basics do appear work with published versions of spark as is so excuse me for getting ahead of myself.  I do need to spend a little time with the scope attached and just check the key/ptt interactions are working as expected.

I also understand that many established operators will use serial keyer software and the sdr program has little to do.  This is great.

There are other operators that would probably prefer a simpler setup eg plug in the keyer and fire up the sdr software.  For this to work nicely some things do need to be adjustable by the sdr program and midi is the obvious way to do it.  

There are a number of members at my club that I keep trying to tempt into the sdr world. If I were to show the cw operators (who simply have a key plugged into an analog radio ) a setup with keyer sw, sdr sw virtual serial cables etc I think my chances of a conversion would be low :) Answering the question 'how do I switch from mode a to mode b'' with 'download this other bit of software, find the com port and do xxx' is also not ideal.

Reid, I guess your comment about 4 midi messages is to do with nrpn messages, if so I fully agree they should not be used for the main real time events, I think they do make sense for other settings though.

73 Alan M0NNB

[si...@sdr-radio.com]

Alan,

 

There may be more than one client.

 

1. CW Keyer standalone GUI
2. SDR Console driving HL2 / Pluto / Lime…

 

The GUI could send a string vis CW Keyer, the console must get the MIDI commands so it can generate the CW for Pluto & Lime.

 

Simon Brown, G4ELI

https://www.sdr-radio.com

 

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/24746033-7f25-4237-8f45-5f63938d724dn%40googlegroups.com.

[Alan Hopper]

Hi Simon,

yep, my understanding is this would currently be handled by a serial connection from the other sw to the keyer and the keyer passing the cw to the sdr sw via midi.  I  believe this side of things is fairly sorted or are you suggesting there could be multiple midi clients?

73 Alan M0NNB

[Reid Campbell]

Hi Alan,

On 09/02/2022 10:43, 'Alan Hopper' via Hermes-Lite wrote:

Hi,

 I fully agree that stage 1 has to be to keep it simple and get the basics working with common sdr software.  The basics do appear work with published versions of spark as is so excuse me for getting ahead of myself.  I do need to spend a little time with the scope attached and just check the key/ptt interactions are working as expected.

I have the basic keying working using TeenseyWinkeyEmulator. Worked right out of the box once I mapped the MIDI to the right command. I'm having a issues interfacing to the hasak as it didn't output dots and dashes but paddle events.  The more I got into it, the more complicated it was getting.

Maybe I don't understand the use cases. Do we need to go through them so that everyone is up to speed and record them in a wiki?

I also understand that many established operators will use serial keyer software and the sdr program has little to do.  This is great.

There are other operators that would probably prefer a simpler setup eg plug in the keyer and fire up the sdr software.  For this to work nicely some things do need to be adjustable by the sdr program and midi is the obvious way to do it.  

There are a number of members at my club that I keep trying to tempt into the sdr world. If I were to show the cw operators (who simply have a key plugged into an analog radio ) a setup with keyer sw, sdr sw virtual serial cables etc I think my chances of a conversion would be low :) Answering the question 'how do I switch from mode a to mode b'' with 'download this other bit of software, find the com port and do xxx' is also not ideal.

Yes, would agree, not everybody has our competence. Plug and play is now expected for all our gadgets and we should try to provide the same for the keyer. It should identify itself, the software it's running, and the version to cater for different revisions. The SDR should provide basic configuration ability. The only one that comes to immediate mind is mode A/B. Speed setting coming from the keyer would be nice so that the actual WPM can be displayed. Speed setting the other way is not necessary but could be an option. 

Reid, I guess your comment about 4 midi messages is to do with nrpn messages, if so I fully agree they should not be used for the main real time events, I think they do make sense for other settings though.

I guess they might have a place but I think the SDR software should only provide the basics. Maybe this is were the MIDI controllers comes in to setup things like dot/dash ratios, etc? I wouldn't expect the controller to be used for QSO exchanges, that what all the logging programs are for. That not to say it couldn't have macros or beacon modes or what ever else but that's all for later.

Anyway, it's good to talk and get a understand of were the keyer fits in.

Cheers

Reid
Mi0BOT/Gi8TME  

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/f431dd7e-ab85-4dcc-9516-bdae906c321bn%40googlegroups.com.

["Christoph v. Wüllen"]

Just one question:

does Spark actually *send* MIDI messages?

The point is, that other SDR software. piHPSDR and linHPSDR usually only have MIDI input
(no output). I think this is the source of misunderstanding.

Of course, in piHPSDR and other software you can *set* things like CW speed and side tone
frequency in the menus, since this data is e.g. sent to the (HPSDR) radio and becomes
effective there if (and only if) CW is done "in the radio", that means in the
FPGA of the radio. The side tone frequency is also used internally by the SDR console
since it determines the "BFO offset", that is, how far the RX frequency is moved away
from the dial (and TX) frequency.

So now I understand what you think of: adjust CW speed, side tone frequency and side tone
volume in the SDR console and send these values to the keyer. Well, the interface is there
it should already work *now* if the SDR program can send MIDI messages. For the keyer it
makes no difference where the MIDI messages actually come from (a MIDI controller or
the SDR console).

> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/f431dd7e-ab85-4dcc-9516-bdae906c321bn%40googlegroups.com.

["Christoph v. Wüllen"]

>
> Yes, would agree, not everybody has our competence. Plug and play is now expected for all our gadgets and we should try to provide the same for the keyer. It should identify itself, the software it's running, and the version to cater for different revisions. The SDR should provide basic configuration ability. The only one that comes to immediate mind is mode A/B. Speed setting coming from the keyer would be nice so that the actual WPM can be displayed. Speed setting the other way is not necessary but could be an option.

The default setups of the TeensyWinkeyEmulator have been carefully chosen as to allow plug+play.

Of course, you must "teach" the SDR console which MIDI command signifies key-up/down and
possibly which one signifies PTT on/off, but this should be easy, especially if the
SDR console has a "learning" menu with a "configure" mode, reports the last MIDI command
received and lets you choose from a list the appropriate action (look at pihpsdr).

[Alan Hopper]

Hi Christoph,

The version I'm working on now does send midi and it does work.  For context spark already had a keyboard keyer and macros etc built into the CW mode with frequency, speed and sidetone controls so connecting them to the keyer is a natural desire.

73 Alan m0nnb

[Duncan Clark]

In message <00de1bde-727c-a26f...@gmail.com>, Reid
Campbell writes

>One of the aims of this project was to produce a low latency CW
>sidetone for use with SDRs and be available to a wide audience.

Which is all as an ordinary user that I want.

I don't do CW contests but I do chase DX and if that means CW then so be
it.

Having a low latency audio for CW board with the ability to plug in the
PTT, headphones and mic would be ideal.

Anything else quite honestly is overkill for me.

IMHO KISS approach works to get it all going then you can complicate it
to your hearts desire by adding in contest operability, macros and alike
etc.

It's 'only' firmware but no hardware gets into us end users hands until
you programmers agree something.

I'd hate for such a fine low latency hardware solution to get bogged
down in making the firmware all singing all dancing such that we don't
ever get around to using it.

Just my POV.

Duncan

PS Simon do you still have that 6 x PL509 from your Bangor days?


--
Duncan Clark
G4ELJ

[Roger Critchlow]

I've just pushed an updated version of hasak into the CWKeyer repo with a precompiled hex.

Hasak now starts with TX_ENABLE true, so it's sending MIDI notes for keyout (0) and pttout (1) with velocity = 127 for on, = 0 for off, and keying the key/ptt out jack.

Hasak now accepts an input note tune (2) which should key the same way as the straight key channel does, but is purely theoretical until I make more time for testing.

The MIDI controller is live at https://cwkeyer.elf.org, it's very rough and ugly and quite likely at the moment

[Roger Critchlow]

Clicked on send too soon, again.

So, I'm going to focus on getting a few remaining bits of hasak settled, and on making the cwkeyer web page less painful to look at and use.

-- 73 -- rec -- ad5dz --

[Reid Campbell]

Hi Roger,

Just uploaded your latest release but I'm not seeing any MIDI output when I key? I'm seeing MIDI when the knobs are turned but nothing when I touch the paddles?

The other thing I noticed was that I have to turn the master volume to the 3 clock position for a reasonable level of audio. It might be my head phones but TeenseyWinkeyEmulator is the same low level.

Cheers

Reid
Mi0BOT/Gi8TME

--
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/CAGayqouOYF8gAu%2BJs0iZxB4ADAxgO3Q2AprccG%2ByRCPqdyD8hw%40mail.gmail.com.

[Roger Critchlow]

Thanks, Reid --

That was my error, set the mask correctly, tested the mask correctly, but forgot to ensure that the mask was copied to its correct location.

It should be fixed by the current contents of https://github.com/softerhardware/CWKeyer/tree/main/firmware/hasak.

-- 73 -- rec -- ad5dz --

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/610a830f-2c52-d5a7-fec2-b9ed4ab051b1%40gmail.com.

[Reid Campbell]

Hi Roger,

Great, now getting output when I touch the paddles, just trying to decipher it (sending dashes).

 TIMESTAMP IN PORT STATUS DATA1 DATA2 CHAN NOTE EVENT               
     97667  1  --    144     0     0    1  C -1 Note Off              
     97667  1  --    144     1     0    1  C#-1 Note Off              
     97847  1  --    144     0   127    1  C -1 Note On               
     97907  1  --    144     0     0    1  C -1 Note Off              
     98088  1  --    144     0   127    1  C -1 Note On               
     98148  1  --    144     0     0    1  C -1 Note Off              
     98327  1  --    144     0   127    1  C -1 Note On               
     98388  1  --    144     0     0    1  C -1 Note Off              
     98567  1  --    144     0   127    1  C -1 Note On               
     98627  1  --    144     0     0    1  C -1 Note Off              
     98807  1  --    144     0   127    1  C -1 Note On               
     98868  1  --    144     0     0    1  C -1 Note Off              
     99048  1  --    144     0   127    1  C -1 Note On               
     99528  1  --    144     1   127    1  C#-1 Note On     

So note C is the keying, c# is the PTT?
I'm puzzled with the two notes at the last both being on?

Could you have your default build not have PTT. Assume semi break-in by the HL2 for the moment.

Getting there.

Cheers

Reid
Mi0BOT/Gi8TME        

[Mike Lewis]

You should be able to configure your SDR end to not know about the keyer sent PTT commands, effectively ignoring them.

 

Mike

K7MDL  EL87sm & CN88sf

 

From: herme...@googlegroups.com <herme...@googlegroups.com> On Behalf Of Reid Campbell
Sent: Thursday, February 10, 2022 17:27
To: Roger Critchlow <r...@elf.org>
Cc: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: Software Support for New CW Keyer

 

Hi Roger,

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/82d36728-65b5-1ca4-f17a-a81f78ed8ae2%40gmail.com.

[Reid Campbell]

Hi Mike,

The problem I'm having at the minute is to do with mapping the MIDI notes. It expects one at a time, so if it receives another in the middle of the mapping, it complains. I'm also trying to think of a justification for send PTT at all. The HL2 has the capability to delay RF, allowing relay to change and not have hot switching.

Cheers

Reid
Mi0BOT/Gi8TME 

[Mike Lewis]

Here is one for you.

 

I built a very minimal one of these and embedded it into a piHPSDR controller case replacing a standard USB sound dongle.  I use a standard ham radio mic with PTT button into it (added the mic audio flow and debounce) and of course a CW keyer (straight and paddles).  

 

A fullup piHPSDR controller (or a PC) lack extra IO pins so the keyer module does the PTT with proper debounce and also handles mic and speaker audio.  I use the MIDI messages for PTT and keyer events.  Works today with SparkSDr, PiHPSDR and Thetis.  I plan to extend this version after it hits production to include several encoders and buttons, one a VFO knob.

 

PTT timing is configurable with lead in and tail times.

 

Mike

K7MDL  EL87sm & CN88sf

 

[Roger Critchlow]

Hi again Reid --

That would be me ignoring the comments about active low and reversing the on/off logic.  It's fixed and pushed.

I also dropped pttout from the default for noteEnable.  So this build only outputs keyout notes.

-- 73 -- rec -- ad5dz --

[Reid Campbell]

OK, if you are talking about PTT for voice, that's OK, you need that, unless you use VOX. Do we need a PTT signal for CW. Is the first dit or dah enough to trip the transmitter and let the HL2 do the timings for you. What about QSK for the Anan radios?

Cheers

Reid
Mi0BOT/Gi8TME

[Reid Campbell]

That is working now. Was able to listen on a separate receiver and sounded fine. Would ready have to look with a scope to check the timing.

Further to Mikes message relating to PTT, for Thetis there needs to be different PTTs for Voice and CW.

Cheers

Reid
Gi8TME/Mi0BOT 

[Roger Critchlow]

I assume that most modern radios don't usually need a PTT for code or voice.  Maybe for voice operation in noisy environments, but in general I expect they can detect the presence of signal and switch to transmit under their own control.  But, a friend was sending QRQ CW audio to a very nice, expensive, modern radio, and we had to wire a digital PTT that keyed an ultrasonic tone into the CW audio to kick the VOX into changing over.

Ideally you could modify the noteEnable mask with  https://cwkeyer.elf.org, but that's not implemented in the interface yet.

-- 73 -- rec -- ad5dz --

["Christoph v. Wüllen"]

Dear Reid, a(nd cc to the list because the pictures may be worth looking it):

a) You cannot set the HL2 TX latency to 70 msec. The "TX latency" defines how much

of the TX FIFO inside the FPGA has to be filled before TXing starts. The size

of the HL2 FIFO is about 80-90 msec (there is no more "space" in the FPGA),

so TXing really should start at half-filling. So if you need a PTT-to-RF

delay larger than 40msec (the now-standard TX latency time) you must use

the PTT input with a lead-in time.

b) As to the "MIDI to RF" delay:

I have plenty of measurements for the MIDI case, but this tells you

more about

the SDR software rather than about the HL2.

In my setup the PTT-to-RF pulse time is not critical, it is usually

larger than 50 msec. This is so because the "MOX" bit from the Metis data

packet is extracted and processed first, and then the TX IQ samples go into the

TX FIFO which ideally is at half-filling so it needs some time for the pulse

"travelling through" the FIFO and arriving at the antenna.

Note pihpsdr does not use the so-called "CWX" interface (least significant bit

of Q samples) but insteads directly

produces the IQ samples that describe the RF pulse. This is simple since I(t)=0

wand Q(t) is the envelope of the pulse, if you transmit on the dial frequency.

The first picture shows what happens when piHPSDR receives the

"Key down" and "PTT" MIDI message simultaneously (no lead-in time). Note in all

cases a letter "s" was keyed at 20 wpm (so three dots 60 msec wide, separated by

pauses also 60 msec wide).

There is a 50msec PTT-to-RF delay, but the first RF pulse is shortened. The reason for this

is that this was in non-duplex mode so the WDSP receiver needed shut-down first and (only)

then TXing starts. Consequently this is worse in "dual RX" mode:

However when activating DUPLEX (that means, the WDSP receivers continue to get samples

and need not be shut down), there is not problem even with 2 RX.

Normally I don't use DUPLEX mode. The crosstalk from the T/R relais leads to

strong RX signals while TXing and thus to

"AGC pumping", that is, after a TX/RX transition your receiver is deaf for a short

amount of time. I could, of course, do DUPLEX and zero the RX IQ samples while TXing

but I guess shutting down the RX during TX frees the CPUs for doing TX-specific work.

Of course, this is what the PTT lead-in time is all about!

Even in non-duplex mode with

2 RX active, a lead-in time of 40msec is enough (so the MIDI PTT-on message arrives

40 msec before the first CW Key-down messaga)

so this is why I shortened the default lead-in time from 150 to 50 msec. Of course, if

you have a VERY slow PA you can increase the lead-in time to any value you like,

here e.g. measured with 100 msec (note the "SDR" delays add onto this value):

but this is normally not needed.

Yours,

Christoph DL1YCF.

[Matthew]

Hi Christoph,

I noticed on another thread that you have also made reference to TX buffer size. Your observations about linHPSDR don't seem to hold true against the measurements that Steve undertook:

https://groups.google.com/g/hermes-lite/c/91uSCsAmQp4/m/Q2vgfnLpAwAJ

My understanding is that (with a wired connection) the value placed in ADDR 0x17 DATA [6:0] (TX buffer latency in ms, default is 20ms), the value is largely dependent on the regularity of packets from the SDR software to the HL2. Steve's measurements show with quisk, SparkSDR and my linHPSDR fork, the TX buffer fill level could be a lot less than half with no impact (ignoring any external PA needs).

73 Matthew M5EVT.

[Alan Hopper]

Hi Rodger,

I've had an initial play with hasak and the basics all seem to work.  In reading the nrpn messages it appears some values are signed eg master volume and some are unsigned eg sidetone frequency is this intentional?

73 Alan M0NNB

On Tuesday, February 8, 2022 at 9:50:59 PM UTC r...@elf.org wrote:

Hi Alan --

hasak echoes everything that gets set when it gets set.  This includes setting the built-in defaults or saved settings from eeprom at startup, or when hasak is told to reset to defaults or to eeprom settings, or when an enabled pot changes a setting, or when a controller sets a value, or when hasak is told to perform a roll call.  This is done so the controller can know what the settings are and display the current settings to the user.  It also confirms to the controller that its commands are being performed and only its commands are being performed.   There are also some commands which are purely informational, the value they echo back is the only way you find out what the value is.  Finally, and unintentionally, the echoing also provides feedback to the controller about how fast it is demanding changes to the keyer parameters.

Changing sidetone frequency or level only takes effect between buffers, and buffers are 32 samples long, and at 48000 samples/second, that's 2/3 of a millisecond per buffer.  If you change frequency or level faster than that, all you're doing is overwriting the previous change before it took effect, and generating echo messages to yourself.  Similarly, you can't change the keyer speed faster than the current dot clock time, 60ms at 20WPM, all the extra messages just overwrite the previous setting before the keyer had a chance to use it, and generate an echo.  And you'd need to back off from those rates to give the operator enough samples or dits to hear the change.

Thanks for bringing this up, I was thinking in terms of throttling the rate of control changes by some general one size fits all scheme, but now I see that the different controls have natural minimum update rates.  I'll have to roll that back into the pot sampling rates, too.

And I haven't been following the last set wins discussion closely enough.  Is there general agreement about how it's going to work?

 -- 73 -- rec -- ad5dz --

On Tue, Feb 8, 2022 at 12:25 PM 'Alan Hopper' via Hermes-Lite <herme...@googlegroups.com> wrote:

Hi All,

I have two way 'last wins' working nicely for things like sidetone frequency. I notice midi message for things like this are sent straight back from the keyer, this involves a little work to prevent endless loops of messages happening, this is not a problem but does increase cpu usage.  Could the keyer only send these messages if the change is caused by something other than midi or is there a good reason for the echoes that I've not thought of?

73 Alan M0NNB

> Subject: Re: Software Support for New CW Keyer
>
>>
>>

>>> Am 07.02.2022 um 13:25 schrieb 'Alan Hopper' via Hermes-Lite <herme...@googlegroups.com>:
>>>
>>> Hi keyer producers,
>>> in the case of the spark keyboard cw wpm being tied to the keyer wpm this ideally wants to be two way, ie. you can adjust it on screen or from a knob on the keyer. This has some issues with the use of pots on the keyer as they cannot move to represent the value set onscreen, if they were encoders this would not be an issue. The value set could simply be the last change detected i.e an onscreen change would be reverted to the absolute value of the pot it the pot were changed,
>>
>> exactly, "last one wins". This is not new: if you have a "MIDI DJ controller" with knobs, and assign one knob to the AF volume, then the following happens:
>>
>> - turn the knob ==> AF volume changes AND slider in the GUI of the SDR console moves
>> - move the slider in the GUI ==> AF volume changes but MIDI knob stays, AF volume is not in sync with the knob
>> - turn the knob again ==> AF volume changes AND slider moves
>>
>> If this is not a problem for (normal) MIDI consoles, it is also not a problem for MIDI keyers.
>> I should say "last one wins" and "ignore the problem".
>>
>> Yours,
>>
>> Christoph DL1YCF
>>
>>
>>
>>

>> --
>> 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/EDAB50A2-0B04-4DDB-AAA3-D0FDBC68AD39%40darc.de.
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>

--
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/bb83f578-1fa1-4e7a-9674-9afe89748e13n%40googlegroups.com.

[Alan Hopper]

Hi Roger,

sorry for spelling your name wrong.

73 Alan M0NNB

[James Ahlstrom]

Hello Group,

I am back from skiing and Steve sent me a SofterHardware CWKeyer, so I have some initial observations.

Since the point of this project is to create an immediate sidetone, I was surprised to find that when testing with a straight key the sidetone was not immediate. I am testing with the USB connected to Quisk, headphones and the straight key jack. The hex files are from yesterday. When I press the key, the hardware sends 0x9402,127, then 0x9401,127 with sidetone. That is, there is a pause until the sidetone is heard. Thereafter, sidetone is simultaneous with key presses until there is a sufficient pause to produce a 0x9402,0 message to end transmission. It seems the hardware sends 0x9402 as a kind of PTT to change to Tx, and then sends key press messages with sidetone.

This can't be right. The first key press must be simultaneous with sidetone. If the HL2/SDR combo must do something to change to Tx, that is its problem, not the problem of the CWKeyer. Graeme made this point back on February 6, and you can read his discussion here https://groups.google.com/g/hermes-lite/c/P-i_EYCN--k/m/0AEgFTf3AgAJ.

Jim

N2ADR

[Roger Critchlow]

Hey Alan --

Right, all the level controls are (I hope) tenth of a dB with the useful values in the middle of the encoded range.  Should probably do 100ths instead, though the encoded range would still need to be restricted in the UI.  There are a few other signed NRPN: the keyer compensation, the unimplemented balance controls.

The time units are samples, but displayed as ms in the controller interface.

-- 73 -- rec -- ad5dz --

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/09a1b7a5-eeed-48d0-9144-834b1726e807n%40googlegroups.com.

[Roger Critchlow]

Hello Jim --

Oh, that must be the version which had a default non-zero ptt head time applied to the sidetone.  

The more recent hex files from https://github.com/softerhardware/CWKeyer fix that.  The released hex files are in the firmware/TeensyWinkeyEmulator and firmware/hasak directories.  The firmware/releases directory doesn't get updated often.

-- 73 -- 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/cec8eac4-c95e-4a2a-b41e-d651d8c4c4een%40googlegroups.com.

[Graeme Jury]

Hello Jim,

You can save a lot of messing around if you use an ssh connection to github g...@github.com:softerhardware/CWKeyer.git as you dopn't have to set up the dual authentication which has recently been introduced. Don't forget to use


The first time you checkout use --init   e.g.
git submodule update --init --recursive

from then on to pull use
git pull --recurse-submodules

I made a symlink to the hasak and winkeyer subdirectories in my sketchbook directory and compiled from there. If you are going to change the code it may be best to fork the project and do pull requests.

73, Graeme zl2apv

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/CAGayqov4%2BCoxBLj-KQOV32%3D17j4fP7Bi0KQ4jYyhq%3DROBAfAZA%40mail.gmail.com.

[Steve Haynal]

Hi Roger,

When you post a .hex file, are you posting it in the release area or in your repository? I don't care where it goes, but is should be in one place and clear on the project page. Right now the project page points to the release area which is nice as you have access to past releases:

https://github.com/softerhardware/CWKeyer#programming-the-teensy-4

Can you please either move your releases there, or update the project page to point to where you'd like your releases?

73,

Steve

kf7o

[Steve Haynal]

Hi Christoph,

Is the red line the PTText from the HL2 or the Keyer? I assume HL2?

The default TX buffer latency is 20ms, unless software changes it. It can be set up to more than 40ms, but the bounds are determined by jitter on your network. The max length is around 80ms. 

I'd recommend always staying in full duplex. To minimize annoying crosstalk during TX, enable the hardware-managed LNA and set the LNA value to -12 during TX:

https://github.com/softerhardware/Hermes-Lite2/wiki/Protocol#base-memory-map

You may want to experiment with the PTT option of 31 ms added here:
https://github.com/softerhardware/Hermes-Lite2/tree/master/gateware/bitfiles/archive/20210516_73p1

73,

Steve

kf7o

[si...@sdr-radio.com]

Roger,

 

Just FWIW I’m liking this hasak hex, I can now start development with a good working firmware.

 

What I’ve never tried to do and what I can’t do is query the current settings. Is there a specific command which instructs the keyer to return the state of  all controls?

 

Simon Brown, G4ELI

https://www.sdr-radio.com

 

From: herme...@googlegroups.com <herme...@googlegroups.com> On Behalf Of Roger Critchlow
Sent: 10 February 2022 22:01
To: Reid Campbell <scumballc...@gmail.com>
Cc: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: Software Support for New CW Keyer

 

Thanks, Reid --

 

That was my error, set the mask correctly, tested the mask correctly, but forgot to ensure that the mask was copied to its correct location.

 

It should be fixed by the current contents of https://github.com/softerhardware/CWKeyer/tree/main/firmware/hasak.

 

-- 73 -- rec -- ad5dz --

[Steve Haynal]

Hi Jim,

If you are not seeing low key-to-ear latency, then something is broken in the keyer firmware. You are correct that a main goal of this project is low key-to-ear latency. Key-to-antenna latency may be a little longer, but that should not matter. See this post where I and others measured latencies around March 8:

https://groups.google.com/g/hermes-lite/c/XC-Q9nlXiLU/m/jHQe3r0-DAAJ\

Some measurements were with Quisk.

There are getting started instructions here:

https://github.com/softerhardware/CWKeyer

The instructions will be expanded and enhanced over time.

73,

Steve

kf7o

[Roger Critchlow]

Hi Steve --

I'll just keep leaving them in the hasak directory, it's an extra step to remember to build it, and I'm beginning to remember how to get the update into CWKeyer..  The release directory is confusing, it has a directory named  20210109 which looks like a date from January last year.  The TeensyWinkeyEmulator in there is over a month old.  Oh, you wanted to keep dated directories

I'm about to push a branch named 'rec' to the CWKeyerShield.  It implements a NRPN layer for the emulator with a handful of NRPN's defined.  It also stores all control change data bytes in a ctrls[] array.  If you could check it out, build a TeensyWinkeyEmulator, and exercise the MIDI handling with your python package I would appreciate any feedback.  You should be able to write all 128 values, query their values, overwrite, query again, and unset them.  Unset values have no value, so the query operation does not return.

If that goes well, we can merge it and you can start making NRPNs.

-- 73 -- 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/d9c2b583-c45c-437a-a070-bf16ac2328d6n%40googlegroups.com.

[Roger Critchlow]

Hi Simon --

The best reference to all the hasak nrpns is in the MIDI controller source, https://github.com/recri/cwkeyer-js, the file src/hasakProperties.js is constructed from hasak/config.h, but it's easier to read.  But beware that they aren't all there, that is they may be in the file but not in the implementation, and there are some that are implemented and look as though they work, but they don't sound right to me.

  "KYRP_ECHO_ALL": {nrpn: 2003, type: "cmd", label: "Echo all", title: "echo all set nrpns to midi", property: "echoAll"},

-- 73 -- rec -- ad5dz --

[DL1YCF]

Yes, this is the PTT lead-in time. In the most recent versions I have reduced this to 50 msec (it was 150 msec before).
When keying SDR software via MIDI, the SDR program takes some time to „go TX“.

You can use any "WinKey manager“ program to change the settings, at compile time you only set the default.
So changing the lead-in time to zero or disabling PTT and its gone.

> Am 11.02.2022 um 19:11 schrieb James Ahlstrom <jah...@gmail.com>:
>
> Hello Group,
>
> I am back from skiing and Steve sent me a SofterHardware CWKeyer, so I have some initial observations.
>
> Since the point of this project is to create an immediate sidetone, I was surprised to find that when testing with a straight key the sidetone was not immediate. I am testing with the USB connected to Quisk, headphones and the straight key jack. The hex files are from yesterday. When I press the key, the hardware sends 0x9402,127, then 0x9401,127 with sidetone. That is, there is a pause until the sidetone is heard. Thereafter, sidetone is simultaneous with key presses until there is a sufficient pause to produce a 0x9402,0 message to end transmission. It seems the hardware sends 0x9402 as a kind of PTT to change to Tx, and then sends key press messages with sidetone.
>

> This can't be right. The first key press must be simultaneous with sidetone.

With 50 msec delay you hardly notice it, and I just won’t put any resource in recording all key-down/up events
with a time stamp and replay them later. Just disable PTT or set the lead-in to zero and you are happy,
but then check whether your SDR software does it right and the first dit arriving at the antenna is not
shortened. If you key the HL in hardware, you need not PTT and thus no lead-in time. The lead-in time
is all about keying via MIDI.

> If the HL2/SDR combo must do something to change to Tx, that is its problem, not the problem of the CWKeyer.

Again, just switch of PTT or set lead-in to zero. If this works without problems then it is just fine.
The lead-in option is meant to solve problems, not to make problems. If you do not
like it, do not use it. I need it, therefore some lead-in is the default.

Most important:

The setting is stored in the Teensy EEPROM, so once you change it, it will remain forever (until
the next explicit change). The setting even „survives“ recompilation, but I am not sure
if it „survives“ re-loading of a hex file.

Yours,

Christoph.

[si...@sdr-radio.com]

Roger,

 

• What is the correct range of values for Master Volume, Sidetone Volume and Sidetone frequency?
• I am not sure the NRPN is being sent correctly, I have to shift the LSB (98) down one bit to match the values in hasakProperties.js. Value seems OK – Speed sends 5 to 54.

--

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/CAGayqotOe6zTKotDjcFy4_NtsV71Bq-Jigs%3D4sEAGT8gtQD6Rw%40mail.gmail.com.

[DL1YCF]

Yes, PTText is the HL2 RCA. piHPSDR sets the TX latency to 40 msec. This is hardwired, the tests
with 20 msec have been made with changing that constant in the source code.

> Am 12.02.2022 um 06:54 schrieb Steve Haynal <softerh...@gmail.com>:
>
> Hi Christoph,
>
> Is the red line the PTText from the HL2 or the Keyer? I assume HL2?
>
> The default TX buffer latency is 20ms, unless software changes it. It can be set up to more than 40ms, but the bounds are determined by jitter on your network. The max length is around 80ms.
>
> I'd recommend always staying in full duplex. To minimize annoying crosstalk during TX, enable the hardware-managed LNA and set the LNA value to -12 during TX:
> https://github.com/softerhardware/Hermes-Lite2/wiki/Protocol#base-memory-map
>

Nope. When using PURESIGNAL, the LNA is set as to have the correct feedback level. BUT, this is about -15 dBm so will
definitely lead the AGC into saturation, if the RX continue to work. „duplex“ is a purely software issue, namely
whether the (software) receivers still get samples or not.

Even -12 dB LNA won’t do it if you use a PA. crosstalk at the T/R relay is not better than 60 dB, so
with 100 Watt out (50 dBm) you get -10 dBm at the antenna input, still enough to saturate AGC no matter
which LNA position.

> You may want to experiment with the PTT option of 31 ms added here:
> https://github.com/softerhardware/Hermes-Lite2/tree/master/gateware/bitfiles/archive/20210516_73p1
>

Again I do no think so. I guess with the new firmware that has about 80ms „FIFO space“, a TX latency
of 40 msec is very good. And if doing hardware CW keying without PTT, 40 msec RF delay will suit
most PAs. So the basis message is:

Hardware keying: 40 msec PTText-to RF delay, if you have an „antique“ PA that needs more,
use hardware PTT and a lead-in that is OK for you.


MIDI keying: PTText-to-RF is not problem, but check which lead-in time you need for NOT
chopping the first pulse. This is entirely related to your SDR program (not to
the hardware).

> There is a 50msec PTT-to-RF delay, but the first RF pulse is shortened. The reason for this
> is that this was in non-duplex mode so the WDSP receiver needed shut-down first and (only)
> then TXing starts. Consequently this is worse in "dual RX" mode:
>
>
>
>

> However when activating DUPLEX (that means, the WDSP receivers continue to get samples
> and need not be shut down), there is not problem even with 2 RX.
>
>
>
>

> Normally I don't use DUPLEX mode. The crosstalk from the T/R relais leads to
> strong RX signals while TXing and thus to
> "AGC pumping", that is, after a TX/RX transition your receiver is deaf for a short
> amount of time. I could, of course, do DUPLEX and zero the RX IQ samples while TXing
> but I guess shutting down the RX during TX frees the CPUs for doing TX-specific work.
>
> Of course, this is what the PTT lead-in time is all about!
> Even in non-duplex mode with
> 2 RX active, a lead-in time of 40msec is enough (so the MIDI PTT-on message arrives
> 40 msec before the first CW Key-down messaga)
>
>
>
>

> so this is why I shortened the default lead-in time from 150 to 50 msec. Of course, if
> you have a VERY slow PA you can increase the lead-in time to any value you like,
> here e.g. measured with 100 msec (note the "SDR" delays add onto this value):
>
>
>
>

> but this is normally not needed.
>
>
>
> Yours,
>
> Christoph DL1YCF.
>
>

> --
> 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/fa61229e-3273-49cf-8231-1cff727dead2n%40googlegroups.com.

[Roger Critchlow]

Simon --

The level controls are signed values, so you need to sign extend the 14 bit NRPN value.  

The units are dB/10, so the range -819.2 to 819.1 is ridiculous, just use the part in the middle.  Since I didn't have to pack parameters into single bytes, I opted to use units that didn't need a lot of mangling.  Single digits of fractions display nicely in a UI control, too.

I'm still puzzling out what the right range would be.  If you take an unsigned 32 bit integer, you have  to right shift it 32 times before all the bits disappear. So a 32 bit unsigned int has 192 dB of dynamic range?  If that argument holds water, then a 64 bit value holds 384 dB, and a 128 bit value holds 768 dB.

-- 73 -- rec -- ad5dz --

[si...@sdr-radio.com]

Roger,

 

I assume you splitting the 14-bit value into to two 7-bit values, sending these in the MSB and LSB?

 

For Master Volume & Sidetone Volume the range I see is 16065 to 16383, For Sidetone Frequency 2560 to 12730 (256.0 to 127.3 Hz?). Speed is good – 5 to 54.

 

So for volume I have a range of 319, is this correct?

 

Simon Brown, G4ELI

https://www.sdr-radio.com

 

[si...@sdr-radio.com]

Sorry,

 

Re: Volume, I expect you’re sending 0 to -31.8 dB?

Re: Frequency 256.0 Hz to 1,273.0 Hz?

 

Simon Brown, G4ELI

https://www.sdr-radio.com

 

From: si...@sdr-radio.com <si...@sdr-radio.com>

Sent: 12 February 2022 16:18
To: 'Roger Critchlow' <r...@elf.org>
Cc: 'Reid Campbell' <scumballc...@gmail.com>; 'Hermes-Lite' <herme...@googlegroups.com>

Subject: RE: [Question] Software Support for New CW Keyer

 

Roger,

 

I assume you splitting the 14-bit value into to two 7-bit values, sending these in the MSB and LSB?

 

For Master Volume & Sidetone Volume the range I see is 16065 to 16383, For Sidetone Frequency 2560 to 12730 (256.0 to 127.3 Hz?). Speed is good – 5 to 54.

 

So for volume I have a range of 319, is this correct?

 

Simon Brown, G4ELI

https://www.sdr-radio.com

 

From: Roger Critchlow <r...@elf.org>

Sent: 12 February 2022 15:31

[Roger Critchlow]

Simon --

Good idea.  I don't do xml, but send me an example and I'll cobble up something.  There's probably a JSON XML converter somewhere.

So many formats for property lists, so little time.

-- rec --

On Sat, Feb 12, 2022, 11:55 AM <si...@sdr-radio.com> wrote:

Roger,

 

Just thinking aloud – at a later stage when users are downloading .hex files, an accompanying XML or other file with NRPN values and ranges could ensure no changes needed to the GUI.

 

Having the MIDI notification for Key Out is excellent, with this I can generate MCW for Pluto, Lime etc.

 

Simon Brown, G4ELI

https://www.sdr-radio.com

 

From: Roger Critchlow <r...@elf.org>
Sent: 12 February 2022 16:47
To: Simon Brown <si...@sdr-radio.com>
Subject: Re: [Question] Software Support for New CW Keyer

 

Simon --

 

Right, those are the ranges that the pots map into, and you can check that by opening https://cwkeyer.elf.org, opening the Basics folder, and watching the values as you twiddle the pots.

 

-- rec --

 

[Reid Campbell]

Hi Roger, Simon,

Should the 4 pot controls not be producing normal note data and not NRPN. I think we are limiting the versatility of the keyer by using this more specialised commands for the pots. There is SDR software already out there which can easily map the pot controls which will be confused by NRPN.

Cheers

Reid
Mi0BOT/Gi8TME

[si...@sdr-radio.com]

I agree, but it’s really not that hard to check for a defined sequence of four MIDI messages.

 

Simon Brown, G4ELI

https://www.sdr-radio.com

 

[Reid Campbell]

A lot of these existing interfaces just expect one midi note. My experience with PowerSDR and Thetis is that multiple MIDI messages confuses the mapping of a note to a function. What advantage is NRPN giving us, as the big disadvantage is incompatibility.

Cheers

Reid
Mi0BOT/Gi8TME

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/028801d82047%245961d420%240c257c60%24%40sdr-radio.com.

[Roger Critchlow]

Reid --

It's not a problem.  Hasak keeps everything in NRPNs as a matter of policy, but we can easily enable a few note formatted leaks for you, just need the time to come up with a generally useful solution.  Which notes do you need and what do they mean?

-- 73 -- rec -- ad5dz --

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/9782f390-4157-7874-181b-97596bb21db3%40gmail.com.

[Reid Campbell]

Hi Roger,

Any output from the keyer which causes an action should be a single note. It doesn't matter what the note is because it is mapped. The mapping process works by causing the MIDI note to be output, which is detected by SDR software. The note is then mapped to an action.

The outputs that I can think of are:
Keyed out
Keyed PTT
Voice PTT
Master volume
Side-tone volume
Frequency
Speed

Having mapped the note, it can be made bi-directional so the speed can be sent back to the keyer, or PTT, to key the physical port on the keyer.

The problem comes were there is no output to mapped, like how to change the mode of keying to A or B. Christoph had a suggestion of wrapping up the Winkey protocol in MIDI messages. Maybe that's were the NRPN comes in, I haven't studied the MIDI protocol that closely at the minute but I think it would be sensible to go with the established Winkey protocol. It needs to be supported anyway as a large number of logging programs use it.

Cheers

Reid
Gi8TME/Mi0BOT

[DL1YCF]

>
> The problem comes were there is no output to mapped, like how to change the mode of keying to A or B.

At the moment there are MIDI messages for PTT lead-in and hang time. But seeing where this leads to,
I wish I had never opened this box of Pandora and restricted Keyer control to the serial line.
If SDR console programmers want to have these things, they should use the WinKey protocol and a serial
line, simply because then it also works with a plethora of other keyers. The WinKey protocol is
a quasi-standard in CW business, as witnessed by the many kinds of „WinKey clones“ for Arduinos etc.,
so why inventing another wheel?

Just my .02,

Christoph.

[Roger Critchlow]

Hi Reid --

So Keyed Out, Keyed PTT, and Voice PTT should all be 127 for on and 0 for off.

What values do you expect for volume, frequency, and speed?  

-- 73 -- rec -- ad5dz --

[si...@sdr-radio.com]

Hi,

 

0 to 127 for volume and frequency, 0 to 54 for speed.

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/CAGayqouO-GeL9UOeJOTET2z5Sp0HrzFxoxJ5vaDVqzh8Te2j7g%40mail.gmail.com.

[si...@sdr-radio.com]

Sorry,

 

5 to 54 for speed, too early, need glasses ☹ .

 

Simon Brown, G4ELI

https://www.sdr-radio.com

 

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/005d01d820a1%24ebe18ac0%24c3a4a040%24%40sdr-radio.com.

[Reid Campbell]

They sounds good to me. Have we covered all the possible outputs?

Cheers

Reid
Mi0BOT/Gi8TME

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/006601d820a2%24677b6340%24367229c0%24%40sdr-radio.com.

[Steve Haynal]

Posting back to the group for wider visibility.

73,

Steve

kf7o

---------- Forwarded message ---------
From: DL1YCF <dl1...@darc.de>
Date: Sat, Feb 12, 2022 at 2:47 AM
Subject: Re: Software Support for New CW Keyer

To: Steve Haynal <softerh...@gmail.com>

Jim’s observation ONLY concerned the first dit, from then on everything was in-sync.
He was just using a PTT lead-in time, which can be set to zero and everyone is happy.

> --
> 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/879d4775-af0a-4940-8b99-0cbd8c6a8293n%40googlegroups.com.

[jpwa...@gmail.com]

Is the CWKeyer available from MakerLabs yet, or do we just order PCB's and parts?

..jpw J P Watters

KC9KKO

Morris, IL USA

[Steve Haynal]

Hi JPW,

No, it is not available yet. I also advise against using the current PCB. There a few minor changes I plan to make:

https://github.com/softerhardware/CWKeyer/issues

Once those are done, software support has settled down, and the post Chinese New Year rush as past, I will arrange for Makerfabs to sll units.

73,

Steve

kf7o