PHEV Watchdog for all.

[Kim]

Can we see the total run time of the ICE somewhere via OBD?

 

[GreyBigFoot]

Not to my knowledge.

But I'm looking forward to get to version 1, so I can have some spare time to do some serious data mining over the OBD interface and extract more valuable info.

 

[elm70]

Not to my knowledge.

But I'm looking forward to get to version 1, so I can have some spare time to do some serious data mining over the OBD interface and extract more valuable info.

Are you also considering to send code to the PHEV .. for change some setting ?

Per Vtech it is possible to change the amount of power from Battery to motors .. default is 60kw .. but this can be increased .. Vtech tested up to 110kw ... for me it will be nice to change this up to 80kw or 90kw .. for have less risk to start the ICE by accident

Also ... it should be possible to define at which SOC ICE should kick in ... that is 26% and 30% ... since 30% is consider over 3.80v ... I feel these value could be lowered a bit .. allowing extra EV range at no risk to damage battery

Another nice code to send .. is the one that state error on fuel pump .. or error on starting the ICE ... this enable pure EV mode .. like when we take out the fuel pump fuse from the car ...

 

[anko]

Keep in mind, Vtech did not just send some OBD codes, he (completely) reprogrammed / flashed one or more ECUs.

 

[GreyBigFoot]

Not to my knowledge.

But I'm looking forward to get to version 1, so I can have some spare time to do some serious data mining over the OBD interface and extract more valuable info.

Are you also considering to send code to the PHEV .. for change some setting ?

Per Vtech it is possible to change the amount of power from Battery to motors .. default is 60kw .. but this can be increased .. Vtech tested up to 110kw ... for me it will be nice to change this up to 80kw or 90kw .. for have less risk to start the ICE by accident

Also ... it should be possible to define at which SOC ICE should kick in ... that is 26% and 30% ... since 30% is consider over 3.80v ... I feel these value could be lowered a bit .. allowing extra EV range at no risk to damage battery

Another nice code to send .. is the one that state error on fuel pump .. or error on starting the ICE ... this enable pure EV mode .. like when we take out the fuel pump fuse from the car ...

No, sorry. Hacking is a whole new level and I'm not into it. Specially not wanting to use my car as guinea pig (to expensive for that).

This app only reads data from the interface and I want to keep it that way.

 

[drdel]

I'm having difficulty finding a download link for this app?

 

[pasquinade]

I'm having difficulty finding a download link for this app?

Facebook group:

https://www.facebook.com/groups/152278275319772/

If you don't have a facebook account, here's a direct link to the latest version (8.1):

https://drive.google.com/file/d/0BwtieZzWGqeWSU1KaFIwbTBTRmM/view

 

[drdel]

I'm having difficulty finding a download link for this app?

Facebook group:

https://www.facebook.com/groups/152278275319772/

If you don't have a facebook account, here's a direct link to the latest version (8.1):

https://drive.google.com/file/d/0BwtieZzWGqeWSU1KaFIwbTBTRmM/view

Thanks.

 

[GreyBigFoot]

It's been missing a presentation video but finally here it is

https://www.youtube.com/watch?v=uulN-LJdLjI

Cheers.

 

[elm70]

After moving from 0.7 to 0.8.1 .. now the live data stop after few minutes .... before I was able to keep over 30min live data connection .. now it is breaking all the time after 5 min or so ...

The Trip function is the best part of the app .. but does not look reliable with my HW

 

[GreyBigFoot]

After moving from 0.7 to 0.8.1 .. now the live data stop after few minutes .... before I was able to keep over 30min live data connection .. now it is breaking all the time after 5 min or so ...

The Trip function is the best part of the app .. but does not look reliable with my HW

That's because v0.7 didn't validate any of the data received from the adapter.

Which adapter are using?

From the symptoms could be one that is very slow to handle the requests. If so, try to slow down the "Dog", there's an option for that in the Settings menu.

