Adding data display to Bolt EV with UltraGauge MX

UltraGauge MX (bottom center) shows various info next to the iOS 14 CarPlay screen (right)

To keep a detailed log of the Bolt EV's battery status, I've been using a Bluetooth OBD-II adapter that connects to a smartphone for the past two years. While it worked well, I wanted to have a permanent display showing the data and installing an iPhone to do so seemed to be an overkill. So I searched for dedicated "gauge" units that allowed for customization and narrowed the selection down to ScanGauge 2 and UltraGauge MX. The former allowed for more custom data (25 PIDs vs. 8), while the latter had a bigger screen (8 lines vs. 2). I ended up with the bigger screen.

With the device at hand, I had to find a way to program it to display Bolt EV-specific data using the existing custom PID information, and then install it on a place where it is both easily visible and properly shaded. After a bit of work, I was able to fulfill all of the objectives, as you can see in the photo above. The first page shows the actual vehicle speed, accelerator pedal position, various battery information including State of Charge (both raw and displayed), usable capacity, and temperature, as well as current trip distance and 12V battery voltage. Let's see how this was done.
First boot-up of UltraGauge MX

Initially, UltraGauge detects how many of the 60 standard OBD-II PIDs (Parameter Identifications) and 28 self-calculated data it supports are available on the car. Because Bolt EV does not have an internal combustion engine, most of these are irrelevant and unsurprisingly unsupported. Of the 20 said to be usable as shown here, only 7 of them are standard PIDs and none are related to monitoring the high-voltage propulsion battery.
PID # Description Unit
010D Vehicle speed km/h
0121 Distance driven with CEL (Check Engine Light) on km
0130 Warm-ups since TC (Trouble Code) was cleared Count
0131 Distance driven since TC was cleared km
0142 ECM (Engine Control Module) 12V Battery Voltage V
0146 Ambient Air Temperature °C
0149 Accelerator Pedal Position 1 %
So I had to devote all of the eight custom PID slots available for this purpose. The problem is that the screen for configuring them (MENU - Gauge/Page Menu - Select Gauge/Page - M Gauge Setup) looks like this:
MGauge programming screen for slot 1

And it's not easy to make sense of it at first. I needed to translate the information found in an unofficial list of custom PIDs for Bolt EV into this format. After reading the UltraGauge MX programming supplement and researching the CAN Bus protocol, I was able to do just that. For these PIDs...
PID # Description Unit Formula
228334 State of Charge (Displayed) % A × 100 / 255 + 0
015B State of Charge (Raw) % A × 100 / 255 + 0
2241A3 Battery Capacity (for 2017-18 Bolt) kWh A × 999 / 31250 + 0
22434F Battery Temperature °C A × 1 / 1 - 40
22436B HV Charger Voltage V A × 1 / 2 + 0
22436C HV Charger Current A A × 1 / 20 + 0
22437D Last Charge Amount kWh A × 1 / 100 + 0
2241B6 Battery Heater Power kW A × 1 / 1000 + 0
I programmed UltraGauge like this:
# Abbr1 Abbr2 TData TCtrl RCtrl RPos Mtch X / + Out Ave L/R
1 SoC D % 07E4228334 93 31 2008 628334 0064 00FF 0000 00 00 32
2 SoC R % 07E0015B 92 21 1808 415B 0064 00FF 0000 00 00 32
3 Cap kWh 07E42241A3 93 31 2010 6241A3 03E7 7A12 0000 00 00 22
4 Bat °C 07E422434F 93 31 2008 62434F 0001 0001 FFD8 00 00 30
5 Chg hvV 07E422436B 93 31 2010 62436B 0001 0002 0000 00 00 32
6 Chg hvA 07E422436C 93 31 2010 62436C 0001 0014 0000 00 00 32
7 Chg kWh 07E422437D 93 31 2010 62437D 0001 0064 0000 00 00 22
8 BHt kW 07E42241B6 93 31 2010 6241B6 0001 03E8 0000 00 00 13
You can see that TData is composed of the header and the PID. The header specifies which ECM the data should be coming from and there are at least eight of them (E0 to E7) on Bolt. The numbers used in the formula are entered in hexadecimal, as with other inputs. After making sure that the programmed PIDs were working as intended, I went ahead with the permanent installation of the device.
Continue reading "Adding data display to Bolt EV with UltraGauge MX"

Excessive cellular data consumption in iOS

Documents & Sync consumed 6.6GB of cellular data on my iPhone last month

I usually use somewhere between 5 to 7GB of cellular (mobile) data per month on my iPhone because my data plan gives me 6GB and I make sure not to go over too much. But since last December, I started to notice an unintended, excessive data consumption which caused my monthly usage to hover around 9 to 12GB until April. It then subsided for a while, but it came back last month. I didn't want to pay the carrier more than what I actually used, so I decided do something about it.

The root of this problem has been pinpointed to "Documents & Sync" activity under "System Services" category from fairly early on. You can see that it consumed 6.6GB of data by itself last month, out of 11.51GB total. The difficult part was determining what exact services were causing it, since there were many iOS features depending on synchronizing data and documents to iCloud. After much trial and errors, I was able to find two of them which caused most, of not all, of the issues.

Disabling Photos and iCloud Drive from using cellular data solved the overuse

One was the Photos app using the data connection to update Shared Albums and iCloud Photos. This was a bit strange because I have disabled iCloud Photos and my Shared Albums see barely any activity. Still, it had caused a burst of data consumption from time to time, spending up to nearly 1GB in about 10 minutes in the worst case and making the phone hot in the process. After disabling cellular data option within the Photos entry in the Settings app, these bursts were no more.

The other was the iCloud Drive. When I disabled its cellular data use by using the option buried at the bottom of the Cellular entry in the Settings app, the remaining excess usage stopped. Come to think of it, the data consumed during normal use, be it using the camera, browsing the internet, or interacting with the social media, was roughly twice the previously normal level. So whatever I did, the iCloud Drive was trying to sync some undetermined data in parallel, even though I had no intention of letting it do that. The available space in the Drive did not change, so I would guess it was some sort of system-level stuff.

By the way, the Internet searches I did while trying to fix this problem revealed that a lot of people had similar experiences, but with slightly different solutions. Some people had success by adjusting settings related to iMessages or Keychain, to name a few. So my solution may not be definitive for everyone and you should treat it as a starting point.
Defined tags for this entry: , , ,

Copyright (C) 1996-2024 Woo-Duk Chung (Wesley Woo-Duk Hwang-Chung). All rights reserved.