Openport Stand-Alone Logging Beta

Openport Stand-Alone Logging Beta

Postby cboles » Tue Sep 15, 2009 4:18 pm

Sorry it took so long to get something out there - but here it is - a beta you can try for stand-alone logging with the Openport 2.0.

Here are some important things to note and understand:

* The OP2 logs to microSD and SDHC cards - you will need one formatted with a FAT12, FAT16 or FAT32 file system. Large SDHC cards can actually end up being slower when plugged into your PC due to the greater I/O required in FAT32.
* You may not be aware, but when a microSD is plugged into the OP2 and it is plugged into your computer via USB, you can see this microSD as an additional drive on your system. There is no need to ever remove the microSD card unless you want to use a card reader which is faster than the OP2.
* At this point in the beta, there is no GUI in EcuFlash or elsewhere for setting up the logging. You must do so by creating a logcfg.txt file (described later).
* The OP2 will not log while it is plugged into to you computer via USB. It will only log when plugged into your car and the proper trigger conditions have been met.
* Each time the OP2 starts logging, it will create a new logXXXX.csv file which contain CSV entries with the log data. The first line will be the column headers. You can load this into Excel and other programs, or just view it as a text file.
* This version of the beta supports logging from K-line and CAN Subarus (SSM), K-line and CAN Mitsubishis (MUT-II and mode23) the Innovate MTS bus products via the 3/32" plug, and the internal ADC channels. I am working on MUT-II support right now.

Here is how to install and use this beta:

* Download and install http://www.tactrix.com/index.php?option=com_content&view=category&layout=blog&id=44&Itemid=65 (this is the official beta download page from here on)
* Run EcuFlash and do a Help|Licensing operation. This will cause a firmware update to 1.10.xxxx, which has the logging support.
* If you go to the C:\Program Files\OpenECU\EcuFlash\samples\logging directory you will see some example logging configuration files. These are text files you can open in a text editor and read.
* Copy the appropriate text file to your microSD card and rename it logcfg.txt. Make sure your text editor does not end up writing the file as logcfg.txt.txt.
* Disconnect the OP2 from your PC and plug it in to your car and go for a drive.
* Come back and connect your OP2 to the PC and examine the CSV files.

Some additional notes:

* About the status lights on the OP2:
RED - OBD port or Innovate port data is being received
GREEN - OBD port data is being sent
BLUE+RED - SD card activity (read or write)

* This means that when logging is working properly, you should see RED and GREEN flashing often, and BLUE flashing occasionally when a new block of log data is written.
* The current version of the beta has no power management, and the OBD port is always on, so it is possible to drain your battery if you leave the OP2 plugged in for several days while your car is off.
* Until there is a GUI, you will need to know the parameter IDs and scalings of the parameters you want to log in order to set up the logcfg.txt properly. This may not be for the timid, although it is certainly possible for more experienced users to share set-up logcfg.txt files with others. Once EcuFlash logging is available this problem will go away.

Important notes about this latest release



--1.10.2938
* IMPORTANT - the OP2 now uses a custom driver I wrote for better speed and stability than the Microsoft usbser.sys driver. This allows for reduced latency and a cleaner installation as well. *** This means that initially you must do a full EcuFlash and J2534 / driver install so that all of these components will work together. OLDER ECUFLASH AND OP20PT32.DLL VERSIONS WILL NOT WORK WITH THE DRIVER. **

-- new features --
* Up to 60 parameters allowed
* Completely changed innovate MTS bus logging to support multiple LC-1 and other MTS devices (see subaru k-line adc lc1.txt sample for details)
* Support for more flexible lower speed/priority parameter sampling through the use of a new additional parameter feature called sampgroup.

sampgroups are numbered 1 through 15, the number simply being a label. All parameters in the same sampgroup will share a single timeslot. The OP2 will determine how many of each sampgroup there are, build a cycle of that size, and phase each of them properly. This allows you to have different groups of low speed parameters, running at different speeds, each optimally using the sample cycle. (see subaru k-line adc lc1.txt sample for details)

priority = 2 is still allowed, but all it does is assigned the parameter to sampgroup = 1

* SD card uses DMA for greater speed in all cases
* SD card multiblock read / write to increase speed when connected to USB (800kB/s read / 500kB/s write is typical)
* Filesystem operations queued to a separate thread to allow seamless logging regardless of SD card latency
* Multibyte parameter (up to 32-bit) mitsubishi support
* Support for zeroing sample count each time a new file is started using zerosamplecount = 1
* Support for zeroing time count each time a new file is started using zerotimecount = 1
* Time count starts on nice intervals
* Time only shows to the millisecond
* Increased range and fine-granulatrity of possible logging intervals
* Improved details in logcfg.out dumps
* Support for filling in missing samples if ECU misses a response or two using fillmissingsamples = 1
* Support for new file cuttting action "newfile" which starts a new file if your conditions are met (see subaru k-line adc lc1.txt sample for details)
* improved timing estimates for most logging protocols

-- bug fixes --
* fix error in && and || tokens
* increase speed of SSM K-line comms
* fix occasional failed transition to logging after USB disconnect
* fix overly-rapid mitsubishi communication attempts if ECU not responding

--1.10.2720

-- new features --
* up to 4 logging channels allowed (e.g. ssmcan, lc-1, adc, & calculated data)
* support for fast RAM parameters on Subaru CAN vehicles (assuming ROM patch has been made). just use the known RAM parameter ID (0xFFxxxx) and the OP2 will do the rest. reading of multibyte RAM parameters is sped up by the ROM patch which allow reading up to 4 bytes with a specially encoded 3-byte parameter request. due to current Subaru output buffer limitations, only 80 bytes can be returned in a single request, so only 20 4-byte params can be read at a time. i will make some changes to the OP2 firmware in the future to issue multiple requests to overcome this 80-byte of data limit.
* new "previous value" parameter added to RPN expressions (e.g. "#RPM" instead of "RPM"). this is useful in creating trigger conditions that are sensitive to the direction of change in a value. for example, if you wanted to capture each dyno pull from 2000rpm to 7000rpm to a separate file, you could set the following conditions:

conditionrpn = #RPM,2000,<,RPM,2000,>=,&&
action = start

conditionrpn = #RPM,7000,<,RPM,7000,>=,&&
action = stop

-- bug fixes --
* collecting lc-1 data does not cause additional steps in the sample count

--1.10.2702--

-- new features --
* writing of logcfg.out has been speed up 100x or more - there is little need to use the debug=noout option anymore
* added some more finely spaced "friendly" logging intervals

-- bug fixes --
* fix bug where logging could sometimes start immediately after a firmware reflash without they normal delay to check for USB
* fix bug where long SSM responses were not correctly parsed
* fix bug where 32 bit data fields (such as floats) were not masked correctly
* increased mrmacan logging interval estimates to avoid sampling overruns

--1.10.2696--

There are a number of new features and major changes to the logging in this new 1.10.2696 version from the previous 1.10.2678 one. Take a look at all of the updated sample logging files to see how to use these features. ***YOUR OLD LOGCFG.TXT FILES WILL NO LONGER WORK***

-- new features --
* set debug=noout at the beginning of your logcfg.txt file to suppress the logcfg.out output - this greatly improves startup time
* time now starts at 1/1/2009 each time the OP2 boots to give more reasonable looking file times
* green status light now blinks during 5 baud inits (e.g. MUTII)
* high/low priority sampling of parameters - set priority=2 for low priority sampling of a param
* parameters and triggers now use RPN based scalings so that you can do arbitrary equations or evaluations. i will add an infix (algebraic/parenthetical) to RPN parser later for those who are confused by RPN...
* calculated / derived parameters are now supported - you can now make new parameters based on equations of other parameters
* MUTII logging is now much more robust - it will re-initialize if there is a break in communications
* CAN (SSM/MRMACAN) logging is more robust - it will retry if there is a break in communications
* SSM K-line logging is more robust - it will retry if there is a break in communications (it used to be this way before, but I had broke it with the priority logging)
* added the ability to set voltages or ground pins - this is handy for MUTII users who need to ground pin 1
* added isvisible option to parameters so that you can use them for triggering or calculations, but not write them to the log file
* isfloat=1 parameters automatically default to databits=32 now

-- bug fixes --
* logging mode now starts if the OP2 is already plugged into OBD and you remove the USB connection - this means you don't have to unplug the OP2 from OBD at all between logging / reading logs / tuning / flashing / etc.
* databits values over 31 could be truncated
* sample time is now in units of seconds
* sample number now should increment by 1 per log cycle for mitsubishis
cboles
Site Admin
 
Posts: 1233
Joined: Wed Dec 29, 2004 5:45 pm
Location: Seattle, WA

Re: Openport Stand-Alone Logging Beta

Postby unchi » Tue Sep 15, 2009 8:25 pm

sweeeet! ill try tomorrow!
i have a spare 1 GB card
unchi
 
Posts: 114
Joined: Tue Apr 25, 2006 7:02 am

Re: Openport Stand-Alone Logging Beta

Postby unchi » Tue Sep 15, 2009 8:30 pm

