0.988.7 Release

[kritip]

I didn't log for as long as expected, but here we go anyway.

0.988.7a
3.0.3d fully seq

There is corruption in the log, and it logged at about 17/s

I'll try and upload in 7-zip format, as it compressed the best. Free at http://www.7-zip.org //edit, extension not allowed // edit, file now too big.

http://www.megafileupload.com/en/file/1 ... t-zip.html

A blown fuel hose put an end to the logging!

[LT401Vette]

That's not too good... I haven't looked that the 3.x extra code at all. It looks like something is really slowing it down. I would be interested if there where any debug statements going out to the TunerStudioLogFile.txt. Also has the data packet size changed by much? Is the data rate pretty weak with normal logging too?

For the most part the log looks good, but I see 2 records (6724 & 18764) where it looks like a byte got shifted.

I'm sorry I didn't get the build out last night. I got home and the Power Supply on the machine I use to build is dead. I can build on another, but last time i did that it turned out I put out a release that only ran with JRE 1.6 and it took a bit more than a day before I noticed, and it was already on 50 people peoples computers . So I try to stick with the one machine for public releases.
I ordered a new PS from and should have that machine back in a couple days.

[racingmini_mtl]

The packet size is 161 bytes instead of 145 bytes for 2.1.0. And I haven't done any datalog speed comparison between the 2. But besides the log size, there isn't any difference in the comm code so I would have thought that the speed would pretty much be proportional.

Jean

[LT401Vette]

I would expect 15 extra bytes to have a pretty minimal difference too. So I'm thinking there is something else going on.
If you have CAN_COMMANDS enabled it does slow down logging quite a lot. But in burst mode it would use the burst command anyway. However, if there is no burstCommand, it will use the normal command and if you have CAN_COMMANDS enabled, that would be the CAN command instead of a simple A

[racingmini_mtl]

CAN_COMMANDS is disabled by default in the ini. So logging is done with a simple A unless the ini has been changed from default.

Jean

[LT401Vette]

It is disabled by default, but it is enabled if it is enabled in Project Properties, then it would be on without changing the ini.

I have several time caught myself asking why is it going so slow to find out I had that enabled. 17 record/s is right about where it usually lands when CAN_COMMANDS is enabled.

[racingmini_mtl]

Yeah, I thought about that after posting. I guess it's my MT mindset...

Jean

[kritip]

I have CAN_COMMANDS disabled.

Perhaps it is the usb adapter i use, though that does seem reliable.

I did try setting my USB adater to it's highest data rate, but TS seemed to drop its speed back down too 115000, guess that should make no difference though.

I have no clue how many records/s i have on a regular log, do i just manually count then in the log?

Cheers,

Kristian

[LT401Vette]

I did try setting my USB adater to it's highest data rate, but TS seemed to drop its speed back down too 115000, guess that should make no difference though.

The MS itself doesn't really support over 115200, I don't have a higher number in the drop down, I can put it there, but I don't know of a place it will work.


A quick way to see what rec/sec you are getting is to look at the SecL field, see how many records you get with the same SecL. If you do that over say 5 seconds of SecL you can get a bit more precise. I will usually just open the log in something like TextPad, then I can just highlight the rows with the same SecL, TextPad will tell you in the status bar how many rows you have highlighted.

[kritip]

I have run 2 logs today, both just over 1 hour in length, and on the same journey.

First log was a burst mode log, logging at approx 20/s

Second Log was a normal log

The normal log is fine, not one corruption, the burst log has LOTS of corruption.


To open them, I use the environmental variable "JAVA_OPTS=-Xms3000m -Xmx3000m" as I have plenty of memory.


For this set of logs i used the same usb adapter, but used a different laptop running vista instead of xp, just to rule it out of the equation.


http://www.megafileupload.com/en/file/1 ... s-zip.html are the two logs I made. I haven't checked the rate of the non burst file yet.

Cheers,

Kristian

[LT401Vette]

Those are some good sized logs...

In your normal log it looks like you are getting about 15-16 records per second. I am assuming that you are set to the default 15/sec under communications-->Data Rate. Or have you raised it and that is just all you can get?

If you increase the data rate with normal logging you can probably get pretty close to the same rate and still have better protection against corrupt records. That is really the key to burst model, it just reads the data as fast as the controller will send it back. Where under normal logging, even if you are running at 20 records / second, it still maintains more conservative timings. If you go to Maximum, it is still more conservative than Burst Mode, but not much....

On your burst log you said there is lots of corruption, but I only see 10 bad records out of 82000, So I'm thinking a minor tweak can take care of that. I doubt that is the firmware that is sending it back wrong, it is more likely perhaps something in the windows buffers. You could play with the windows buffers, turn them to 0 and see if that takes care of it.

After that, I am still curious why your rates are as slow as they are. I should get the 3.0 code and try it here with a real serial cable and make sure I see no substantial drop in data rate. I would be surprised.

[LT401Vette]

Looking a little more at your log... I see, there are a good bit more than 10 corrupt records. I was just counting the ones that created a MARK .

[kritip]

Those are some good sized logs...

In your normal log it looks like you are getting about 15-16 records per second. I am assuming that you are set to the default 15/sec under communications-->Data Rate. Or have you raised it and that is just all you can get?

Apologies. Yes it was set to the default 15/s. On the other laptop it was sent to maximum, but on this one i setup specifically to test, I forgot to change it to maximum.

If you increase the data rate with normal logging you can probably get pretty close to the same rate and still have better protection against corrupt records. That is really the key to burst model, it just reads the data as fast as the controller will send it back. Where under normal logging, even if you are running at 20 records / second, it still maintains more conservative timings. If you go to Maximum, it is still more conservative than Burst Mode, but not much....

I'll get chance to run another test in a few days, which I'll do at maximum settings

On your burst log you said there is lots of corruption, but I only see 10 bad records out of 82000, So I'm thinking a minor tweak can take care of that. I doubt that is the firmware that is sending it back wrong, it is more likely perhaps something in the windows buffers. You could play with the windows buffers, turn them to 0 and see if that takes care of it.

After that, I am still curious why your rates are as slow as they are. I should get the 3.0 code and try it here with a real serial cable and make sure I see no substantial drop in data rate. I would be surprised.

I have a laptop with a real serial connection, that i may be able to try. It's up for sale on eBay at the moment, but if i have chance before it sells, i will try it.


When the records go bad, they seem to go dramatically bad. Is there any way MLV can detect corrupt records, and warn or filter them out, so that the graphs are still legible? Guess this is the wrong approach though, and the actuall fault should be corrected.

Cheers,

Kristian