Cheers.

 

[elm70]

I'm using OBDlink LX, which is supposed to be one of the best ... but maybe the Bluetooth version is a bit slow .. or maybe is slow since my phone is both connected on the CAR audio system and to the OBDlink on Bluetooth ...

Anyhow ... I was using the default setting on "Often" .. and now I changed to "Regularly" .. assuming this is what I have to change for workaround the problem.

I think data validation is good, but to terminate the "Start Live Data" due to an error is a bit "hard" .. why not trying to keep the stream open and adapt the code (that could mean just ignore invalid data , and/or restart the communication )

From user point of view, once the "Start Live Data" is set on, this should be on, until the user manually terminate it , else it is not a reliable feature

Thanks again for your great app

 

[elm70]

Tested with "Regularly" ... got up to 7min recording before it stop the "Live data Trip" ...

I guess this abnormal disconnection from Live Data Recording .. is something it could be improved

 

[GreyBigFoot]

Sorry, doesn't works like that.

In order to have accurate values it's crucial to have the data fed consistently.
The "Dog" will not stop at first error, it will actually take 5 failed responses to stop "live data".

I am using myself an OBDLink LX adapter since day one with not a single issue in 13.000kms, so assuming yours is not malfunctioning I can only point that the problem is neither in your adapter or the app, but in connection from your mobile device to the adapter.

I might put the threshold failure value available as an option in settings, but increasing above the current value will surely affect the stats, so in then end it should be a matter of how accurate you want the data to be.

 

[elm70]

Sorry, doesn't works like that.

In order to have accurate values it's crucial to have the data fed consistently.
The "Dog" will not stop at first error, it will actually take 5 failed responses to stop "live data".

I am using myself an OBDLink LX adapter since day one with not a single issue in 13.000kms, so assuming yours is not malfunctioning I can only point that the problem is neither in your adapter or the app, but in connection from your mobile device to the adapter.

I might put the threshold failure value available as an option in settings, but increasing above the current value will surely affect the stats, so in then end it should be a matter of how accurate you want the data to be.

In my view ... better some data with some "error" .. then no data at all. But since you have a check about error data, it is only about having less data in the stream since some data are rejected since malformed.

Also ... I don't get: the stream of data will be working again if I click again on the "start live data", why don't make it automatically restarting (or better, if was not be stopped in first place) ... if I don't click on stop live data, I don't want that an error can stop my trip recording ... and I don't want to monitor even if an error happen.

About your counter .. it is 5 consecutive errors .. or 5 errors in total ? I would consider only consecutive errors , which should lead to a re-initialization of the live data stream

 

[GreyBigFoot]

Sorry, doesn't works like that.

In order to have accurate values it's crucial to have the data fed consistently.
The "Dog" will not stop at first error, it will actually take 5 failed responses to stop "live data".

I am using myself an OBDLink LX adapter since day one with not a single issue in 13.000kms, so assuming yours is not malfunctioning I can only point that the problem is neither in your adapter or the app, but in connection from your mobile device to the adapter.

I might put the threshold failure value available as an option in settings, but increasing above the current value will surely affect the stats, so in then end it should be a matter of how accurate you want the data to be.

In my view ... better some data with some "error" .. then no data at all. But since you have a check about error data, it is only about having less data in the stream since some data are rejected since malformed.

Also ... I don't get: the stream of data will be working again if I click again on the "start live data", why don't make it automatically restarting (or better, if was not be stopped in first place) ... if I don't click on stop live data, I don't want that an error can stop my trip recording ... and I don't want to monitor even if an error happen.

About your counter .. it is 5 consecutive errors .. or 5 errors in total ? I would consider only consecutive errors , which should lead to a re-initialization of the live data stream

There is no such thing as some "error"... The app will not account any malformed data, that's why it validates what it gets from the adapter.