Colby can you implement Mode 23 logging for the Evo X.....
Tephra has a command line logger u can jack

this would be amazing!
unchi
 
Posts: 114
Joined: Tue Apr 25, 2006 7:02 am

Re: Openport Stand-Alone Logging Beta

Postby Tephra » Tue Sep 15, 2009 8:34 pm

awesome!

it would be awesome if you can implement CAN mode23 support - that reads a config file off the SD card to problem for what memory locations...

Let me know if you want packet formats..
Tephra
 
Posts: 59
Joined: Mon Aug 27, 2007 2:16 am

Re: Openport Stand-Alone Logging Beta

Postby Tephra » Tue Sep 15, 2009 8:36 pm

beaten...

:)
Tephra
 
Posts: 59
Joined: Mon Aug 27, 2007 2:16 am

Re: Openport Stand-Alone Logging Beta

Postby cboles » Tue Sep 15, 2009 8:44 pm

Tephra wrote:awesome!

it would be awesome if you can implement CAN mode23 support - that reads a config file off the SD card to problem for what memory locations...

Let me know if you want packet formats..


I do - just send me the info and I will add it. Doing CAN/ISO15765 is easy compared to K-line with it's sloppy OEM protocols...
cboles
Site Admin
 
Posts: 1233
Joined: Wed Dec 29, 2004 5:45 pm
Location: Seattle, WA

Re: Openport Stand-Alone Logging Beta

Postby Tephra » Tue Sep 15, 2009 9:18 pm

Hi Colby,

ok packet format is:
0x00 - always 0
0x00 - always 0
0x07 - 07e0 is CAN target
0xE0 - ditto
0x05 - packet length
0x23 - mode23
0xXX - first byte of memory address
0xYY - second byte of memory address
0xZZ - third byte of memory address
0xLL - length of memory address

Using the J2534 api you need to set the DataSize to 12 (so pad remaining bytes with 0's)

Return requests are processed using:
if (RecvMsg[i].Data[5] == 0x63) {
unsigned long RequestReturn = 0;
if (RecvMsg[i].Data[4] == 0x03) {
RequestReturn = RecvMsg[i].Data[6] * 256 + RecvMsg[i].Data[7];
} else if (RecvMsg[i].Data[4] == 0x02) {
RequestReturn = RecvMsg[i].Data[6];
}
byte 5 is OR'D by the ECU with 0x40 upon mode23 successful call
byte 4 is the length of the packet
byte 6....n are the return bytes.. normally 1 or 2 bytes in length obviously.. my program only handles sending of 2 bytes...

So for instance:

00 00 07 e0 05 23 80 87 3e 02 is RPM for my ROMID.

-53040010 config file (field 3 is length, ie 2bytes for RPM, last field is loop priority):
RPM:0x80873e:2:x,1000,*,256,/:1
PSIG:0x808712:2:x,4,/,0.19347,*,14.5,-:1
TimingAdv:0x8089ff:1:x,20,-:1
KnockSum:0x808a43:1:x:1
Load:0x808766:2:x,10,*,32,/:1
IPW:0x80a934:2:x,1000,/:2
AFR:0x809346:2:x,1023,/,5.99,*,10,+:1
AirFlow:0x8087d8:2:x,2,*,100,/:3
ActiveWGDC:0x808b4b:1:x,2,/:2
FuelTrim_Idle:0x804573:1:x,0.1953125,*,25,-:250
FuelTrim_Cruise:0x804575:1:x,0.1953125,*,25,-:250

Trouble with mode23 is every region of car has different memory addresses - so at the moment we have 3 or 4 different config files...

But apart from that it works great :)

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

Re: Openport Stand-Alone Logging Beta

Postby cboles » Wed Sep 16, 2009 8:30 am

ahhh, by mode23 you are referring to the KWP2000 readMemoryByAddress command... no problem.
cboles
Site Admin
 
Posts: 1233
Joined: Wed Dec 29, 2004 5:45 pm
Location: Seattle, WA

Re: Openport Stand-Alone Logging Beta

Postby cboles » Wed Sep 16, 2009 8:47 am

Tephra wrote:Hi Colby,
Using the J2534 api you need to set the DataSize to 12 (so pad remaining bytes with 0's)


Actually, you should be using the ISO15765 channel for this in J2534 and not CAN. Also set the ISO15765_FRAME_PAD flag in your flow control filter and in the messages you send. Then all of the lengths and things will be properly parsed for you. In addition, you will be able to properly handle responses with payloads greater than 7 bytes, which gets complicated and requires handshaking responses.
cboles
Site Admin
 
Posts: 1233
Joined: Wed Dec 29, 2004 5:45 pm
Location: Seattle, WA

Re: Openport Stand-Alone Logging Beta

Postby cboles » Wed Sep 16, 2009 1:10 pm

I tried issuing readMemoryByAddress commands to an Evo X ECU, but it appears I am not in the right diagnostic mode. What initialization are you doing before you issue these?
cboles
Site Admin
 
Posts: 1233
Joined: Wed Dec 29, 2004 5:45 pm
Location: Seattle, WA

Re: Openport Stand-Alone Logging Beta

Postby unchi » Thu Sep 17, 2009 6:13 pm

cboles wrote:I tried issuing readMemoryByAddress commands to an Evo X ECU, but it appears I am not in the right diagnostic mode. What initialization are you doing before you issue these?

u have to activate mode 23 logging in the ecu first
unchi
 
Posts: 114
Joined: Tue Apr 25, 2006 7:02 am

Re: Openport Stand-Alone Logging Beta

Postby Tephra » Thu Sep 17, 2009 6:17 pm

Hi Colby,

re initialisation

1) you need to put the ECU into reflash mode - power to pin8 i believe?
2) you need to send OBD Mode 0x10 - i have the code around someplace.

