SG9665GC firmware updates and pre release access

No. There's discussion somewhere about this but the basic reason boils down to the fact that there is no map data in the camera/GPS unit to determine where the unit is located. The GPS data consists only of the coordinates.

that discussion was about automatically accounting for daylight savings time changes
 
Rough function would be better than no function though. (at least if you can turn it on and off) That's how most dashcams seem to do it.

most cameras have time sync from GPS (as we do also), automated timezones though they don't
 
Thus the business case. If you're going strictly for a hardcore niche market, then you can lower the priority even further. If you're trying to expand beyond that, then it raises the priority of all these absurd hang-ups that so many people have, because you want them as customers. It still doesn't necessarily make it worth messing with or even possible in the first place based on the hardware chosen. But it remains a consideration to be ranked against others for limited resources.

It's one thing to offer a quality product with a range of useful features and to add oft requested features if and when practical. But to accommodate every petty whim or demand from entitled table pounding users regardless of the time, effort or cost involved will put you out of business in no time.
 
It's one thing to offer a quality product with a range of useful features and to add oft requested features if and when practical. But to accommodate every petty whim or demand from entitled table pounding users regardless of the time, effort or cost involved will put you out of business in no time.
Is it? Is it a different thing? WTF kind of response is that? And who ever suggested any company should ever "accommodate every petty whim of entitled table pounding users" regardless of practical considerations?
 
Is it? Is it a different thing? WTF kind of response is that? And who ever suggested any company should ever "accommodate every petty whim of entitled table pounding users" regardless of practical considerations?

Well, you are the one who said essentially that, suggesting, "it raises the priority of all these absurd hang-ups that so many people have".

As for the rest of it, I think successful manufacturers and dash cam developers here on DCT like @jokiin and others can best address the practical realities of designing and marketing such products. I can assure you though that developing dash cameras around potential buyer's "absurd hang-ups" is not one of their priorities.
 
Last edited:
What I actually said: "If you're going strictly for a hardcore niche market, then you can lower the priority even further. If you're trying to expand beyond that, then it raises the priority of all these absurd hang-ups that so many people have, because you want them as customers."

I have no problem with the way @jokiin and crew have developed their products. They strike me as very similar to Valentine Research, makers of the much loved Valentine One radar detector: function over form and quality over quantity. Which is certainly part of why the SG0665CG can command over twice the price of the A119, for example. The V1 still has no GPS available at all, no built-in Bluetooth, no OLED display, none of the stuff most people expect in a high end radar detector today. It's the same black box with little indicator lights on it that it was in the early '90s when it came out. And yet it still commands a hefty premium over most other mass-market radar detectors. Yes, I really wish Mike Valentine would change his mind about GPS lock-outs and would build Bluetooth into the unit itself. And a new display would be nice (that showed the posted speed limit like a sat nav can). But we still stick with the V1 because it's still one of the best and offers the best customer service.

Valentine Research is going strictly for a hardcore niche market. So they lower the priority of the absurd hang-ups of the general public even further than others might. How SG approaches that broad series of considerations is their own strategic choice, which then informs their tactical choices.

One thing you may have not realized is that everything has a priority assigned to it. It can be so low as to be ignored completely or so high that everything else stops until it's done. Time zone detection, boundary crossing handling, and automatic DST changes each have a priority. It could even inform the decision on which hardware to base future models on, one day, if it were high enough priority. It may just be that neither is high enough to warrant much consideration at all.

The idea that anyone in the industry specifically develops products around absurd hang-ups is ridiculous.
 
What I actually said: "If you're going strictly for a hardcore niche market, then you can lower the priority even further. If you're trying to expand beyond that, then it raises the priority of all these absurd hang-ups that so many people have, because you want them as customers."

I have no problem with the way @jokiin and crew have developed their products. They strike me as very similar to Valentine Research, makers of the much loved Valentine One radar detector: function over form and quality over quantity. Which is certainly part of why the SG0665CG can command over twice the price of the A119, for example. The V1 still has no GPS available at all, no built-in Bluetooth, no OLED display, none of the stuff most people expect in a high end radar detector today. It's the same black box with little indicator lights on it that it was in the early '90s when it came out. And yet it still commands a hefty premium over most other mass-market radar detectors. Yes, I really wish Mike Valentine would change his mind about GPS lock-outs and would build Bluetooth into the unit itself. And a new display would be nice (that showed the posted speed limit like a sat nav can). But we still stick with the V1 because it's still one of the best and offers the best customer service.

Valentine Research is going strictly for a hardcore niche market. So they lower the priority of the absurd hang-ups of the general public even further than others might. How SG approaches that broad series of considerations is their own strategic choice, which then informs their tactical choices.

One thing you may have not realized is that everything has a priority assigned to it. It can be so low as to be ignored completely or so high that everything else stops until it's done. Time zone detection, boundary crossing handling, and automatic DST changes each have a priority. It could even inform the decision on which hardware to base future models on, one day, if it were high enough priority. It may just be that neither is high enough to warrant much consideration at all.

The idea that anyone in the industry specifically develops products around absurd hang-ups is ridiculous.

What you actually said was, "If you're trying to expand beyond that, then it raises the priority of all these absurd hang-ups that so many people have, because you want them as customers." You are the one who came up with that concept.

The radar detector market is a different animal than the relatively embryonic and indeed for the time being more or less "enthusiast" dash cam market. The SG9665GC commands over twice the price of the A119 partly on the quality of its components, included accessories and memory card as well as its extraordinarily generous return and replacement policy which must get paid for one way or another and so is built into the pricing equation.
 
