Fantastic - I will owe you big time if you can pull that off.

 

If needed, the archive file I've used to program my camera module is attached.  For testing purposes you'll need to set DPS to Global A/Global A with ObjDetectionBus, then select pins 3 and 11 - other settings have yielded programming errors for me in DPS.

FCM USE ME.zip

Any luck so far?  Let me know if I can help at all...

will send it to you later this day

 

will send it to you later this day

39142371.bin

Just now, WSOpel said:

will send it to you later this day

39142371.bin 1.55 kB · 0 downloads

is for BCM

That one yields the same effect as the Equinox calibration above: program to 99%, then programming error message with the car basically bricking afterwards.  I was able to program the BCM back to its prior function with my other archive that has stock headlamp calibration.

 

Log files for both DPS runs are attached, as are both archive files I'm using.

BCM Intellilux 3rd time is the charm.zip BCM re-re-re-program.zip ProgramLog 4 3 2023 BCM Stock.Txt ProgramLog 4 4 2023 BCM.Txt

I should note that "BCM Intellilux 3rd time is the charm" is the one I created with your new calibration file, and "BCM re-re-re-program" is the basically stock one that has Rainsense wiper calibration added.

Update:

 

I took a deeper dive into that calibration file and found that the checksum was off.  Using the instructions for checksum correction drawn up by @Troy and others here, I fixed the checksum and used the file to successfully program the BCM.

 

The automatic high beam switch still does not work, but the low beams are no longer locked on - the control switch on the dash functions as it should.  I'm going to attempt to recalibrate my camera and other systems this evening in the hopes that pulling the BCM piece together will help things play together as they ought - in the meantime, @WSOpel, if you have any ideas let's hear them!

 

If it's not been made clear, I'm amazed by and grateful for this community and all its knowledge.  Still plugging away...

Also, after driving the car, the low beams remain on even in full sunlight. Normal system operation otherwise. 

Oh sorry for my mistake. I will look in the files again. Did the Auto funktion work in yor original config ? Mayby i hade some issue by Compare the DID.

The Front Camera is need for the Automatic HIGH beam with the Full funktion of pass out the other Traffic.

 

I hope you can understand what i mean

16 minutes ago, WSOpel said:

Oh sorry for my mistake. I will look in the files again. Did the Auto funktion work in yor original config ? Mayby i hade some issue by Compare the DID.

The Front Camera is need for the Automatic HIGH beam with the Full funktion of pass out the other Traffic.

 

I hope you can understand what i mean

 

39142371.bin

Yes, the stock calibration had the automatic low beams working.

 

The new BCM file you uploaded has more or less the same effect that the other did - the low-beams stay on even in daylight, but the on-off switch works normally.  Still no intelligent high beam function.

 

Just to make sure I track what you're saying re: the camera too: I know that proper camera programming is needed to make the intelligent high beams work, but are you saying that the on-off switch for the intelligent high beams communicates directly with the camera?  Or does it route through the BCM somehow?

 

No worries at all - I've quickly come to the understanding that attempting these things is basically playing a game of whack-a-mole.  Change one thing, then change another thing because you changed the first thing, etc.  I get it!

39047010ZH.xml try this for the Cam

will look tomorrow in the cal again

Haven't tried it yet, but that XML has several more pieces under "ModificationItem" than the ones I've been getting off of TIS2Web.  Cautiously optimistic...

I decided I'd do a little snooping on this XML, and it looks like I might have discovered another issue: it seems as though the intelligent high beam camera functions are tied into RPO code UEY, which is apparently an European version of forward brake assist.  This XML as written requires the presence of UEY in order to program; it also appears to require the absence of the equivalent American RPO, code UGN, in order to write. 

 

I took the liberty of switching the RPO codes around so that it would write functions in the presence of the UGN RPO; however, in so doing I think I've screwed up the checksum, as I get security access errors when trying to write the XML configuration through the ECU Configuration option in DPS.  (I've accessed the seed key and entered that into the system prior to programming, to no avail.)  Not totally certain how to rewrite checksums in XMLs either, especially GM's particular breed.

 

The edited XML is attached...let me know if I've screwed something up.

39047010ZHedit.xml

If xml works the same way as for the cluster, you don't need any check summs etc. You just need to make it do what you want and look for RPOs that you have(it should work unless there reason for certain rpos to be present is hardware related and could not be done without particular components). I'll have a look at xml and will let you know.

Another thing- it looks like this xml is defaults for Australian market. I'd try to change that to Europe and swap RPOs to make it look for yours, not for European one.

Also UEY is not declared in this xml, maybe you meant UHY?

Yep, I meant UHY. (This is what I get for typing late at night after chasing a toddler around all evening, lol.) 

 

You might be right on the Australian coding, but I've found that GDS will recognize my TourX as different makes depending on what diagnostics I have loaded - Global will make it say it's a Holden Commodore, whereas Opel/Vauxhall makes it say it's an Opel. So i would be surprised (but not shocked) if that mattered. 

 

Part of the reason I think it might be RPO-sensitive too is the fact that, in some of my experiments with getting the traffic sign recognition active, I seemingly found that adding the code for chassis ride height from the TourX broke the function. (No error codes, the sign display in the front menu worked, but the camera would not transmit the data to the cluster, seemingly.) Taking that code out fixed the issue. 

can you give me your Build Record without VIN ? so i will mod the XML

The FCM-only build record is attached - I have the complete one too if you need it.

FCMBuild.txt

i need the whole build like cluster

In that case, here you go!

BuildRecordNoVIN.bld BuildRecordNoVIN.txt

So there is a mate who was trying to do exactly the same thing - he bought new switches from the guy in China who were supposed to do programming for this function. He was unsuccessful last night saying that there are additional wiring required. I'll keep you posted if I get any info on this.

Interesting. FWIW, the only non-stock switch I have installed right now is the turn signal stalk - the stock one does not have a button on it at all, and the one I have installed has the auto high beam button on it. 

 

I do know from diving into this that there are features available in Europe which require more parts and wiring than we have - the adjustable suspension, for example, requires a whole different control module that is absent on TourXes, as is the module which enables 360-degree camera viewing and a steering lock module. That said, scouring the service manuals doesn't really point to any additional systems that are needed to make this work other than a headlamp control module and front camera module, both of which I've visually verified are present on my car as well as successfully programmed.