DataMaster version 1.8.3 released

[Steve Cole]

The new update contains a few new features that we hope will help some of you. When doing Vtune recordings with a remote display you can now change the split location in the histogram. This allows you to make the upper area smaller or larger by "hooking" the horizontal bar and sliding up or down to the size that works for you. We only added this to the recording histogram as that where we thought it might help. We hope this helps on the smaller remote screens. Then for those of you wanting to graph things in 2-d or 3-d plots we add a couple of forms that allow you to graph any data you like. There are a few various graph forms you can select from and this was just things that were already in the graphics package we already use. You can play all kinds of games with the data but it's up to you as to what it may or may not mean. Graphs can be sent to the printer or saved as Jpeg format.

[mayor]

I just posted a new thread about the new features of the Datamaster program, but I'll move that stuff onto this thread and delete that one. 

there's some new features:



so I opened up some old data files and played around:




there's even a 3D chart option:


pretty cool stuff.   

[hrdtail78]

Thanks Steve. That 3D graph is cool looking.

[Thumper Buttercup]

Thanks for the change in recording, being able to slide that up will
help with our small 7" screen.


Mark

[Steve Cole]

Make sure you play around with the Marker size setting as that controls how big the dot that is placed on the graph. Some screens will show better at various size dots and the back round color and grid color can be changed as well in the graphs. On the 3-D graphs you can change the upper and lower limits to give more or less color range to the plotted data. There are a few different 3-D graphs you can choose from but it's all up to you guys to play with it as you desire.

[N-gin]

Very cool stuff. Looks like im going to have to start looking through my old v tunes

[cts1950]

A new face lift with fancy stuff isn't going to help me look at data.  How it is set up know is great.  In GenericO2Data I can can watch everything.  Not only the 6 points I am graphing but a lot more data up top.  I can click one Rec# at a time.  Which is usually 5-6 times a second.  which is about 1700 rec. for 5 minutes.  Sometimes 6 line graphs are too much.  A lot of the time I will only use 2.  Like O2 sensor front and rear.  I don't need a line graph for RPM's.  At any rec# I can look up and see what my RPM's was.  At this same time I can compare my RPM to MAP, Temp, IAT, vehicle speed, VE, spark, BPW.......  To me it is like taking 1700 snap shots and looking at them in order with time and putting the run back together.  The 3D graphs seem to stack the 1700 snap shots and project them all at once on a screen.


It is funny when Steve releases a face lift It is great, but when it is mlv it is not worth looking at how quickly you change your tune.

[whittlebeast]

How do you do custom fields?  Even simple basic things like duty cycle do not appear to be here.

[glens]

Andy, how can you possibly calculate duty cycle when you don't have all the data with which to do it?  Some of us occasionally look at the graphed logs for general information only, because looking too closely for nit-picking items gets aggravating due to the dearth of data.  Why would you want to treat them like every little event is included in its entirety when that's blatantly not the case?  I mean, don't you see the large holes?  Wasting time wondering what might be in them is a waste of time.

[whittlebeast]

Statistics gets around that stuff fairly effectively.  Duty cycle is a fairly straight based on RPM and pulse width.  You have both of those numbers.

[hrdtail78]

It is funny when Steve releases a face lift It is great, but when it is mlv it is not worth looking at how quickly you change your tune.

I never said mlv is not worth looking at.  I have it downloaded and have played with it.  Seems you know how to post quotes.  Find that.  I have continually asked how mvl will help.  I hold my opinion on a product until I have actually used it.  I don't regurgitate what I have heard from others.

Thanks Steve. That 3D graph is cool looking.

I thanked Steve for still working on his product and making improvements.  The 3D graph comment was a joke.  I'm sure some got it.

[cts1950]

I have been using MLV since 2004 and have watched it evolve and improve. It appears that the datamaster log viewer was made for displaying short dyno runs which  makes sense because autotune was not used in the SERT so it was a dyno operators tool . The short files are easy to see and zoom in on. That part of DM could use some more work for those who log a 200 mile run. Being able to zoom in and scroll through the entire run is a huge difference. Steve has made some big changes in the display and I applaud him for that and I hope he will address the scrolling and zoom in future releases.

