Annoying chirp at end of (some) P25 calls using trunk-recorder

[smsscottsmith]

(Updating did not help)

 

[smsscottsmith]

Must be op25's fault, even though neither variant of op25 has that problem when run on their own.

While it is true that the developer of trunk recorder grabbed code from an earlier version of op25 to implement his P25 protocol handler, that does not make the application in any way related to, or dependent on op25. Both apps are open source and developers are free to reuse whatever code they deem suitable (with appropriate attribution), much like op25 itself has reused code from numerous other sources including trunk88, mmdvm, gr-smartnet, gr-fsk4, ezpwd, and so forth.

So after looking at things more closely as well as speaking to another guy who is ALSO using trunk-recorder to receive a conventionalP25 system, I have some findings. The following is json output for a call I recorded but reformatted to make important associations more clear.

{"freq": 470512500, "time": 1661665672, "pos": 0.00, "len": 2.52, "error_count": "0", "spike_count": "0"},
{"src": 453, "time": 1661665672, "pos": 0.00, "emergency": 0, "signal_system": "", "tag": ""},

{"freq": 470512500, "time": 1661665676, "pos": 2.52, "len": 1.44, "error_count": "30", "spike_count": "2"},
{"src": 1, "time": 1661665676, "pos": 2.52, "emergency": 0, "signal_system": "", "tag": ""},

{"freq": 470512500, "time": 1661665678, "pos": 3.96, "len": 2.34, "error_count": "0", "spike_count": "0"},
{"src": 453, "time": 1661665678, "pos": 3.96, "emergency": 0, "signal_system": "", "tag": ""},

{"freq": 470512500, "time": 1661665682, "pos": 6.30, "len": 1.08, "error_count": "105", "spike_count": "6"},
{"src": 1, "time": 1661665682, "pos": 6.30, "emergency": 0, "signal_system": "", "tag": ""}

Both myself and this other user (been speaking to him on the trunk-recorder Discord and his handle is Taclane) have noticed a pattern where we only find errors/spikes when the source call comes from dispatch/control and this is also when that obnoxious sound is heard. I am going to attempt to receive at least one other conventionalP25 system in my area to see if I notice the same thing.

I'm letting you know on the off chance that something about this "speaks" to you, heh...

Thanks.

 

[boatbod]

So after looking at things more closely as well as speaking to another guy who is ALSO using trunk-recorder to receive a conventionalP25 system, I have some findings. The following is json output for a call I recorded but reformatted to make important associations more clear.

{"freq": 470512500, "time": 1661665672, "pos": 0.00, "len": 2.52, "error_count": "0", "spike_count": "0"},
{"src": 453, "time": 1661665672, "pos": 0.00, "emergency": 0, "signal_system": "", "tag": ""},

{"freq": 470512500, "time": 1661665676, "pos": 2.52, "len": 1.44, "error_count": "30", "spike_count": "2"},
{"src": 1, "time": 1661665676, "pos": 2.52, "emergency": 0, "signal_system": "", "tag": ""},

{"freq": 470512500, "time": 1661665678, "pos": 3.96, "len": 2.34, "error_count": "0", "spike_count": "0"},
{"src": 453, "time": 1661665678, "pos": 3.96, "emergency": 0, "signal_system": "", "tag": ""},

{"freq": 470512500, "time": 1661665682, "pos": 6.30, "len": 1.08, "error_count": "105", "spike_count": "6"},
{"src": 1, "time": 1661665682, "pos": 6.30, "emergency": 0, "signal_system": "", "tag": ""}

Both myself and this other user (been speaking to him on the trunk-recorder Discord and his handle is Taclane) have noticed a pattern where we only find errors/spikes when the source call comes from dispatch/control and this is also when that obnoxious sound is heard. I am going to attempt to receive at least one other conventionalP25 system in my area to see if I notice the same thing.

I'm letting you know on the off chance that something about this "speaks" to you, heh...

Thanks.

With that high of an error count one might reasonably expect to be encountering burst noise or a tuning/framing hiccup. Whatever it is, it's not something typically experienced in op25, which is where my sand box starts and ends.

 

[smsscottsmith]

welp, though I disagree, the only supporting evidence I have is one other user of trunk-recorder who corroborates that he experiences detected errors specifically when (for whatever reason) control/dispatch is transmitting so I guess I'm SOL.

I'm going to try taking some IQ recordings and maybe switching to a R820T2-based receiver as I haven't been the greatest fan of the E4000 stuff anyways. I may also make a temporary setup at my work where, coincidentally, the police department is one of the other nearby ones that use p25c and take some data.

In the meantime I think I may simply take my feed down --- I can only imagine that any listeners aren't exactly enjoying the situation lol

 

[boatbod]

welp, though I disagree, the only supporting evidence I have is one other user of trunk-recorder who corroborates that he experiences detected errors specifically when (for whatever reason) control/dispatch is transmitting so I guess I'm SOL.

Perfectly possible it's a trunk-recorder bug or an issue with what's whats being received off the air, but once again I'll repeat that this is NOT an op25 problem. There are far too many op25 instances out there running happily and receiving dispatch broadcasts for this to be a systemic problem. Moreover the op25 code incorporated and used by trunk-recorder is (presumably) maintained by the trunk-recorder devs, so you're barking at the wrong tree. Have you tried running one of the actual op25 apps?

 

[smsscottsmith]

Perfectly possible it's a trunk-recorder bug or an issue with what's whats being received off the air, but once again I'll repeat that this is NOT an op25 problem. There are far too many op25 instances out there running happily and receiving dispatch broadcasts for this to be a systemic problem. Moreover the op25 code incorporated and used by trunk-recorder is (presumably) maintained by the trunk-recorder devs, so you're barking at the wrong tree. Have you tried running one of the actual op25 apps?

Yeah, my apologies. I was thinking about my post all day at work regarding how much of an ass I sound like. Disregard. I have some leads. If I solve, I'll post here.

 

[smsscottsmith]

I joined their discord. Will post here if I have joy. Apparently the version in the broadcastify image is very old. So that's a starting point.

Fixed it thanks to some folks in the trunk-recorder Discord.
Basically change vocoders.

// /master/lib/op25_repeater/lib/p25p1_fdma.cc
                   if (d_do_audio_output) { // LINE 685
                        if (!d_do_nocrypt || !encrypted()) {
                            std::string encr = "{\"encrypted\": " + std::to_string(0) + ", \"algid\": " + std::to_string(ess_algid) + ", \"keyid\": " + std::to_string(ess_keyid) + "}";
                            send_msg(encr, M_P25_JSON_DATA);
                            // This is the Vocoder that OP25 currently uses.
                            // WAS COMMENTED OUT - 082922 SMS
                            software_decoder.decode_fullrate(u[0], u[1], u[2], u[3], u[4], u[5], u[6], u[7], E0, ET);
                            audio_samples *samples = software_decoder.audio();
                            for (int i=0; i < SND_FRAME; i++) {
                                   if (samples->size() > 0) {
                                       snd[i] = (int16_t)(samples->front());
                                    samples->pop_front();
                                } else {
                                    snd[i] = 0;
                                }
                            }

                            // This is the older, fullrate vocoder
                            // it was copied from p25p1_voice_decode.cc
                            // WAS *NOT* COMMENTED OUT - 082922 SMS
                            /*int16_t frame_vector[8];

                            for (int i=0; i < 8; i++) { // Ugh. For compatibility convert imbe params from uint32_t to int16_t
                                frame_vector[i] = u[i];
                            }
                            frame_vector[7] >>= 1;
                            vocoder.imbe_decode(frame_vector, snd);*/