krillin

iTrader: (3)

i've been using zeitronix and mitsulogger (at the same time) when logging and have had no issues until recently. i had to reinstall ecuflash(for a reason i'll mention later), and afterwards i noticed that when i run mitsulogger and zeitronix at the same time, that my mitsulogger only gives me like 6 samples for an entire 3rd gear pull. if i log with mitsulogger alone, i get my normal 50 samples for the entire pull.

btw, my zeitronix is hooked up into the serial port on my laptop and of course the mitsulogger via usb tactrix cable. i don't understand why i am getting this issue right now when i've been able to log fine for the past few months.

anyone have any ideas?


oh and the reason why i had to reinstall ecuflash...i was messing around with the custom color maps. i noticed that if i chose a color like volcano but scrolled down to see the other colors, THEN scroll back to volcano then the color would be different. it seems like the colors shifted to different names. so i would shut down ecuflash and restart it, but then i would get a pop up window with some sort of XML error or something. there was no way to load ecuflash and i would have to end task in task mgr. so i reinstalled ecuflash (loads fine) and this is where i am getting the issue with mitsulogger and zeitronix logging at the same time.

i've uninstalled ecuflash completely along with all the drivers and even tried using ecuflash 1.28 (was using 1.29a) to see if older tactrix drivers would fix the problem but it hasn't.

again, anyone have similar problems? until i figure this out it looks like i'll have to log one thing at a time. :-\

jfitzpat

Is the serial port that you are using for your Zeitronix a built in COM port or a USB COM port?

If it is a USB COM port I would try borrowing one that I was sure does not use the FTDI chipset. Then there should be no driver overlap or conflict.

