Openport Stand-Alone Logging Beta

Re: Openport Stand-Alone Logging Beta

Postby cboles » Thu Sep 24, 2009 3:55 pm

ptharris wrote:Colby I wonder if it is worth rolling the OP2 firmware back to what is included with ecuflash 1.42? How do I do this? Then try reinstall the beta version. Just a thought

Phil


There is no way to roll back really - the J2534 DLL only updates if it has something newer. I don't think that would help - If you have the version of firmware that EcuFlash is reporting, then we can be pretty sure you are running what everyone else is. All of the firmware updates are signed / secure, so The stand alone logging doesn't depend on anything but the firmware, so once you have the correct firmware, what DLLs / EcuFlash version you are using has no effect on its ability to log.
cboles
Site Admin
 
Posts: 1233
Joined: Wed Dec 29, 2004 5:45 pm
Location: Seattle, WA

Re: Openport Stand-Alone Logging Beta

Postby cboles » Fri Sep 25, 2009 4:22 pm

I have a new version at the head of this thread now. It has MUT-II and mode23 support. I have added a couple of logging configurations samples for these in the logging directory. Based on my observations with these ECUs, I have structured these loggers a little differently that I have for Subarus. In the case of CAN ReadMemoryAddress requests for the Evo X, I found that the response latency was variable, so instead of requesting parameters on a regular intervals that would be determined by the worst-case response times, I am letting the logger free-run and issue requests as soon as it gets the previous response. This provides the highest possible incoming sample rate, but I still resample these values down to a regular output logging rate. I do the same for the MUT-II logging. The Mitsubishi CAN logging averages about 100 parameters/sec, the MUT-II logging is about 200 parameters/sec.

I haven't tested these Mitsubishi logging modules on actual cars yet, only on bench ECUs, so there may be some initialization or logging rate issues I am not aware of yet. Let me know how it works for you.

Colby
cboles
Site Admin
 
Posts: 1233
Joined: Wed Dec 29, 2004 5:45 pm
Location: Seattle, WA

Re: Openport Stand-Alone Logging Beta

Postby cboles » Sun Sep 27, 2009 10:02 am

Anyone had a chance to try this yet?
cboles
Site Admin
 
Posts: 1233
Joined: Wed Dec 29, 2004 5:45 pm
Location: Seattle, WA

Re: Openport Stand-Alone Logging Beta

Postby Ceddy » Sun Sep 27, 2009 6:33 pm

What would the best SD Card to get, for people buying new cards?

A 2GB card formatted FAT-16?

Does card speed only matter when copying files to your computer, or could the card be over run when logging?

Does the OP 2.0 have any size limitations? SDHC 2.0 32GB Max or FAT-32 2TB Max?



Thanks, can't wait to try this out and not have to bungy cord my laptop to the passenger seat anymore.
Ceddy
 
Posts: 8
Joined: Sat Oct 28, 2006 12:07 pm

Re: Openport Stand-Alone Logging Beta

Postby Tephra » Sun Sep 27, 2009 7:00 pm

cboles wrote:I have a new version at the head of this thread now. It has MUT-II and mode23 support. I have added a couple of logging configurations samples for these in the logging directory. Based on my observations with these ECUs, I have structured these loggers a little differently that I have for Subarus. In the case of CAN ReadMemoryAddress requests for the Evo X, I found that the response latency was variable, so instead of requesting parameters on a regular intervals that would be determined by the worst-case response times, I am letting the logger free-run and issue requests as soon as it gets the previous response. This provides the highest possible incoming sample rate, but I still resample these values down to a regular output logging rate. I do the same for the MUT-II logging. The Mitsubishi CAN logging averages about 100 parameters/sec, the MUT-II logging is about 200 parameters/sec.

I haven't tested these Mitsubishi logging modules on actual cars yet, only on bench ECUs, so there may be some initialization or logging rate issues I am not aware of yet. Let me know how it works for you.

Colby


Hi Colby,

Yes since the ECU doesn't encode the response with an ID it is hard to match requests to responses, so a one-by-one approach is the only way.

Cheers
D.
Last edited by Tephra on Sun Sep 27, 2009 7:07 pm, edited 1 time in total.
Tephra
 
Posts: 59
Joined: Mon Aug 27, 2007 2:16 am

Re: Openport Stand-Alone Logging Beta

Postby Tephra » Sun Sep 27, 2009 7:06 pm

Looks good.

The format of the logfile isn't too bad - although I prefer mine :D If you can implement RPN formula rather than scale1+2 that would be awesome :)

Can we implement a priority type option - ie 1 = get this entry EVERY loop, 2 = every second loop, 20 = every 20th loop

That way I can put fuel trims @ 200 to save logging speed for rpm/knock/afr etc :)
Tephra
 
Posts: 59
Joined: Mon Aug 27, 2007 2:16 am

Re: Openport Stand-Alone Logging Beta

Postby cboles » Mon Sep 28, 2009 2:22 pm

Tephra wrote:
Hi Colby,

Yes since the ECU doesn't encode the response with an ID it is hard to match requests to responses, so a one-by-one approach is the only way.

Cheers
D.


Actually, I wasn't having a problem matching them up, since I also look at loopbacks of my own transmissions, so I can use those for context. What was an issue was the varying response times (particulary with the EvoX). If I was going to do the requests in a truly periodic fashion, I was going to have to space them by the worst case response time. My issuing a new request right after the previous response, thing could run just a little faster, although the scientist in me doesn't like the jittered sampling...
cboles
Site Admin
 
Posts: 1233
Joined: Wed Dec 29, 2004 5:45 pm
Location: Seattle, WA

Re: Openport Stand-Alone Logging Beta

Postby Tephra » Mon Sep 28, 2009 5:33 pm

BTW here is some straight C code (not sure if your writing in C or something else) for the RPNCalc routine I used in my mode23 logger. It's only basic and has limited functionality, but works pretty good :)

input RPNExpr is a RPN string
input XValue is the "x" in the RPN Expression
return is the evaluated expression
Code: Select all
double RPNCalc(char *RPNExpr, double XValue) {
   double stack[256];
   unsigned char stackpos = 0;
   char *token, *nexttoken;
   char tmpstr[255];
   
   memset(stack, 0, sizeof(stack));

   strcpy_s(tmpstr, 255, RPNExpr);            
   token = strtok_s(tmpstr, ",", &nexttoken);
   while (token != NULL) {
      if (strcmp(token, "+") == 0) {
         double tmp = stack[stackpos-2] + stack[stackpos-1];
         stackpos -= 2;
         stack[stackpos] = tmp;
         stackpos++;
      } else if (strcmp(token, "-") == 0) {
         double tmp = stack[stackpos-2] - stack[stackpos-1];
         stackpos -= 2;
         stack[stackpos] = tmp;
         stackpos++;
      } else if (strcmp(token, "*") == 0) {
         double tmp = stack[stackpos-2] * stack[stackpos-1];
         stackpos -= 2;
         stack[stackpos] = tmp;
         stackpos++;
      } else if (strcmp(token, "/") == 0) {
         double tmp = stack[stackpos-2] / stack[stackpos-1];
         stackpos -= 2;
         stack[stackpos] = tmp;
         stackpos++;
      } else if (strcmp(token, "x") == 0) {
         stack[stackpos] = XValue;
         stackpos++;
      } else {
         double tmp;
         sscanf_s(token, "%lf", &tmp);
         stack[stackpos] = tmp;
         stackpos++;
      }
      // Get next token:
      token = strtok_s(NULL, ",", &nexttoken);
   }
   return stack[0];
}
Tephra
 
Posts: 59
Joined: Mon Aug 27, 2007 2:16 am

Re: Openport Stand-Alone Logging Beta

Postby Tephra » Mon Sep 28, 2009 11:10 pm

Colby I tried the new version in post #1.

However when copying files TO the MicroSD card (via the OP20/USB) I get a HORRIBLE transfer rate.

I am talking sub 50KB/sec

I tried inserting the MicroSD card into a SD converter and plugged that straight into the laptop and get 6+ MB/sec.

Any ideas?

edit - this is with an 8GB SDHC (Kingston) card - not that it should matter :)
Tephra
 
Posts: 59
Joined: Mon Aug 27, 2007 2:16 am

Re: Openport Stand-Alone Logging Beta

Postby cboles » Tue Sep 29, 2009 10:39 am

Tephra wrote:Colby I tried the new version in post #1.

However when copying files TO the MicroSD card (via the OP20/USB) I get a HORRIBLE transfer rate.

I am talking sub 50KB/sec

I tried inserting the MicroSD card into a SD converter and plugged that straight into the laptop and get 6+ MB/sec.

Any ideas?

edit - this is with an 8GB SDHC (Kingston) card - not that it should matter :)


8GB SDHC does matter, because you probably need to run FAT32 to use it and may end up with a lot more disk I/O because of that (long story). The Openport 2.0 is not a USB 2.0 high speed device - it is a full speed one. You still should be able to get a few hundred KB/sec though. I'm running some benchmarks right now to test SD .vs. SDHC, FAT16 .vs. FAT32, etc. since it has been a while. Why do you care what the transfer rate TO the card is, when all you need to write is logcfg.txt? The OP2 would definitely not be my first choice as general purpose microSD reader\writer...
cboles
Site Admin
 
Posts: 1233
Joined: Wed Dec 29, 2004 5:45 pm
Location: Seattle, WA

Re: Openport Stand-Alone Logging Beta

Postby ptharris » Tue Sep 29, 2009 2:41 pm

Colby

The loging to SD card is working perfect for me again (08 STI CANbus) do you have any other parameters settings you could forward onto me, I went through the SSM code and tried to scale them and got some wierd readings on some items (I am not very great at this equations)

Phil
ptharris
 
Posts: 55
Joined: Fri Mar 06, 2009 7:34 pm

Re: Openport Stand-Alone Logging Beta

Postby Tephra » Tue Sep 29, 2009 2:59 pm

Hi Colby,

OK I did some more testing.

Uploading TO the card I get a MAX of 50KB/Sec, downloading FROM the card I get a MAX of 200KB/Sec

Given FullSpeed USB is 12Mbit we are still a little off :)

btw the card is formatted using a 64k blocksize - not sure if that matters!

Any word on implementing priority or rpn formulas?

Cheers
D.
Tephra
 
Posts: 59
Joined: Mon Aug 27, 2007 2:16 am

Re: Openport Stand-Alone Logging Beta

Postby Tephra » Tue Sep 29, 2009 6:16 pm

ok I just got back from a quick log:

1) I get about 100 individual samples a second using Mode23
2) It would be good if you can do the /1000000 for the Time field
3) It would be good if the sample column was the loop, rather than the sample (ie 1,2,3,4, rather than 10,20,30 - i have 9 items to log)
4) If we can somehow encode the time/date stamp in the filename that would be awesome

Apart from that its pretty good :)

I understand #4 is very unlikely, since I dont think the ECU has any concept of human time... Maybe the radio CAN??!?!
Tephra
 
Posts: 59
Joined: Mon Aug 27, 2007 2:16 am

Re: Openport Stand-Alone Logging Beta

Postby mshoemaker » Wed Sep 30, 2009 5:40 am

I was curious if there is a way to control the logging start/stop via a switch, etc the Set/Coast or Resume/Accel switches, defogger switch, ac switch?

Thanks,
Matthew
mshoemaker
 
Posts: 12
Joined: Tue Sep 29, 2009 3:43 pm
Location: Jerseyville, Illinois

Re: Openport Stand-Alone Logging Beta

Postby cboles » Wed Sep 30, 2009 5:56 am

Tephra wrote:ok I just got back from a quick log:

1) I get about 100 individual samples a second using Mode23
2) It would be good if you can do the /1000000 for the Time field
3) It would be good if the sample column was the loop, rather than the sample (ie 1,2,3,4, rather than 10,20,30 - i have 9 items to log)
4) If we can somehow encode the time/date stamp in the filename that would be awesome

Apart from that its pretty good :)

I understand #4 is very unlikely, since I dont think the ECU has any concept of human time... Maybe the radio CAN??!?!


1) As do I
2) Agreed. It will also start at zero before release. The current timecode allows me to see when the logging started relative to the hardware booting.
3) It normally is for Subaru logging and some others that are synchronous with the logging rate. It is just this way temporarily for debugging so I can see what the parameter sampling rate is versus the logging rate. It will go back to 1 increment per sample before release.
4) Not really possible. The CPU has a RTC, but no battery to back it up (there were a number of issues with adding a battery to this design). If you left the OP2 plugged into the car and then plugged into the PC via USB, I could sync to the PC clock, but I don't think most people would go to the trouble to do that.
cboles
Site Admin
 
Posts: 1233
Joined: Wed Dec 29, 2004 5:45 pm
Location: Seattle, WA

PreviousNext

Return to Openport Stand-Alone Logging Beta

Who is online

Users browsing this forum: No registered users and 4 guests