Openport Stand-Alone Logging Beta

[cboles]

from above:

* total unique string storage space (11 chars * max_params)

this is shared by everything though, including the RPN scaling tokens.

i should also mention that it is smart to not have a bunch of multiplies and divides in your scalings when a single multiply would suffice. you save storage and increase speed since there is no FPU in the OP2...

the total string storage hasn't changed. i just removed the header writing bug.

Storage in number of parameters that can be logged? Its currently at 60 for can right?

So string storage is still 512 and header writing bug fixed? (Sorry I didnt catch this. haha) I thought the 512 param name limitation was the bug

[mfb]

from above:

* total unique string storage space (11 chars * max_params)

this is shared by everything though, including the RPN scaling tokens.

i should also mention that it is smart to not have a bunch of multiplies and divides in your scalings when a single multiply would suffice. you save storage and increase speed since there is no FPU in the OP2..

I did not change the scalings for those parameters as those were just generated based on rom raider log definitions. How will I implement your suggestion 'a bunch of multiplies and divides in your scalings when a single multiply would suffice. ' ?

Also what does FPU stand for?

[burnzy]

might not make sense, but thats how hamish coded evoscan, however I just checked and logid isn't required, only field that is really neccessary is to change "sample" to LogentrySeconds"
If that could be added some time in future that would be great thanks for all your work.

It knows that for MUT, each paramid request only returns one byte. Because databits=16, it knows it will have to do two requests of sequential paramid to get the two bytes it needs.

I'll consider adding some option, but how does LogID make any sense for the sample number?

the scaling is right, how does it know the second byte, where do we put that, assuming load is 00 and 01.
is there a paramid2?
On a side note, is it possible to make first column read "LogID" instead of "sample" and second entry "LogEntrySeconds" instead of "time" so that it will open up in evoscan.
At the moment I'm having to manually edit those titles into the logs. Other than that they work perfectly and is great for map tracing in evoscan.

[cboles]

In the early days of the definitions, I was a proponent of expressions like

y = x * 100 / 255

because when you were reverse engineering the code, you could see that x had a 0-255 range and you wanted y to have a 0-100 range. Expressions like this are easy to read and understand. In addition, the rational expression is exact. On a PC with a floating point processor, calculating these scaling expressions for thousands of map cells is trivial.

On a microcontroller with no floating point, speed does matter, and although you wouldn't be pushing the limits unless you were logging thousands of parameters per second, it pays in terms of speed and storage to make the expressions like this:

y = x * 0.39215686

* it doesn't contain any divides, which are slower than multiplies
* it only has one multiply
* it only has one constant to store
* the expression takes less space to store

again, this is probably not critical for you - but you asked

from above:

* total unique string storage space (11 chars * max_params)

this is shared by everything though, including the RPN scaling tokens.

i should also mention that it is smart to not have a bunch of multiplies and divides in your scalings when a single multiply would suffice. you save storage and increase speed since there is no FPU in the OP2..

I did not change the scalings for those parameters as those were just generated based on rom raider log definitions. How will I implement your suggestion 'a bunch of multiplies and divides in your scalings when a single multiply would suffice. ' ?

Also what does FPU stand for?

[mfb]

In the early days of the definitions, I was a proponent of expressions like

y = x * 100 / 255

because when you were reverse engineering the code, you could see that x had a 0-255 range and you wanted y to have a 0-100 range. Expressions like this are easy to read and understand. In addition, the rational expression is exact. On a PC with a floating point processor, calculating these scaling expressions for thousands of map cells is trivial.

On a microcontroller with no floating point, speed does matter, and although you wouldn't be pushing the limits unless you were logging thousands of parameters per second, it pays in terms of speed and storage to make the expressions like this:

y = x * 0.39215686

* it doesn't contain any divides, which are slower than multiplies
* it only has one multiply
* it only has one constant to store
* the expression takes less space to store

again, this is probably not critical for you - but you asked

Hi Colby,

I read the RPN link you put in one of the txt files. I already removed those with division and just converted it to multiplication. Ex x,4,/ to x,0.25,* x,100,*,255,/ to x,.39215686,* If using multiplication is faster than division, why does the romraider logger still have these in the definitions? I should ask them this.

Thanks!

[cboles]

