[Sls-slp] JAXA RID against OID Frame

Thu Mar 5 00:17:42 UTC 2009

NO,  Projects should not be allowed to get fill/idle/OID packets.      OID frames on the other hand can contain insert data if managed for the physical channel (TM or AOS)

On 3/4/09 8:26 AM, "Kazz, Greg J" <greg.j.kazz at jpl.nasa.gov> wrote:

You are all thinking very logically. But flight projects often cut corners and find all sorts of unusual and esoteric ways of utilizing the standards. Consensus on this matter seems to be, yes it is possible, but the limit of the probability of doing so approaches zero.

Greg

________________________________

From: Greenberg, Edward
Sent: Wednesday, March 04, 2009 3:03 AM
To: Matt Cosby; Gian.Paolo.Calzolari at esa.int; Kazz, Greg J
Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Tim RAY; Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org; gilles.moury at cnes.fr
Subject: Re: [Sls-slp] JAXA RID against OID Frame

I agree with Matt and Gian Paolo.  If you want to send a packet with a meaningful secondary header and no useful information thengive it an APID with that interpretation, not one that says it only contains idle data.    Have a wonderful time discussing this trivia.

On 3/4/09 1:59 AM, "Cosby Matthew" <MCOSBY at qinetiq.com> wrote:
Greg,

I agree with Gian Paolo.

When our TM systems detect an Idle Packet (APID set to 0x7FF) it discards it.

>From the TM Spec.
4.3.2.5 Extracted Packets shall be delivered to the users on the basis of the PVN in their header. Incomplete Packets are not required to be delivered in cross support situations.

NOTE . Idle Packets are discarded. Data Fields that contain only Idle Data are also discarded.

This states that the Idle Packet is discarded and implies that there is no user data within the packet. There probability isn't any where in the standard stating that you can't put a secondary header in the Idle Packet, but this is implied as this packet is thrown out. So quoting Gian Paolo it would be crazy to put any useful data into the idle packet.

Regards,

Matt.

Matthew Cosby

QinetiQ
Bldg X107 Rm G003
Cody Technology Park
Ively Road, Farnborough
Hants, GU14 0LX

  Tel:  01252 396313
  Email:  mcosby at QinetiQ.com
  Fax:  01252 392969
  Web:  www.QinetiQ.com <http://www.qinetiq.com><http://www.qinetiq.com>
QinetiQ - The Global Defence and Security Experts

P Please consider the environment before printing this email.

________________________________

From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp-bounces at mailman.ccsds.org] <mailto:sls-slp-bounces at mailman.ccsds.org%5d><mailto:sls-slp-bounces at mailman.ccsds.org%5d> On Behalf Of Gian.Paolo.Calzolari at esa.int
Sent: 03 March 2009 18:21
To: Kazz, Greg J
Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Ray,Timothy J. (GSFC-583.0); Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org; gilles.moury at cnes.fr; Greenberg,Edward
Subject: RE: [Sls-slp] JAXA RID against OID Frame

"Kazz, Greg J" <greg.j.kazz at jpl.nasa.gov> wrote on 03-03-2009 18:21:35:

> G.P.,
>
> But a Space Packet can contain a Secondary Header, which could
> contain useful data as well. So in that sense, OID Packet also makes
> sense. In other words, discarding an "Idle Packet" can have a
> drawback or unintended consequence. CCSDS needs to use consistent
> terminology across the board and I think that is what this JAXA rid
> is pointing out. I am looking forward to Marjorie's responses to
> those rids as well.
>
> thanks,
>
> Greg
>

Greg,
     The Frame has a structure linked to the Virtual Channel and all frames on a VC have the secondary header (if this is used) independently they are OID or not.
Conversely the Space Packet has a structure linked to the APID and a mission implementing a Packet Secondary Header on Idle Packets would just be crazy. :-) In addition, I think that, being the idle APID fixed, there is no chance for having a Secondary header in an Idle Packet [this is TBC].

Comments/confirmations are welcome.

Ciao

Gian Paolo
The information contained in this E-Mail and any subsequent
correspondence is private and is intended solely for the intended
recipient(s).  The information in this communication may be
confidential and/or legally privileged.  Nothing in this e-mail is
intended to conclude a contract on behalf of QinetiQ or make QinetiQ
subject to any other legally binding commitments, unless the e-mail
contains an express statement to the contrary or incorporates a formal Purchase Order.

For those other than the recipient any disclosure, copying,
distribution, or any action taken or omitted to be taken in reliance
on such information is prohibited and may be unlawful.

Emails and other electronic communication with QinetiQ may be
monitored and recorded for business purposes including security, audit
and archival purposes.  Any response to this email indicates consent
to this.

Telephone calls to QinetiQ may be monitored or recorded for quality
control, security and other business purposes.

QinetiQ Limited
Registered in England & Wales: Company Number:3796233
Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom
Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, Hampshire, GU14 0LX, United Kingdom
http://www.qinetiq.com/home/notices/legal.html <http://www.QinetiQ.com/home/legal.html><http://www.QinetiQ.com/home/legal.html>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20090304/467805a4/attachment.html>