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".

jens 07:18, 17 June 2011 (UTC) Dome some more investigations. Retired "Class of emission" which is not longer needed aboard.
It is very tempting to introduce TIMREF rather then TIMZON. As far as I know all information are been given in a specific time reference of the transmitting station. So, if we have an area in a timezone different of the station's timezone the transmission times will be provided according to the station time. We do have a association between the radio service area and the radio station. So one can compute the differences between both if needed. What we need is to say whether the transmission or the working hours are at UTC or LT.