Nate Carlson

That is awesome!! My additional rtl-sdr's showed up today; once I get a test system built and validated I will give this a try. (As I've noted elsewhere I'm all...

Got the RTL's set up and tuned (yay), and have them recording the same data as my production system now. Will check in later to see how things look.

Found an issue.. here's the srclist for a call on my prod system.. `"srcList": [ {"src": 135702, "time": 1604323391, "pos": 0.000000, "emergency": 0, "signal_system": "p25", "tag": ""}, {"src": 131428, "time":...

Added a quick patch: ``` diff --git a/trunk-recorder/call.cc b/trunk-recorder/call.cc index 877abd3..e0de625 100644 --- a/trunk-recorder/call.cc +++ b/trunk-recorder/call.cc @@ -11,6 +11,7 @@ void Call::create_filename() { tm *ltm = localtime(&start_time); + current_time =...

I'll have to review the audio now that it's been running for awhile, but seems like the splitting with this solution is accurate. Downside is that it does require changes...

With the current analog_squelch branch, which is splitting via the wav sink, plus my patch to add the current timestamp to the filename of the wav file. Note that I...

Pushed some changes I've made here: https://github.com/natecarlson/trunk-recorder/tree/split_recordings_nate I'm pulling the call time from the source now, which makes it consistent.. and adding the frequency to the source info that gets...

Thread from discussion on gitter: Luke Berndt @robotastic Oct 29 20:44 @kb2ear Does it try to tune in the different freq in the list or is it not even trying...

That's an easy change to the source code; I've done an ugly implementation of that on a fork of OpenMHz. Not sure if @robotastic would be interested in that upstream?

I'd love to see it. In the ideal world I think this would all live on the player side, ideally with an easy way for authorized users to add unit...