CW zero beat indication

[S54AM]

Links below shows explanation of zero beat and interesting simple visual indicating circuit to match incoming CW signal to the sidetone to set exactly the same the TX frequency. I have operational this circuit using audio line output on mcHF as signal source and this addition is rely helpful. Is there any software solution to provide this option on the screen of mcHF (as KX3 has)?

https://www.youtube.com/watch?v=8Dxx-N2CVPI http://www.iz0kba.it/eng/cw-zero-beat.html

73, Marko, S54AM

[DG9BFC]

set your keybeep tone to 700hz set receiving tone to same tone height done (if done several times you will have that 700hz in your ear and can tune it by ear to be right on spot) the mchf also has a peak filter (set that manually to 700) ... that also helps to find the right spot cause that peak filter is very narrow hope that helps a bit

[DD4WH]

thanks for the interesting link to the KX3 feature and the wonderful explanation of zero beat! Did not know that the KX3 had a graphical and acoustical CW helper. Yes, you could do it like Sigi suggested. I am pretty convinced that it should be possible to implement a graphical helper for CW tuning without imposing any significant load on the STM32 processor in the UHSDR software:

• we have the FFT already done for spectrum display/waterfall display
• take the bins from the display FFT and search in the bins that are in the filter passband (which is usually quite narrow in CW) for the loudest signal (do averaging over several FFT loops). Note the number of that bin
• take the signal values of that bin, the bin below and the bin above (do that several times and average to account for pauses between the dits and dahs) and calculate a three-bin quadratic interpolation to exactly determine the frequency of that signal (exactly like the SNAP mode did)
• calculate the deviation of the received CW signal from Rx frequency +- CW sidetone
• show this deviation graphically Just an idea . . . comments welcome. I will not be able to implement that in short time frame, but it´s on the todo list, however with low priority. 73 de Frank

[S54AM]

Thanks Sigi and Frank for your hints and explanations. If I am honest, we can easely survive without this feature because our good ears for music (HI) and known STM limits. I am going to do some experiments with fsk tone decoder xr2211

FSK/tone decoder as HW additon (modification). http://www.wb3aal.com/Pages/K6XX/K6XXCWIndicatorKit.htm

Idea how to use exsisted LED as indirect indicator (in mcHF red one) http://www.wb3aal.com/Pages/K6XX/K1-Front.jpg 73, Marko

[s53dz]

I think this is a very attractive enhancement. (Also the HW one.) As it has been said --> all needed data for the implementation being already calculated for the scope/waterfall display.

73 Bojan

[db4ple]

Hi Bojan, 'already calculated for the scope/waterfall display' -> may not be exactly true, the granularity of the fft bins depends on the zoom level. Only if the highest zoom level is acceptable as input (48000/256 -> 187,5 Hz) we always have what we want.

[s53dz]

Hm, :o so by choosing the Zero-Beat it should go temporally in the max FFT zoom. But where to get additional RAM to show the rest (frozen) spectrum then? How do they do it so well?

[db4ple]

Well it is just a matter of how narrow we have to be, not being a signal processing expert, I have no precise idea. BTW, if we "freeze" the screen, no additional ram is required, but we could also switch to the required zoom level for the time of detecting the beat, much simpler solution. 73 Danilo

[s53dz]

As RIT resolution in our case is 20 Hz and in other's maybe 10 Hz, I would say this is the target.

[DD4WH]

I think with quadratic interpolation we always have enough resolution regardless of chosen magnify mode (<5 Hz) And display will not be frozen but there could be a small tuning indicator inside the spectrum So no RAM and no additional horsepower needed, see SNAP mode, but with reusing the existing FFT values, not a new FFT As I said its on the list, but time is limited 😉 73 de Frank

[DD4WH]

I have added some info on this in the WIKI: https://github.com/df8oe/UHSDR/wiki/Automatic-Carrier-Frequency-Tuning-by-SNAP-MODE

[DD4WH]

While thinking about this again, there were some questions coming up, maybe someone of you can help me with that, because I know nearly nothing about CW:

• why do we need an additional graphical indicator in the UHSDR (like the one in the KX3) for tuning to the accurate CW carrier? You can see the carrier of your CW QSO partner very clearly in the spectrum/waterfall and you have the line indicating your sidetone aka your TX frequency --> I would say we do not need an additional graphical indicator, its all there already (especially if you use one of the the high magnify modes of the display where you have a resolution of 5.9Hz per pixel) . . .
• If that is correct, we do not need a way to hear the sidetone by button press for the same reason
• the only thing that then remains from the wishlist would be the automatic tuning to the received CW carrier What do the CW freaks think about this? 73 de Frank

[s53dz]

Frank,

yes, good thinking. You are mainly right.

For me it would be the goal, for CW at least, to get a good help from radio like this:

