[SLS-OPT] O3K channel model

Jon Hamkins Jon.Hamkins at jpl.caltech.edu
Wed Apr 29 00:19:54 UTC 2020


Nicolò, and all,

We agree that we all can run simulations using the model described on 
either p. 2 or p. 7 of the updated presentation Geraldine sent out, and 
scale from either model to the other afterwards.

We also agree that our top priorities do not include computing the 
mutual information at this time, although it is an interesting idea.

Our top priority will be simulating the codes according to the p. 2/p. 7 
model, in a non-fading environment.

Let's plan to discuss the channel interleaver next Tuesday.  To simplify 
things, I suggest that we consider just one (N,B) interleaver for each 
fading case we want to consider, instead of three.  We just need to make 
it sufficiently long to overcome the fade -- e.g., we could pick it to 
be some multiple of the coherence time of the fade.  (I don't think we 
learn much from also simulating an insufficiently long interleaver, 
since all codes will fail with it; and likewise, the performance of a 
longer-than-necessary interleaver will not perform substantially 
different than the sufficiently long interleaver.)  If we had to pick 
just one fading case, case A might not be the best one, since that is a 
mild case.  A, D, E, and H show progressively more difficulty.

      ----Jon

*Jon Hamkins*
Lead Technologist
33   |   Communications, Tracking, and Radar Division
*O* 818-354-4764   | *M* 626-658-6220

*JPL*   |   jpl.nasa.gov
On 4/28/2020 8:33 AM, Nicolo Mazzali (external) wrote:
> Dear All,
>
> Thanks a lot to Dirk and Géraldine for the very useful contribution.
> In the past we used the "ampère model" (in slide 7 from Géraldine), 
> and, as Géraldine correctly pointed out, it's just a matter of scaling 
> to move from that to the "photons per bit model" (slide 8). So for ESA 
> it's fine either way.
>
> I think that the last details that we need to agree upon before 
> running the new simulation campaign concern the fading and the 
> interleaver dimensioning. In our opinion it is important to include 
> them both in the assessment, since in past meetings it was shown that 
> there is an intertwined relationship between the code, the channel, 
> and the interleaver.
> For simplicity we propose to use fading A from the DLR, leaving the 
> performance assessment with the other time series for the green book. 
> On the interleaver dimensioning, since it depends both on the symbol 
> rate and the fading, I think that we should pick 3 different (N,B) 
> values. Honestly, I don't think we have the time (nor the need) for an 
> accurate optimization of these parameters, so we might well live with 
> a rule-of-thumb dimensioning.
>
> Finally, concerning Géraldine's request for the mutual information, we 
> still don't think that such investigation would be worth the required 
> effort. This applies in particular to fading channels, where the 
> computation of the mutual information is not as straightforward as on 
> the AWGN channel, especially when the fading is not generated 
> according to a given statistical model but numerically by means of a 
> time series. Also, including the interleaver would further complicate 
> the analysis. On top of this, we are not using Matlab for our 
> simulations, and including the mutual information in our simulator 
> would inevitably delay the delivery of the results of the new 
> simulation campaign.
>
> Kind regards,
>
> *Modis for ESA - European Space Agency*
>
> Nicolò Mazzali, PhD
> Communication Systems & Technologies Engineer
>
> Telecommunications Section (TEC-ESC)
> Radio Frequency Systems Division (TEC-ES)
>
> Directorate of Technology, Engineering & Quality (D/TEC)*
>
>
> ESTEC*
> Keplerlaan 1, PO Box 299
> NL-2200 AG Noordwijk, The Netherlands_
> __nicolo.mazzali at esa.int_ <mailto:nicolo.mazzali at esa.int>| 
> _www.esa.int_ <http://www.esa.int/>
> T +31 71 56 53215
>
>
>
>
>
> From: <Dirk.Giggenbach at dlr.de>
> To: <Jon.Hamkins at jpl.caltech.edu>
> Cc: SLS-OPT at mailman.ccsds.org
> Date: 23/04/2020 20:04
> Subject: Re: [SLS-OPT] O3K channel model
> Sent by: "SLS-OPT" <sls-opt-bounces at mailman.ccsds.org>
> ------------------------------------------------------------------------
>
>
> Hi Jon,
>
> we do not have data APD-RFEs for that low rate which we could 
> test/measure.
>
> I checked some datasheets, the one coming closest to 1.22Mbps is the 
> LaserComponents IAG350H1D –APD Receiver with 1MHz Bandwidth and 350µm 
> APD.  They don’t show dark current in the DS.
>
>
> These values seem close to best compared to other receivers:
>
> Responsivity=94MV/W  ,  I guess that includes Amplification of M=10, 
> so TIA would be ~9MOhm
>
> NEP=32fW/sqrt(Hz)   -   referred noise density of 0.3E-12 A/sqrt(Hz) 
>  or  3µV/sqrt(Hz)
>
> _https://www.lasercomponents.com/de-en/product/apd-receivers/_
>
> Hope that helps,
>
> Dirk
>
> *Von:* SLS-OPT [mailto:sls-opt-bounces at mailman.ccsds.org] *Im Auftrag 
> von *Jon Hamkins via SLS-OPT*
> Gesendet:* Mittwoch, 15. April 2020 17:20*
> An:* SLS-OPT at mailman.ccsds.org*
> Betreff:* [SLS-OPT] O3K channel model
>
>
> Attached is the O3K channel model we discussed yesterday.  It also 
> contains a suggestion for how to state the O3K coding performance.  I 
> welcome your comments.  If we can agree to the model in the next week 
> or so, each agency may be able to begin simulating with it and discuss 
> some initial results at the May teleconferences.
> A few notes:
>
>   * I am suggesting we study 10 Gsps, 78.125 Msps, and 1.22 Mbps,
>     since those include the highest and lowest data rates and one in
>     the middle.
>   * I don't have a good suggestion for the TIA noise density at 1.22
>     Msps.  Dirk, would you be able to supply a number?
>   * I have algebraically simplified the expressions for the means and
>     variances.  You can compare the model to the expressions Dariush
>     presented on yesterday (p. 5), and check my algebra.
>   * I have included the fading parameter as well.  Just set rho=1 if
>     you want no fading.
>
>    ----Jon
>
> -- *
> Jon Hamkins*
> Lead Technologist
> 33   |   Communications, Tracking, and Radar Division*
> O* 818-354-4764   | *M* 626-658-6220
> *
> JPL*   |   jpl.nasa.gov
>
>
> _______________________________________________
> SLS-OPT mailing list
> SLS-OPT at mailman.ccsds.org
> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-opt
>
>
> 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 at esa.int).
>
> _______________________________________________
> SLS-OPT mailing list
> SLS-OPT at mailman.ccsds.org
> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-opt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-opt/attachments/20200428/e90dc13a/attachment-0001.htm>


More information about the SLS-OPT mailing list