We wern't sucessful with #1 (remember my emails to you?)

So we made 3 bytes worth of changes to the ROM to enable Mode23 without any init...

Re CAN vs ISO15765 - yeh probably, but CAN works ok with manual padding :)

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


Re: Openport Stand-Alone Logging Beta

Postby cboles » Fri Sep 18, 2009 11:00 am



Ahhh. Now I understand why some people are bricking their Evo X ECUs trying to make this mod. Can I make a suggestion? Instead of using a byte data type and directly modifying ROM code bytes, use the bloblist data type instead. This is what it was intended for. That way you can pattern match against a longer byte sequence and be sure you are actually modifying the right code area. The bloblist data type will let the user know if the area in question does not match one of its known states. Here is an example for the 5268XXXX rom:

First, here are the code snippets we would like to modify:

Code: Select all
ROM_:0007F114 63 03                                   ldi8    R3, #j1979_mode_3
ROM_:0007F116 64 04                                   ldi8    R4, #j1979_mode_4
ROM_:0007F118 B0 03 00 20                             beq     R0, R3, loc_7F198
ROM_:0007F11C B0 04 00 21                             beq     R0, R4, loc_7F1A0
ROM_:0007F120 65 05                                   ldi8    R5, #j1979_mode_5
ROM_:0007F122 66 06                                   ldi8    R6, #j1979_mode_6
ROM_:0007F124 B0 05 00 21                             beq     R0, R5, loc_7F1A8
ROM_:0007F128 B0 06 00 22                             beq     R0, R6, loc_7F1B0
ROM_:0007F12C 67 07                                   ldi8    R7, #j1979_mode_7
ROM_:0007F12E 61 08                                   ldi8    R1, #j1979_mode_8
ROM_:0007F130 B0 07 00 22                             beq     R0, R7, loc_7F1B8


Code: Select all
ROM_:0008AB06 64 04                                   ldi8    R4, #j1979_mode_4
ROM_:0008AB08 B0 03 00 30                             beq     R0, R3, loc_8ABC8
ROM_:0008AB0C B0 04 00 31                             beq     R0, R4, loc_8ABD0
ROM_:0008AB10 65 05                                   ldi8    R5, #j1979_mode_5
ROM_:0008AB12 66 06                                   ldi8    R6, #j1979_mode_6
ROM_:0008AB14 B0 05 00 42                             beq     R0, R5, loc_8AC1C
ROM_:0008AB18 B0 06 00 30                             beq     R0, R6, loc_8ABD8
ROM_:0008AB1C 67 07                                   ldi8    R7, #j1979_mode_7
ROM_:0008AB1E 61 08                                   ldi8    R1, #j1979_mode_8


Here is how you are doing it currently:
Code: Select all
<table name="IFMode 0x05 -> 0x23 #1" category="Misc" type="1D" address="0x7f121" scaling="Hex8"/>
<table name="IFMode 0x05 -> 0x23 #2" category="Misc" type="1D" address="0x8ab11" scaling="Hex8"/>
<table name="DoMode 0x42 -> 0x52" category="Misc" type="1D" address="0x8ab16" scaling="Hex16"/>


Here is what i suggest:
Code: Select all
<scaling name="mode23_patch1" storagetype="bloblist">
   <data name="disabled" value="65056606" />
   <data name="enabled" value="65236606" />
</scaling>

