Members Login
Username 
 
Password 
    Remember Me  
Post Info TOPIC: Dragtools - development starting...


Guru

Status: Offline
Posts: 2338
Date:
RE: Dragtools - development starting...



Sounds good - looking forward waiting what it looks like on the screen.

We still have this issue that the RPM/SEC is not verified with real world results, I believe there is a factor of 1.28, 2 or even 2.56 that should be applied - but its one of these things we can only find out with real world testing (without excessive amount of desktop debugging).




__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Senior Member

Status: Offline
Posts: 186
Date:

sportbikeryder wrote:

On another, general programming note, Is there a particular reason why all of the programming is performed with pulldown menu's rather than a user input option?

Seems it could be much easier to program if the box was left open for typing rather than to have to code in all of the options for every pulldown. Also, this would allow users to fine tune or even try new ranges of items as appropriate.

perhaps a suggested max / min range listed woudl be appropriate itf this was done.


Note, this is not necessarily directed at you Ballad, just an overall observation.

John



There in no reason, just design decision. I used the inputbox function
to implement custom rear tire size as you requested. Are there other
generally used tire size that I can include?
Let me have the list of sizes as a convenience, besided the "custom" option.
I set front sprocket from 14 to 22 teeth and rear from 39 to 47.
Hope this is enough without a "custom" tooth size.



 



__________________


Guru

Status: Offline
Posts: 1247
Date:

Sounds good Ballad. Common tire sizes are 180/55, 190/50, 190/55, and 200/50 , all 17"

As for gearing, the front is fine, The rear that is used for dragracing is often larger, somewhere in the 49-53 tooth range. The overall ratio's are not extreme, since a 19 or 20 tooth front is used.

__________________


Senior Member

Status: Offline
Posts: 186
Date:

PetriK wrote:


Sounds good - looking forward waiting what it looks like on the screen.

We still have this issue that the RPM/SEC is not verified with real world results, I believe there is a factor of 1.28, 2 or even 2.56 that should be applied - but its one of these things we can only find out with real world testing (without excessive amount of desktop debugging).



The modified dragtools modules are now available into ballad2_fork, with a
large range of sprocket and tires, besides a direct input of "custom"
rear tire circumference (in millimeters).


 



-- Edited by ballad2 on Monday 14th of February 2011 11:01:05 PM

__________________


Senior Member

Status: Offline
Posts: 186
Date:

ballad2 wrote:

 

sportbikeryder wrote:

On another, general programming note, Is there a particular reason why all of the programming is performed with pulldown menu's rather than a user input option?

Seems it could be much easier to program if the box was left open for typing rather than to have to code in all of the options for every pulldown. Also, this would allow users to fine tune or even try new ranges of items as appropriate.

perhaps a suggested max / min range listed woudl be appropriate itf this was done.


Note, this is not necessarily directed at you Ballad, just an overall observation.

John



There in no reason, just design decision...

 

 




If the linear acceleration concept proofs to be useful, I could allow to set

it to an arbitrary decimal value and calculate back the RPM/sec values for

each gear. This would provide finer tuning granularity on top of a

uniform frame of reference.



-- Edited by ballad2 on Tuesday 15th of February 2011 09:00:47 AM

__________________


Veteran Member

Status: Offline
Posts: 26
Date:

Hi,
with the dragtools active,
 is it just the ignition retard slowing acceleration rate, or are the stp's involved with this as well ?


thanks in advance,
regards Blair.

__________________


Senior Member

Status: Offline
Posts: 186
Date:

gixxted wrote:

Hi,
with the dragtools active,
is it just the ignition retard slowing acceleration rate, or are the stp's involved with this as well ?


thanks in advance,
regards Blair.



In the current dragtools.c implementation, only ignition retard is takenn into account. It is a very small module, so it is not a coding issue, it would be an
interesting subject to discuss if there are facts or positive experiences about it.
At this time the issue is more detecting when to start a reaction rather then
which reaction is more effective.

 