1. to have a zoomed graphical indication of zero-beat,
2. as a bonus then, an automatic snap-on.

I think the mentioned graphical display of KX is just premium to have. Well zoomed, well done. Perhaps it could be done also by using an existing marker for TX but it should be at least zoomed-in no matter what zoom is being used.

73 Bojan

[DG9BFC]

1 you have it already 2 will come soon

[s53dz]

Sigi,

I don't think this is the same, considering what I wrote. A SNAP could be useful also in RTTY, where there are two carriers. An expected resolution to have effective SNAP-ON is around 10 Hz. It is not very helpful if you would have to switch the zoom manually to use this function. Just my opinion.

73 Bojan

[S54AM]

Hello to all,

I am not really CW freak, but on QRP, CW mode is my favourite for longer contacts. I would be happy, If on the screen CW sign starts flashing when side tone reaches 700Hz (+- 10Hz). I do not expect need for jumping on menus during QSO. Keep simple. Everything additional will be premium (tone button, possibility to preset side tone frq., grafics, ...). This is my opinion.

73, Marko

[s53dz]

Frank,

D2.5.93: where do I switch on the SNAP helper display? (cw_decoder_config.snap_enable) With CW decoder=on, mode=CW I get only calculated WPM indication.

I did not measure the received WPM, but comparing to sent WPM it appears to be a difference.

TNX 73 Bojan

[df8oe]

Please take a look here:

https://github.com/df8oe/UHSDR/pull/1062

73 Andreas

[DD4WH]

The WIKI knows it all ;-).

https://github.com/df8oe/UHSDR/wiki/Automatic-Carrier-Frequency-Tuning-----CW-TUNE-HELPER-&-SNAP-MODE

[DD4WH]

WPM value is based on "PARIS", so it can only be 100% accurate if you receive "PARIS" and compare that to sent "PARIS". How much deviation did you measure?

[s53dz]

Thanks to both of you, Yes, with wiki it is easier, if it is there already, hi.

Nice job, Frank, really. Now, if this proves safe it would be nice to be able to enable/disable SNAP mode just by long-press-toggling for example S1? As I suppose it eats some STM power.

As to PWM: no, as I said I have not measured yet. Just feeling as it is some 50% off. Do not take this as a fact, please. But, as you said, PARIS is the right reference here. When I calculate the word length I add 4 elements to close a CW word. So PARIS is 48 elements long.

EDIT: Scale is about +-120Hz? Now also the RIT step could be 10 Hz? EDIT2: And, perhaps also without explicitly enabling CW decode?

73 Bojan

[db4ple]

Hi, I transmitted with fldigi some CQ calls into a dummy and my WPM were after some time zooming into fldigis WPM value +/- 1 However although decoding correctly the displayed WPM goes only slowly to the "correct" value since it is heavily averaged and a slow response to changes. A simple CQ call is not long enough to adjust by more than a few WPM.

73 Danilo

[s53dz]

I see, then this averaging is the cause. No need to measure then. But on the other hand if you know the temporary element length (?), you can calculate the precise momentary WPM out of that.

tu = 60 sec / (48u * WPM)

where tu = element length 48u = PARIS length in units

73 Bojan

[db4ple]

Hi, you know that, I know that but the code doesn't. It does an average over the detected dits / dahs / spaces / wordspaces times. Which is the right thing to do considering the code is intended to work with hand sent morse code, which is much less precise in all aspects.

[s53dz]

Understood, as I just wanted to add a comment that the snap-helper is a great help, whereas counting WPM of a less help and importance here. At least to me. But if your intention is to help novice-hams using CW, of course, I can see benefit there.

Many thanks to all involved in this SNAP-helper enhancement!

I suppose in pushing SNAP further, by choosing SNAP function there could be an automatic switch to a maximum frequency encoder precision (10 Hz) for the time of active SNAP function. (As actually XIT would do.) Here also a 10 Hz RIT would bring a balance in setting precise frequency. I think an excellent frequency stability of mcHF HW allows for that.

73 Bojan

[s53dz]

D2.5.95: Nice work - the tune-helper. But it requires to switch on CW decoder manually. I suppose it would be nice improvement if the two menu lines would work independently:

• CW decoder=on --> display the CW decoder text line and WPM figure,
• CW tune-helper=on --> display the helper rectangle, whatever functions it may use behind.

The idea being to be able to choose only what you need.

EDIT: Further observation: Since the "Red" LED is somehow reserved for TX it would be perhaps better to use an RX LED for the CW decoder output.

73 Bojan

[df8oe]

Thanks for your ideas. All this is WIP and very early alpha stage - not yet ready and not reliable working at the moment. Hopefully we will approach satisfying functionality the next days. Some of the daily snapshots do show what is possible in decoding (but have other issues) - some do have mire functions but do not decode well. We will fit "the best of each of them" in the next versions ;)

