Can the OnStar vehicle reports check on firmware versions installed?
Can the OnStar vehicle reports check on firmware versions installed?
I would like to find out just how integrated OnStar is with the rest of the systems on board the HHR SS. Since they can supposedly pull down trouble codes, etc can they also tell if the computer has been re-flashed? If so and they look at the checksum/version they could tell if it was a non-GM installed upgrade.
On that note can OnStar push down firmware upgrades or do those have to be done at the dealer?
I'd like to find a way to display the versions I have to find out if mine are the latest ones available.
Also, OnStar can automatically slow down some cars if needed in the event they are stolen. Is the HHR one of the vehicles that this applies to?
On that note can OnStar push down firmware upgrades or do those have to be done at the dealer?
I'd like to find a way to display the versions I have to find out if mine are the latest ones available.
Also, OnStar can automatically slow down some cars if needed in the event they are stolen. Is the HHR one of the vehicles that this applies to?
It is my understanding that the main network in the HHR is all based on CAN BUS. If the OnStar module is also connected on the BUS and can query devices for certain parameters (Mileage, tire pressure, oil life remaining, trouble codes) then I guess I would like to know just what else they can query from the cars on board systems??? Is anyone else curious about this? Is it all locked and limited or can they create their own queries at a later date to pull more stats about other parameters.
I guess one of the only ways to really find out is to get on the CAN bus and use one of the loggers to capture all the CAN BUS data to/from the OnStar box to find out what stats they are really getting.
I guess one of the only ways to really find out is to get on the CAN bus and use one of the loggers to capture all the CAN BUS data to/from the OnStar box to find out what stats they are really getting.
Pushing a flash down the the system via OnStar is not only impractical, but downright dangerous...
The OBD II connection that GM uses is based on SAE J1850 VPW (variable pulse width - 10.4/41.6 kbaud) not CAN). The maximum speed of early 3G CDMA phones is 307kb, which translates roughly into 38 kbaud... ASSuming zero mod/demod overhead... so probably more like 33 kbaud).
What happens when a bit gets dropped in the ether? The BCM is (most likely) bricked. If you were driving down the road, now you're coasting toward the shoulder... and you probably can't even use OnStar any more to call for assistance. Flashing the BCM is a "tense moment" and so you don't want ANYTHING to upset the system while this is being done. The only real solution to this is a "failover" system that allows for NDU (non-disruptive upgrade), which is essentially a secondary system that accepts the new flash, then, on completion, tells the other system that it is now going to take over, thus allowing the first system to be upgraded. This is SOP for HA computer storage systems... but is also absurdly expensive for this kind of application, especially given the value of the feature GM would gain from it.
The OBD II connection that GM uses is based on SAE J1850 VPW (variable pulse width - 10.4/41.6 kbaud) not CAN). The maximum speed of early 3G CDMA phones is 307kb, which translates roughly into 38 kbaud... ASSuming zero mod/demod overhead... so probably more like 33 kbaud).
What happens when a bit gets dropped in the ether? The BCM is (most likely) bricked. If you were driving down the road, now you're coasting toward the shoulder... and you probably can't even use OnStar any more to call for assistance. Flashing the BCM is a "tense moment" and so you don't want ANYTHING to upset the system while this is being done. The only real solution to this is a "failover" system that allows for NDU (non-disruptive upgrade), which is essentially a secondary system that accepts the new flash, then, on completion, tells the other system that it is now going to take over, thus allowing the first system to be upgraded. This is SOP for HA computer storage systems... but is also absurdly expensive for this kind of application, especially given the value of the feature GM would gain from it.
you must be some sort of computer dork like me.
Pushing a flash down the the system via OnStar is not only impractical, but downright dangerous...
The OBD II connection that GM uses is based on SAE J1850 VPW (variable pulse width - 10.4/41.6 kbaud) not CAN). The maximum speed of early 3G CDMA phones is 307kb, which translates roughly into 38 kbaud... ASSuming zero mod/demod overhead... so probably more like 33 kbaud).
What happens when a bit gets dropped in the ether? The BCM is (most likely) bricked. If you were driving down the road, now you're coasting toward the shoulder... and you probably can't even use OnStar any more to call for assistance. Flashing the BCM is a "tense moment" and so you don't want ANYTHING to upset the system while this is being done. The only real solution to this is a "failover" system that allows for NDU (non-disruptive upgrade), which is essentially a secondary system that accepts the new flash, then, on completion, tells the other system that it is now going to take over, thus allowing the first system to be upgraded. This is SOP for HA computer storage systems... but is also absurdly expensive for this kind of application, especially given the value of the feature GM would gain from it.
The OBD II connection that GM uses is based on SAE J1850 VPW (variable pulse width - 10.4/41.6 kbaud) not CAN). The maximum speed of early 3G CDMA phones is 307kb, which translates roughly into 38 kbaud... ASSuming zero mod/demod overhead... so probably more like 33 kbaud).
What happens when a bit gets dropped in the ether? The BCM is (most likely) bricked. If you were driving down the road, now you're coasting toward the shoulder... and you probably can't even use OnStar any more to call for assistance. Flashing the BCM is a "tense moment" and so you don't want ANYTHING to upset the system while this is being done. The only real solution to this is a "failover" system that allows for NDU (non-disruptive upgrade), which is essentially a secondary system that accepts the new flash, then, on completion, tells the other system that it is now going to take over, thus allowing the first system to be upgraded. This is SOP for HA computer storage systems... but is also absurdly expensive for this kind of application, especially given the value of the feature GM would gain from it.
Pushing a flash down the the system via OnStar is not only impractical, but downright dangerous...
What happens when a bit gets dropped in the ether? The BCM is (most likely) bricked. If you were driving down the road, now you're coasting toward the shoulder... and you probably can't even use OnStar any more to call for assistance. Flashing the BCM is a "tense moment" and so you don't want ANYTHING to upset the system while this is being done. The only real solution to this is a "failover" system that allows for NDU (non-disruptive upgrade), which is essentially a secondary system that accepts the new flash, then, on completion, tells the other system that it is now going to take over, thus allowing the first system to be upgraded. This is SOP for HA computer storage systems... but is also absurdly expensive for this kind of application, especially given the value of the feature GM would gain from it.
What happens when a bit gets dropped in the ether? The BCM is (most likely) bricked. If you were driving down the road, now you're coasting toward the shoulder... and you probably can't even use OnStar any more to call for assistance. Flashing the BCM is a "tense moment" and so you don't want ANYTHING to upset the system while this is being done. The only real solution to this is a "failover" system that allows for NDU (non-disruptive upgrade), which is essentially a secondary system that accepts the new flash, then, on completion, tells the other system that it is now going to take over, thus allowing the first system to be upgraded. This is SOP for HA computer storage systems... but is also absurdly expensive for this kind of application, especially given the value of the feature GM would gain from it.
There is still the question as to if they can check the logs to see how many times the BCM has been flashed and if it is a non-GM issued set of code/parameters on it. This is a concern to anyone who gets the automatic e-mail about the vehicle stats. Are they collecting that data and could that be used in a warranty claim?? If that is the case then it may not matter if you flash the BCM back after using one of the available tunes. See my concern?
I had read that the 2008 was completely CAN BUS and that the other methods of connecting were obsolete. It sounds like the older method may still be used to program the BCM but the rest is using the newer BUS.
This is still new to me but I do find it interesting and want to learn as much about my new HHR as I can.
Thread
Thread Starter
Forum
Replies
Last Post