__________________


Senior Member

Status: Offline
Posts: 186
Date:

PetriK wrote:


Sounds good - looking forward waiting what it looks like on the screen.

We still have this issue that the RPM/SEC is not verified with real world results, I believe there is a factor of 1.28, 2 or even 2.56 that should be applied - but its one of these things we can only find out with real world testing (without excessive amount of desktop debugging).



The improved module with gearing and finer grained RPM/sec is ready.
Only K8dragtools.vb and designer have to be copyed from ballad2_fork.
Are you going to integrate it into mainstream code?


 



__________________


Guru

Status: Offline
Posts: 2338
Date:

Yep, looked at it one day - but need to find out the correct rpm/sec values first. Now i am a bit worried that ll this leads into confusion as the ratio is not yet same as real world.

Looking forward into hearing feedback of the ratios to modify the multipliers.


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Senior Member

Status: Offline
Posts: 186
Date:

PetriK wrote:

Yep, looked at it one day - but need to find out the correct rpm/sec values first. Now i am a bit worried that ll this leads into confusion as the ratio is not yet same as real world.

Looking forward into hearing feedback of the ratios to modify the multipliers.



The idea under my design is to measure the best possible linear acceleration
(which an accelerometer or by taking intermediate timing)
before wheel spinning and adjust RPM/sec to match that value. Then the effective
RPM/sec can be extracted by logs and coefficients adjusted, but that is not
relevant since the primary reference and final goal is the linear acceleration.

 



__________________


Guru

Status: Offline
Posts: 2338
Date:

Yes, understand the idea - anyhow if the basic assumption of rpm/sec is incorrect it does not help.

Would rather touch this when we have the conversion rate corrected. Live tas taught to only build on a solid foundation. This is not yet solid, before we can get some track data.


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Senior Member

Status: Offline
Posts: 186
Date:

PetriK wrote:

Yes, understand the idea - anyhow if the basic assumption of rpm/sec is incorrect it does not help.

Would rather touch this when we have the conversion rate corrected. Live tas taught to only build on a solid foundation. This is not yet solid, before we can get some track data.



Ok, no problem. Anyway you can notice that the simple display of linear
acceleration better helps to set RPM/sec: as a matter of fact with current default values the linear acceleration in 2a and 3a gear are higher than in 1a,
which is likely to be  the other way around.

 



__________________


Guru

Status: Offline
Posts: 1233
Date:

PetriK wrote:

Yes, understand the idea - anyhow if the basic assumption of rpm/sec is incorrect it does not help.

Would rather touch this when we have the conversion rate corrected. Live tas taught to only build on a solid foundation. This is not yet solid, before we can get some track data.



Would it help to verify the conversion rate if we logged the calculated rpm/sec value to the data logging files?



__________________

site_logo_small.png

www.WoolichRacing.comTune your bike to the Limit with our Advanced ECU Flashing Products



Senior Member

Status: Offline
Posts: 186
Date:

jkwool wrote:

 

PetriK wrote:

Yes, understand the idea - anyhow if the basic assumption of rpm/sec is incorrect it does not help.

Would rather touch this when we have the conversion rate corrected. Live tas taught to only build on a solid foundation. This is not yet solid, before we can get some track data.



Would it help to verify the conversion rate if we logged the calculated rpm/sec value to the data logging files?

 



That can be easily done by importing the .csv into excel. It would be
useful to display non only the first derivative of RPM(t), but also the
second derivative. The time intervals where the second derivative is
negative are unlikely to be candidates for wheel spinning, while
regions where  RPM(t) has upward concavity are higly suspect.

 



__________________


Senior Member

Status: Offline
Posts: 186
Date:

jkwool wrote:

 

PetriK wrote:

Yes, understand the idea - anyhow if the basic assumption of rpm/sec is incorrect it does not help.

