[tunerpro] Re: Progammatic interfaces?
- From: Ryan Eaton <architechnik@xxxxxxxxx>
- To: tunerpro@xxxxxxxxxxxxx
- Date: Tue, 13 Nov 2012 06:43:54 -0800
I got the attachment as well. What type of engine is that spreadsheet for?
Also, I would like to see a manually entered delay or delay algorithm for
some of the sensors readings built into TPRT. I know my WB O2 is terrible
at matching to the RPM and timing, especially at throttle changes. That's
fine when I do a single pull, because i can just shift the entire readout a
few cells. Although when I try to create a cruise log (to see that I'm in
pretty good shape for regular trims) the sudden throttle changes throw off
the WB readings for certain RPM and can disturb the averages pretty
significantly for particular cells.
-Ryan
On Tue, Nov 13, 2012 at 3:58 AM, Carl-Otto Rustad <carl-otto@xxxxxxx> wrote:
> Thank You Jason!
> I got the first one with the attached file.
> It went through and made it all the way
> to Norway, at the speed of light I guess.
> I'm looking at it now, looks nice and must
> have taken some time to come up with.
>
> Carl.
>
>
> ------ Original Message ------
> *Received: * Tue, 13 Nov 2012 02:19:47 AM CET
> *From: * Jason H <scorp1us@xxxxxxxxx>
> *To: * "tunerpro@xxxxxxxxxxxxx" <tunerpro@xxxxxxxxxxxxx>
> *Subject: * [tunerpro] Re: Progammatic interfaces?
>
>
> If not here it is http://www.filedropper.com/scorp1us-blm-worksheet-spark
>
> Sorry for the emails - it looks like it didn't go out and I had to go to
> the other computer to get it again.
>
> Once again, USE AT YOUR OWN RISK
> It may cause impotence, inconitnence and conflatulation.
> Bearing may lose their bearing. Rods may become springs and pistons might
> not pis.
>
> ------------------------------
> *From:* Jason H <scorp1us@xxxxxxxxx>
> *To:* "tunerpro@xxxxxxxxxxxxx" <tunerpro@xxxxxxxxxxxxx>
> *Sent:* Monday, November 12, 2012 8:05 PM
> *Subject:* [tunerpro] Re: Progammatic interfaces?
>
> Did everyone get the attachment?
>
> ------------------------------
> *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()
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Visit the TunerPro web site at http://www.tunerpro.net/ To unsubscribe,
> email tunerpro-request@xxxxxxxxxxxxx with "unsubscribe" in the Subject,
> or visit http://www.tunerpro.net/mailingList.htm.
>
Other related posts:
