Logging

Any feature requests for the Syvecs Engine Control Systems
Jez
Horsham Developments
Posts: 64
Joined: Sun Jun 22, 2008 9:20 pm
Location: Newbury, Berkshire
Contact:

Logging

Post by Jez » Mon Sep 08, 2008 8:54 pm

Is there a way to display logged AFR as a load vs rpm grid (so you can see the afr for each fuelling cell) as you can with datalogit / Power FC??

pat
Syvecs Staff - Cleaner
Posts: 354
Joined: Fri May 23, 2008 9:23 am
Location: Out there... somewhere
Contact:

Re: Logging

Post by pat » Tue Sep 09, 2008 1:16 pm

Jez,

That type of functionality does not exist presently for several reasons :

First off, the system is designed from the ground up with different levels of user access in mind. For example, say a tuner was supplying a complete engine / ECU package, and they were providing some sort of a warranty with that package, then they don't want the user having access to the maps, being able to change things etc. In these circumstances the ID may be "H-Dev" instead of "GENERIC", and you could supply the user with User and Support ID files but not Root for the "H-Dev" identity; the user could then use SData to pull the logs and SView to view them, but because they don't have Root access they cannot look at or change the calibration. If you didn't even want them looking at the logs then you could neglect to give them the Support ID file, they can still grab a log for you with SData but they cannot view it with SView, but they could email it to you. For the most part we DON'T recommend that tuners do this but when there are good reasons to do so, the option is there.

In order for this to work, the data logging system needs to be independant of the calibration software. It would, therefore, not know what the map dimensions are, what the breakpoints are, etc so to draw up a grid that matches the calibration would require the user to input the map breakpoints themselves, which is not very helpful; remember the logging software cannot know about the calibration, it is there to view what is in the log (and sometimes not all of what is in the log).

The next problem that you have, let's say that we have overcome the hurdle of the logging software knowing the correct map dimensions is how to attribute a) single values and b) multiple values that should be in the same cell. For the former, let's say you have breakpoints at 1500 & 1650 mbar and 2400 & 2800 RPM but the log is showing a lambda of 0.88 at 2550 RPM and 1575 mbar. Just what do you "do" with that value ? Do you just blindly put it in all four cells that border it ? Do you put it in the nearest cell ? Both are technically "wrong", what if there is a sharp node in the plenum resonance at this point and the AFR is somewhat different to what it is at 2400 and 2800 ? Do you throw away most of the logged data because it's not close enough to the centre of a map cell ? Also, what happens if the log goes through the same cell on more than one occasion, do you use the last value encountered, average all the values, maintain min/max/avg etc ? The problem is that there will be as many opinions as there are options on what is the "right" way of doing it.

While it would be possible to do, it would be a bit of a nightmare to keep everyone happy, and there are more ways than one to crack a nut. If you limit your sample set to a single run then of course some of these problems go away, but then you could also just scroll through the log and see what happened... also there are the XY reports, you could plot map1 vs rpm and dock it, then plot lam1 vs rpm, dock it, flick to the graph window and as you scroll the current operating conditions will be visible in the XY traces. When you zoom in on the graph to display only the area of the log you're interested in, the sample set in the XY traces will be reduced to your current graph span, so you can see a plot of boost vs RPM and lambda vs RPM.

Hopefully this gives an insight into why things are done the way they are, what challenges are faced in trying to make the software as useful as possible, while trying to avoid clutter and either stuff that is at best ambiguous or at worst just misleading. There are other ways to achieve the results you're after and it's something we're looking into, something a little more along the lines of being able to "record" a run in SCal and instead of having live data in the dashboard and placing the cursor on the map based on those, being able to suspend the live data and scroll back through historic data; you'de then be able to simply look at the recorded lambda and make adjustments to the correct cell without needing to find it first, but this sort of functionality belongs in SCal not in SView. In fact, given that the dashboard will display fuelMltCll1 while in the fuel screen, it wouldn't be rocket science to just get Scal to apply the recorded fuelMltCll1 value to the current map cell, but of course you do get back to the "which cell is the right cell to apply it it?" question...

Cheers,

Pat.

jezzpalmer
Posts: 58
Joined: Thu Mar 05, 2009 10:43 pm
Location: Swansea

Re: Logging

Post by jezzpalmer » Thu Mar 26, 2009 8:20 am

pat wrote: There are other ways to achieve the results you're after and it's something we're looking into, something a little more along the lines of being able to "record" a run in SCal and instead of having live data in the dashboard and placing the cursor on the map based on those, being able to suspend the live data and scroll back through historic data; you'de then be able to simply look at the recorded lambda and make adjustments to the correct cell without needing to find it first, but this sort of functionality belongs in SCal not in SView. In fact, given that the dashboard will display fuelMltCll1 while in the fuel screen, it wouldn't be rocket science to just get Scal to apply the recorded fuelMltCll1 value to the current map cell, but of course you do get back to the "which cell is the right cell to apply it it?" question...

Hi Pat,

Has there been any progress on this, as a method of re-running run logs in SCal and overlaying them onto maps, other functions and linearisations would be very useful. :)
Regarding the issue of cell determination, would it not be possible to use the same interpolation algorithm used to determine the run-time fueling/timing etc to highlight the contributing cells (perhaps use different colouring to show the level of contribution?), then just leave it to the user to interpret what cells require adjusting, I don't see that this would be a any less accurate than analysing data in SView and translating it to the map, but would save a great deal of time.

Whilst on the topic of logging, in addition to logging to onboard memory, would it be possible to also realtime log to file on a laptop whilst one is connected, allowing for longer logging times; and perhaps realtime graphing straight to Sview?

Thanks,
Jezz.

jezzpalmer
Posts: 58
Joined: Thu Mar 05, 2009 10:43 pm
Location: Swansea

Re: Logging

Post by jezzpalmer » Tue Dec 08, 2009 9:53 am

jezzpalmer wrote: Whilst on the topic of logging, in addition to logging to onboard memory, would it be possible to also realtime log to file on a laptop whilst one is connected, allowing for longer logging times; and perhaps realtime graphing straight to Sview?

Thanks,
Jezz.
Is there any likelyhood of this happening?

Also, is there any plan to produce an input expander for the S6?

TLicense
Posts: 42
Joined: Wed Jun 18, 2008 7:33 am

Re: Logging

Post by TLicense » Fri Mar 19, 2010 12:08 pm

jezzpalmer wrote:
jezzpalmer wrote: Whilst on the topic of logging, in addition to logging to onboard memory, would it be possible to also realtime log to file on a laptop whilst one is connected, allowing for longer logging times; and perhaps realtime graphing straight to Sview?

Thanks,
Jezz.
Is there any likelyhood of this happening?

Also, is there any plan to produce an input expander for the S6?
I'd really like to see logging direct to a laptop. I know it's possible to log only the useful data by logging only under certain conditions (ie only when on boost and above 3000 rpm for instance) but you can guarantee if anything went wrong with mine it would be when those conditions aren't being met!
If it were possible to log to a laptop (or car pc) then only the HD space would be the limit...

TLicense
Posts: 42
Joined: Wed Jun 18, 2008 7:33 am

Re: Logging

Post by TLicense » Wed Apr 13, 2011 1:49 pm

Have been having a think about the logging capability over the last few days. With all the channels logging at suitable rates I only get 178 seconds of logging time!

I've been using SMON a fair bit recently to monitor stuff on the fly, would it be incredibly difficult to enable SMON to log to a HD as it's running?

Alternatively, what's the chances of being able to fully sort out the CAN link with 3rd party data loggers? I know in this thread viewtopic.php?f=4&t=251 it was mentioned that it should be possible with a Motec ADL. Could the same be said for the ACL or any of the Cosworth (Pi) range? Are there any other datalogging solutions out there? I'm not interested in a dash system, just pure datalogging.

Perhaps I need to be a bit more ruthless in what data I record? (My personal opinion is more is always more! :D )

Tony

black
Posts: 7
Joined: Sat Jan 16, 2016 7:38 am

Re: Logging

Post by black » Thu Jan 28, 2016 11:01 am

Is there anything in development about these functions in S6GP?

Logging direct to Laptop?

Logging Lambda vs Lambda Target and "analyzer function" to calc. difference and match to fuel sites in calibration file?

stevieturbo
Posts: 838
Joined: Sun Dec 07, 2008 2:04 pm

Re: Logging

Post by stevieturbo » Thu Jan 28, 2016 12:28 pm

black wrote:Is there anything in development about these functions in S6GP?

Logging direct to Laptop?

Logging Lambda vs Lambda Target and "analyzer function" to calc. difference and match to fuel sites in calibration file?

You can already stream data direct to laptop for logging.

And a fuel correction table you'd think would be a very simple and helpful tool. No different really than short term and long term fuel trims albeit more targeted.

black
Posts: 7
Joined: Sat Jan 16, 2016 7:38 am

Re: Logging

Post by black » Thu Jan 28, 2016 1:04 pm

stevieturbo wrote:
black wrote:Is there anything in development about these functions in S6GP?<br abp="642"><br abp="643">Logging direct to Laptop?<br abp="644"><br abp="645">Logging Lambda vs Lambda Target and "analyzer function" to calc. difference and match to fuel sites in calibration file?
<br abp="646"><br abp="647"><br abp="648">You can already stream data direct to laptop for logging.<br abp="649"><br abp="650">And a fuel correction table you'd think would be a very simple and helpful tool. No different really than short term and long term fuel trims albeit more targeted.
Maybe my english is to bad so I do not fully understand your last sentence. Sorry :(

OEM call it "long term fuel trim", some call it "tune by statistics", some call it "mixture map" - result is always similar. Ecu analyzes how good target is hit by runtime value and calculates a correction value after a minimum number of cell) hits.

I did not find such a function in S6? Is there a long term fuel trim in S6?

stevieturbo
Posts: 838
Joined: Sun Dec 07, 2008 2:04 pm

Re: Logging

Post by stevieturbo » Thu Jan 28, 2016 6:51 pm

There is currently no option for recording lambda or fuel corrections in Syvecs.

I would like this too, other ecu's offer it and it's a very helpful feature.

Post Reply