Would rather touch this when we have the conversion rate corrected. Live tas taught to only build on a solid foundation. This is not yet solid, before we can get some track data.



Would it help to verify the conversion rate if we logged the calculated rpm/sec value to the data logging files?

 



With the new dragtools module you can also log the effective bike speed
and its linear acceleration! I would go further and save final transmission
ration and rear wheel circumference in a stable place into the bin file.
Default values are available for each kind of ecu and could be modified
with a specific form (independent from the new dragtools form).
This would make available the effective bike speed and acceleration at runtime in the ecu for any future use we might think about.



 



__________________


Member

Status: Offline
Posts: 10
Date:

I can see I'm gona need some tuition here but MAN this is exciting stuff.


__________________


Senior Member

Status: Offline
Posts: 186
Date:

ballad2 wrote:

 

With the new dragtools module you can also log the effective bike speed

and its linear acceleration! I would go further and save final transmission
ration and rear wheel circumference in a stable place into the bin file.
Default values are available for each kind of ecu and could be modified
with a specific form (independent from the new dragtools form).
This would make available the effective bike speed and acceleration at runtime in the ecu for any future use we might think about.



 



Given gear position and cluch switch position we can save at each time a good guess
of the bike speed. The first usage I can think about is disable launch control over
a specific (very low) speed threshold. This would help to have the same bin file for
both drag and normal street usage. For example the current implementation does
not fit down shifting  at high rev.


__________________


Veteran Member

Status: Offline
Posts: 26
Date:

Its been quiet about this, have there been used on track now?

I am tempted to at least start to use the 2 step limiter part of it,

cause my start is really bad now due to new rear tires, both change in brand, profile & construction.

I looked at my datalogging from last race and calculated what 1st gear had an average 2538 rpm/sec, 2nd 3634rpm/sec and 3 1076rpm/sec

note what this is a much heavier bike with a small backwheel (1775mm)
and a 3300rpm drop from releasing the clutch

 

I have a few questions before giving it a go

Q1: if I only want to use the 2step limiter, should I then put in 0deg on all gears?

Q2:I use clutch to downshift, will the 2 step give me a problem for the rest of laps

Q3: Is there a way to switch dragtool on/off?
guess its needed for tire burnout in dragracing, and I need to be able to steer with rearwheel spin during race:

/3wheelracer
K8 gixxer with gen2 bin



-- Edited by 3wheelracer on Sunday 3rd of July 2011 11:49:37 AM

Attachments
__________________


Veteran Member

Status: Offline
Posts: 26
Date:

I put all zeros in the gears, and have my 2-step at 7400 with an MTC clutch no wheelie bars.

__________________


Newbie

Status: Offline
Posts: 4
Date:

Hey.

I'am Alex from Germany!

Has anyone of you tested the Dragtools on the race-track jet?

I also would like to know if there is a way to switch the dragtools during the race on/off?

 

Thanks,

 

Alex



__________________


Veteran Member

Status: Offline
Posts: 30
Date:

does anyone have any good base settings I could use to start using this for drag racing?


__________________


Guru

Status: Offline
Posts: 1247
Date:

With continued use of the 2-step feature, both myself and a new prostreet using ECU Editor "Blue Ballz" have found that fuel needs to be added shile on teh 2-step in order to build boost.

An enhancement may be to include an option to add "X"% of fuel while on the 2-step to promote an "antilag" for turbo applications.



-- Edited by sportbikeryder on Monday 2nd of July 2012 06:59:03 PM

__________________


Senior Member

Status: Offline
Posts: 148
Date:

That would be a nice feature I am still using ms0 ms1 feature to succeed.

__________________

LIFE IS SHORT RIDE HARD



Guru

Status: Offline
Posts: 1233
Date:

sportbikeryder wrote:

With continued use of the 2-step feature, both myself and a new prostreet using ECU Editor "Blue Ballz" have found that fuel needs to be added shile on teh 2-step in order to build boost.

