Topics

Echo trainer response timing

Ben
 

Dear all,
I noticed when using the echo trainer that sometimes my responses are somewhat slower. I thougth i was crazy, and my mind was playing tricks on me. But today i recorded a session and checked with Audacity. Timing was different! Is this only me? Also i don't always have the impression that my responses are slower. This was 7 minutes into a training session.

Settings:
Latency: 4/8
Keyer mode: Curtis B
DahT%: 0
DiT%: 0
AutoChar space: Off
WPM: 20
Echo trainer, English words
Recorded with microphone, not from line output.

Please find a screenshot attached. Upper track = Morserino echo trainer, lower track is my response on the word. You'll see only the letter S in the screenshot (3 dits). I aligned the letter S on the fist dit. In the lower track you'll also see my paddle click before the first dit. I marked the second dit with a vertical line. You'll see the difference.

Thanks,
Ben

Willi, OE1WKL
 

That’s interesting! And I must say I have not the slightest clue about the reason for that…

Willi

Am 23.02.2020 um 11:20 schrieb Ben <ben@...>:

Dear all,
I noticed when using the echo trainer that sometimes my responses are somewhat slower. I thougth i was crazy, and my mind was playing tricks on me. But today i recorded a session and checked with Audacity. Timing was different! Is this only me? Also i don't always have the impression that my responses are slower. This was 7 minutes into a training session.

Settings:
Latency: 4/8
Keyer mode: Curtis B
DahT%: 0
DiT%: 0
AutoChar space: Off
WPM: 20
Echo trainer, English words
Recorded with microphone, not from line output.

Please find a screenshot attached. Upper track = Morserino echo trainer, lower track is my response on the word. You'll see only the letter S in the screenshot (3 dits). I aligned the letter S on the fist dit. In the lower track you'll also see my paddle click before the first dit. I marked the second dit with a vertical line. You'll see the difference.

Thanks,
Ben

<M32-echo-trainer.png>

Ben
 

I did another test. Just uploaded a file with the character '5' (5 dits) for the file player. I recorded from the line output, so no background noise and cllicks. Same issue as you can see in the screenshot. I did another 15 minute training session and i was not able to hear it this time myself. So there is a timing difference, but it is not always noticable for me.

I have tested this on two M-32's, version 2.3. same result.

Ben
 

From what i can see now, is that the dits are the same length, only the space between the dits is longer when sending a respone with my external paddle.

Willi, OE1WKL
 

Yes, it seems they are about 1/10 of a dit-length delayed….

Will try to find out the reason for that….


Willi

Am 23.02.2020 um 17:40 schrieb Ben <ben@...>:

From what i can see now, is that the dits are the same length, only the space between the dits is longer when sending a respone with my external paddle.

<m32-response-space-longer.png>

Willi, OE1WKL
 

Ben,
Can you do this with other wpm settings, to see if it is depended on dit length, or if it is a fixed delay?

Willi

Am 23.02.2020 um 17:40 schrieb Ben <ben@...>:

From what i can see now, is that the dits are the same length, only the space between the dits is longer when sending a respone with my external paddle.

<m32-response-space-longer.png>

Ben
 

Hi Willi,
I tried also 10 and 30 wpm, saw a delay there also, will measure it after dinner.

Ben

Ben
 

This is what i measured. The 4-6ms extra space seems to occur at 10, 20 and 30 wpm.

       
10 WPM      
signal m32(ms) response(ms) difference(ms)
dit 120 121 1
space 122 126 4
dit 119 120 1
space 122 128 6
dit 120 120 0
space 122 128 6
dit 120 120 0
space 122 126 4
dit 120 121 1
       
20WPM      
signal m32(ms) response(ms) difference(ms)
dit 60 60 0
space 63 67 4
dit 60 60 0
space 61 67 6
dit 60 60 0
space 61 67 6
dit 60 60 0
space 63 67 4
dit 57 60 3
       
30WPM      
signal m32(ms) response(ms) difference(ms)
dit 38 40 2
space 42 48 6
dit 39 40 1
space 44 48 4
dit 38 40 2
space 43 48 5
dit 38 40 2
space 42 48 6
dit 40 40 0

Willi, OE1WKL
 

Thanks, Ben.
Apparently this is not proportional to speed, but a pretty constant delay.
I will investigate further to find a clue about its origin...

Willi



Von meinem Mobiltelefon gesendet

Am 23.02.2020 um 19:12 schrieb Ben <ben@...>:

This is what i measured. The 4-6ms extra space seems to occur at 10, 20 and 30 wpm.

       
10 WPM      
signal m32(ms) response(ms) difference(ms)
dit 120 121 1
space 122 126 4
dit 119 120 1
space 122 128 6
dit 120 120 0
space 122 128 6
dit 120 120 0
space 122 126 4
dit 120 121 1
       
20WPM      
signal m32(ms) response(ms) difference(ms)
dit 60 60 0
space 63 67 4
dit 60 60 0
space 61 67 6
dit 60 60 0
space 61 67 6
dit 60 60 0
space 63 67 4
dit 57 60 3
       