Less data means less accuracy and that can be disastrous when you are inferring data (and there is a lot of that in the app, and that's what makes it interesting).
By closing the live stream the app makes sure that the data collected for the segment is solid and consistent, that's why it works that way.

Obviously 5 consecutive errors.

 

[elm70]

For me it is a better to get a measurement with an error (ideally would be nice to have the measure + the error level) .. then don't have any measurement at al

For example ... if I want to know how big is my garden ... I like to know that is 123m2 with 50% error .. then don't get any result / estimation

And this is the same as when I kick "Start Live Data" ... if this stop after 20% of my trip or even after 10% of my trip ... I may get precise value for the small time frame .. but I get no result at all for the entire trip .. and a partial result is quite useless

I'm aware I'm not in position to tell you how to make your own application ... but I would suggest:
- Improve the error handling
- Or automatically restart a new "Trip" in case one trip get stopped due to error ...

The first option implies to have "not so pure data" in the trip
The second option implies to have always "clean data", but to break a single trip into multiple trips

Thanks again for your very valuable application

 

[GreyBigFoot]

Sorry, I won't do customization of the app. At least it's not in my priorities.

I will take in consideration suggestions that are doable and from which I see a real benefit.

Don't see a real benefit on reducing accuracy to workaround a malfunctioning device.

As I said before when producing inferred values it's crucial to have consistent data.
You might not be aware of, but a lot of the info displayed by the app doesn't come directly from the car.
There is not much value on displaying fuel consumption if it's off by 0.5lts or more at the end of the trip...
Or to have regenerated and charged energy wrongly counted.
Those are only a few examples.

I can only say that for the next release there will be:

- New "Resume Live Data" option (not automatic) in the main menu, that's for when you do a long journey with stops and you want to have a single card of the trip.
- New "Autostart" option in the settings menu, that's for starting live data (not resuming) as soon as you open the app.
- New "Merge with previous Trip" option in the Trip List.

 

[elm70]

Sorry, I won't do customization of the app. At least it's not in my priorities.

I will take in consideration suggestions that are doable and from which I see a real benefit.

Don't see a real benefit on reducing accuracy to workaround a malfunctioning device.

Totally agree ...

I'm just wondering if my case is special (malfunction on my phone or adapter) or is more common as you may think.

The fact that you have a counters and see errors .. it means you have error also in "ideal" set up.
Also the fact that end user can select how often (or better how much data ) they can stream ... it sounds like you have seen this as a problematic point in the code ... ideally the application should be able to determine how much data can be streamed without having too much errors, without the need to end user selection.

From functional point of view .. if end user ask to "start trip live data" .. this should not be stopped by anything else then end user input .. at least .. this is from my understanding of designing end user experience

I have used EvBatMon application for logging data ... and I did not notice any abnormal termination or missing of data ... but EvBatMon may monitor less data compared to your application

Anyhow .. I have couple of old phones with android that are sitting unused at home .. maybe I will find one that will work fine with your application

PS: Again compliments and big thank you for your excellent application

 

[GreyBigFoot]

I've used EVBatmon for some time and from my experience it does not do any calculations (beside simple conversions) it's just showing data from the OBD2 interface, so no problem there on accuracy... Not the most stable thing also, but that's another story.

The data validation is essentially there to finalize the trip when you forgot to do it after turning off the car (which in my case is every time).
The 5 threshold corresponds to approximately one cycle of data polling, which is what I consider to be the maximum.

Now as for the adapter, unless it has some kind of malfunction you are using probably the best one for the OBD2 interface.

So I would suspect on the device, either a performance problem or a compatibility issue with adapter/device (bluetooth connection).

I should add that as far as I know that's not a common issue.
I think two or three users have reported something similar (losing connection after a while) with the Samsung S series phones and the KW902 adapter.
Clearly a compatibility problem on the bluetooth connection.

Thank you for the compliments, I do appreciate it. It's always good to see your work recognized.