CWX/Keyboard CW

[Matthew]

I think I am up for the challenge of trying to implement keyboard CW for my purposes of replacing the need for an external keyer (e.g. winkeyer) for contesting with the HL2 (i.e. keyboard/macro cw).

Having never used PowerSDR or a Hermes, the concept of CWX is something I have only recently picked up through this forum. I've struggled to find a clear idea of what it does but from looking at the Hermes gateware (and trying to decipher the PowerSDR source code) I think I can see that through the TX data sent from the PC it tells Hermes whether to send a dit or a dah, Iambic.v seems to be the main part of this. Can anyone on this group comment on performance of this? Especially at speeds of >= 30 WPM? My concern with this approach is that over a remote link, jitter could come into play and result in CW sounding fairly ropey at more QRQ speeds. Perhaps I am wrong in my understanding of CWX at hardware level?

Starting from a clean page before looking at the CWX stuff (and about 4 years since I wrote any verilog to remember how much code something takes up in an fpga), my thought was to send the character to the HL2. The HL2 then has a look up table of characters and sorts out it's own dot/dash timing. This means there is no need to implement a keyer to cope with Iambic A, B, ultimatic etc. It feels like this should be through a separate port, but this may be beyond my rusty verilog at the moment for an initial prototype.

My thinking is then a PC app looks like a winkeyer server to logging software but sends the characters to the HL2 (and provides sidetone). It would probably need some sort of end of word flag to ensure correct word spacing. Some clever thought over a buffer (and transmission rate of characters from the PC) to hold the characters would be required to reduce code size? With the space available in the HL2, does this seems at least feasible in a rough sketch concept?

I appreciate this sort of CW operation is not for everyone, but the beauty of the HL2 is it is open source and everyone can make their own modifications/changes. Additionally, this framework should allow to PC paddle based operation.

73 Matthew M5EVT.

[Steve Haynal]

Hi Matthew and Group,

Thanks for your interest in remote CW functionality. I'm also interested in that. I actually took the extra exam at a time when you had to do 20wpm and used to do entirely QRP CW with a straight key, but don't think I could do that again without much practice, so it would be great to have your input and help as a current CW user. I half heartedly started on adding the openhpsdr keyer to the HL2 several months ago, but didn't do much. I've been thinking and reading a lot about remote CW and now have a better picture of what I'd like to attempt. After this next gateware release in the next day or two, I'd like to focus on remote CW. 

First I'd like to enable CWX. I couldn't find much documentation too, but my understanding is that it is keyboard-based CW through PowerSDR without any sidetone. I've read that once you try it, it is very intuitive to use so doesn't need much documentation. I have a good understanding of what is implemented in the gateware to support it based on the openhpsdr RTL.

I'd eventually like a way to connect a key or or paddle to the PC that is less expensive than a winkeyer. This is outside of the HL2 gateware as most support is (already) provided by software, but the gateware may need some enhancements. There is already a way to connect a key or paddle to the PC supported by PowerSDR:

https://apache-labs.com/community/viewtopic.php?f=14&t=3100

More details on connecting a CW key or paddle to a PC:

https://www.youtube.com/watch?v=TgiHS2UC0JQ&t=148s

https://morsepower.blogspot.com/2016/08/cwcom-getting-started-connecting.html

I have been playing with a <$5 Pro Micro board:

https://www.aliexpress.com/item/32768308647.html

The Pro Micro board can be configured to send MIDI data or Serial data to a PC. I'd like to create a small simple program for this board that has a jumper to select between MIDI or serial and then uses the other pins for various inputs to the PC. The idea is for it to be a cheap generic means to interface switches, buttons, keys, dials, to SDR software. I will send one of these for free with image flashed (when ready) to anyone seriously developing SDR software. There are also plenty of inexpensive serial-only USB adapters which can be used.

Latency is a real concern when doing CW through a PC with sidetone. The above Apache link stresses the importance of ASIO drivers, which I agree with. WASAPI on Windows is supposedly just as good but I don't have experience with it. ASIO or ASIO-like low latency on Windows and JACK on Linux is a must. Fortunately, the hams over at 

http://qrqcwnet.ning.com/

have put together quite a bit of interesting and helpful information related to this. In particular, check out:

https://www.youtube.com/watch?v=zzd7naKzRgw

https://www.youtube.com/watch?v=-ky2WJEZnxU

In fact, there are many many really good videos by the qrqcw group, especially those by AA0HW, and even videos featuring group member AD5DZ's code:

https://www.youtube.com/user/QRQcw/videos

http://qrqcwnet.ning.com/profile/chase

I added the KXStudio repositories to all my Linux machines and am using JACK and Carla as described by AA0HW for everything now. This has eliminated some occasional glitches I would see during FT-8 transmit with wsjt-x and Quisk. Although there is a small learning curve (KXStudio and the Carla, Cadence and Catia apps have made it *much* easier than the past), it is well worth the effort. I am never going back... In fact, a modular SDR based on plugins and Carla (there are already many exceptional audio filters, imagine a PureSignal plugin) is a dream, similar to GNU radio but leveraging the much richer body of existing work.

https://kx.studio/Repositories

Although SDR software can (and should) support low latency audio interfaces and better CW, I don't necessarily think the CW support should be in the SDR software. First, you have to add CW support to all your favorite SDR programs which is a pain. Second, the SDR software has to manage the latency. Instead, I think the CW support should be a plugin (VST, LV2) or jack-enabled app that I can wire up in Carla. This plugin or app should take the audio output of SDR software as input, then insert the CW sidetone and send data to the HL2 on a different ethernet port. Since the CW app is managed by jack and last in line to the audio, latencies to the audible sidetone of well under 10ms should be possible. I run my system at 5ms latency and am not really pushing it. Also, the plugin or app will mute the receiver sound when the CW is sounding. Latencies from the HL2 for receive or to the HL2 to send may be a little longer, but won't matter in practice.

There is quite a bit of help on writing VST or LV2 plugins, and they are designed to be simple to write with many virtual knobs, sliders, etc:

https://lv2plug.in/pages/developing.html

https://docs.juce.com/master/tutorial_create_projucer_basic_plugin.html

There is even a jack-enabled app that implements the openhpsdr cw keyer:

https://github.com/n1gp/iambic-keyer

It is important that the software version of the keyer match the RTL version for proper timing.

Here are some specific tasks if people are interested in helping with this effort. Also, please share and discuss any other ideas for remote CW.

** kf7o: Add CWX to gateware

** kf7o: Add second ethernet port for async independent sending of CW info to HL2 gateware if and when needed

** kf7o or ???: Create simple Pro Micro Arduino program to send button pushes, etc, to PC as midi or serial data. Favor interface standards and conventions of existing software.

** ???: Create VST or LV2 plugin or extend N1GP's iambic-keyer to accept audio in and mix in a sidetone, as well as send async ethernet data to the HL2.

** ???: Add similar low latency functionality as the VST/LV2/N1GP program above to existing SDR software, and receive a free programmed Pro Micro from me :)

Any volunteers?

 

I've spent way too much time writing this post... I am trying to post less and develop more in my limited hobby time this year.

73,

Steve

kf7o

[Alan Hopper]

Hi Mathew and Steve,

