Improvements of the DTMF Contact sending

Discussions related to the firmware code development
ok1pt
Posts: 167
Joined: Mon Jul 20, 2020 3:38 am

Re: Improvements of the DTMF Contact sending

Post by ok1pt » Sat Oct 03, 2020 4:38 am

VK3KYY wrote:
Fri Oct 02, 2020 10:26 pm
Can you load the official CPS and tell me which inputs on the DTMF signalling screen map to which parts of your code, and I will attempt to write code to read those fields from the codeplug data.
Hi Roger!
On the right columne of the DTMF signalling window:
- First digit delay is the pretime
- The next two options (separate length of the first digit, * and #) we don't use yet (if you want, I can patch it to the code as well)
- The last one (DTMF Rate) should be converted to our digit/pause duration. There are only 3 values, 5, 6 and 10. For 10, it's 50ms tone /50ms pause, for 5 I think the best will be 150ms tone and 50 ms pause and for 6 the exact value is 117 ms of tone but I think we can round it down to 100 ms tone / 50 ms pause. So the conversion will just switch between 50, 100 and 150 ms of tones and the pause will be fixed to 50.
However, I don't like this option, much better would be to set individually the length of tones and pauses. But our Chinese programmers decided to go this way, so let's follow it..
Cheers/73, Pavel

VK3KYY
Posts: 7473
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Improvements of the DTMF Contact sending

Post by VK3KYY » Sat Oct 03, 2020 5:00 am

ok1pt wrote:
Sat Oct 03, 2020 4:38 am
VK3KYY wrote:
Fri Oct 02, 2020 10:26 pm
Can you load the official CPS and tell me which inputs on the DTMF signalling screen map to which parts of your code, and I will attempt to write code to read those fields from the codeplug data.
Hi Roger!
On the right columne of the DTMF signalling window:
- First digit delay is the pretime
- The next two options (separate length of the first digit, * and #) we don't use yet (if you want, I can patch it to the code as well)
- The last one (DTMF Rate) should be converted to our digit/pause duration. There are only 3 values, 5, 6 and 10. For 10, it's 50ms tone /50ms pause, for 5 I think the best will be 150ms tone and 50 ms pause and for 6 the exact value is 117 ms of tone but I think we can round it down to 100 ms tone / 50 ms pause. So the conversion will just switch between 50, 100 and 150 ms of tones and the pause will be fixed to 50.
However, I don't like this option, much better would be to set individually the length of tones and pauses. But our Chinese programmers decided to go this way, so let's follow it..
Cheers/73, Pavel
Please can you explain about "much better would be to set individually the length of tones and pauses"

I have the CPS source, so can possibly make some changes

The existing data structure is here.

https://github.com/rogerclarkmelbourne/ ... #L64-#L112

Currently we don't use this data from the codeplug at all, and I don't think we will ever implement any "Kill" functions, as this firmware is for Ham radio only.
Also, the data bytes called reserve1, reserve 2 and reserve 4, which are probably not used at all by the official CPS and are probably all set to 0x00 by default, so can be re-used

ok1pt
Posts: 167
Joined: Mon Jul 20, 2020 3:38 am

Re: Improvements of the DTMF Contact sending

Post by ok1pt » Sat Oct 03, 2020 7:53 am

VK3KYY wrote:
Sat Oct 03, 2020 5:00 am


Please can you explain about "much better would be to set individually the length of tones and pauses"
Hi Roger,
yes.
Instead of this "rate" option it would be better to have two integer values called
"DTMF digit duration [ms]" and "DTMF pause duration [ms]". and let the user set them manually.
Of course also the third value called "First digit delay [ms]" should be settable to set the pretime.
It's a question whether to implement different length of the first digit (it can help if the standard timing is short - like 50 ms - to set up the audio path gain of the receiver). I believe that there is not needed to make a different timing of * and #, I don't know about any usage in the ham world.
I have the CPS source, so can possibly make some changes

The existing data structure is here.

https://github.com/rogerclarkmelbourne/ ... #L64-#L112

Currently we don't use this data from the codeplug at all, and I don't think we will ever implement any "Kill" functions, as this firmware is for Ham radio only.
Also, the data bytes called reserve1, reserve 2 and reserve 4, which are probably not used at all by the official CPS and are probably all set to 0x00 by default, so can be re-used
Perfect that we have such freedom!
WIth regards / 73
Pavel

VK3KYY
Posts: 7473
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Improvements of the DTMF Contact sending

Post by VK3KYY » Sat Oct 03, 2020 8:10 am

Thanks Pavel

I think we will initially just implement using values from the normal data in the codeplug. But perhaps in the future we can update it to include more settings.

Arrghh. I just realized that if use these settings, then the firmware needs to also have a way to configure them.

We'll probably add the settings to the Options screen, as I don't think its worthwhile to have a complete new menu screen just for the DTMF options.

ok1pt
Posts: 167
Joined: Mon Jul 20, 2020 3:38 am

Re: Improvements of the DTMF Contact sending

Post by ok1pt » Sat Oct 03, 2020 9:17 am

VK3KYY wrote:
Sat Oct 03, 2020 8:10 am
Thanks Pavel

I think we will initially just implement using values from the normal data in the codeplug. But perhaps in the future we can update it to include more settings.

Arrghh. I just realized that if use these settings, then the firmware needs to also have a way to configure them.

We'll probably add the settings to the Options screen, as I don't think its worthwhile to have a complete new menu screen just for the DTMF options.
OK, I also think that until we implement most of the DTMF signaling (assuming it ever happens), it's enough to have it in the general Options menu.
73, Pavel

ok1pt
Posts: 167
Joined: Mon Jul 20, 2020 3:38 am

Re: Improvements of the DTMF Contact sending

Post by ok1pt » Sun Oct 04, 2020 8:14 am

Hi Roger!
Today I found on github, that you made a new tag containing the DTMF changes (+ a big bonus with individual power per channel :-) ). How to pull it ? I can't see it on neither of the two branches. Even when looking directly on the github sources (in the development branch), I can't find it, the most recent sources I can see on the web don't contain the desired changes. What I'm doing wrong ?
With regards, Pavel

User avatar
Zl1XE
Posts: 110
Joined: Fri Jul 24, 2020 12:25 am

Re: Improvements of the DTMF Contact sending

Post by Zl1XE » Sun Oct 04, 2020 8:45 am

Hi Pavel,
Check out the new release:
- viewforum.php?f=13
- you need the cps and the firmware

ok1pt
Posts: 167
Joined: Mon Jul 20, 2020 3:38 am

Re: Improvements of the DTMF Contact sending

Post by ok1pt » Sun Oct 04, 2020 9:17 am

Zl1XE wrote:
Sun Oct 04, 2020 8:45 am
Hi Pavel,
Check out the new release:
- viewforum.php?f=13
- you need the cps and the firmware
Hi!
I understand. I already have the CPS, as I'm using binary releases.
However, I would like to pull the firmware release to my local git tree, because I'm compiling the firmware from the source. And I can't find this release on the official github (even using the web interface), so I can't pull the changes to my local git. This is the problem. Probably I don't know how to specify the tag... I believed that this release was made from the development branch, but there aren't the latest changes, and in the master branch the code is even older (from the release 2020.10.01.
And I can't find any other branch which I could check out and then pull.
With regards,
Pavel

ok1pt
Posts: 167
Joined: Mon Jul 20, 2020 3:38 am

Re: Improvements of the DTMF Contact sending

Post by ok1pt » Wed Oct 07, 2020 2:51 pm

Hi!
So, I tested your "very development" binary release. And I have hints for making it better :-).
1) CPS problem: In original CPS, items "First digit length" and "* # length" can be set to 0. In our CPS it's not possible.
2) In the firmware: Original firmware evaluates these values and ADDS them to the standard timing. It's written in the context help of CPS. They have an example - if you have 10 CPS = 50 ms digit and 100ms First digit length, total length of the first digit will be 150 ms.
As a result, if the values of First Digit Length and *# lenght is set to 0, they have the standard length and the sequence pace is monotonous. We can't reach this now for quicker CPS rates.
With regards,
Pavel

