CW - experimental feature

[Matthew]

I am trying to test CW experimental mode. I downloaded the file from here on Friday night: http://www.ihopper.org/radio/previews.htm. I'm running Ubuntu 18.04. I tried a macro (CQ), also just typing text, but all I can hear (listening on another receiver) is the constant tone of the carrier and the radio remains in tx. I have to manually disengage the PTT.

Command prompt has the following text:

Hermes Lite 2
Unsuccessful in setting thread realtime priority
4
ALSA lib pcm.c:8306:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8306:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8306:(snd_pcm_recover) underrun occurred

Perhaps I am doing something wrong?

73 Matthew M5EVT.

[Alan Hopper]

Hi Matthew,

Sorry, I don't think you are doing anything wrong, it looks like my linux publish script is broken, I'll sort it and test from the .tar.gz before publishing it :)

73 Alan M0NNB

[Alan Hopper]

Hi Matthew,

I've just replaced the file again. You should be able to monitor by setting the volume whilst transmitting, this will have the latency of the round trip through the radio.  This version does not have the latency improvements I mentioned on the hl group.

73 Alan M0NNB

On Sunday, January 19, 2020 at 7:04:52 PM UTC, Matthew wrote:

[Matthew]

All working now, thanks.

I'll run some tests over the coming days and report back.

73 Matthew M5EVT

[Matthew]

Alan,

I'm a bit torn if it is best to post this here or on the HL2 group. I settled for here.

I have done some testing tonight with spark2.0.1.0beta3.

First I set up the HL2 on WiFi in a remote room transmitting into a dummy load. I monitored the RF from the shack on another rig. Lacking something more scientific in a quick test, latency "felt" similar to using logging program to key a USB winkeyer into the rig. Certainly nothing that I think would stop working DX pileups and contests.

Now more specific observations:

- Users would probably want the option of setting the sidetone frequency. I prefer 650 Hz, some prefer 500 Hz, most QRP rigs default to 700-750 Hz.

- I would want to be able to click on the peak of a CW signal and hear the cw signal, not click offset by my sidetone frequency.

- Similar for displayed frequency (if using CAT control to QSY to a cluster spot, I want to hit the right frequency).

- I am not sure how to handle a key being connected to the key jack on the HL2. I did this and I was able to TX at the sidetone frequency minus Spark TX f. Some people may wonder why no one is replying if they mix and match between paddle and keyboard.

- I'm not sure if you are using a self written library for the CW and can tweak it? I looked at the transmitted RF waveform on a scope, I measured a rise/fall time of around 9 ms on your waveform. I aim for around 5 ms when I design a CW transmitter. Connecting into the CW jack and using Quisk in CW mode, I observed a rise/fall time of around 5 ms.

- Users may want to change the dit/dah ratio. I would want to change the timings from their current setting. In CQWW some people run with different pronounced different ratios, however, my ear is trained to hear a certain dit/dah ratio.

- I personally wouldn't use any of the macros in Spark for CW. My logging software (tlf and cqrlog) talks to a cwdaemon clone (https://github.com/drewarnett/pywinkeyerdaemon or https://github.com/ok2cqr/winkeyer_server). I think Spark would need to have a cwdaemon server built in to allow this functionality. As far as I know, this is how a lot of (apart from the hardcore ones who use a paddle for 48 hours straight) contesters send CW from their logging software as this handles all the serials numbers and exchanges etc.

- I would want to reduce the CW hang time from the current setting. I imagine everyone will want to tweak this to their taste.

I hope this helps for some feedback. I think this is very promising, but for me interfacing to logging software is key. I imagine for others (the majority?), a paddle is key. But clearly, this is about setting a foundation worth build on and I think you have this.

73 Matthew M5EVT.

[Alan Hopper]

Hi Matthew,

thanks very much for testing, it was not really ready for release but your thread on the hl group tempted an early release.  It is promising that the latency is acceptable which also indicates your solution of an external program would work.

I completely agree with the tuning and clicking and that is on my list.

I have full control of the cw generation so can certainly add those preferences.

Thanks for the logging/keyer links, I'll spend some time understanding how these are used and how to best integrate.

73 Alan M0NNB