I have an experimental keyboard cw working in Spark, it is not ready for general release but I think I'll add an 'experimental' option to allow people to opt in to incomplete features. It might at least prove useful in designing something better. I keep going round in circles thinking about remote key'd cw, I have worked out a fairly optimum way to do low latency sidetone in spark but then wonder if an external keyer with sidetone is simpler and ultimately better. I had thought of making a usb device with keyer, sidetone and a few knobs and buttons.

73 Alan M0NNB

[Alan Hopper]

Hi All,

I've just posted a version of Spark here http://www.ihopper.org/radio/previews.htm 2.0.1.0beta1 (windows only for now, linux this evening). In settings it has an option to show experimental stuff. Once this is set it is best to restart Spark.  There should then be keyboard cw modes CWH & CWL . These have had very little testing but might focus ideas for remote cw.  There is an exceedingly crude cw detector that is probably best just ignored.  The cw works through generating iq on the pc and does not currently use the cw features of the HL.

73 Alan M0NNB

[W. J. Sz]

Hi Steve and group, 
When we use ASIO by several applications simultaneously, there are sometimes problems. One of the good solutions is FlexASIO https://github.com/dechamps/FlexASIO. 
73, Jozef 

[James Ahlstrom]

Hello Group,

I don't use PowerSDR so I am looking at the Protocol 1 specification to see how remote CW might work. The PC can send keyer speed etc. to the hardware in address 0b1011, so there must be a keyer in the firmware. There is also a hardware input for a dot/dash paddle, so the keyer can be used if the HL2 is local. But if it is remote, there is no Protocol 1 command to close the dot/dash by software, so the keyer can not be used remotely. Even if such a protocol existed, it would not offer any advantage over just sending key up/down commands from the PC, assuming the PC was connected to a paddle. So a firmware keyer is useless.

I assume CWX means sending the ASCII text to the firmware and programming the firmware to form the CW; so send 'a', the firmware generates dit dah. But there is no ability to send text in Protocol 1.

I am not sure what to do about this, but I am opposed to any solution that is based on an extended protocol, and therefore makes it difficult to use PowerSDR. Lots of people like PowerSDR.

Perhaps someone can explain if and how PowerSDR can generate CW and send it to remote hardware. Does it just send a 1 kHz sine wave and transmit it as SSB?

Jim

N2ADR

[Matthew]

I *think* PowerSDR/CWX uses some bits in the TX packet from the PC to tell the keyer in the Hermes gateware whether to send a dot or a dash. My concern is that if using a link from the PC to HL2 with jitter (wifi, remote VPN), at higher speeds, times between dots and dashes to form a character could make the transmitted CW sound like poor keying? Hence why I was thinking that it would be best to send the character to the HL2, then jitter only affects space between characters.

If the user is sat at the HL2 with a paddle, to my mind there is little need for a keyer (in the normal sense) in the HL2, one can simply use a Winkeyer (or Arduino clone as I do). So for remote CW, the logic needed is simply to key the TX for 1 of 2 periods (periods set by the keyer speed address Jim mentions above). This should simplify logic, rather than having to implement Iambic A, Iambic B (and ultimatic modes that some keyers have). I am keen to experiment with sending the character to the HL2 rather than the dot/dash, this seems much more robust.

I am very familiar with KXstudio and Jack. When I installed KXstudio a few years ago this was the first time Jack worked well and reliably for me. Latency was low enough that I couldn't "feel" it on an electric guitar. I am waiting to upgrade to the 18.04 ISO, but this seems to have been in the pipeline for a long time now.

I think the approach outlined by Steve sounds sensible and should appeal to the masses. I will certainly be interested in prototyping some ideas to support this, but GUIs are never my strong point. My focus is on interfacing logging software (which needs to be done through a custom written winkeyer server) to send CW through the HL2 rather than using a paddle.

73 Matthew M5EVT.

[in3otd]

Looking at the Hermes code, there are these lines:

//--------------------------------------------------------------------------------------------

//  Iambic CW Keyer

//--------------------------------------------------------------------------------------------

// parameter is clock speed in kHz. Keyer data from PC is sent in I channel when in FPGA CW mode. 

wire keyout;

wire dot, dash, CWX;

assign dot  = (IF_I_PWM[2] & internal_CW);

assign dash = (IF_I_PWM[1] & internal_CW);

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

iambic #(30) iambic_inst (.clock(Apollo_clk), .cw_speed(keyer_speed),  .iambic_mode(keyer_mode), .weight(keyer_weight), 

                          .letter_space(keyer_spacing), .dot_key(!KEY_DOT | dot), .dash_key(!KEY_DASH | dash),

  .CWX(CWX), .paddle_swap(key_reverse), .keyer_out(keyout));

so it seems that the keyer data are sent in the TX packet (I data, IF_I_PWM), when internal_CW is enabled (bit 24 at address 0xf).

As far as I understand, the PC can send straight CW using the CWX bit (in the keyer code CWX goes more or less directly to keyer_out) or send dot and dashes that will be then generated by the keyer in the FPGA.

73 de Claudio, DK1CG / IN3OTD

[neil whiting]

This all sounds very complicated :-)

Is it not feasible to just use the audio path in place for SSB to send a keyed sine-wave at the preferred CW tone?

You would want to set the TX filtering in CW mode so that harmonics are attenuated - this used to be difficult with 

filter SSB transceivers but ought to be easy on an SDR.

Or am I missing something?

73,  Neil  G4BRK

[Roger Critchlow]

It is feasible, but there is a 22ms lag between transmit audio arriving at the HL2 and a transmitted signal reaching the antenna, hence a minimum 22ms lag between key events and key tone events derived from the transmitted signal.  When I last measured the latency between MIDI key events and receive audio in Jack it was just a bit less than 22 ms.  This 22ms delay is part of the HL2 transmit buffer design, intended to smooth out the itter in inter-packet arrival times.  The 22ms delay is perfectly tolerable for most users, but too much for QRQ and QSK operations.

-- 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/f4992bd4-5f0d-4ebf-bef4-cb039c214845%40googlegroups.com.

[Matthew]

The method you describe works. However, if we want to remain independent from needing SDR authors to integrate functionality into their software then it needs a separate app. This then means virtual audio cables (or such like) to route the audio CW to the software. Then you need to get the drive levels correct, plus get VOX set correctly. I have done exactly this using fldigi. I think recent discussions elsewhere on this forum suggested there is no free software for Windows to do this.

However the subtle yet annoying part of this for me is that you are using LSB/USB mode and QSYing to cluster spots doesn't work as you are offset in frequency (if this doesn't make sense tune a CW signal in CW mode in some SDR software then change to USB, look at the frequency). I use CAT control to QSY to a cluster spot, it doesn't take my to the frequency and I have to re-tune manually. This soon gets irritating in a contest.

Alan - I tried to test your new version of Spark SDR, it didn't work in Ubuntu 18.04, it returns a blank line (no errors) and returned to the command prompt. The previous build works fine.

73 Matthew M5EVT.

[James Ahlstrom]

Hello Neil,

The other answers are correct, but actually your method works better than you might think. First you use a sine wave at zero Hertz; that is DC, a constant amplitude. This has a zero offset, but you need to shape the key envelope as usual. Since you are sending "sound", the HL2 buffers the signal just like in SSB, so there should be no jitter. But there will be a delay between when the CW starts at the PC and when it is transmitted. Roger measured this as 22 msec.

Still, the real issue is how to accommodate all the SDR software out there. PowerSDR, for example, does not work that way.

Jim

N2ADR

[Alan Hopper]

Hi Mathew & all,

