Version 0.6.0 Alpha 4 Released

[sdrtrunk]

https://github.com/DSheirer/sdrtrunk/releases/tag/v0.6.0-alpha.4

This release resolves a critical memory (thread) leak that can happen when using the polyphase channelizer.

[dave38...@gmail.com]

I have from beta 2 thru beta 6. All versions work fine using 1 nooelec on an 800mhz system and 1 airspy mini on 2 700mhz phase 2 systems.

v0.6.0-alpha4 starts up fine and then the airspy goes idle with nothing in log as seen in video here  https://sabercathost.com/qRmT/2023-03-06_19-45-33.mp4

Ends up on the 800 and does not stay locked on 700

v0.6.0-alpha3 starts up and both tuners stay locked on control channel but the 2 systems on the airspy do not generate any recordings or live calls.   Mentioned and discussed here https://groups.google.com/g/sdrtrunk/c/8RcCa2YPYR0  and posted here

 Nooelec/airspy issue

#1475 opened last week by dave3825us

Again for clarification. Beta's 2 thru 6 work using the same 2 dongles plugged into the same 2 usb ports. Only one playlist on the Windows 10 64 bit pc. Ever since RSP support was added I have problems with v0.6.0-alpha3 & v0.6.0-alpha4.

[Jim Kovalsky]

Thanks for the update!  That leak must have been the issue, since this is the first release since v0.5.0-alpha6 that doesn't drop to idle when monitoring the P25 system I need to.  So far it's been running a couple of hours without an issue - previously it would die in about 15 minutes.  I'll continue to monitor for the next couple of days.

Jim

On Sunday, March 5, 2023 at 6:28:01 AM UTC-5 sdrtrunk wrote:

[Brian Hall]

It ran for a few hours for me on Debian 11 (Bullseye) and then the app completely locked up and became completely unresponsive. 🤷🏻‍♂️

[Jim Kovalsky]

Yep..  spoke too soon..  After about 2 hours is dropped back to idle and decoded nothing else.  Back to the v5 alpha...

[charley....@gmail.com]

Still runs fine for me on two separate, recently built, fully updated, well resourced Windows machines. One runs 24/7 along with Unitrunker 2 and Trunking Recorder with three Airspys and two Nooelecs. The other is a test setup.  I'm monitoring two Moto Phase 2 systems (one 700 MHz, one 800 MHz) from within their service areas, thus receiving a strong signal.    No errors in the SDRT startup log.  It must be a hardware, resource or device driver issue on the host platforms.  Or signal, either fringe or antenna.  Perhaps a bad cable.  I do know that when I tried to run earlier SDRT versions on an older 6th Gen i-5 I had some issues.  Once I acquired new host platforms, my issues went away.

[Jim Kovalsky]

Sorry, but just because YOU don't experience the problem doesn't mean it doesn't exist.  The *only* variable that has to change for it to fail is the version of the program that is running.  I can LITERALLY turn off the one version and turn on the other with ZERO change in hardware, cables, antennas, or anything else and I get the identical results every time.  

V5 Alpha 6 will run 24x7.  Any version after that *will* have better audio decode quality, but it will also fall to an "idle" condition 100% of the time within a short time.... I'm monitoring a very busy p25 Phase 2 system with a mix of encrypted and unencrypted channels.

Don't get me wrong -- I love SDRTrunk and am happy to do anything I can to help -- but it's clear that there is a bug yet to be located.

[charley....@gmail.com]

You are misunderstanding my point.  There is something unique in YOUR setup that is causing the issue, and I'm trying to get you to think about what it could be by illustrating what works for me.  Part of the problem is that we cannot "see" deep inside your hardware setup or your monitoring situation - the other is the inherent weakness of Google Groups in troubleshooting complex technical issues.

[Jim Kovalsky]

I clearly understand that the conditions I'm running under must have something different.  At the same time, there are multiple other users reporting the same "fall to idle" condition.  I've spent 40 years in software development - I'm rather well-versed in what *can* cause the issue.  What I don't know is how to supply the needed details to identify where the differences exist.  Something changed after v5 alpha 5 that caused this to start happening - that's what I can state for sure.

[charley....@gmail.com]

There is a data bias relating to the number of complaints to actual faults.  In other words, most users like me are likely not experiencing any major issues. Without knowing the specifics of your hardware configuration, the system you are trying to monitor and from where, it is difficult to offer any solutions.  Simply stating that you continue to have issues with the latest version does not move the solution forward.  As far as we know using the data points that you have or have not provided, your SDR dongle could be failing.

[GTR8000]

Charley, I have to say, your constant "Works fine for me!" posts are getting a little tedious. If you have nothing of real value to add to these discussions, then perhaps you should refrain from posting.

I have a setup that works great with previous versions of SDRTrunk, but crashes and burns with some of the latest releases on multiple PC's that are substantially unique from one another. I've been working with Denny privately to see if we can figure out what is going on.

So to claim that any issues any of us encounter is due to some uniqueness with the system, or a "failing dongle", is nothing but uninformed speculation on your part. Give it a rest, okay?

[Chris Simons]

Thx GTR, needed to be said.  Latest version (listed on this thread) goes "idle" using the Heterodyne tuner but works fine on the Polyphase tuner.  Matter of fact, all versions of 0.6.0 go idle on Heterodyne after a few seconds, older 0.5.0 Betas worked fine for both.  Started seeing the problem with 0.5.1 Final.

System:  Windows 11, 6 core, Intel i5, 8 gb ram.  Using 2 RTL SDR V3 dongles monitoring p25p2 system.

[charley....@gmail.com]

I see your point, but the opposite could be said for people having issues yet providing no actionable data.  Equally tiresome.  I'll hold my responses to those who supply enough data to support a suggestion.

[Douglas Graham]

I might give this a try later... I've not had much luck past 0.5.1... 0.5.2 died way too often, which made me hesitant on 0.6.x.

I'm running 8 Nooelec Smart v5 radios, monitoring 2 P25 Phase 1 and 1 P25 Phase 2 network

0.5.1 has been the most stable for me - it still dies after a random time period (some days an hour, others it might be 6 hours), but comes right back after a restart. I ended up writing a supervisor app that watches the java cmd window for errors and automatically restarts the app... that has been working quite well for me.

[Douglas Graham]

Tried 0.6.0 a4... audio dies in under an hour every restart with no errors and screen appears to freeze (8 Nooelec Smart v5's on a properly powered hub)... going back to 0.5.1 seems much more stable
. When the software works, it is great.... I do appreciate the work put into developing it.

[Douglas Graham]

I got a pretty lengthy nasty email from someone on this thread, so here are my basic responses:

I'm running 8 Nooelec SDR Smart v5s on a powered USB 3.0 hub, with an Intel i7 8750H (Hex core, HT processor) with 32 GB RAM, NVidia RTX 2070 Graphics. Each radio is confined to 2.4MHz of bandwidth, covering systems that operate in the 700Mhz and 800Mhz band. Process utilization never goes over 40% CPU and is usually in the 20-25% range.

The 2 primary errors I see are libusb pipe errors or "Couldn't design final output low pass filter"

8 radios is overkill, as I stated before, generally, the max I see in use are 6 radios.

I'm not knocking the software in any way... I find it is amazingly better than a $700 Uniden scanner for trunked systems.

[charley....@gmail.com]

I'm wondering if your USB bus / controller (internal to the PC) is being saturated.  Some power users install add-in cards with up to 4 discrete USB controllers to divide the load. 

[Brad Wicks (Ulti P. Uzzer)]

I run a 5 Nooelec SDR fan cooled array on a Ryzen 16 core w/64 gigs and after recently upgrading to 0.6.0a4 I have also noticed a lot more instability and lots errors in the JVM window with only 20 to 30 mins of running.

[Douglas Graham]

I'd find it hard to think that 8 radios at 2.4Mb would saturate a 5Gb USB 3 bus, but I am fairly limited in that this is a laptop, not a PC. Otherwise, yes, I would have a lot of options on adding cards or separating the busses better.  One thing I have noted, and it has nothing to do with the software... I do need to reset the radios about every 2 weeks... generally one in the bunch tends to get hung up... these are "cheap" SDRs after all.  After resetting all of them this morning and disconnecting/reconnecting my powered hub, things are quite a bit better... 0.6.0a4 is actually running pretty solid other than I cannot pull up the playlist... I just get a blank box. Not too worried, as it is "alpha" so far... but things are much improved.  My watchdog app is keeping an eye on things and has not forced a restart yet.  I hit my peak for recordings off of 4 channels yesterday (running 0.5.1) at 36,778 files, after my python scripts deleted the files with unusable audio. It was nice to go to bed and not miss anything... not good things... someone threw someone else in a burn barrel and set it on fire.. listening to the FD find the body and call in PD was um, not expected.

Keep up the great work on this software... The only thing that could make this better is if the SDRs had the receive range of my Uniden scanners.

[Douglas Graham]

Maybe I spoke too soon... 0.6.0a4 just took a nose dive. I noticed it seemed quiet for this time of the morning... tons of "i.g.d.util.Dispatcher - Temporary buffer overflow for thread [sdrtrunk polyphase buffer processor] - throwing away samples" errors. A restart brought everything back.

[charley....@gmail.com]

If you plug a USB2 device into a USB3 port, the port will run at USB2 speed.

[charley....@gmail.com]

I replaced an Airspy with a RSP1a today, and started a test run with SDRT 0.6 Alpha 4.  So far so good.  No errors in startup log.  All supporting software / drivers are installed in their default locations.  I'm trying to make a move away from Airspy because of their ridiculous warranty / RMA policy where they want a customer to pay upfront for warranty service.  I hope that more software developers will enable RSP1a support.

[charley....@gmail.com]

Updating the above.  Overnight and this morning, I'm am getting these periodic errors:

2023-03-23 10:06:35.181 WARN  i.g.d.util.Dispatcher - Temporary buffer overflow for thread [sdrtrunk polyphase buffer processor] - throwing away samples  [79MB/376MB 21%]

 I do not get these with a slightly narrower band width Airspy Mini.  Reading earlier threads about this error, it seems like higher band width devices like Airspy R2 - and now RSP1a - can saturate the USB bus before the CPU can clear it.  The thought is that a better CPU (minimum 8 cores) is desired when using these devices.  I'm testing on a mid-range Dell 3070 Micro, i5-9500T / 16Gb which has 6 cores.  I know that an Airspy R2 runs with no errors on another, more powerful host machine.

[Douglas Graham]

Charley, those are the same errors I am seeing, and I agree with your earlier comment about USB 2.0 vs USB 3.0... plugging in a USB 2.0 device slows things down considerably by design. The theoretical max for my Nooelec SDRs is about 60Mb/s per radio, so 6 active radios at that rate would be 360Mb/s. USB 2.0 has a theoretical max of 480 Mb/s.  This is a bit tight taking command overhead into play.  But... Not knowing how exact the error messages are... seeing buffer overflows makes me think maybe the buffers are a too small?  Since the CPU is never much over 25% and there is no other limiting factor maybe a slightly larger buffer might help. I'm not sure... I've just tried to keep things running when I step away for a few hours. (It's a tech thing... most errors never occur when I'm watching it)

[charley....@gmail.com]

I would think that a larger buffer might help smoothing out the data flow.  My question what buffer.  There is a physical USB buffer (256 bytes) but maybe it's referring to  a logical buffer created in RAM?

[charley....@gmail.com]

Data point: I changed out the RSP1A back to the original Airspy Mini, and the buffer errors have ceased.  I'm trying to dig up multiple RTL type SDRs to test that setup to see if it produces buffer errors.

[A Vel]

I was wondering if alpha.5 will include support for Airspy HF+?

[sdrtrunk]

I'm targeting Version 0.6.0 Alpha 6 for Airspy HF+.  There was a major bugfix I had to get patched in 0.5.3 and 0.6.0-Alpha5.

[Austin Hruskach]

Ive been having an ongoing issue where every traffic call starts off with sync loss, but only on the first line of the decoded messages log. PPM / Gain / Sample rate is all perfect...