because on a PC with floating point, this is a trivial amount of additional computation, and like i explained below, the original expressions give a more intuitive understanding of what is going on in the ECU code.

In the early days of the definitions, I was a proponent of expressions like

y = x * 100 / 255

because when you were reverse engineering the code, you could see that x had a 0-255 range and you wanted y to have a 0-100 range. Expressions like this are easy to read and understand. In addition, the rational expression is exact. On a PC with a floating point processor, calculating these scaling expressions for thousands of map cells is trivial.

On a microcontroller with no floating point, speed does matter, and although you wouldn't be pushing the limits unless you were logging thousands of parameters per second, it pays in terms of speed and storage to make the expressions like this:

y = x * 0.39215686

* it doesn't contain any divides, which are slower than multiplies
* it only has one multiply
* it only has one constant to store
* the expression takes less space to store

again, this is probably not critical for you - but you asked

Hi Colby,

I read the RPN link you put in one of the txt files. I already removed those with division and just converted it to multiplication. Ex x,4,/ to x,0.25,* x,100,*,255,/ to x,.39215686,* If using multiplication is faster than division, why does the romraider logger still have these in the definitions? I should ask them this.

Thanks!

[mfb]

Thanks for the explanation.

To accurately log my parameters using CAN, how many is a good limit? What's an indication if the logging is already poor? No of samples per second?

[mfb]

Colby,

You might want to check this live graph application out http://www.live-graph.org/index.html You may want to integrate this with Ecuflash and its logging feature.

[cboles]

Thanks. I used to build / write real-time (32ch x 40kS/s) nervous system monitoring hardware / software for a company I started after grad school. So of course I'm very picky about plotting waveforms and the like!

Colby,

You might want to check this live graph application out http://www.live-graph.org/index.html You may want to integrate this with Ecuflash and its logging feature.

[mfb]

Should be very interesting once you get the ecuflash logger out.

Livegraph cannot access the microsd card while OP2 is logging. It can only work with RR for now. Its a nice alternative to Excel though.

[LM_logger]

Hi Colby,

I've tried to reach you through the normal support channels re logging of afrs but to no avail.

from config sample file:

;----------------inno----------------
type=inno
; log from an innovate MTS bus via the 3/32" jack
; multiple LC-1 and other MTS devices (e.g. TC-4) are supported
;

It also states on your website that the standalone logger is able to log data via the MTS bus.

Unfortunately not all Innovate devices use the same serial protocol, the LC-1 uses version2 as I'm sure the TC-4 does also.

The problem is that I bought the openport 2.0, because of the logging from MTS bus and the standalone feature, and it appears incompatible with the LM-1 device I'm using as the LM-1 use serial protocol version 1.

Is it possible to implement this protocol into the firmware of the openport 2.0 so that logging from the LM-1 works?. At present I can get it to log inno.afr but the value is incorrect and remains constant at "128" throughout an extended log. I'm fairly certain its down to the different protocols.

If there is anything re files (config or logs) or protocol versions let me know and I'll pass them on to you.

After shelling the bucks on a device that "logs data from MTS bus" and not having it do so is a bit of a let down. Hopefully we can get this sorted or you can tell me why not.

Many thanks.

[cboles]

I can try to add support for it, but it would require some firmware changes as the current firmware only supports the version 2 protocol. The main impediment is that I don't own a LM-1 for development to test it with, and they aren't made anymore (the LM-2 is the current version they are selling). I need to look at the protocols carefully again to see if I can support both versions without any hints from the user configuration. I don't want to add support for it in a way that breaks the version 2 stuff or prevents it from reliably synchronizing on the first packet word. It might be easier to start with me building an updated version of the J2534 innovate logging sample for the PC first, and have you try that and let me know if it works, then I can port that to the OP2 logging.

Hi Colby,

I've tried to reach you through the normal support channels re logging of afrs but to no avail.

from config sample file:

;----------------inno----------------
type=inno
; log from an innovate MTS bus via the 3/32" jack
; multiple LC-1 and other MTS devices (e.g. TC-4) are supported
;

It also states on your website that the standalone logger is able to log data via the MTS bus.

Unfortunately not all Innovate devices use the same serial protocol, the LC-1 uses version2 as I'm sure the TC-4 does also.

The problem is that I bought the openport 2.0, because of the logging from MTS bus and the standalone feature, and it appears incompatible with the LM-1 device I'm using as the LM-1 use serial protocol version 1.