I've just overwritten the linux build with a new version as I did it in a bit of a rush, please let me know if it works for you (it works here).

I think supporting the powersdr solution obviously makes sense as people use it and so far we have not found anyone to modify powersdr but exploring other solutions is also fun. From the spark perspective I'd prefer to put time into something that works for many radios rather than just hpsdr stuff.

My current experiment does create cw on the pc (as if it were usb), as James says this removes the issue of jitter, latency on the pc can be low as no tx filtering is needed as you can generate a clean waveform, the only issue is the latency in the hl2 tx buffer, on a good pc and network I suspect this can be made much smaller without issue.

 

The alternatives of passing dot/dash key or paddle state direct to the radio at first appear tempting as they could avoid some of the latency but I suspect you are just swapping latency for jitter.

Jitter and latency are deeply related, much of the latency is there on purpose to cure jitter, bypassing buffers to reduce latency just moves the jitter problem down the line.

I'm unconvinced about having the keyer on the hl2(for remote usage) as jitter will make life hard for the keyer unless the paddle press info is time stamped but then you still have to buffer for the expected jitter.

We can support multiple solutions at once, if my experiment proves useable  it does not impact the powersdr solution. Having some control over tx buffer size would be nice and could have benefits for other modes as well, this maybe possible with no firmware mods simply by tracking buffer level and dropping the odd packet to keep the buffer as small as possible.

73 M0NNB

[James Ahlstrom]

Hello Claudio and Group,

Thank you for the code. Together with using PowerSDR I think I am getting a clue. It looks like the gateware iambic keyer came first, and used the hardware paddle input to the Hermes. Since the Hermes hardware had the paddle, the keyer had to be in the gateware. When remote keying from the PC became available, it sent a dot and dash bit to imitate the paddle plus a CWX bit that just closed the key. My PowerSDR version is 3.3.7. The CW settings are in the DSP/CW tab and the CWX tab.

PowerSDR has a connection to a COM port for keying, and can generate keying from ASCII text. Of the three bits sent from the PC to the Hermes, I fail to see the point of the dot and dash bits that imitate the paddle. The CWX bit can operate the key and create all the dots and dashes it wants. I wonder if PowerSDR really sends the dot and dash bits at all. If not, it would be easy to implement the CWX bit in the HL2 because it is equivalent to the hardware key we already have. I won't have time to check exactly what PowerSDR sends for CW because I am leaving for a ski trip on Sunday.

The critical point here is that PowerSDR sends the pattern of keying in the Tx I/Q sound samples. It does not try to operate the key directly. That means there is no problem with jitter from PC timing issues. It is like a paper tape of key data to be played when it gets to the PC (anyone else remember paper computer tapes? - probably not). When the CW "tape" gets to the HL2, it is buffered and played just like SSB. If SSB has no dropouts, then the CW will have no timing issues. There will still be a delay between when the CW is generated and when it is transmitted. Roger measured this as 22 msec. I don't think this is a problem, because it is comparable to the time needed to switch from Rx to Tx and allow Tx relays to settle. Or we could use less buffering for CW because the jitter from reading the mic is absent.

I have always been neurotic about PC timing issues and CW, but now I think times have changed. Even ARM processors now have multiple cores and can provide prompt timing. As a test I just pinged a couple of addresses on my network. Both a directly wired and a WiFi address were one msec round trip. Try it. Anyway I no longer see any point in sending ASCII text to the HL2 since it is equivalent to sending a tape of key data.

So IMHO adding remote CW to the HL2 means we implement the Protocol 1 as used by PowerSDR. If PowerSDR doesn't really use the dot/dash bits, we don't even need the gateware keyer.

Jim

N2ADR

[Steve Haynal]

Hi Group,

Just a few comments as I catch up on these posts.

Thanks Alan for the SparkSDR with initial CW support. I hope to try it soon.

My understanding of the PowerSDR remote CW operation agrees with what Claudio described and Jim just concluded ("tape player" model). The way I think of it is that the microphone IQ sample buffer is emptied at the same rate and fashion as it currently is for real audio. The SDR software stuffs CW key events into bits of these samples which are read out at a constant rate. Although everything could possibly be done with just CWX, I'll probably add the keyer to support dot and dash and better PowerSDR compatibility.

There should be no jitter as the timing is predetermined by the sequence of events read at a constant rate from the transmit FIFO. Although probably not necessary if software is doing everything, the keyer has a special letter space mode such that if there is idle time exceeding the minimum space between dot and dash, it will insert a proper letter spacing of 3x the minimum space time, that can help ensure timing.

There will be latency as others have pointed out. I'd like to distinguish between key-to-sidetone latency and key-to-antenna latency. A few tens of milliseconds should not matter for key-to-antenna latency. Key-to-sidetone latency will matter for those using a paddle, and for those uses I think a low latency audio setup like I described earlier will be required. But key-to-sidetone latency for keyboard entry of CW should not matter, and if this is the main mode of operation for some, there is no need worrying about the complexities of setting up a low latency audio PC system.

The current latency is 22ms. This is hard set in the gateware. It is just a couple of numbers and I will look into making this configurable for reduced latency experiments. 

On Facebook, a friend of mine just posted numbers for his new fiber internet service. Even over a wide area network and internet provider, he was seeing ping latencies of 12ms and jitter of 1ms for destinations within 20km of him. I agree with Alan that we should be able to tune the latency to less than 22ms on a good home network. I suspect most of the jitter one might see with SDR software is from timing variations in the software getting around to forming and sending a new packet rather than the underlying network.

73,

Steve

kf7o

[Alan Hopper]

Hi Steve,

I've been tweaking the latency in Spark and shaved 15ms off both tx and rx by bypassing the tx filter for tx and using a minimum phase filter for rx, (15ms was the group delay of the filters). I also found a delay on key presses as it currently finishes a full space if idling before sending a new key press. I hope to release the improved version in the next couple of days.  I'm not an experienced cw operator so I'm rather relying on feedback to know if it is useful.  Once the keyboard stuff works well enough I'l have a go at adding sidetone and a key interface.

I can see the 'tape' model has the advantage that the radio can fill in the gaps better if a packet arrives late, it does not look like much work to add this mode to what I'm already doing.

73 Alan M0NNB

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

Ah,

 

Having thought about this for a while I was going to suggest that the Console program generates the CW signal. In my case I have HL2, Pluto, Lime, Ettus hardware to support. I’ll probably write all this into an extension program with CW memories etc.

 

Generating dot / dash bits is obviously easy as well.

 

With the ANAN solution there’s no issue with latency as the audio can be played via speakers / phones connected to ANAN. As this isn’t the case with all hardware then generating CW in the console solves this.

 

Simon Brown, G4ELI

https://www.sdr-radio.com

[Steve Haynal]

Hi Simon,

I think the initial focus here is remote CW operation. The ANAN solution doesn't work if the ANAN radio is in another room. I'd like to see how well we can make a remote solution work. I think that keyboard CW entry will not have annoying latency for the user even if the sidetone is generated on the PC and is 10s of ms delayed. Paddle or key use at the PC has the biggest latency challenge for key-to-sidetone and I think will require some of the low latency setups mentioned in my original post. If we can make both keyboard and PC paddle/key use work well, then there is a single solution for both local and remote operation, as well as multiple radios.

73,

Steve

kf7o

[Alan Hopper]

