• If posting about a radio issue: Include the HOST, DSP and UCM/secure firmware versions, flashcode and CPS version you're using along with the operating system info. This is critical information.

MotoTRBO DDMS and OTAP, pulling my hair out

max2770

Contributing Member
Joined
Feb 4, 2020
Messages
58
So I'm testing OTAP and ARS, and there's something I'm not getting right.

  • RM Server is running on Windows Server 2019
  • RM Job Scheduler and Device Monitor/Programmer are running on a laptop on the same domain
  • Control Station radio is connected to laptop by USB
  • DDMS service is running
  • RM Device Monitor successfully connects to PN server
If I disable PN Server in Device Monitor, OTAP is successful. If PN server is checked, device never populates in DM and stays pending forever.

I installed TransTRBO ARS Server/Watcher and the radios populate right away, works flawlessly. Even with max logging DDMS only returns "service has started".

It's not the firewall as I've tested with and without it enabled.

What the hell am I missing? Thanks!
 

phonebuff

Prolific Contributor
CS Forums $upporter
Joined
Nov 10, 2013
Messages
678
How big / busy a system is this ?

I am not sure DDMS will work with out MNIS, never really thought about this configuration.
 
OP
M

max2770

Contributing Member
Joined
Feb 4, 2020
Messages
58
I'm only testing so 5 radios on a dedicated channel. MNIS isn't needed because simplex.
 

TRENT310

Prolific Contributor
CS Forums $upporter
Joined
Nov 23, 2013
Messages
164
The main benefit to that presence watcher with subscribers running ARS is for multi-site Cap+ systems so the packet data traffic can be sent to the site in question where the subscriber has registered and not tie up RF resources at other sites unnecessarily, but in conventional or IPSC it will necessarily be repeated everywhere anyway.

For a "tactical OTAP" configuration between a control station and subscribers within simplex range perhaps the only benefit to having presence would be when you queue up the entire fleet for a job that it won't be trying to talk to radios that aren't switched on or aren't in range. It will try to reach them and then fail over and over in the device monitor. But whatever, it's not like in simplex there's any real traffic prioritization or any concept of data revert to an alternate timeslot (unless you're trying to use DCDM, which is not a configuration I've ever tried because of its undesirable behaviour if 2 subscribers decide to elect themselves as timing master). Basically the takeaway is you'd prevent RM job processor from retrying periodically and keying up the control station radio until the subscriber radio itself registers using ARS. Also one of the issues with the ARS implementation in TRBO is that it doesn't de-register when you leave the ARS-enabled personality for another one, or a non-ARS personality. It only de-registers if you power down while selected on that personality, so you'd still end up with radios the watcher thinks are still online but have switched to different personalities, until the inactivity timeout.

Is the ARS on the subscribers set to register to the radio ID of the control station, and all that? Have you set up ARS watcher passively without running its built-in server role and having the DDMS bound to that port? Is it bound to the correct interface for the radio CAI and not the system's other network interfaces?

Is this a permanent configuration that is worth spending all this time on or would you eventually be using this in an infrastructure (repeater) environment where you can just use MNIS/NAI Data and avoid the control station?
 
OP
M

max2770

Contributing Member
Joined
Feb 4, 2020
Messages
58
I fixed it, I had a rule on my domain firewall that was blocking communications somehow - not sure how the test application worked, but it's no longer an issue.

Thanks for the help!