Results 1 to 14 of 14

Thread: IP Site connect and GPS tracking issues....pls help

  1. #1
    Join Date
    Sep 22, 2012
    Posts
    17
    Thanks
    4
    Thanked 1 Time in 1 Post

    Default IP Site connect and GPS tracking issues....pls help

    I have a customer with a 4 repeater IP Site connect system. We recently had to send a repeater in to fix a PA problem for the 3rd time, now this repeater will not pass GPS positons over the IP site connect. The voice still works over the site connect but the GPS is being lost or blocked for some reason. Here are the details.

    Repeater XPR8300 current firmware is 01.09.11 and the tracking software is Streettrek, all the voice and data is sent over slot one to a control station.

    I was able to take a stock repeater to the site that has an older firmware of 01.08.00 and it will pass GPS traffic on the Streettrek right away but I can't get it to work on the original repeater. I was unable to discuss this problem with the guys a Comtran who make the tracking software as I am sure they are quite busy with storms on the East Coast.

    Does anyone have any ideas as to what could be causing this problem? I tried to find the old firmware to downgrade the repeater but it is no longer available on Motorola Online.

    Thoughts?

    Thanks....


  2. #2
    Join Date
    May 30, 2012
    Posts
    226
    Thanks
    29
    Thanked 59 Times in 29 Posts

    Default

    There are multiple undocumented issues that occur when mixing firmware versions within IP Site Connect repeaters. You can't downgrade, so your only option is to either swap out the repeater, as you did for your testing, or upgrade all the repeaters to the same revision. Not to say that won't cause it's own issues, but at least then it'll be a 'supported' system. Oh, and you'll probably want to upgrade your base station's firmware as well, unless Comtran says otherwise.

  3. #3
    nfl123 No Longer Registered

    Default XPR8300 REPEATER

    Quote Originally Posted by Dorf411 View Post
    I have a customer with a 4 repeater IP Site connect system. We recently had to send a repeater in to fix a PA problem for the 3rd time, now this repeater will not pass GPS positons over the IP site connect. The voice still works over the site connect but the GPS is being lost or blocked for some reason. Here are the details.

    Repeater XPR8300 current firmware is 01.09.11 and the tracking software is Streettrek, all the voice and data is sent over slot one to a control station.

    I was able to take a stock repeater to the site that has an older firmware of 01.08.00 and it will pass GPS traffic on the Streettrek right away but I can't get it to work on the original repeater. I was unable to discuss this problem with the guys a Comtran who make the tracking software as I am sure they are quite busy with storms on the East Coast.

    Does anyone have any ideas as to what could be causing this problem? I tried to find the old firmware to downgrade the repeater but it is no longer available on Motorola Online.

    Thoughts?

    Thanks....
    Best Advise is to upgrade all repeaters to current firmware. I always make sure we keep the same firmware in all the repeaters if using IP site connect. I use a few systems with GPS Revert for Slot 2. My biggest problem is voice calls being missed when reporting over to slot 2 for GPS. There is supposed to be late entry but for some reason we can't seem to get radios with gps revert for slot 2 to rejoin a voice discussion on slot 1 when they go to report GPS. No one seems to be able to duplicate this in the lab and all we hear is it is a coverage issue. It's not a coverage issue becase when we have a radio with the GPS off side by side with a GPS enabled radio you can observe the issue. Very frustrating to us and the customer. The GPS seems flawed in IP Site Connect. I have pleaded with Motorola to come up with some sort of new coding for the radios so they can transmit their GPS upon Pre or post transmit, similar to the MDC1200 Signalling System. It would use up less air time and would almost guarantee no missed calls if they were able to somehow code the data stream correctly.

  4. #4
    Join Date
    May 30, 2012
    Posts
    226
    Thanks
    29
    Thanked 59 Times in 29 Posts

    Default

    Quote Originally Posted by nfl123 View Post
    Best Advise is to upgrade all repeaters to current firmware. I always make sure we keep the same firmware in all the repeaters if using IP site connect. I use a few systems with GPS Revert for Slot 2. My biggest problem is voice calls being missed when reporting over to slot 2 for GPS. There is supposed to be late entry but for some reason we can't seem to get radios with gps revert for slot 2 to rejoin a voice discussion on slot 1 when they go to report GPS. No one seems to be able to duplicate this in the lab and all we hear is it is a coverage issue. It's not a coverage issue becase when we have a radio with the GPS off side by side with a GPS enabled radio you can observe the issue. Very frustrating to us and the customer. The GPS seems flawed in IP Site Connect. I have pleaded with Motorola to come up with some sort of new coding for the radios so they can transmit their GPS upon Pre or post transmit, similar to the MDC1200 Signalling System. It would use up less air time and would almost guarantee no missed calls if they were able to somehow code the data stream correctly.
    I'm a little unclear on what you're saying here. TRBO uses the LRRP protocol, which means the field radios don't send a GPS update unless the AVL software (TRBOnet, NeoTerra, etc) requests them to. If your radio is involved in a voice call on slot 1, the software cannot send the LRRP to the radio until the voice activity on slot 1 has ended. Not saying you don't have an issue of some sort, but I'm trying to wrap my head around how it's coming about.

  5. #5
    nfl123 No Longer Registered

    Default

    Well, it was told (and my understanding) that if you checkmark LRRP in the radio settings of the subscriber, the radio remembers the update period of when to send GPS(wether it is using selected channel or revert). The Radios do have LRRP Checkmarked as per Street Trek Instructions. On occassion, we have gotten a number of end user complaints that the radios with GPS enabled are missing voice calls as opposed to radios that do not have gps enabled. There does not seem to be any late entry as I understood how it would work on the occassion the radio deciced to go report it's gps on the same instant a voice call were to happen.
    I guess my understanding is not as clear as it should. I have been working with Motorola on this issue and they seem to think the program settings are all correct. We did find out that for a system using IP Site connect, no matter what the radio, ALWAYS have IP Site Connect checked in all radios even if you utilize a base and it is dedicated to one site because there is some sort of timing issue that is necessary for the radio to work properly with the field check marked.
    Thank you for the reply.

  6. #6
    Join Date
    May 30, 2012
    Posts
    226
    Thanks
    29
    Thanked 59 Times in 29 Posts

    Default

    Quote Originally Posted by nfl123 View Post
    Well, it was told (and my understanding) that if you checkmark LRRP in the radio settings of the subscriber, the radio remembers the update period of when to send GPS(wether it is using selected channel or revert). The Radios do have LRRP Checkmarked as per Street Trek Instructions. On occassion, we have gotten a number of end user complaints that the radios with GPS enabled are missing voice calls as opposed to radios that do not have gps enabled. There does not seem to be any late entry as I understood how it would work on the occassion the radio deciced to go report it's gps on the same instant a voice call were to happen.
    I guess my understanding is not as clear as it should. I have been working with Motorola on this issue and they seem to think the program settings are all correct. We did find out that for a system using IP Site connect, no matter what the radio, ALWAYS have IP Site Connect checked in all radios even if you utilize a base and it is dedicated to one site because there is some sort of timing issue that is necessary for the radio to work properly with the field check marked.
    Thank you for the reply.
    Ok, you may be right, as all GPS systems I've worked with I've left the 'Persistent LRRP' box unchecked...mainly because neither the CPS help, or the system planner, nor could anyone at Motorola, really explain what the hell it did. If you leave it unchecked, the radio will act as I explained, and you won't have the issues. The software will wait until voice activity is completed, then it will send out it's requests. So, you end up with updates not always coming in exactly when they are supposed to, but the voice comms remain pretty much unaffected. If for instance the timing is set for 2 minutes, and there's 30 seconds of voice activity when the software wants to send it's request, it'll send it right after the voice call is completed, so you'll get that update a little later than the two minutes. Best thing is for you to try a few radios with the box unchecked & see if things work the way you want them to.

  7. #7
    nfl123 No Longer Registered

    Default

    I never really entertained the idea of not using LRRP. I wonder if that is the key. There is more dependency on the server to send more data over the voice channel-That was the reason why to check mark LRRP, to lower the amount of data being used over the voice channel when using GPS.
    I just don't know why they can't just send the ARS and any other data related messages for Conventional and IP Site connect over to a different slot. I was told that ARS really isn't needed for GPS purposes. It only exists for Text Message and E-mail Services, but since GPS is data, there's no way around the ARS message. Street Trek's latest version allows you to set their ARS Polling back to about two weeks. This means once the radio sends it's first ARS message to the server, Street Trek won't send another "hello" to the radio unit it reaches that 2 week period. You can set it for just about any 30 minute interval now with their new Server Software. The old Server Software used to poll radios every 30 minutes. Since they have changed it, I have not had an opportunity to try this on some current public safety systems because they don't want to jepordize voice communications. I was also told to turn off Data Call Confirmed. It just takes up more air time.
    I think there is a lot of different opinions about what does what between Motorola and Street Trek. Motorola says one thing and then Street Trek says another. Street Trek has had a better track record when it comes to GPS and Data questions.
    Again, I am working With Motorola on a few issues and hope to have some answers that I hope to share that will possibly benefit other users in the group.


    Also I used the new Version of 8.5 today. It won't let you program a radio with 25 KHz bandwidth in analog mode without a special Entitlement ID.
    So, if you want to avoid that for now, stick to version 8.0
    Keep in touch, I appreciate all the input you have offered.

  8. #8
    nfl123 No Longer Registered

    Default

    The other idea i was thinking of trying for Emergency Purposes only would be to program a channel with the Emergency Digital ID feature and with GPS enabled. If the officer hits the orange button the radio reverts to that channel with the same frequency information as their primary channel but now it is using another channel with GPS and ARS Enabled. Street Trek says they poll the radio's GPS once their server receives a Digital Emergency ID, but I wonder if it is long enough to get that information for the time it spends on that channel. I will have to test that idea in the lab, I just haven't had time yet.

  9. #9
    Join Date
    May 30, 2012
    Posts
    226
    Thanks
    29
    Thanked 59 Times in 29 Posts

    Default

    Quote Originally Posted by nfl123 View Post
    I never really entertained the idea of not using LRRP. I wonder if that is the key. There is more dependency on the server to send more data over the voice channel-That was the reason why to check mark LRRP, to lower the amount of data being used over the voice channel when using GPS.
    I'm not sure it lowers the data? I haven't used Street Trek, but others do not have any parameters to realize the radio is using persistent LRRP as opposed to not, and will send the LRRP request out at the timed intervals regardless. I'm wondering if it isn't creating more data traffic.

    Quote Originally Posted by nfl123 View Post
    I just don't know why they can't just send the ARS and any other data related messages for Conventional and IP Site connect over to a different slot. I was told that ARS really isn't needed for GPS purposes. It only exists for Text Message and E-mail Services, but since GPS is data, there's no way around the ARS message.
    Agreed, I don't understand why all data can't be reverted in conventional mode either...they can do it in Capacity Plus, so why not? ARS is needed for GPS as it allows the AVL software to know when to begin sending the location requests, and also know when to stop sending them when the radio goes off-line. This is how it works without persistent LRRP, at least.

    There's like 400+ pages for the MotoTRBO system planner, and "persistent LRRP" is mentioned once, but it's in relation to something else, so there's no explanation of it whatsoever.

  10. #10
    nfl123 No Longer Registered

    Default

    We were always told to use persistent LRRP because with that setting checked marked the radio stores in it, the GPS Interval. This is supposed to reduce the amount of DATA over the radio system so the Street Trek Server (or any other 3rd party GPS Server) doesn't have to tie up the channel with polling data. LRRP reduces the data rate down to half since the Server does not need to poll the radio. The only time the GPS Server talks to the radio about polling intervals is when you make a change in the polling interval. The GPS Server then tells the radio to store the new polling time in it and that's all.

    I believe there's a way to code the radio with new firmware so you can send the GPS information as a pre or post format of a voice transmission. If they do it that way, it would work ideally for my customer situation. The only time we really need to know where someone is at is when they transmit. If you do it that way, I think it would use less air time with data packets going back and forth.

  11. #11
    Join Date
    May 30, 2012
    Posts
    226
    Thanks
    29
    Thanked 59 Times in 29 Posts

    Default

    Quote Originally Posted by nfl123 View Post
    We were always told to use persistent LRRP because with that setting checked marked the radio stores in it, the GPS Interval. This is supposed to reduce the amount of DATA over the radio system so the Street Trek Server (or any other 3rd party GPS Server) doesn't have to tie up the channel with polling data. LRRP reduces the data rate down to half since the Server does not need to poll the radio. The only time the GPS Server talks to the radio about polling intervals is when you make a change in the polling interval. The GPS Server then tells the radio to store the new polling time in it and that's all.
    I like the concept, still not sure how it's set in the server to know not to poll the radio, as I haven't seen a setting to that effect. Perhaps the radios tell the server if their persistent LRRP box is checked? It would be nice to find some actual Motorola/ADP documentation that actually describes the operation.

    Quote Originally Posted by nfl123 View Post
    I believe there's a way to code the radio with new firmware so you can send the GPS information as a pre or post format of a voice transmission. If they do it that way, it would work ideally for my customer situation. The only time we really need to know where someone is at is when they transmit. If you do it that way, I think it would use less air time with data packets going back and forth.
    I haven't seen that setting yet in TRBO...NexEdge radios can be made to do it though!

  12. #12
    Join Date
    Sep 22, 2012
    Posts
    17
    Thanks
    4
    Thanked 1 Time in 1 Post

    Default

    Just an update, I did get my problem somewhat solved. I first tried some testing in house with two repeaters, a base and a portable w/gps for testing of a simple IPSC system on our LAN. Everything had updated firmware and I still could not get the gps to track properly on the TREKSERVER. Since I had to familiarize myself with TRBODVR for another customer I did some testing on TRBODVR and everything worked fine with old and new firmware so the best solution was to upgrade the system with problems from STREETTREK SERVER to TRBODVR and the problem was solved.

    One thing I noticed with LRRP is that if you do any messing around with a subscriber on a test system and an alternate ARS and GPS ID the radio will continue to attempt to send to the test destination. For example, if you normally send GPS and ARS to 16448250 and want to play a game for a while and change it to 648250 for some testing and then program the radio back to normal when you are done playing you will see on TRBODVR that the subscriber is sending GPS to both 16448250 and 648250. It will continue to do that till you read the radio, uncheck LRRP write the radio, the recheck LRRP and write again. After that it will only attempt to send to 16448250.

  13. #13
    Join Date
    May 30, 2012
    Posts
    226
    Thanks
    29
    Thanked 59 Times in 29 Posts

    Default

    That is very interesting, about the radio sending the updates to two different ID's...thanks for the update!

  14. #14
    Join Date
    Dec 12, 2012
    Location
    CA
    Posts
    8
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    I have worked wit Trbo Net and Smart PTT and they all have that same issue with GPS.You have to use the same firmware with every repeater in IPS connect otherwise it wont work correct.