Hi Group,

 Just uploaded spark2.0.1.0beta3 to http://www.ihopper.org/radio/previews.htm This has reduced latency from keypress to tx output for keyboard cw, I don't think the tx side can get much faster other than shrinking the hl2 tx buffer (but I could be wrong).  The latency on rx (and duplex monitoring) has been tweaked a bit but there is still room for improvement there.

73 Alan M0NNB

[Alan Hopper]

Hi Steve and Group,

SparkSDR 2.0.2.0beta4  http://www.ihopper.org/radio/previews.htm has some tweaks to the keyboard cw experiment.  In doing this I also added support for the ptt signal from the HL2, this message is also sent back when the hardware key input is used. The software tries to use this both to switch between rx and tx audio agcs and also to set the rf preamp gain. I suspect with hardware keying the lna stuff maybe less than perfect because of the round trip delay. The protocol spec does mention separate tx and rx attenuator settings(added 2014), I wonder if HL2 should use them (correct me if it already does). I have also wondered about just ignoring the hardware ptt signal in cw mode.

73 Alan M0NNB

[Steve Haynal]

Hi Alan,

I tried SparkSDR 2.0.2.0beta4 today and was very impressed. I was able to start the CQ macro and run up to 80 wpm. I could hear myself reasonably well even given the latency of the round trip to the HL2. I don't think this latency will matter for keyboard entry. Only the macros worked for me (no keyboard entry yet) but I think that is the state of this beta or am I missing something?

The HL2 does not use the two TX and RX attenuator settings. I saw this too while working on PowerSDR CWX support. I think it would be good to support this. I think the issue reported by JI1UDD of reduced sensitivity after TX can be solved this way. I'll add it in with the CWX support. I'm also looking at adding some hooks for software to reduce the buffer latencies in the HL2 if there is a good network connection.

I have CWX mostly integrated in my gateware. I hope to finish testing and release soon. I am also working on some issues for the IO board beta testers.

73,

Steve

kf7o

[Alan Hopper]

Hi Steve,

good to know some of it works,  keyboard should work once you click in the lower text box.  Good news on the tx/rx gain stuff, it has always been a bit of a guessing game when to switch them.  I'll look at sidetone next and then interfacing to a key, I have played with triggering cw with a midi piano keyboard, it works but my cw skills are so bad I've no idea if it is really usable.

73 Alan M0NNB

[Alan Hopper]

Hi Steve,

I've just ordered a pro micro and an esp32 to experiment with cw midi input, If you have any working code I'd love to try it.  One thought was to use bluetooth on the esp32 so the key could be wireless.

73 Alan M0NNB

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

Wow,

 

MIDI is always an option, I was wondering whether there’s a USB / HID board available. In my case there’s a demand for CW support with Pluto and Lime on the Es’Hail 2 satellite, so I’ll have to write an iambic keyer, just not sure how I’ll interface the paddles to the computer.

 

Simon Brown, G4ELI

https://www.sdr-radio.com

 

From: 'Alan Hopper' via Hermes-Lite <herme...@googlegroups.com>
Sent: 03 February 2020 12:10
To: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: CWX/Keyboard CW

 

Hi Steve,

[Steve Haynal]

Hi Alan,

I'll try to send some code soon. I'm just using one of the existing USB MIDI libraries:

https://github.com/BlokasLabs/usbmidi

I'd like to add code so that a jumper can switch between USB MIDI and USB serial. As I pointed to before, PowerSDR and other software already has method to connect key to serial which would be good to support too.

Bluetooth on the esp32 is an interesting idea. What latency do you expect?

73,

Steve

kf7o

[Alan Hopper]

Hi Steve,

don't rush with the code, I have something I can test with.  Once my boards turn up I was going to measure latency and jitter with a scope on the key and the audio output, I'll try with bluetooth and see what happens.  I have sidetone working on midi input now (not released) and by ear from the piano keyboard it seems quick.  I've been looking at improving the case of a key plugged into the radio and using the software for sidetone. I notice the protocol has dit and dah fed back next to the ptt signal, I have not yet worked out their purpose or what happens with a keyer or straight key, a bit that simply goes high when a cw carrier is being sent could take a fast path in the software to sidetone generation.

73 Alan M0NNB

[Alan Hopper]

Hi Group,

I've just uploaded SparkSDR 2.0.2.0beta7 to http://www.ihopper.org/radio/previews.htm this now has midi key input and sidetone both for midi input and a key or keyer plugged into the HL2. There are a few more things I can do to reduce latency but I'm interested to know if this is usable.

73 Alan M0NNB

[Steve Haynal]

Hi Alan,

This sounds great. I will try to test it out this weekend.

With CWX I have learned that the dot and dash input are never used, so no keyer in the HL2 is required. I also ran into some problems with how I started doing TX buffering. I had it setup to drain the TX buffer when PTT was not set so that we could always start with a known buffer and latency when PTT became true. This was to reduce TX glitches, but does not work with CWX where the time nothing is sent matters for spacing.

73,

Steve

kf7o

[Alan Hopper]

Hi Steve and All,

the very very basic arduino midi key interface is here https://github.com/ahopper/sparkey I run it on the pro micro board (leonardo clone) that Steve linked to above. A straight key can be connected to inputs 2 or 3 and in the Spark midi setup enter the control id you see when pressing the key in the control column and set the action to 'Key'.

73 Alan M0NNB

[PA3GSB]

Hi all

I have been reading through some of the reactions of doing remote CW.

Most important is  the latency....the gateware does contain buffers running in the normal flow.

But is was tinking about using the PING protocol and use the payload of these packets to generate directly in the gateware the signal..... without a min. of buffering.

Ping is  already in the firmware present... so no need for additonal udp ports and buffering.

Could this be an approach?

73 Johan

PA3GSB

[Ronald Nicholson]

Remote CW over a wired network?  Or remote over WiFi or WAN?  You might want to gather some statistics on your network's Ping latency variation.

Over WiFi and WAN I often see a huge amount of jitter in a long run of Ping times: Jumps of a dozen mS or more.  A dot at 30 WPM is only 40 mS in duration, so any network latency jitter that measures as a significant fraction of 40 mS might distort Morse Code character timing in an annoying manner.

My plan for low latency CW is to use a key wired directly to a GPIO on a Raspberry Pi that is directly ethernet cabled to the same network router as is the Hermes Lite 2 and running its UDP link.  When  remote, I think I'll only be able to do clean CW via computer keyboard to an SDR app, with much higher latency.

Ron

N6YWU

------

[Alan Hopper]

Hi Group,

just been playing with the 69.1 firmware, with one channel of a scope on my midi key switch and another channel on the rf output I measure a steady 18ms between key and rf using modulated iq and 12ms using the cwx mode.  The latest spark with cwx support is here http://www.ihopper.org/radio/previews.htm 2.0.2.0beta10 - The next task is to tweak the sidetone latency, it is already much better than using the duplex feedback from the radio but plenty of room for improvement.

73 Alan M0NNB

[Steve Haynal]

Hi Alan,

Thanks for the CWX addition to your software. I am surprised you are seeing lower latency with cwx as both the audio and cwx signal go through the same buffer. Is it because there is less processing in the SparkSDR side?

