Chevy Bolt EV Forum banner

21 - 40 of 86 Posts

·
Registered
Joined
·
1,001 Posts
It's the 14 volt module that controls charging for the 12 volt DC BECM. It's controlled separate
from the rest of the cars networks. We are network restricted due to the high amount of bus control systems. We currently have 5 data bus systems. I can only guess they setup this 12 volt charging system on it's own to simplify things.
 

·
Premium Member
Joined
·
787 Posts
It's the 14 volt module that controls charging for the 12 volt DC BECM. It's controlled separate
from the rest of the cars networks. We are network restricted due to the high amount of bus control systems. We currently have 5 data bus systems. I can only guess they setup this 12 volt charging system on it's own to simplify things.
Does the passenger side DLC/OBDII port do anything other than supply 14V? It's not like you can't hookup a battery tender to the 12V terminals in the "engine" bay to recharge the 12V battery if it gets low.
 

·
Registered
Joined
·
1,001 Posts
Does the passenger side DLC/OBDII port do anything other than supply 14V? It's not like you can't hookup a battery tender to the 12V terminals in the "engine" bay to recharge the 12V battery if it gets low.
The DLC is the data/communication port for the 14 volt module. Both ports have a battery feed/power supply pin for the scan tools. It's not used to power up accessories.
 

·
Registered
Joined
·
5,071 Posts
How else do you expect to gain communication with the vehicle ? The interface tool plugs
into the DLC and communicates with the PC on a point to point network.
Yes, but you mentioned "wireless". IMHO a "wireless" connection that you have to plug in kind of defeats the purpose of it being "wireless".
 

·
Registered
Joined
·
1,001 Posts
Yes, but you mentioned "wireless". IMHO a "wireless" connection that you have to plug in kind of defeats the purpose of it being "wireless".
The car is not wireless. The scan tool interface is wireless. Put the brakes on!
 

·
Registered
Joined
·
390 Posts
The car is not wireless. The scan tool interface is wireless. Put the brakes on!
The car does have a wireless AP, if I am not mistaken. Apart from the security issues you had to address, the thought that you could use this AP to access ECUs in the car, without the need for an additional wireless-to-car adapter, is not a stupid idea perse ;)

As a matter of fact, my car has an AP and I can (for example) initiate pre-conditioning of my car via an Android App that is connected to the cars AP. The little module that implements the AP is connected to the CANBUS in order to be able to send command to the A/C unit.
 

·
Registered
Joined
·
390 Posts
Yes, but you mentioned "wireless". IMHO a "wireless" connection that you have to plug in kind of defeats the purpose of it being "wireless".
Well, if you can plug in a little adapter into the port and then sit behind a nearby desk with your laptop to do your work, rather than sit in the passenger seat with a laptop in your lap (hang on, that is what they are there for :D) that does have added value.

A couple of years ago, my car broke down. A service truck showed up and the service guy plugged in a wireless adapter and did most of his work from within the cabin of his truck.
 

·
Registered
Joined
·
390 Posts
It's the 14 volt module that controls charging for the 12 volt DC BECM. It's controlled separate
from the rest of the cars networks. We are network restricted due to the high amount of bus control systems. We currently have 5 data bus systems. I can only guess they setup this 12 volt charging system on it's own to simplify things.
My current car, which is a plug in hybrid, has the same 'issues'. I can identify 7 different busses, 3 of which are high-speed 500 kbps busses. But they are all connected through gateways. The gateways let some traffic pass and some other not, in order to keep the amount of traffic on each bus within limits.

Normal question / response ODBC requests are always let through by the gateways, so I can access each ECU via the main DLC port. But when I want to monitor traffic that is broadcasted by various ECUs I typically only see the data from the ECUs that are on the same bus as the DLC port (which happens to be the bus that controls most ECUs common to petrol cars). In order to be able to capture data broadcasted by the ECUs of the E-motors, the generator, the OBC, BMU, etc., I had to install a second DLC port on one of the other high speed busses. And that works just fine, using the same type of OBDC adapters.

Where I got confused is where you said both ports have the same power supply, yet one is specifically for a 14 volt module. Also, I thought it was a bit odd that on one hand you recommended not to plug in a standard OBDII adapter into the second port, while on the other hand you think it is a good idea that both ports used the same form factor.

From what I understand now, the second DLC port is a 'normal' DLC port where some of the free pins are used to support a very specific device. Does that make sense?

Would this device perhaps allow you to operate the 12 v DC BECM and recharge the battery even after the 12 volt battery is completely flat? Because IMHO that might explain why you want to have the 12 v DC BECM on a separate network.
 

·
Registered
Joined
·
151 Posts
With the standard OBDII port by the steering wheel, you can plug in a standard Bluetooth or WiFi OBDII reader and get some useful information out of the car, like SOC, kW draw from the battery, how much power the electric motor is pulling, or putting back into the battery, read diagnostic trouble codes, and reset the check engine light among other functions.
Does anyone here try that, ?? device and ?? apps ?? Any suggestions pictures...
 

·
Premium Member
Joined
·
787 Posts
Does anyone here try that, ?? device and ?? apps ?? Any suggestions pictures...
I'm using the the LE Link low-energy Bluetooth reader with EngineLink software for iOS. Available from amazon.com:

[ame]https://www.amazon.com/dp/B00QJRYMFC[/ame]

This reader can also be used on Android devices with the Torque Pro app.

The Volt PIDs can be used as a starting point to start reading data. Obviously not all of the Volt PIDs will give you any useful data.

Here's an example of data I read using the EngineLink app while doing a fast charging session:

 

Attachments

