<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Dear Dennis and all,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">I eventually found the time to have an in-depth view of Wai and Wing input (below referred as technical note, TN for short).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">I would like to provide a feedback for your consideration when incorporating the TN as annex of the green book (CCSDS 413.1-G-2 Simultaneous Transmission of GMSK Telemetry and PN Ranging).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">The first point is of a kind of editorial nature.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Whan I created the first annex, I made an effort to adhere, as much as possible, to the terminology and conventions described in the target book, for example through the re-iterated use of PT Ts/No,
 omnipresent in the book, in formulas and figures.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">At the moment I think this goal is not achieved in the TN, which makes extensive use of other quantities in formulas and plots, and it runs a bit “independently” from the future container. It could
 be difficult for a reader to do all required translations to make the considerations applicable to his/her case.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">My suggestion here would be to take a bit of effort in aligning the treatment to the green book.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">The second point is about a complementarity which I see between this TN and the input I had previously sent.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Whereas I tackled primarily the need to have a structured process for establishing proper configurations (a need which emerged during these investigations), especially with simultaneous presence
 of high Doppler dynamics and low signal to noise, the goal of the TN is of a more explorative nature (in my view), with an investigation path involving multiple architectures and combinations of successful/failed attempts.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">I think this complementarity could be made more evident, e.g. by clarifying in the TN, maybe in the conclusions, that different (present or future) implementation and algorithms could lead to different
 results, e.g. in terms of supportable gammas.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">The third point is of a technical nature. It is related to an identified threshold for supportable gamma with GMSK BTs = 0.25. As clarified in the past, and also reflected in the annex I produced,
 supportability of a configuration is also strongly depending on the amount of phase jitter (linked to the SNR), in addition to Doppler dynamics.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Figure 2 in my annex is absolutely clear on this point.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">It is numerically clear that the behaviour of the configurations which are claimed to confirm the gamma = 0.02 threshold in the hardware validation section is dominated by the amount of phase jitter.
 By reducing such amount it is certainly possible to exceed such threshold, as later acknowledged even in the TN.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">So in summary, I find the following sentence misleading, it could maybe be revised together with similar statements in the conclusions.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">“The </span><span style="font-family:"Cambria Math",serif;mso-fareast-language:EN-US">𝛾</span><span style="mso-fareast-language:EN-US"> = 0.02 inoperability threshold was confirmed. We must caution
 that this conclusion has a caveat. The architecture of the hardware is not identical to low-SNR MAP used in this analysis. It is more related to the high-SNR MAP [10]. The fact that both architectures arrive at the same inoperable point leads one to conclude
 that the result is fundamental.”<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Other than the above, I find the TN informative, and I acknowledge the immense effort that was involved (I can say symmetrically spent on ESA side)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">I hope the above is useful, and as usual I remain available for any question.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><br>
Regards<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Marco<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> SLS-RFM <sls-rfm-bounces@mailman.ccsds.org>
<b>On Behalf Of </b>Lee, Dennis K (US 332G) via SLS-RFM<br>
<b>Sent:</b> 03 May 2023 13:15<br>
<b>To:</b> sls-rfm@mailman.ccsds.org<br>
<b>Subject:</b> [Sls-rfm] RFM inputs (batch #3)<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">SLS-RFM_23-05 and SLS-RFM_23-06 attached.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify
 the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo@esa.int).
</body>
</html>