RadioReference on Facebook   RadioReference on Twitter   RadioReference Blog
 

Go Back   The RadioReference.com Forums > Software > Trunking Control Channel Decoding

Trunking Control Channel Decoding For discussion of installation, setup, configuration, and use of the Trunker / Unitrunker digital decoding utilities (for decoding Trunking control channels)

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #61 (permalink)  
Old 06-22-2014, 1:41 PM
shifty21's Avatar
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: May 2014
Location: Sarnia, Ontario
Posts: 39
Default Here's my error

Just nicely updated my Java. I'm using an Acer Netbook Aspire One running Windows XP 32bit.
I've attached my error. I've looked for a sdrtrunk gui file but didn't see one.
Attached Images
 

Last edited by shifty21; 06-22-2014 at 1:42 PM.. Reason: I dislike spelling errors...
Reply With Quote
Sponsored links
  #62 (permalink)  
Old 06-22-2014, 1:56 PM
jazzbassNick's Avatar
Member
  Audio Feed Provider
Audio Feed Provider
 
Join Date: Jul 2012
Location: San Gabriel CA
Posts: 111
Default

Looks like it's running in a different directory. gui.SDRTrunk is in the.jar file.
This command:
Code:
java -cp "SDRTrunk.jar;libs/*;config/*;http://forums.radioreference.com/images/*" gui.SDRTrunk
needs to run in the same directory as SDRTrunk.jar and the folders.
Double-clicking the .bat file works correctly or navigating your command prompt to the folder then typing
Code:
run_sdrtrunk_windows.bat
would work.
__________________
Happily broadcasting LASD, Temple Station Feed

Sharing ADSB data with PlanePlotter, live-military-mode-s.eu, libhomeradar, flightradar24, vrs-europe.eu, MilAirComms

Last edited by jazzbassNick; 06-22-2014 at 2:03 PM.. Reason: detail of the path added from my desktop. Initial reply via phone
Reply With Quote
  #63 (permalink)  
Old 06-22-2014, 2:11 PM
shifty21's Avatar
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: May 2014
Location: Sarnia, Ontario
Posts: 39
Default

That was the issue. Thanks Nick
Reply With Quote
  #64 (permalink)  
Old 06-23-2014, 1:58 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Apr 2014
Location: Pedricktown, NJ
Posts: 6
Default

Nice I can't wait to give this a try when my other dongle shows up tomorrow. I was looking to monitor trunking systems in my area and this looks to make a world easier.
Reply With Quote
  #65 (permalink)  
Old 07-02-2014, 1:28 PM
inigo88's Avatar
California DB Admin
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Oct 2004
Location: Kern County, CA
Posts: 1,566
Default

Hey Denny,

I am running into the exact same problem as gator did with Passport on page 1 of this thread, only this time I am using an RT820 tuner SDR (he was using line-in from a Pro-92 discriminator tap). In both cases the system messages pass the error correction test, but appear to be random in nature - different DCC, Home Site IDs, Talkgroups, Message Types, etc.

Here's an example from the same conversation on the same talkgroup:

Code:
00:00:03	Passport	Pass	CALL TG:43025/**UNKNOWN** SITE:077 CHAN:0139/0.00000 FREE:1259/0.00000	

101011000 10 00010001011 1001101 1010100000010001 0000 10011101011 00011010

(0x158) DCC:2 GOTO:139  HSID:77   TGID:43025   Type:0  FREE:1259   CRC


00:29:10	Passport	Pass	CALL TG:23469/**UNKNOWN** SITE:029 CHAN:0446/0.00000 FREE:1708/0.00000	

101011000 01 00110111110 0011101 0101101110101101 0001 11010101100 01001010

(0x158) DCC:1  GOTO:446  HSID:29   TGID:23469   Type:1  FREE:1708  CRC

00:30:19	Passport	Pass	CALL TG:58997/**UNKNOWN** SITE:002 CHAN:0161/0.00000 FREE:322/0.00000	

101011000 11 00010100001 0000010 1110011001110101 0000 00101000010 00010011

(0x158) DCC:3 GOTO:161  HSID:2   TGID:58997   Type:0  FREE:322   CRC

00:32:06	Passport	Pass	UNKNOWN SITE:041 CHAN:0392/0.00000 FREE:747/0.00000 TYP:12 TG:40258	

101011000 11 00110001000 0101001 1001110101000010 1100 01011101011 00011011

(0x158) DCC:3 GOTO:392  HSID:41   TG?:40258   Type:12  FREE:747    CRC
The messages also don't seem to be decoded in real time. They lag behind the conversation (sometimes appearing when nothing is being received at all). I also don't get any "IDLE" messages when receiving the idle bursts every three seconds (which should be type 1 messages indicating the registering LCN and site numbers of neighboring sites). As you can see above, the talkgroup ID varies during the conversation, as do the site number and DCC (which, like an LTR area bit, should stay consistent throughout the system).

I suspect the error is around where the program turns the subaudible data into binary symbols. The 0x158 sync pattern (101011000) correctly appears at the beginning of each OSW and the error detection says "Pass", but what follows doesn't make sense.

For reference, I found an old thread about decoding Passport OSWs I contributed to here (although I've since forgotten everything I knew about it ): LTR Passport Decoder Project
Reply With Quote
Sponsored links
        
  #66 (permalink)  
Old 07-02-2014, 9:43 PM
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Feb 2010
Location: Fulton, NY
Posts: 119
Default

Quote:
Originally Posted by inigo88 View Post
Hey Denny,

I am running into the exact same problem as gator did with Passport on page 1 of this thread, only this time I am using an RT820 tuner SDR (he was using line-in from a Pro-92 discriminator tap). In both cases the system messages pass the error correction test, but appear to be random in nature - different DCC, Home Site IDs, Talkgroups, Message Types, etc.

Here's an example from the same conversation on the same talkgroup:

Code:
00:00:03	Passport	Pass	CALL TG:43025/**UNKNOWN** SITE:077 CHAN:0139/0.00000 FREE:1259/0.00000	

101011000 10 00010001011 1001101 1010100000010001 0000 10011101011 00011010

(0x158) DCC:2 GOTO:139  HSID:77   TGID:43025   Type:0  FREE:1259   CRC


00:29:10	Passport	Pass	CALL TG:23469/**UNKNOWN** SITE:029 CHAN:0446/0.00000 FREE:1708/0.00000	

101011000 01 00110111110 0011101 0101101110101101 0001 11010101100 01001010

(0x158) DCC:1  GOTO:446  HSID:29   TGID:23469   Type:1  FREE:1708  CRC

00:30:19	Passport	Pass	CALL TG:58997/**UNKNOWN** SITE:002 CHAN:0161/0.00000 FREE:322/0.00000	

101011000 11 00010100001 0000010 1110011001110101 0000 00101000010 00010011

(0x158) DCC:3 GOTO:161  HSID:2   TGID:58997   Type:0  FREE:322   CRC

00:32:06	Passport	Pass	UNKNOWN SITE:041 CHAN:0392/0.00000 FREE:747/0.00000 TYP:12 TG:40258	

101011000 11 00110001000 0101001 1001110101000010 1100 01011101011 00011011

(0x158) DCC:3 GOTO:392  HSID:41   TG?:40258   Type:12  FREE:747    CRC
The messages also don't seem to be decoded in real time. They lag behind the conversation (sometimes appearing when nothing is being received at all). I also don't get any "IDLE" messages when receiving the idle bursts every three seconds (which should be type 1 messages indicating the registering LCN and site numbers of neighboring sites). As you can see above, the talkgroup ID varies during the conversation, as do the site number and DCC (which, like an LTR area bit, should stay consistent throughout the system).

I suspect the error is around where the program turns the subaudible data into binary symbols. The 0x158 sync pattern (101011000) correctly appears at the beginning of each OSW and the error detection says "Pass", but what follows doesn't make sense.

For reference, I found an old thread about decoding Passport OSWs I contributed to here (although I've since forgotten everything I knew about it ): LTR Passport Decoder Project
With only 7 bits of CRC for each message, there will be a number of random noise bit sequences that both start with the proper sync pattern and pass the CRC check that will be flagged as valid and decoded. The decoder runs continuously attempting to decode messages, even when nobody is transmitting. Any bit sequence that starts with the SYNC and passes the CRC will be decoded/displayed.

These invalid messages should be easy to spot, especially when they're in the middle of a valid call message stream, or when they occur randomly on an idle channel.

You'll see these random invalid (noise) messages on both the LTR and Passport decoders.

Other than these invalid messages, are you seeing valid decoded Passport messages and call sequences?
Reply With Quote
  #67 (permalink)  
Old 07-02-2014, 11:05 PM
inigo88's Avatar
California DB Admin
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Oct 2004
Location: Kern County, CA
Posts: 1,566
Default

Unfortunately not that I can see. Each time they key up (same talkgroup based on conversation, same frequency) it appears as a different combination of DCC, GOTO LCN, HSID, Talkgroup, Message Type and FREE LCN. So far I haven't seen a pattern and it appears to be random. I'll post a screenshot later tonight.

Thanks again!
Reply With Quote
  #68 (permalink)  
Old 07-03-2014, 5:53 AM
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Feb 2010
Location: Fulton, NY
Posts: 119
Default

Quote:
Originally Posted by inigo88 View Post
Unfortunately not that I can see. Each time they key up (same talkgroup based on conversation, same frequency) it appears as a different combination of DCC, GOTO LCN, HSID, Talkgroup, Message Type and FREE LCN. So far I haven't seen a pattern and it appears to be random. I'll post a screenshot later tonight.

Thanks again!
If you are not already doing so, can you try using one of the lower sample rates ( .240 MHz, or .288 MHz ) while you are decoding. On my R820T, I get significant frequency drift with the higher sample rates and have to continually adjust the PPM correction. But, with the lower rates I set the PPM and it will run for days and won't need an adjustment.

Are you hearing the callup conversations via sdrtrunk or via another scanner/source? If you are hearing the conversation via sdrtrunk, there should be approximately 3-4 messages per second displayed during the call. I'm attaching a screenshot of a callup & fleetsync gps burst decode from a local passport channel for comparison.

Can you make a baseband I/Q recording of the passport channel during a call and post it?
Attached Images
 

Last edited by DSheirer; 07-03-2014 at 6:09 AM.. Reason: screenshot
Reply With Quote
  #69 (permalink)  
Old 07-03-2014, 1:41 PM
inigo88's Avatar
California DB Admin
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Oct 2004
Location: Kern County, CA
Posts: 1,566
Default

Thank you so much Denny, that did it!!!

I thought I had tried all combinations of sample rate, but I guess I didn't try as low as 0.240 MHz (my RT820 defaulted to 0.960 MHz, which wasn't working at all). Also I noticed this when I first bought the SDR, but other programs like SDR# also default to the lowest gain setting, and my RT820 required the highest setting (Master gain of 495 in my case).

For reference, I suspect this is the same problem "gator" was experiencing with his Passport decoding on page 1 of this thread.

Thanks again!
Reply With Quote
Sponsored links
  #70 (permalink)  
Old 07-20-2014, 8:32 PM
Member
   
Join Date: Dec 2009
Location: Edmonton, Alberta
Posts: 92
Unhappy Tuner unrecognized

Hi.

I've got several Nooelec R820T tuners. They all work with SDR# & Unitrunker, but I am unable to get them to work with SDRTrunk.

I have made sure I am using the latest version (with R820T support).
I have reinstalled the latest version of Zadig several times.
Have performed reboots, and restarts of SDRTrunk.
I have also plugged the SDR dongle in, waited 2 minutes, then launched SDRTrunk to see if it would work. All to no avail...

I simply get the following message,
"SDRTrunk does not support RTL2832 with [UNKNOWN] tuner". See image below.

Probably the oddest part of the story is, I did get it to run the very first time I tried it, and was able to monitor an LTR system for a couple of hours . I just haven't been able to get it to work since!

I can't imagine it is a driver issue - since all the other software is working fine with these tuners. I don't really know what else to try at this stage, but I'd love to be collecting some info on the local LTR networks that are not well documented in the RR DB.

System is an i7 laptop running Windows 8.1.

Anyone got any clues on this?
Attached Images
 
Reply With Quote
  #71 (permalink)  
Old 07-21-2014, 12:23 AM
Ghstwolf62's Avatar
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: May 2006
Location: Clifton Forge Virginia
Posts: 510
Default

Quote:
Originally Posted by rabrol View Post
Hi.

I've got several Nooelec R820T tuners. They all work with SDR# & Unitrunker, but I am unable to get them to work with SDRTrunk.

I have made sure I am using the latest version (with R820T support).
I have reinstalled the latest version of Zadig several times.
Have performed reboots, and restarts of SDRTrunk.
I have also plugged the SDR dongle in, waited 2 minutes, then launched SDRTrunk to see if it would work. All to no avail...

I simply get the following message,
"SDRTrunk does not support RTL2832 with [UNKNOWN] tuner". See image below.

Probably the oddest part of the story is, I did get it to run the very first time I tried it, and was able to monitor an LTR system for a couple of hours . I just haven't been able to get it to work since!

I can't imagine it is a driver issue - since all the other software is working fine with these tuners. I don't really know what else to try at this stage, but I'd love to be collecting some info on the local LTR networks that are not well documented in the RR DB.

System is an i7 laptop running Windows 8.1.

Anyone got any clues on this?
I don't know if this will help but I got that when the dongle was tied up with something else. Someone said something about programs keeping the dongle to themselves or something like that a while back and it started working as soon as I got the dongle unaffiliated with whatever was holding onto it.

For instance now I still get that on the other dongle I have plugged in when I run the program. It works on the dongle used for SDR Trunk but says what yours says on the other dongle plugged in.

See if you can unaffiliate your dongles completely then before doing anything else run SDR trunk with your dongle plugged back in and reset.

Hopefully that will work and someone who understands computer stuff can explain it better than I for you.
__________________
KJ4KFW
One of the few in the world apparently with radios & scanners that actually work like they're supposed to.
Reply With Quote
  #72 (permalink)  
Old 07-21-2014, 5:41 AM
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Feb 2010
Location: Fulton, NY
Posts: 119
Default

Quote:
Originally Posted by rabrol View Post
Hi.
I have made sure I am using the latest version (with R820T support).
I have reinstalled the latest version of Zadig several times.
Have performed reboots, and restarts of SDRTrunk.
I have also plugged the SDR dongle in, waited 2 minutes, then launched SDRTrunk to see if it would work. All to no avail...
The error is being thrown when SDRTrunk tries to claim the dongle in order to determine the tuner type. A libusb error #12 means that SDRTrunk couldn't claim the device.

Probable causes are A) another application or process has already claimed the dongle or B) your user account in Windows doesn't have privilege to use the dongle.

Since it worked for you previously, I would suspect that A) is the cause. But, all of the troubleshooting steps you've described are what I would recommend to attempt resolving the issue.

Do you have any software applications set to autostart when Windows boots that might be claiming the device?
Reply With Quote
  #73 (permalink)  
Old 07-21-2014, 9:03 PM
Member
   
Join Date: Dec 2009
Location: Edmonton, Alberta
Posts: 92
Default

Quote:
Originally Posted by DSheirer View Post
The error is being thrown when SDRTrunk tries to claim the dongle in order to determine the tuner type. A libusb error #12 means that SDRTrunk couldn't claim the device.

Probable causes are A) another application or process has already claimed the dongle or B) your user account in Windows doesn't have privilege to use the dongle.

Since it worked for you previously, I would suspect that A) is the cause. But, all of the troubleshooting steps you've described are what I would recommend to attempt resolving the issue.

Do you have any software applications set to autostart when Windows boots that might be claiming the device?
Quote:
Originally Posted by DSheirer View Post
The error is being thrown when SDRTrunk tries to claim the dongle in order to determine the tuner type. A libusb error #12 means that SDRTrunk couldn't claim the device.

Probable causes are A) another application or process has already claimed the dongle or B) your user account in Windows doesn't have privilege to use the dongle.

Since it worked for you previously, I would suspect that A) is the cause. But, all of the troubleshooting steps you've described are what I would recommend to attempt resolving the issue.

Do you have any software applications set to autostart when Windows boots that might be claiming the device?
Thanks for the insights and suggestions guys. However I'm still rather confused by this.

I have checked to see if any other software would be claiming the dongle. I can't see any.
I know that Unitrunker or SDRShapr won't run if another program has claimed the device. For example both are unable to claim the device - whichever started using it first gets it.

However, I can launch SDR Sharp and use the dongle. I can then close SDR Sharp and launch Unitrunker and claim the dongle. Then I can close Unitrunker, go back to SDRSharp and use it again with no problems. When these 2 programs seize the device, they get it. The point is, both these programs are able to seize the device (so long as the other isn't running). Additionally RTL1090 can seize the device too if no other software is using it.

No such joy with SDRTrunk.

Since these other pieces of software do not see the device as claimed, and I can open & close them at will, I am lead to believe that the device isn't being claimed by something else - otherwise these other softwares could not use it when I started them.

I also tried disabling antivirus, laptop USB charging software, truecrypt, dropbox, disabled bluetooth, etc, all to no avail.

I guess that leaves me with the question, what else can cause an error 12 if no other software is claiming the device?

Perhaps that would lead to option B. However my main user account is the only account on this machine - administrator level (except for the windows default Guest account which is never used). I did attempt right-clicking the startup bat script as selecting "Run as administrator" but the script would not run that way. I also ran the script directly from the command prompt, and ran in to the same issue. SDRTrunk loads, but the tuner is still listed as unknown.

As you know I've tried rebooting, and reinstalling the drivers (which seems unnecessary given that the other programs can "speak to" the device).

Is there something I'm missing here? Any other things I can try?
Thanks again for your help in trying to solve this!
Reply With Quote
  #74 (permalink)  
Old 07-22-2014, 12:18 AM
Ghstwolf62's Avatar
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: May 2006
Location: Clifton Forge Virginia
Posts: 510
Default

Have you tried removing all dongles you have. Unplugging anything remotely connected to anything SDR then rebooting computer and putting dongle back in followed by running SDR Trunk?

Don't do anything else with dongles or programs except put dongle in hole and start SDR Tunk. Do not run any other SDR programs of any kind first.

That's what solved it on mine. Then placed other dongles back in and didn't have a problem again.

I've found SDR in general to be very picky about weird stuff. For instance programming radios seems to give SDR absolute fits. I programmed my Trbo radio and Wouxun radio the other night and all my SDR programs/dongles refused to work at all after that.

Finally removing everything SDR related from ANY USB port and plugging them back in for whatever reason reset things and all worked great after.

Have to do that from time to time but have no idea why.

Thanks Dsheirer, I knew someone would explain it and make some sense.
__________________
KJ4KFW
One of the few in the world apparently with radios & scanners that actually work like they're supposed to.
Reply With Quote
  #75 (permalink)  
Old 07-22-2014, 3:25 AM
joeuser's Avatar
Member
  Shack Photos
Shack photos
Premium Subscriber
Premium Subscriber
 
Join Date: Feb 2014
Location: North Central Kansas
Posts: 586
Default

This above or something is starting up with your system grabbing the dongle. You'd want to dig into administrative tools & system configuration...
__________________
-BCD436HP,BCD996XT,BC780XLT(x2),UBC780XLT -DX-440,Pro-21A -Pro-197(x4),Pro-164(x2) -Trident TRX-100XLT | UV-5R w/ NA-771(x2) | R820T(x2), UniTrunker, DSD+ | -RG-8/U -Discone & ST2 @ ~1600ft elevation
Reply With Quote
Sponsored links
  #76 (permalink)  
Old 07-22-2014, 6:00 AM
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Feb 2010
Location: Fulton, NY
Posts: 119
Default

Rabrol,

I posted a new sdrtrunk build to the download folder that has added DEBUG logging to help in figuring out which specific operation is causing the error. Could you please download and run that version and post the application log file to the google groups support forum.

Download:
https://drive.google.com/folderview?...0k&usp=sharing

Support Forum:
http://groups.google.com/group/sdrtrunk

Your application log file should be stored at:
c:\Users\retka_000\SDRTrunk\logs\

I'm going to be out of town through Sunday afternoon with CAP, but I'll dig into the log file when I get back and see if we can get SDRTrunk working for you.

Denny
Reply With Quote
  #77 (permalink)  
Old 07-22-2014, 12:25 PM
Member
   
Join Date: Dec 2009
Location: Edmonton, Alberta
Posts: 92
Default

Quote:
Originally Posted by DSheirer View Post
Rabrol,

I posted a new sdrtrunk build to the download folder that has added DEBUG logging to help in figuring out which specific operation is causing the error. Could you please download and run that version and post the application log file to the google groups support forum.

Download:
https://drive.google.com/folderview?...0k&usp=sharing

Support Forum:
http://groups.google.com/group/sdrtrunk

Your application log file should be stored at:
c:\Users\retka_000\SDRTrunk\logs\

I'm going to be out of town through Sunday afternoon with CAP, but I'll dig into the log file when I get back and see if we can get SDRTrunk working for you.

Denny
Hi Denny.
I'm at work right now, but will do this over the next few days and post via the Google Group.
Thanks for the support!

Rob
Reply With Quote
  #78 (permalink)  
Old 07-23-2014, 3:14 AM
Member
   
Join Date: Jul 2011
Posts: 17
Default

Great project! Unfortunately can't try it because local services are using NEXEDGE equpment, so consider this as one more request for NXDN decoder (take a look as this....it may help you NXDN Control Channel Decoder - Anritsu America )
Reply With Quote
  #79 (permalink)  
Old 07-23-2014, 8:27 AM
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Feb 2010
Location: Fulton, NY
Posts: 119
Default

Quote:
Originally Posted by detelazurno View Post
Great project! Unfortunately can't try it because local services are using NEXEDGE equpment, so consider this as one more request for NXDN decoder (take a look as this....it may help you NXDN Control Channel Decoder - Anritsu America )
I just started on an fsk4 decoder for p25, so nxdn shouldn't be too far behind that.
Reply With Quote
  #80 (permalink)  
Old 07-23-2014, 8:37 AM
Member
   
Join Date: Jul 2011
Posts: 17
Default

Quote:
Originally Posted by DSheirer View Post
I just started on an fsk4 decoder for p25, so nxdn shouldn't be too far behind that.
I'm glad to hear that!
As you know there is some frequency drift, so do you plan to make something like autotuner (or call it whatever you like) to follow the peak of the frequency, BUT based on the IF input singal as it is much more accurate than what you see on the spectrum no matter how good PPM corection is?
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT -5. The time now is 3:04 PM.


Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
All information here is Copyright 2012 by RadioReference.com LLC and Lindsay C. Blanton III.Ad Management by RedTyger
Copyright 2011 by RadioReference.com LLC Privacy Policy  |  Terms and Conditions