Plus the battery is now dead.. would leading it in the wrong way, kill it?
I can't see how it's related to the core issue, unless a bad signal could somehow crash the kvm? And it resets itself some hours later?
I've never had 'batt low' on the dash and never thought to check.. plus with the other fob not working assumed it was not a battery issue (batt in the other fob is good)
It might have killed the fob, electronics don't like reverse polarity.
 
Keys and other items with 'consumer replaceable' batteries are usually well protected against reverse polarity and incorrect (to a point) voltage.
 
Keys and other items with 'consumer replaceable' batteries are usually well protected against reverse polarity and incorrect (to a point) voltage.
Yes, pretty much everything on batteries also doesn't get enough amps to do any damage
 
Plus the battery is now dead.. would leading it in the wrong way, kill it?
I can't see how it's related to the core issue, unless a bad signal could somehow crash the kvm? And it resets itself some hours later?
I've never had 'batt low' on the dash and never thought to check.. plus with the other fob not working assumed it was not a battery issue (batt in the other fob is good)
Later KVM's definitely go into 'lockout' type mode if there are many incorrect codes received in a specific timeframe, it's called 'tarpitting' and is a common software defence originally developed for email servers.
 
Not familiar with this car, but does SDD show you Valid or Invalid code received like the P38 ?
 
The RF receiver just converts the received signal to serial data packets then the KVM compares it to expected rolling code range, I haven't looked at KVM data for a long time - from what I remember the code table and expected / actual result were only visible with a FSE login, which is as long winded way of saying 'yes & no - but output functions could be seen'.
 
Later KVM's definitely go into 'lockout' type mode if there are many incorrect codes received in a specific timeframe, it's called 'tarpitting' and is a common software defence originally developed for email servers.
Maybe then I've pressed the button a few times that's sent either a partial or corrupted signal due to low power and that's locked the KVM, which is why it works after so many hours again.. hmm.. that sounds plausible to to the point on Friday when the spare key didn't work.. but maybe i need to keep an eye on the idea
 
I'm still going to go thru the CCF and reload it. It does complain about inconsistencies (5)
See if i can see what doesn't line up. I know from the bmw i had that for example of you wanted DRL turned on, you had to be consistent across different options (i don't plan to change anything)
 
Maybe then I've pressed the button a few times that's sent either a partial or corrupted signal due to low power and that's locked the KVM, which is why it works after so many hours again.. hmm.. that sounds plausible to to the point on Friday when the spare key didn't work.. but maybe i need to keep an eye on the idea
It would need over 250 presses to exceed the range of stored codes, it may be worth leaving the battery out of one key and using the other for a period of time to see if one key or the other is 'spamming' the car - none of which would explain the DTC you had for loss of comms to the RF receiver though. The receiver is LR012398 and doesn't need coding, maybe see if you can get a cheap one and swap it over once you've checked the wiring? unfortunately there's no real tests you can do with it not working as intermittently as yours - and TBH, it could still be wiring or KVM...
 
Update: so far, it's not happened again, so i am following the logic that disconnecting the battery has cleared any bogus data and allowed all the modules to reset (turn it off and on again)
Both keys still work so leaving the battery in the wrong way around overnight didn't cause any issue
 

Similar threads