Had an MS3X on the test bench today...
03-24-2010, 06:02 PM
#61
Junior Member
Join Date: May 2007
Location: Columbia, MD
Posts: 248
Total Cats: 0
The developer was supposed to be getting me that data and then I never heard back.
If you have that data I'd like to see it. My stipulation was that I'd implement it functionally the same as that developer (but without using his code directly) if the difference between actual timing and commanded timing was minimal. If it isn't minimal, then the "load" axis on the MS3 code's table will only exist when using a MAF, and in speed density mode, it'll just be RPM based.
Either way we'll have continuously variable timing control, it's just a matter of how it'll be done in the speed density case.
EDIT: Just to add, either way, implementing this has very wide-reaching implications for our code. (In other words, just saying "I'll implement it" makes it sound easier than it is). It's a pretty complicated thing to add to our code which is why we made the decision for it to go into 1.1 and/or 2.0 and not 1.0.
Ken
Reply
0
0
03-24-2010, 06:05 PM
#62
Junior Member
Join Date: May 2007
Location: Columbia, MD
Posts: 248
Total Cats: 0
We're not amazing, we just like doing what we do!
Not at this point.
If you go to the megameet in Reading PA this year, I'll be happy to drink beer bought for me by you (or anyone, including myself) 
If I did that, I don't think you'd want to drive on my code... 
Ken
Is there some place that I can donate money
or beer
or blow?
Ken
Reply
0
0
03-24-2010, 06:37 PM
#64
Supporting Vendor
Thread Starter
iTrader: (33)
Join Date: Jul 2006
Location: atlanta-ish
Posts: 12,659
Total Cats: 134
Yeah, he had gotten me in contact with the developer (his name escapes me now). What I had originally wanted to see was a log from his controller of actual valve timing versus commanded timing during quick transients such as freerevving in neutral in a manner that would happen when doing things like rev-matching for a down-shift.
The developer was supposed to be getting me that data and then I never heard back.
If you have that data I'd like to see it. My stipulation was that I'd implement it functionally the same as that developer (but without using his code directly) if the difference between actual timing and commanded timing was minimal. If it isn't minimal, then the "load" axis on the MS3 code's table will only exist when using a MAF, and in speed density mode, it'll just be RPM based.
Either way we'll have continuously variable timing control, it's just a matter of how it'll be done in the speed density case.
EDIT: Just to add, either way, implementing this has very wide-reaching implications for our code. (In other words, just saying "I'll implement it" makes it sound easier than it is). It's a pretty complicated thing to add to our code which is why we made the decision for it to go into 1.1 and/or 2.0 and not 1.0.
Ken
The developer was supposed to be getting me that data and then I never heard back.
If you have that data I'd like to see it. My stipulation was that I'd implement it functionally the same as that developer (but without using his code directly) if the difference between actual timing and commanded timing was minimal. If it isn't minimal, then the "load" axis on the MS3 code's table will only exist when using a MAF, and in speed density mode, it'll just be RPM based.
Either way we'll have continuously variable timing control, it's just a matter of how it'll be done in the speed density case.
EDIT: Just to add, either way, implementing this has very wide-reaching implications for our code. (In other words, just saying "I'll implement it" makes it sound easier than it is). It's a pretty complicated thing to add to our code which is why we made the decision for it to go into 1.1 and/or 2.0 and not 1.0.
Ken
We're well aware that it won't be an easy implementation. but adding this feature set to the hardware will be an amazing benefit to the community.
Reply
0
0
03-24-2010, 09:38 PM
#66
Junior Member
Join Date: May 2007
Location: Columbia, MD
Posts: 248
Total Cats: 0
Yep, here's the thread on it at msextra.com:
Megasquirt MSEXTRA and MS3EFI • View topic - MegaMeet 2010 - June 25-26th, Reading, PA
Ken
Megasquirt MSEXTRA and MS3EFI • View topic - MegaMeet 2010 - June 25-26th, Reading, PA
Ken
Reply
0
0
03-24-2010, 09:42 PM
#67
Junior Member
Join Date: May 2007
Location: Columbia, MD
Posts: 248
Total Cats: 0
I understand the commanded vs actual tracking was bang on in transients. Developer's name is Kevin. He is as busy as he is smart, and tends to take a couple of days to answer email. He's also an occasional reader of this board, so who knows, maybe he'll stop by.
We're well aware that it won't be an easy implementation. but adding this feature set to the hardware will be an amazing benefit to the community.
We're well aware that it won't be an easy implementation. but adding this feature set to the hardware will be an amazing benefit to the community.
As far as my comment on the difficulty of it, my main point was more that it touches a lot of "stable" code that we didn't want to touch for 1.0 in the ignition area.
For 2.0 I'm converting everything to the angle clock ignition method which should free up a lot of CPU cycles and give the same or better accuracy as before so that's where I'd prefer to make large changes to ignition.
However, since I realize a lot of people really want this feature, I will try to get it done for 1.1 instead.
Ken
Reply
0
0
03-24-2010, 09:49 PM
#68
mkturbo.com
iTrader: (24)
Join Date: May 2006
Location: Charleston SC
Posts: 15,176
Total Cats: 1,680
Last I heard though nobody had gotten that data on the kind of transients I'm talking about, only slower ones in gear on the dyno. I'm most interested in the "quick blip" case, as having fuel wrong due to the variable valve timing not keeping up with conditions could cause weird issues with throttle response in those conditions. If you could email me that data on the quick-blip freerev transients, I'd appreciate it.
As far as my comment on the difficulty of it, my main point was more that it touches a lot of "stable" code that we didn't want to touch for 1.0 in the ignition area.
For 2.0 I'm converting everything to the angle clock ignition method which should free up a lot of CPU cycles and give the same or better accuracy as before so that's where I'd prefer to make large changes to ignition.
However, since I realize a lot of people really want this feature, I will try to get it done for 1.1 instead.
Ken
As far as my comment on the difficulty of it, my main point was more that it touches a lot of "stable" code that we didn't want to touch for 1.0 in the ignition area.
For 2.0 I'm converting everything to the angle clock ignition method which should free up a lot of CPU cycles and give the same or better accuracy as before so that's where I'd prefer to make large changes to ignition.
However, since I realize a lot of people really want this feature, I will try to get it done for 1.1 instead.
Ken
Reply
0
0
03-25-2010, 12:57 PM
#69
Junior Member
Join Date: May 2007
Location: Columbia, MD
Posts: 248
Total Cats: 0
I may take you up on that but probably later than May.
It's probably going to be sometime in the summer before I even think about starting on it.
Thanks though, I'll definitely take you up on it.
Ken
It's probably going to be sometime in the summer before I even think about starting on it.
Thanks though, I'll definitely take you up on it.
Ken
Reply
0
0
Thread
Thread Starter
Forum
Replies
Last Post
