Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Looking for Wrong Frequencies #947

Open
Dewey3 opened this issue Apr 11, 2024 · 4 comments
Open

Looking for Wrong Frequencies #947

Dewey3 opened this issue Apr 11, 2024 · 4 comments

Comments

@Dewey3
Copy link

Dewey3 commented Apr 11, 2024

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
A42E.log

@taclane
Copy link
Contributor

taclane commented Apr 11, 2024

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
Copy link
Author

Dewey3 commented Apr 11, 2024

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
Copy link
Author

Dewey3 commented Apr 11, 2024

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
Copy link
Author

Dewey3 commented Apr 13, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants