DRM Software Radio Forums  

Go Back   DRM Software Radio Forums > DRM Software Radio - User Forums > General Topics
User Name
Password
FAQ Members List Calendar Search Today's Posts Mark Forums Read

Reply
 
Thread Tools Search this Thread Display Modes
Old 07-08-2017, 00:28   #1
PhilipOneL
Registered User
 
Join Date: Oct 2014
Location: Eastern Newfoundland
Posts: 134
Some stations reset receivers' time; but some don't

Having two MorphyRichards 27024 sets, I am frequently concerned about setting time. Both my sets lose their time & date when the mains power is removed (by being unplugged, for instance). I used to spend the half-hour of mindlessly turning the button to get the right time and date, but then I discovered some DRM stations automatically update time on my set. (We have no local FM or digital stations that do this.)

Despite the sometime strength of their signals, neither RRI nor Kuwait, reset my time. Voice of Nigeria resets it sometimes (not always, and not always correctly). And the overnight signal from the BBC on 3955 kHz also resets the time and date, always perfectly.

I keep wondering why some stations incorporate this useful service, and others do not. Is it very wasteful of bandwidth? Costly to programme?
PhilipOneL is offline   Reply With Quote
Old 10-08-2017, 09:34   #2
Digger
Registered User
 
Digger's Avatar
 
Join Date: Mar 2005
Location: Near Stockholm, Sweden
Posts: 9,464
Probably it is just a matter of doing it or not! I'm not an expert, please correct me if I'm wrong.

It is described in the ETSI ES 201 980 (part of it):

6.4.3.9 Time and date information data entity - type 8
The current time and date can be specified to allow a receiver to follow frequency schedules, etc. This data entity uses
the unique mechanism for the version flag. The data entity is coded as follows:
Modified Julian Date 17 bits.
UTC (hours and minutes) 11 bits.
and optionally:
rfu 2 bits.
Local Time Offset sense 1 bit.
Local Time Offset value 5 bits.
The following definitions apply:
Modified Julian Date: this field indicates the date in MJD format.
UTC: this field specifies the current UTC time expressed in hours (5 bits) and minutes (6 bits).
rfu: this 2-bit field is reserved for future use of the Local Time Offset sense and Local Time Offset value fields and
shall be set to zero until defined.
__________________
Regards,
Terje

http://www.hobbyradio.se/en/drm/webp....index_en.html
Digger is offline   Reply With Quote
Old 11-08-2017, 09:47   #3
hcliu
Registered User
 
hcliu's Avatar
 
Join Date: Aug 2012
Location: Chengdu, China
Posts: 13
From my personal view, I won't let the receiver to adjust the time even if the DRM signal carries this information, because shortwave broadcasting are usually inter-continental and may cross one or more time zones, the time offset can be wrong if it was not carefully considered at the transmitting side. This is different from FM RDS which is almost local.

And sometimes we can receive programs that are not intentionally targeted at us, so the carried time information and time offset may not make sense but just mess up the receiver's local time settings and consequently ring the alarm clock too early or too late. :-D
hcliu is offline   Reply With Quote
Old 11-08-2017, 11:12   #4
PhilipOneL
Registered User
 
Join Date: Oct 2014
Location: Eastern Newfoundland
Posts: 134
Ahh, Hcliu -- I see what you mean, but you clearly do not use a MorphyRichards27024. The change from a wrong time zone is a very small matter for me, compared to resetting the date and time, one click per day, from the 2006 default it resets to when mains power is lost.

.
PhilipOneL is offline   Reply With Quote
Old 14-08-2017, 09:32   #5
zfyoung
Registered User
 
Join Date: Aug 2006
Location: BaiSe, P.R. China @E10636′ N2355′
Posts: 208
I don't get the point here: The time code (sent via ether )only has valid meaning when it is associated with specific time zone (which should be an integral part of the time code info. embedded in DRM stream). The owner of the receiver only need to set its local time zone code once in user interface, and a properly designed DRM receiver should automatically adjust the local time clock by referring to both the over-the-air DRM reference clock and local time zone code.

Same for the emergency warning application: Say there is pending disaster in affected region A, B, C(which should have its unique region code), the Tx side should attach the list of region code with the warning message. On the Rx side, again,
the user of the receiver only need to set its local region code once and for all. When the Rx receive the warning message, it checks the warning message region code against the user set local region code. If the local region code is in the affected region list, it rings the alarm (or trigger other necessary behavior depend on receiver design) , otherwise just ignore it.

zfyoung
__________________
Any kind of audio drop-out is worse than any kind of low quality audio: No audio, No log report.

My Rx location: GuangXi Province @ E10636′ N2355′
zfyoung is offline   Reply With Quote
Old 26-08-2017, 16:42   #6
PhilipOneL
Registered User
 
Join Date: Oct 2014
Location: Eastern Newfoundland
Posts: 134
Zfyoung, as you said, you somehow missed the point of the discussion. The point is that only a few DRM stations actually send the code which resets time/date in my receivers. You are right about setting the time zone in the receiver (that information, unlike time/date, is preserved when mains power is lost in the MR27024).

Parenthetically, the V Nigeria time-setting code can be what seems to be a random number of minutes wrong.
PhilipOneL is offline   Reply With Quote
Old 27-08-2017, 08:27   #7
zfyoung
Registered User
 
Join Date: Aug 2006
Location: BaiSe, P.R. China @E10636′ N2355′
Posts: 208
Quote:
Originally Posted by PhilipOneL
the V Nigeria time-setting code can be what seems to be a random number of minutes wrong.

That says so much of the professional competence of their broadcast engineers. I can't imagine what would happen if when they 'randomly' set the emergency early warning messages (earthquake, tsunami, cyclone, flash-flood, bush-fire, nuclear-strike..... ). If they can NOT get it right after years of testing, then can they get it right in an emergency? I won't hold my breath....


zfyoung
__________________
Any kind of audio drop-out is worse than any kind of low quality audio: No audio, No log report.

My Rx location: GuangXi Province @ E10636′ N2355′

Last edited by zfyoung : 27-08-2017 at 09:34.
zfyoung is offline   Reply With Quote
Old 27-08-2017, 09:07   #8
Digger
Registered User
 
Digger's Avatar
 
Join Date: Mar 2005
Location: Near Stockholm, Sweden
Posts: 9,464
Setting parameters at the TX side

Another irritating thing is that BBC (on 3955 and 17790 kHz) and Babcock (on 9760 kHz) insist on using AFS when there are no alternative frequencies available! When the reception is unstable, the receiver stars looking for these non-existent frequencies and most of the time you'd have to re-tune the receiver manually back to the transmitter frequency all the time.
__________________
Regards,
Terje

http://www.hobbyradio.se/en/drm/webp....index_en.html
Digger is offline   Reply With Quote
Old 27-08-2017, 21:54   #9
tpreitzel
Registered User
 
Join Date: Apr 2012
Posts: 1,762
Indeed,

It's far past time for the DRM Consortium to address these issues with their members and start insisting those members pressure their clients on proper configuration of digital SW broadcasts as much as possible.
tpreitzel is offline   Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is On
Forum Jump


All times are GMT. The time now is 11:48.


Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.