- Joined
- Jun 6, 2020
- Messages
- 14
(Updating did not help)
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.
{"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": ""}
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.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.
JSON:{"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.
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?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.
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.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?
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.
// /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);*/