An enhancement may be to include an option to add "X"% of fuel while on the 2-step to promote an "antilag" for turbo applications.



-- Edited by sportbikeryder on Monday 2nd of July 2012 06:59:03 PM


 I have added this as an enhancement request. I wish i had more time to action some of this stuff straight away but at least it is being logged so it is not forgotten...



__________________

site_logo_small.png

www.WoolichRacing.comTune your bike to the Limit with our Advanced ECU Flashing Products



Guru

Status: Offline
Posts: 1247
Date:

If I am not mistaken, the boostfuel is using the ECU "COV1" portion of the code to add fuel on a temporary basis and re-writing the value of the COV1 10 times a second to correspond to teh values in the boostfuel lookup tables.

The "Yosh box" used to use these values as well I believe to re-program the computer.
There was talk on a GEN1 about using the yoshbox variables to enrich for nitrous some time ago.
If the GEN2 works the same way, a resistor placed across pins 55 0r 56 may do something to add a bit of fuel.

The software method would likely be to have an input in dragtools for the fuel addition value very similar to the boost fuel, use the "* tps" fueling method. Write the the value to COV1 when the clutch is in AND rpm is within 1000 (or so) rpm of the 2-step setting, then remove the value when teh clutch is released.

Issues with this may be "interference" with the boost fuel code as it is currently programmed as it may also be trying to write to COV1 as the boost starts to build

I'm not sure if COV2 is just another soft area int eh ECU that will also add fuel, but if so, that could be an option to prevent any interference.

This coudl all be incorrect...I'm just trying to read through the code and understand how the architecture actually is function for each part.

__________________


Guru

Status: Offline
Posts: 546
Date:

If i read you correct John and cov 2 is active , then thats a good place to begin live tuning

__________________


Guru

Status: Offline
Posts: 1247
Date:

Live tuning has been discussed a bit, potentially using the same theory as the SDS tool. For example, it can send a temporary value for idle speed. Could be similar to sending temporary fuel values. Only 1 value is really needed as teh PC could track and store each value outside of the bike, and resend / store as appropriate. May not be fast enough, but it would be a start.

I had mentioned using an input in the past to hook up a ~5 position resistor pot to ass 0, +2, +4, -2, -4 percent fuel or ignition depending on position. Sort of a passive/ incremental "live tuning" that woudl read the value and add to the multiplier. Would work well tough or ignition tuning on a steadystate load cell dyno.


__________________


Guru

Status: Offline
Posts: 1233
Date:

I have thought about this quite a bit as well. To my mind what would be reallly cool for tuning fuel maps would be to incorporate the real time element with the auto tune, so you would have your target afr map and provided we could feed information back into the ecu we could adjust fuel values in real time until the value that matched the target AFR was arrived at. So you would not need to tweak values manually while on the dyno you would just have the target AFR map set and you would guide the engine to the cell/s to be tuned and when the software has arrived at the value required for that cells target AFR the cell would change colour and the operator would move to the next cell/s

For ignition a more manual approach would be needed but the same principals would apply. i.e. feed back a delta value to the ecu coresponding to the current map location which is stored in the software until the next flash which would apply all the deltas to the map in the ecu.



__________________

site_logo_small.png

www.WoolichRacing.comTune your bike to the Limit with our Advanced ECU Flashing Products



Guru

Status: Offline
Posts: 1247
Date:

Dynojet has a very similar closed loop tuning option for dyno tuning.


__________________


Guru

Status: Offline
Posts: 1233
Date:

I just need another 20 hours in every day and I would have it finished in no time :)



__________________

site_logo_small.png

www.WoolichRacing.comTune your bike to the Limit with our Advanced ECU Flashing Products

«First  <  1 2 3 | Page of 3  sorted by
 
Quick Reply

Please log in to post quick replies.

Tweet this page Post to Digg Post to Del.icio.us


Create your own FREE Forum
Report Abuse
Powered by ActiveBoard