I was looking at packet timing and jitter in wireshark and both SparkSDR and Quisk are the best I saw. In the 69p1 gateware the TX buffer latency is now ~10ms. Once it is 5ms full, the gateware waits another 5ms and then starts using the contents. This is to avoid the situation with linhpsdr or PowerSDR where the first burst of packets fills 20 ms, not quite half of the buffer, and the next almost overflows the buffer. I suspect that with the good timing of SparkSDR and a good network, we can reduce the latency to ~5 ms or ~udp PC2HL2 packets. I still plan to add this control. For an arriving key on to the CW RTL, there is ~8ms for the TX power to turn on and relays to settle, then the signal starts with a 4 ms ramp up. There is also a 4ms ramp down at the end. CWX which passes through the buffer should add another 10ms of latency.

I was thinking CWX is primarily useful for PowerSDR users as that is what is supported by PowerSDR. I thought you'd have more control over shaping and spacing using your IQ method. I did not implement the dot/dash bits of CWX. Only the lsb CWX bit does anything. I didn't see PowerSDR every using the dot/dash bits as timing can become tricky. This also simplifies the gateware as no keyer is required (I did port that back for those interested). 

73,

Steve

kf7o

[Steve Haynal]

Hi Johann and Ron,

Ping could work, but I don't see the expense of opening up another port as too high and think a separate port could be cleaner. See eth_port in dsopenhpsdr1.v. We would only need to add some states selected by the different eth_port value to handle some simple extensions.

Ron, what you are doing sounds very similar to the CW support I think someone added to the radioberry.

https://github.com/pa3gsb/Radioberry-2.x/wiki/piHPSDR-running-CW-mode#protocol-1

73,

Steve

kf7o

[Alan Hopper]

Hi Steve,

My iq method may be being delayed by some code in spark that ramps all signals on ptt, I need to turn this off for cw and other clean generated signals. Does the upconversion and filtering in the radio add any group delay to the iq signal vs cwx?

 I wonder if the cwx method could use lower buffer latency than the iq method as buffer under-run would just just create jitter but not the nasty spikes of interrupted iq, ie it can assume the last key state.  It is all an experiment at the moment, I'll certainly keep the iq method as it will work with any radio and may drop the cwx if it ends up being the same.  I understand that cwx has to be kept as it is to work with powersdr.  

I assume the ~8ms for tx to turn on also applies to direct key plugged into hl2, this might explain how I see ~10ms extra latency on sidetone triggered from the radio compared to that triggered from midi. I use the dah bit from the radio to trigger sidetone if keyed from the radio, is this bit delayed by the 8ms?

73 Alan M0NNB

[Steve Haynal]

Hi Alan,

The upconversion and filtering will add some delay, but it is well under 1ms. I haven't computed it but estimate it is in the 10-20us range.

Yes, no matter the origin, everything is delayed by at least 8ms to allow for the TR and filter relays to settle when going to TX.

I tried setting the return PTT true whenever the TX is on, but then I see the problem with Quisk that TX always stays on. There is a feedback loop with Quisk. I want to make sure every packet that was intended to transmit goes out, so only stop when the PC-to-HL2 PTT is turned off. But since Quisk is setting the PC-to-HL2 PTT based on the HL2-to-PC PTT we see this problem. I think Quisk does this so that the external PTT switch on the HL2 will force the software to transmit. What do you think should be done here?

73,

Steve

kf7o

[Alan Hopper]

Hi Steve,

I suspect recent versions of spark might also have the same loop issue with ptt if on for all txs, maybe it should be turned on with hw ptt or key and turned off by tx going off. The software needs to only see it if triggered by the hardware.

If the dah back from the radio is delayed by the 8ms could this be changed? It would help make sidetone on the pc for a key plugged into the radio better.

73 Alan M0NNB 

[Steve Haynal]

Hi Alan,

Bit [2] of the return C0 is connected to the ext CW key input after a 6.5ms debounce. It doesn't have the 8ms applied. The 6.5ms debounce is arbitrary and we may be able to reduce that. Some experts may know the typical debounce required for a key. Or we can make it "debounce to go off" so that on is always immediate.

This bit is only set for the external CW key input at the HL2. Do you want this set for other sources of CW too? 

73,

Steve

kf7o

[Steve Haynal]

Hi Group,

In the Radioartisan group, there is a recent thread about using the Pro Micro as a K3NG keyer. W6IPA has done some interesting work and posted some pictures. I don't think we need a keyer in the arduino, but the interfacing of a key or paddle to the PC and the PCB he made is right along the lines I've been thinking:

https://groups.io/g/radioartisan/topic/arduino_micro_pro/71166797

73,

Steve

kf7o

[Alan Hopper]

Hi Steve,

I think this should be just for external key input, there would be loop issues like the ptt otherwise.

73 Alan M0NNB

[Alan Hopper]

Hi Steve,

that looks neat. Whilst I agree we should be able to make the keyer and side tone work in the pc, there is an attraction to doing it in the arduino(or whatever), the side tone can then be faultless. For the case of headphones an analog audio mixer could be built in so pc audio is sent via the keyer  and mixed with the side tone.  The same setup could also be used directly plugged into the radio.

73 Alan M0NNB

[Alan Hopper]

Hi Group,
just been playing with audio code and am getting a reliable 5 to 7ms latency from arduino midi switch to sidetone audio out on an old windows box with built in audio using wasapi, so this approach is looking possible.

73 Alan M0NNB

[Alan Hopper]

Hi Steve,

assuming the key line is not noisy and only has switch bounce, I would have though triggering both ways instantly as long as the previous change of state was older than Xms would work.

73 Alan

On Friday, February 14, 2020 at 4:08:40 AM UTC, Steve Haynal wrote:

Hi Alan,

[Joe LB1HI]

Hi,
     I noticed the inconvenience that occurs under Linux (recent Mint 19) and under Windows. In CWX when setting Semi Break-in is set to a higher value. The TX relay remains in the TX position by the set time value since the last CW sign is sent. (Rely stops clicking to the CW rhythm). However, openHPSDR software visual still "clicks", switching from TX to receiving and back to the rhythm of CW characters.
(I noticed on YouTube videos that this phenomenon does not occur in other users using Annan10 and openHPSDR mRX 3.4.9)
The solution to this CWX problem is not that important if we find another solution to enable CW keying in accordance with the Hermes Lite ideology. That is, remotely (Ethernet etc.). A solution that would cover all of the most commonly used software such as OpenHPSDR, Spark, Console V3, Quisk etc.

73, Jozef, lb1hi 

[PA3GSB]

I was looking after a long time to the CW functionality in pihpsdr using the CW gpio pins.

I found an other nice option (using pihpsdr) in cw mode to use the gpio lib to set the gpio pins for cw.

By using a small program it is easy to type some text which can be transmitted via the cw pins

I think the following program can be  used as basic setup: http://abyz.me.uk/rpi/pigpio/code/morse_code_py.zip

this can be done locally but also via pigpio socket interface.

Just to inform you about the possiblity.

73 Johan

PA3GSB

[James Ahlstrom]

Hello Alan and Group,

I measured my old sidetone code for CW. The delay from key closure to sidetone audio output is 170 msec. This is very different from your 5 msec result, but I think we are measuring different things. I am replacing radio samples with the sidetone. The radio samples playback buffer is large to allow for the irregular receipt of samples from various hardware, so the sidetone will not be heard until it works its way through the buffer. I could certainly reduce this buffer and track down any other unnecessary delays, but I don't think I can reduce it below about 50 msec. There is a conflict between the requirements of radio sound playback (large buffer) and sidetone playback (small buffer is OK).

