RISC OS startup without RTC

A bug has been introduced somewhere so that RISC OS starts up with a date well into the future when no real time clock is recognised by RISC OS. It should start up with the last shutdown date so that time is continuous and then if a real time clock appears, the time would be advanced to the correct time. For example network connected but down on start up then network sparks into life.

It particularly affects a computer using a GPS module as its source of time/date as an uninitialised GPS module starts off thinking it is January 2100 (which SatNav is careful to avoid passing on to the operating system) at midnight, then it gets the GMT time from a satellite but still doesn’t know a better date than 2100 and only passes the date back in a few messages. Later on it passes the correct date (and then stores it using an internal battery for the future) and time, at which point SatNav passes the information to RISC OS.

The problem revealed itself because the GPS module battery expired and I was trying to track down why RISC OS thought it was January when the computer was last shut down in Febraury 2018.

Has the behaviour of RISC OS when started up with no real time clock available changed again to something bizarre please?

Apparently the year¹ is stored in CMOS bytes 128 and 129 so it might be worth trying:

SYS "OS_Byte", 161, 128 TO ,,i%
SYS "OS_Byte", 161, 129 TO ,,j%
PRINT i%
PRINT j%

That code is completely untested as I’m away from my machine at the moment :)

It should hopefully determine whether the date’s not being read, or not being written.

¹ I’m not sure where the rest of the date goes.

I’m home now… and with my 23-Oct-17 ROM I get the correct behaviour (the date persists across an “unplug and replug”). The CMOS values only contain 0 and 20 respectively so they could be a red herring.

Edit: It’s also working with the latest ROM (22-Feb-18). I’m on a Pi 3.

Strange. I have just copied & run your code on my Iyo 5.23 (14 Nov 17) and my Pi3 5.23 (01 Oct 17) and they both return 18 and 20 – ie the correct year of 2018.

Note both do have an RTC.

What date does *time show?

The problem revealed itself because the GPS module battery expired and I was trying to track down why RISC OS thought it was January when the computer was last shut down in Febraury 2018.

“January” is a very vague time. What day and year was it reporting?

I managed to get 01 Jan 2100 on my Pi when I was faffing about with a duff RTC module. Can’t remember if it was the default from the RTC module or hard-coded into RISC OS. Since I replaced it with a much better module (approximately £1.50 from China!) it has all been tickety-boo.

What day and year was it reporting?

Unfortunately I haven’t tested it yet. The date display on the PaPiRus display omits the year and I didn’t have an HDMI monitor connected. 6th January is the best I can do at the moment. I’ll do some testing and let you know.

Have now tested it. I have a GPS module as the only source of date and time which worked well over the last six months. Having left it unattended for several months the tiny watch battery (CR1220) which kept the on board real time clock ticking on the GPS module has expired.

The GPS board is from Adafruit and is designed around the MTK3339 chipset. It can track up to 22 satellites on 66 channels and features a built-in antenna. Location update rate is up to 10 per second (default is one per second) and power usage is only 20mA during navigation. The module has a built in data-logging capability that can log time, date, longitude, latitude, and height every 15 seconds and only when there is a fix. The internal FLASH can store about 16 hours of data. When a bigger antenna is required, any 3V active GPS antenna can be connected via the uFL connector and the module will automatically detect the active antenna and switch over.

Unfortunately when it does not know the time and date, the NMEA sentences return ‘060180’ as the date and count forward from midnight, obtaining the data from its internal RTC which has reset to its default. Once it has a clear satellite signal (not even a fix) the time from the satellite is included instead of midnight and some time later the date (and its internal RTC) is corrected. Now because RISC OS has been set to Jan 2080 by my software on start up (from the GPS module) the error is too large to be corrected. NMEA sentences only contain a two character year and I presume the 060180 was intended to be 1980. This would have been ignored as before the last shut down date (by my software) so it seems I must interpret the date in NMEA sentences as from 1980 to 2079, rather than from 2000 to 2099.

All my own fault, therefore! I was sure that it defaulted to 1-Jan-2100 (and I think I excluded that) but it seems I was wrong. Anyway once it has a fix, turning it off and then on again sets the RISC OS time correctly. It appears that the internal real time clock on the GPS module cannot communicate the century as the NMEA sentences it uses to communicate do not contain these data (or should it be ‘this datum’?).

