I was surprised to find out these two open source applications were not already being discussed here so I'm going to out them for those of you looking for something like this.
A few months ago friends of mine were playing with DSD+ and the windows based Trunking Recorder using nooelec neSDRs and we were struggling to get it to decode cleanly, remain stable, etc. I've found that this method using op25 seems to produce far more consistent and nicer quality decode.
One of those friends of mine stumbled upon trunk-recorder written by Luke Berndt which uses op25 and gnuradio, but has matured. What was missing was a Trunking Recorder like web interface - but then we somehow found this trunk-player (written by Dylan Reinhold) which is already written to accept data from Trunk Recorder. When we showed an interest in his work he released it on GitHub and has been tweaking it based on some feedback we've given him.
https://github.com/robotastic/trunk-recorder
https://github.com/ScanOC/trunk-player
Screen shot of the web based player: https://github.com/ScanOC/trunk-player/raw/master/docs/images/trunk_player_main.png?raw=true
A few of us have trunk-recorder running on (admittedly beefier CPU) Ubuntu linux machines using 3 SDR dongles to capture an entire P25 or Smartnet system. The nice thing about trunk-recorder is it is entirely self contained - there is no need to run a CC channel app, nothing to direct decoders, nothing to interact via virtual cables. Trunk recorder basically listens to the CC, directs the SDRs, and outputs a .wav and a corresponding .json file with metadata. (ie: every unit ID in that transmission - see the screenshot above)
What you need is enough SDRs to effectively cover the system you want to capture and a modest amount of CPU. For me that was just under 6mhz of dongles and a new-to-me computer off eBay - your mileage may vary. I am able to run 3 at 2mhz sample rates. I am using a dual quad core L5420 @ 2.5Ghz - the Ubuntu box looks like this during off peak time for the system:
top - 00:45:58 up 5 days, 4:38, 2 users, load average: 3.65, 4.11, 4.21
Tasks: 178 total, 1 running, 177 sleeping, 0 stopped, 0 zombie
%Cpu0 : 15.0 us, 4.0 sy, 0.0 ni, 80.7 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
%Cpu1 : 8.1 us, 2.0 sy, 0.0 ni, 89.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu2 : 21.0 us, 3.1 sy, 0.0 ni, 74.2 id, 0.7 wa, 0.0 hi, 1.0 si, 0.0 st
%Cpu3 : 10.9 us, 4.2 sy, 0.0 ni, 84.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu4 : 14.5 us, 2.6 sy, 0.0 ni, 82.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu5 : 60.9 us, 1.0 sy, 0.0 ni, 38.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu6 : 30.4 us, 1.7 sy, 0.0 ni, 67.2 id, 0.0 wa, 0.0 hi, 0.7 si, 0.0 st
%Cpu7 : 8.9 us, 3.8 sy, 0.0 ni, 87.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
Every time trunk-recorder writes a .wav and .json file it will (optionally) run a shell script. There are pre-written shell scripts included between the two applications that act on those two files to make them easily playable. This is where it gets really spiffy.
Every time a .wav and .json file is generated on my SDR machine it will:
1. Push the two files to a second machine (where I'm running the django / web based trunk player).
(You could do this at your house or put the web based server out on the internet)
2. Add a entry to a sql database for the webserver. This makes the web interface know everything.
3. optionally convert the .wav file to a .mp3 for size. I am doing this.
4. push the .mp3 file up to Amazon S3 storage so it can be referenced - this isn't required, but its already written into the scripts. If you don't do this you have to find a place to put the .wav files where they can be accessed via a web browser.
In the web interface you can simply go to the "default" page where every single .mp3 file is played as they arrive - or you can build scanlists, which basically creates a web-based scanner.
The really cool scaling feature about the way trunk-player works is you could theoretically have 2-3+ friends each setup a recorder for a given P25 / Smartnet system and all of you feed the same web based front end. Then all of you can listen to each of those systems, mixing talk-groups into scan lists of interest and being able to access it from anywhere on the Internet - which is great if one of you is in a better position to overcome simulcast distortion than your friends?
The way trunk-recorder works is if radio traffic occurs back-to-back on the same voice frequency it will record that all in a single .mp3 file until a timeout is reached or some other talk-group appears there. This takes some getting used to and admittedly adds a little bit of delay to when you hear a transmission in real-time, but by default trunk-recorder doesn't record the actual silence between the transmissions, so you hear everything back-to-back quickly. That is now adjustable, but some people may like that to "catch up" to the delay of listening to multiple talk-groups.
The benefits of this are pretty huge since you get 100% of every transmission for every talk-group, so while you may setup a scan list that gets "behind" by 2-3 minutes you know you're hearing every transmission of every talk-group that interests you.
This isn't for the faint at heart. While installation has clearly improved and become easier you're going to need to modify some files, tweak some settings, etc. to make it do what you want. If you're comfortable doing that these two apps are worth your time.
As more of us start providing feedback and learning the quirks the installation should become more and more easy for the novice end user.
A few months ago friends of mine were playing with DSD+ and the windows based Trunking Recorder using nooelec neSDRs and we were struggling to get it to decode cleanly, remain stable, etc. I've found that this method using op25 seems to produce far more consistent and nicer quality decode.
One of those friends of mine stumbled upon trunk-recorder written by Luke Berndt which uses op25 and gnuradio, but has matured. What was missing was a Trunking Recorder like web interface - but then we somehow found this trunk-player (written by Dylan Reinhold) which is already written to accept data from Trunk Recorder. When we showed an interest in his work he released it on GitHub and has been tweaking it based on some feedback we've given him.
https://github.com/robotastic/trunk-recorder
https://github.com/ScanOC/trunk-player
Screen shot of the web based player: https://github.com/ScanOC/trunk-player/raw/master/docs/images/trunk_player_main.png?raw=true
A few of us have trunk-recorder running on (admittedly beefier CPU) Ubuntu linux machines using 3 SDR dongles to capture an entire P25 or Smartnet system. The nice thing about trunk-recorder is it is entirely self contained - there is no need to run a CC channel app, nothing to direct decoders, nothing to interact via virtual cables. Trunk recorder basically listens to the CC, directs the SDRs, and outputs a .wav and a corresponding .json file with metadata. (ie: every unit ID in that transmission - see the screenshot above)
What you need is enough SDRs to effectively cover the system you want to capture and a modest amount of CPU. For me that was just under 6mhz of dongles and a new-to-me computer off eBay - your mileage may vary. I am able to run 3 at 2mhz sample rates. I am using a dual quad core L5420 @ 2.5Ghz - the Ubuntu box looks like this during off peak time for the system:
top - 00:45:58 up 5 days, 4:38, 2 users, load average: 3.65, 4.11, 4.21
Tasks: 178 total, 1 running, 177 sleeping, 0 stopped, 0 zombie
%Cpu0 : 15.0 us, 4.0 sy, 0.0 ni, 80.7 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
%Cpu1 : 8.1 us, 2.0 sy, 0.0 ni, 89.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu2 : 21.0 us, 3.1 sy, 0.0 ni, 74.2 id, 0.7 wa, 0.0 hi, 1.0 si, 0.0 st
%Cpu3 : 10.9 us, 4.2 sy, 0.0 ni, 84.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu4 : 14.5 us, 2.6 sy, 0.0 ni, 82.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu5 : 60.9 us, 1.0 sy, 0.0 ni, 38.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu6 : 30.4 us, 1.7 sy, 0.0 ni, 67.2 id, 0.0 wa, 0.0 hi, 0.7 si, 0.0 st
%Cpu7 : 8.9 us, 3.8 sy, 0.0 ni, 87.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
Every time trunk-recorder writes a .wav and .json file it will (optionally) run a shell script. There are pre-written shell scripts included between the two applications that act on those two files to make them easily playable. This is where it gets really spiffy.
Every time a .wav and .json file is generated on my SDR machine it will:
1. Push the two files to a second machine (where I'm running the django / web based trunk player).
(You could do this at your house or put the web based server out on the internet)
2. Add a entry to a sql database for the webserver. This makes the web interface know everything.
3. optionally convert the .wav file to a .mp3 for size. I am doing this.
4. push the .mp3 file up to Amazon S3 storage so it can be referenced - this isn't required, but its already written into the scripts. If you don't do this you have to find a place to put the .wav files where they can be accessed via a web browser.
In the web interface you can simply go to the "default" page where every single .mp3 file is played as they arrive - or you can build scanlists, which basically creates a web-based scanner.
The really cool scaling feature about the way trunk-player works is you could theoretically have 2-3+ friends each setup a recorder for a given P25 / Smartnet system and all of you feed the same web based front end. Then all of you can listen to each of those systems, mixing talk-groups into scan lists of interest and being able to access it from anywhere on the Internet - which is great if one of you is in a better position to overcome simulcast distortion than your friends?
The way trunk-recorder works is if radio traffic occurs back-to-back on the same voice frequency it will record that all in a single .mp3 file until a timeout is reached or some other talk-group appears there. This takes some getting used to and admittedly adds a little bit of delay to when you hear a transmission in real-time, but by default trunk-recorder doesn't record the actual silence between the transmissions, so you hear everything back-to-back quickly. That is now adjustable, but some people may like that to "catch up" to the delay of listening to multiple talk-groups.
The benefits of this are pretty huge since you get 100% of every transmission for every talk-group, so while you may setup a scan list that gets "behind" by 2-3 minutes you know you're hearing every transmission of every talk-group that interests you.
This isn't for the faint at heart. While installation has clearly improved and become easier you're going to need to modify some files, tweak some settings, etc. to make it do what you want. If you're comfortable doing that these two apps are worth your time.
As more of us start providing feedback and learning the quirks the installation should become more and more easy for the novice end user.
