MDC/FleetSync Optional Signaling Best Practices

[lucasec]

I spent some time over the weekend trying to get two NX5000s to speak analog signaling to each other. I did a few experiments with both MDC and FleetSync, but there are a lot of options so I'm trying to figure out the best practices/which combinations are actually practical.

For constraints, let's just assume a small group operating analog conventional. Start with simplex to keep it simple. I have control of the radios in use and can program however I see fit (no need to interoperate with an existing setup).

Signaling type: I assume FleetSync II is the obvious choice if all the radios are Kenwood, otherwise MDC.

Audio Control: If set to "and Optional Signaling", the audio will not unmute unless a Selcall is made. There's not really an analog equivalent of the "Selcall on PTT" setting available in the DMR/NXDN modes, so if a channel is configured this way, a contact always has to be selected off the call list (just keying up the channel won't unmute any other radios). Is this how people typically configure a large system?

PTT ID: Do you use BOT, EOT, or both? EOT seems useful for still getting caller ID if the BOT gets clipped due to late entry, but doesn't help at all if the channel is set to only unumte on Selcall.

PTT ID with QT/DQT: On MDC, we can set the radio to turn off QT/DQT before sending the MDC burst, which seems to be the only way to avoid hearing the EOT burst. I assume this should be used whever possible with MDC. FleetSync does not appear to have this option, but we have "FleetSync Burst Noise Reduction" which seems to clip out 98% of the noise.

PTT ID Pause: If enabled, defaults to 1 second, but I could imagine it being useful to set this even longer to reduce repeated PTTs in a longer conversation.

My last question is more around system design. Using the signaling just for caller ID or to send out paging tones is obivously lower stakes. But if optional signaling is required for unmute, I assume missed transmissions are common if radios are in scan or operating at the extremeties of their usable range (since unlike digital, the signaling doesn't repeat itself throughout the transmission). When is the optional signaling best used and what are the most common cases it should be avoided?

 

[dryfb]

I use FS and MDC on every radio I have so hopefully this'll be of some help.

FleetSync II sucks IMO, takes longer and isn't worth it. If all KW then use Fleetsync 1 at 1200 BPS

I have never seen anything like that actually being used tbh. Every user of FS I see has it as QT/DQT or "or Optional Signalling." Not sure because I don't have access to the programming but not hard to completely rule out "and optional signalling"

I use both but BOT makes it easier for end users to see who is talking

I don't think FS has that option at all but I like FS burst noise reduction and use it a lot to limit the noise

I don't use this except on ham repeaters so if I slip off the PTT I don't make another BRRRT noise. I only use BOT on ham stuff and I use 1 second default for this.

I use it just for sending alerts but the radios are never muted and never require a FS message to open up audio for my fleet of 10-20 Fleetsync capable Kenwood radios. I can send you a stripped-down codeplug for my NX300 if you want to see how I have my Fleetsync set up.

 

[mmckenna]

Signaling type: I assume FleetSync II is the obvious choice if all the radios are Kenwood, otherwise MDC.

Fleetsync has more capability.
MDC is more common.

If all you need is a radio ID, or to trigger the alias, either one will work.

Audio Control: If set to "and Optional Signaling", the audio will not unmute unless a Selcall is made. There's not really an analog equivalent of the "Selcall on PTT" setting available in the DMR/NXDN modes, so if a channel is configured this way, a contact always has to be selected off the call list (just keying up the channel won't unmute any other radios). Is this how people typically configure a large system?

No, "And" means you have to have both, and that means you can miss traffic. I'd not run this way.

PTT ID: Do you use BOT, EOT, or both? EOT seems useful for still getting caller ID if the BOT gets clipped due to late entry, but doesn't help at all if the channel is set to only unumte on Selcall.

I run EOT for our PD. Running it BOT risks it stepping on someone talking. As soon as they release PTT, the ID will show. That's usually good enough to identify the user. For hobby use, you'll probably recognize the voice of the people you are talking to.

PTT ID with QT/DQT: On MDC, we can set the radio to turn off QT/DQT before sending the MDC burst, which seems to be the only way to avoid hearing the EOT burst. I assume this should be used whever possible with MDC. FleetSync does not appear to have this option, but we have "FleetSync Burst Noise Reduction" which seems to clip out 98% of the noise.

Yes, people will get tired of the data burst rather quickly.

PTT ID Pause: If enabled, defaults to 1 second, but I could imagine it being useful to set this even longer to reduce repeated PTTs in a longer conversation.

My last question is more around system design. Using the signaling just for caller ID or to send out paging tones is obivously lower stakes. But if optional signaling is required for unmute, I assume missed transmissions are common if radios are in scan or operating at the extremeties of their usable range (since unlike digital, the signaling doesn't repeat itself throughout the transmission). When is the optional signaling best used and what are the most common cases it should be avoided?

Scan and BOT are not going to work reliably. Same reason scan and two tone decode don't work reliably. Trying to mess with timing to make it work just means it's going to cut off the voice at the beginning of the transmission. That'll annoy users quickly.

MDC will often get through even when voice won't. I've always been surprised at how well it works on the fringes of coverage.

EOT is the way to go if you don't have a specific need to see the ID at the beginning of the message. Your time out timer on PTT should be set to something reasonable anyway, so waiting 60 seconds for the timeout timer to kick in isn't a big deal. It also addresses the scan issue.

 

[lucasec]

I use it just for sending alerts but the radios are never muted and never require a FS message to open up audio for my fleet of 10-20 Fleetsync capable Kenwood radios. I can send you a stripped-down codeplug for my NX300 if you want to see how I have my Fleetsync set up.

Thanks—this was helpful, I was able to follow along. Don't worry about sharing your file as I don't have D3N at the moment (only D1N).

In terms of what people actually use in production systems, would this be a fair characterization?

• 50%+ are only using MDC/FleetSync for Caller ID display
• After that, paging features (when paging is in use, do you also set alert tones to a fixed volume, or is the tone + LED is enough to get people's attention even when tone volume is linked to the radio volume?)
• Rare to see systems using true selective calling on analog, in the same sense as how DMR works, where radios only "hear" calls that are destined to them (individually or to a group they are a part of)

(intentionally leaving off AVL applications with GPS reporting and data/text messages)

 

[dryfb]

Thanks—this was helpful, I was able to follow along. Don't worry about sharing your file as I don't have D3N at the moment (only D1N).

In terms of what people actually use in production systems, would this be a fair characterization?

• 50%+ are only using MDC/FleetSync for Caller ID display
• After that, paging features (when paging is in use, do you also set alert tones to a fixed volume, or is the tone + LED is enough to get people's attention even when tone volume is linked to the radio volume?)
• Rare to see systems using true selective calling on analog, in the same sense as how DMR works, where radios only "hear" calls that are destined to them (individually or to a group they are a part of)

(intentionally leaving off AVL applications with GPS reporting and data/text messages)

In public safety systems, it's probably like 80 or 90%+ for only using caller ID. I know my county has selective calling set up (at least has a button for it) since I'll occasionally hear someone who accidentally is using select call but I've never seen or heard it used past that. Usually better to just keep stuff simpler for radio users.

I use fixed volume for a 2 tone set on my NX300 (I'm a photographer and I take a fair amount of fire pictures so I like to know when smth is happening, along with severe weather all calls), I have that set to selectable but I'd say linked to radio volume is fine *depending on radio discipline.* If your users have bad habits about leaving radio volume down then fixed or selectable may be better. For AVLs, I've used RADText to experiment and catch some aliases on NXDN but not really a commonly used thing, and GPS reports over fleetsync 1200 BPS are SLOW.

 

[lynskey85]

I run EOT for our PD. Running it BOT risks it stepping on someone talking. As soon as they release PTT, the ID will show. That's usually good enough to identify the user. For hobby use, you'll probably recognize the voice of the people you are talking to.

BOT should NOT risk it stepping on someone talking if programmed correctly with a sidetone and the users understand that they can't talk until the side tone ends. In fact I have found it to be EXTREMELY beneficial over the years for preventing people from clipping themselves at the beginning of a transmission when the radio is not opened up yet, particularly for subscribers transmitting into a repeater.

 

[mmckenna]

BOT should NOT risk it stepping on someone talking if programmed correctly with a sidetone and the users understand that they can't talk until the side tone ends. In fact I have found it to be EXTREMELY beneficial over the years for preventing people from clipping themselves at the beginning of a transmission when the radio is not opened up yet, particularly for subscribers transmitting into a repeater.

That's certainly an option.

Our officers didn't want sidetone, or anything else that made noises. They also were reluctant to have the delay. I provided both options, and they chose EOT.

 

[Kitn1mcc]

For the railroad stuff i run it all EOT just makes things easier