At the moment I don't think it is possible to use the normal radio sound playback path for the sidetone. Note that this has nothing to do with faster sound drivers. We could use an additional sound card optimized for low latency for sidetone, but I am not enthusiastic.

If anyone can think of some tricks to switch buffer size on the fly, please let us know.

On Friday, February 14, 2020 at 2:02:48 PM UTC-5, Alan Hopper wrote:

Hi Group,
just been playing with audio code and am getting a reliable 5 to 7ms latency from arduino midi switch to sidetone audio out on an old windows box with built in audio using wasapi, so this approach is looking possible.

73 Alan M0NNB

[Alan Hopper]

Hi Jim,

I play a number of tricks:-

sidetone triggered from the radio key is detected when the udp packet is unpacked and a key up or key down signal is sent direct to my audio callback loop so it bypasses all processing and buffering.

A similar thing happens for midi key input.

The sidetone is generated in the audio callback( including shaping ) and added to any other audio.

My currentl released version does all this but has quite long basic audio buffers I should release a win 10 version that fixes that. My 5ms tests were with the audio device in exclusive mode, I hope I now have similar performance in shared mode.

73 Alan M0NNB 

[James Ahlstrom]

Hello Alan,

A very fine design. I look forward to test results using the radio play audio path.

Jim

N2ADR

[James Ahlstrom]

Hello Steve and group,

As you have no doubt guessed, I am back from my ski trips. I was gone most of the time from January 22 to March 10. Shortly after I got back they started closing all the ski areas due to covid-19. I came back with a cold, and am just getting over it. But there is little to do as everything has been closed for the virus. So I am doing ham radio.

As Steve pointed out, you can connect paddles to a PC using a USB-to-serial port adapter. But there is an issue. The PC must turn the DTR signal True as it is used as a power source, and it goes to paddle common. My DTR is +6 volts. The paddles are connected to DSR and CTS. These are normally open circuit, but are connected to DTR when closed. The assumption is that open circuit DSR and CTS counts as False. Any voltage +3 to +25 is True. The RS-232 standard actually wants -3 to -25 volts for False.

The real issue is that you could not use this scheme to connect a keyer (like WinKeyer) or most other switches because one side of the switch is grounded. You could connect a keyer directly to the HL2 hardware, but we are talking about remote CW. If you want to write the keyer in the PC and only need paddles, this is no problem. But writing a keyer is difficult. Just look at all the options a real-world keyer offers.

I am thinking of making a small serial port board with an interface that tolerates one switch side to be grounded. But does anyone know of one that already exists?

Jim

N2ADR

[Steve Haynal]

Hi Jim,

Welcome back and hope you feel better. I don't think people are using true RS-232 signaling and voltages. I suspect most of the cheap USB to serial adapters are operating out of spec. There is a lot of interesting information at this site:

http://qrqcwnet.ning.com/

I still want to build a small arduino-based USB gizmoo that converts keyer presses into MIDI or UART data for the PC. I think Alan has done something like this.

To bypass all the audio latency in a program like Quisk, I still think JACK is the way to go. The keyer program is a separate program. The audio is mixed by jack with low latency. Another ethernet port number is used to send the CW data to the HL2. This is still on the to do list.

Have you ever considered native JACK audio IO for Quisk? Here is an example:

https://github.com/n1gp/iambic-keyer

73,

Steve

kf7o

[Roger Critchlow]

I attach a picture of my "low commitment" usb-midi key.  Just a 170 pt solderless breadboard, a microprocessor with breadboard pins, and a breadboard friendly stereo jack.  Mine uses a Teensy LC MPU, but any of the small breadboardable MPUs could wire up the same way.  The source for the Teensy version is in https://github.com/recri/keyer/tree/master/embedded/MidiKeys.

I looked at sending keyer state via serial, because the Teensy can present a composite MIDI+Serial interface, but it appears that the USB standard for serial doesn't make any provision for sending CTS from the device to the host.  DTR and RTS from the host, DSR, RI, and DCD from the device are all covered, but nothing about CTS.  The FTDI serial chip sends DTR/RTS/DSR/CTS no problem, but it uses a vendor specific USB class.

-- 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/bd8fde01-58d9-4652-a756-9f8e0dfe7c7d%40googlegroups.com.

[James Ahlstrom]

Hello Roger,

It would be interesting to write a general purpose program for an Arduino device that connects to a PC with USB and sends key presses, receives logic data and perhaps serial data. But I am not focused on this because MCUs require programming, and I am not sure users will be able to program the device. I wanted something dead simple that just connects paddles or a WinKeyer to a PC without fuss.

Jim

N2ADR

[James Ahlstrom]

Hello Steve and Group,

This discusses keyers and sidetone latency. I will write a separate note on PC interfaces.

Quisk supports four sound systems, DirectX, Alsa, PulseAudio and PortAudio. To do anything about latency, I would have to re-write all four. From a customer support point of view, sound systems are a sore point. I constantly get questions about how to make sound work. This is especially true when using sound devices to send samples back and forth to digital programs like fldigi and WSJT-X.

I think Quisk can use JACK now because JACK supports ALSA devices. I can use JACK to mix Quisk radio audio with the sidetone produced by a separate keyer program. But I need the keyer program, another sound device for the keyer program and a working JACK setup. Then I need a way to read the key state of the keyer program and use it to turn on CWX.

I know you are fond of MIDI. But a user must set up a working MIDI. And AFAIK MIDI is designed around a sequencer of notes and is not really designed to produce arbitrary length tones or mix them with foreign output.

To see what is required for a keyer program look at WinKeyer and its ecosystem. WinKeyer supports its own GUI with a blizzard of options. For example, it can change the inter-word spacing from 7 dits to 6 dits to speed up contest exchanges. There are six keying modes. There are keyboard macros and prosign mappings. You can attach separate programs to provide logging and decode the CW to text. Read the WinKeyer Manual at http://k1el.tripod.com/files/WKUSB_Manual_v1.1.pdf and see if we should write that. And keyers provide their own sidetone, so our latency problem goes away.

To provide a serious CW keyer experience for our users, I think we should figure out how to attach to the various keyers that already exist and not re-invent the wheel.

Jim

N2ADR

[James Ahlstrom]

Hello Steve and Group,

I am looking at attaching a WinKeyer or similar to a PC and using it to support CW on a remote HL2 using CWX. Currently WinKeyer can attach to a local HL2 without problems.

This requires an interface to USB that supports an open collector switch to ground. I have a design using a USB-Serial cable and a hex inverter. It can support several input switches. The serial port outputs are available on  pads, but are weak arbitrary voltages. Recall that a serial port does not offer 5 volt power like USB.

Do you have a wish list of features you would like such an interface to have? I will see if I can add them. But I would like to avoid an MCU because of the extra complexity.

Jim

N2ADR

[Joe LB1HI]

Hi, Jim and all the group.

I fully agree with you, Jim. This is exactly what probably most people are waiting for.

The ability to work comfortably CW remote. Where the key manipulator is with us and the computer away from HL2. (just like the manipulator, this also applies to CW DX software or CW contests). In a remote location, whether it is a separate room in the same house or somewhere far through the Internet.

It will probably set more requirements and challenges through the Internet than through the local LAN due to parameters such as delay and transfer.

Once again, I want to say words of appreciation to all involved software developers contributing to the development of the Software Defined Radio HL2 project. As the name suggests, the software is an integral part.

73, Joe LB1HI

