[tunerpro] Re: Progammatic interfaces?
- From: Jason H <scorp1us@xxxxxxxxx>
- To: "tunerpro@xxxxxxxxxxxxx" <tunerpro@xxxxxxxxxxxxx>
- Date: Mon, 12 Nov 2012 14:50:55 -0800 (PST)
Spreadsheet for 16197427 attached. Use at your own risk.
May be incomplete, or completely wrong.
May cause impotence, incompetence, and incongruousness.
Let me know if it gets stripped.
________________________________
From: Jason H <scorp1us@xxxxxxxxx>
To: "tunerpro@xxxxxxxxxxxxx" <tunerpro@xxxxxxxxxxxxx>
Sent: Monday, November 12, 2012 3:45 PM
Subject: [tunerpro] Re: Progammatic interfaces?
Yes, however I've realized my file on this computer does not have the spark
calculation as well.
I'll try to attach the version with the spark table math later. **NOTE** I do
not take my math as gospel. The more dialed-in your readings are, the finer
adjustments you make. I went through several iterations, so you'll probably
have to adjust the correction factors while you get dialed-in. Failure to
adjust quickly enough can lead to engine damage, USE AT YOUR OWN RISK.
Really, it is simple, but it took some time. The PCM's map/rpm cells do not
line up with the logged cells, so you have to do some averaging to fill in the
gaps. The number of cells on a 12xxxx ECU is even smaller, so the sheet can't
be used directly (which is why we should have an algorithm do this). Since I am
super lazy, what I did (and
you'll see this) is I take a copy/paste, then iterate it each step to get the
biggest cell table then cut it down for pasting back into tunerpro.
________________________________
From: Brandon Cossette <bcossette@xxxxxxxxx>
To: tunerpro@xxxxxxxxxxxxx
Sent: Monday, November 12, 2012 3:25 PM
Subject: [tunerpro] Re: Progammatic interfaces?
Jason,
Do you have a spreadsheet for the 16197427 PCM's? If so can you share it with
me?
On Nov 12, 2012 3:06 PM, "Jason H" <scorp1us@xxxxxxxxx> wrote:
Thanks for your offer, but I already have that too. :-) I am an excel wiz. I am
just a really lazy excel wiz. Copy/pasting varies between ECUs as not all have
the same RPM and MAP cells, so one spreadsheet does not fit all, but one
algorithm can (or can be conditionally executed)
>
>There are other applications that you can do of course, that was a trivial,
>yet cool example. I needed something people could follow.
>Given the plethora of python libraries out there, it would be trivial to turn
>these into web services as well.
>Imagine developing your own dash (true a 1-second delay would be a problem,
>but if the event based interface was used this would not be a problem)
>integrating 3rd party libraries, (statistics, etc) logging data to common
>databases... Tunerpro turns into a gateway drug. You could have your
ipad, phone etc, tap into it.
>
>If an ARM/Linux version of tunerpro (just he ALDL data+python, forget the GUI)
>could be produced, then you can run the whole thing on a in-dash LCD and use
>Python or a webservice to monitor any parameter int he car with a touch
>interface. Tunerpro would develop a vertical market based on tunerpro. I
>mention ARM because of Raspberry Pi, a $25 ARM board that you can couple with
>a touchscreen. I don't know of any intel (XP) capable boards for that kind of
>money.
>
>
>
>
>
>
>
>
>________________________________
> From: Brandon Cossette <bcossette@xxxxxxxxx>
>To: tunerpro@xxxxxxxxxxxxx
>Sent: Monday, November 12, 2012 1:49 PM
>Subject: [tunerpro] Re: Progammatic interfaces?
>
>
>Jason,
>I have developed an excel macro 70% that takes blm's according to your datalog
>(with a wideband) and automatically makes corrections to your ve table. You
>can copy and paste from a generated VE Table to and from Excel and TunerPro.
>There's an import button on the front sheet to pull in a .csv datalog.
>Message me for more info.
>On Nov 12, 2012 12:59 PM, "Jason H" <scorp1us@xxxxxxxxx> wrote:
>
>
>>As a software developer myself, I would be able to probably write an
auto tune module if TunerPro exported it's readings. This is likely not going
to happen, however it would be immensely cool for me to be able
to load a script into TunerProand access and write the values as needed.
>>
>>
>>For this I would recommend Python, which has an "embedding" module (
>>http://docs.python.org/2/extending/embedding.html ), probably use SIP (
>>http://www.riverbankcomputing.com/software/sip/intro )to interface between
>>the C/C++ runtime (I'm guessing TunerPro is in C/C++) and provide python
>>objects.
>>
>>
>>If you can't follow this, this is how it would play out.
>>Tunerpro would take a command line script argument (myfile.py) or a menu
>>would allow a specification of script with a file-select dialog.
>>Depending on how the hand-off to python is implemented, the script would be
>>called at some time (either by registering functions on a particular event or
>>a time interval)
>>The python script would run, and on completion control would be reverted back
>>to TunerPro.
>>
>>
>>Example code (assuming a timer starts the script every second)
>>import tunerpro # creates the tunerpro C++/Python interface object
>>
>>def checkSparkTable(): #declare a function that does
>>the following:
>>
>> for rpm in tunerpro.ecu.rpm_graduations: # returns a list of [400, 600,
>>8000, 1000, 1200, 1400, 1600.. etc - specific to each ECU]
>> for map in tunerpro.ecu.map_graduations: # returns a list of MAP
>>graduations [0, 20, 40 ... 100]
>> rcell = tunerpro.tables("average spark retard").rpm(rpm).map(map) # for
>>brevity pick out retard cell and hold onto it.
>> scell = tunerpro.tables("main spark").rpm(rpm).map(map) # for brevity
>>pick out spark cell and hold onto it.
>> if rcell.samples > 5 and rcell.value > 0: # if we have a 5 samples
>>and we have retard
>>
>> scell.value = scell.value - 1 # decrease timing 1 degree
>>
>> rcell.samples = 0 # reset the retard cell
>>so we don't do this again until we have 5 more readings
>>
>> rcell.value = 0 # reset the retard cell
>>so we don't use old data
>>
>>
>>
>>checkSparkTable() #invoke the function
>>
>>
>>
>>
>>This will watch the average spark retard table and bump the main spark table.
>>This will be invoked and process the whole table every second. TunerPro would
>>have to come up with and publish the object model (or rather, this stuff
>>might be assigned by your definition file)
>>
>>
>>Instead of fixed-time invocations of this script, TunerPro could develop a
>>call-back model for events:
>>tunerpro.tables("main spark").onWrite.addHandler(checkSparkTable)
>>
>>
>>Where the python logic above is invoked every time the TunerPro updates the
>>values in the table from from the datastream. This is a little more
>>complicated because the C++ program needs to directly support calling python
>>functions, whereas a timed invocation just happens.
>>
>>
>>
>>
>>
>>Similarly:
>>tunerpro.ecu.flags(flagname).value = true or false
>>tunerpro.ecu.list(listname).at(value) = some value
>>
>>
>>If we come up with a library of functions, we can distribute that and people
>>can use the functions as:
>>import tunerpro
>>import jasonslibrary
>>import daveslibrary
>>
>>
>>jasonslibrary.checkSparkTable()
>>daveslibrary.adjustBLMs()
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
Other related posts:
