From greg.j.kazz at jpl.nasa.gov Mon Mar 14 19:18:46 2005 From: greg.j.kazz at jpl.nasa.gov (Greg Kazz) Date: Mon, 14 Mar 2005 11:18:46 -0800 Subject: [Sls-slp] Fwd: Re: [Sls-rfm] Re: [CESG] URGENT: review of Prox-1 pink sheets Message-ID: <6.2.0.14.2.20050314111647.02b7cbe8@mail.jpl.nasa.gov> All, Comments from Don Olsen (Aerospace Corp.) on the Prox-1 Data Rate Stability requirements pink sheet I sent out earlier. Greg >Date: Fri, 11 Mar 2005 22:58:51 +0100 >From: Enrico.Vassallo at esa.int >Subject: Re: [Sls-rfm] Re: [CESG] URGENT: review of Prox-1 pink sheets >To: Donald P Olsen >Cc: Greg J Kazz , Jean-Luc.Gerner at esa.int, > sls-rfm at mailman.ccsds.org >X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 >X-MIMETrack: Serialize by Router on esocmta1/esoc/ESA(Release 5.0.13a |April > 8, 2004) at 03/11/2005 10:58:52 PM >X-Source-IP: esacom59-ext.esoc.esa.int [131.176.86.4] >X-Source-Sender: Enrico.Vassallo at esa.int >X-JPL-spam-score: 0.00% >Original-recipient: rfc822;gkazz at mail.jpl.nasa.gov > > >Donald, > >I would tend to agree with you. CCSDS standards should be leading standards >for future implementation. Here it seems to me that we are trying to >standardize an existing equipment with its own imperfections and design >problems. >I have copied Jean-Luc in his function of ESA representative when Prox-1 was >developed and not as SLS area director. I am sure that he would also support >my and your views. > >It looks like we will have an interesting discussion in Athens. Given that >not too many people are registered so far for the RFM/RNG meeting, we may be >able to replan the meetings and devote more time to this issue. > >Best Regards, Enrico > > > > > > > Donald P > Olsen > > Enrico.Vassallo at esa.int > rg> cc: Greg J Kazz > , Gian.Paolo.Calzolari at esa.int, > Sent > by: Jean-Luc.Gerner at esa.int, > sls-rfm at mailman.ccsds.org, sls-rfm-bounces at mailman.ccsds.org > sls-rfm-bounces at mailma Subject: Re: > [Sls-rfm] Re: [CESG] URGENT: review of Prox-1 pink sheets > n.ccsds.org > > > > > > 10/03/2005 > 21:22 > > > > > > > > > >Greetings to all: > >It seem like +/- 10 % is an awful lot!!!! It would therefore seem reasonable >to do a spectrum analysis and see if there are any spectrum problems with >transmission of such a wobbling signal, particularly if due to the small >number of samples per symbol, >the wobble had a periodic component and hence would generate a descret >modulation spur or if the wobble would create a significant degradation in >Eb/No. > I recommend that rather than totally sacrificing the precision of the >existing recommendation, that we chose an amount that is sufficiently small >to limit the spurs to an appropriate spectral mask and let electral request a >waver since their >hardware is cast in concrete. > >Don Olsen > > > > > Enrico.Vassallo at esa.int > > Sent by: sls-rfm-bounces at mailman.ccsds.org > >To >sls-rfm at mailman.ccsds.org > > 02/17/2005 01:00 AM >cc >Greg J Kazz , Gian.Paolo.Calzolari at esa.int, >Jean-Luc.Gerner at esa.int >Subject >[Sls-rfm] Re: [CESG] URGENT: review of Prox-1 pink sheets > > > > > > > > > > > >Dear RF and Modulation experts, > >could you take a look at the attached pink sheets and send any comments/RIDs >to our WG with copy to Gregg by March 17? The goal would be to try and >resolve any issues before the meeting takes place! > >As you can imagine, we are very pressed for time at the Athens meeting. > >Thanks in advance for your cooperation, Enrico >----- Forwarded by Enrico Vassallo/esoc/ESA on 17/02/2005 09:56 ----- >|---------+---------------------------> >| | Greg Kazz | >| | | | .nasa.gov> | >| | | >| | 16/02/2005 18:19| >| | | >|---------+---------------------------> > > >------------------------------------------------------------------------- > ------------------------------------------------------| > > | >| > | To: Enrico.Vassallo at esa.int >| > | cc: Gian.Paolo.Calzolari at esa.int, Jean-Luc.Gerner at esa.int >| > | Subject: Re: [CESG] URGENT: your need for meeting rooms, Spring >2004 | > > >------------------------------------------------------------------------- > ------------------------------------------------------| > > > > > >Hi Enrico, > >I've attached the pink sheets to the Prox-1 Physical layer which was >approved for agency review (they went out to the CCSDS secretariat for >posting on the web site as well last week). > >If everyone in the joint WGs (RFM and SLS-SLP) has a chance before the >Spring meetings to take a good look at these pink sheets, and we review any >comments by email before the meeting, then I think we should be able to >resolve the issue in the one hour time frame you are suggesting. Tenatively >Wed. April 13 from 11 - 12 > > I recommend that you email these pink sheets to your WG and ask them to >comment so that we can stream line the process ahead of the Spring meetings >and cc: Greg Kazz to their messages as well so that I can track the progress. > >Note that the paragraph in RED italics was added as a result of the Prox-1 >Build-2 WG meeting held in Toulouse in November 2004 and will most likely >be the point of any controversy. > >Thanks. > >best regards, > >Greg > >At 12:35 AM 2/16/2005, Enrico.Vassallo at esa.int wrote: > > >Greg, > > > >I had planned to held the RFM meeting on April 12-13 and the RNG meeting on > >April 14. The SLS plenary meeting will be held on April 15. > > > >There is a need for a joint RFM/CC meeting that is tentatively expected to > >require a full afternoon. Gian Paolo and myself agreed to hold it on April > >13. > > > >For the data rate stability issue, I believe that one hour should suffice. > >Given the packed schedule for such April meetings, I would be inclined to > >propose that we squeeze such one-hour meeting before the joint RFM/CC on > >April 13 afternoon. > > > >Would such preliminary planning be commensurate with your needs? > > > >Depending on the input papers we plan to receive (as customary I will call > >for papers to be delivered one week prior to meeting start - papers coming > >later will go to the next meeting), we could re-assess the situation and > >possibly do a little adjustment to the schedule with one week's notice. > > > >Please let us have your views on this, Enrico > > > > > > > > > >|---------+---------------------------> > >| | Greg Kazz | > >| | >| | .nasa.gov> | > >| | | > >| | 08/02/2005 18:57| > >| | | > >|---------+---------------------------> > > > > > >------------------------------------------------------------------------- > ------------------------------------------------------| > > > > | > > | > > | To: Jean-Luc.Gerner at esa.int > > | > > | cc: Enrico.Vassallo at esa.int, > > Gian.Paolo.Calzolari at esa.int > > | > > | Subject: Re: [CESG] URGENT: your need for meeting rooms, > > Spring 2004 | > > > > > >------------------------------------------------------------------------- > ------------------------------------------------------| > > > > > > > > > > > >Jean-Luc, > > > >My appologies for not responding to you sooner. > > > >I foresee the following meetings for these WGs: > > > >1) One full day for SLS-SLP > > > >2) Two hour joint meeting with RF&MOD to resolve the data rate stability > >requirements within the Prox-1 Physical layer document. - We have not yet > >had the opportunity to address this issue face to face with RF&MOD. This > >falls under the Prox-1 Build-2 WG tasks, and is the only action remaining > >for that WG. > > > >Jean-Luc: Where pink sheets ever delivered to you by the CCSDS secretariat > >regarding the change pages proposed in Toulouse regarding the Prox-1 > >Physical layer? > > > >3) 1/2 day for SLS Link Layer WG to review the final Prox-1 GB > > > >I don't foresee a joint CC & SLS-SLP WG meeting at this time. > > > >best regards, > > > >Greg >(See attached file: prox1_datarate_rqmts_pinksheets.doc) > >(See attached file: >prox1_datarate_rqmts_pinksheets.doc)_______________________________________________ > >Sls-rfm mailing list >Sls-rfm at mailman.ccsds.org >http://mailman.ccsds.org/mailman/listinfo/sls-rfm >_____________________________ >Sls-rfm mailing list >Sls-rfm at mailman.ccsds.org >http://mailman.ccsds.org/mailman/listinfo/sls-rfm From greg.j.kazz at jpl.nasa.gov Fri Mar 18 19:24:38 2005 From: greg.j.kazz at jpl.nasa.gov (Greg Kazz) Date: Fri, 18 Mar 2005 11:24:38 -0800 Subject: [Sls-slp] CCSDS SLS-SLP, Prox-1-Build-2 Meeting Schedules and more Message-ID: <6.2.0.14.2.20050318111734.02b575b8@mail.jpl.nasa.gov> Dear WG members, Attached is the Space Link Service Area Schedule for the CCSDS Spring 2005 meeting in Athens. To my knowledge, this schedule is the most up to date version. Note that there is a Joint SLS-security WG meeting planned for Monday, April 11 from 10:30 to 12 (see the far right column of the table attached). Please let me know if you have any question. I am looking forward to seeing you in Athens. Best regards, Greg Kazz Chairman SLS-SLP and Prox-1-Build2 WGs -------------- next part -------------- A non-text attachment was scrubbed... Name: CCSDS SLS Agenda Spring05 Iss5.doc Type: application/msword Size: 48128 bytes Desc: not available URL: From greg.j.kazz at jpl.nasa.gov Fri Mar 18 23:44:35 2005 From: greg.j.kazz at jpl.nasa.gov (Greg Kazz) Date: Fri, 18 Mar 2005 15:44:35 -0800 Subject: [Sls-slp] Prox-1 Data Link Layer Pink Sheets Message-ID: <6.2.0.14.2.20050318153941.028530b8@mail.jpl.nasa.gov> All, There are two changes proposed in these pink sheets to Prox-1 Data Link Layer: 1) Change the name of PLCW_Repeat parameter to PLCW_Repeat_Interval 2) Add Notification #11 to Annex E (Notification to Vehicle Controller) This case was discovered in system test at LMA on MRO with Electra We added an action in full and half duplex state tables in case the response to the hail was carrier only. Pink sheets attached. Please let me know if you have any questions/comments regarding these proposed changes by March 31. best regards, Greg Kazz Chairman Prox-1-Build-2 WG -------------- next part -------------- A non-text attachment was scrubbed... Name: Prox1_datalink_pink.pdf Type: application/pdf Size: 240127 bytes Desc: not available URL: From greg.j.kazz at jpl.nasa.gov Tue Mar 22 05:00:46 2005 From: greg.j.kazz at jpl.nasa.gov (Greg Kazz) Date: Mon, 21 Mar 2005 21:00:46 -0800 Subject: [Sls-slp] Table form of Prox-1 Phy Layer Data Rate Requirements Message-ID: <6.2.0.14.2.20050321205622.029a56a8@mail.jpl.nasa.gov> All, Attached is a file containing the Prox-1 Physical Layer Pink Sheets - Data Rate Requirements in Tabular Form from Dennis Lee. These pink sheets contain the same information as the previous set, however reformated into a table so that it's easier to understand. These are the pink sheets that I plan to discuss at our joint meeting with RF&MOD in Athens. Please let me know if you have any questions or concerns and cc: Dennis Lee best regards, Greg Kazz Chairman Prox-1 Build-2 WG -------------- next part -------------- A non-text attachment was scrubbed... Name: prox1_datarate_rqmts_pinksheets 3-21-05 DL.doc Type: application/msword Size: 51712 bytes Desc: not available URL: From greg.j.kazz at jpl.nasa.gov Thu Mar 24 13:16:30 2005 From: greg.j.kazz at jpl.nasa.gov (Greg Kazz) Date: Thu, 24 Mar 2005 05:16:30 -0800 Subject: Fwd: Re: [Sls-rfm] [Sls-slp] Table form of Prox-1 Phy Layer Data Rate Requirements and comments from NASA GSFC Message-ID: <6.2.0.14.2.20050324051016.028dae28@mail.jpl.nasa.gov> To: Prox-1 Build-2 WG members and Electra Project, Victor Sank's (NASA GSFC) comments to the Prox-1 Physical Layer Pink Sheets follows. Greg >Date: Thu, 24 Mar 2005 08:44:47 +0100 >From: Enrico.Vassallo at esa.int >Subject: Re: [Sls-rfm] [Sls-slp] Table form of Prox-1 Phy Layer Data Rate > Requirements >To: "Victor J. Sank" >Cc: Greg J Kazz , Dennis.K.Lee at jpl.nasa.gov, > Wai Fong >X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 >X-MIMETrack: Serialize by Router on esocmta1/esoc/ESA(Release 5.0.13a |April > 8, 2004) at 03/24/2005 08:44:49 AM >X-Source-IP: esacom59-ext.esoc.esa.int [131.176.86.4] >X-Source-Sender: Enrico.Vassallo at esa.int >X-JPL-spam-score: 0.00% > > >Victor, > >so far we have received your comments and Don's comments, which I endorsed >from the ESA point of view. None were submitted in RID forms but I don't >believe we need to be so formal. >I will forward your e-mail to the RFM WG and I believe that Greg will do the >same with his WG. We will discuss all inputs at the joint meeting. > >Regards, Enrico > > > >|---------+---------------------------> >| | "Victor J. Sank"| >| | | | c.nasa.gov> | >| | | >| | 23/03/2005 23:07| >| | | >|---------+---------------------------> > > >-------------------------------------------------------------------------------------------------------------------------------| > | > | > | To: Greg J Kazz , > Dennis.K.Lee at jpl.nasa.gov | > | cc: Enrico.Vassallo at esa.int, > wai.fong at gsfc.nasa.gov > | > | Subject: Re: [Sls-rfm] [Sls-slp] Table form of Prox-1 Phy > Layer Data Rate Requirements | > > >-------------------------------------------------------------------------------------------------------------------------------| > > > > >Greg, Dennis, >Administrative: > Please be carful to put a proper date in the document header where it >says DATE: >Your document has an Automatic date which is no good, it shows current data >every time someone opens the document instead of the actual intended creation >date. > >Technical: > prox1_datarage_rqmts_pinksheets 3-21-05 DL.doc states >"Because its symbol clock is derived by dividing down the USO frequency which >in most cases is not an exact multiple of the Prox-1 specified data rates, >Electra dithers the number of samples per symbol to insure that the average >symbol rate is equal to the value in the specification in order to achieve an >average symbol rate matching the Prox-1 specification. This can cause a >fairly large deviation in symbol period from one symbol to another (up to 7% >[1]), in particular when there are relatively few samples per symbol at the >high symbol rates." > Suggest you change the point of view in the Prox 1 specification. >Use the oscillator as the defining item for the data rate and accept that it >will not be exactly 1 Kbps or whatever the goal is. For example, for ST5 we >have a 9.625 MHz oscillator that is used to define the data rates. The rates >are Rj = 9.625 MHz/n, where n is an integer. Our 100 Kbps data rate is >actually 100.26 Kbps, 200 Kbps is actually 200.52 Kbps and 1 Kbps is actually >1.0001 Kbps. % jitter 0.26% worst case in these examples. In our case, the >bit synch on the receive side can easily track the actual data rate even when >set to the approximate value. I assume, but do not know for sure, that in >the case of Prox1 equipment, the situation is similar. By doing things this >way, the jitter is very low which is important to the spectrum purity, >receiver and receiving bit synch. The trade off is low jitter but maybe some >tracking loop stress. We have not had acquisition problems even when setting >the approximate data rate. > I am suggesting that the receiving bit synch can handle the loop >stress better than the jitter. > >Enrico, > I do not want to put this in an official RID unless you think it >should be. > >Victor > > > >Thanks, >Victor > > >At 09:17 AM 3/22/2005 +0100, Enrico.Vassallo at esa.int wrote: > For consideration at the joint meeting in Athens. > > Regards, Enrico > > ----- Forwarded by Enrico Vassallo/esoc/ESA on 22/03/2005 09:17 ----- > |---------+---------------------------------> > | | Greg Kazz | > | | | | gov> | > | | Sent by: | > | | sls-slp-bounces at mailma| > | | n.ccsds.org | > | | | > | | | > | | 22/03/2005 06:00 | > | | | > |---------+---------------------------------> > > > >-------------------------------------------------------------------------------------------------------------------------------| > > | > | > | To: sls-slp at mailman.ccsds.org > | > | cc: > | > | Subject: [Sls-slp] Table form of Prox-1 Phy Layer Data Rate > Requirements | > > > >-------------------------------------------------------------------------------------------------------------------------------| > > > > > > All, > > Attached is a file containing the Prox-1 Physical Layer Pink Sheets - > Data > Rate Requirements in Tabular Form from Dennis Lee. These pink sheets > contain the same information as the previous set, however reformated > into a > table so that it's easier to understand. These are the pink sheets that > I > plan to discuss at our joint meeting with RF&MOD in Athens. > > Please let me know if you have any questions or concerns and cc: Dennis > Lee > > best regards, > > Greg Kazz > Chairman Prox-1 Build-2 WG(See attached file: > prox1_datarate_rqmts_pinksheets > 3-21-05 DL.doc)_______________________________________________ > Sls-slp mailing list > Sls-slp at mailman.ccsds.org > http://mailman.ccsds.org/mailman/listinfo/sls-slp > > > > _______________________________________________ > Sls-rfm mailing list > Sls-rfm at mailman.ccsds.org > http://mailman.ccsds.org/mailman/listinfo/sls-rfm > > >Victor J. Sank Code 567 / MEI >NASA Goddard Space Flight Center >Code 567, Building 19, Room S044 >Greenbelt, MD 20771 >Email: Victor.Sank at gsfc.nasa.gov >Phone: 301 286 2645 >pager: 301 207 1863 >Cell: 240 353 8056 >Fax: 301 286 1750 From MCosby at space.qinetiq.com Thu Mar 24 16:25:53 2005 From: MCosby at space.qinetiq.com (Matthew Cosby) Date: Thu, 24 Mar 2005 16:25:53 +0000 Subject: [Sls-rfm] [Sls-slp] Table form of Prox-1 Phy Layer Message-ID: <5.2.1.1.0.20050324162200.052c0290@ntexch02s> Greg, here are the BNSC responses to the new pink sheets... See you in Athens. Matt. We would like to voice our concerns regarding this new pink sheets for the data rate stability for Proximity-1. These concerns have been developed in consultation with engineers at QinetiQ (Steve Kynaston, Dai Stanton and myself) who have been responsible for several baseband and RF CCSDS systems, including 2 implementations of Proximity 1. We can't accept a change to a recommendation just because a single implementation cannot meet the current specification. The reason why Electra could not meet this requirement is due to a design decision not because the specification is too stringent. Making this type of change has serious knock-on interoperability issues. The correct cause of action would be for the Electra implementers to issue a waiver, to their customers, indicating that they don't meet the current Proximity-1 specification. We should not accommodate in the recommendation a symbol-to-symbol timing deviation that could lead to, at best, large implementation losses in the bit synchroniser and, at worst, a total inability of a bit synchroniser to track the incoming data. We believe that the modifications made to the recommendation at the Autumn 2004 meeting have severely compromised interoperability between orbiters and landers (both extant and planned) by not specifying a symbol-to-symbol frequency deviation. The current form of words and, to a greater extent, the statements in the pink sheets allow for pathologically behaved baseband implementations which would be impossible to decode. (E.g. a waveform which had a symbol 99 bit periods long followed by 99 symbols squeezed into a single period). We do not believe that it is prudent to issue a recommendation which does not provide enough rigor to guarantee orbiter/lander interoperability at the bit synchronisation level. ------------------------------------------------ Matthew Cosby Digital & Embedded Technology, Space Department, Arthur C Clarke Building, QinetiQ Ltd, Cody Technology Park, Farnborough, Hants, UK. GU14 0LX. Tel: +44 (0)1252 396313 Pager: +44 (0)7659 130547 ------------------------------------------------ e-mail : MCosby at space.QinetiQ.com WWW : http://www.QinetiQ.com ------------------------------------------------------------------ The views expressed above are entirely those of the writer and do not represent the views, policy or understanding of any other person or official body. ------------------------------------------------------------------ ############################################################# The information contained in this email and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the intended recipient(s) any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. ############################################################# From thomas.c.jedrey at jpl.nasa.gov Thu Mar 24 18:27:53 2005 From: thomas.c.jedrey at jpl.nasa.gov (Thomas Jedrey) Date: Thu, 24 Mar 2005 10:27:53 -0800 Subject: [Sls-rfm] [Sls-slp] Table form of Prox-1 Phy Layer In-Reply-To: <5.2.1.1.0.20050324162200.052c0290@ntexch02s> Message-ID: <200503241827.j2OIRrId007731@xmta3.jpl.nasa.gov> Matthew, A symbol to symbol to symbol variation was included. Your comments on the decision to use a non-integer divisor are correct in that it was a program decision to use this. Unfortunately this is not a negotiable point since this form of the radio will be providing network support at Mars for the next 20 years or so. So any design expecting support from the NASA Mars network assets will have to be compatible with these specifications - regardless of whether they are included in the prox-1 specification or not. Thomas C. Jedrey Supervisor, Wireless Communications Group Jet Propulsion Laboratory Phone: 818-354-5187 Fax: 818-354-6825 -----Original Message----- From: Matthew Cosby [mailto:MCosby at space.qinetiq.com] Sent: Thursday, March 24, 2005 8:26 AM To: sls-slp at mailman.ccsds.org Cc: David.J.Bell at jpl.nasa.gov; Eric.Schwartzbaum at jpl.nasa.gov; Thomas.C.Jedrey at jpl.nasa.gov; Dennis Lee; Charles.D.Edwards at jpl.nasa.gov; SJKynaston at space.qinetiq.com; adstanton at keltik.co.uk; adstanton at space.qinetiq.com Subject: [Sls-rfm] [Sls-slp] Table form of Prox-1 Phy Layer Greg, here are the BNSC responses to the new pink sheets... See you in Athens. Matt. We would like to voice our concerns regarding this new pink sheets for the data rate stability for Proximity-1. These concerns have been developed in consultation with engineers at QinetiQ (Steve Kynaston, Dai Stanton and myself) who have been responsible for several baseband and RF CCSDS systems, including 2 implementations of Proximity 1. We can't accept a change to a recommendation just because a single implementation cannot meet the current specification. The reason why Electra could not meet this requirement is due to a design decision not because the specification is too stringent. Making this type of change has serious knock-on interoperability issues. The correct cause of action would be for the Electra implementers to issue a waiver, to their customers, indicating that they don't meet the current Proximity-1 specification. We should not accommodate in the recommendation a symbol-to-symbol timing deviation that could lead to, at best, large implementation losses in the bit synchroniser and, at worst, a total inability of a bit synchroniser to track the incoming data. We believe that the modifications made to the recommendation at the Autumn 2004 meeting have severely compromised interoperability between orbiters and landers (both extant and planned) by not specifying a symbol-to-symbol frequency deviation. The current form of words and, to a greater extent, the statements in the pink sheets allow for pathologically behaved baseband implementations which would be impossible to decode. (E.g. a waveform which had a symbol 99 bit periods long followed by 99 symbols squeezed into a single period). We do not believe that it is prudent to issue a recommendation which does not provide enough rigor to guarantee orbiter/lander interoperability at the bit synchronisation level. ------------------------------------------------ Matthew Cosby Digital & Embedded Technology, Space Department, Arthur C Clarke Building, QinetiQ Ltd, Cody Technology Park, Farnborough, Hants, UK. GU14 0LX. Tel: +44 (0)1252 396313 Pager: +44 (0)7659 130547 ------------------------------------------------ e-mail : MCosby at space.QinetiQ.com WWW : http://www.QinetiQ.com ------------------------------------------------------------------ The views expressed above are entirely those of the writer and do not represent the views, policy or understanding of any other person or official body. ------------------------------------------------------------------ ############################################################# The information contained in this email and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the intended recipient(s) any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. ############################################################# From greg.j.kazz at jpl.nasa.gov Thu Mar 24 19:01:53 2005 From: greg.j.kazz at jpl.nasa.gov (Greg Kazz) Date: Thu, 24 Mar 2005 11:01:53 -0800 Subject: [Sls-rfm] [Sls-slp] Table form of Prox-1 Phy Layer In-Reply-To: <5.2.1.1.0.20050324162200.052c0290@ntexch02s> References: <5.2.1.1.0.20050324162200.052c0290@ntexch02s> Message-ID: <6.2.0.14.2.20050324105110.02da7f10@mail.jpl.nasa.gov> Matt, Tom Gannett generated the pink sheets in CCSDS format and I sent them out. They contain the symbol to symbol addition you and Lester recommended at the Fall meeting. It includes the paragraph on the symbol to symbol deviation. After that Dennis Lee discovered that we could more precisely capture part of these requirements in a table. I sent that proposal out as well. I said that it was only a format change. I forgot to include the symbol to symbol deviation paragraph into Dennis's proposal. However, they are included in the official pink sheets. Greg >Greg, > >here are the BNSC responses to the new pink sheets... > >See you in Athens. > >Matt. > >We would like to voice our concerns regarding this new pink sheets for the >data rate stability for Proximity-1. These concerns have been developed in >consultation with engineers at QinetiQ (Steve Kynaston, Dai Stanton and >myself) who have been responsible for several baseband and RF CCSDS >systems, including 2 implementations of Proximity 1. > >We can't accept a change to a recommendation just because a single >implementation cannot meet the current specification. The reason why >Electra could not meet this requirement is due to a design decision not >because the specification is too stringent. Making this type of change has >serious knock-on interoperability issues. > >The correct cause of action would be for the Electra implementers to issue >a waiver, to their customers, indicating that they don't meet the current >Proximity-1 specification. We should not accommodate in the recommendation >a symbol-to-symbol timing deviation that could lead to, at best, large >implementation losses in the bit synchroniser and, at worst, a total >inability of a bit synchroniser to track the incoming data. > >We believe that the modifications made to the recommendation at the Autumn >2004 meeting have severely compromised interoperability between orbiters >and landers (both extant and planned) by not specifying a symbol-to-symbol >frequency deviation. The current form of words and, to a greater extent, >the statements in the pink sheets allow for pathologically behaved >baseband implementations which would be impossible to decode. (E.g. a >waveform which had a symbol 99 bit periods long followed by 99 symbols >squeezed into a single period). We do not believe that it is prudent to >issue a recommendation which does not provide enough rigor to guarantee >orbiter/lander interoperability at the bit synchronisation level. > > > >------------------------------------------------ >Matthew Cosby >Digital & Embedded Technology, >Space Department, >Arthur C Clarke Building, >QinetiQ Ltd, >Cody Technology Park, >Farnborough, >Hants, UK. >GU14 0LX. > >Tel: +44 (0)1252 396313 >Pager: +44 (0)7659 130547 >------------------------------------------------ >e-mail : MCosby at space.QinetiQ.com >WWW : http://www.QinetiQ.com >------------------------------------------------------------------ >The views expressed above are entirely those of the writer >and do not represent the views, policy or understanding of >any other person or official body. >------------------------------------------------------------------ > > >############################################################# > >The information contained in this email and any subsequent >correspondence is private and is intended solely for the intended >recipient(s). For those other than the intended >recipient(s) any disclosure, copying, distribution, or any action taken or >omitted to be taken in reliance on such information is prohibited and may >be unlawful. > >############################################################# > >_______________________________________________ >Sls-slp mailing list >Sls-slp at mailman.ccsds.org >http://mailman.ccsds.org/mailman/listinfo/sls-slp From egreenbe at jpl.nasa.gov Thu Mar 24 19:44:31 2005 From: egreenbe at jpl.nasa.gov (Ed Greenberg) Date: Thu, 24 Mar 2005 11:44:31 -0800 Subject: [Sls-rfm] [Sls-slp] Table form of Prox-1 Phy Layer In-Reply-To: <200503241827.j2OIRrId007731@xmta3.jpl.nasa.gov> References: <5.2.1.1.0.20050324162200.052c0290@ntexch02s> Message-ID: <5.2.0.9.2.20050324113705.01f61850@mail.jpl.nasa.gov> Gentlemen, We are all trying to get to a Standard that will provide service to all any agencies transceiver. I think that the problem may be related to the generalization of the specification. The real variations are related to the selected data rate and the non-integer divisor. Can we identify the symbol to symbol variance at the specific Prox-1 rates so that we can a) determine if these are workable or not, and if they are workable then we can try to define them in a manner that is rate specific so we can proceed. Ed At 10:27 AM 3/24/2005 -0800, Thomas Jedrey wrote: >Matthew, > >A symbol to symbol to symbol variation was included. > >Your comments on the decision to use a non-integer divisor are correct in >that it was a program decision to use this. Unfortunately this is not a >negotiable point since this form of the radio will be providing network >support at Mars for the next 20 years or so. So any design expecting >support from the NASA Mars network assets will have to be compatible with >these specifications - regardless of whether they are included in the prox-1 >specification or not. > >Thomas C. Jedrey >Supervisor, Wireless Communications Group >Jet Propulsion Laboratory >Phone: 818-354-5187 >Fax: 818-354-6825 > > >-----Original Message----- >From: Matthew Cosby [mailto:MCosby at space.qinetiq.com] >Sent: Thursday, March 24, 2005 8:26 AM >To: sls-slp at mailman.ccsds.org >Cc: David.J.Bell at jpl.nasa.gov; Eric.Schwartzbaum at jpl.nasa.gov; >Thomas.C.Jedrey at jpl.nasa.gov; Dennis Lee; Charles.D.Edwards at jpl.nasa.gov; >SJKynaston at space.qinetiq.com; adstanton at keltik.co.uk; >adstanton at space.qinetiq.com >Subject: [Sls-rfm] [Sls-slp] Table form of Prox-1 Phy Layer > >Greg, > >here are the BNSC responses to the new pink sheets... > >See you in Athens. > >Matt. > >We would like to voice our concerns regarding this new pink sheets for the >data rate stability for Proximity-1. These concerns have been developed in >consultation with engineers at QinetiQ (Steve Kynaston, Dai Stanton and >myself) who have been responsible for several baseband and RF CCSDS >systems, including 2 implementations of Proximity 1. > >We can't accept a change to a recommendation just because a single >implementation cannot meet the current specification. The reason why >Electra could not meet this requirement is due to a design decision not >because the specification is too stringent. Making this type of change has >serious knock-on interoperability issues. > >The correct cause of action would be for the Electra implementers to issue >a waiver, to their customers, indicating that they don't meet the current >Proximity-1 specification. We should not accommodate in the recommendation >a symbol-to-symbol timing deviation that could lead to, at best, large >implementation losses in the bit synchroniser and, at worst, a total >inability of a bit synchroniser to track the incoming data. > >We believe that the modifications made to the recommendation at the Autumn >2004 meeting have severely compromised interoperability between orbiters >and landers (both extant and planned) by not specifying a symbol-to-symbol >frequency deviation. The current form of words and, to a greater extent, >the statements in the pink sheets allow for pathologically behaved baseband >implementations which would be impossible to decode. (E.g. a waveform which >had a symbol 99 bit periods long followed by 99 symbols squeezed into a >single period). We do not believe that it is prudent to issue a >recommendation which does not provide enough rigor to guarantee >orbiter/lander interoperability at the bit synchronisation level. > > > >------------------------------------------------ >Matthew Cosby >Digital & Embedded Technology, >Space Department, >Arthur C Clarke Building, >QinetiQ Ltd, >Cody Technology Park, >Farnborough, >Hants, UK. >GU14 0LX. > >Tel: +44 (0)1252 396313 >Pager: +44 (0)7659 130547 >------------------------------------------------ >e-mail : MCosby at space.QinetiQ.com >WWW : http://www.QinetiQ.com >------------------------------------------------------------------ >The views expressed above are entirely those of the writer >and do not represent the views, policy or understanding of >any other person or official body. >------------------------------------------------------------------ > > >############################################################# > >The information contained in this email and any subsequent >correspondence is private and is intended solely for the >intended recipient(s). For those other than the intended >recipient(s) any disclosure, copying, distribution, or any >action taken or omitted to be taken in reliance on such >information is prohibited and may be unlawful. > >############################################################# > > >_______________________________________________ >Sls-slp mailing list >Sls-slp at mailman.ccsds.org >http://mailman.ccsds.org/mailman/listinfo/sls-slp Progress is impossible when you always do things the way they have always been done. From greg.j.kazz at jpl.nasa.gov Tue Mar 29 00:10:44 2005 From: greg.j.kazz at jpl.nasa.gov (Greg Kazz) Date: Mon, 28 Mar 2005 16:10:44 -0800 Subject: [Sls-slp] Review copy of Prox-1 GB Message-ID: <6.2.0.14.2.20050328160511.02d5f3b8@mail.jpl.nasa.gov> SLS-SLPers, Attached is the Prox-1 GB for review at the Spring 2005 meeting in Athens. I would like you to read through it and let me know if you have any comments on it, including any additional topics you think have merit that weren't covered. I plan to devote a day at the Spring meeting discussing the green book. In particular, we need to update the state diagram of the COP-P and the associated text to match the current blue book. best regards, Greg Kazz Chairman SLS-SLP WG -------------- next part -------------- A non-text attachment was scrubbed... Name: 211-G-0-DRAFT-03-28-05C.doc Type: application/msword Size: 1412096 bytes Desc: not available URL: From greg.j.kazz at jpl.nasa.gov Tue Mar 29 16:34:04 2005 From: greg.j.kazz at jpl.nasa.gov (Greg Kazz) Date: Tue, 29 Mar 2005 08:34:04 -0800 Subject: [Sls-slp] Alternative Proposed Prox-1 Physical Layer Pink Sheet Message-ID: <6.2.0.14.2.20050329083031.0289e740@mail.jpl.nasa.gov> All, Attached is a candidate pink sheet to the Prox-1 Physical layer Recommendation. It contains Dennis Lee's proposal. Greg -------------- next part -------------- A non-text attachment was scrubbed... Name: Prox1_phy_pink_dl.pdf Type: application/pdf Size: 153201 bytes Desc: not available URL: From greg.j.kazz at jpl.nasa.gov Tue Mar 29 18:18:09 2005 From: greg.j.kazz at jpl.nasa.gov (Greg Kazz) Date: Tue, 29 Mar 2005 10:18:09 -0800 Subject: [Sls-slp] Both alternatives attached Message-ID: <6.2.0.14.2.20050329101314.02b3af08@mail.jpl.nasa.gov> All, I've attached both candidate pink sheets to the Prox-1 Physical Layer specification concerning the data rate stability requirements to this email. The difference is the issue about symbol to symbol stability addressed in the 2nd attachment. We will discuss these sheets at the meeting in Athens during the joint RF&MOD/Prox-1 Build-2 meeting. best regards, Greg -------------- next part -------------- A non-text attachment was scrubbed... Name: Prox1_phy_pink_dl.pdf Type: application/pdf Size: 153201 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 211x1p21v2.pdf Type: application/pdf Size: 155067 bytes Desc: not available URL: From timothy.j.ray at nasa.gov Tue Mar 29 23:08:24 2005 From: timothy.j.ray at nasa.gov (Timothy Ray) Date: Tue, 29 Mar 2005 18:08:24 -0500 Subject: [Sls-slp] Review copy of Prox-1 GB References: <6.2.0.14.2.20050328160511.02d5f3b8@mail.jpl.nasa.gov> Message-ID: <01a901c534b4$35cde210$e194b780@gsfc.nasa.gov> I have a handwritten text version of state diagrams for FOP-P and FARM-P. My wrists and forearms hurt too much (carpal tunnel?) to type it in at this time. Tim ----- Original Message ----- From: "Greg Kazz" To: Sent: Monday, March 28, 2005 7:10 PM Subject: [Sls-slp] Review copy of Prox-1 GB > SLS-SLPers, > > Attached is the Prox-1 GB for review at the Spring 2005 meeting in Athens. > > I would like you to read through it and let me know if you have any > comments on it, including any additional topics you think have merit that > weren't covered. I plan to devote a day at the Spring meeting discussing > the green book. > > In particular, we need to update the state diagram of the COP-P and the > associated text to match the current blue book. > > best regards, > > Greg Kazz > Chairman SLS-SLP WG > ---------------------------------------------------------------------------- ---- > ---------------------------------------------------------------------------- ---- > _______________________________________________ > Sls-slp mailing list > Sls-slp at mailman.ccsds.org > http://mailman.ccsds.org/mailman/listinfo/sls-slp > From greg.j.kazz at jpl.nasa.gov Thu Mar 31 21:07:11 2005 From: greg.j.kazz at jpl.nasa.gov (Greg Kazz) Date: Thu, 31 Mar 2005 13:07:11 -0800 Subject: [Sls-slp] Fwd: [Cesg-all] CCSDS Social Event, Sunday 10 April Message-ID: <6.2.0.14.2.20050331130656.02bca3e8@mail.jpl.nasa.gov> >Date: Thu, 31 Mar 2005 12:46:32 -0800 >From: "Adrian J. Hooke" >Subject: [Cesg-all] CCSDS Social Event, Sunday 10 April >Sender: cesg-all-bounces at mailman.ccsds.org >X-Sender: ahooke at mail1.jpl.nasa.gov >To: CCSDS Engineering Steering Group - All , > CCSDS Management Council , > CCSDS Secretariat >Cc: >X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 >X-BeenThere: cesg-all at mailman.ccsds.org >X-Source-IP: 66-193-180-202.gen.twtelecom.net [66.193.180.202] >X-Source-Sender: cesg-all-bounces at mailman.ccsds.org >X-AUTH: Internal IP >X-JPL-spam-score: 0.00% >X-Mailman-Version: 2.1.4 >List-Post: >List-Subscribe: , > >List-Unsubscribe: , > >List-Archive: >List-Help: >List-Id: CCSDS Engineering Steering Group - All > >Folks: for those of you who will be in Athens by Sunday 10 April, we are >tentatively planning a social event - an all day Sunday cruise to the >islands of Porus, Hydra and Aegina. The cost to each person is 85 Euros >but if we get enough people then we may be able to negotiate a discount. >There are no guarantees about the arrangements - this opportunity came out >of a casual web search at http://www.fantasy.gr/english/index.html - but >so far the operators seem to be reputable and responsive. The schedule is: > >SUNDAY 10 APRIL: > >8.00 a.m. Transfer by motorcoach from Athens to Flisvos Marina and embark >on the cruise ship. >8.30 a.m. sail for the island of HYDRA . In Hydra you have free time for a >stroll, shopping or swimming. > In the early afternoon sail for the island of AEGINA , passing > through the narrow strait > separating the Peloponnesian coast from the island of POROS . > Lunch is served after sailing. > Short stop in Poros. Upon arrival in Aegina you can either join > the excursion to the > Temple of Aphaia (extra cost) or walk around the main town. > Finally, re-embark for > the trip back to Flisvos Marina. >7.15 p.m. Arrival at Flisvos Marina and transfer to Athens . > >Linda Kezer has graciously agreed to be the focal point for collecting the >names of people who are interested. Please let Linda know if you would >like to be included, plus any guests. Send your information to: > >Linda Kezer > >Please pass this invitation on to your working group and BOF participants. >It's been a long time since we have had a CCSDS social event, and this >could be a great way to start the technical week in a relaxed and friendly >setting. > >Best regards >Adrian > >Adrian J. Hooke >Chairman, CCSDS Engineering Steering Group (CESG) >_______________________________________________ >CESG-all mailing list >CESG-all at mailman.ccsds.org >http://mailman.ccsds.org/mailman/listinfo/cesg-all From Jean-Luc.Gerner at esa.int Thu Mar 31 16:51:51 2005 From: Jean-Luc.Gerner at esa.int (Jean-Luc.Gerner at esa.int) Date: Thu, 31 Mar 2005 18:51:51 +0200 Subject: [Sls-slp] Table form of Prox-1 Phy Layer Data Rate Requirements Message-ID: Greg, The change may look ok at first glance but I am puzzled with the rationale. To me, the process in the development of a blue book is, in order of priority: 1. what do future missions need? 2. can it be achieved with state-of-the-art hardware 3. practicalities of short-term missions; if hardware not compatible, is a waiver practicable. Last solution is to reassess the requirements in the BB and readjust them if possible. Your reasoning is bottom-up: the existing (maybe outdated) hardware cannot meet the requirement, so let's change the requirement. What if this approach hampers future programmes by forcing them to be contented with poor performances for compatibility with outdated hardware? I submit these thoughts for discussion in your WG. best regards Jean-Luc Gerner TEC-ETT Tel: +31 71 565 4473 Greg Kazz cc: Sent by: Subject: [Sls-slp] Table form of Prox-1 Phy Layer Data Rate Requirements sls-slp-bounces at mailma n.ccsds.org 22/03/2005 06:00 All, Attached is a file containing the Prox-1 Physical Layer Pink Sheets - Data Rate Requirements in Tabular Form from Dennis Lee. These pink sheets contain the same information as the previous set, however reformated into a table so that it's easier to understand. These are the pink sheets that I plan to discuss at our joint meeting with RF&MOD in Athens. Please let me know if you have any questions or concerns and cc: Dennis Lee best regards, Greg Kazz Chairman Prox-1 Build-2 WG(See attached file: prox1_datarate_rqmts_pinksheets 3-21-05 DL.doc)_______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/mailman/listinfo/sls-slp -------------- next part -------------- A non-text attachment was scrubbed... Name: prox1_datarate_rqmts_pinksheets 3-21-05 DL.doc Type: application/msword Size: 51712 bytes Desc: not available URL: From Jean-Luc.Gerner at esa.int Thu Mar 31 18:26:58 2005 From: Jean-Luc.Gerner at esa.int (Jean-Luc.Gerner at esa.int) Date: Thu, 31 Mar 2005 20:26:58 +0200 Subject: [Sls-rfm] [Sls-slp] Table form of Prox-1 Phy Layer Message-ID: Ed, I like your wise words. I would add that what we are building is for the coming 20 years; we must make sure that we make optimal use of the system potentialities. If we were to introduce lousy requirements, no doubts that CCSDS would loose part of its credibility. We can't take such a risk. This 400 MHz system is already rather capacity-limited; hence we MUST make the best out of it. best regards Jean-Luc Gerner TEC-ETT Tel: +31 71 565 4473 Ed Greenberg , sls-slp at mailman.ccsds.org Sent by: cc: adstanton at keltik.co.uk, adstanton at space.qinetiq.com, sls-slp-bounces at mailma SJKynaston at space.qinetiq.com, "'Dennis Lee'" , n.ccsds.org Charles.D.Edwards at jpl.nasa.gov, Eric.Schwartzbaum at jpl.nasa.gov, David.J.Bell at jpl.nasa.gov Subject: RE: [Sls-rfm] [Sls-slp] Table form of Prox-1 Phy Layer 24/03/2005 20:44 Gentlemen, We are all trying to get to a Standard that will provide service to all any agencies transceiver. I think that the problem may be related to the generalization of the specification. The real variations are related to the selected data rate and the non-integer divisor. Can we identify the symbol to symbol variance at the specific Prox-1 rates so that we can a) determine if these are workable or not, and if they are workable then we can try to define them in a manner that is rate specific so we can proceed. Ed At 10:27 AM 3/24/2005 -0800, Thomas Jedrey wrote: >Matthew, > >A symbol to symbol to symbol variation was included. > >Your comments on the decision to use a non-integer divisor are correct in >that it was a program decision to use this. Unfortunately this is not a >negotiable point since this form of the radio will be providing network >support at Mars for the next 20 years or so. So any design expecting >support from the NASA Mars network assets will have to be compatible with >these specifications - regardless of whether they are included in the prox-1 >specification or not. > >Thomas C. Jedrey >Supervisor, Wireless Communications Group >Jet Propulsion Laboratory >Phone: 818-354-5187 >Fax: 818-354-6825 > > >-----Original Message----- >From: Matthew Cosby [mailto:MCosby at space.qinetiq.com] >Sent: Thursday, March 24, 2005 8:26 AM >To: sls-slp at mailman.ccsds.org >Cc: David.J.Bell at jpl.nasa.gov; Eric.Schwartzbaum at jpl.nasa.gov; >Thomas.C.Jedrey at jpl.nasa.gov; Dennis Lee; Charles.D.Edwards at jpl.nasa.gov; >SJKynaston at space.qinetiq.com; adstanton at keltik.co.uk; >adstanton at space.qinetiq.com >Subject: [Sls-rfm] [Sls-slp] Table form of Prox-1 Phy Layer > >Greg, > >here are the BNSC responses to the new pink sheets... > >See you in Athens. > >Matt. > >We would like to voice our concerns regarding this new pink sheets for the >data rate stability for Proximity-1. These concerns have been developed in >consultation with engineers at QinetiQ (Steve Kynaston, Dai Stanton and >myself) who have been responsible for several baseband and RF CCSDS >systems, including 2 implementations of Proximity 1. > >We can't accept a change to a recommendation just because a single >implementation cannot meet the current specification. The reason why >Electra could not meet this requirement is due to a design decision not >because the specification is too stringent. Making this type of change has >serious knock-on interoperability issues. > >The correct cause of action would be for the Electra implementers to issue >a waiver, to their customers, indicating that they don't meet the current >Proximity-1 specification. We should not accommodate in the recommendation >a symbol-to-symbol timing deviation that could lead to, at best, large >implementation losses in the bit synchroniser and, at worst, a total >inability of a bit synchroniser to track the incoming data. > >We believe that the modifications made to the recommendation at the Autumn >2004 meeting have severely compromised interoperability between orbiters >and landers (both extant and planned) by not specifying a symbol-to-symbol >frequency deviation. The current form of words and, to a greater extent, >the statements in the pink sheets allow for pathologically behaved baseband >implementations which would be impossible to decode. (E.g. a waveform which >had a symbol 99 bit periods long followed by 99 symbols squeezed into a >single period). We do not believe that it is prudent to issue a >recommendation which does not provide enough rigor to guarantee >orbiter/lander interoperability at the bit synchronisation level. > > > >------------------------------------------------ >Matthew Cosby >Digital & Embedded Technology, >Space Department, >Arthur C Clarke Building, >QinetiQ Ltd, >Cody Technology Park, >Farnborough, >Hants, UK. >GU14 0LX. > >Tel: +44 (0)1252 396313 >Pager: +44 (0)7659 130547 >------------------------------------------------ >e-mail : MCosby at space.QinetiQ.com >WWW : http://www.QinetiQ.com >------------------------------------------------------------------ >The views expressed above are entirely those of the writer >and do not represent the views, policy or understanding of >any other person or official body. >------------------------------------------------------------------ > > >############################################################# > >The information contained in this email and any subsequent >correspondence is private and is intended solely for the >intended recipient(s). For those other than the intended >recipient(s) any disclosure, copying, distribution, or any >action taken or omitted to be taken in reliance on such >information is prohibited and may be unlawful. > >############################################################# > > >_______________________________________________ >Sls-slp mailing list >Sls-slp at mailman.ccsds.org >http://mailman.ccsds.org/mailman/listinfo/sls-slp Progress is impossible when you always do things the way they have always been done. _______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/mailman/listinfo/sls-slp