My winter Mustang Mach-E project

[Jiji]

Like it, 92% is what I have been seeing for Level 2 by doing the math.

To be accurate you also need to account for the charging/discharging of the LVB while plugged in. In a perfect world the LVB would be at 100% SoC and the HVB at the set point SoC when you unplugged but in reality the LVB discharges once the HVB set point is hit and might go through multiple discharge/charge cycles while plugged in.

Level 3 is quite a bit less efficient because of battery heating. Small sample size and temp. dependent, but I have calculated less than 80%.

Which is why I included the HVB Temperature in the detailed report, anticipating there will be more movement during a DCFC charge session.

It will soon be time to visit a DCFC site and make sure data collection works and then get a decent session in for a reference cDCFC charge. That and preconditioning are there two states I haven't looked at.

Sponsored

 

[MachTri]

I thought of an interesting algorithm to estimate HVB health. Bin the mi/kWh according to rate of climb (would account for speed and inclination) and ambient temperature. Compare similar bins mi/kWh over time.

 

[Jiji]

I thought of an interesting algorithm to estimate HVB health. Bin the mi/kWh according to rate of climb (would account for speed and inclination) and ambient temperature. Compare similar bins mi/kWh over time.

Interesting idea, one I am working on is to categorize trips by outside temperature, something I was used to when I had TeslaFi. Here is idea of what it would like:

Once you have the data the possibilities are endless, unfortunately the time is limited. Need to sort out a better graphing package first as a picture is worth 1000 words.

 

[Jiji]

Progress on the graphing front, now have integrated a much better graphing package that will open up the display of new visualizations. But here are the new graphs rendered in Charts by Daniel Gindi (GitHub) (scroll back to see the improvement):

X axis is time, 0 is the trip start and if you are sharp you already noticed you can scroll the graph window to view the entire trip.

Right now I have fixed scaling but I'll fix that so the full vertical range the graph is utilized. Lots of new options to explore, left and right Y axes, multiple line plots, and more.

 

[MachTri]

Right now I have fixed scaling but I'll fix that so the full vertical range the graph is utilized. Lots of new options to explore, left and right Y axes, multiple line plots, and more.

Nice work. Overlays would be pretty interesting.

 

[Jiji]

Nice work. Overlays would be pretty interesting.

What's an overlay? Just another variable in the graph?

Here is a snapshot of the speed and power from a trip yesterday. Having both in one graph would make it obvious that the large negative power spike is due to regenerative braking (not that it could be anything else):

I know I can add a y-axis to the right and plot power and speed on the same graph. But I still learning the graphing package and right now I am focused on sorting trips by temperature and distance and visualizing that.

 

[Jiji]

Time to get control of the sprawling code base that grows this way and that as I play around, so today I added a settings tab where you can configure the selection of metric or imperial units in the displays.

Not much to see but it allowed me to simplify the underlying code and maybe there will be some company some day for this lonely toggle switch.

Hard to believe that a month ago I didn't know Swift (the programming language) or SwiftUI (the UI designer), now I have the core of a potentially useful application. If only Apple stopped killing it on my phone after a few days because I am not a $99 developer.

 

[Jiji]

There is a problem with dirty GPS data so time to solve it. I happened to notice maps where I was stopped in gear had unacceptable path overlays like these (leaving the driveway on the left and parking at a store on the right):

When in gear there is one GPS point every couple of seconds and they are spread out spatially but when stopped you have many of them clustered around your location and they lead to weird paths as GPS really isn't as accurate as we think it is. Let's see if there is anything we can do to clean this up.

Being young and naive I was using the raw 64-bit IEEE floating point coordinates returned by Apple, but these can have 10 or more digits after the decimal point which is great because we want to know our position as accurately as possible. But according to the internet (Measuring accuracy of latitude and longitude?), the floating point latitude and longitude delivered by Apple are junk, at least past five or six decimal places:

So I rounded the latitude and longitude to 6 places and even then I saw variation in the fourth digit after the decimal point when parked so still have work to do. My bright idea was to discard GPS coordinates when the GPS speed is zero and the speed of the previous sample was also zero (if we didn't move the last position is good!). Pretty easy to implement and the results are better (driveway on the left, stopping for 5 minutes in a parking lot in the center, ~30 seconds at a stop light on the right):

Unfortunately this is a brute force method lacking scientific rigor (the father two samples are apart the more likely there is a change in position) and I don't know if it really would work in a variety of different situations The MME GPS speed is an integer value in meters per second, stopped is zero and 1 is 3.6 kph (1 m/s * 0.001 km/m * 3600 sec/hr), not really precise in my estimation. The high resolution speedometer has units of 1/128 kph so that is much more precise and perhaps a better source of speed but perhaps there is a more difficult way to do this and that might something called the trackpoint distance threshold method which I found here.

It may be the way to go as the results look promising but there might be other solutions as well to this problem so I shall ponder this as I enjoy some warm, sunny, March weather and think about the positive slope of my km/kWh trend line that the impending spring is forcing upon me.

 

[MachTri]

It may be the way to go as the results look promising but there might be other solutions as well to this problem so I shall ponder this as I enjoy some warm, sunny, March weather and think about the positive slope of my km/kWh trend line that the impending spring is forcing upon me.

From past professional software development projects, I can confirm that dropping repeated GPS samples below a speed threshold is a valid approach. Depending on the device, you may get better accuracy at higher speeds. Android's Location API will correct GPS based on known Wifi APs but that's hit-or-miss depending on if the AP is in their database, hasn't moved and the hardware you are using supports it. We had some indoor applications that were nearly as accurate as outdoor GPS using the Android Location Services. I don't know if Apple does similar.

 

[Jiji]

From past professional software development projects, I can confirm that dropping repeated GPS samples below a speed threshold is a valid approach. Depending on the device, you may get better accuracy at higher speeds. Android's Location API will correct GPS based on known Wifi APs but that's hit-or-miss depending on if the AP is in their database, hasn't moved and the hardware you are using supports it. We had some indoor applications that were nearly as accurate as outdoor GPS using the Android Location Services. I don't know if Apple does similar.

Nice to know but I went ahead and implemented the distance threshold algorithm, made easy by the Apple MapKit calculating the distance between two points, this is the results for a threshold of 4 meters for the two maps the start of the Wednesday post:

The left map is less complicated but there is a reverse K turn in there that I show with the red lines that the GPS is struggling to track accurately. Could be a lack of satellites as the trip starts in a garage - who knows? Actual I think the phone GPS knows as I can get some accuracy data if I needed it,

The right side is cleaner but likely wrong. This trip was to pick up some bird seed at a store and the original path was likely the two left turns into a parking spot which both maps fail to clearly show.

Ultimately the lesson I am taking away is that GPS isn't sufficiently accurate when you wish to distinguish features less than a few meters apart so the displayed maps zoomed in are going to have some artifacts.

 

[MachTri]

Yea. For that kind of accuracy, you typically need AGPS or something like vectornav.com

 

[Jiji]

End of March is here and time to wind this project down. Having more daylight and warmer temperatures means my learning project is coming to a close. But before I do let's dive into using local search to convert our trip start and end points into something more friendly.

Previously we displayed the street information returned by a reverse geocoding lookup of the latitude and longitude and it looked like this:

The trip Start/End were fixed previously but now you see we have a link we can follow and see if there are nearby points of interest (POI) we can use to better identify the purpose of a trip. Selecting the end point of this trip we get a new view with the nearby POIs, one of which might have been the actual destination:

The idea would be to select one of these destinations and save that information back into the trip database as a visit to McDonalds is more memorable than a simple address. Better still you could customize the string bound to the location so you have "Home", "Work", or "Jiji's" used place of an address.

I haven't done all of this yet and may never but the results would look so much better in conveying trip information. This is a concept screenshot I made up to show this nice feature:

And that wraps things up for now. Wishing all a great summer and fun times with your MME.

 

[Jiji]

Brief update.

I have been liking access to my trip and charging data, especially seeing the efficiency go up from spring to summer conditions. Below is a summary of the last weeks drives and trip to a Ford show where I saw the Green Goblin in person.

Of course you can access the My EV driving data in FordPass but you will be disappointed. It measures trips from ignition on to ignition off and there is very little useful information such as the trip start and destination. You do get a brake score so it is not totally lame.

But I get frustrated with the power draw of the Raspberry Pi and Ford will let me know if I left it plugged in so I decided to take a look at the OBDlink MX+ I have as a potential replacement.

If you don't know the programming interface goes way back in time to when Hayes modems were a thing and use the AT command set (OBDlink extends this with a newer ST command set). So I created a small iPhone application to connect to the OBDlink MX+ and start sending CAN bus commands to see if it has the bandwidth to serve as the hardware between the iOS application and the OBD connector.

Well the results are in and they are acceptable, not great but acceptable. The MX+ has a nice method of supporting periodic requests but it only supports one CAN bus and Ford in their wisdom have most of the useful vehicle and charging data on the HSCAN bus but the hi-res odometer (tenths of km resolution) is on the MSCAN bus so this feature seems to be disqualified.

So I see an OBDlink MX+ based project this fall which should open the solution up to others. Should anyone know of a OBD dongle that has an advanced programming interface that allows periodic reads of the HSCAN and MSCAN buses I would welcome hearing about it.

Happy summer driving all!

 

[Jiji]

iOS 16 is now out which now includes SwiftUI Charts, updated my app tonight to start using them. Here I reduced the size of the trip map view and added the trip elevation below it. Makes it easy to see why efficiency is up or down on a particular trip:

 

[Av8tor]

@Jiji Is this available to download?

Sponsored