Talk:RDOSVC
jens 15:11, 15 November 2008 (CET) Please can you check the work done?
DavidAcland 17:05, 24 November 2008 (CET)
In trying to follow the pattern of pltsrv and mrnsrv, I notice that we have not called either of these ... Area. We have just defined the service. I quite like the form "... place where a ... service can be obtained" and perhaps there is a case to reflect this back into pltsrv and mrnsrv.
DavidAcland 10:59, 2 December 2008 (CET)
Having thought a bit more about this, I now find my earlier thoughts were wrong. This Object does define the area and so I have made this clear in the Alternative definition. If you are happy with this please can you put this definition in place of the original.
I think that frqprs is also now finished
DavidAcland 22:41, 5 February 2009 (CET) Many attributes changed to remove Attribute type:A which is denigrated in S-100. Many changed to complex; some simplified to integer; frqprs changed to frqpar. Multiple pairs can be created by repeating FRQPAR. facssp changed to FAXSSP which is more intuitive.
jens 21:49, 12 February 2009 (CET)
most agreed.
faxssp DRMSPD, indcop; see discussion there
FRQTXM and FRQRXV were difficult to understand due to 00.0 resolution but I got it why they become integer; clever solved :-) .
obstim and timtrm is to be discussed again because ISO construction used for TIMSTA, TIMEND can be used instead
DavidAcland 15:42, 13 February 2009 (CET)
Thanks for these points. Now all covered.
jens 09:28, 4 May 2011 (UTC) We need to have a language information attribute. NAVTEX e.g. can be transmitted in English or national language. Shall I add LNGINF to the attributes? I will add it as a place holder now.
jens 11:29, 4 May 2011 (UTC) Additionally, we need attributes for transmission power and for a particular time frame like between 0600-1800 whatever time. Is it a good idea to engage WKHRDY for the latter issue?
raphael 19:23, 4 May 2011 (UTC): Language - must it be free-form (LNGINF) or can it be one of the ISO list (ie., use LANGGE instead)?
Times: WKHRDY should be all right unless there are differences between different times.
DavidAcland 10:42, 13 May 2011 (UTC)
We would need to differentiate when to use this approach instead of TIMTRM.
Looking again at TIMREF, I see we have 1= UTM, 2=LT. I wonder if this is sufficient. It begs the question "What is the local time zone?".
I think we should add a third attribute CATTZN which we have started developing for the TIMZON feature. We could then express the transmission time 0600-1800 in UTM, Local time or in a specified zone time.
jens 17:04, 13 May 2011 (UTC) TIMTRM is not necessarily identical with WKHRDY.
I support the idea of introducing TIMZON too.
I will continue modelling the radio station information next week. In thought having considered all when introduced the radio stuff in Brest years ago. Today I afraid that I have some open issues to solve before being able to say "It is good".