Last edited:
Yes, thank you for agreeing. And it was not an exact comparison to the V1, just pointing out the similarities in style and approach.
 
We've been internally testing new V1 firmware for the past week. So far so good. The goal is to match V2/V3 features for V1 owners.
 
The blue cast in @Feitelijk's video is indeed a problem that has been seen before in certain other cameras. For example, similar problems existed in early iterations of the Mobius 1 firmware which also sometimes manifested as a Red - Green shift. If you drove by a large red brick building or a bright red vehicle would cross your path the footage would go greenish/cyan for awhile until it recovered.

The problem is related to the RGB (RED-GREEN-BLUE) additive color model used in digital cameras, computers, etc. (as opposed to the CMYK (CYAN-MAGENTA-YELLOW-BLACK) subtractive color model used in pigment based printing and chemical based analogue photographic color printing)

On the RGB color wheel Yellow and Blue are exactly opposite one another. (as are RED & GREEN) Notice how in @Feitelijk's examples the image goes from a mostly YELLOW environment to excessively BLUE. This is because the camera is attempting to achieve proper color balance by adding BLUE in order to compensate for the abundance of YELLOW in the scene but it is overcompensating and the camera has difficulty returning to normal once it sees a normal color environment again.

View attachment 28053

So, as I've said, YELLOW and BLUE are opposite each other on the RGB color wheel chart.
Notice that the center of the chart is WHITE.
When RED-GREEN & BLUE are in proper balance in the RGB model you get pure WHITE.
This is what the familiar term "White Balance" is referring to.
Feitelijk's camera is overshooting the white balance point and then slowly returning to normal.
Understanding this concept is the key to resolving this problem in the firmware.

View attachment 28052 View attachment 28067

Mobius addressed this problem relatively quickly once they became aware of it.

Feitelijk has been reporting this problem for quite some time now but it has yet to be addressed. This is reminiscent of my dissatisfaction regarding the blooming and blown out upper tonal range issue that went on for a year and half or more from the time I first reported it until it finally received some level of firmware remedy.

For a long time now I've been wondering why a highly rated camera such as the SG9665GC is still on "beta" firmware more than two years after its introduction. Updates, sure that's pretty normal, but I can't think of another digital product I've ever owned that is still on "beta" firmware more than two years after coming to the market. I suppose whatever you call these updates, "beta" or otherwise doesn't really matter as long as major issues get the attention they require but for some reason issues like this seem to linger for a very long time on the GC until they finally get that attention. I do understand that it can take awhile to sort things out but a problem like this does seem to still be a "beta" kind of thing two years in. Like I've mentioned, Mobius got right on it. Then again, maybe this color balance problem hasn't gotten any firmware attention because it hasn't been reported all that often?

Interestingly, now that I think about it the dynamic range/high contrast issue that went on for so long was also a matter of the camera taking far too long to recover to a normal state after an exposure compensation event. Seeing the camera overcompensating for color balance and then taking too long to recover feels in some ways like a similar phenomenon. Perhaps there is something challenging along these lines inherent in this DSP/sensor hardware combination?

For whatever it is worth, I have not personally noticed any color balance or color shift issues whatsoever with my SG9665GC. Since re-calibrating the camera and re-flashing beta 27 results have been quite good except for some occasions when the footage is too dark for the general lighting scenario. Happily this has been less severe than previously and therefore less of a concern. Come to think of it, FWIW, the "too dark" footage thing also seems to be an overcompensation exposure issue.

The only recent problem I've had was discovered just this morning upon reviewing some footage from yesterday. Apparently the last file on the memory card is corrupted and unplayable. Hopefully, this is some sort of one-off and not a harbinger of some other brewing problem. Yesterday morning it was - 4 degrees below zero Fahrenheit when I woke up in the morning and the camera was out in my truck all night but I have no idea if that could have anything to do with the bad file. If it happens again I'll try a fresh memory card and go from there.
I do remember vaguely you had a similar issue a few months back.
 
I do remember vaguely you had a similar issue a few months back.

Well, not really @Sutton, as I said right in my post you've quoted, "I have not personally noticed any color balance or color shift issues whatsoever with my SG9665GC.".

I did mention that color balance shifts happened in some early Mobius 1 firmware versions though.

Perhaps you are referring to the high contrast/dynamic range exposure issue that has since been addressed in the recent beta?
 
When the hell is the new beta coming out?

no public beta at the moment, will be a release version next but need to get the manual updated before it's posted, should be before new year though

there are further updates coming but we're waiting on some SDK updates we've requested to get done so we can do what we need
 
Well, not really @Sutton, as I said right in my post you've quoted, "I have not personally noticed any color balance or color shift issues whatsoever with my SG9665GC.".

I did mention that color balance shifts happened in some early Mobius 1 firmware versions though.

Perhaps you are referring to the high contrast/dynamic range exposure issue that has since been addressed in the recent beta?
Perhaps , you may be right. I do follow your posts pertaining to the SG9665GC But with so many posters here I have a problem to actually maintain memory who said what as time passes.
 
Any update for the new release version firmware?
 
Probably never - they are slow as poop. I asked over a week ago and anytime I ask it's "right around the corner"...until a month or two goes by.
 
Also testing newest V1 firmware, and to be honest i have only found 1 bug with it.
 
Back
Top