This is an overview of my PC based scanner that I have been running since July 2021 on Muskegon County Simulcast of MPSCS. My setup has a few unique features that I have implemented over the years since I started monitoring. I always look for ways to improve, and I take pride in the active development of my pc scanner. With that said, I look forward to opinions and feedback.
Purpose:
To feed Broadcastify and Broadcastify Calls with ALL Non encrypted Traffic from Muskegon County Simulcast (MCS) on a budget and use of existing materials if possible. MCS has 14 Trunked channels across the 770MHz band and 850MHz band. I also want to have extensive debugging and logging ability.
What I put together:
I started off with a Dell OptiPlex 8010 with a Core i7 and 8GB RAM, I attached 3 x RTL-SDRBlog v3 SDRs to it and ran SDRTrunk to decode and stream the scanner audio. I then used Trunking Recorder to stream locally and via web, and archive calls.
The Issues began:
The system started off with low traffic, but as it ramped up, I had to add a 4th SDR to keep up with traffic, at the same time I experimented with using an Airspy R2 that has 10MHz of bandwidth, to cover a cluster of channels in the 770MHz band where most voice traffic is taking place. While I was optimizing the Tuners RF coverage with the Voice Channel Spacing of the trunked system, I noticed that Windows did not like to run SDRs at 2.4MHz Sample rate no matter what I tried, so I had to make SDRTrunk run them at 1.92MHz Sample Rate in order to lose USB data / buffer overflows. All of this in addition to that, SDRTrunk on Windows is a resource HOG! everything is pretty much pinned on Task Manager.
New Equipment, New Ideas:
I got my hands on a second identical OptiPlex 8010, so I decided to put a highly stable of Linux on it, I chose MXLinux. I installed SDRTrunk on it and attached the 4 SDRs to it and I made a shocking discovery, not only did it reduce the overall system utilization to under 25% during max decode load, it also ran ALL 4 of the SDRs on 2.4MHz sample rate with absolutely no issues. So I declared Windows 10 do be a bottleneck. So now I have a Linux PC that scans and records calls, but isnt compatible with my favorite software, Trunking Recorder. So I ran both side by side. I use a program called Syncthing to sync / mirror the recorded files across both machines. I did not want to use FTP, SMB, etc. I had issues with those. I also wanted the ability to have calls stack up, rather than not write to disk at all if a network share doesnt work. So with syncthing, if a PC restarts or goes offline, upon startup, it will pull the files in order to keep calls in order in Trunking Recorder. If calls queue, it also pulls oldest first to keep it as close to realtime as possible.
Logs for days:
Now that I can record all calls without any issues, and stream them effectively, I gotta keep track of performance. SDRTrunk always records "Control Channel Event Logs" that keep track of SDRTrunks interaction with the Control Channel and traffic channels. This log will tell me if a Tuner is unavailable for a call in progress, if the Control Channel Frequency Changes, and I can also compare this log with recorded calls that have any issues with them. These logs are also cross referenced with logs from Unitrunker (on the windows 10 PC) that runs Control Channel Only Decoding on Muskegon County Simulcast, and a site Neighbor, Ottawa County Simulcast. Logs from both of them can determine what talkgroups carry over to other sites, and talkgroup discovery and identification.
(I gotta stop here, but I will update this post later with photos, and a finished description!)
Purpose:
To feed Broadcastify and Broadcastify Calls with ALL Non encrypted Traffic from Muskegon County Simulcast (MCS) on a budget and use of existing materials if possible. MCS has 14 Trunked channels across the 770MHz band and 850MHz band. I also want to have extensive debugging and logging ability.
What I put together:
I started off with a Dell OptiPlex 8010 with a Core i7 and 8GB RAM, I attached 3 x RTL-SDRBlog v3 SDRs to it and ran SDRTrunk to decode and stream the scanner audio. I then used Trunking Recorder to stream locally and via web, and archive calls.
The Issues began:
The system started off with low traffic, but as it ramped up, I had to add a 4th SDR to keep up with traffic, at the same time I experimented with using an Airspy R2 that has 10MHz of bandwidth, to cover a cluster of channels in the 770MHz band where most voice traffic is taking place. While I was optimizing the Tuners RF coverage with the Voice Channel Spacing of the trunked system, I noticed that Windows did not like to run SDRs at 2.4MHz Sample rate no matter what I tried, so I had to make SDRTrunk run them at 1.92MHz Sample Rate in order to lose USB data / buffer overflows. All of this in addition to that, SDRTrunk on Windows is a resource HOG! everything is pretty much pinned on Task Manager.
New Equipment, New Ideas:
I got my hands on a second identical OptiPlex 8010, so I decided to put a highly stable of Linux on it, I chose MXLinux. I installed SDRTrunk on it and attached the 4 SDRs to it and I made a shocking discovery, not only did it reduce the overall system utilization to under 25% during max decode load, it also ran ALL 4 of the SDRs on 2.4MHz sample rate with absolutely no issues. So I declared Windows 10 do be a bottleneck. So now I have a Linux PC that scans and records calls, but isnt compatible with my favorite software, Trunking Recorder. So I ran both side by side. I use a program called Syncthing to sync / mirror the recorded files across both machines. I did not want to use FTP, SMB, etc. I had issues with those. I also wanted the ability to have calls stack up, rather than not write to disk at all if a network share doesnt work. So with syncthing, if a PC restarts or goes offline, upon startup, it will pull the files in order to keep calls in order in Trunking Recorder. If calls queue, it also pulls oldest first to keep it as close to realtime as possible.
Logs for days:
Now that I can record all calls without any issues, and stream them effectively, I gotta keep track of performance. SDRTrunk always records "Control Channel Event Logs" that keep track of SDRTrunks interaction with the Control Channel and traffic channels. This log will tell me if a Tuner is unavailable for a call in progress, if the Control Channel Frequency Changes, and I can also compare this log with recorded calls that have any issues with them. These logs are also cross referenced with logs from Unitrunker (on the windows 10 PC) that runs Control Channel Only Decoding on Muskegon County Simulcast, and a site Neighbor, Ottawa County Simulcast. Logs from both of them can determine what talkgroups carry over to other sites, and talkgroup discovery and identification.
(I gotta stop here, but I will update this post later with photos, and a finished description!)
