OBDX Development - Developer Tools and Suggestions

[antus]

you might need to look at the exception and see what its saying. it might be trying to protect you from data in a transient state, but in this case it doesnt matter if the data is old or new. there might be some keyword or syntax just to ignore it, or there might be something else going on that needs a specific approach to work around.

[Tazzi]

you might need to look at the exception and see what its saying. it might be trying to protect you from data in a transient state, but in this case it doesnt matter if the data is old or new. there might be some keyword or syntax just to ignore it, or there might be something else going on that needs a specific approach to work around.

Yeah, kinda like that.
Basically any UI elements need to be updated on the main UI thread otherwise it results in a crossthreading error. This was not saying 'cross threading" error, but it basically was the same thing.
The data source that the graphs are bound to are instantly updated when I add any new data to the lists, which when added on the background thread results in accessing the background and main UI threads clashing to cause a windows fault (I cant even catch it with a try/catch!!).

When invoking the charting to update on the main ui, this results in the data lists to be updated without the error since its now operating on the same thread the actual graph elements update on.

Anyways, problem removed, on bench, it looks like its working seemlessly but in car, we have a little bit of lag on the main graphing display.
The dash display graph seems to be pretty instant, whereas the dedicated graph page still seems to have a little bit of lag.
There should be no difference between the two different charting displays thus both should be instant, I know the size of the chart isnt the problem so its likely a simple 'lock' I have somewhere which is causing a brief hold up, or possibly a chart refresh I have placed which is causing double the processing.

Either way, we have made massive progress!

Something else I will need to look into is making fixed X axis timeframe so that all the charts axis are matching, this will also improve efficiency.

[Tazzi]

I honestly have been too spoilt using a high end PC for my development. Back in the day I use to work on a single screen, low end laptop... which forced myself to write code that dealt with low end PCs.

When logging on the E38's, if you select enough PIDs, the logging rate goes up to 120frames/s. This is ALOT.... considering theres 4-6 parameters per frame, this means theres potentially 480-720 updates updates to screen per second.

Even though my desktop can keep up, my poor laptop is just not coping (Even though that has the latest gen i7 intel in it!). The reason I know its the charting slowing it down, is I have now moved the X axis to a timer, where it moves on a smooth timeframe which all X axis's now copy. This reduces the processing strain of the charting elements, but even so, the actual live data lines start lagging behind and eventually fall off of screen, this signifies it is taking too long to add/draw each element to the charts.

Anyways, currently we have implemented the following:
1) GUI updates that run on a background thread. Main thread is processing received frames.
2) Timer implemented that only updates the screen elements every 50ms. When this timer hits, it will process ALL received frames during that time in a loop.

New things I have tried to fix but were not suitable:
1) I enabled a "Direct X" processing ability of the UI elements, but this made the laptop crash trying to use it. It was meant to help with performance, but, appears to kill the laptop when opening graph view.
2) Disabling painting of the UI elements until all new updates are added to their lists. This did improve performance, but resulted in heaps of flickering from the charting.

So... we are now back to the drawing board to solve this, I believe the only last ideas I can think of are:
1) Add a timestamp for each variable update, and limit displaying to screen for every 24-50ms. This means when processing 120frames per second, it will only updates a handful of times. This will mean less data points on a chart, but should still be very smooth.
2) copy the graph 'lists' to an external data list. Then add the new data to these lists, and finally bind the new lists to the charts. This will prevent the charts from updating when I add each point at a time.

Im going to try option 2 first. I feel this *should* give quite a performance boost. Since technically it will be adding 50ms worth of data to the lists in one hit and the page should repaint only once.

I do understand that most tuners don't always monitor the live data while driving, and simply review it later. But there are some circumstances where seeing the data upfront while on a track or otherwise is important... so we are making this work!

[Tazzi]

200+ alterations later... and we are working on the laptop while in car.

Due to the speed of the desktop, it would update the UI fast enough the it was finalized before the live data was trying to be put to screen. But on the laptop, it would receive live data before the actual graph element had even finished displaying to screen! This took (Way) longer then expected to figure out which resulted in it crashing the application with a Microsoft error which couldn't even be caught.

Our solution has been to just update the variable as soon as it comes through, but only apply to the GUI display including graphs ever 50ms. This could probably be reduced, or at least made variable for people to mess with for higher end PC setups, but for now this works good enough for me!

Going to go grab a video of it in car so I can upload something to youtube.

[Tazzi]

Just update the youtube page with a quick demo: https://youtu.be/Xt5ulTN-1g8

Yes I do sound exhausted, since its been a (very) long few days getting OBDXplorer to the stage it is!

[In-Tech]

Neat

[antus]

sounds good, nicely done

[Tazzi]

Thanks lads!
Moving forward, last box of GTs are almost with Pete so the GT will be released shortly (finally).
With that said, there will be some new additions to OBDXplorer once I get some feed back. Will move to enabling the histograms and replay features

Next on development while waiting though is a fresh project with Maui for cross platform smartphone apps. I did spend several hundreds of hours developing with Xamarin so I do have experience with crossplatform development, but during this time Microsoft made the announcement of phasing out Xamarin in favor of Maui, so this best to stay ahead of the curve and move to the latest development.

I am hoping MAUI will be a hell of alot easier to start with compared to Xamarin, since that was an absolute nightmare. Trying to use platform specific peripherals (Bluetooth on Android, BLE on iPhone) head banging painful.

Three applications will be on the list for development:
1) OBDXplorer For iOS/Android
2) NVS Flasher
3) NVS Diagnostics

First is just a smartphone version of the OBDXplorer.
Second and third are Envyous Customs applications, basically to make a programming app to allow doing everything I do, and a diagnostics app for the Holdens. Even though the last two arent OBDX apps, they will be exclusively using OBDX tools, plus I will likely use their code snippits in example apps for a developer corner on OBDX Pro.

[Tazzi]

I can safely say I prefer Maui over Xamarin. They certainly have fixed up multiple things.

Although I have a bit of a worry about bluetooth support on both iOS and Android, since I keep getting warnings basically telling my I need to target (Very) new operating systems which blocks out 80% of devices. Even my android phone doesn't run on android 12, so.. technically it shouldn't be possible to use.
In saying that, it appears its related to permissions, so I have added all required permission to make it happy. Nothing actually pops up on my android phone about permissions, but I would guess it will on newer phones for bluetooth access/location ect which is all part of the same system.

The next concern is if a user does deny it, then trying to actually check it in code which doesn't seem to be all that simple. Under certain circumstances, it appears the user can dismiss permanently so even if I prompt to enable the access to the user, its instantly hidden and declined due to previous decisions, meaning this would have to be changed in phone settings. I guess the worst case scenario is a basic video guide showing how to give the app permissions if previously declines... no big deal I suppose.

I am yet to do any testing on my iPhone, but the BLE implementation is all setup and ready for it. Assuming this works for the android, it should work for the iphone since the only difference is selecting a BLE device instead of the classic android. I can also target ble for android too if wanted which may actually be a good solution too, requiring no actual paring of the device.

[hjtrbo]

Is it poss to do what to some apps do. When you deny a required permission it just exits out of the app. Brutal but effective.