73 Andreas

[s53dz]

Tune helper works well and only in CW-L mode. If you have the CW LSB/USB auto switched to on then you can finish in CW-U and you are out. So, the menu item CW LSB/USB auto is obsolete now?

73 Bojan

[db4ple]

This is alpha stage! CW-L problem fixed in next daily build

[s53dz]

D2.5.98: Report - Tune helper works well now in CW-L and CW-U.

73 Bojan

[s53dz]

I think TUNE HELPER works well. I suppose if you manage to implement just these two things:

• toggle TUNE HELPER on/off by long-hold-button for example S3
• turning TUNE HELPER to on independently of CW decoder = on.

then I suppose this issue is gone. Marko?

73 Bojan

[db4ple]

For the second item: we use the signal detection of the CW decoder to know when to measure the signal. Since it basically takes next to no time o do the CW decoding we can let it run all the time (just for the purpose of telling us that there is a CW signal (without showing the decoded output).

Why not let the tune helper run all the time in CW mode? Does not take too much processor time either, since we reuse the data from the waterfall / scope.

[DD4WH]

absolutely agreed:

• the CW decoder could/should run all the time in the background, only switch in the menu whether the text should be displayed or not
• also I like the idea of the tune helper always on, maybe it motivates people to be better "on spot" ;-) I also like the idea of having this tune helper in other modes, it will be not strictly a tune helper, but an offset graphical indicator, I will try to work on that the next weeks, maybe also with the option of being able to choose a higher resolution [for MW dxing, it is very nice to have a possibility to measure carrier offset with an accuracy of at least one Hz ;-)]

BTW, I have a prototype of an "AGC"/"ATC" for the decoder threshold running already, but its not yet ready for alpha testing, too much "other" work at the moment . . .

73 Frank

[s53dz]

Nice thinking there about having the tool running, although wasting MCU's power when not needed in general is not a good idea. But hey, if the increase is small enough ... I think when talking about an accuracy of 1 Hz or better we are approaching the mcHF LO frequency accuracy already. At least at 30 MHz. But other HWs should probably improve that.

TNX 73 Bojan

[S54AM]

Hi,

Also from my perspective tune helper should have possibility to be independent (from CW decoder) and always ON when you choose CW mode and when tune helper is ON in menu bar. Anyway I am amazed with current results. Bojan, Danilo and Andreas, big thanks for your effort on this issue.

73, Marko

[DD4WH]

OK, I try to summarize the next steps:

• CW decoder always running in the background when mode is CW (no problems with performance here, the CW decoder runs in the decimated path and takes considerably less than 1% of the maximum possible processor load: no waste of processor power involved) --> we need the CW decoder for the CW tune helper
• CW TUNE HELPER always on as default setting --> switchable ON/OFF in CW menu [also: barely no processing power involved here]
• CW DECODER text display ON/OFF switchable in CW menu
• implement CW SNAP: press a button and the frequency is automatically adjusted to the received CW frequency +-sidetone --> work in progress, should come out for testing in the next weeks
• I am not convinced we would need toggle buttons: I think you would once set your preference ON/OFF in the menu and then it would stay like that, especially if you know that there is virtually no advantage in terms of processing power when those functions are switched OFF

Re: accuracy: I was thinking about relative frequency accuracy, not absolute accuracy. It is not difficult to increase relative accuracy up to the sub-Hz-level (eg. the ZoomFFT could easily be extended to magnify-by-4096 which would lead to a spectrum display of about 6Hz wide, making the pixel resolution 0.02Hz = 20mHz ;-)). Dont know if anybody needs this, I experimentally implemented this in my Teensy Convolution SDR and it works astonishingly well for identifying carrier offset in MW broadcast stations (however update rate is one spectrum display every 4 seconds as a result of the basic DSP law that time and frequency accuracy are always negatively correlated!)

73 de Frank

[s53dz]

Frank,

An excellent job and nice summary. TNX

Just a comment on the fourth bullet point: If you go SNAP TO you end-up on a decimated frequency (on 5 or 10 Hz boundary?) which would probably be not the same as a current frequency step. What will then be the frequency if one advance for one step? Rounding perhaps? Here I really don't know what others do. I have this difficulty when switching the mode (depending on the CW_display_mode) you can end-up on a frequency (side-tone arithmetic) which is on 50 Hz margin but the current frequency step is set to 100 Hz.

73 Bojan

[DD4WH]

good point. What accuracy would you wish for? We can build that into the firmware. Should we round the determined CW carrier frequency to the next 10Hz? [maximum deviation to your QSO partners freq would then be 5Hz] 73 de Frank

[df8oe]

