CW Mode: start of first character clipped with external keyer or straight key #1011
Comments
|
Hello Don, 73 |
|
Hi Danilo and Stein, |
|
Hi Don, The problem is not directly a hardware problem, the SMT32F4 is absolutely capable of responding much faster, it is a problem of the current software architecture. I have an idea how to solve this but it is not trivial to implement so that it works without causing problems. So stay tuned. |
|
Thanks Danilo for your interest. I would like to have a solution to the problem and I realize it will be considerable work. I am really happy with all the other features of the rig and am amazed at the great features you fellows have been able to incorporate into it. I am enjoying it with the fine internal keyer in the meantime. Thank you for all the hard work that has been put into it. |
ve3ids
changed the title
|
Just for information about the CW dot values to help further: 73 Bojan PS: Yes, an excellent internal keyer. |
|
I too am having the same issue of the first character being cut off if Inallow the break in to open or leave the space too long that the radio does break in. Have listened tonit on another radio and can confirm. And this is with a straight key and not the keyer |
|
We are reaching the edge of this little radio. I am not sure this can be fixed either because RX/TX switching needs a minimum of time (LO must be retuned, code for calculating sine waves must start and get "clean" output (first ms must be clipped). So are is only workarounds: use the internal keyer or add a delay so that full BK is disabled. Using internal keyer we can delay the start without clipping the first dot reasonable. I do not think mcHF will ever become a "high-speed CW TRX" and it is not yet constructed to reach this aim... But if we are working on audio path maybe there are some ms to gain. We will see... Priority of this is not high because using internal keyer all is working well. 73 |
|
I have just discovered that my mcHF (0.6 boards, 2.5.72 firmware) also has this problem. I got the radio for CW, including straight key work for skcc, so this is a major disappointment for me. 73, |
|
ALL mcHF s do have this "problem". The newer firmwares are much faster than the old ones so we already have made a huge improvement. But we are getting into regions where a few ms are disturbing highspeed - CW - but a few ms are definitely needed by software for getting from RX to TX, for switching relay from RX to TX ( and relay is MANDATORY because of pin diodes leads to very distroted TX signals). Additional to get rid of the "popp" at each TX start we must (!!) add a few ms of muted signal to every TX start. Randy, I think you have choosen the wrong TRX for your working conditions... There are better ones - preferred no-SDRs... If I am working in CW I use maximum speed of 18...20WM which is the maximum speed I can handle. At this speed I cannot see any issues. 73 de |
|
Andreas, will the OVI40 have straight key operation or external keyer operation? I would like to build the OVI40 as well but if it has this issue like the mcHF has, it won't do what I want it to do. 73 Don VE3IDS |
|
Hi, 73 |
|
In my opinion, any QRP transceiver that won't do a good job at CW is doomed. 73, |
|
Hi Randy, that is your conclusion drawn by your position of view. In my opinion UHSDR is already doing a good job in CW. Not a perfect one - all right. But you can work in CW with internal keyer with mainly any problems and if you want to use straight key (or external keyer) you only have to leave full bk or reduce the speed to speeds most CW QSOs do have. There will come up the time we will completely redraw all audio functions and paths because the existing ones are not flexible and extendable in the way we want. This is a point where we will think about other structures and hopefully CW speed will rise up the speed which technically cannot be improved. CW routines in radio are ~5% of code - we must stay carefully to not make radio unusable due to sporadic firmware crashes because of routines are left fast but "unclean". 73 |
|
tested with speeds up to 30WPM: no more reproduceable. At higher speeds may be. |
|
Andreas,
Checked briefly, and looks good! With a straight key or bug I send around 25 wpm and works well at that speed! Don’t know what was done, but I really appreciate it!
73,
Randy, KS4L
… On Jan 30, 2018, at 12:27 PM, DF8OE ***@***.***> wrote:
tested with speeds up to 30WPM: no more reproduceable. At higher speeds may be.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I just installed 2.7.76 and I still get the first dit clipped about half
the time. It seems to happen with some sort of timing. If I send the dit at
the right moment, it is ok, but if it starts when the rig isn't ready, it
misses it, if that makes sense. Do I need some other settings applied?
If I hold the external keyer dit paddle, it will miss about 90 % of the
dits and turn them into dash length characters. By setting the tx rx delay
up so it doesn't drop out, it will work in non QSK mode but still misses
about half of the first dit of the sequence.
Thanks
Don ve3ids
…On Jan 30, 2018 4:31 PM, "KS4L" ***@***.***> wrote:
Andreas,
Checked briefly, and looks good! With a straight key or bug I send around
25 wpm and works well at that speed! Don’t know what was done, but I really
appreciate it!
73,
Randy, KS4L
> On Jan 30, 2018, at 12:27 PM, DF8OE ***@***.***> wrote:
>
> tested with speeds up to 30WPM: no more reproduceable. At higher speeds
may be.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub, or mute the thread.
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1011 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/Adv_TAggO5-tmDnFElsJGKNGW0MwVtiEks5tP4oIgaJpZM4O8yTO>
.
|
|
I cannot confirm and many others not, too. So I think it is configuration dependent or it is a hardware issue. Additionally it is not possible to improve there something without many, many, many work. So actually nobody will start there anything. Again we are missing a test report from those who do have this issue, if disbaling waterfall/scope changes the behaviour. 73 |
|
I have found that turning off the LCD will allow the external keying to be
stable up to 26 WPM. My workaround for now is to set the LCD timeout for 2
seconds. Also waterfall mode is slightly better than scope mode when the
LCD is on but not by much. The only change that seemed to help was to kill
the display, I tried many other settings with no changes to the issue. I
could not find a way to shut off the scope only and leave the rest of the
LCD active for a test I think there was that option at one time but maybe
there isn't now, I couldn't find it.
73 Don ve3ids
On Jan 31, 2018 3:18 AM, "DF8OE" <notifications@github.com> wrote:
I cannot confirm and many others not, too. So I think it is configuration
dependent or it is a hardware issue. Additionally it is not possible to
improve there something without *many, many, many* work. So actually nobody
will start there anything.
Again we are missing a test report from those who do have this issue, if
disbaling waterfall/scope changes the behaviour.
73
Andreas
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1011 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/Adv_TDBhi9NkOK_zl5lCyvsefE0a9Rkfks5tQCHrgaJpZM4O8yTO>
.
|
|
Please try if the next (!) build (2.7.88 or later) will reduce the issue. We added dropping out from display update (which is the most time consuming activity during CW). Please report your findings. |
|
I have just install 2.7.89 and it works great up to 30 WPM. Beyond 30 it
will misbehave a little but still not too bad up to 35. I added 20 ms RX TX
delay and it helps and isn't noticable, it is essentially QSK with that
small delay. 30 is plenty fast enough for me, I'm a happy camper!
Thanks very much for this great improvement, it is greatly appreciated!!!!
73
Don ve3ids
…On Feb 3, 2018 5:24 PM, "db4ple" ***@***.***> wrote:
Please try if the next (!) build (2.7.88 or later) will reduce the issue.
We added dropping out from display update (which is the most time consuming
activity during CW). Please report your findings.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1011 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/Adv_TPrsYTU9o2HqAblhOyRPHigahWCHks5tRNy5gaJpZM4O8yTO>
.
|
|
Thanks for aour report! I think we would have started that much earlier if someone would have posted test results w/o activated scope/wf.... But nobody has tried this before - so it seems not very urgent... |
|
Yes, I mentioned that this should be tested on Aug 21th 2017 in comment number 3 for this issue... can barely remember that. But github almost never forgets a thing.. |
|
Happy to report that here CW is working great with straight key input
with keying speeds as high as I can send (probably around 25 wpm).
Thanks very much!!
However, I tried this with today's latest version, 2.7.91, and in that
version, my CAT port for the mcHF does not work. I backed down to
2.7.88, and it again works fine, so I'll stay there for now. Just to
double check, I changed back to 2.7.91, and it still doesn't work. So
back to 2.7.88, and all is well again.
I was going to report this on github, but saw a message to place "test
reports" elsewhere. When I looked there, all I saw was in German,
which, unfortunately, I don't read. So this report will have to do.
73,
Randy, KS4L
|
|
Hi Randy, TNX, |
|
Hi Randy, please feel free to post there in English. It is a multilanguage community - many developers come from Germany. So English AND German are the languages there. Bug reports indeed must be placed here on GitHub. |
|
Regarding CAT: I just tested from 88 to 91 but all versions do work flawlessly using same settings on software. Cannot confirm not working CAT. |
|
Danilo,
Is it necessary to reset or adjust any Menu settings related to CAT when switching between these versions? I did not reset or adjust an settings when I checked this yesterday.
73,
Randy, KS4L
… On Feb 5, 2018, at 2:20 AM, DF8OE ***@***.***> wrote:
Regarding CAT: I just tested from 88 to 91 but all versions do work flawlessly using same settings on software. Cannot confirm not working CAT.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
2.7.89 and .91 work fine with cat control on my version 6 mcHF. I didn't
try .90
73 Don ve3ids
On Feb 5, 2018 7:53 AM, "KS4L" <notifications@github.com> wrote:
Danilo,
Is it necessary to reset or adjust any Menu settings related to CAT when
switching between these versions? I did not reset or adjust an settings
when I checked this yesterday.
73,
Randy, KS4L
On Feb 5, 2018, at 2:20 AM, DF8OE ***@***.***> wrote:
Regarding CAT: I just tested from 88 to 91 but all versions do work
flawlessly using same settings on software. Cannot confirm not working CAT.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1011 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/Adv_TCTe4AH8BOFgCfLngj5sEth_aZRpks5tRvnlgaJpZM4O8yTO>
.
|
|
It is not neccessary to change anything - everything works out-of-the-box as before. |
|
Further info on my problem with CAT in my mcHF 0.6. I am testing this with
the latest WSJT-X (1.8.0) running on Windows 10 with the latest updates. I
loaded and tested all the FW versions from 2.7.88 to 2.7.94 (today's
latest), running BL 3.4.6. My mcHF CAT works correctly using WSJT-X
(1.8.0) on all the tested FW versions except 2.7.91, 2.7.92, and 2.7.93
where WSJT-X fails to find the COM port for the mcHF. Even when WSJT-X
fails to find the COM port, Windows Device Manager still correctly shows
the COM port (COM 5 in my case), as well as the mcHF USB audio ports.
This could be a problem with WSJT-X, I suppose, but this version of WSJT-X
has been out for several weeks and I haven't seen any other complaints
about this. It also works fine with my Elecraft K3.
However, if no one else can reproduce this, I'll write it off, since the
latest mcHF version (2.7.94) works fine for me.
And in any case, all of the FW versions 2.7.88 - 2.7.94 work well with
straight key input for CW, which was what this thread is about anyway.
73,
Randy, KS4L
…On Mon, Feb 5, 2018 at 7:05 AM, DF8OE ***@***.***> wrote:
It is not neccessary to change anything - everything works out-of-the-box
as before.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1011 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AeZAzGpFapZm3x5QqTm04Myz6gd25DD1ks5tRvyGgaJpZM4O8yTO>
.
|
|
Randy,
I didn't test mine with WSJT-X, I was using DXSUITE Commander to test.
Sorry, I didn't think to try WSJT, I will try that when I get a chance.
Which version are you running, mine is probably 3 months old.
73 Don VE3IDS
…On Tue, Feb 6, 2018 at 4:19 PM, KS4L ***@***.***> wrote:
Further info on my problem with CAT in my mcHF 0.6. I am testing this with
the latest WSJT-X (1.8.0) running on Windows 10 with the latest updates. I
loaded and tested all the FW versions from 2.7.88 to 2.7.94 (today's
latest), running BL 3.4.6. My mcHF CAT works correctly using WSJT-X
(1.8.0) on all the tested FW versions except 2.7.91, 2.7.92, and 2.7.93
where WSJT-X fails to find the COM port for the mcHF. Even when WSJT-X
fails to find the COM port, Windows Device Manager still correctly shows
the COM port (COM 5 in my case), as well as the mcHF USB audio ports.
This could be a problem with WSJT-X, I suppose, but this version of WSJT-X
has been out for several weeks and I haven't seen any other complaints
about this. It also works fine with my Elecraft K3.
However, if no one else can reproduce this, I'll write it off, since the
latest mcHF version (2.7.94) works fine for me.
And in any case, all of the FW versions 2.7.88 - 2.7.94 work well with
straight key input for CW, which was what this thread is about anyway.
73,
Randy, KS4L
On Mon, Feb 5, 2018 at 7:05 AM, DF8OE ***@***.***> wrote:
> It is not neccessary to change anything - everything works out-of-the-box
> as before.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#1011 (comment)>, or
mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/
AeZAzGpFapZm3x5QqTm04Myz6gd25DD1ks5tRvyGgaJpZM4O8yTO>
> .
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1011 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/Adv_TIbs5Tzx2tG0UnqXW3-H-MxLJn85ks5tSMHNgaJpZM4O8yTO>
.
|
|
I’m running WSJT-X 1.8.0.
… On Feb 6, 2018, at 3:25 PM, ve3ids ***@***.***> wrote:
Randy,
I didn't test mine with WSJT-X, I was using DXSUITE Commander to test.
Sorry, I didn't think to try WSJT, I will try that when I get a chance.
Which version are you running, mine is probably 3 months old.
73 Don VE3IDS
On Tue, Feb 6, 2018 at 4:19 PM, KS4L ***@***.***> wrote:
> Further info on my problem with CAT in my mcHF 0.6. I am testing this with
> the latest WSJT-X (1.8.0) running on Windows 10 with the latest updates. I
> loaded and tested all the FW versions from 2.7.88 to 2.7.94 (today's
> latest), running BL 3.4.6. My mcHF CAT works correctly using WSJT-X
> (1.8.0) on all the tested FW versions except 2.7.91, 2.7.92, and 2.7.93
> where WSJT-X fails to find the COM port for the mcHF. Even when WSJT-X
> fails to find the COM port, Windows Device Manager still correctly shows
> the COM port (COM 5 in my case), as well as the mcHF USB audio ports.
>
> This could be a problem with WSJT-X, I suppose, but this version of WSJT-X
> has been out for several weeks and I haven't seen any other complaints
> about this. It also works fine with my Elecraft K3.
>
> However, if no one else can reproduce this, I'll write it off, since the
> latest mcHF version (2.7.94) works fine for me.
>
> And in any case, all of the FW versions 2.7.88 - 2.7.94 work well with
> straight key input for CW, which was what this thread is about anyway.
>
> 73,
> Randy, KS4L
|
|
Randy
I just tried mine and wsjt-x works normally with 1.8.0 and 2.7.91 but I am
running Vista though so that may be the difference.
73 Don ve3ids
On Feb 7, 2018 6:59 AM, "KS4L" <notifications@github.com> wrote:
I’m running WSJT-X 1.8.0.
On Feb 6, 2018, at 3:25 PM, ve3ids ***@***.***> wrote:
Randy,
I didn't test mine with WSJT-X, I was using DXSUITE Commander to test.
Sorry, I didn't think to try WSJT, I will try that when I get a chance.
Which version are you running, mine is probably 3 months old.
73 Don VE3IDS
On Tue, Feb 6, 2018 at 4:19 PM, KS4L ***@***.***> wrote:
> Further info on my problem with CAT in my mcHF 0.6. I am testing this
with
> the latest WSJT-X (1.8.0) running on Windows 10 with the latest
updates. I
> loaded and tested all the FW versions from 2.7.88 to 2.7.94 (today's
> latest), running BL 3.4.6. My mcHF CAT works correctly using WSJT-X
> (1.8.0) on all the tested FW versions except 2.7.91, 2.7.92, and 2.7.93
> where WSJT-X fails to find the COM port for the mcHF. Even when WSJT-X
> fails to find the COM port, Windows Device Manager still correctly shows
> the COM port (COM 5 in my case), as well as the mcHF USB audio ports.
>
> This could be a problem with WSJT-X, I suppose, but this version of
WSJT-X
> has been out for several weeks and I haven't seen any other complaints
> about this. It also works fine with my Elecraft K3.
>
> However, if no one else can reproduce this, I'll write it off, since the
> latest mcHF version (2.7.94) works fine for me.
>
> And in any case, all of the FW versions 2.7.88 - 2.7.94 work well with
> straight key input for CW, which was what this thread is about anyway.
>
> 73,
> Randy, KS4L
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1011 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/Adv_TBhFPrUxGbZdX0jQWoLatO_hGIzUks5tSZAjgaJpZM4O8yTO>
.
|
I am having problems trying to use an external keyer or straight key. The internal keyer works great. The start of the character is clipped each time the mcHF goes to TX mode. If the txrx delay is increased, it will send ok as long as the delay is high enough so it doesn't drop between characters. At a word space it will mess up the first letter again. I have a version 6 with the August 19 daily build.
Thanks
Don ve3ids
The text was updated successfully, but these errors were encountered: