the math in the above version has a flaw. it works alright... but...
will fix it later tonight.
the math in the above version has a flaw. it works alright... but...
will fix it later tonight.
well a week of progress is great so far,
this version fixes the math in previous versions (which was an attempt to demonstrate an idea) with a bit more consistent math that actually works.
i was overcomplicating it.
it kinda ends up making each data point relationship into a vector, the magnitude of that vector defines its weight within the average. it is maturing quite a bit and finally giving good trim maps, making this an awesome linear analyzer that may end up being good at relating tons of different kinds of data to its target tuning cell.
so basically, the closer the data point (your trim vs rpm vs map) is to the target 'observer' point (the dead center of the ve table cell), the more effect it has on that observer. it uses a proper slope calculation with noise filter highpass (meaning data from too far away of cells has zero effect) and clipping at the top (meaning stuff close by is always 100%)
we don't have to worry about a hysteresis or anything near cell boundaries so data near a boundary will affect neighboring cells, since it doesn't care about literal cell boundaries, it just tries to gather surrounding data in a way which makes sense, and each data point can affect any cell 'within its reach' with varying effect.
it also has a visualizer now, so you can see how this interpolator is actually mapping its data points to cells,
veinterp.png
i also fixed a one-off bug in the knock analyzer so the points are in the right spot... added a few other small tidbits.
enjoy
http://fbodytech.com/files/trimalyzer-0.3.1a.zip
Seem like a great idea to me! Not only for narrowband, I thing the same algorithm could be used for wideband data. Will make tuning much more precise.
This corresponds perfectly with the idea I've been developing for a while: a standalone datalogger that would plug into ALDL port like small ELM327 adapter and log to .csv file on SD card. You could collect a LOT of data just driving normally without any cables or laptops cluttering the car!
So I'll be glad to test your software as I progress with this datalogger device :)
I tested the software on Saturday and it seems like it will be great. Ill try .3.1a.when the weather breaks. Great work steveo!
i did that with linux and a raspberry pi once.
ncurses interface, cheapo ebay backup camera as a screen (optional).
it worked as soon as you turned the igntion on, added small wifi adaptor and some scripts so it automatically uploaded logs when i parked in my driveway
http://fbodytech.com/misc/raspberry-...arddatalogger/
the software is old but you could probably screw around and make it work?
i've decided modifying bins in place is something i'm not going to do
instead the user will:
- use my analyzer to get their data
- copy their entire VE table from tunerpro
- click a button in the analzyer (this will modify the data in the clipboard)
- paste the modified VE table back into tunerpro
checks will be made to ensure the copied data matches the layout of the table in the analyzer, and if failed, it will refuse to modify it.
preset table layouts will be available for common masks (and to assist in cases of multiple VE tables in the same bin, etc)
MAF analysis will work in the same way
sound easy enough?
it'll go ahead and display your modified VE table too, so you know what you'll be pasting.
Last edited by steveo; 03-21-2017 at 10:03 PM.
Evening Steveo.
Some feedback for you on 31a.
I like the VE Analysis display although these now show a range of 101 - 88 with the same data.
That's more of what i was expecting switching from Wideband to narrowband than in the 1st version.
The main bulk of the VE table is about 97 to 93 with a few dips.
Not an issue for me as i'll go back to OLSD after the ticket. The lean surge & knock is back with the narrowband O2's.
What i did wonder about is where you feel the MAP & RPM boundaries occur.
Whilst writing my analyzer I plumped for the row/column value as the MAX for that cell, ie the 20 MAP cell was for upto 20. 20.01 to 25 went in the 25 MAP cell.
I don't know whether it would be better to use the value as the center point for the cell.
THE $EE VE table goes from 20 to 100. Using my stratagy the VE values are plotted as 15 to 100 MAP.
Conversely we could have 20 to 105 if using the lower bound or centered would give 17.5 to 102.5.
The same would go for the RPM's although that has a 7000 column which would be sufficient for the 8051 PCM
I wondered your thoughts and thinking on this.
Also i think the Knock Count Map & VE Interpolation Map screens would be better suited to having their own tab rather than a button at the bottom of the Visual Analysis page.
I also think the Process Logs button should be at the bottom of the main window, after you have scanned down / altered any settings.
What is this written in ? i guess you are using QT again?
Excellent stuff!
Mitch
'95 Z28 M6 -Just the odd mod.
'80 350 A3 C3 Corvette - recent addition.
yupWhat is this written in ? i guess you are using QT again?
depends how it's labeled, as far as i know generally when you see a 20kpa column (if labeled properly), it's 0-20kpa. the next column labeled 30kpa is actually 20-30kpa. this is kinda ambiguous i know, in eehack i drew my labels right on the cell borders.What i did wonder about is where you feel the MAP & RPM boundaries occur.
Whilst writing my analyzer I plumped for the row/column value as the MAX for that cell, ie the 20 MAP cell was for upto 20. 20.01 to 25 went in the 25 MAP cell.
I don't know whether it would be better to use the value as the center point for the cell.
THE $EE VE table goes from 20 to 100. Using my stratagy the VE values are plotted as 15 to 100 MAP.
Conversely we could have 20 to 105 if using the lower bound or centered would give 17.5 to 102.5.
The same would go for the RPM's although that has a 7000 column which would be sufficient for the 8051 PCM
I wondered your thoughts and thinking on this.
im making three modes for ve analysis
strict will put the data in the cell only,
loose will put the data in the cell but with a hystersis-like boundary (so if it's right near a boundary, it affects two cells),
interploation mode uses pure geometric analysis and relates things to the dead center of the cell, with weighted averages and crap.
im thinking early on, people will use interpolation to get the ve table approximated, then 'loose' mode will be good for 'fine grained' adjustments
considering the visualization tab really does the same thing and there's no reason to view both at the same time or flip between them, i think im going to re-use the page at least for now.Also i think the Knock Count Map & VE Interpolation Map screens would be better suited to having their own tab rather than a button at the bottom of the Visual Analysis page.
same with the fuel mapping. since ve and maf analysis performs similar functions but aren't often used simultaneously, i'll leave them on the same page, it'll let me re-use a lot of controls and code more easily
kinda fits with this being a general purpose tool with different operating modes
perhaps. i dont even really like the main window layout much. i'll work on that a bit later after the analyzer is working properlyI also think the Process Logs button should be at the bottom of the main window, after you have scanned down / altered any settings.
Last edited by steveo; 03-22-2017 at 01:29 AM.
Thanks for reminding this project, I think I've already stumbled upon it some time ago on your website.
I'm doing something much simpler and cheaper - ATXmega with USB interface and SD card, so the device would work as standalone datalogger, and when connected to PC as normal ALDL virtual COM interface. The whole thing shouldn't cost more than $25 in parts.
I hate driving with laptop on the seat and cables cluttering the interior, and the PCB will be about the size of ALDL plug itself.
For me the idea is to use it for fine tuning rides - after I have tuned it, people can normally drive with this device, and after some time I have TONS of data to perfect the tune.
Going back to your program, I also think it is best to leave bin modification in TunerPro. It's better to know exactly what is being modified.
Last edited by dzidaV8; 03-22-2017 at 01:49 AM.
you should open source your code and make it at least kinda adaptable to different aldl data sets; i'm sure other people would like to build oneI'm doing something much simpler and cheaper - ATXmega with USB interface and SD card, so the device would work as standalone datalogger, and when connected to PC as normal ALDL virtual COM interface. The whole thing shouldn't cost more than $25 in parts.
i'm making major progress, i'd say the ve analyzer is almost done.
i have all three analysis modes working very well, i have a new method of table size defining with a better ui, a preset system, and i almost have the system working that modifies tables copied to the clipboard, so implimenting the trim modifications should be a few clicks for tunerpro users.
now, i have RPM as a row and MAP as a column.
are there many XDF files that have the oppisite (RPM columns and MAP rows?)
im wondering if i should add that option either by allowing my own table to rotate, or to allow clipboard data to be parsed in an alternate way.
Bookmarks