Since Mitsulogger is not reporting timeout errors and your data isn't coming back garbage, I'd be prone to think that this is a case were the logger is getting dead locked (it can't get samples because the operating system is not in a position to yield to it, or let it run, frequently enough). Shared device drivers is the only EcuFlash centric thing I can think of (the installer does include the latest FTDI drivers).

Outside of kernel driver space, one of the few places that Windows regularly deadlocks is UI. Is there any change in sample rate if one application or another is minimized?

Good Luck,
-jjf

krillin

iTrader: (3)

hey jjf. thanks for the reply.
the serial port is built in to the laptop (older thinkpad 600x). whether the app is minimized or not, it doesn't make a difference. again, i've been able to use both zeitronix and mitsulogger simultaneously with no issues until a few days ago, and the only thing i did within that time period was reinstall ecuflash because of the weird XML error at startup after messing with the color maps.

well, there is one more thing to try before i give up and just wait to see if the new mitsulogger fixes my problem...

jfitzpat

Sorry, I busted open the EcuFlash installer to see if there were a bunch of system DLLs or something that might explain this (like the way IE would break common controls system wide during the must-kill-Netscape hey day). Frankly, it looks pretty benign.

If you're using a built in com port, there is virutally no overlap. I think that MJ calls the Tactrix cable via D2XX (bypassing the Windows COM stack).

Three other things you could take a look at. First, you could right click on the task bar and select Task Manager, then click on the Performance tab. I'd be interested in what CPU usage is doing. If it is soaring it could be something seemingly benign, like display code dead locking on a GDI(+) resource. Even if this worked before, a Windows update, display driver update, etc. can suddenly cause these sorts of problems.

Second, here is a connection diagnostic I wrote: http://www.innovatemotorsports.com/s...PTestSetup.exe

It isn't really a logger, but it will connect via MUT, through D2XX and then keep doing a keep-alive query (RPM every second). You can also manually issue queries. I'd be interested in a slow down in either the keep alives or the manual queries when you have both apps running. Also, the log will show any timeouts that Mitsulogger may be ignoring or retrying. It won't solve your problem, but since I understand how all the pieces are implemented, it might give me some clue as to what level you are dead locking on.

Third, does it make a difference what order you start and connect the applications in?

Honestly, it sounds to me like Mitsulogger is working fine. 4-6 Hz is all I normally see when I log a bunch of stuff and it sounds like you are getting that with Mitsulogger alone.

Again, sorry I couldn't be of more help.

-jjf

MalibuJack

iTrader: (5)

I'm suspecting a driver problem with his issue at this point, since he had several versions installed over time, and he had to foul with it to get it to install properly or get his color choices to stick..

His other PM to me stated 5-6 samples total, and not per second, otherwise I would have suggested that its normal.

krillin

iTrader: (3)

no you're right. it's 5-6 samples total for the entire pull. sorry for the confusion.
i have only had ecuflash installed once on my laptop and once of my pc at home. i got errors on both computers when browsing through the color maps and had that startup issue (xml error) with ecuflash which forced me to reinstall it.

i doubt there are many people that mess with the colors but i'd like someone to go to their color maps, choose volcano1 or whichever is the first volcano color. scroll down 3 or 4 colors and then scroll back up to the first volcano color. for me the color isn't the same one anymore, it's the color or something above it.

even with ecuflash 1.28 i tried to scroll through the colors then back and it did the same thing, but it didn't give me a startup error like with 1.29a.

MalibuJack

iTrader: (5)

Yeah it appears one of the color map XML files is corrupt or the routines to handle/swap the colors is.. It seems to corrupt the saved settings with an illegal character.

I doubt this is the source of your problem, but I would suggest not changing the color map from default in the future (I can reproduce this error also) and although it can be fixed by deleting the XML files in rommetadata and copying clean ones back over.. For one reason or another this action corrupts something in one or more of the XML files. It seems that XML files are modified even when their not touched (only opening a rom) not sure what causes it, but its obviously a bug.

I would look elsewhere for why your logging suddenly slowed down, I suspect there is something else running in the background, or a problem with the driver which is slowing things down.

jfitzpat

I actually got that. He said 50 samples on a 3rd gear pull, which sounds about right to me (7-8 seconds?)

It is hard for me to see how the FTDI drivers could really be the problem, unless I am mistaken and you aren't calling via D2XX. D2XX isues deviocontrol calls into the FTDI driver. The driver, in turn, translates the calls into 'URB's' for the USB stack, then schedules a completion routine. Even if you are reading and writing constantly, without any sleep mechanism at all, this yeilds.

You're bypassing the windows comm stack, so there seems to be virtually no overlap at all. There are some potential weirdnesses, like it might be worth trying to manually move the VCP assigned to the tactrix up to a high com number using the advanced settings in the Device Manager, but these are pretty obsure.

The highest probably conficts of this sort are generally drawing (even today, a bunch of GDI elements are non re-entrant, single instace) and a kernel deadlock. Sometimes you'll see the later with crappy USB -> serial adapters when the software keeps hitting the comm stack read and write timeout code from a spawned thread. But you are bypassing that and the driver for built in ports is pretty benign.

Sorry, these types of problems are usually pretty easy to track down if you can reproduce them with a kernel level debugger loaded, but are awfully hard to figure out with no tools and remotely!

-jjf

MalibuJack

iTrader: (5)

yeah.. He has an older laptop (I have one of these sitting around) that has a built in serial port. I doubt there is a conflict between the USB driver and Serial port (I do call the device using the FTD2xx libraries) and it was working fine until recently.

If I recall, the USB host version of this laptop would be 1.0, and it may actually be suffering from something else stealing priority away from the USB bus, I see this with disk access, disk protection, antivirus software, Popup blockers and spyware scanners, anything that tends to steal away unused timeslices.

Not to mention the things mentioned by jfitzpat in his prior posts. \

Its funny though, during the debug process I had experienced something similar on an IBM 240x laptop, its similar to your laptop at the hardware level. I had noticed in that case it was a setting was changed causing alot of dropped data (incomplete responses due to timeouts)

Do you by chance have the 2 byte response checkbox checked? or the timeouts set to anything?

MalibuJack

iTrader: (5)

Oh and one more thing you can try, don't connect the white connector to the car when logging, just the OBD connector.. see if that helps.. I don't think it has any relevance, but its worth a try.

krillin

iTrader: (3)

i never have the white connector connected when logging. i immediately disconnect it when i'm finished reading or writing from my ECU. also, i don't touch any of the baud rate settings and the 2 byte is unchecked like default. the only settings that are altered is the injector latency setting and the voltage, which i've been using since i've been using mitsulogger.

i ran mitsulogger in demo mode at lunch and noticed that mitsulogger was hovering 90-95% CPU resources. i never bothered to check this when logging before but i'm guessing that this could be part of the problem.

MalibuJack

iTrader: (5)

I can see that being a problem if you have a lot of stuff running a the same time.. Maybe memory overhead or something changed recently?

jfitzpat

That's high, but I wouldn't read to much into a demo mode. I'd be more concerned about where it sits while actually logging. Also, just because it is registering that high does not automatically mean that that is the actual cycles requried. If a program calls sleep(0) in Windows in a loop, the thread will run a disproportionate amount of the time while the machine is relatively quite. Run other apps that start causing process switches in those sleep calls, and you can actually see CPU usage go down.

Still, I'd investigate. If the usage is really high, and you run a second app, Mitsulogger could be running short. A maybe-crash test you could try would be to go to the task manager and boost the priority of the Mitsulogger application before running the other app. If you are truly CPU bound, that should boost the Mitsulogger logging rate with two apps.

-jjf

krillin

iTrader: (3)

i haven't changed anything on the laptop. i don't use it for anything besides logging data in my car. :-\

i even uninstalled AVG so it wouldn't run it in the background even though it's always been on this laptop. oh well...

MalibuJack

iTrader: (5)

Out of curiosity, have you Run Mitsulogger alone, without the zeitronix logger app to see if its the combination or just mitsulogger deciding to be crabby?

Good news is the wideband zt2 logging for Mitsulogger is real close to release.

but I really want to know why this suddenly stopped working right, so running the app standalone and doing some logging as you normally would will either do the same thing, or it wont...

As far as I recall, I don't use the standard sleep method, but I do use the thread sleep method if the delay count is greater than zero. High CPU Utilization is not surprising for an application that does alot of random data generation writing to disk, you obviously can see its high at the taskmanager, but it doesn't require alot of CPU to run and does release as much time to the OS if there are other processes that require it.

How much memory is in the computer? Perhaps there's alot of disk swapping going on? This could be something "recent". But things rarely change for no reason, so if this started happening, there had to be something that changed.