[Alan Hopper]

Hi Matthew,

implementing a cwdaemon looks very doable, I guess you will want cat at the same time.  I'd be interested if the cat in the digiu and digil modes has everything needed for your loggers. The multi radio/multi receiver nature of Spark will mean you can have many cwdaemons and virtual cw transceivers at once, I've no idea if there is any use for this.

Is the cwdaemon the norm (windows & pc) or are there other competing approaches?

73 Alan M0NNB

[Matthew]

I'll check out CAT and report back.

I didn't know the answer to cwdaemon and windows. I did a bit of searching and cwdaemon does not appear to be a windows thing. I had a look at some documentation for N1MM, DXlog and Log4OM and as far as I could see from a quickish look, you would have to interface through virtual com ports (yuk!) into SparkSDR.

73 Matthew M5EVT.

[Alan Hopper]

Hi Group,

there is a new experimental release 2.0.2.0beta4 here http://www.ihopper.org/radio/previews.htm There is now just one cw mode rather than cwl and cwh, I could not see a reason for both but am willing to be put right on this. The frequency of the carrier is now that set and is the same as the HL2 hardware cw.  cw tone frequency can now be set.  The rise time is now shorter.

The ptt signal from the radio will now put the software into transmit.

73 Alan M0NNB

[Alan Hopper]

Hi Matthew and Group,

I'm almost there with a cwdaemon interface, In setting cqrlog up for testing I noticed a cw interface option to use Hamlib. Spark uses the tcp rigctl protocol which has a 'b' command to send morse https://www.mankier.com/1/rigctl#Commands-Radio_Commands, I wondered if this is ever used, I don't support the 'b' command at the moment but it should be easy to add.

73 Alan M0NNB

On Tuesday, January 21, 2020 at 7:45:46 PM UTC, Matthew wrote:

[Matthew]

I've grabbed the latest and it is really sounding great. I will be impressed if anyone can send a >14 wpm from a key in the HL2 and using Spark generated sidetone - I gave up after a minute of trying to adjust my brain!

I've always struggled with rigctl/rigctld. Right now I'm in DigiU mode, it tells me port 51111 is the one to use. I've tried rigctl -m 2 -r localhost:51114, but it returns rig_open: error = IO error. If I port scan that port it tells me it is closed. Any pointers?

I'm not aware of any software using the 'b' command.

73 Matthew M5EVT.

[Alan Hopper]

Hi Matthew,

yep the delay on the trip back from the radio needs some tweaking but sidetone at the key is always going to be better, it is a fun challenge to reduce the latency here but not the real answer.

I had trouble getting cqrlog to talk over cat, in the end it worked by putting 127.0.1.1 in host, 51111 in port and selecting 2 Hamlib Net rigctl as radio. rigctl itself is not needed as spark pretends to be rigctl.  This got me to the point where I discovered cqrlog relies on some messages I don't support so no point in trying until I add them.  The 127.0.1.1 is odd (localhost didn't work) I shall try and find out what is happening there.

I now have just about enough understanding of cqrlog so I can test so progress should be quick.

73 Alan M0NNB

[Alan Hopper]

Hi Matthew,

I just uploaded 2.0.1.0beta5( linux only) to http://www.ihopper.org/radio/previews.htm this works for me in cqrlog both using hamlib or cwdaemon as the cw device, in the rig setup you should be able to use localhost and probably port 51111 for the rig and 61111 for cwdaemon in the cw settings.  I had to add a sw hangtime to turn off ptt, at the same time I added a hw hangtime, I'd be interested to know if it works when Steve sends you a hang time capable gateware. cat is now available on all modes so you should be able to change modes from cqrlog.

73 Alan M0NNB

On Sunday, January 26, 2020 at 10:01:32 PM UTC, Matthew wrote:

[Alan Hopper]

Hi Group,

I think I managed to upload everything except the linux file last night! It is there now.

73 Alan M0NNB

[Matthew]

Partial success.

- Cwdaemon works with cqrlog. This is great, pg up and pg down change speed and it seems reliable.

- Cqrlog CAT control frequency read works. Set frequency doesn't work (guessing not implemented?)

