Corrected tone_key.cpp Motorola Code

[KillerTurtleSoftware]

Corrected Motorola Code on a few freqs.

[gullradriel]

Do they have to follow Motorola's rule ?

[KillerTurtleSoftware]

They don't, I just noticed when testing that the codes had some typos, so I corrected them.
When on the Receive Audio App, it doesn't say the actual frequency, just the codes, so when I was checking, it looked like it was detecting the wrong frequency.

[Brumi-2021]

Hi @KillerTurtleSoftware , I appreciate your typo error correction PR . Your PR seems OK . It is strange, not pointed before.
But just to check it closely, i would appreciate if you can share with us, in which TX App are we using it ? And if you already confirmed the compiled solution? (I guess yes )
Cheers

[KillerTurtleSoftware]

This is being used in the Receive---Audio app. At least that is the app I saw the issue.

I did last night, while working on a new app.

[Brumi-2021]

Hi @KillerTurtleSoftware
,I was looking it on Mic Tx ,in the key tones subcarrier CTCSS tx , but I did not know to which key tone name check it ?

Anyway you mean , in the automatic CTCSS tone detection in the NFM mode , Audio App ?
And did you confirm after compiling your PR , not ?

[KillerTurtleSoftware]

The options_tone_key when in NFM is where it is set. It's only visible if you are in NFM mode.

Correct Audio App.

I haven't gotten a chance to check the receive, as I have the RF system analyzer at my work. I will do the check either Monday at work, or I may grab one of our older Spectrum analyzers and bring it home this weekend to check.

[Brumi-2021]

Hi @KillerTurtleSoftware thanks a lot for your answer
I have two Portapack with Mayhem . Do you know if our Mic App tx can select that particular Motorola key tone subcarrier BB , and then check with the other Portapack its auto CTCSS decoding from NFM mode ? If so, let me know the key tone name of the Mic App tx , and I can also check it .
Cheers

[KillerTurtleSoftware]

@Brumi-2021

The Mic App tx can select the Tone Key, if Mode is set to "NFM/FM". The option that had the issue was "16 2Z", I corrected it to "16 2A". So this should be able to be selected and your other Portapack, should be able to decode it to the matching code.

When I was testing it before, it was showing the correct line number of the CTCSS freq, so it's decoding them correctly.

FYI, This is my first time doing anything on Github, so I apologize if I should have submitted this different.

[Brumi-2021]

Hello , @KillerTurtleSoftware , now I finally could understand you!
You are just changing the GUI OSD name of 3 particular key tones , that has typo mistake .

The freq. is correct , it is just the character name mistake . I agree !

Based on Wikipedia , you are completely correct .
Let’s approve your PR .
Later I will double check the tone freq. , but last time that I checked were perfectly matching .
so no risk , let’s merge it . And thanks for point it and solve it !

[KillerTurtleSoftware]

That's correct just the OSD name was wrong. I went thru and checked the frequencies on all of them, to make sure there weren't any other mistakes, and that's when I found 11 and 12 were wrong as well.

[Brumi-2021]

Hi again , @KillerTurtleSoftware , I checked several random CTCSS freq. and all of them matches with the labelled freq.

Just plotting one example, ,
(no need that you pick up your spectrum analyzer from your work office. , we can conclude that CTCSS generator is working well, it was just the label OSD name typo. )
Cheers,