User avatar
F1RMB
Posts: 2517
Joined: Sat Nov 16, 2019 5:42 am
Location: Grenoble, France

Re: Improvements of the DTMF Contact sending

Post by F1RMB » Wed Oct 07, 2020 3:22 pm

Hi,
ok1pt wrote:
Wed Oct 07, 2020 2:51 pm
Hi!
So, I tested your "very development" binary release. And I have hints for making it better :-).
1) CPS problem: In original CPS, items "First digit length" and "* # length" can be set to 0. In our CPS it's not possible.
Really ?
DTMF_settings.png
DTMF_settings.png (11.1 KiB) Viewed 3780 times
ok1pt wrote:
Wed Oct 07, 2020 2:51 pm
2) In the firmware: Original firmware evaluates these values and ADDS them to the standard timing. It's written in the context help of CPS. They have an example - if you have 10 CPS = 50 ms digit and 100ms First digit length, total length of the first digit will be 150 ms.
As a result, if the values of First Digit Length and *# lenght is set to 0, they have the standard length and the sequence pace is monotonous. We can't reach this now for quicker CPS rates.
With regards,
Pavel
Since I had contradictory information about the duration or * and #, it's currently twice the duration (if *# duration is equal to 0). I will change that.



Cheers.
---
Daniel

Post Reply