Add support for full CTCSS and DCS beacon options #478
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thank you for the suggestion. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change adds the ability to include the tone type specifier to a beacon's frequency info. Today a beacon can include the T{number} field to specify a tone. The APRS spec includes support for CTCSS tone squelch and DCS codes.
http://www.aprs.org/info/freqspec.txt
With this change the tone argument can be set to a value of the form specified in the spec. For example, specifying a CTCSS squelch of 107.3, the TONE argument can be set to C107, or if a DCS code of 047 is to be specified the TONE value can be set to D047.
If the TONE argument in a beacon line is set to just a numeric value, it will assume this is specifying a tone specifier as it always has and will add a leading T to the value specified.
I looked at the decoding path and it appears that the the beacon decode path already understands the different tone leading characters.
This change would imply a documentation change to add these options to the TONE argument in beacon lines.