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

Duplicate Recordings on Smartnet Analog #851

Open
decoy4fun opened this issue Nov 4, 2023 · 4 comments
Open

Duplicate Recordings on Smartnet Analog #851

decoy4fun opened this issue Nov 4, 2023 · 4 comments

Comments

@decoy4fun
Copy link
Contributor

decoy4fun commented Nov 4, 2023

When the system I am listening to gets busy, I end up with a lot of what sounds like duplicate calls in my recordings. What's actually happening though, is when a call ends on the trunked system I'm listening to, it's assigning another talkgroup to the same frequency within the 1 second I have set in my config. Trunk-recorder continues the existing call as though it's the original talkgroup, but also spins up another recorder for the new call so the same conversation gets recorded twice.

On September 1st at 13:35 we had a working structure fire. A responding ambulance got into a pretty hefty accident and there was so much traffic that there were calls recorded as many as 3-5 times under various unrelated talkgroups. Recordings are available under the "Cache" OpenMHz feed.

This issue is ultimately locking all of my recorders (which I've seen all recording the same frequency at once in the past) so I'm missing other calls.

To me, It doesn't seem like TR is recognizing the change in TG ID's so it's not stopping the original recording when a new one starts on the same frequency.

I am listening to this system via the Logan Peak site.

My original config;

{
    "ver": 2,
    "defaultMode": "analog",
    "callTimeout": "1",
    "logLevel": "info",
    "logFile": true,
    "uploadServer": "https://api.openmhz.com",
    "broadcastifyCallsServer": "https://api.broadcastify.com/call-upload",
    "captureDir": "/home/user/SDR/Recordings/",
    "sources": [{
            "center": 855862500,
            "rate": 2148000,
            "error": 1400,
            "gain": 40,
            "digitalRecorders": 1,
            "analogRecorders": 5,
            "driver": "osmosdr",
            "device": "rtl=001",
            "enabled": true
        },{
            "center": 858075000,
            "rate": 2148000,
            "error": 1400,
            "gain": 40,
            "digitalRecorders": 1,
            "analogRecorders": 5,
            "driver": "osmosdr",
            "device": "rtl=002",
            "enabled": true
        },{
            "center": 860600000,
            "rate": 2148000,
            "error": 1400,
            "gain": 40,
            "digitalRecorders": 1,
            "analogRecorders": 5,
            "driver": "osmosdr",
            "device": "rtl=003",
            "enabled": true
        },{   
            "center": 146940000,
            "rate": 3700000,
            "error": 1400,
            "gain": 55,
            "debugRecorders": 0,
            "digitalRecorders": 0,
            "driver": "osmosdr",
            "device": "rtl=004",
           "enabled": false
        }],
 "systems": [{
            "control_channels": [856762500, 858937500],
            "type": "smartnet",
            "talkgroupsFile": "aaUCA-ALL.csv",
            "shortName": "Cache",
            "modulation": "qpsk",
            "analogLevels": 4,
            "squelch": -45,
            "bandplan": "800_reband",
            "audioArchive": false,
            "transmissionArchive": false,
            "callLog": false,
            "compressWav": true,
            "recordUnknown": true,
            "conversationMode": false,
            "talkgroupDisplayFormat": "id_tag",
            "broadcastifyApiKey": "redacted",
            "broadcastifySystemId": "2859",
            "apiKey": "redacted",
            "enabled": true
        },{
            "type": "conventional",
            "channelFile": "aahamchannel.csv",
            "shortName": "CacheHamRadio",
            "callLog": false,
            "squelch": -25,
            "audioArchive": false,
            "analogLevels": 4,
            "compressWav": "true",
            "transmissionArchive": false,
            "enabled": false
        }],
    "plugins": [{
            "name": "rdioscanner_uploader",
            "library": "librdioscanner_uploader.so",
            "server": "redacted",
            "enabled": true,
            "systems": [{
                    "shortName": "Cache",
                    "apiKey": "redacted",
                    "systemId": "redacted"
                }]
        }]
}
@decoy4fun
Copy link
Contributor Author

decoy4fun commented Nov 4, 2023

To aid in troubleshooting we've already done in discord, this comment from tadscottsmith states:

There could be a flaw in the logic somewhere as well. On first glance it looks like the P25 since_last_write() logic might have been updated, where the analog recorder hasn't.

https://github.com/robotastic/trunk-recorder/blob/01f3f624ba68e41f3a5cef540a283851bd6f52be/trunk-recorder/recorders/p25_recorder_decode.cc#L64-L68C1

https://github.com/robotastic/trunk-recorder/blob/01f3f624ba68e41f3a5cef540a283851bd6f52be/trunk-recorder/recorders/analog_recorder.cc#L264-L267C2

Per this comment, it's possible a similar issue was fixed for p25 systems but the solution may not have been copied for analog systems.

@robotastic
Copy link
Owner

Is this still an issue? I don't remember if this was something that may have been ficxed with v5.0

@decoy4fun
Copy link
Contributor Author

It was still an issue after releasing v5.0 but the smartnet analog system I was monitoring has been shut down and is now p25 phase II so I'm unable to verify/test anything anymore.

@Cole0209
Copy link

FYI this does still occur regularly for smartnet. As far as I could figure out it seems to happen only when the system is reusing frequencies right after another TG finishes with it. Watching the spectrum on another SDR it looks like the repeater for that frequency isn't dropping so the squelch never closes. The next transmission on a different TG will be recorded in full and this will continue until the system lets that repeater drop. Not sure how the smartnet recording works for t-r but something to force end the call even if it doesn't drop below the squelch threshold when another call is started on the same frequency might be a fix?

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

No branches or pull requests

3 participants