SDRTrunk

[EdwardClerkRudolf]

headless operation?

I have SDRtrunk running on a slightly overclocked Rpi3+ using 3x RTLSDR dongles monitoring a P25 Phase 1 system and providing a feed to broadcastify. It is running very well but I am trying to get the setup to be more robust. I understand that it won't run headless because it needs various GUI bits to work right. I use RealVNC to access the Pi and minimize the waterfall GUI after I manually run the command line. Minimizing the GUI window saves about 100% on the top cpu counter. ((190% with GUI up, 90% minimized, then about 100+% for each call).

Is there any method by which I could start SDRtrunk up at boot or am I completely limited to manually typing in the command line from a GUI window every time? Is there a way that say VNC server starts up the GUI interface and would give SDRtrunk what it needs? Would screen work? I have it set to boot to GUI. But I need a way to put the command line in rc.local or similar. Can I fire off a VNC connection from the pi in which SDRtrunk runs and to which I could connect? If I plugged a monitor into it would that solve the problem? It ability to access the waterfall from a running program is useful. I also want to be able to monitor if the program has crashed (low cpu) and autorestart.

ECR

 

[EdwardClerkRudolf]

nearly headless

Ok this time the google came through. I had to figure out what to ask it.

I have my pi boot to GUI.
You can autostart programs in the GUI by placing them in the appropriate autostart folder.

sudo nano /home/pi/.config/lxsession/LXDE-pi/autostart

add:
@/home/pi/projects/sdrtrunkguistart.sh

nano /home/pi/projects/sdrtrunkguistart.sh

put this into the file:
#!/bin/bash
sleep 10
java -jar /home/pi/sdr-trunk-all-0.3.4-beta.2.jar &
sleep 30
xdotool getactivewindow windowminimize

then:
chmod +x sdrtrunkguistart.sh

to get the xdotool:
sudo apt-get install xdotool

This will start up sdrtrunk in the gui at boot and then minimize the window. You can then connect to it with RealVNC.

Next monitor cpu usage and restart upon low usage. Occasionally SDRtunk will stop trunking but will still be running.

ECR

 

[dvsbmx]

Wicked pissa!

Finally, I can decode Rhode Island Statewide Communications Network (RISCON) P25 without spending half a stack on a digital trunking scanner!

Thanks Denny!

 

[amcferrin90]

Do each of your tuner's have a different name/label? The software remembers the tuner configuration settings for each tuner by name.

You can use the scroll wheel on your mouse to zoom in/out on the spectral display. Zoom in on the channel that you're trying to decode and align the signal to the expected frequency value on the display using the +/- PPM settings. As slicerwizard stated, let your dongle's warm up before you make your final corrections.

i guess I need to subscribe to this thread or I missed the email message.

When I fire up SDR#, there are two RTL-SDR(USB) dongles that show. Both are listed as "Generic RTL2832U OEM but one has a (0) and the other a (1). Running SDR# in two instances, one of each SDR I tuned a close control channel. They are both plugged in all the time with a blue light lit. I ran them both about 5 minutes and saw no noticeable drift. However the (0) needs a PPM of 47 while the (1) needs a PPM of 55 (really I think 54.5 but SDR# doesn't offer that kind of granularity).

If I were to open Unitrunker, I get two dongles labeled "R820T-1" & "R820T-2". In Unitrunker each receiver has a unique device description "RTL2838UHIDIR:00000001" & "RTL2838UHIDIR:6&2A0D8868&0&5". Using the app as a reference.

When I run SDR Trunk it detects two SDR dongles both named the same and the same serial number. When I run the program tonight I got 700 and 800 decoding pretty well, it wasn't perfect. So how to set the different PPM for each dongle? I still think there's some crazy thing going on in the tuner setup. I couldn't find a manual and I tried looking on YouTube for a walk through.I might entertain doing a team viewer with someone if they think they could walk me through it?

 

[DSheirer]

i guess I need to subscribe to this thread or I missed the email message.

When I fire up SDR#, there are two RTL-SDR(USB) dongles that show. Both are listed as "Generic RTL2832U OEM but one has a (0) and the other a (1). Running SDR# in two instances, one of each SDR I tuned a close control channel. They are both plugged in all the time with a blue light lit. I ran them both about 5 minutes and saw no noticeable drift. However the (0) needs a PPM of 47 while the (1) needs a PPM of 55 (really I think 54.5 but SDR# doesn't offer that kind of granularity).

If I were to open Unitrunker, I get two dongles labeled "R820T-1" & "R820T-2". In Unitrunker each receiver has a unique device description "RTL2838UHIDIR:00000001" & "RTL2838UHIDIR:6&2A0D8868&0&5". Using the app as a reference.

When I run SDR Trunk it detects two SDR dongles both named the same and the same serial number. When I run the program tonight I got 700 and 800 decoding pretty well, it wasn't perfect. So how to set the different PPM for each dongle? I still think there's some crazy thing going on in the tuner setup. I couldn't find a manual and I tried looking on YouTube for a walk through.I might entertain doing a team viewer with someone if they think they could walk me through it?

It seems as if both of your tuner dongles have the same serial number and SDR# and Unitrunker may both be creating a temporary ID for the second/duplicate tuner.

sdrtrunk attempts to use a separate configuration for each dongle using the dongle's serial number to uniquely identify each one. When both tuners have the same serial number, it uses the same configuration file for each. Any changes to the configuration for one will (eventually) be applied to both tuners once you restart the application.

I experimented with using the USB port number that the tuner is plugged into as a way to identify each dongle. But, that creates a problem when you move a tuner to a different/new USB port and the application thinks it's a new tuner (ie new port name) and loads a default configuration file.

The best solution is to rename each tuner to have a distinct serial number so that sdrtrunk can identify each one correctly and load/assign the correct settings for each tuner.

Denny

 

[amcferrin90]

It seems as if both of your tuner dongles have the same serial number and SDR# and Unitrunker may both be creating a temporary ID for the second/duplicate tuner.

sdrtrunk attempts to use a separate configuration for each dongle using the dongle's serial number to uniquely identify each one. When both tuners have the same serial number, it uses the same configuration file for each. Any changes to the configuration for one will (eventually) be applied to both tuners once you restart the application.

I experimented with using the USB port number that the tuner is plugged into as a way to identify each dongle. But, that creates a problem when you move a tuner to a different/new USB port and the application thinks it's a new tuner (ie new port name) and loads a default configuration file.

The best solution is to rename each tuner to have a distinct serial number so that sdrtrunk can identify each one correctly and load/assign the correct settings for each tuner.

Denny

Thanks Denny. I found a way to change the serial numbers and that definitely got things moving. It's working, needs tweaking and I got to find the manual. It seems like the link in the wiki was bad.

Alan

 

[BM82557]

Manual for Version 3.0 is at - https://github.com/DSheirer/sdrtrunk/wiki/UserManual_V0.3.0

 

[EdwardClerkRudolf]

4.0 alpha

I am testing out .4.0 alpha release I am running on an rPi 3plus. I have 3 flightaware yellow dongles plugged in. The system I am attempting to monitor is a P25 Phase 1 (would really like Phase 2 decoder!). The control channel and other channel spacing is far enough apart that I need at least 2 dongles.

I have found that if I try to enable the tuners to receive more than around 3mhz combined of spectrum then sdrtrunk starts to error out, so I have the dongle assigned to the control at 0.288mhz and the other 2 at 1.2- 1.4mhz. I assume I start to overflow something, probably the usb 2 bus. The .4 alpha release seems to not like a setting other than 2.4mhz. Am I doing something wrong, or is there a formula I can follow as I attempt to optimize my system as cpu, system resources and dongles are at a premium.

here is some output:

at java.lang.Thread.run(Thread.java:745)
16:41:21.393 ERROR i.g.d.d.f.c.PolyphaseChannelManager - Error [162MB/212MB 76%]
java.lang.IllegalStateException: User count is below zero. This indicates that this buffer's decrement user count was invoked by more than the expected user count
at io.github.dsheirer.sample.buffer.AbstractReusableBuffer.recycle(AbstractReusableBuffer.java:118)
at io.github.dsheirer.sample.buffer.AbstractReusableBuffer.decrementUserCount(AbstractReusableBuffer.java:100)
at io.github.dsheirer.dsp.filter.channelizer.ComplexPolyphaseChannelizerM2.receive(ComplexPolyphaseChannelizerM2.java:231)
at io.github.dsheirer.dsp.filter.channelizer.PolyphaseChannelManager$BufferSourceEventMonitor.receive(PolyphaseChannelManager.java:613)
at io.github.dsheirer.dsp.filter.channelizer.PolyphaseChannelManager$BufferSourceEventMonitor.receive(PolyphaseChannelManager.java:574)
at io.github.dsheirer.dsp.filter.channelizer.ContinuousBufferProcessor$Processor.run(ContinuousBufferProcessor.java:173)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
16:41:21.395 ERROR i.g.d.d.f.c.ContinuousBufferProcessor - Error while dispatching buffers to listeners [162MB/212MB 76%]
java.lang.IllegalStateException: User count is below zero. This indicates that this buffer's decrement user count was invoked by more than the expected user count
at io.github.dsheirer.sample.buffer.AbstractReusableBuffer.recycle(AbstractReusableBuffer.java:118)
at io.github.dsheirer.sample.buffer.AbstractReusableBuffer.decrementUserCount(AbstractReusableBuffer.java:100)
at io.github.dsheirer.dsp.filter.channelizer.PolyphaseChannelManager$BufferSourceEventMonitor.receive(PolyphaseChannelManager.java:626)
at io.github.dsheirer.dsp.filter.channelizer.PolyphaseChannelManager$BufferSourceEventMonitor.receive(PolyphaseChannelManager.java:574)
at io.github.dsheirer.dsp.filter.channelizer.ContinuousBufferProcessor$Processor.run(ContinuousBufferProcessor.java:173)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
16:41:22.379 ERROR i.g.d.d.f.c.PolyphaseChannelManager - Error [161MB/212MB 75%]
java.lang.IllegalStateException: User count is below zero. This indicates that this buffer's decrement user count was invoked by more than the expected user count
at io.github.dsheirer.sample.buffer.AbstractReusableBuffer.recycle(AbstractReusableBuffer.java:118)
at io.github.dsheirer.sample.buffer.AbstractReusableBuffer.decrementUserCount(AbstractReusableBuffer.java:100)
at io.github.dsheirer.dsp.filter.channelizer.ComplexPolyphaseChannelizerM2.receive(ComplexPolyphaseChannelizerM2.java:231)
at io.github.dsheirer.dsp.filter.channelizer.PolyphaseChannelManager$BufferSourceEventMonitor.receive(PolyphaseChannelManager.java:613)
at io.github.dsheirer.dsp.filter.channelizer.PolyphaseChannelManager$BufferSourceEventMonitor.receive(PolyphaseChannelManager.java:574)
at io.github.dsheirer.dsp.filter.channelizer.ContinuousBufferProcessor$Processor.run(ContinuousBufferProcessor.java:173)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
16:41:22.381 ERROR i.g.d.d.f.c.ContinuousBufferProcessor - Error while dispatching buffers to listeners [161MB/212MB 75%]
java.lang.IllegalStateException: User count is below zero. This indicates that this buffer's decrement user count was invoked by more than the expected user count
at io.github.dsheirer.sample.buffer.AbstractReusableBuffer.recycle(AbstractReusableBuffer.java:118)
at io.github.dsheirer.sample.buffer.AbstractReusableBuffer.decrementUserCount(AbstractReusableBuffer.java:100)
at io.github.dsheirer.dsp.filter.channelizer.PolyphaseChannelManager$BufferSourceEventMonitor.receive(PolyphaseChannelManager.java:626)
at io.github.dsheirer.dsp.filter.channelizer.PolyphaseChannelManager$BufferSourceEventMonitor.receive(PolyphaseChannelManager.java:574)
at io.github.dsheirer.dsp.filter.channelizer.ContinuousBufferProcessor$Processor.run(ContinuousBufferProcessor.java:173)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
16:41:22.391 INFO i.g.d.a.b.AudioBroadcaster - [RPi] status: Connecting [162MB/212MB 76%]
16:41:22.408 INFO i.g.d.a.b.AudioBroadcaster - [RPi] status: Connected [163MB/212MB 76%]
16:41:28.523 DEBUG i.g.dsheirer.gui.SDRTrunk - Application shutdown started ... [179MB/212MB 84%]

 

[DSheirer]

Edward, I pulled/removed the 0.4.0 alpha 1 release until I can fix some errors that are causing problems for some folks, specifically P25 decoder performance and not all sample rates are supported on the R820T. I should have these resolved over the weekend and will publish a new 0.4.0 alpha 2 release for you to try.

cheers,
Denny

 

[EdwardClerkRudolf]

I look forward to it!

Is a tuner assigned exclusively to a radio system or if control channels for two different systems are within the bandwidth of one tuner, can two different systems use that one tuner for control or channel decode?
I am trying to buy fewer RTLsdrs.

 

[DSheirer]

I look forward to it!

Is a tuner assigned exclusively to a radio system or if control channels for two different systems are within the bandwidth of one tuner, can two different systems use that one tuner for control or channel decode?
I am trying to buy fewer RTLsdrs.

The tuners are treated as a pooled set of resources and each tuner can source as many channels as will fit within the bandwidth.

 

[EdwardClerkRudolf]

4 Alpha 4 tests

I am testing 4 Alpha 4 on a rPi3+ with 3 dongles.

When I started testing the alpha series I lost all my aliases I had previously defined. I put most of them back in for Alpha.3 and it streams, but every few hours the control channel goes idle, cpu usage drops and it quits working and a restart is necessary.

I tried Alpha.4 yesterday. All my old aliases showed back up, the streaming shows a green connected, but nothing streams. I can see the activity on Now Playing. It is acting as if I do not have the correct Alias List specified under Channel, but as nearly as I can tell they are the same (chosen from the drop down list).

ECR

 

[DSheirer]

I'm testing some fixes for the issue with the control channel going idle and I hope to have a new alpha 5 release this weekend.

I'm not sure what would cause the issue you're seeing with the aliases and streaming. I think you're on the right track that it may have to do with specifying the correct alias list name in the channels, but without seeing your playlist, I can't say for sure.

Denny

 

[jl2s]

For me, in the new Alpha releases, the Aliases either don't show up, or it takes them several seconds until they pop up. But this is not for all transmissions, some work perfectly like in the previous beta, some don't show up at all.

The main problem I experience is that there seems to be a delay before the aliases show up (some never do). I have alot of aliases that are do not monitor, and for some conversations it takes 1-2 seconds before the alias appears (by appears I mean the alias name in the PRIMARY TO box, its completely blank, no name no HEX), and in that time the alias is blank, I hear conversation, later if the alias finally appears then the conversation is ignored. Aliases worked properly until the Alpha releases.\

Another example with blank/no aliases. Not even a HEX value appears for the call in the PRIMARY TO.

Would it help if I uploaded a youtube video showing the behavior?

This all works properly in the previous beta releases. Do I need to edit the alias to fix this somehow? It's just not locking up and displaying aliases. Pretty often.

P.S. if not for the Alias issue, imo SDRtrunk performance is better than FMP24/DSDPlus, or UniTrunker 2.x That's on my PC and setup, maybe other's will disagree, but for me it's my go to.

 

[DSheirer]

I just found/corrected the issue that is causing the delay in showing the from/to talkgroups (and processing of 'do not monitor' for audio). This will be in the next alpha 5 release. I hope to release it this weekend, but I'm still chasing another bug at the moment.

Thanks for the feedback on the issue.

Denny

 

[RF-Guy-El-Loco]

Aliases Delay

I was also having the same issue as above in vers Alpha 4.0. But I was monitoring 3 all highly active control channels/tower sites at once and thought I was pushing it too hard. Still grinning from ear to ear over SDRTrunk, my older Thinkpad I-3 cores were all running at 195+ degrees, and I even drilled holes in the case under the fan, but that didn't really help. The laptop just keeps running SDRTrunk fine on Ubuntu Mate even like that, fan at max rpms. No overloads either. I can't believe it. The desktops don't even break a sweat now on Alpha 4.0, rarely above 20% CPU usage load even with Win 7. They used to avg about 50%, load spike every 8 secs or so, but no longer, just a steady 20% (or less) usage. You did a lot of work releasing CPU/Memory resources in the Alpha 4.0 code. And it shows. You're a Genius.

SDRTrunk and the laptops have replaced my scanners now for APCO P-25 digital. I may never buy a scanner again! Of all the things that make my life the happiest right now, your program comes in at #1. Easily. Thank you for what you've done for us all.

 

[SDRPlayer]

Agreed, great work Denny! Really appreciate your time and effort.

 

[DSheirer]

You're very welcome. Thanks for the positive feedback!

Denny

 

[DRL-XM43]

I was also having the same issue as above in vers Alpha 4.0. But I was monitoring 3 all highly active control channels/tower sites at once and thought I was pushing it too hard. Still grinning from ear to ear over SDRTrunk, my older Thinkpad I-3 cores were all running at 195+ degrees, and I even drilled holes in the case under the fan, but that didn't really help. The laptop just keeps running SDRTrunk fine on Ubuntu Mate even like that, fan at max rpms. No overloads either. I can't believe it. The desktops don't even break a sweat now on Alpha 4.0, rarely above 20% CPU usage load even with Win 7. They used to avg about 50%, load spike every 8 secs or so, but no longer, just a steady 20% (or less) usage. You did a lot of work releasing CPU/Memory resources in the Alpha 4.0 code. And it shows. You're a Genius.

SDRTrunk and the laptops have replaced my scanners now for APCO P-25 digital. I may never buy a scanner again! Of all the things that make my life the happiest right now, your program comes in at #1. Easily. Thank you for what you've done for us all.

What Guy said.... SDRTRunk is brilliant and getting better with each update.

Denny, you rock!!!

 

[DRL-XM43]

Beta 5 released today