I think we can leave it "as it is". A step is a step and will not be rounded. And a snap is a snap and may be aligned at a grid (but must not). Both are independent. If snap leads to 7.015.432 and your step is 100Hz, you would step +/- 100 Hz from this if you turn VFO knob.

But there is already an "align" function by tapping on "TUNE" field on LCD. At this stage it is aligning at 500Hz grid. This is of course extendable to every other grid (and can be conditionaly, too).

73 Andreas

[s53dz]

Frank, I think 10 Hz is enough, since the correspondent in CW can not use much less filter BW as 300 Hz. Hi. But, if you do so, then also RIT is to coarse ...

Andreas, I don't think that staying on the same decimated frequency that was done for one QSO only should be persistent! I am more for a wise way of rounding to a current step size. My opinion only.

73 Bojan

[df8oe]

All frequencies are same weighted. You throw in your psychologic argument of "round" frequencies - but what does mean for usage?

If I use an old analog receiver I do not know exact frequency and all is working well. My opinion only.

73 Bojan

[df8oe]

...and if you want to go to a "grid" - just tap on TUNE symbol on LCD... Both suggestions can be bundled. We only must discuss which conditions lead to what grid.

[df8oe]

Think about this: If you snapped to one CW signal you are landing at 123Hz. Why rounding to a special grid? If you turn VFO-knob and see the next interesting signal you snap to 456Hz - and are "on". What is the functional advantage to always be on a grid?

[s53dz]

Well, Andreas, actually we don't need a frequency display at all, we can just go SNAP TO or TAP TO a signal and do a QSO. Hi! Of course I do not agree to that. This display is also way to small to use it for a such frequent tapping. And please, see the frequencies on HF bands: they are mostly on 0 Hz or on side-tone (mistakenly) boundaries! Nowadays machines are very accurate. But I agree with you 100% for the old days and the good old analog VFO without steps.

Additional thought: When Marko said about the button SNAP I think now he has a point there. We see if one want to align his frequency to a correspondent then he has to use RIT (20 Hz) or a STEP of a usable value (10 Hz). Now if TUNE HELP would be quickly available (one touch away) then it could be also the frequency step appropriately lowered for the time function is ON. BTW: What is with a TUNE HELP function in SPLIT mode? Only for RX? Only for TX?

73 Bojan

[df8oe]

Yes - that's it! If I do want to start a QSO I just go the frequency and start QSO. It is not important what number this frequency doeas have. It must be in the borders of band - that's all. Most OMs do write on their QSL cards "40m" or "7MHz" - no interest in the other digits.

Shall we all others who do transmit on "not round frequencies" correct??

We are thinking different here...

TUNE HELP of course is only for RX. I do not see any technical base for TX.

73 Andreas

[df8oe]

I am using touch screen very intensively and I am very happy to have this mighty functionality. If I see a CW signal I just tap on it on waterfall or scope and I am "on". I mostly use this way for tuning. Only if I want big steps I use VFO knob. I do not agree LCD is too small for doing touch functions. TUNE field at the right bottom is a very big place - you can aim to it using fingernails 100%.

73 Andreas

[df8oe]

Again one argument against a grid:

If I do want to work a rare DX station which is working in split mode I do have the best chances, if I am not TXing at the same frequency all others do. If the others all are TXing on the same "rounded" frequency: it will be a luck for me who does translate some Hz beneath all others - hi...

[s53dz]

You mean only for TX, since by TUNE HELP we want to be with our TX exactly on correspondent's TX/RX. But, of course you are right, we are tuning to RX signal here. This is a goal. CW operator on receive does not care if his RX is 100 Hz away in a 300 Hz RX BW!

As I said, you don't need a frequency display at all, hi. Just use TX_OUT_OF_HAM_BANDS=OFF and that is it. But, please use also the newest function SNAP TO, as this way we could find your signal on frequency. :)

To your last point, yes, we need XIT (20 Hz or 10 Hz resolution) for that. Or, of course, an analogue-like VFO. Viva analogue!

I suppose if we choose STEP=1Hz and a complex dynamic tuning, we will have such an analogue-like tuning.

73 Bojan

[DG9BFC]

in my view the issue can be closed for now ... tune helper works fine ... snap to zerobeat function can be added later (if programmers are willing to do so) .... with the tunehelper you can tune very accurate to be on spot ... that should be ok for any normal cw op ... right?!?

[s53dz]

For me this CW_tune_helper works really great. Exceptionally great. Perhaps, I miss only what I said before:

turning TUNE HELPER to on independently of CW decoder = on.

Sigi, I am not a heavy CW OP, but I like any good support for CW work. By saying this, I can't tell if I am a "normal" or normal CW OP. Hi.

73 Bojan

[s53dz]

With the D2.5.109 the TuneHelper is switchable independent of CWdecoder. Nice work. This issue to be closed since there will probably be another for SNAP TO?

TNX 73 Bojan