Looking for Wrong Frequencies

[Dewey3]

I just switched one of my recorders from v4.3.2 (9-15-2022) to the latest build, v4.7.1 (4-8-2024). With the exception of the UID problem I have with one of the systems I monitor (#674 and #836), v4.7.1 is working well. After allowing the 4/8 version of v4.7.1 to run for a day, I decided to take a look at the logs to see under the hood how it is running. I discovered that I am getting a lot of Not Recording: no source covering Freq errors referencing frequencies 10 MHz higher than the system. To be sure I didn't miss anything, I took a look at the same system on Unitrunker and confirmed that the system frequencies have not changed. I am using the exact same config.json file, so unless I need to make an adjustment due to the version change, I can confirm that I am not seeing these errors in the old v4.3.2 logs. I have attached a screen print of the system frequencies (https://www.radioreference.com/db/sid/2847) and a partial copy of a log file loaded with the Not Recording: no source covering Freq errors.

A42E.log

[taclane]

There is some recent discussion on radioreference concerning a band plan for this system that reaches up to 868.9875 MHz.

It is entirely possible that those aren't errors, and this could be a case of the rrdb system page not being congruent with reality.

[Dewey3]

There is some recent discussion on radioreference concerning a band plan for this system that reaches up to 868.9875 MHz.

It is entirely possible that those aren't errors, and this could be a case of the rrdb system page not being congruent with reality.

Thanks. All of my scanners seems to be tracking it ok, so I took a look at Uniden Sentinel and I'm not seeing anything new there. As mentioned, I am also literally watching the system now on Unitrunker and everything is still the same there as well. Thank you again, and I will look into this a little closer to see if I can find out what is going on... especially since I didn't see the errors before yesterday when I upgraded that TrunkRecorder RPi from v4.3.2 to v4.7.1.

[Dewey3]

Thank you @taclane !!! My first attempt at writing a rebanded system with multiple bandplans, but everything has been running smoothly for an hour now without one Not Recording: no source covering Freq error. It's interesting that there is a discussion about it on RR, but the database has not been updated (since 2022!). I haven't missed any tranmsissions, so I know nothing is wrong there. When I get home tomorrow, I'll take a look at the logs and am expecting not to see any of those errors. Thanks again!

  "systems": [{
    "shortName": "A42E",
    "type": "smartnet",
    "control_channels": [853262500,853375000,853650000,853900000],
    "modulation": "fsk4",
    "squelch": -61,
    "talkgroupsFile": "A42E-TR.csv",
    "compressWav": false,
    "audioArchive": false,
    "transmissionArchive": false,
    "callLog": false,
    "analogLevels": 8,
    "digitalLevels": 2,
    "recordUnknown": true,
    "recordUUVCalls": true,
    "hideEncrypted": false,
    "hideUnknownTalkgroups": false,
    "minDuration": 0,
    "minTransmissionDuration": 0,
    "talkgroupDisplayFormat": "id_tag",
    "bandplan": "800_reband",
    "bandplanBase": 851025000,
    "bandplanHigh": 854000000,
    "bandplanSpacing": 25000,
    "bandplanOffset": 440,
    "bandplanBase": 851012500,
    "bandplanHigh": 868987500,
    "bandplanSpacing": 25000,
    "bandplanOffset": 0

[Dewey3]

Unfortunately, I had to roll back to the tried and true 9/15/2022, v4.3.2 that works so well for me. After updating my config.json to reflect the "800_reband" and new bandplans, I am still getting the calls to the higher non-existent frequencies. Once I went back to v4.3.2 using the exact same config.json (I did readjust the dongle center frequencies back to 851.56875, 853.58125, and 856.5000), all of those calls to the higher frequencies stopped. The actual, or at least in use system frequencies are 851.0750 - 856.5625, and the additional frequencies that are being sought in v4.7.1 are 858.3375 - 868.7000. If it helps any, here is a copy of each non-existent frequency that was being called by v4.7.1:

Freq: 858.337500 MHz	Not Recording: no source covering Freq
Freq: 859.287500 MHz	Not Recording: no source covering Freq
Freq: 859.662500 MHz	Not Recording: no source covering Freq
Freq: 866.325000 MHz	Not Recording: no source covering Freq
Freq: 867.612500 MHz	Not Recording: no source covering Freq
Freq: 868.450000 MHz	Not Recording: no source covering Freq
Freq: 868.612500 MHz	Not Recording: no source covering Freq
Freq: 868.700000 MHz	Not Recording: no source covering Freq

[robotastic]

Checking to see if this is still an issue?

[Dewey3]

Sorry for the delay, I forgot that this was my OP, yes, it is still occurring. I've attached my json and a log file that I just started to show how fast (and how much) it can happen. I know the 868 in the band plan is w-a-a-a-y high, but that comes directly from RadioReference (https://forums.radioreference.com/threads/charles-county-band-plan.470758/) and also works with the RR-Sentinel downloads without any problems on the x36 and SDS.

12-19-2024_1350_00.log
A42E.json

[kb2ear]

I see the same errors on Charles county, however, I see errors like this on every 800_reband system I manage. (I don't have may left) Always on a non-existent talkgroup. When I have tried to listen to the traffic there is nothing ever recorded.

Running on v5 48b0ee1

12-19-2024_0000_08.log:[2024-12-19 00:08:04.194390] (error)   [charles] 41159C  TG:                       - (     57888) Freq: 866.325000 MHz    Not Recording: no source covering Freq
12-19-2024_0000_08.log:[2024-12-19 13:02:35.475983] (error)   [charles] 43830C  TG:                       - (     32048) Freq: 859.287500 MHz    Not Recording: no source covering Freq
12-19-2024_0000_08.log:[2024-12-19 13:02:51.715455] (error)   [charles] 43835C  TG:                       - (     32048) Freq: 859.287500 MHz    Not Recording: no source covering Freq
12-19-2024_0000_08.log:[2024-12-19 14:00:00.494659] (error)   [charles] 44240C  TG:                       - (     32048) Freq: 859.287500 MHz    Not Recording: no source covering Freq
12-19-2024_0000_08.log:[2024-12-19 14:00:40.953252] (error)   [charles] 44246C  TG:                       - (     32048) Freq: 859.287500 MHz    Not Recording: no source covering Freq
12-19-2024_0000_08.log:[2024-12-19 14:05:29.885529] (error)   [charles] 44280C  TG:                       - (     40368) Freq: 868.700000 MHz    Not Recording: no source covering Freq
12-19-2024_0000_08.log:[2024-12-19 15:00:13.360154] (error)   [charles] 44588C  TG:                       - (     32048) Freq: 859.287500 MHz    Not Recording: no source covering Freq
12-19-2024_0000_08.log:[2024-12-19 15:00:39.808325] (error)   [charles] 44594C  TG:                       - (     32048) Freq: 859.287500 MHz    Not Recording: no source covering Freq
12-19-2024_0000_08.log:[2024-12-19 16:25:03.160564] (error)   [charles] 45066C  TG:                       - (     40368) Freq: 868.700000 MHz    Not Recording: no source covering Freq

[ilyacodes]

I commented in the TR discord – if this started in April, it seems to correlate to when I was making a lot of refactorings and additions to the Type II logic.

Thoughts:

• Check that 800_reband is being properly parsed – the new name is 800_rebanded but I did add legacy name detection, though maybe there’s a bug?
• Is it possible to enable verbose op25 logs? Level 11(?) or higher (maybe 13 to be safe) will dump all type II parsing data and would be helpful for debugging.

[Dewey3]

I commented in the TR discord – if this started in April, it seems to correlate to when I was making a lot of refactorings and additions to the Type II logic.

Thoughts:

* Check that `800_reband` is being properly parsed – the new name is `800_rebanded` but I did add legacy name detection, though maybe there’s a bug?

* Is it possible to enable verbose op25 logs? Level 11(?) or higher (maybe 13 to be safe) will dump all type II parsing data and would be helpful for debugging.

I made the change from 800_reband to 800_rebanded, but that's not it. I'll try to change the logging a little later. Thanks for your help 👍

[Dewey3]

I commented in the TR discord – if this started in April, it seems to correlate to when I was making a lot of refactorings and additions to the Type II logic.

Thoughts:

* Check that `800_reband` is being properly parsed – the new name is `800_rebanded` but I did add legacy name detection, though maybe there’s a bug?

* Is it possible to enable verbose op25 logs? Level 11(?) or higher (maybe 13 to be safe) will dump all type II parsing data and would be helpful for debugging.

Thank you! This continues happen on a daily basis, yesterday's log is attached (all freqs over 856.5625 are bogus). Can you please inform me where I can set the logging as you have described?

12-26-2024_0002_01.log

[kb2ear]

I commented in the TR discord – if this started in April, it seems to correlate to when I was making a lot of refactorings and additions to the Type II logic.
Thoughts:

* Check that `800_reband` is being properly parsed – the new name is `800_rebanded` but I did add legacy name detection, though maybe there’s a bug?

* Is it possible to enable verbose op25 logs? Level 11(?) or higher (maybe 13 to be safe) will dump all type II parsing data and would be helpful for debugging.

I made the change from 800_reband to 800_rebanded, but that's not it. I'll try to change the logging a little later. Thanks for your help 👍

the docs still say "800_reband" BTW, and I can not find any reference to 800_rebanded in the source code of trunk-recorder

[kb2ear]

Make sure those are valid talkgroups. I would bet that those talkgroup only happen on those weird frequencies and not on system assigned ones. I've see similar things on Smartnet and P25 where there are non-existent talkgroups being sent to non-existent frequencies.