<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"><title>Prox-1 Data Link Layer review - two specification issues</title>
</head>
<body>
<font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">Dear SLS-SLP,<br>
<br>
We need to consider the following feedback I have received from the NASA Electra implementers with respect to the current Prox-1 Data Link Layer specification before it is released again.<br>
Please read the following text and let me know how you feel about these two issues below. <br>
I plan to discuss them in an upcoming telecon before the SLP meeting in Berlin.<br>
<br>
Best regards,<br>
<br>
Greg Kazz<br>
Chairman SLS-SLP WG<br>
<br>
1. Carrier_Only_Duration, Acquisition_Idle_Duration, Tail_Idle_duration values – potentially different MIB values for hailing vs comm change<br>
<br>
NASA figured there may be theoretical cases where you would not want to force them to be the same. For instance, you might want longer times for hailing to assure lock, but smaller times for comm change (where you may be able to leverage pre-existing lock) to reduce the amount of non-data-transfer “down time” added by comm changes in adaptive data rate operations. Our default values only differ in Carrier_Only_Duration, which is 1.0 sec for hailing and zero for comm change. <br>
<br>
2. What’s the motivating case for the newly proposed S80: Reconnect State in Prox-1 ?<br>
<br>
This is where the carrier_loss_timer expires on the orbiter (Hailer), and makes the orbiter drop it’s carrier long enough, so that the lander is forced to drop carrier lock as well. Matt claims the protocol will simply let him flywheel through such a short term glitch. He is really asking do we really need this reconnect feature?<br>
<br>
NASA has observed in the lab the following scenario (not yet in flight, though that’s probably because the MRO Electra tends to hold on to carrier too hard rather than lose carrier too easily):<br>
</span></font><ol><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">Hailing occurs at hailing settings (frequency, data rate, etc).
</span></font><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">Hailing succeeds and session commences at active settings (different from hailing settings).
</span></font><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">Orbiter loses carrier and starts rehailing (which the Electras do at the original hail settings; since rehailing is currently outside the Prox-1 spec, this was just our design decision), but the lander does not lose carrier (ie. for a time exceeding the lander’s Carrier_Loss_Timeout) and so the lander is still listening at the active settings. It is easy for the lander to retain carrier lock even if the orbiter is at a different data rate or coding.
</span></font><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">Communication may never be re-established (automatically). <br>
</span></font></ol><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
Similar behavior can also occur if the lander hears the hail and goes to the active settings, but the orbiter does not hear the lander response. Unless the the lander’s Carrier_Loss_Timeout is less than the orbiter’s Hail_Wait_Duration , this can happen in the existing Prox-1 spec, and there is no obvious reason why the Hail_Wait_Duration should be linked to the Carrier_Loss_Timeout in this way. And nominal Carrier_Loss_Timeout might be large to flywheel over short outages. So in Electra we added a Rehail_Gap_Duration to be linked to the Carrier_Loss_Timeout, rather than adding constraints to the Hail_Wait_Duration.<br>
<br>
There is an argument to add this constraint to the Hail_Wait_Duration, just depends on preference for adding new entities versus loading existing entities with multiple purposes. In Electra we generally try to go for the more flexible way, which we usually think is adding more settings. That does not mean that’s the only way.<br>
</span></font>
</body>
</html>