Welcome to dumpvdl2 Discussions!

[szpajder]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

[jmatchet]

An associate of mine had started modifying and older version (1.3 or 4) to add a congestion time counter Frame_CV to the avlc_frame_qentry_t structure When the frame demodulates and decodes as good, that frame time counter would be added to CV1 variable, and when it fails, it would be added to CV2. CV1 is valid VDL received, and CV2 is bad frame or energy (ie congestion) received.

I wanted to continue my colleagues work, but see the structure has been re-factored with version 2.2 .

He also would print out the CV1/CV2 values with the frequency that they were received.

With the 2.2 version, would you recommend I keep these added congestion counters to the avlc_frame_qentry_1 or move them into metadata?

Does the new stats package have any of this type of congestion information?

[szpajder]

With the 2.2 version, would you recommend I keep these added congestion counters to the avlc_frame_qentry_1 or move them into metadata?

Put them into vdl2_msg_metadata. These are per-channel metrics similar to the noise floor estimate (nf_pwr_dbfs) which is already there. Metadata gets passed to all formatting routines (fmtr_text, fmtr_json, etc) - you may modify them to show your counters in the formatted output. These functions don't have access to avlc_frame_qentry_t structure, so you couldn't print them if you'd put them there.

Does the new stats package have any of this type of congestion information?

Nope, the program doesn't compute this. However nothing prevents you from adding new StatsD counters for your CV1/CV2 metrics.

[jmatchet]

Thank you for the advice.
I tested out the Channel Utilization/Counter changes on the 1.3.1 and 1.4 versions of dumpvdl2 and likely will need to debug modifications before porting to 2.2.

Using a R&S radio to simulate 100% channel utilization, a dp8sk test tone (though not a valid VDL frame) was generated to emulate a stuck PTT, which can occur from time to time on real aircraft.

The 1.3.1 and 1.4 versions of dumpvdl detected the 100% Channel Util and non vdl counter CV2 increments, but after outputing the 2 CU timestamped updates a minute apart, the decoder stopped incrementing CU counters. Once the PTT tone is removed, the count restarts. I may have a bug in the added CU code.
EAM.zip