PS. One would like to say that it would be nice if this technology soon entered the radioshack accessory more intensively (it is already but not much and mainly commercially) and it could be called, for example, SDA =  Software-defined accessories, or SDCMC = Sofware defined control and management center Hi :-)

[Steve Haynal]

Hi Roger,

That is good to know. I didn't now the Arduino serial did not support the other DTR/RTS, etc. signals.

73,

Steve

kf7o

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

[Steve Haynal]

Hi Jim,

The WinKeyer has come up before and looks like a very easy to use option. I think it would be great if Quisk supported that. I'm not a big CW user so don't have a big wish list. Maybe others on this list do. I'm interested in something that still allows for the radio to be remote. Let me know if you need any changes or additions to the gateware to support this.

The little Arduinos with USB we've been playing with only require a computer and USB cable to program plus the free Arduino software. I don't consider it too difficult, but some may find programming challenging. MIDI is a pretty simple protocol which sends note on or off information. Each note is assigned a different number. You can use two notes for dash or dot on or off. I'm still interested in this direction but haven't spent much time. Maybe if you add support for the WinKeyer, we can try to make the Arduino use the same or similar protocol and leverage your work. This would provide those with a key a <$10 solution.

73,

Steve

kf7o

[Matthew]

Jim,

Do you envisage using a WinKeyer (or similar) to do the Iambic part and you will take the simple key up, key down output from the keyer? This would allow people to use their favourite keyer and you won't need to support it (Iambic A, Iambic B, ultimatic, Iambic A and B come in sub-variants that people get used to too).

I have been working on a version of linhpsdr to allow logging software macros and keyboard cw to key the HL2 (via the cwx functionality in firmware 69). I plan to expand this into hardware key support. I have built this around a modified version of cwdaemon. Cwdaemon users historically have had to customise their linux kernel to combat latency problems (granted, this is mainly around PC keying a rig, not paddle keying PC). I have ruled out any kernel modifications. From my testing with a scope and USB serial adapter, I haven't seen a need for this. My only concern is if different brands of USB serial adapters could behave differently. I feel you pain with supporting 4 different sound systems. Similar issues could occur supporting numerous USB serial adapters (depending on the hardware approach taken).

At the core of cwdaemon is libcw http://unixcw.sourceforge.net/. I have had to tweak this library as it didn't seem to function properly anymore. However, there are examples and code within this that have given me some ideas to experiment with. Specifically, making a mouse behave as a paddle. From the little experimenting I have done, I am not convinced Pulseaudio will suffice for low latency sidetone from a hardware key.

Getting a common method to work on all Linux, Windows and Mac is certainly a challenge. Alan has previously queried using hamlib cw functionality to provide a common method for all operating systems and SDR software. I was pondering over this yesterday and I think it warrants more investigation.

Most of my discussion above is a step ahead of your discussion. For me the most important part is lowest latency from key down to producing sidetone. We could cheat and mix sidetone and SDR audio away from the PC, but I like the technical challenge of this in software.

73 Matthew M5EVT.

[James Ahlstrom]

Hello Matthew,

I plan to create an interface board to be used with a common USB-Serial adapter. It has three RCA phono jacks with the shell ground. Grounding the center terminals sets DSR, CTS and one additional serial signal. A user could use it to attach paddles (two jacks), a PTT foot switch, or the keyed output from Winkeyer. It is up to the PC program to make sense of the inputs.

For Quisk, the key up/down output of Winkeyer will just key the HL2 using CWX. There is no iambic keyer in Quisk or the gateware.

Jim

N2ADR

[Don Solberg]

I have been using Winkeyer with my HL2 and it works very well, both with a paddle and with an external application that interfaces with WinKeyer.  I use MRP40.  This is an excellent solution for a "local" HR2.  

If you want to have the HL2 remote, K1EL offers a solution with remote Winkeyer  https://www.hamcrafters2.com/WKremoteX.html

This requires a WinKeyer connected to the radio and another connected to the PC.  I used this for several years when I was operating my entire station remotely, 200 miles away.  The side tone is local and they keying is excellent.  This is a little pricey, but it works out of the box.

73,

Don

K9AQ

[Don Solberg]

[Matthew]

I would suggest considering a non-cwx route. Alan did this in SparkSDR, I did some testing at fast CW speeds in the SparkSDR Linux version and it works well. The problem with cwx method is you are tied to Hermes or Hermes Lite 2. If you are trying to support radios beyond these, you would implement the "audio" method anyway? Plus, with generating the sidetone in software for the cwx method, you have done most of the "work" anyway. The unixcw library I linked above produces nice sidetone, but catching the SIGINT for the end of a note and supporting it across different sound systems has clearly proved problematic for the developers. With the "audio" method, catching and acting upon the SIGINT is less critical. My testing so far with implementing cwx in linhpsdr doesn't convince me it offers any great benefit. But it is an interesting technical exercise nonetheless!

The only problem I envisage with your described approach is that if I use logging software with macros, I often change CW speed using page up/page down from the keyboard. I will also mix and match between macros and paddle. So I would need a USB connection into the WinKeyer to control CW speed (in addition to the USB connection from the key out of the WinKeyer). This would also likely be the routing for keyboard cw. It seems a little odd to use external hardware to pass a signal to another piece of software! You could route logging software keyboard cw through hamlib, but then you need to action and make decisions on 2 different sources of CW keying.

Interesting technical challenges.

73 Matthew M5EVT.

[Ronald Nicholson]

If you want the USB key interface dongle to work with iPads and iPhones, then it needs to use the MIDI protocol, not serial.  iOS comes with built-in USB MIDI support; but Apple blocks access to the serial port USB profile on iOS devices.  Macs can use either MIDI or USB serial.

I've got a Teensy LC on order.  When I get it, I'll run some keying latency experiments on iOS, iPadOS, and macOS.

[James Ahlstrom]

Hello Matthew,

On Sunday, March 22, 2020 at 10:43:56 AM UTC-4, Matthew wrote:

I would suggest considering a non-cwx route. Alan did this in SparkSDR

Yes, sending shaped CW as an audio signal to be transmitted as SSB is an option. I don't know if it is better than CWX. I envision the "audio signal" to be at zero hertz. A 700 hertz tone would be offset from the Tx frequency by 700 hertz.

 

Plus, with generating the sidetone in software for the cwx method, you have done most of the "work" anyway.

I would not generate any sidetone. It is up to WinKeyer to generate a sidetone somehow. It must be doing this for "normal" radios like Icom, Kenwood etc.

 

The only problem I envisage with your described approach is that if I use logging software with macros, I often change CW speed using page up/page down from the keyboard. I will also mix and match between macros and paddle. So I would need a USB connection into the WinKeyer to control CW speed (in addition to the USB connection from the key out of the WinKeyer).

Yes, a WinKeyer always has a USB connection to the PC to support keying speed, keyboard CW and logging software. In my proposed scheme, the paddles connect to the WinKeyer as usual, not to the PC. The extra serial interface connects to the keyed output of the WinKeyer, the connection that usually goes to the rig. Quisk would read raw key up/down information from this and use it to key the remote HL2, and just act as a dumb switch.

Yes, it is odd to have a software loop through two serial ports. It would be nice if WinKeyer made raw key up/down available to Quisk from its usual USB connection. Then I would not need the interface board.  But AFAIK, it does not, so I am stuck with an extra serial interface that must tolerate one side grounded.

Jim

N2ADR

[Roger Critchlow]

Jim --

