Update cysfprotocol.h

[vk4tux]

Lets identify the YSF connects with a 'Y' suffix? I do this on my own system and others I look after, and find it very beneficial,
to discern between DMR/D-Star and YSF connects. DMR and D-Star can be sorted by looking at the suffix column (none for DMR),
so doesn't need the same treatment.

[lwkoon]

Updated

[vk4tux]

Not sure why Luc didn't like this one. Good to know who is connecting via YSF.

…

On 2/1/20 7:39 pm, 9W2LWK wrote: Updated — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#135?email_source=notifications&email_token=ACCUMYEQW3JX42HEI2BNM4LQ3WY5BA5CNFSM4JQKECG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH56SIQ#issuecomment-570157346>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCUMYBRQTJ4NOONBPX62F3Q3WY5BANCNFSM4JQKECGQ>.

[yo2loj]

I use Y for YSF and R for DMR. It's quite handy, without the need to check in repeater/nodes...
Using no suffix for DMR will throw off possible statistics via the json interface, where the only way to distinguish between clients and peers is the absence of suffix for peers. Maybe the json interface needs an overhaul, introducing a type and a protocol parameter or something, but that's another topic.

[lwkoon]

Do you guys know on the XLX link between Brandmiester, the last heard for XLX Interlink "options" still DSTAR instead of C4FM, do you have any clue to show C4FM instead of DSTAR when a YSF client connect and transmit? have not going through the protocol used and link for through.