SDRTrunk
- Thread starter DSheirer
- Start date
- Status
jazzbassNick
Member
Looks like it's running in a different directory. gui.SDRTrunk is in the.jar file.
This command:
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
would work.
This command:
Code:
java -cp "SDRTrunk.jar;libs/*;config/*;http://forums.radioreference.com/images/*" gui.SDRTrunkDouble-clicking the .bat file works correctly or navigating your command prompt to the folder then typing
Code:
run_sdrtrunk_windows.bat
Last edited:
shifty21
Member
That was the issue. Thanks Nick
DiabloKing
Member
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.
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:
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
): http://forums.radioreference.com/tr...oding/188-ltr-passport-decoder-project-4.html
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
[b](0x158) DCC:2 GOTO:139 HSID:77 TGID:43025 Type:0 FREE:1259 CRC[/b]
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
[b](0x158) DCC:1 GOTO:446 HSID:29 TGID:23469 Type:1 FREE:1708 CRC[/b]
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
[b](0x158) DCC:3 GOTO:161 HSID:2 TGID:58997 Type:0 FREE:322 CRC[/b]
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
[b](0x158) DCC:3 GOTO:392 HSID:41 TG?:40258 Type:12 FREE:747 CRC[/b]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
): http://forums.radioreference.com/tr...oding/188-ltr-passport-decoder-project-4.htmlHey 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 [b](0x158) DCC:2 GOTO:139 HSID:77 TGID:43025 Type:0 FREE:1259 CRC[/b] 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 [b](0x158) DCC:1 GOTO:446 HSID:29 TGID:23469 Type:1 FREE:1708 CRC[/b] 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 [b](0x158) DCC:3 GOTO:161 HSID:2 TGID:58997 Type:0 FREE:322 CRC[/b] 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 [b](0x158) DCC:3 GOTO:392 HSID:41 TG?:40258 Type:12 FREE:747 CRC[/b]
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
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?
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!
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?
Attachments
Last edited:
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!
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!
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?
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?
Attachments
Ghstwolf62
Member
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.
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!
Ghstwolf62
Member
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.
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.
joeuser
The Wretched
This above or something is starting up with your system grabbing the dongle. You'd want to dig into administrative tools & system configuration...
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?id=0B7BHsssXUq8eOHBTNndCczZTd0k&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
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?id=0B7BHsssXUq8eOHBTNndCczZTd0k&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
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 )
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.
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?
- Status