- Tlf CAT partially works, TLF can read the RX freq. Set frequency doesn't work. So this appears to suggest CAT behaves similarly between different Linux loggers. This is good. I think all I would use that is missing is set frequency.

- Tlf can send 1 message with cwdaemon, then it appears to send Spark into an odd state. Spark engages PTT from Spark macros, but does not send anything. I can recover from this by changing mode within Spark. Tlf should be in most linux repos for you to test this (sudo apt install tlf should work if Debian). Make a folder, place the following in a text file and name it logcfg.txt:

RULES=cqww
EDITOR=joe
CALL=TEST
TIME_OFFSET=0
TIME_MASTER
NETKEYER
NETKEYERPORT=61111
NETKEYERHOST=127.0.0.1
CWSPEED=25
WEIGHT=1
CQDELAY=10
TXDELAY=2
CLUSTER
BANDMAP=S,900  # skipdupes, 900s livetime
SCOREWINDOW
CHECKWINDOW
PARTIALS
NOB4
CQDELAY=7
MARKERS=tlfmarkers

from a terminal window with this folder as the working directory, type tlf. F1 should send a CQ. This will work once, then Spark goes into this odd mode. I am aware tlf interprets cwdaemon protocol in a certain way (see https://lists.nongnu.org/archive/html/tlf-devel/2019-12/msg00006.html).

I'm still working with Steve re: hang time.

This is a really slick setup now. No cables, no USB to serial adapter, and great interfacing to logging software. I'm guessing the Windows folks will need cwdaemon to appear as a virtual com port. Perhaps wait until someone requests this?

73 Matthew M5EVT.

P.s. you per-empted a feature requested with CW filter high/low lock - thanks.

[Alan Hopper]

Hi Matthew,

that's sounding promising, I can set frequency here, certainly using the band and memory options in trx control, does this not work for you or is there another way to set frequency in cqrlog?

If you run spark from a console it should display any unhandled cat messages with ### in front of them. I'll add some optional logging in the next release so we can capture all the messages.  Thanks for the tlf tips and the link, I've added some code to tidy up the cwdaemon messages from tlf .  I've joined the N1MM group and was planning to sound them out about adding a network interface (rigctl), I really don't want to go down the serial route.

73 Alan M0NNB

[Alan Hopper]

Hi Matthew,

I wonder if I misunderstood, did you mean the cw tone frequency? If so yep it is currently ignored and I'll add it.

73 M0NNB

[Matthew]

Alan,

I have no idea what I was doing last night, but set frequency works in both tlf and cqrlog tonight. I did say earlier I have limited repeatable success with hamlib rigctl(d)! I'll keep an eye on this.

Can't see any need for cw tone frequency control via hamlib. This is a "set and forget" for me, so I would simply set this in SparkSDR.

I'll get my HR50 out and test the whole setup over the weekend for an hour or two on cw for some "soak" testing.

73 Matthew M5EVT.

[Alan Hopper]

Hi Matthew,

lets hope it keeps working:) I've just posted beta6 which may fix cwdaemon on tlf (not tested) and has better logging of cat and cwdaemon messages.  I look forward to the results of the real world test, I'm sure more tweaks will be needed but I feel we are getting somewhere.

73 Alan M0NNB

[f6ehp]

Hi Alan,

I do not practice cw and have not followed everything on this subject, so this post is perhaps already solved -

I just tried CW with an external keyer connected to my HL2 cw input. That works but I get the same issue with Quisk and Spark : TX goes on automatically with the first dit or da, but stays on at the end. With vox on, the relay  beats too quickly.

73 Pascal

[Alan Hopper]

Hi Pascal,

I think someone reported this on the hl group but I can't find it right now, I have a feeling that recent firmware fixes this ( I don't see it here).  The hw hang time slider I've added should be sending the correct message but the current firmware ignores it. I suspect some software tweaking will be needed to the rx-tx-rx transitions.

73 Alan M0NNB

[f6ehp]

Hi Alan,

The 68p4 release published 11 days ago solves this issue. Sorry for this useless post.

Best 73 and thanks again for all.

Pascal

[f6ehp]

I just discover the new CW mode with decoder and cwdaemon..wonderfull, thanks a lot !