Is it possible to implement this protocol into the firmware of the openport 2.0 so that logging from the LM-1 works?. At present I can get it to log inno.afr but the value is incorrect and remains constant at "128" throughout an extended log. I'm fairly certain its down to the different protocols.

If there is anything re files (config or logs) or protocol versions let me know and I'll pass them on to you.

After shelling the bucks on a device that "logs data from MTS bus" and not having it do so is a bit of a let down. Hopefully we can get this sorted or you can tell me why not.

Many thanks.

[mfb]

Hi Colby,

I finally got to install LC-1 and used this code instead:

type = inno
paramname = mylc1.afr
paramid = 0x0101
scalingrpn = x,14.7,*

Previously I had it like this:

type = inno
paramname = mylc1.afr
paramid = 0x0102 ; get lambda from first LC-1
scalingrpn = x,14.7,* ; scale to an AFR

Hahaha, I forgot to remove the ones after ; As for the paramid 0x0101 and 0x0102, its okay to use either of the 2 right? I only have one channel. Both channels configured in LogWorks as lambda.

[LM_logger]

Thanks for the reply.

I understand its now retro gear(LM-1) and that it would be easier if you had one for development. I'm happy to send you mine if needed, though I understand also that there are probably minimal users with this spec and requirement, but it does leave me without functionality I wanted or believed I could have .

I think your idea if you have the time and inclination would certainly work, as evoscan is able to log from either LM-1/LC-1 so that aspect is possible. I'm happy to try and test anything you produce to see if we can get this to work as it would bring something to my setup that it was originally built/purchased for.

As far as the protocols go the differences in the first word are bits 13,9,7

In SPv1 they are always zero
In SPv2 bits 13 and 9 of first word are always 1 whilst 7 is zero.

As said above if you have the time and inclination I'd be happy to work with you on this one. Let me know what you think and if you're willing to give it a go.

Thanks for the response and giving an understanding of whats involved.

Many thanks.

I can try to add support for it, but it would require some firmware changes as the current firmware only supports the version 2 protocol. The main impediment is that I don't own a LM-1 for development to test it with, and they aren't made anymore (the LM-2 is the current version they are selling). I need to look at the protocols carefully again to see if I can support both versions without any hints from the user configuration. I don't want to add support for it in a way that breaks the version 2 stuff or prevents it from reliably synchronizing on the first packet word. It might be easier to start with me building an updated version of the J2534 innovate logging sample for the PC first, and have you try that and let me know if it works, then I can port that to the OP2 logging.

[cboles]

Accommodating the the additional protocol shouldn't be to bad, but what I need to test is if by allowing those two bitfields to be in either state I lose most of the natural ability of the system to synchronize to the first word in the stream. Dose EvoScan require you to select LM-1/LC-1 or does it auto-detect? I'm hoping that auto-detection will work.

Thanks for the reply.

I understand its now retro gear(LM-1) and that it would be easier if you had one for development. I'm happy to send you mine if needed, though I understand also that there are probably minimal users with this spec and requirement, but it does leave me without functionality I wanted or believed I could have .

I think your idea if you have the time and inclination would certainly work, as evoscan is able to log from either LM-1/LC-1 so that aspect is possible. I'm happy to try and test anything you produce to see if we can get this to work as it would bring something to my setup that it was originally built/purchased for.

As far as the protocols go the differences in the first word are bits 13,9,7

In SPv1 they are always zero
In SPv2 bits 13 and 9 of first word are always 1 whilst 7 is zero.

As said above if you have the time and inclination I'd be happy to work with you on this one. Let me know what you think and if you're willing to give it a go.

Thanks for the response and giving an understanding of whats involved.

Many thanks.

I can try to add support for it, but it would require some firmware changes as the current firmware only supports the version 2 protocol. The main impediment is that I don't own a LM-1 for development to test it with, and they aren't made anymore (the LM-2 is the current version they are selling). I need to look at the protocols carefully again to see if I can support both versions without any hints from the user configuration. I don't want to add support for it in a way that breaks the version 2 stuff or prevents it from reliably synchronizing on the first packet word. It might be easier to start with me building an updated version of the J2534 innovate logging sample for the PC first, and have you try that and let me know if it works, then I can port that to the OP2 logging.