Watching the voice channels, there are no indications as to which LCN they are.

More hunting...

Thanks,
tpg

No... the voice channels don't really share a lot of information other than the network ID and site #. Since the control channel is telling the radios to go to voice channel XX, and that information is stored in the radio itself, there isn't really a need for the voice channel to announce which LCN it is. The best you can really do is compile a list of all the active frequencies per site then (as mentioned above) use one scanner to monitor the control channel and a 2nd one to see where the calls get directed. The LCN order isn't overly important to us anyways, since you can't program a Connect Plus system into a real radio for passive monitoring (it demands to affiliate before it will do anything, and you need the Connect Plus option board in your radio too).

Note that from this build onwards you will need to have Java 7 installed to run the program. To find out which version you have installed go to a command prompt and type "java -version" if you don't see something like "java version 1.7.0" or the program doesn't run then you need to upgrade. The upgrade can be downloaded from for free here ..

The only change in Build 57 is that it should decode the Connect Plus CSBKO 01 FID=6 PDUs. These display the site IDs of neighbouring sites in a multi site system.

Seems to be working for me. Just so other knows, they shouldn't be alarmed if they see 0,0,0,0,0 as the neighbor list. Apparently it isn't mandatory that this information be sent over the control channel. On a wide area system (18+ sites) that I monitor, only two site control channels broadcast anything other than 0,0,0,0,0

Or, if all control channels for all CP sites must send this info, then there may be something wrong in DMRDecode.

Mike

__________________
Mike / AA8IA
PSR800/PRO197/BCD436HP/BCD536HP

If I PM you about a submission, please reply promptly or your submission may be rejected.

I've looked back at some logs I made back in the spring and found several sites that were not broadcasting any neighbor info either.... but they are now. So perhaps it's just a matter of the system's techs getting back to the sites to update things as the system comes online and expands.

Hello All
This morning with no warning Github announced that users can no longer use their site to distribute program binaries. This means that while I can still store and share the DMRDecode source code on Github I can no longer leave the binary .JAR files on there for you to download. So at short notice I have created a new download page which can be found here ..

Please use this URL to download all future versions of DMRDecode until further notice. The old Github download page is still in existence but I can no longer upload new files to it and more annoyingly can't delete the old build (57) which is still on there and may be stuck there forever.

Build 58 now displays ¾ Data Continuation PDUs as raw binary. However you won't make any sense of them at the moment as they are convolution coded but this is a first step.

So I see TRBO firmware 1.11.02 has been released, which includes the new 'restricted access to system' feature. From the release notes:

Quote:

Restricted Access to System (RAS): prevents the unauthorized subscriber users from using the repeaters in the radio system and listening to repeater outbound voice/data/CSBK transmission, through the use of RAS Key authentication and Radio ID Range Check. This feature is supported on all MOTOTRBO subscriber platforms, as well as on XPR8300. XPR8400, XPR8380 and MTR3000 repeaters.

I wonder if this simply prevents the radio from listening to outbound transmissions, or if the repeater output will be 'encrypted' with the RAS key. If this is the case then DMRDecode/DSD etc won't work so well

So I see TRBO firmware 1.11.02 has been released, which includes the new 'restricted access to system' feature. From the release notes:

I wonder if this simply prevents the radio from listening to outbound transmissions, or if the repeater output will be 'encrypted' with the RAS key. If this is the case then DMRDecode/DSD etc won't work so well

Sounds to me like DSD / DMRDecode users will be fsck'd.

Mike

__________________
Mike / AA8IA
PSR800/PRO197/BCD436HP/BCD536HP

If I PM you about a submission, please reply promptly or your submission may be rejected.

I wonder if this simply prevents the radio from listening to outbound transmissions, or if the repeater output will be 'encrypted' with the RAS key. If this is the case then DMRDecode/DSD etc won't work so well

Interesting. To be honest I always wondered why DMR didn't have this feature in the first place when other digital systems (Tetra etc) did. However lets see what we actually get in practice when someone actually starts to monitor one of these systems.Remember that previous announcements from certain radio companies tend to sound a lot worse than they actually turn out to be.

I suspect its a header that will be incorporated int the sent data stream. If you dont have the header you cant access the system. On RX it may be a matter of looking for a matching header. Adding a layer of encryption can be a pain especially if the user is already running one of the 2 current types of encryption.

The RAS key is a text string (similar to enhanced privacy) and is programmed via the CPS to repeaters and subscribers. A repeater(s) can also be programmed with an I.D range check... If 'your' I.D does not match- the radio will not TX/RX via the repeater.

Both of these new systems can be used together, or own there own.

I am guessing the RAS key will be transmitted from both the subscriber unit and repeater on every transmission... Hopefully Ian can work his magic to decode the text string

The RAS key is a text string (similar to enhanced privacy) and is programmed via the CPS to repeaters and subscribers. A repeater(s) can also be programmed with an I.D range check... If 'your' I.D does not match- the radio will not TX/RX via the repeater.

Both of these new systems can be used together, or own there own.

I am guessing the RAS key will be transmitted from both the subscriber unit and repeater on every transmission... Hopefully Ian can work his magic to decode the text string