DRM Software Radio Forums  

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

Thread Tools Search this Thread Display Modes
Old 07-08-2017, 00:28   #1
Registered User
Join Date: Oct 2014
Location: Eastern Newfoundland
Posts: 132
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
Registered User
Digger's Avatar
Join Date: Mar 2005
Location: Near Stockholm, Sweden
Posts: 9,443
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): 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.

Digger is offline   Reply With Quote
Old 11-08-2017, 09:47   #3
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
Registered User
Join Date: Oct 2014
Location: Eastern Newfoundland
Posts: 132
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
Registered User
Join Date: Aug 2006
Location: BaiSe, P.R. China @E10636′ N2355′
Posts: 204
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.

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

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 05:42.

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