Does your receiver not begin transmission with:

$PMTK103*30<CR><LF>

?

That’s a special value meaning “cold start”, indicating to not trust the date or positional information until a fix is received.

That’s a special value meaning “cold start”, indicating to not trust the date or positional information until a fix is received.

I think not (it is explicit in the NMEA messages that no positional info is being received to start with, whether a cold or a warm start). Because it has an internal RTC and battery (to retain info) it includes the date and time from its internal RTC in its NMEA messages before it has even found a satellite. Only when the battery has run done and gone flat does it revert to ‘060180’ at midnight. It does not send the century at any point, so it has to be inferred.

I could simply ignore ‘060180’ unless and until a valid fix has been obtained (as it will, eventually, correctly be the year 2080) but my current work around is to switch off and on again once a fix has been obtained. I think the simplest approach is what I shall do, as the uninitialised date from the GPS module is consistent.

All my own fault, therefore! I was sure that it defaulted to 1-Jan-2100 (and I think I excluded that) but it seems I was wrong.

The GPS module defaults to ‘060180’, interpreted as 6th Jan 2080, and I excluded it as below. See if you can spot the error!

18360 REM date provided in NMEA message and extracted
18365 REM in k$="ddmmyy" and b$="hhmmss" (time is GMT)
18370 kk$=MID$(k$,1,2)
18375 REM Note 33750*256cs = 1 day and 
18377 REM &553AD90000 is 5 byte UTC for 00:00:00,01-Jan-2016
18380 kH%=(VAL(kk$)-1)*33750+&553AD900
18390 kL%=0
18400 kH%+=(VAL(MID$(k$,5,2))-16)*365*33750
18410 kH%+=(((VAL(MID$(k$,5,2))-1) DIV 4)-3)*33750
18420 leap%=((VAL(MID$(k$,5,2)) MOD 4)=0)*33750
18430 CASE MID$(k$,3,2) OF
18440 WHEN "01":kk$+="-Jan-20"
18450 WHEN "02":kk$+="-Feb-20":kH%+=31*33750
18460 WHEN "03":kk$+="-Mar-20":kH%+=59*33750-leap%
18470 WHEN "04":kk$+="-Apr-20":kH%+=90*33750-leap%
18480 WHEN "05":kk$+="-May-20":kH%+=120*33750-leap%
18490 WHEN "06":kk$+="-Jun-20":kH%+=151*33750-leap%
18500 WHEN "07":kk$+="-Jul-20":kH%+=181*33750-leap%
18510 WHEN "08":kk$+="-Aug-20":kH%+=212*33750-leap%
18520 WHEN "09":kk$+="-Sep-20":kH%+=243*33750-leap%
18530 WHEN "10":kk$+="-Oct-20":kH%+=273*33750-leap%
18540 WHEN "11":kk$+="-Nov-20":kH%+=304*33750-leap%
18550 WHEN "12":kk$+="-Dec-20":kH%+=334*33750-leap%
18560 OTHERWISE:kk$+="-???-20"
18570 ENDCASE
18580 kk$+=MID$(k$,5,2)
18590 REM kk$ is string to display
18600 REM kH%,kL% is 5-byte UTC of 00:00:00 <date of msg>
18610 IF needtime% AND kH%<&7FFFFFFF THEN
18620   REM Exclude dates after 04:28:56 18-Mar-2074
18623   REM because the GPS module returns '060180' when
18626   REM its battery goes flat, hence reject 2080
18670   hrs%=VAL(MID$(b$,1,2))
18680   mins%=VAL(MID$(b$,3,2))
18690   secs%=VAL(MID$(b$,5,2))
18700   extra%=secs%*100+mins%*6000+hrs%*360000
18710   kL%=extra% AND &FF
18720   kH%+=extra%>>8
18730   !tmm%=kL%
18740   tmm%!1=kH%
18750   SYS "Territory_SetTime",tmm%
18760   needtime%=FALSE
18770 ENDIF

The error is in line 18610 as, according to BASIC, &81000000 is, indeed, less than &7FFFFFFF.