Evoscan Navigator in Evo X? Yes please !!!
Jul 18, 2010, 08:38 AM
#151
Evolved Member
iTrader: (1)
Join Date: Nov 2009
Location: Omaha, NE
Posts: 1,456
Likes: 0
Received 0 Likes
on
0 Posts
Not to throw more work your way... but anyway to have data items log when on some screens, but not log on others. The idea being that you don't have to have 10 items read from the ECU (which slows it down) when there are only a couple of things on the screen that need to be displayed.
Jul 19, 2010, 05:18 AM
#152
yeah I thought of that, but I wanted to be able to still log some items to the csv log even though I only see a few of them on the screen at once. by changing the priority in your data.xml you can speed it up this way. i.e set barometer to priority 9 etc. and fuel trims to 9 etc.
Jul 19, 2010, 08:39 AM
#153
Evolved Member
iTrader: (1)
Join Date: Nov 2009
Location: Omaha, NE
Posts: 1,456
Likes: 0
Received 0 Likes
on
0 Posts
Yeah, I've done that.
But with more screens, comes more items to be displayed.
Maybe and interesting feature (and possibly easy to add) would be to have a parameter in data.xml like DisplayOnly = "true" and while it is polling data for the gauges, if it is not going to be displayed on the screen, it will not bother reading it from the ECU.
My Gauge has quite a few items being displayed on it, and the lag is ok, but you can see it. Maybe this is simply due to how fast the Nav can simply update the screen.
But with more screens, comes more items to be displayed.
Maybe and interesting feature (and possibly easy to add) would be to have a parameter in data.xml like DisplayOnly = "true" and while it is polling data for the gauges, if it is not going to be displayed on the screen, it will not bother reading it from the ECU.
My Gauge has quite a few items being displayed on it, and the lag is ok, but you can see it. Maybe this is simply due to how fast the Nav can simply update the screen.
Jul 24, 2010, 01:24 AM
#154
yeah good point, I already have some options to get optimal speeds; but another option wouldn't hurt 
Using current version of EvoScanPPC for max gauge display performance:
1) Show Readings (untick this for max performance)
2) Save to csv log file (untick this for max performance)
3) Auto Start Logger and Auto Show Gauges (tick these just to make it easier for handsfree)
4) use your pc to edit the data.xml file and set some items to priority="9" or higher for those items you don't care so much about.
5) untick those items on the main screen that your display doesn't use.
I will implement your idea:
1) Gauge Display Only (tick this for max performance, it will force all csv logging and all other dataitem requests being sent to the Vehicle unless it is on the current display gauge)
and you are right, this will be even more important in my next release with all the numbered gauge displays working, different screens will display different sets of information.
what about logging to csv file? I might as well log it to disk, it doesn't take long. the slowest part is the vehicle, unticking the data items that you don't need will have the most positive effect on speed. the gauge display screen updates are very efficient, I hand coded it all. and I used direct kernel drawing APIs for some of them.
Using current version of EvoScanPPC for max gauge display performance:
1) Show Readings (untick this for max performance)
2) Save to csv log file (untick this for max performance)
3) Auto Start Logger and Auto Show Gauges (tick these just to make it easier for handsfree)
4) use your pc to edit the data.xml file and set some items to priority="9" or higher for those items you don't care so much about.
5) untick those items on the main screen that your display doesn't use.
I will implement your idea:
1) Gauge Display Only (tick this for max performance, it will force all csv logging and all other dataitem requests being sent to the Vehicle unless it is on the current display gauge)
and you are right, this will be even more important in my next release with all the numbered gauge displays working, different screens will display different sets of information.
what about logging to csv file? I might as well log it to disk, it doesn't take long. the slowest part is the vehicle, unticking the data items that you don't need will have the most positive effect on speed. the gauge display screen updates are very efficient, I hand coded it all. and I used direct kernel drawing APIs for some of them.
Jul 26, 2010, 02:55 AM
#157
Hi mate, yeah i added your idea as an option to the settings screen called "Gauge Display Only"
Its all working perfectly.. I just have a few other things to tidy up with the new gauge template system. And I'll send you out a copy of the updated version.
Its all working perfectly.. I just have a few other things to tidy up with the new gauge template system. And I'll send you out a copy of the updated version.
Dec 30, 2010, 06:43 AM
#159
Since I'm building EvoScan for iPad & iPhone & Andriod & GPSNav(Windows Mobile), I thought it made sense to put together a Gauge Designer software that can create templates for all 4 versions of EvoScan Mobile Apps. You can download Gauge Designer v1.2 from here: http://www.evoscan.com/gpsnav
Dec 30, 2010, 01:55 PM
#160
Evolved Member
iTrader: (7)
Join Date: Sep 2010
Location: 805-Conejo Valley
Posts: 2,558
Likes: 0
Received 0 Likes
on
0 Posts
Windows Mobile?!? Does that mean I will be able to have EvoScan on my Samsung Omnia II (Windows Mobile Smart Phone), log to my SD Card, and then view/edit it on my laptop!!!??!!
Dec 30, 2010, 09:56 PM
#161
Evolving Member
Screw windows mobile ... ANDRIOD? FOR SERIAL? [southpark refernce not serial plug hehe] Dude that will rock. I assume plugged into the USB? or via a bluetooth adaptor of sorts? What hardware are you designing on right now?
Last edited by Jumperalex; Dec 30, 2010 at 10:03 PM.
Jan 9, 2011, 12:37 PM
#162
Evolving Member
yeah good point, I already have some options to get optimal speeds; but another option wouldn't hurt
Using current version of EvoScanPPC for max gauge display performance:
1) Show Readings (untick this for max performance)
2) Save to csv log file (untick this for max performance)
3) Auto Start Logger and Auto Show Gauges (tick these just to make it easier for handsfree)
4) use your pc to edit the data.xml file and set some items to priority="9" or higher for those items you don't care so much about.
5) untick those items on the main screen that your display doesn't use.
I will implement your idea:
1) Gauge Display Only (tick this for max performance, it will force all csv logging and all other dataitem requests being sent to the Vehicle unless it is on the current display gauge)
and you are right, this will be even more important in my next release with all the numbered gauge displays working, different screens will display different sets of information.
what about logging to csv file? I might as well log it to disk, it doesn't take long. the slowest part is the vehicle, unticking the data items that you don't need will have the most positive effect on speed. the gauge display screen updates are very efficient, I hand coded it all. and I used direct kernel drawing APIs for some of them.
Using current version of EvoScanPPC for max gauge display performance:
1) Show Readings (untick this for max performance)
2) Save to csv log file (untick this for max performance)
3) Auto Start Logger and Auto Show Gauges (tick these just to make it easier for handsfree)
4) use your pc to edit the data.xml file and set some items to priority="9" or higher for those items you don't care so much about.
5) untick those items on the main screen that your display doesn't use.
I will implement your idea:
1) Gauge Display Only (tick this for max performance, it will force all csv logging and all other dataitem requests being sent to the Vehicle unless it is on the current display gauge)
and you are right, this will be even more important in my next release with all the numbered gauge displays working, different screens will display different sets of information.
what about logging to csv file? I might as well log it to disk, it doesn't take long. the slowest part is the vehicle, unticking the data items that you don't need will have the most positive effect on speed. the gauge display screen updates are very efficient, I hand coded it all. and I used direct kernel drawing APIs for some of them.
Is there a way to poll a non-gauge item, like Baro or IPW, without displaying it on the gauges ... other than making it an gauge that blends in with the background and small fonts?
For both the GPS unit and PC EVOScan ... setting Baro to a low priority causes PSIG to not work right because I get a single instance of Baro and then zero's until the next reading. That messes up PSIG readings since it is evaluated using Baro. So is there a setting I'm missing that tells EVOScan to store/repeat a low priority reading in between polling?
Oh and what about still allowing logging even when using Gauge Display Only? I have a few templates for different tuning jobs and it would be very nice if the logged parameters tracked with my template selction. Right now, it seems, that I have to turn off Gauge Display Only and then manually changed the items to be logged to match my gauges Does that makes sense?
Jan 11, 2011, 04:47 PM
#164
Evolving Member
Here is a question for you ... about how fast can the unit realistically response when updating the screen for say a single boost dial gauge? Do I gain anything by only polling one parameter or can the units screen only update so fast? Ignoring the actual LCD screens refresh rate as an obvious limitation.
And yeah it would be really helpful if low priority parameters could be written and used in evals even when not being actively polled, thanks.
Jan 12, 2011, 12:31 AM
#165
oh yeah, the EvoScan GPS unit is capable of drawing very very fast, so its the openport and the vehicle slowing it down. yes you can log just a single boost gauge. and it will be super fast.
yeah I'll look into "low priority parameters be written and used in evals" as far as I know it is already written, if its not in the evals, chances are its not being written, but I will double check.
yeah I'll look into "low priority parameters be written and used in evals" as far as I know it is already written, if its not in the evals, chances are its not being written, but I will double check.