search

robotastic / trunk-recorder

Records calls from a Trunked Radio System (P25 & SmartNet)
GNU General Public License v3.0
866 stars 195 forks source link

multi-system and p25 CC's #120

Closed bctrainers closed 4 years ago

bctrainers commented 7 years ago

This is an enhancement/feature request. I didn't see this in the source code, something to consider.

Tonight i noticed that the main CC source center frequency for P25 is required to be in the first item listed under the sources json file.

Would it be possible to add in two new flag options within each sources segment called "ContainsCC" and "ContainsACC". Both would be boolean options.

robotastic commented 7 years ago

Could you add a little more info?

In the config.json file, the center freq setting in the source blocks should be flexible, I don't think the order should matter. Can you post an example of what isn't work?

What would "ContainsCC" and ContainsACC mean? Is ACC, alternate control channel?

kcwebby commented 7 years ago

My configuration has the control channels covered by my fifth and sixth SDR, so I'm not sure this is a bug as you described.

On Apr 14, 2017 06:46, "Luke Berndt" notifications@github.com wrote:

Could you add a little more info?

In the config.json file, the center freq setting in the source blocks should be flexible, I don't think the order should matter. Can you post an example of what isn't work?

What would "ContainsCC" and ContainsACC mean? Is ACC, alternate control channel?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/robotastic/trunk-recorder/issues/120#issuecomment-294140875, or mute the thread https://github.com/notifications/unsubscribe-auth/AKTZAs3od4Kj0SZgCInuxGZ6hVni6hzbks5rv1yPgaJpZM4M9g-Q .

Treehouseman commented 7 years ago

I'm pretty sure I know what the issue is, As of now, the system control channel retune feature only works if the channels are within the same source block.

How recorder works control channels is that it reads the first frequency given, and creates a control channel decoder on the radio covering that frequency. GNURadio doesn't really allow swapping of block connections while running, or the addition/removal of them. But it does allow you to change variables, like the center frequency on the filters, so the retune feature takes the decode channel given for that system and updates the center frequency. If the frequency is not covered by the source it's connected to, it won't tune. And it can't add a new decode block because it's already started running.

bctrainers commented 7 years ago

Hi, i've attached my multi-system json config. As a pretext to the file... The P25 system is a single-site system in johnson county ks. It is attached to a larger system that is known as the KC MARRS system in Kansas City (each county has its own simulcast site/system). JoCo has a single control channel for the system in the county, the two alt-CC's are not included in the system list on the file (as it resulted in extensive console spam).

The rtl=03 centered on 855325000 was moved to the top of the sources listings as it's in the frequency block that contains the Control channel for the county system. Once this was moved to the top, the p25 decode spam i got about it having 0 decodes disappeared, and the entire compiled application ran as it normally should. Able to pull in audio very clearly at that.

I would expect that i would not need to move the CC based centered frequency to the top of the list to be able to decode P25 data. Hence the request originally for "ContainsCC" and "ContainsACC" as a boolean setting within each sources item. It would default to false, but if true on either, that center frequency would be the first to be monitored for the P25 control channel stream.

joco-p25-multisdr.zip

robotastic commented 7 years ago

Hmm... well that is quiet weird. The order of the Sources shouldn't matter at all. One the program is first start, it will go through the sources in order to find a source that covers the control channel. With my configs, I don't have the source that will have the control channel first in the list. I wonder if there is something else happening and it just happened to work better when you restarted. Can you give the Logging branch a try to see if that helps? There is some newer code there.

git checkout logging
git pull
make
bctrainers commented 7 years ago

I've changed the repo over to the logging branch. The logging only logs to screen, any way to log to a file or to pipe it somewhere?

Treehouseman commented 7 years ago 
./recorder 2>&1 | tee -a log.txt
gofaster commented 5 years ago

Sorry to resurrect this. I have the issue described by Treehouseman in comment #3 above. A system I monitor has a 2.875 MHz span between the primary and alternate control channels; which is greater than the bandwidth of a single RTL-SDR. When trunk-recorders tries to tune to the alternate control channel frequency, it fails with the following error:

[2019-06-21 09:43:40.006090] (error) [CSERN] Retuning to Control Channel: 774.581238 [2019-06-21 09:43:40.006113] (info) - System Source - Min Freq: 772.259949 Max Freq: 774.659973 [2019-06-21 09:43:40.006170] (error) [CSERN] Control Channel Message Decode Rate: 0/sec, count: 0 [2019-06-21 09:43:43.010582] (error) [CSERN] Retuning to Control Channel: 771.431213 [2019-06-21 09:43:43.010651] (info) - System Source - Min Freq: 772.259949 Max Freq: 774.659973 [2019-06-21 09:43:43.010665] (error) - Unable to retune System control channel, freq not covered by the Source used for the inital control channel freq.

The alternate control channel frequency is covered by another source block that also covers the voice frequencies. Is there a fix or work-around for this? Running trunk-recorder version as of Jun 7, 2019 commit.

Treehouseman commented 5 years ago

So I never made it "work" for the system that needed it I just did a hack to let me have multiple system configs for one system so it had a control channel on each radio it needed to cover all the frequencies. It was extremely hacky and I don't even remember how I did it honestly, I never committed any of it to my fork or anything, just left it as in place station specific modifications. It really isn't a good method. It adds a notable bit of extra CPU load with the constant control channels and can still cause some annoying issues. Control channels don't like to not decode for long periods of time, they can become deaf and stop decoding until trunk recorder restarts. They can also retune on momentary signal loss and do the same thing. Honestly I just disabled all system retuning in the end and just deal with losses with (if any) control channel hopping.

Basically, if you want to do it right, duplicate the system per radio, but keep in mind recordings might get mashed up at time.