new mustang maf & translator

[zac83]

I've logged a few DSM's with maf translators using a snapon scanner... the karmen frequency was instantly modified when the TPS signal changed.... There dosnt seem to be any 'refresh rate' lag or anything like that. It would be interesting to find out how exactly the MAF translator reads and emulates the signal.

 

[brads]

The delay time should be substantially less than a second. The devices I have made that were similar to that would respond in much less than 1 second. The lag from input to output should be on the order of a few milliseconds or less.

If what you were saying about the latency being that long for the devices to read the frequency, then spit it back out were true, it would apply equally to AFCs and similar devices as it would to a translator device. I never saw a 1 sec lag on my AFC.

Brad

 

[eclipsegsx9797]

why do people actually buy this maft setup, i mean ive heard nothing but bad things about tuning with them and i have never attempted to tune with it. ever sense i got mine i left it at 0 and tuned with my afc and soon il tune with my dsmlink. i only bought it to vent and open up some space in my engine bay. im using tial thats why i have to vent

 

[LightningGSX]

Originally posted by brads
The delay time should be substantially less than a second. The devices I have made that were similar to that would respond in much less than 1 second. The lag from input to output should be on the order of a few milliseconds or less.

If what you were saying about the latency being that long for the devices to read the frequency, then spit it back out were true, it would apply equally to AFCs and similar devices as it would to a translator device. I never saw a 1 sec lag on my AFC.

Brad

I don't know how you could compare a MAFT to a AFC, since they are two different devices with two different purposes and with two totally different software setups.

 

[LightningGSX]

Originally posted by zac83
I've logged a few DSM's with maf translators using a snapon scanner... the karmen frequency was instantly modified when the TPS signal changed.... There dosnt seem to be any 'refresh rate' lag or anything like that. It would be interesting to find out how exactly the MAF translator reads and emulates the signal.

So you were measuring frequency in and frequency out? On the car?Whats instantly?

 

[brads]

Originally posted by LightningGSX
I don't know how you could compare a MAFT to a AFC, since they are two different devices with two different purposes and with two totally different software setups.

They both take a frequency in, and spit a modified frequency out. What is so different about them? Sure they have different user interfaces. But they are designed to do similar things-scale frequency based signals. What else do you think the MAFT has to do that is going to make it take a second to respond?

Brad

 

[LightningGSX]

First of all, I said my "guess" was about a second.I could think of lots of reasons for latency of up to a second, primarily the counting and scaling.Do you think it is lookuptable driven? a lookup table of over 2000 frequencies? it probably has to do some math, think about how many clock cycles it takes to do * or /.Then add time neccesary to count the input signal and then add the time it takes to output the scaled signal,It is definately not instantaneous.As far as comparing it to a AFC...2 different engineers, writing 2 different sets of code, into 2 different microcontrollers,with 2 different clock speeds.Yeah thats comparable.

 

[brads]

Originally posted by LightningGSX
First of all, I said my "guess" was about a second.I could think of lots of reasons for latency of up to a second, primarily the counting and scaling.Do you think it is lookuptable driven? a lookup table of over 2000 frequencies? it probably has to do some math, think about how many clock cycles it takes to do * or /.Then add time neccesary to count the input signal and then add the time it takes to output the scaled signal,It is definately not instantaneous.As far as comparing it to a AFC...2 different engineers, writing 2 different sets of code, into 2 different microcontrollers,with 2 different clock speeds.Yeah thats comparable.

Judging by the way you are describing how you think the code works, you don't have any idea of how one would be programmed. If you have the proper design strategy figured out, its not difficult to get the times down to what I said. At least its not difficult for someone who has programmed microcontrollers for any period of time. It may be tough to do if the person designing it only had done a few programs in some sort of lab at school.

The AFC and translator are comparable because they are both designed to do the same thing: modify a frequency based airmeter output. What makes you think the micro and clockspeed(as long as it was within reason) would matter significantly for response time if they picked the right coding methodology? Your argument about the math functions etc is farfetched. Most micros operate with clocks on the order of megahertz, giving them more than enough time to do the math in 1ms, most should be done with it in significantly less than that. Which would be around 1 pulsewidth delay, or less, like I said.

This is a ridiculous argument. A one second delay would make the translator unusable. I've seen enough posts of people having good drivability with it to not buy into that.

Brad

 

[Groomz]

If the delay were that long, I would have to do several things to change my life. It would now take a few minutes from when I pressed the button on the blender before it made my smoothie, I would now have to click a web link and come back in a few hours before it has loaded ( all on a T1 network, mind you ) and when I start my car I would have to give it 10 minutes to communicate with itself b/c electricity is so g-d slow now.

1 second in a computers world is enough to do alot of things and counting and translating voltage from an external source is a fart in the wind for any computer ( even DSM ECU's ). What about injector pulse width calculation and duty cycle, coolant temp compensation, boost, intake temp changes, and a whole bunch of other variables that go in before the ECU even decide's to do something. If that time estimate were accurate, our cars would never run, they would sit there chugging away code while we went and bought a carburated Ford.