·
Registered
Joined
·
14 Posts
EngineLink and TorquePro look like a start, but it sounds like I need access to the PIDs for data fields in order to see anything useful.

Looks like I need to hope/wait for someone to do something like the My Green Volt App for the Chevy Volt (which has cool graphics and Volt specific data).
 

·
Premium Member
Joined
·
787 Posts
EngineLink and TorquePro look like a start, but it sounds like I need access to the PIDs for data fields in order to see anything useful.

Looks like I need to hope/wait for someone to do something like the My Green Volt App for the Chevy Volt (which has cool graphics and Volt specific data).
A lot of the PIDs are available for the Bolt, just derived from the Volt ones.
 

·
Registered
Joined
·
64 Posts
For our Nissan Leaf there was a great smartphone app to see deep into the battery and other settings with a bluetooth OBD.

Has anyone had any luck with an app and plugging in a OBD into your Bolt? If so, name the app used.
Not sure where you are located but I just signed up to fleetcarma's "Charge the North" program here in ontario, canada. I got a free module to plug into the OBD port and i can see all the data online in a portal. its pretty neat.

fleetcarma may have something for the U.S. if you want to look into that.
 

·
Registered
Joined
·
151 Posts

·
Registered
Joined
·
124 Posts
I'm using the the LE Link low-energy Bluetooth reader with EngineLink software for iOS.

Here's an example of data I read using the EngineLink app while doing a fast charging session:
SOC (usable) is interesting. Which SOC number matched what is reported on the dash?
 

·
Premium Member
Joined
·
787 Posts
Why taking this one instead of cheaper you can get on eBay???

http://www.ebay.com/itm/ELM327-OBD2...hash=item1a2b444ac9:m:m7H1hMYq_WRU8MTVnFZa9Lw

I found millions of different model at different prices. Which one is better for the Bolt??

And what is the PIDs??
The Low Energy one is, well, low energy, so I can leave it plugged in all the time. Also, the device is approved for use with Apple devices and has a higher degree of security than Bluetooth 2.0 devices. The one that you listed may not have gone through the qualification steps to be used on iOS devices.

The PIDs are the specific bits of data that you are requesting from the car's computers. Standard ones are like RPM of the ICE, coolant temp, throttle position, incoming air temp, estimated MPG, etc.

In order to get non-standard things like State of Charge (SOC), charging current, electric motor current draw, battery pack voltage, you have to define custom PIDs that can request that data and display it. Through trial and error, and probably access to the service manuals, it's possible to figure out where to look for the data and how to interpret and display the results. Generally a manufacturer that creates their own custom PIDs tend to reuse them across their entire model lineup. While a bunch of the Volt's PIDs don't work on the Bolt, a large number of them do, like SOC %, pack voltage, pack current draw, etc. You can edit the file that the software uses and remove the non-Bolt ones so you don't see weird data.
 

·
Premium Member
Joined
·
787 Posts
SOC (usable) is interesting. Which SOC number matched what is reported on the dash?
The SOC (Usable) PID is from the Volt, and represents the usable portion of the pack, not the whole pack. I'm not sure how well it is suited for the Bolt. Sometimes the the number is the same as the SOC reported by the app and the charging station, and sometimes it's off by more than 10 percentage points in either direction. I've seen it show -16% when SOC was 5%, and 114% when SOC was 96%. The SOC reported by the myChevrolet app and the station would only vary by 1 percent. I suspect there was rounding going on, and those are probably accurate enough.

I need to sit on a fast charger again and take more detailed notes on things.
 

·
Registered
Joined
·
151 Posts
The Low Energy one is, well, low energy, so I can leave it plugged in all the time. The one that you listed may not have gone through the qualification steps to be used on iOS devices.
Anyone of them, even they are not low energy, will not cost to much power, 12V at maybe 0.5 amp.. But for iOS I know you're limited, but for Android can be good??
 

·
Registered
Joined
·
1 Posts
I am building a small ESP32-based CAN bus scanner which can currently capture all the messages seen on the OBD2 main CAN bus.

Are there any hints on where to start? I am also likely to write a scanner which will query the three or four main devices I see talking, and make a list of what they return if I know, and ask the community what they may be if I don't.

Does anyone know if sending a mode 22 request to pretty much anything is dangerous in any way? From my understanding, mode 22 is a query, and I'll get back a mode 62 response with the sub-id queried and the results. It also looks like each query is 8 CAN message bytes long, but the actual length is encoded in the mode 22 request. Strange to me, as it's wasteful, but I'm happy to follow the standard, should there be one there.
 

·
Registered
Joined
·
390 Posts
I am building a small ESP32-based CAN bus scanner which can currently capture all the messages seen on the OBD2 main CAN bus.

Are there any hints on where to start? I am also likely to write a scanner which will query the three or four main devices I see talking, and make a list of what they return if I know, and ask the community what they may be if I don't.

Does anyone know if sending a mode 22 request to pretty much anything is dangerous in any way? From my understanding, mode 22 is a query, and I'll get back a mode 62 response with the sub-id queried and the results. It also looks like each query is 8 CAN message bytes long, but the actual length is encoded in the mode 22 request. Strange to me, as it's wasteful, but I'm happy to follow the standard, should there be one there.
Not just 22. For example, 21 can be a query as well. And then the response will start with 61. Simply 0x40 higher. The length is in the response, not in the request. Unless the response is a multi frame response. Been very useful to me.

Have you had a look at https://www.elmelectronics.com/wp-content/uploads/2016/07/ELM327DS.pdf? This doc has been very useful to me.
 
21 - 40 of 86 Posts
Top