I can agree, the hardware may be low commitment, but getting anyone to install an IDE to build software for a microprocessor is a very uphill slog.  I could publish hex files, but you'd still need to install the IDE to get the program to flash the hexfile, and you'd need to get the right hexfile for your Teensy, since the MidiKey can run on 5 different flavors of Teensy board.  At least when you build the IDE will tell you if you've got the right flavor connected to the USB port.  So I guess I need to go into the 

My reason for doing this with MIDI is, first of all, that it is a universally recognized time critical protocol.  Every platform that implements MIDI does it with the lowest latency possible, if they screw up then the musicians make fun of them.  Maybe you can get a USB-HID interface to run as fast, maybe you can get an RS232 or printer port signal reflected into a user program as fast, maybe you can read Raspberry PI GPIO into a user program as fast.  I just let ALSA bridge MIDI events into Jack where they arrive with sample accurate timing in the real time thread that is processing samples at low latency.   MIDI note on/off events are logic channels with sample accurate transitions.

But that said, I don't see how you could make it work out as neatly in quisk.

-- 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/28a1d6d8-7a59-41ab-8af5-60fe9ed7878e%40googlegroups.com.

[Alan Hopper]

Hi All,

there are many options here and I find myself jumping between them.  It think it is possible to use winkeyer with spark at the moment if its key output is connected to midi via https://github.com/ahopper/sparkey on a pro micro or any other i/o to midi device. This could be true for any keyer with keyup/down output. I'd be very interested to hear how well this works from anyone in a position to try.  I don't have the cw skills to know what is useable or not, I was planning to sit down with someone from the local club to get some feedback but not a wise idea at the moment.  I suspect many of the microcontroller based keyers could be tweaked to give a midi output and or serial. Like Jim I don't want to get into writing a full blown keyer (and am not qualified to) I may write a simple one for my own satisfaction and education as one aim for this period of isolation is to master cw.  I'm favouring midi over serial at the moment purely as I already have midi support in Spark, if serial proves to have advantages or if existing keyers can be tweaked to generate just serial, I'll probably add it.

73 Alan M0NNB

To unsubscribe from this group and stop receiving emails from it, send an email to herme...@googlegroups.com.

[Alan Hopper]

Hi all,

a thought to make it simpler to get going with a micro version is to build the programmer into the sdr software or a simple config app using something like https://github.com/twinearthsoftware/ArduinoSketchUploader so no ide to install.

73 Alan M0NNB

On Sunday, March 22, 2020 at 4:36:55 PM UTC, Roger Critchlow wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to herme...@googlegroups.com.

[Matthew]

Alan,

I would like to try this out. If I get a Leonardo (or clone), can I simply plug into the USB socket and Spark will pick it up as a midi device in Linux? My experience of Midi is mostly based around DIN sockets and running Jack servers for music purposes.

I have a K3NG based keyer and I dislike the buzzer sidetone from it, so I am keen to explore sidetone from the PC.

Alan, if you would like a CW sked on HF, I am more than happy to go as slow as you like for practice (I sat a 5 wpm exam). I can do all HF bands and 80m in the evening should work. PM me if you wish to. We could have possibly the first HL2 to HL2 cw qso?

73 Matthew M5EVT.

[Alan Hopper]

Mathew,

it should work, I haven't tried on linux but the libary I'm using is linux friendly. No one has reported a problem, I'll try and find some time to test on linux.  I shall set a sked as a target, not quite ready yet, thanks.

73 Alan M0NNB

[Joe LB1HI]

Hi all,
Everything has been repaired and works properly. It's just a matter of setting in the Open HPSDR software. :-)

73, Joe lb1hi




On Wednesday, February 19, 2020 at 4:03:45 PM UTC+1, Joe LB1HI wrote:

Hi,
     I noticed the inconvenience that occurs under Linux (recent Mint 19) and under Windows. In CWX when setting Semi Break-in is set to a higher value. The TX relay remains in the TX position by the set time value since the last CW sign is sent. (Rely stops clicking to the CW rhythm). However, openHPSDR software visual still "clicks", switching from TX to receiving and back to the rhythm of CW characters.
(I noticed on YouTube videos that this phenomenon does not occur in other users using Annan10 and openHPSDR mRX 3.4.9)
The solution to this CWX problem is not that important if we find another solution to enable CW keying in accordance with the Hermes Lite ideology. That is, remotely (Ethernet etc.). A solution that would cover all of the most commonly used software such as OpenHPSDR, Spark, Console V3, Quisk etc.

73, Jozef, lb1hi 

[Matthew]

Alan,

Good news! My Leonardo board arrived and I have a working concept on the desk. Paddle -> nanoKeyer -> Arduino (running sparkey) -> SparkSDR on linux.

I'm not very reliable with a paddle over 25 wpm. I spent a bit of time warming up with a practice oscillator at 30 wpm to get my timing right. I then switched over to SparkSDR keying and I honestly could notice a difference (e.g. any latency). Perhaps some of the QRQ paddle folks could find something relating to timing, but I think this is a perfect solution for 99% of the folk who use a paddle.

I don't really like the idea of the 2 USB connections to allow a mix of keyboard CW and paddle CW (useful for dxing/contesting). One idea is that I write a keyer app on the Arduino and SparkSDR would talk to the keyer via midi to change speed. I'll give this some more thought.

73 Matthew M5EVT.

[Alan Hopper]

Hi Matthew,

that sounds very promising especially as I have not minimised the audio buffer size on linux yet.  Yep a keyer in the arduino would be neat or getting midi from an existing keyer, I'll could certainly add controls to spark to send stuff back to the keyer . I wonder if it is worth tempting the authors of the better keyers that this is a growing market.  For my own use I'm tempted to add a couple of knobs and switches to the arduino.  I'm rather hoping someone else will take up the challenge of making a sdr/midi friendly keyer.  Programming the arduino from spark also looks fairly easy to do.

Thanks for this.

73 Alan M0NNB

[Matthew]

DB9MAT has already done some work on probably exactly what you describe in hardware terms:

https://www.dropbox.com/s/g6rj2y3m1nsj8rb/GiantKnob.pdf?dl=0

https://pbs.twimg.com/media/EEwTgvwWkAMoOWU.jpg:small

I started programming AVRs using assembler, then moving to C for AVRs felt like cheating. This sort of mentality has meant I've got on with Arduinos! I've got quite a large collection of useful AVR C code I've written over the years for various homebrew projects, including a full blown keyer that does pretty much everything this application would need, I just lack the MIDI. A quick search did show up some AVR MIDI libraries... Too many projects, I really did want to start building/designing a remote controlled receive antenna phasing system next...

73 Matthew M5EVT.

[Alan Hopper]

Hi Matthew,

I know exactly what you mean, I've never really got the arduino stuff when you can have the full visual studio avr experience, that being said tweaking an arduino example meant sparkey took less time to write than coming up with the name:) I notice nanoKeyer is opensource and runs on an arduino so maybe adding midi could be fairly simple.

73 Alan M0NNB

[Alan Hopper]

Hi Group,

the latest releases of SparkSDR here https://ihopper.org/radio/previews.htm have a couple of tweaks to improve cw especially if you are using the latest firmware. On windows 64 in the audio device drop down boxes each device is repeated with the second one having an 'L' at the end, selecting one of these should give much lower latency on sidetone. With the latest gateware switching between tx and rx should be cleaner.

73 Alan M0NNB