30WPM      
signal m32(ms) response(ms) difference(ms)
dit 38 40 2
space 42 48 6
dit 39 40 1
space 44 48 4
dit 38 40 2
space 43 48 5
dit 38 40 2
space 42 48 6
dit 40 40 0

Willi, OE1WKL
 

In my sleep it dawned on me… ;-)


I should have seen it already in the first picture you sent (see attached). Look at the delay between the click of your key ands the beginning of the side tone...
It is a result of debouncing the key (through measurements on various keys, amongst them very expensive ones, I found out that some of them are bouncing heavily up to > 5 ms. SO the debouncing routine uses a delay to allow the contacts to come to rest.

I will see if I can find a debouncing method that works without (or with less) delays…


73

Willi



Am 23.02.2020 um 19:11 schrieb Ben <ben@...>:

This is what i measured. The 4-6ms extra space seems to occur at 10, 20 and 30 wpm.

       
10 WPM      
signal m32(ms) response(ms) difference(ms)
dit 120 121 1
space 122 126 4
dit 119 120 1
space 122 128 6
dit 120 120 0
space 122 128 6
dit 120 120 0
space 122 126 4
dit 120 121 1
       
20WPM      
signal m32(ms) response(ms) difference(ms)
dit 60 60 0
space 63 67 4
dit 60 60 0
space 61 67 6
dit 60 60 0
space 61 67 6
dit 60 60 0
space 63 67 4
dit 57 60 3
       
30WPM      
signal m32(ms) response(ms) difference(ms)
dit 38 40 2
space 42 48 6
dit 39 40 1
space 44 48 4
dit 38 40 2
space 43 48 5
dit 38 40 2
space 42 48 6
dit 40 40 0

Ben
 

On Mon, Feb 24, 2020 at 09:18 AM, Willi, OE1WKL wrote:
In my sleep it dawned on me… ;-)
Best advice ever!

I understand switches need to be debounced and that there is a short delay involved. Is that same delay also necessary between consecutive dits, where i don't release my key? All spaces on the response seem to be longer than the Morserino sending.

Willi, OE1WKL
 

It seems the matter is more complicated than I thought (never trust the solutions that come up in your sleep ;-)

The debounce delay as defined in the software is only 0.75 ms (and it does indeed only come into account when there is a change between pressed or cleared, not when it is continuously pressed)  -- this means the reason for the delay must be somewhere else.

I will investigate further…

Willi



Am 24.02.2020 um 18:32 schrieb Ben <ben@...>:

On Mon, Feb 24, 2020 at 09:18 AM, Willi, OE1WKL wrote:
In my sleep it dawned on me… ;-)
Best advice ever!

I understand switches need to be debounced and that there is a short delay involved. Is that same delay also necessary between consecutive dits, where i don't release my key? All spaces on the response seem to be longer than the Morserino sending.

Willi, OE1WKL
 

Now I think I have nailed it, after doing a number of timings within some of the functions in the software:

Checking the paddles (including reading the capacitive ones, and debouncing) takes about 2 ms (I can bring that down to half that value).

At each loop in the state machine the paddles are being checked. It takes two additional loops from touching the paddle to actually getting the sound out (or keying a transmitter).

This in total gives 6 ms delay, pretty close to what you were measuring.

What I did now (this will be in the next release of the software):
- bring down the time to check the paddles to 1 ms.
- skip the checking of paddles in these two loops of the state machine (which is meaningless at that moment, anyway).

This brings down the total delay to 1 ms. 

What I could do additionally (I think it will not have any bad side effects): subtract one millisecond from the space between the elements of a character, to compensate for the millisecond it takes to check for a paddle press. Should bring the total delay down to 0 (or at least to a value smaller than 25 microseconds).


73

Willi


Am 25.02.2020 um 15:33 schrieb Willi, OE1WKL <willi@...>:

It seems the matter is more complicated than I thought (never trust the solutions that come up in your sleep ;-)

The debounce delay as defined in the software is only 0.75 ms (and it does indeed only come into account when there is a change between pressed or cleared, not when it is continuously pressed)  -- this means the reason for the delay must be somewhere else.

I will investigate further…

Willi



Am 24.02.2020 um 18:32 schrieb Ben <ben@...>:

On Mon, Feb 24, 2020 at 09:18 AM, Willi, OE1WKL wrote:
In my sleep it dawned on me… ;-)
Best advice ever!

I understand switches need to be debounced and that there is a short delay involved. Is that same delay also necessary between consecutive dits, where i don't release my key? All spaces on the response seem to be longer than the Morserino sending.


Ben
 

That sounds great! Nice that you found it :)

Joe Wittmer K9SZ
 

Hi Willi,

What I could do additionally (I think it will not have any bad side effects): subtract one millisecond from the space between the elements of a character, to compensate for the millisecond it takes to check for a paddle press.
Just woke with a thought...

Perhaps an option to try is updating the state machine to transition to a state of not polling the paddles during the last couple mills.

Just an idea, fwiw...

As a side, I’d like to see on this board where I can trigger a couple GPIOs and measure timing with a logic probe.

73
Joe