[whittlebeast]

Andy, how can you possibly calculate duty cycle when you don't have all the data with which to do it?  Some of us occasionally look at the graphed logs for general information only, because looking too closely for nit-picking items gets aggravating due to the dearth of data.  Why would you want to treat them like every little event is included in its entirety when that's blatantly not the case?  I mean, don't you see the large holes?  Wasting time wondering what might be in them is a waste of time.

Glen, If you work thru the math and you are dealing with a motor that sprays the injectors one time per engine cycle, the math shakes out to

DutyCycle = PW * RPM /1200

pulse width is in milliseconds.

[glens]

Thanks, Andy.  That sort of math has never been a problem for me.  I guess I was thinking "percent" for "duty cycle".  As in "85% duty cycle", or "25% duty cycle".  I don't recall seeing or hearing anything like "6.345 mS duty cycle", which for some reason I was envisioning you talking about.  At any rate, when would this figure typically be a concern for you?

[whittlebeast]

Thanks, Andy.  That sort of math has never been a problem for me.  I guess I was thinking "percent" for "duty cycle".  As in "85% duty cycle", or "25% duty cycle".  I don't recall seeing or hearing anything like "6.345 mS duty cycle", which for some reason I was envisioning you talking about.  At any rate, when would this figure typically be a concern for you?

At about 80% or above, predicting fuel flow from the injector gets sketchy.  At the sort of RPM we deal with in the Harley world, that is at about 16ms max.  In the rice bike world that can get down to the 7 ms range. 

This has everything to do with sizing injectors to stay within the operating range of about 2.2 ms or so on the low side and 80% DC on the high side.

Beast

[whittlebeast]

Are you telling everybody that the PW is reported incorrectly in your code or is it the RPM that is reported incorrectly?

Beast

[Rider57]

Steve is correct Andy. It isn't just Delphi, its Motronic also and Bosch! I have seen this before TTS 1.0 even was released.

[Steve Cole]

Andy

I will say this one last time. The only data that is sent out from the ECM is recorded and then reported in our product. It is accurate as reported in our product. You cannot add data in as you have no way to know what the missing data is, no amount of anything is going to allow you to MAKEUP data when you do not know what is missing and from where, it just doesn't work that way. If you want to look at injector duty cycle just use the injector calculator provided in our product.

Statistics works fine across known good data but it doesn't work for missing or corrupt data. No amount of statistic work is going to makeup for the missing data until you use real test equipment that allows you to see what is missing and from where. Then at that it takes a lot more than statistics to get there. Back a few weeks ago someone posted a link to papers on how to reconstruct undersampled data, if you want to learn how to do it I would start with that.


Edit: Here is the post information about undersampled data, "The sort of thing that gets my attention"
« Reply #96

[blusmbl]

Steve is correct Andy. It isn't just Delphi, its Motronic also and Bosch! I have seen this before TTS 1.0 even was released.

Serial data is slow, it's just the nature of the beast. I don't expect more than 5hz out of it on the programs I work on just going through the OBD port.  You can do CCP on the newer Bosch modules and get some data recorded at engine speed, but you're still somewhat limited with the number of parameters.  Memory emulation is the way to go from an OEM development standpoint, but costs 30x as much as the TTS we get to use on our bikes.  What we've been given is much more than enough to get our bikes tuned correctly, if you understand the limitations of the data.

[Steve Cole]

Steve is correct Andy. It isn't just Delphi, its Motronic also and Bosch! I have seen this before TTS 1.0 even was released.

Serial data is slow, it's just the nature of the beast. I don't expect more than 5hz out of it on the programs I work on just going through the OBD port.  You can do CCP on the newer Bosch modules and get some data recorded at engine speed, but you're still somewhat limited with the number of parameters.  Memory emulation is the way to go from an OEM development standpoint, but costs 30x as much as the TTS we get to use on our bikes.  What we've been given is much more than enough to get our bikes tuned correctly, if you understand the limitations of the data.

This sums it up very well!