Search results

Not super impressed with the bugs I'm running into so far with SwiftUI on macOS. There's a fun one where sheets always animate twice on dismissal (radar filed). Got a somewhat half-decent version of the vehicle scanner onboarding sheet working now though:

Oof it looks like the navigation stack isn't super well loved on macOS. Will have to explore a few options for actually building out settings because this isn't great.

Very quickly seeing why Apple decided to redesign the settings UI in the latest versions of macOS: the old tab style doesn't really let you reuse any of the drill-down navigation code already written for iOS. Going to pivot this over to a sidebar UX to handle that.

Neat! SwiftUI has an easy way to wire up Settings so they work in a standard way. Now to quickly shuffle this around to use a tab view...

Sidebar working now. Definitely a good amount of work ahead here. Maybe I should just keep it as an empty window ?

Hah! A fair bit of work ahead to tune the platform-isms :)

Got tired with deploying to the iPhone to test the bluetooth functionality, so I flipped the bit to enable Sidecar to run as a Mac app :D After an hour or squashing macOS build errors the app is showing a window!

Which OBD dongles are folks using btw? I'm trying to order one of each of the common ones to make sure the app works well with a variety of devices.

WIP onboarding screen for the vehicle scanning feature:

Haha yeah I need to work on getting more reproducible mockups of the app ? I've started working on a Figma kit for the app's emergent design language but it's admittedly not been a priority yet.

Working on my pitch deck again for the app; thoughts on this cover slide?

From the latest trip data I'm now seeing something interesting: only the first three bytes of each cell are now populated, with the remainder being zero'd out: [2024-01-15T22:21:36Z] module 1: 83 9d 9e 54 00 00 00 00 9d 94 54 00 00 00 00 9d 94 54 00 00 00 00 9d a8 54 00 00 00 00 9d 76 54 00...

Trip photo from today ?

The ranges are helpful! It does seem like each module only reports 6 cells instead of 12. Cell voltage + state of charge both seem correct in terms of interpretation, but still playing with interpretations of the remaining bytes in each cell block.

Uploaded the raw trip data to a public Google Sheet here: Looking at the data over time it seems like my original interpretation wasn't fully accurate. Playing with a few other interpretations but some of the voltages seem to represent a min/max value, though the voltages don't really make sense.

Got tons of data from the drive, now charging at an EA and got some frames from that as well. Should hopefully get to the bottom of these mystery numbers today :) Btw I turned down the live notifications server because kubernetes was nothing but a headache. I’m going to spin up a simpler server...

It looks like I'm forced to go take a road trip through the mountains now and monitor these cell.unknown values to see if/how they change over time ?

Interestingly the `cell.unknown` parameters seem to be consistent across the entire battery pack in a given snapshot, but the values *do* change over time. Last night I was getting the following cell.unknown values: 4a, 6e, 78, 6e, 5a, 64 And today: 48, 4c, 42, 4c, 2e, 4c So all of the...

Command range is 0x221850...0x221870 for modules 1-33 inclusively. Trying a few other exports of data, seeing some new patterns emerge. When I take an instant snapshot of every module I get the following nice grid: module 1: 83 90 42 35 41 43 44 48 90 38 35 90 56 35 4c 90 2e 35 90 4c...

Not yet, but will look into it! Latest update on the battery readouts, feeling decently confident in the decoding of the voltage and SoC % for each cell. // module 1: 83 91 6e 38 41 45 45 4a 91 64 38 91 6e 38 6e 91 50 38 91 5a 38 78 91 64 38 91 5a 38 6e 91 32 38 91 64 38 5a...