Pascal

[Alan Hopper]

Hi Pascal,

please don't expect much from the decoder, it is far from finished ( in honesty I meant to hide it but forgot).  All feedback on cw mode is gratefully received as I don't have enough cw skill/experience to know when I'm getting it right.

73 M0NNB

[Alan Hopper]

Hi Group,

just thought I'd document the current state of cw in Spark, I'll copy into the help for the next release :-

cw mode is enabled by selecting 'Enable Experimental Features' in the settings dialog, you need to restart after changing this.

cw can be sent in a number of ways

1. keyboard - simply set the wpm slider and type into the bottom text box, tx will stop after either the sw hang time or if you press the return key.

 

2. A keyer or straight key connected to midi via https://github.com/ahopper/sparkey or anything else that generates midi. The midi settings need setting so your chosen device triggers the 'key' action.

3. A keyer or straight key connected to the HL2 jack.  

4. From other software using cwdaemon or rigcntrl. Spark pretends to be cwdaemon. For rigcntrl no server is needed and Spark responds to the 'b' , 'KEYSPD', and 'CWPITCH' commands.

Your cw can be monitored by listening to your own signal by turning up the volume whilst transmitting however this creates quite a delay which makes it only useful for slow morse.

There is a separate sidetone volume slider which produdes much lower delay between key and tone, this works for all means of keying.

On windows 64 the audio output device drop down has optiond with an 'L' sufix these should reduce the latency for all means of monitoring.

Best results will be had with the latest gateware in the radio.

There is a cw decoder but it is far from finished.

The cwx checkbox is meant to test another way of generating cw, I don't think this is working properly at the moment so please ignore it.

73 Alan M0NNB

[Max]

Hi Alan

New CW features work very well including the sidetone which seems to have negligible latency, but one small issue....... the sidetone level slider seems to have only two settings, 0 and 1, either on or off. Is that just an error my end or as intended? Would be nice to have a few levels to choose from and preferably continuously adjustable.

Also, not sure why, but in CW mode, keying the TX results in a small power output even with drive slider at zero. Again, is this as expected?

Thanks for looking and 73

Max

[Alan Hopper]

Hi Max,

yep the sidetone slider has a bug, I have fixed it here so it will be ok in the next release. Are you keying the tx from the radio socket, if so you will still get output as the radio drive control is only -7.5db when set to zero and the waveform is generated in the radio when keyed this way, when keyed from the software I adjust the radio drive but also scale the IQ to give a larger range of drive, I also reduce the IQ to 0 when the drive is zero.

73 Alan M0NNB

[Max]

NP Alan. All understood. Yes, keying from the socket. All works well and now also all explained about the residual output. At least I now know this is as intended.

Yes, the sidetone works very well. Read so much on the groups about the difficulty of generating sidetone in software without latency issues but I think you have cracked this, at least for us mere mortals that operate in "human" realms of CW up to around 30 wpm......actually I am not even at that level to receive but I turned the keyer speed well up and it seems pretty good to me in terms of response.

If I ever do want high speed CW via keyboard I would not be operating from front panel...... I have successfully set up MRP40 with audio tone to the audio-in and it works very well, although I personally do not really get much satisfaction out of sending CW about 2-3 times as fast as I can copy by ear...... otherwise to me it just becomes another data mode!

Many thanks

Max

[Alan Hopper]

Hi Group,

I've been exploring the idea of what a fully integrated keyer/ sdr interface might be like and have made a very crude keyer here https://github.com/ahopper/sparkey/tree/iambic as a first step. I've no idea if it is any good as I've never used a keyer before. I'm hoping in the long term we can use one of the existing keyer solutions tweaked for sdr use. This is really just to explore what wants to be done and controlled from the sdr software and how it would interface to loggers etc.  

73 Alan M0NNB

[Karl Heinz Kremer - K5KHK]

Alan, 

your link does not go to the iambic branch (at least not for me, the contents of the INO file are the same as for the "normal" version). I had to change the "Branch" setting from master to iambic to get the modified file. I have not tried it yet, but at least now I know how to find the code :)

Thanks,

Karl Heinz - K5KHK