<scaling name="mode23_patch2" storagetype="bloblist">
   <data name="disabled" value="65056606B0050042" />
   <data name="enabled" value="65236606B0050052" />
</scaling>

<table name="mode 23 part 1" category="Misc" type="1D" address="0x7f120" scaling="mode23_patch1"/>
<table name="mode 23 part 2" category="Misc" type="1D" address="0x8ab10" scaling="mode23_patch2"/>


as you can see, it matches against a larger part of the code pattern, so it is a bit safer!
cboles
Site Admin
 
Posts: 1233
Joined: Wed Dec 29, 2004 5:45 pm
Location: Seattle, WA

Re: Openport Stand-Alone Logging Beta

Postby unchi » Fri Sep 18, 2009 11:13 am

cboles wrote:


Ahhh. Now I understand why some people are bricking their Evo X ECUs trying to make this mod. Can I make a suggestion? Instead of using a byte data type and directly modifying ROM code bytes, use the bloblist data type instead. This is what it was intended for. That way you can pattern match against a longer byte sequence and be sure you are actually modifying the right code area. The bloblist data type will let the user know if the area in question does not match one of its known states. Here is an example for the 5268XXXX rom:

First, here are the code snippets we would like to modify:

Code: Select all
ROM_:0007F114 63 03                                   ldi8    R3, #j1979_mode_3
ROM_:0007F116 64 04                                   ldi8    R4, #j1979_mode_4
ROM_:0007F118 B0 03 00 20                             beq     R0, R3, loc_7F198
ROM_:0007F11C B0 04 00 21                             beq     R0, R4, loc_7F1A0
ROM_:0007F120 65 05                                   ldi8    R5, #j1979_mode_5
ROM_:0007F122 66 06                                   ldi8    R6, #j1979_mode_6
ROM_:0007F124 B0 05 00 21                             beq     R0, R5, loc_7F1A8
ROM_:0007F128 B0 06 00 22                             beq     R0, R6, loc_7F1B0
ROM_:0007F12C 67 07                                   ldi8    R7, #j1979_mode_7
ROM_:0007F12E 61 08                                   ldi8    R1, #j1979_mode_8
ROM_:0007F130 B0 07 00 22                             beq     R0, R7, loc_7F1B8


Code: Select all
ROM_:0008AB06 64 04                                   ldi8    R4, #j1979_mode_4
ROM_:0008AB08 B0 03 00 30                             beq     R0, R3, loc_8ABC8
ROM_:0008AB0C B0 04 00 31                             beq     R0, R4, loc_8ABD0
ROM_:0008AB10 65 05                                   ldi8    R5, #j1979_mode_5
ROM_:0008AB12 66 06                                   ldi8    R6, #j1979_mode_6
ROM_:0008AB14 B0 05 00 42                             beq     R0, R5, loc_8AC1C
ROM_:0008AB18 B0 06 00 30                             beq     R0, R6, loc_8ABD8
ROM_:0008AB1C 67 07                                   ldi8    R7, #j1979_mode_7
ROM_:0008AB1E 61 08                                   ldi8    R1, #j1979_mode_8


Here is how you are doing it currently:
Code: Select all
<table name="IFMode 0x05 -> 0x23 #1" category="Misc" type="1D" address="0x7f121" scaling="Hex8"/>
<table name="IFMode 0x05 -> 0x23 #2" category="Misc" type="1D" address="0x8ab11" scaling="Hex8"/>
<table name="DoMode 0x42 -> 0x52" category="Misc" type="1D" address="0x8ab16" scaling="Hex16"/>


Here is what i suggest:
Code: Select all
<scaling name="mode23_patch1" storagetype="bloblist">
   <data name="disabled" value="65056606" />
   <data name="enabled" value="65236606" />
</scaling>

<scaling name="mode23_patch2" storagetype="bloblist">
   <data name="disabled" value="65056606B0050042" />
   <data name="enabled" value="65236606B0050052" />
</scaling>

<table name="mode 23 part 1" category="Misc" type="1D" address="0x7f120" scaling="mode23_patch1"/>
<table name="mode 23 part 2" category="Misc" type="1D" address="0x8ab10" scaling="mode23_patch2"/>


as you can see, it matches against a larger part of the code pattern, so it is a bit safer!

Oh colby, where were you when we were doin this !!! hahaah :shock:

will that work with all the different locations of mode 23 on the different rom IDs?
unchi
 
Posts: 114
Joined: Tue Apr 25, 2006 7:02 am

Next

Return to Openport Stand-Alone Logging Beta

Who is online

Users browsing this forum: No registered users and 4 guests