DSD+ I can see LRRP and ARS. Why there are no GPS positions?

[SignalPatcher]

Hello,
Recently I have been receiving transmittion and in the decoder I see LRRP and ARS. Why GPS coordinates is not displayed? Below I'm enclosing samples from completely various frequencies.
Best Regards.

168: http://1drv.ms/1NvgkCO

173: http://1drv.ms/1HdiCVP

 

[racingfan360]

Try this thread from a few weeks ago

http://forums.radioreference.com/vo...ding-software/319882-lrrp-not-displaying.html

 

[SignalPatcher]

I read this topic but I hardly understand something.

I have another recording:

172: http://1drv.ms/1QhAVeN

 

[racingfan360]

DSD+ only decodes Motorola ....you probably have a 3rd party LRRP based system.

 

[SignalPatcher]

So it's the base station sending signal, not the moving cars?

 

[racingfan360]

Right, DSD+ only decodes Motorola's MotoTRBO LRRP
There are other (3rd party) GPS formats which DSD+ will NOT decode.
If you know that the target system is using GPS but you are not seeing GPS co-ords in DSD+, then it isn't MotoTRBO LRRP you are listening to.

 

[SignalPatcher]

I see. Then, as there are other standards GPS, maybe anyone has any training about programming MotoTRBO LRRP?

 

[Forts]

I read this topic but I hardly understand something.

I have another recording:

172: http://1drv.ms/1QhAVeN

There are no LRRP entries in there at all, so either they aren't using it or as mentioned they are using a 3rd party solution. Companies such as neoTerra Systems offer GPS vehicle tracking and more using the option board within the radios. This type of telemetry is proprietary and unlikely to be decoded by DSDlus unless the specs can be found.

 

[SignalPatcher]

Hi,
I'm coming back to this topic with the new recordings.
As the photos show, in all of these recordings the GPS position is sent.
But they are not seen in Event.
But you can see them in logs.
Can it be corrected somehow?

168,6500: https://yadi.sk/d/15_m2gkJ3ESHVu

173,0375: https://yadi.sk/d/6DMIr6u-3ESHrt

172,5125: https://yadi.sk/d/KTNSrv3o3ESJb5

172,0750: https://yadi.sk/d/0h0CU3pv3ESKra

 

[morfis]

Something in the region of 300 miles between the first and last points. Two different countries?

I could show LRRP information decoded here - dsd+ beleives it's seeing valid position data and decodes it. Unfortunately the positions it shows are several thousand miles from here and my local bus company only operate here ;-)

One day it would be good to get the data decoded correctly but I imagine there is far more useful development going on and a handful of buses in some obscure town here isn't worth lookinmg at just yet.

 

[SignalPatcher]

Yes, these are two different countries. The transmissions fall under completely different senders.
And these definitely are not buses!
It might not be useful for you but everything I see in my region look this way:
Thus, I would like it to be improved.

 

[morfis]

Yes, these are two different countries. The transmissions fall under completely different senders.
And these definitely are not buses!

Who said anything about your logs being buses? I said the LRRP messages I see here are from buses and the positions appear to decode, but incorrectly.

 

[SignalPatcher]

If by 'buses' you mean 'vehicles', then you're right. Some of them are ambulances, for instance.

I will send some more recordings (e.g police vehicles) if I find any soon - but they will all look like those I've sent before.

 

[slicerwizard]

Who said anything about your logs being buses? I said the LRRP messages I see here are from buses and the positions appear to decode, but incorrectly.

Have you submitted any data (raw audio / where the buses are) to the DSD+ folks?

 

[G125]

DSDplus not detect frames LRRP if they are sent as Motorola Proprietary data.
DSDplus recognizes frame LRRP only if they are sent over UDP. Geographical positions are decoded only on some of them.

Latitude and longitude are stored using four bytes.
Longitude=x*180/FFFFFFFFhex deg. (for the northern hemisphere locations).
Latitude= x*360/FFFFFFFFhex deg. (for East of the Greenwich meridian).
Speeed is stored using two bytes
V=(v1+v2/128) m/s = 3,6*(v1+v2/128) km/h = 2,2369*(v1+v2/128) mph.
DSDplus takes into account only one byte - the speed is displayed with little accuracy.
The direction is coded using one byte: D=2*x.

 

[SignalPatcher]

...Have you submitted any data (raw audio / where the buses are) to the DSD+ folks?...

What exactly should I send? And to whom should I send it to? Cause nobody from this e-mail address has answered: dsdplusinformationminister@gmail.com

 

[G125]

Other packages where DSDPlus does not detect LRRP data:

 

[mtindor]

For anybody who has / can obtain raw audio that contains undecoded / improperly decoded LRRP, how about submitting raw audio? Problems can be fixed and new things can be supported if people would submit raw audio [using DSDPlus to record the raw audio].

1. Send raw audio to dsdplusfastlane@gmail.com

Send archived audio files, no larger than about 20 MB in size archived [since I think Gmail has a limit of 25 MB for attachments and the MIME encoding will take up a good chunk of that]. And if your archive of choice is ZIP, rename the archived file to .ZAP before sending to the Gmail address.

OR

2. upload the raw audio to some file sharing site of your choice [Google Drive, Mega, etc] and provide the link for download.

Really, you'd be surprised how much can be accomplished with good raw audio samples that will allow Da Minista to reproduce an issue / work on new protocol support.

Mike

PS: I'm sure the author is well aware that not all forms of LRRP are decoded by DSDPlus.

 

[Forts]

Nice work G125. I'm sure audio samples would be very useful if you can submit them.