I'm working on an RM system setup for our internal operations at work, and it's prompting me to have some questions that are a bit outside of my knowledge scope at this point. My system topology is the following:
TRBOnet Enterprise Server (Dispatch consoles)
Radio Management Server (containing RM server, job processor, DDMS, MNIS not currently running, and RM Client)
Radio Management Client in remote office (for USB programming jobs)
XPR4550 Control Station (since I don't have NAI data license for my SLR5700s)
I run USB programming jobs like a dream. OTAP also seems to work, but it seems rather odd to me in regards to how it operates. I've got ARS enabled on my radios, and they're programmed to reach out to the radio ID of the control station. I confirm that this works by running wireshark and watching the ARS packets come in and be acknowledged by DDMS. See below:
As you can see, line 5 & 6 detail an incoming ARS packet when the radio turns on, and an acknowledgement sent back. Line 9 details the radio sending an ARS packet when the radio turns off, and obviously no acknowledgement coming out.
So what I see as far as the weird behavior goes is this - OTAP jobs seem to complete whenever they want, and not right away if the radio is available. Obviously my system knows the status of the radio, as ARS packets are getting through and registering with DDMS which is sending an ack back. Sometimes OTAP jobs will run in 15 minutes after I send it to the test radio, sometimes it will take hours. Keep in mind that these are always just small writes, I am not trying to read whole CPs or anything. I've even tried "jump-starting" the process by forcing ARS on the radio by doing a system/site change or power cycling, and even that does not start up a Pending "Waiting for Radio" OTAP job. When the job eventually does load into device monitor and run, it's pretty fast.
Is there some rhyme or reason to this? Is this proper operation of OTAP? I plan on only using OTAP for our mobiles in our fleet vehicles, so sending periodic writes whenever we have contact changes or channel updates etc. Portables too, but at least I have the USB option there to make it a little more quick for instant updates. I can indeed ping the radios from my server via their converted radio ID/IP addresses.
It almost seems like DDMS is not notifying the Device Monitor that the presence of the radio is there, and that the OTAP job is just going out on a standard timer (like an RM system without presence would act normally. For clarity, I am running all these jobs on the same machine that the control station is hooked to and that DDMS and Device Monitor are running on. Firewall is off. Below is the result of a PN server communication test, so DM can get to DDMS on port 3000.
Any ideas on this? This is kind of intriguing me so I'm happy to be schooled by someone who knows more than me on this. I haven't called Motorola tech support yet, and am dreading having to do so, so I wanted to bring it to the table here first.
Thanks folks.
TRBOnet Enterprise Server (Dispatch consoles)
Radio Management Server (containing RM server, job processor, DDMS, MNIS not currently running, and RM Client)
Radio Management Client in remote office (for USB programming jobs)
XPR4550 Control Station (since I don't have NAI data license for my SLR5700s)
I run USB programming jobs like a dream. OTAP also seems to work, but it seems rather odd to me in regards to how it operates. I've got ARS enabled on my radios, and they're programmed to reach out to the radio ID of the control station. I confirm that this works by running wireshark and watching the ARS packets come in and be acknowledged by DDMS. See below:
As you can see, line 5 & 6 detail an incoming ARS packet when the radio turns on, and an acknowledgement sent back. Line 9 details the radio sending an ARS packet when the radio turns off, and obviously no acknowledgement coming out.
So what I see as far as the weird behavior goes is this - OTAP jobs seem to complete whenever they want, and not right away if the radio is available. Obviously my system knows the status of the radio, as ARS packets are getting through and registering with DDMS which is sending an ack back. Sometimes OTAP jobs will run in 15 minutes after I send it to the test radio, sometimes it will take hours. Keep in mind that these are always just small writes, I am not trying to read whole CPs or anything. I've even tried "jump-starting" the process by forcing ARS on the radio by doing a system/site change or power cycling, and even that does not start up a Pending "Waiting for Radio" OTAP job. When the job eventually does load into device monitor and run, it's pretty fast.
Is there some rhyme or reason to this? Is this proper operation of OTAP? I plan on only using OTAP for our mobiles in our fleet vehicles, so sending periodic writes whenever we have contact changes or channel updates etc. Portables too, but at least I have the USB option there to make it a little more quick for instant updates. I can indeed ping the radios from my server via their converted radio ID/IP addresses.
It almost seems like DDMS is not notifying the Device Monitor that the presence of the radio is there, and that the OTAP job is just going out on a standard timer (like an RM system without presence would act normally. For clarity, I am running all these jobs on the same machine that the control station is hooked to and that DDMS and Device Monitor are running on. Firewall is off. Below is the result of a PN server communication test, so DM can get to DDMS on port 3000.
Any ideas on this? This is kind of intriguing me so I'm happy to be schooled by someone who knows more than me on this. I haven't called Motorola tech support yet, and am dreading having to do so, so I wanted to bring it to the table here first.
Thanks folks.
Last edited:
