Logging with the (Beta) Standalone Tactrix Cable Logger (No More Computer!)
Mar 7, 2010, 02:25 PM
#46
Newbie
Join Date: Nov 2009
Location: Ireland
Posts: 20
Likes: 0
Received 0 Likes
on
0 Posts
Please see log on previous post. https://www.evolutionm.net/forums/8068763-post45.html
Only just picked this line up after reading again,
so do you think or know that the LM-1 output is not serial data, would seem a little odd do you not think? and if so what is the data type? after all they both are capable of powering the same guages without any differences.
Hmmm, I wonder if i hacked the sensor output#2 direct to the standalone (effectively bypassing the LM-1 unit) would it work?
Edited to note:
The last idea above won't work I believe,as the sensor outputs a non-linear resistive signal, which is then converted to a linear voltage by the units and it appears that the bit that does this on the LC1 is located on the connector to sensor whilst with the LM1 its happens within the unit itself, so hacking the wiring before the unit will not work on the LM1. Bugger, there goes another idea.
Support ticket opened with tactrix on subject and hopefully they'll be able to shed some light.
Only just picked this line up after reading again,
so do you think or know that the LM-1 output is not serial data, would seem a little odd do you not think? and if so what is the data type? after all they both are capable of powering the same guages without any differences.
Hmmm, I wonder if i hacked the sensor output#2 direct to the standalone (effectively bypassing the LM-1 unit) would it work?
Edited to note:
The last idea above won't work I believe,as the sensor outputs a non-linear resistive signal, which is then converted to a linear voltage by the units and it appears that the bit that does this on the LC1 is located on the connector to sensor whilst with the LM1 its happens within the unit itself, so hacking the wiring before the unit will not work on the LM1. Bugger, there goes another idea.
Support ticket opened with tactrix on subject and hopefully they'll be able to shed some light.
Last edited by Number_6; Mar 7, 2010 at 05:53 PM.
Mar 7, 2010, 07:06 PM
#47
Newbie
Join Date: Nov 2009
Location: Ireland
Posts: 20
Likes: 0
Received 0 Likes
on
0 Posts
Ah ha
Took a bit of digging
The LM1 and LC1 both use the serial protocol but different versions.
From Innovate site:
So there is an answer to the query. and it seems serial protocol is backward compatible. I could get this working yet
Took a bit of digging
The LM1 and LC1 both use the serial protocol but different versions.
From Innovate site:
Note: The serial protocol spec 1 is used for the LM-1 (six channel) only. The LC-1 and other Innovate products utilize serial protocol 2 (32 channels). Serial protocol 2 is available by request. Please contact technical support; please include information on your application and if the device in which the serial protocol will be used in will be for resale.
We also offer an SDK that is available for download on our Support page.
We also offer an SDK that is available for download on our Support page.
Serial Protocol Format Version 2
This protocol supercedes Version 1 of the LM-1 serial protocol. It is designed to be backward
compatible with protocol version 1. Devices that follow this protocol definition will be compatible
with both.
The change to ISP2 allows to expand the data logging protocol to up to 32 or more channels. It
also allows the user to add additional channels for logging and display at will.
The serial data consists of packets, (in normal operation every 81.92 msec).
The packets are organized as 16 bit words in big endian order.
The first 2 Bytes of a packet are the packet header. Both bytes of a packet header have their high
bit set. The header also contains the total length of a packet, which may be modified by any datasource
device in the chain.
Protocol Version 1 is distinguished from protocol version 2 by bits 13, 9 and 7. In Version 1 these
bits are always 0. Version 1 consists of a LM-1 packet only.
This protocol supercedes Version 1 of the LM-1 serial protocol. It is designed to be backward
compatible with protocol version 1. Devices that follow this protocol definition will be compatible
with both.
The change to ISP2 allows to expand the data logging protocol to up to 32 or more channels. It
also allows the user to add additional channels for logging and display at will.
The serial data consists of packets, (in normal operation every 81.92 msec).
The packets are organized as 16 bit words in big endian order.
The first 2 Bytes of a packet are the packet header. Both bytes of a packet header have their high
bit set. The header also contains the total length of a packet, which may be modified by any datasource
device in the chain.
Protocol Version 1 is distinguished from protocol version 2 by bits 13, 9 and 7. In Version 1 these
bits are always 0. Version 1 consists of a LM-1 packet only.
Apr 3, 2010, 05:02 PM
#51
Evolving Member
iTrader: (4)
Join Date: Jun 2007
Location: NorCal
Posts: 223
Likes: 0
Received 0 Likes
on
0 Posts
So I finally got this to work (big thanks to weebles and xPRimNT), but I can't get the LC-1 to work.
Link to my original post:
http://www.***************/forums/sh...ad.php?t=29450
Here is my log.cfg:
;----------------inno----------------
type=inno
; log from an innovate bus via the 3/32" jack
; currently the LC-1 is the only supported device
; in the "inno" case the parameters are already pre-defined, you just
; need to reference them by name so that they are included in the log
; output. note that these parameters won't become valid until the LC-1
; has been calibrated and the sensor is warmed up.
paramname = mylc1.afr
paramid = 0x0101
scalingrpn = x,14.7,*
It will log everything else, but the values in the mylc1.afr column all read as "0". It did the same when I tried to log directly into evoscan....
I've read here that others have experienced the same problem, but with the LM-1. I at least get a value in the column...(https://www.evolutionm.net/forums/ev...-computer.html)
Here are some pieces of the puzzle:
Windows 7
Evoscan 2.6
"OUT" connected via 2.5mm serial port and linked to Tactrix-seated properly
"IN" 2.5mm serial port from LC-1 is plugged-seated properly
Logging attempt done when 02 sensor is hot/LC-1 sensor light is "steady on"
02 has been calibrated properly (but I will attempt again)
Engine is ON with logging attempt
Any help is most appreciated!
Link to my original post:
http://www.***************/forums/sh...ad.php?t=29450
Here is my log.cfg:
;----------------inno----------------
type=inno
; log from an innovate bus via the 3/32" jack
; currently the LC-1 is the only supported device
; in the "inno" case the parameters are already pre-defined, you just
; need to reference them by name so that they are included in the log
; output. note that these parameters won't become valid until the LC-1
; has been calibrated and the sensor is warmed up.
paramname = mylc1.afr
paramid = 0x0101
scalingrpn = x,14.7,*
It will log everything else, but the values in the mylc1.afr column all read as "0". It did the same when I tried to log directly into evoscan....
I've read here that others have experienced the same problem, but with the LM-1. I at least get a value in the column...(https://www.evolutionm.net/forums/ev...-computer.html)
Here are some pieces of the puzzle:
Windows 7
Evoscan 2.6
"OUT" connected via 2.5mm serial port and linked to Tactrix-seated properly
"IN" 2.5mm serial port from LC-1 is plugged-seated properly
Logging attempt done when 02 sensor is hot/LC-1 sensor light is "steady on"
02 has been calibrated properly (but I will attempt again)
Engine is ON with logging attempt
Any help is most appreciated!
Apr 4, 2010, 12:31 PM
#53
Newbie
Join Date: Nov 2009
Location: Ireland
Posts: 20
Likes: 0
Received 0 Likes
on
0 Posts
;----------------inno----------------
type=inno
; log from an innovate bus via the 3/32" jack
; currently the LC-1 is the only supported device
; in the "inno" case the parameters are already pre-defined, you just
; need to reference them by name so that they are included in the log
; output. note that these parameters won't become valid until the LC-1
; has been calibrated and the sensor is warmed up.
paramname = inno.afr
paramname = inno.lambda
type=inno
; log from an innovate bus via the 3/32" jack
; currently the LC-1 is the only supported device
; in the "inno" case the parameters are already pre-defined, you just
; need to reference them by name so that they are included in the log
; output. note that these parameters won't become valid until the LC-1
; has been calibrated and the sensor is warmed up.
paramname = inno.afr
paramname = inno.lambda
You don't need to define them again just reference them as shown.
As regards evoscan, check you have selected the LC-1 in the dropdown box for the external wideband sensor.
Other than that
I've a LM-1 and can get a value in the columns, but its constant and not what is expected.
Support ticket sent to Tactrix weeks ago and not even a reply as of yet
. Don't think this side of things is at the top of their list, seems more balanced towards the main logging aspect of the device. Shame really when you've taken the time and money and asked the questions before shelling out the cash for a piece of kit.The LM-1 is different from LC-1 in protocols used to transfer data, but that shouldn't effect yourself. Try the above with config and evoscan.
Edited to note: that this line below needs to be included in the config file as well, even if you are just trying to log inno
type=mrmacan;
Last edited by Number_6; Apr 4, 2010 at 12:34 PM.
Apr 4, 2010, 02:56 PM
#55
Newbie
Join Date: Nov 2009
Location: Ireland
Posts: 20
Likes: 0
Received 0 Likes
on
0 Posts
I've only been keeping an eye on this thread for my own issues, didn't realise
As I've a LM-1 it don't really matter does it? Given that we know they are using different protocols?
Could you direct me to a page regarding the changes for the LC-1?
Apr 4, 2010, 06:13 PM
#56
Evolved Member
iTrader: (1)
Join Date: Jun 2008
Location: Kanagawa, Japan
Posts: 1,018
Likes: 0
Received 0 Likes
on
0 Posts
I haven't been keeping up much on the standalone logging of the OP2.0 but I was wondering what Colby meant by this:
http://forums.openecu.org/viewtopic.php?f=57&t=4566
How does this checkbox patching work?
Originally Posted by Colby
Just wanted everyone to know that the latest beta on the site now supports simple checkbox patching of the EVO X (and probably other Mitsu CAN ROMs) ROMs for the "mode23" RAM logging feature. This "smart" patching system is a much easier / safer way to do this patch without having to have a specific patch for your particular ROM.
How does this checkbox patching work?
Apr 4, 2010, 09:00 PM
#57
Evolving Member
iTrader: (4)
Join Date: Jun 2007
Location: NorCal
Posts: 223
Likes: 0
Received 0 Likes
on
0 Posts
The lines in bold are the only ones needed to get the logger to log the afrs if everything is right with LC-1.
You don't need to define them again just reference them as shown.
As regards evoscan, check you have selected the LC-1 in the dropdown box for the external wideband sensor.
Other than that
You don't need to define them again just reference them as shown.
As regards evoscan, check you have selected the LC-1 in the dropdown box for the external wideband sensor.
Other than that
The LC-1 is fully functional as I can view my AFR's in logworks, but logs nothing in evoscan...
I haven't got a clue either brutha....
Apr 5, 2010, 12:43 AM
#59
I haven't been keeping up much on the standalone logging of the OP2.0 but I was wondering what Colby meant by this:
http://forums.openecu.org/viewtopic.php?f=57&t=4566
How does this checkbox patching work?
http://forums.openecu.org/viewtopic.php?f=57&t=4566
How does this checkbox patching work?
I havn't tested it yet... makes my stuff redundant
