Open FarvaTechnology opened 5 years ago
Looking at Error should help. This is basically the number of decode errors that are found when decoding the digitized audio. Spike counts when there are a lot of back to back errors. Most of this comes from here: https://github.com/robotastic/trunk-recorder/blob/a5453f277c71c3bba2bb384b7f5984af0c0150c9/lib/op25_repeater/lib/p25p1_fdma.cc#L651
You might be able to find a different way to pull the stats too.
Also - the Admin portal maps the errors vs freq. If you log in there you can see what freq and rtl sticks are doing bad. With most systems, each freq has a seperate filter and amp, and sometimes they can be bad on certain freq.
Admin Portal? Despite all my geek like work on this project - I have no idea what the admin portal is. LOL Is there a web interface to trunk-recorder? If so, where is it?
MY CODE CHANGES: To help me track down "jitter"... I made the following changes that will allow me to look at the JSON output and figure out what frequencies are linked to what cards for EACH transmission/recording.
Basically I am adding "device" value from the config file to the JSON output. Best I can tell, this value becomes attached to the SOURCE obj and the RECORDER obj.
I am simply grabbing this object at the time the FREQ_LIST obj is being created. Hopefully if a long recorded conversation jumps across frequencies... My JSON ouputput file should list EACH device that the conversation was recorded on.
When I create my AUTOMATED jitter testing process to examine JSON files - I should now be able to create "trends" of what files have JITTER and EASILY isolate it down to the specific RTL/SDR card VS only having the frequency and having to do the conversion to figure out what card it happened on.
I am not sure if the admins would consider adding "DEVICE" to the json output values. I think it would be a "nice to have".
Here are my changes: myfile << "{ \"freq\": " << std::fixed << FormatFreq(freq_list[i].freq) << ", \"time\": " << freq_list[i].time << ", \"pos\": " << freq_list[i].position << ", \"len\": " << freq_list[i].total_len << ", \"device\": " << freq_list[i].device << ", \"error_count\": " << freq_list[i].error_count << ", \"spike_count\": " << freq_list[i].spike_count << "}";//01072019
Call.cc
// if there call is being recorded and it isn't the first time the freq is being set
if (recorder && (freq_count > 0)) {
Rx_Status rx_status = recorder->get_rx_status();
freq_list[freq_count - 1].total_len = rx_status.total_len;
freq_list[freq_count - 1].spike_count = rx_status.spike_count;
freq_list[freq_count - 1].error_count = rx_status.error_count;
freq_list[freq_count - 1].device = recorder->get_source()->get_device();//01072019
}
Call_Freq *freq_list = this->get_freq_list();
int freq_count = this->get_freq_count();
for (int i = 0; i < freq_count; i++) {
boost::property_tree::ptree freq_node;
freq_node.put("device", freq_list[i].device);//01072019
freq_node.put("freq", freq_list[i].freq);
freq_node.put("time", freq_list[i].time);
freq_node.put("spikes", freq_list[i].spike_count);
freq_node.put("errors", freq_list[i].error_count);
freq_node.put("position", freq_list[i].position);
freq_node.put("length", freq_list[i].total_len);
freq_list_node.push_back(std::make_pair("", freq_node));
}
call_node.add_child("freqList", freq_list_node);
Don't forget to modify call.h for new value (std::string device)
It is just me working on this. That seems like a good change. You can reverse from the freq, what device it was, but that is a pain. Would you be able to submit this change as a Pull Request using GitHub? That way I can just click a button. If that is all new, no worries, I can just cut and paste.
Yep - I have a site up: openmhz.com which lets you archive and stream the audio. goto admin.openmhz.com to sign up. You have to send up the audio in M4A. more info here: https://github.com/robotastic/trunk-recorder/wiki/Uploading-to-OpenMHz
All
I am experiencing jitter within one of my feeds and I want to isolate what card it's happening on via an automated process (NAGIOS).
In order to do this - I must learn more about the "error_code" and "spike_count" rates listed within the freqList feature of the JSON file that is provided with each sound file.
The goal of NAGIOS automation will be: 1) All .wav files from trunk-recorder are sent to a media processing server for conversion to MP3. 2) Within the media conversion process - I want to test error_code & spike_count rates to see if they are outside acceptable thresholds. 3) When an event occurs outside threshold - I will have media server send the event to the NAGIOS server as a WARN or an ALERT type event with frequency and channel/agency that this occurred on. This will allow for troubleshooting and resolution via an automated alerting system.
In order for me to accomplish this - I must learn more about the error_count and spike_count.
Can someone please assist me in learning more about these key/value pairs?
Are these values coming from trunk-recorder? Are these values coming from gnuradio libraries?
What are the thresholds for an error_code that would be an indication of "jitter" in a digital system (you know... That voip'ish sound).
Thanks in advance for your assist with this question.
++Todd