SG9663DC Clock problem [SOLVED]

[Striker]

I'm having an issue with my SG9663DC's clock. I was recording a test video while driving around and noticed the time jumped back an hour from 23:51:02 back to 22:51:16. This affected the time for the rest of my videos. I also had to correct the time yesterday as well (I'm set to PDT -8hrs).

I'm using beta firmware 1.31. Is anyone else having an issue with the time for their dash cam? Should I try rolling back to public version 1.30? I have the new hardwire kit, so I want to keep testing it with the beta firmware.

(I'll try to post photos of my newbie install later; wires are everywhere but at least it's working properly, I think...)

 

[jokiin]

do you have DST (daylight savings time) where you are?

in most cases we find when the time is off by an hour people haven't accounted for the DST change

 

[Striker]

Thanks, I didn't account for that. I'll fix the time and adjust to -7hrs GMT and report back if it still does the -1 hour jumping.

 

[Striker]

Setting time -1hr for DST solved the issue.

 

[Brian_CA]

New owner of SG9663DC and it should be installed in the next few days. Hopefully someone from SG can answer my question(s):

1) Does the SG9663DC obtain date and time information from the satellite?
2) If the answer is yes, could firmware not be written to allow for automatic DST provision. The code effectively would be: DST begins second Sunday in March and ends on first Saturday in November alternatively the values in bold could be variables which would accommodate any future changes to DST implementation dates.

Many thanks in advance.

 

[jokiin]

1. yes
2. no, not at this point in time at least

 

[kamkar]

A minor nuisance with the DST, but not so bad as its not that often, geographical we Danes are +1 but now in the summer i have to set it to +2

 

[Brian_CA]

jokiin, many thanks for the quick reply.

With regards to your response to #2, would this programmatic solution be within the capabilities of the Novateck NT96663 processor. It would be nice to know if this is something that could be considered in the future as it would increase the set-and-forget value of the SG9663DC.

 

[jokiin]

it's not something that is in the current SDK so would need to be hand coded, a lot more things to do before we could look at this, if it comes in a future SDK though we would do it

 

[Brian_CA]

Understand completely that there are other more pressing items to address. I appreciate the responses as it reaffirms that I purchased an excellent dash cam from a company that values customer service.

 

[wozzzzza]

day light saving never bothers me as we dont have it here

 

[DT MI]

...could firmware not be written to allow for automatic DST provision. The code effectively would be: DST begins second Sunday in March and ends on first Saturday in November alternatively the values in bold could be variables which would accommodate any future changes to DST implementation dates...

Not quite that simple as not all areas observe DST and others use different start and end dates.

https://en.wikipedia.org/wiki/Daylight_saving_time#By_country_and_region

 

[jokiin]

day light saving never bothers me as we dont have it here

we should be so lucky, you'd be surprised how many people have no idea what timezones are

 

[GeekOnTheHill]

we should be so lucky, you'd be surprised how many people have no idea what timezones are

Back in, I believe, 1974, President Richard Nixon signed year-round daylight savings time into law. Lots of people were upset over it because, among other things, it meant that children would have to walk to school while it was still dark. But when people suggested that they just start school an hour later, the teachers' unions went apoplectic because starting school an hour later would mean they'd get home an hour later.

I found it all quite amusing because the only thing that actually would change would be an arbitrary number. If they started school an hour later, the children would be going to school, and the teachers returning home from school, at exactly the same times as if DST hadn't been implemented. The hands on the clocks would be in different positions, but the time itself would not change.

I still view DST with vigorously-raised eyebrows. It's a pointless, twice-yearly ritual, as far as I'm concerned. I'm especially puzzled by my retired friends who don't see well-enough to drive at night, and who want year-round DST because it would give them "more hours of daylight." Um, no. The number of daylight hours would be exactly the same; and they could avail themselves of those hours, without DST, simply by getting out of bed an hour earlier.

Richard

 

[kamkar]

Nixon said a lot, in a series / doku on the Vietnam war i heard him say something pretty disturbing about Jewish people.
It was good to me to watch and i recommend it left and right.
https://en.wikipedia.org/wiki/The_Vietnam_War_(TV_series)

 

[GeekOnTheHill]

jokiin, many thanks for the quick reply.

With regards to your response to #2, would this programmatic solution be within the capabilities of the Novateck NT96663 processor. It would be nice to know if this is something that could be considered in the future as it would increase the set-and-forget value of the SG9663DC.

I'm no expert on coding for cameras, but I don't think it has so much to do with the processor as just more code. More than likely the RTC uses UTC anyway, and the camera knows where it is because of the GPS. Add a database of the time zone rules for every place on earth, and it could calculate local time as an offset from UTC. Add some more code, and it could update local time every time it crossed a time zone boundary.

The problems would be, firstly, that even something relatively simple like checking a location against a database requires storage, CPU, and RAM resources that most people would rather be spent on good video; and secondly, that dash cams don't generally connect to the Interwebs, so the database would fairly frequently become incorrect as the rules changed (which happens pretty often).

I rarely travel outside my own time zone by car. If I did, I'd just set the clock to UTC and leave it there.

Richard

 

[DT MI]

...The problems would be, firstly, that even something relatively simple like checking a location against a database requires storage, CPU, and RAM resources that most people would rather be spent on good video; and secondly, that dash cams don't generally connect to the Interwebs, so the database would fairly frequently become incorrect as the rules changed (which happens pretty often)...

Thirdly (and most important) someone will have to monitor the rule changes and update the database - who will pay for that ongoing expense?

 

[jokiin]

the processor is capable of looking up a database table without too causing performance issues, our old Ambarella A2 based camera we did 5 years ago had auto timezone, it's not very straightforward though and isn't really worth the trouble

 

[kamkar]

I have several cameras i dont touch the time zone on, for instance my R side camera the innovv C3, i cant even remember when i last had it connected to the computer and did settings on it, but it is years ago, same go for my long range camera on the X cam platform.
The old mobius 1 i do have on the computer now and then, but i cant recall if i have set the time on it, but i think it sync to computer time on its own.
Either way all 3 cameras i dont use time stamp in the footage, so its only trying to wrangle a pice of footage of them i lean up against that feature of the recorded files.

It is annoying, so for a long time i have been dreaming of getting a dual channel camera that sync with satellites, and thats sorted with the DC at least in regard to the main views from the front and rear.