Ctcss error

[samukas81]

Not receiving correct code from CTCSS

[NotherNgineer]

@samukas81 Thank you for reporting the issue. Do you have any more details, such as the following?:

1. Are you seeing an issue when Mayhem is transmitting CTSS (in the Microphone app) or when Mayhem is receiving/decoding CTSS (such as in the Audio app).
2. If it's the microphone app, did you try increasing the Tone Mix setting under Settings->Audio?
3. Which firmware versions are affected?
4. I know that the microphone app had some issues that were resolved yesterday, so would you mind checking if the issue still exists in tonight's nightly build?

I don't know anything about the CTSS code, but I agree it's important for it to work in order for hams to use repeaters.

[Brumi-2021]

Hi @samukas81 , yes , as @NotherNgineer mentioned , we had some regressions in some previous nightly releases a few days ago specially in Mic App , but we feel now , all of known problems were fixed, therefore pls could you recheck with latest today’s nightly and give us more details including the exact tested fw version .

thanks

[Brumi-2021]

Hi @samukas81 , can you update us about it ?
if that is still an issue , pls give us some more details to be able to reproduce it.
Thanks

[samukas81]

Hello Brumi, in the AUDIO application in wfm mode when I transmit from my ht radio with ctcss the portapack does not receive the correct code, I have not tested transmission only reception.

[samukas81]

Sorry not in wfm mode but in narrowband

[Brumi-2021]

Hi @samukas81 , We need more details ,
I believe the HT radio is a PMR NFM Walkie-talkie 446 MHz , not ?
Which CTCSS tone code are you sending from your radio HT ?
And it is detected with different code name in Mayhem Portapack or not decoded at all ?
it is falling just a particular tone code CTCSS or all ?
and with which fw mayhem are you testing it for reception ?

In opposite transmitting from Mic App the same tone code is well detected by HT radio in reception. ?

[NotherNgineer]

Trying with a HT myself, I noticed that the Audio app reports CTCSS 22 if I transmit a CTCSS freq of 136.5, but in the Microphone app it says CTCSS 22 is 141.3. The Microphone app says CTCSS 21 is 136.5, in which case I'd expect the Audio app to say CTCSS 21, assuming the numbering scheme is the same between the two apps.

[Brumi-2021]

Hello @NotherNgineer thanks for your check and help.
I did not check the code , but I was also assuming that both app used common key tone liist

In fact in PR #850 , some other user already pointed some other error that we already amended.

based on below wikipedia Motorola key tone list , it seems that CTCSS 22 freq 141,3 is correct and CTCSS 21 freq is 136,5 , then it seems that Mic App is correct , and we need to correct the Audio Rx , no ?

[NotherNgineer]

In my testing with a cheap HT, the Audio app reports the correct CTCSS code for codes <14, and reports a code # one higher than expected for codes >14. After adding some debug code, I see that the tone detection code is seeing a tone of 67.79 Hz when the HT is supposedly transmitting 67 Hz (1.2% off), and a tone freq of 261.24 Hz when the HT is supposedly transmitting 250.5 Hz (4.4% off).

Not sure yet if the displayed frequency inaccuracy is in the HT transmission or the PortaPack reception, BUT if I transmit on the PortaPack and enable receive CTCSS on the HT, the HT receives the correct CTCSS tone that the Microphone app is configured to transmit...

[Brumi-2021]

Hi @NotherNgineer .
thanks a lot for going deepper in that investigation and also for sharing me a new debug binary tool , to see the exact detected CTCSS freq. of our Mayhem fw , before deciding the closer table index tone .

I also checked with other Oregon Scientific PMR , and I could confirm exactly same conclusions than you .
Our Mic App TX is following the Table , and there is no problem there.
Our Audio Rx App is detecting well the low CTCSS numbers of the table , but when we increase that tone freq. , we are detecting it with some offset .

In my case , Audio Rx App detects well in the low tone # range [1 to 6 ] , from 7 onwards , there is an index shift +1
(tx # 10 , is detected as # 11 and so on ... )
Below example , Walkie uses channel 4 PMR (446 Mhz band) and CTCSS tone # 7
and our Portapack Mayhem decodes it wrongly as # 8

But 38 is detected by 50

Confirmed , we have a tolerance or not accurate measurement shift up , problem in our Audio Rx App ,

We need to check if we can improve the Mayhem fw CTCSS Hz tone measurement accuracy in Audio Rx App
or just apply some -Hz correction based on real offset measurements.
To be continued .

Cheers,

[NotherNgineer]

The attached bootleg firmware should resolve the issue with the wrong CTCSS tone showing up in the apps. Fix is in PR #1226.

portapack-h1_h2-mayhem.bin.zip

[Brumi-2021]

Hello , thanks @NotherNgineer ,

I evaluated your above binary , and now ,
1-) with your PR, the value freq. detection works flawlessly (before your PR, had an error from 1,3% to 4,4% ,

and now after your PR, below 0,4% Hz , excellent job !

2-) Now the only problem is that when transmitting CTCSS#1 it is wrongly classified as CTCSS#0
But after checking the classify tone engine, it seems that the problem is more in our tone table , compared to wikipedia.

But it is easily ammended if we follow wikipedia table ,

We need to reconfirm that wikipedia table and apply final PR mod. to close completelly this CTCSS Audio Rx issue .

Based on other ham equipment makers, it seems that there are different code order ,

But I think we shold support Motorola Open CTCSS Receivers, that is matching with wikipedia.

Cheers,

[NotherNgineer]

PR #1226 has been committed, and the fix will be in nightly build n_230701. If there is any other CTCSS concerns, please submit a new issue.

[Brumi-2021]

Hello @samukas81 ,
Thanks for finding that issue . It took time to understand the problem , but we already fixed it with PR #1226
You can test from my latest Testdrive binary in discord or in tomorrow’s nightly.
You can feedback here or through discord, but so far let’s close it .

Cheers

[samukas81]

Hello Bruno, thank you for the attention you have given to this problem, sorry for not helping much, I'm working too much and I'm short on time, hug!

[samukas81]

Thanks to NotherNgineer too for their efforts!!