[swift-users] [External] Some extra logging/API enhancement to help set synchronization length (STANAG 5069 M)

[Steve Kille]

Andrew,

 

From: Andrew Kamel <andrew.kamel at collins.com> 
Sent: 31 August 2020 20:51
To: Steve Kille <steve.kille at isode.com>
Cc: Jennie Pryor <jennie.pryor at collins.com>; Joseph Splean II <joseph.splean at collins.com>; Xavier Esneu <xavier.esneu at collins.com>; Mark Jorgenson <mark.jorgenson at collins.com>; Murat Dursun <murat.dursun at isode.com>; Mark Timberlake <mark.timberlake at isode.com>
Subject: Re: [External] Some extra logging/API enhancement to help set synchronization length (STANAG 5069 M)

 

Hi Steve,

If I'm understanding you correctly, you would want a status message coming out of the ALE for this so that you can tweak and adjust parameters from your side of things?

It's unfortunately not a trivial job and I don't have anybody to spare at the moment.

[Steve Kille] 

This is Modem information, not ALE.     The information would come from the code that is analysing the synchronization preamble, and controlling when to start looking for the actual waveform.   I’d expect the value to be returned as an additional parameter along with the transmission connect information (receive side) indicating that a new transmission has been received.

 

I wonder if this type of profiling is better done in a controlled lab environment though?

You could potentially create plots showing achieved detection rate against SNR for a given value of M.

[Steve Kille] 

 

I don’t think lab measurements would be much use.    I noted the impact of M when we made the following set of measurements using simulators

   https://www.isode.com/whitepapers/interleaver-simulator-analysis.html

 

 

We found that with 5069 that when synchronization did not happen, that the connection failed and did not recover (4539 is better at picking up connections part way through – Mark explained why).   The effect seemed particularly strong for CCIR POOR, even at quite fast speeds.   I suspect this is due to deep fades, which a 250 ms (M=1) preamble will not span.   We addressed this by setting M=32 for all the tests, which did the trick.

 

Here, we need to determine best setting of M for actual conditions.   Increasing M improves connection resilience, but increases latency and decreases throughput.   So a careful setting seems important.

 

To me, this is something we want to be measuring carefully, so we can choose and optimal setting.    This extra information is needed to achieve this

 

Andrew

[Steve Kille] 

 

Regards

 

 

Steve

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </lists/pipermail/swift-users/attachments/20200901/3f6efee2/attachment.html>