$58 users - strange base pulse widths
Thread Starter
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
$58 users - strange base pulse widths
I have been commenting a $58 bin and trying to correlate the fueling with the ALDL data from my first boosted car I did last year. I still can't figure out the injector base pulse widths.
The data is from TP4.0 in an ms-excel format. The xdf used was the standard Syclone91-93 included with Tunerpro 4.0. I noticed the ALDL def. has a factor of ten (655.36) difference when compared to the $8D definition.
The idle pulsewidth is about 6ms at 800rpm with 42lb/hr injectors.
Anyway, anyone ever see strange pulse widths like this?? Notice the pulsewidth goes to zero as the rpms increase and the WBO2 goes way rich (as intended).
Confuses me.
The data is from TP4.0 in an ms-excel format. The xdf used was the standard Syclone91-93 included with Tunerpro 4.0. I noticed the ALDL def. has a factor of ten (655.36) difference when compared to the $8D definition.
The idle pulsewidth is about 6ms at 800rpm with 42lb/hr injectors.
Anyway, anyone ever see strange pulse widths like this?? Notice the pulsewidth goes to zero as the rpms increase and the WBO2 goes way rich (as intended).
Confuses me.
Which 8D ads?
The PW was incorrect on the included TP 730 ads I believe.
My ads has mult and a factor of 0.015259. With the high range set to 65535. Not 16384 as the included ads has.
I'm not sure if my factor is 100% correct. But it's seems to track correctly. I don't recall how I came up with it a couple years ago.
I noticed the async bpw of the included TP syty ads has a zero in the range. Not sure how the math would work with a factor of 655.xx and 16384 like the BPW item has. But FFFF=65535 so.....
The latest 8D ads is waiting on me to finalize the S_aujp mods.
But Mark Mansur has a preliminary version that was sent him a while back for review. It's not mine or I'd send it.
I looked at the 6E ads. You'd think it would be correct.
It has the range set to 1500.
The PW was incorrect on the included TP 730 ads I believe.
My ads has mult and a factor of 0.015259. With the high range set to 65535. Not 16384 as the included ads has.
I'm not sure if my factor is 100% correct. But it's seems to track correctly. I don't recall how I came up with it a couple years ago.
I noticed the async bpw of the included TP syty ads has a zero in the range. Not sure how the math would work with a factor of 655.xx and 16384 like the BPW item has. But FFFF=65535 so.....
The latest 8D ads is waiting on me to finalize the S_aujp mods.
But Mark Mansur has a preliminary version that was sent him a while back for review. It's not mine or I'd send it.
I looked at the 6E ads. You'd think it would be correct.
It has the range set to 1500.
Last edited by Z69; Jan 4, 2006 at 02:16 AM.
Thread Starter
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
You can up with the .015xxx mult factor by 1/65.536.
Both the mult factor for the $8D and the SyTy91-93 ADS file async and sync seem correct. The ihighrange factors don't seem correct for the SyTy91-93 ADS file
I am GUESSING that the ihighrange is supposed to be an "integer" value for the max value read from the ALDL stream. That is, 0 would be 0ms BPW and 65536 would be the max BPW in msec.
Is there a doc anywhere explaining the ADS file structure? I don't have access to TP4.0 right now. I will check the TP4.0 help section tonight so see if it lists the structure definition.
The BPW are strange though. They drop A LOT with increasing RPM ( a little would be fine). Sometimes at engine startup, the BPW is 1ms to 2ms reported by the ALDL *without* the engine even running yet. The 800rpm idle has a sync BPW of approx. 6ms and async mode is sometimes active. Also, druring normal part throttle cruise & sometimes WOT, the BPW drops to .41msec. You can see this a few times in the posted curve.
All very strange. I looked at the sensor data (MAP, CTS, MAT, etc) to see if a faulty sensor is causing strange BPWs. All looked good. Could be a ground thing, but I checked a few times and all seemed good. I think it is the funky $58 fueling thing coming into play. My $58 code ignorance is still rather high right now so I guess it could be anything.
Both the mult factor for the $8D and the SyTy91-93 ADS file async and sync seem correct. The ihighrange factors don't seem correct for the SyTy91-93 ADS file
I am GUESSING that the ihighrange is supposed to be an "integer" value for the max value read from the ALDL stream. That is, 0 would be 0ms BPW and 65536 would be the max BPW in msec.
Is there a doc anywhere explaining the ADS file structure? I don't have access to TP4.0 right now. I will check the TP4.0 help section tonight so see if it lists the structure definition.
The BPW are strange though. They drop A LOT with increasing RPM ( a little would be fine). Sometimes at engine startup, the BPW is 1ms to 2ms reported by the ALDL *without* the engine even running yet. The 800rpm idle has a sync BPW of approx. 6ms and async mode is sometimes active. Also, druring normal part throttle cruise & sometimes WOT, the BPW drops to .41msec. You can see this a few times in the posted curve.
All very strange. I looked at the sensor data (MAP, CTS, MAT, etc) to see if a faulty sensor is causing strange BPWs. All looked good. Could be a ground thing, but I checked a few times and all seemed good. I think it is the funky $58 fueling thing coming into play. My $58 code ignorance is still rather high right now so I guess it could be anything.
With the ads factors wrong, the display will be a nonsense number at times. I've seen all sorts of wacky numbers on the bench. There doesn't appear to be any overflow control
of the number in TP. So if you wrap around via a mult factor that is too large......
I don't think you could idle at 6ms with 42's.
Like I said, nonsense #'s.
If you haven't already, dig up the A100 list for the data stream math. I think it's ALDL xxxx.zip. Or I could email it if I had an address.
of the number in TP. So if you wrap around via a mult factor that is too large......
I don't think you could idle at 6ms with 42's.
Like I said, nonsense #'s.
If you haven't already, dig up the A100 list for the data stream math. I think it's ALDL xxxx.zip. Or I could email it if I had an address.
Thread Starter
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Thank you Z69. I looked at the $8D code and the $58. Looking at both pieces of code, the max PW sent to the injectors can be 500 msec in both files. The public $58 out there says 1982msec but I think that it is wrong after reading through the code and ALDL datastream stuff.
So theroretically, both the $58 and $8D should have the divide by number set to 65.536 and the iHighRange set to 32,767. This yields the 500msec PW max. that is hard limited in the code.
I will check out the "overflow" with the TP4.0 and the ADS file. The 24#/hr idle PW was approx. 2.0 ms. So the 42#/hr idle PW of 6ms seemed odd. The strange PW dropping to about 0msec seemed odd (overflow/wrapping around). I ignored the strange PWs during the tuning cause it seemed wrong when I was doing it. A lot of variables were working against me....first homemade boost hardware, first $58 code, new cam to break-in, first 'big' injectors, first time using TP4.0 for bin editing & ALDL.
Thanks again, I will check out the A100 list math. The P4 Sunbird doc has some good stuff. I have been using that, the source, and the anht_hac so far.
So theroretically, both the $58 and $8D should have the divide by number set to 65.536 and the iHighRange set to 32,767. This yields the 500msec PW max. that is hard limited in the code.
I will check out the "overflow" with the TP4.0 and the ADS file. The 24#/hr idle PW was approx. 2.0 ms. So the 42#/hr idle PW of 6ms seemed odd. The strange PW dropping to about 0msec seemed odd (overflow/wrapping around). I ignored the strange PWs during the tuning cause it seemed wrong when I was doing it. A lot of variables were working against me....first homemade boost hardware, first $58 code, new cam to break-in, first 'big' injectors, first time using TP4.0 for bin editing & ALDL.
Thanks again, I will check out the A100 list math. The P4 Sunbird doc has some good stuff. I have been using that, the source, and the anht_hac so far.
Thread Starter
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
One other thing, the $58 ADS file uses the 'divide by 65.536 function' for the BPW. The $8D uses the 'multiply by 1/65.536 function'.
Typically, dividing stuff tends to give more underflow/overflow errors for people coding stuff & storing the result. The divide could be the problem.
The math in the $8D and $58 ADS files appears to be correct......except for the high limits. That is, if I am guessing on what the high limits & alarm thing is.
One other thing, the SyTy91-93 ADS file also has the spark w/r/t to ref pulse and the spark w/r/t TDC listed backwards. So that the spark w/r/t to TDC is less than the spark w/r/t ref pulse when the timing is advanced.
I would like to get these fixes in for others.......not just me locally editing the ADS file I use. Do you know who maintains the SyTy91-93 file??
Typically, dividing stuff tends to give more underflow/overflow errors for people coding stuff & storing the result. The divide could be the problem.
The math in the $8D and $58 ADS files appears to be correct......except for the high limits. That is, if I am guessing on what the high limits & alarm thing is.
One other thing, the SyTy91-93 ADS file also has the spark w/r/t to ref pulse and the spark w/r/t TDC listed backwards. So that the spark w/r/t to TDC is less than the spark w/r/t ref pulse when the timing is advanced.
I would like to get these fixes in for others.......not just me locally editing the ADS file I use. Do you know who maintains the SyTy91-93 file??
Last edited by junkcltr; Jan 4, 2006 at 02:03 PM.
I don't recall where I got the Syty ads from.
No one really maintains them.
I just started out with the included one with TP and fixed it as I found problems. The 8D ads that will be out shortly will have all the mode 1 words in it I believe.
I saw the 500ms limit in the code.
But that is simply a cap on the number.
Doesn't mean the accumulator value is scaled to 500.
My theory is FFFF is the limit.
At the time I worked on it. I didn't know about the A100 file.
I've never asked Mark or tried to look up how the ads works.
Another part of our group is handling the ads.
The relocatable AUJP hac will be out shortly.
Actually, I think it is on moates now. JPAUJP_JP2 or something. Feel free to mail JP with any errors you find.
No one really maintains them.
I just started out with the included one with TP and fixed it as I found problems. The 8D ads that will be out shortly will have all the mode 1 words in it I believe.
I saw the 500ms limit in the code.
But that is simply a cap on the number.
Doesn't mean the accumulator value is scaled to 500.
My theory is FFFF is the limit.
At the time I worked on it. I didn't know about the A100 file.
I've never asked Mark or tried to look up how the ads works.
Another part of our group is handling the ads.
The relocatable AUJP hac will be out shortly.
Actually, I think it is on moates now. JPAUJP_JP2 or something. Feel free to mail JP with any errors you find.
Last edited by Z69; Jan 4, 2006 at 03:41 PM.
Trending Topics
Thread Starter
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
I think I got a $58 ADS file from www.nwstp.com while I was doing boost code searching last Fall.
You are right about 65535 being the max. value. The ALDL can report that number. The hard limit is just to the actual injectors.
I noticed the $8D with TP4.0 uses the divide function fro the Target AFR and that seemed to work right when I used that field last year. The divide number was 655.36.
In the $58 ADS the divide number is 65.536. Maybe that causes some fault condition like you mentioned.
You are right about 65535 being the max. value. The ALDL can report that number. The hard limit is just to the actual injectors.
I noticed the $8D with TP4.0 uses the divide function fro the Target AFR and that seemed to work right when I used that field last year. The divide number was 655.36.
In the $58 ADS the divide number is 65.536. Maybe that causes some fault condition like you mentioned.
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Remember that the "Divide" function of TP in the ADS is not
"output X / factor" but "factor / output X"
The mult factor of 0.015259 seemed to work to display a value but I havn't been able to confirm it since fall.
My logs indicate a value between 2 and 6 ms during light cruise so I think it is ok.
"output X / factor" but "factor / output X"
The mult factor of 0.015259 seemed to work to display a value but I havn't been able to confirm it since fall.
My logs indicate a value between 2 and 6 ms during light cruise so I think it is ok.
Thread Starter
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
The multiply seems OK. The 6ms at cruise seems OK. The 2ms at WOT seems odd. The 6ms at idle seems odd.
In the $58 ADS the BPW uses the divide and not the multiply. The $8D ADS uses the multiply for BPW. Once I get the winter boost project up and running I should be able to figure out what is going on. Too busy learning TIG welding & fabbing sheetmetal right now to fire up the ECM emulator. Or too lazy, I'd rather spend the time getting the turbo engine running and play with real hardware.
I took a break from the shop last night and looked over some data so I figured I would throw it out there and see if anyone else saw the strange BPW with the ALDL.
In the $58 ADS the BPW uses the divide and not the multiply. The $8D ADS uses the multiply for BPW. Once I get the winter boost project up and running I should be able to figure out what is going on. Too busy learning TIG welding & fabbing sheetmetal right now to fire up the ECM emulator. Or too lazy, I'd rather spend the time getting the turbo engine running and play with real hardware.
I took a break from the shop last night and looked over some data so I figured I would throw it out there and see if anyone else saw the strange BPW with the ALDL.
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
The actual formula listed in the A100 definition
Maybe that can shed some light on it.
There is no way (unless math prevails) to get "N45 * 256" + N46
That is probably it.
Code:
;--------------------------------------------------- ; 45. INJECTOR PULSE WIDTH (MSB), ; 46. INJECTOR PULSE WIDTH (LSB), ; ,mSec = ([N45] * 256 + [N46]) / 65.536 ; ??? ,mSec = N * 0.0152587890625 ;---------------------------------------------------
There is no way (unless math prevails) to get "N45 * 256" + N46
That is probably it.
Thread Starter
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
That is correct according to the source code. I am guessing that TP4.0 does the MSB*256+LSB for all 16bit fields.
The 1227749_SyTy_91-93.ads file does the following for the BPW:
BPW = (MSB*256+LSB) / 655.36)
It looks like it is off by a factor of ten. It could be as Z69 stated with the underflow problem. The BPW will always be less than 1ms and could cause strange things to show up. It all depends on what type of variable that BPW is stored as and if any hard limiting in the PC ALDL is done.
The total async BPW also has the iHighRange set to 0 which doesn't make sense.
I think only Mark can verify that. I am surprised that no one else has seen this before. It seems quite a few people are using the $58 code in boosted vehicles. Maybe they are using Datamaster for ALDL stuff.
The 1227749_SyTy_91-93.ads file does the following for the BPW:
BPW = (MSB*256+LSB) / 655.36)
It looks like it is off by a factor of ten. It could be as Z69 stated with the underflow problem. The BPW will always be less than 1ms and could cause strange things to show up. It all depends on what type of variable that BPW is stored as and if any hard limiting in the PC ALDL is done.
The total async BPW also has the iHighRange set to 0 which doesn't make sense.
I think only Mark can verify that. I am surprised that no one else has seen this before. It seems quite a few people are using the $58 code in boosted vehicles. Maybe they are using Datamaster for ALDL stuff.
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Originally posted by junkcltr
That is correct according to the source code. I am guessing that TP4.0 does the MSB*256+LSB for all 16bit fields.
The 1227749_SyTy_91-93.ads file does the following for the BPW:
BPW = (MSB*256+LSB) / 655.36)
It looks like it is off by a factor of ten.
That is correct according to the source code. I am guessing that TP4.0 does the MSB*256+LSB for all 16bit fields.
The 1227749_SyTy_91-93.ads file does the following for the BPW:
BPW = (MSB*256+LSB) / 655.36)
It looks like it is off by a factor of ten.
TP can only do (MSB+LSB *256)/655.36
I believe it handles the entire 16 bit field with he math function.
There needs to be an intermediate step where MSB*256 comes into play to get the correct #.
Maybe I'm missing something there. Same issue with one of the other ALDL values like IP fuel or something IIRC.
Thread Starter
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Think of it this way......
a 16 bit value (0xFFFF) is 65535 in decimal. To get that with the two 2 bytes sent over the ALDL, you need to do MS_byte*256 + LS_byte. If both ALDL values are max. then it becomes (0xFF*256+0xFF) or (255*256+255) = 65535 or 0xFFFF.
The math is correct. It is all a matter of how the PC ALDL deals with the result. I noticed the latest $58 ADS at www.nwstp.com is correct in using a divide by 65.536.
a 16 bit value (0xFFFF) is 65535 in decimal. To get that with the two 2 bytes sent over the ALDL, you need to do MS_byte*256 + LS_byte. If both ALDL values are max. then it becomes (0xFF*256+0xFF) or (255*256+255) = 65535 or 0xFFFF.
The math is correct. It is all a matter of how the PC ALDL deals with the result. I noticed the latest $58 ADS at www.nwstp.com is correct in using a divide by 65.536.
Last edited by junkcltr; Jan 5, 2006 at 10:36 PM.
Thread Starter
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Problem Solved
I tried the TP4.0 ALDL data playback function. It works great. The raw data is saved so you can mess with the ADS file and see how it affects how the viewed data looks.
The problem with the BPW is due to a bug with the divide function. First, I set the BPW entry to correctly divide by 65.536 and it reported the BPW incorrectly (still). Second, I change the function to do a multiply by .015xxx (1/65.536) and it worked correctly. The idle BPW reports as 1.5ms and the BPW increases to a max. of 9ms at 4600rpm. All looks good now. I also fixed the async BPW to do a multiply by .015xxx instead of the incorrect .15xxx.
Still have the odd BPW single data point spikes to 10ms and more every so often. I don't think that is a TP4.0 problem though.
The divide function might be fixed in TP4.12.......I am still using TP4.0
The problem with the BPW is due to a bug with the divide function. First, I set the BPW entry to correctly divide by 65.536 and it reported the BPW incorrectly (still). Second, I change the function to do a multiply by .015xxx (1/65.536) and it worked correctly. The idle BPW reports as 1.5ms and the BPW increases to a max. of 9ms at 4600rpm. All looks good now. I also fixed the async BPW to do a multiply by .015xxx instead of the incorrect .15xxx.
Still have the odd BPW single data point spikes to 10ms and more every so often. I don't think that is a TP4.0 problem though.
The divide function might be fixed in TP4.12.......I am still using TP4.0
Senior Member
Joined: Oct 1999
Posts: 6,621
Likes: 2
Car: 91 Red Sled
Axle/Gears: 10bolt Richmond 3.73 Torsen
Re: Problem Solved
Originally posted by junkcltr
Still have the odd BPW single data point spikes to 10ms and more every so often. I don't think that is a TP4.0 problem though.
Still have the odd BPW single data point spikes to 10ms and more every so often. I don't think that is a TP4.0 problem though.
Maybe I'm wrong, this is just something I learned working with c3's.
Thread Starter
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
That could be it. I noticed the odd BPW is always 10.57ms or 24.17ms. It occurs at random during idle, cruise, WOT. It also picks up a strange MAP Kpa at random but less often. The odd BPW and MAP value do not seem correlated.
When I get around to it I will use the Monte ALDL board to dump the BPW right before it does the out to 3FD0 and see what the actually BPW is. Stange though, I couldn't find anyone else with the odd BPW using the search tool.
I need to look over all of the $58 ADS calcs. The MAP KPA only reaches about 92 kpa when boost starts. As boost increases the 1-bar kpa reading will stay at around 92 kpa and not increase at all.
Also noticed some knock at the early TPS opening stage of going WOT. It occurs during the time the BPW goes from 2ms to 5ms as the TPS% goes from 20% to 70%. It isn't making boost at that point. It pulls 3 degrees of spark and adds it back in as the revs and boost increases. I noticed that the spark w/r/t to ref pulse and the spark w/r/t to TDC don't follow during the knock time. The spark w/r/t to TDC seems to follow the trend better. The spark w/r/t to ref pulse could be an early guess of the next ref pulse.
More fun tuning in the Spring. Lots of notes and threory to try.
When I get around to it I will use the Monte ALDL board to dump the BPW right before it does the out to 3FD0 and see what the actually BPW is. Stange though, I couldn't find anyone else with the odd BPW using the search tool.
I need to look over all of the $58 ADS calcs. The MAP KPA only reaches about 92 kpa when boost starts. As boost increases the 1-bar kpa reading will stay at around 92 kpa and not increase at all.
Also noticed some knock at the early TPS opening stage of going WOT. It occurs during the time the BPW goes from 2ms to 5ms as the TPS% goes from 20% to 70%. It isn't making boost at that point. It pulls 3 degrees of spark and adds it back in as the revs and boost increases. I noticed that the spark w/r/t to ref pulse and the spark w/r/t to TDC don't follow during the knock time. The spark w/r/t to TDC seems to follow the trend better. The spark w/r/t to ref pulse could be an early guess of the next ref pulse.
More fun tuning in the Spring. Lots of notes and threory to try.
TGO Supporter
iTrader: (1)
Joined: Nov 2002
Posts: 1,132
Likes: 1
From: Grand Island, NY
Car: 1990 Formula
Engine: 305 TPI
Transmission: WC T5
Originally posted by junkcltr
Stange though, I couldn't find anyone else with the odd BPW using the search tool.
Stange though, I couldn't find anyone else with the odd BPW using the search tool.
I am going to make the fixes you made and when spring rolls around give it a try!
Moderator
iTrader: (1)
Joined: Mar 2002
Posts: 18,432
Likes: 233
From: Chasing Electrons
Car: check
Engine: check
Transmission: check
Originally posted by Z69
8D uses address 30E4 & 30E5 for the aldl PW.
But the fuel code never uses those locations.
I've yet to find how the PW gets put into 30E4 & 30E5.
8D uses address 30E4 & 30E5 for the aldl PW.
But the fuel code never uses those locations.
I've yet to find how the PW gets put into 30E4 & 30E5.
RBob.
Moderator
iTrader: (1)
Joined: Mar 2002
Posts: 18,432
Likes: 233
From: Chasing Electrons
Car: check
Engine: check
Transmission: check
Re: Re: Problem Solved
Originally posted by JPrevost
I'm not sure if this applies in your case or not but I do know that if the ALDL routine/loop picks up the ram location of the injector pulse width it might pick it up before the code has been run to decrease that value. In other words, that isn't the final pulse width, it's a "work in progress" by the hardware. If you request it too soon, woops, the routine wasn't finished and you'll get a junk value.
Maybe I'm wrong, this is just something I learned working with c3's.
I'm not sure if this applies in your case or not but I do know that if the ALDL routine/loop picks up the ram location of the injector pulse width it might pick it up before the code has been run to decrease that value. In other words, that isn't the final pulse width, it's a "work in progress" by the hardware. If you request it too soon, woops, the routine wasn't finished and you'll get a junk value.
Maybe I'm wrong, this is just something I learned working with c3's.
RBob.
TGO Supporter
Joined: Jan 2000
Posts: 1,861
Likes: 0
From: In your ear. No, the other one.
Car: '89 Trans Am WS6
Engine: 350 TPI
Transmission: T5WC
Axle/Gears: 3.08 posi
Re: Problem Solved
Originally posted by junkcltr
I tried the TP4.0 ALDL data playback function. It works great. The raw data is saved so you can mess with the ADS file and see how it affects how the viewed data looks.
The problem with the BPW is due to a bug with the divide function. First, I set the BPW entry to correctly divide by 65.536 and it reported the BPW incorrectly (still). Second, I change the function to do a multiply by .015xxx (1/65.536) and it worked correctly. The idle BPW reports as 1.5ms and the BPW increases to a max. of 9ms at 4600rpm. All looks good now. I also fixed the async BPW to do a multiply by .015xxx instead of the incorrect .15xxx.
Still have the odd BPW single data point spikes to 10ms and more every so often. I don't think that is a TP4.0 problem though.
The divide function might be fixed in TP4.12.......I am still using TP4.0
I tried the TP4.0 ALDL data playback function. It works great. The raw data is saved so you can mess with the ADS file and see how it affects how the viewed data looks.
The problem with the BPW is due to a bug with the divide function. First, I set the BPW entry to correctly divide by 65.536 and it reported the BPW incorrectly (still). Second, I change the function to do a multiply by .015xxx (1/65.536) and it worked correctly. The idle BPW reports as 1.5ms and the BPW increases to a max. of 9ms at 4600rpm. All looks good now. I also fixed the async BPW to do a multiply by .015xxx instead of the incorrect .15xxx.
Still have the odd BPW single data point spikes to 10ms and more every so often. I don't think that is a TP4.0 problem though.
The divide function might be fixed in TP4.12.......I am still using TP4.0
Originally posted by JP86SS
Remember that the "Divide" function of TP in the ADS is not
"output X / factor" but "factor / output X"
Remember that the "Divide" function of TP in the ADS is not
"output X / factor" but "factor / output X"
Thread Starter
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
I did read it and checked what TP was doing. Have you tried the SyTy91-93 bin? It's wrong. The async BPW is wrong also.
The $8D and $58 code calc. the BPW the same way via the ALDL. The $8D ADS that comes with TP uses the divide fxn with 65.536 as the factor for BPW. Using the same divide fxn with 65.536 and the $58 code gives a wrong BPW. Yeah, it's weird. Using a multiply by .015 gives the right BPW with the $58.
Are you saying that the $58 and $8D do the inverse calc of each other. If so, the anht and P4 docs are wrong. I will take another look at them. right or wrong, the ADS file needs an update for the BPWs and the max it can be (65536 = 999.9 ms)
EDIT: I looked at the TP 730 ADS file and it does a divide using 65.536 for BPW. By the divide desciption, then that file in wrong also. (65.535/max BPW) = 65.535/65535 = 1/1000 ms ???? It would show the inverse.......just like I saw with the SyTy91-93 ADS file. Why even have the divide function at all?
The $8D and $58 code calc. the BPW the same way via the ALDL. The $8D ADS that comes with TP uses the divide fxn with 65.536 as the factor for BPW. Using the same divide fxn with 65.536 and the $58 code gives a wrong BPW. Yeah, it's weird. Using a multiply by .015 gives the right BPW with the $58.
Are you saying that the $58 and $8D do the inverse calc of each other. If so, the anht and P4 docs are wrong. I will take another look at them. right or wrong, the ADS file needs an update for the BPWs and the max it can be (65536 = 999.9 ms)
EDIT: I looked at the TP 730 ADS file and it does a divide using 65.536 for BPW. By the divide desciption, then that file in wrong also. (65.535/max BPW) = 65.535/65535 = 1/1000 ms ???? It would show the inverse.......just like I saw with the SyTy91-93 ADS file. Why even have the divide function at all?
Last edited by junkcltr; Jan 7, 2006 at 11:51 PM.
TGO Supporter
Joined: Jan 2000
Posts: 1,861
Likes: 0
From: In your ear. No, the other one.
Car: '89 Trans Am WS6
Engine: 350 TPI
Transmission: T5WC
Axle/Gears: 3.08 posi
No, I'm not saying $58 and $8D are inverse from each other. Nor am I saying the hack is wrong. I have no idea about either, actually. What I am saying is that multiply and divide functionality in TunerPro are completely different. And ultimately what I'm saying is that the ADS file is probably incorrect. Feel free to fix it! No, PLEASE fix it. Then send it to Paul at www.nwstp.com, where you got the file originally.
Really?
Short answer: Because you're not the only one who uses software to tune a vehicle, and because $58 and $8D are not the only masks.
Long answer:
x = 2
factor = 0.5
divide function: factor / x or 0.5 / 2 or .25.
multiply function: factor * x or 0.5 * 2 or 1.0.
Big difference.
Note that 1 / 2 and 1 * 0.5 ARE the same, but that's not what we're talking about here.
Why have the divide function? Well, other than the fact that they each result in a completely different output given the same input (X) and "factor", some of the GM ALDL datastream items use the divide functionality as I've explained it here, whereas others use the multiply. One is not and cannot be a substitute for the other. They are mutually exclusive. They are used for entirely different purposes. They are... (get the point?)
So, if the ADS file is wrong, then fine (and it's probably even likely). Don't confuse a bug in the ADS file for a bug in TunerPro, though.
Reminds me of something someone else posted recently. Something to the affect of [paraphrase] "I don't use categories. I don't even understand why you even have the functionality in TunerPro." The functionality is there because different people use the software for different purposes (i.e. different ECMs, masks, vehicles, makes, models, etc).
Hopefully that's an adequate explanation for you, junkcltr.
Originally posted by junkcltr
Why even have the divide function at all?
Why even have the divide function at all?
Short answer: Because you're not the only one who uses software to tune a vehicle, and because $58 and $8D are not the only masks.
Long answer:
x = 2
factor = 0.5
divide function: factor / x or 0.5 / 2 or .25.
multiply function: factor * x or 0.5 * 2 or 1.0.
Big difference.
Note that 1 / 2 and 1 * 0.5 ARE the same, but that's not what we're talking about here.
Why have the divide function? Well, other than the fact that they each result in a completely different output given the same input (X) and "factor", some of the GM ALDL datastream items use the divide functionality as I've explained it here, whereas others use the multiply. One is not and cannot be a substitute for the other. They are mutually exclusive. They are used for entirely different purposes. They are... (get the point?)
So, if the ADS file is wrong, then fine (and it's probably even likely). Don't confuse a bug in the ADS file for a bug in TunerPro, though.
Reminds me of something someone else posted recently. Something to the affect of [paraphrase] "I don't use categories. I don't even understand why you even have the functionality in TunerPro." The functionality is there because different people use the software for different purposes (i.e. different ECMs, masks, vehicles, makes, models, etc).
Hopefully that's an adequate explanation for you, junkcltr.
Ahhh, the soft white underbelly is exposed.....
I've been "questioned" on a software change I did at work before.
Mind you, the change was to a system that wasn't even physically connected to the system that had the problem.
IF- IF
you have a complete listing of all the quals in a bin.
Say 8D, all the scrolling you have to do will drive you nuts.....
Don't let that 7730.xdf included with TP fool you.
It's for the beginners.
Mark isn't in the xdf/ads publishing business.
That 8D ads has been out for a few years.
And no one, including me took the time to email the correction to Mark. And finding correct/complete/public $58 stuff is very difficult. Paul has added a lot in the last two years.
I've been "questioned" on a software change I did at work before.
Mind you, the change was to a system that wasn't even physically connected to the system that had the problem.
IF- IF
you have a complete listing of all the quals in a bin.
Say 8D, all the scrolling you have to do will drive you nuts.....
Don't let that 7730.xdf included with TP fool you.
It's for the beginners.
Mark isn't in the xdf/ads publishing business.
That 8D ads has been out for a few years.
And no one, including me took the time to email the correction to Mark. And finding correct/complete/public $58 stuff is very difficult. Paul has added a lot in the last two years.
TGO Supporter
Joined: Jan 2000
Posts: 1,861
Likes: 0
From: In your ear. No, the other one.
Car: '89 Trans Am WS6
Engine: 350 TPI
Transmission: T5WC
Axle/Gears: 3.08 posi
Originally posted by Z69
Mark isn't in the xdf/ads publishing business.
Mark isn't in the xdf/ads publishing business.
Junk - please do send me corrected files. I really do want to make sure things are as correct as possible (under the circumstances).
Thread Starter
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
I understand the explanation and now see both the $8D and $58 files were wrong. I was confused because I thought the $8D was hammered out to be correct. I was not sure if the "factor/X" was wrong or the divide was wrong. Now I understand both are right in TP and both the $58 and $8D are wrong.
You answered the why have a divide function at all with:
"Note that 1 / 2 and 1 * 0.5 ARE the same, but that's not what we're talking about here. "
That is exactly why I asked about the divide function. With a single mutiply, you can do the divide function. I understand that you do not make the ADS files, but both have your name as the Author???
Overall, I am new to TP and the ADS files so it is going to take me some time to figure out how to use it properly. And yes the TP 730.ADS file did fool me. Why give beginner's bad info?? One more $58 file bug solved.
This is the change I made.
{
dwItemType =1;
strItemComments =None;
bSeparator =0;
bVisible =1;
dwUniqueID =21;
btByteNumber =32;
btMessageNumber =1;
dwItemSizeBits =16;
dwOperation =0;
dFactor =0.015258;
dOffset =0.000000;
strItemTitle =Injector Base Pulse Width;
strUnitLabel =mSec;
dwAlarmHigh =255;
bAlarmHighENable =0;
dwAlarmLow =0;
bAlarmLowEnable =0;
iRangeHigh =65535;
iRangeLow =0;
iLookupTableIndex =-1;
}
{
dwItemType =1;
strItemComments =;
bSeparator =0;
bVisible =1;
dwUniqueID =38;
btByteNumber =48;
btMessageNumber =1;
dwItemSizeBits =16;
dwOperation =0;
dFactor =0.015258;
dOffset =0.000000;
strItemTitle =Total Async Pulse Width;
strUnitLabel =mSec;
dwAlarmHigh =0;
bAlarmHighENable =0;
dwAlarmLow =0;
bAlarmLowEnable =0;
iRangeHigh =65535;
iRangeLow =0;
iLookupTableIndex =-1;
}
You answered the why have a divide function at all with:
"Note that 1 / 2 and 1 * 0.5 ARE the same, but that's not what we're talking about here. "
That is exactly why I asked about the divide function. With a single mutiply, you can do the divide function. I understand that you do not make the ADS files, but both have your name as the Author???
Overall, I am new to TP and the ADS files so it is going to take me some time to figure out how to use it properly. And yes the TP 730.ADS file did fool me. Why give beginner's bad info?? One more $58 file bug solved.
This is the change I made.
{
dwItemType =1;
strItemComments =None;
bSeparator =0;
bVisible =1;
dwUniqueID =21;
btByteNumber =32;
btMessageNumber =1;
dwItemSizeBits =16;
dwOperation =0;
dFactor =0.015258;
dOffset =0.000000;
strItemTitle =Injector Base Pulse Width;
strUnitLabel =mSec;
dwAlarmHigh =255;
bAlarmHighENable =0;
dwAlarmLow =0;
bAlarmLowEnable =0;
iRangeHigh =65535;
iRangeLow =0;
iLookupTableIndex =-1;
}
{
dwItemType =1;
strItemComments =;
bSeparator =0;
bVisible =1;
dwUniqueID =38;
btByteNumber =48;
btMessageNumber =1;
dwItemSizeBits =16;
dwOperation =0;
dFactor =0.015258;
dOffset =0.000000;
strItemTitle =Total Async Pulse Width;
strUnitLabel =mSec;
dwAlarmHigh =0;
bAlarmHighENable =0;
dwAlarmLow =0;
bAlarmLowEnable =0;
iRangeHigh =65535;
iRangeLow =0;
iLookupTableIndex =-1;
}
I think the JPAUJP_JP2.zip on Moates has a better 8D ads in it.
We almost have the 8D stuff finished. I'm sure it was fixed long ago by someone. -But never made public-
You'd be supprised what shows up in your email when people have it.
We almost have the 8D stuff finished. I'm sure it was fixed long ago by someone. -But never made public-
You'd be supprised what shows up in your email when people have it.
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Originally posted by Z69
I think the JPAUJP_JP2.zip on Moates has a better 8D ads in it.
I think the JPAUJP_JP2.zip on Moates has a better 8D ads in it.
I took it out because of such issues.
The best way for us to fix the ADS is to create a listing from the hac of the datastream and then confirm the formulas used are correct. Trying to work it directly in TP and then having files with "one of many" incorrections fixed causes lots of suspect files to be released.
That's where we are now.
From that definition, anyone can re-create a good file.
For $8D (A100) it is this from the latest file mentioned above:
Code:
;--------------------------------------------------------------
; SERIAL DATA RX MSG
; DEVICE ID = 0x4F, MODE 1
; table value = address
;------------------------------------------------------------------------------------
...
.word 0x01BD ; 38. OIL A/D VALUE (Linearized)
; , Deg C = (N * 0.75) -40
;---------------------------------------------------
.word 0x3128 ; 39. SA + BASE (Reletive to TDC, MSB)
.word 0x3129 ; 40. SA + BASE (Reletive to TDC, LSB)
;
; DEGREE SA = "Value" * (90 / 256)
; Double Byte Value in 2's Complement representation
; If Bit 7 of MSB = 0, Then Result is Positive Value
; Value = ([N39] * 256 + [N40])
; If Bit 7 of MSB = 1, Then Result is Negative Value
; Value = 65536 - (N39] * 256 + [N40])
;---------------------------------------------------
.word 0x30BD ; 41. SA + BASE (Reletive to REF PULSE, MSB)
.word 0x30BE ; 42. SA + BASE (Reletive to REF PULSE, LSB)
;
; DEGREE SA = "Value" * (90 / 256)
; Double Byte Value in 2's Complement representation
; If Bit 7 of MSB = 0, Then Result is Positive Value
; Value = ([N41] * 256 + [N42])
; If Bit 7 of MSB = 1, Then Result is Negative Value
; Value = 65536 - (N41] * 256 + [N42])
;---------------------------------------------------
.word 0x00C1 ; 43. OLD PA3 COUNTER (Knock Counter)
; , N = Knock Counts
;---------------------------------------------------
.word 0x00C4 ; 44. KNOCK RETARD
; , Deg Retard = N * (45/256)
; or , Deg Retard = N * 0.17578125
;---------------------------------------------------
.word 0x30E4 ; 45. INJECTOR PULSE WIDTH (MSB),
.word 0x30E5 ; 46. INJECTOR PULSE WIDTH (LSB),
; , mSec = ([N45] * 256 + [N46]) / 65.536
; ??? , mSec = N * 0.0152587890625
;---------------------------------------------------
.word 0x30F3 ; 47. AFR, MSB, (445 = 14.7)
.word 0x30F4 ; 48. AFR, LSB
; , A/F Ratio = 6553.6 / ([N47] * 256) + 6553.6 / [N48]
;------------------------------------------- Last edited by JP86SS; Jan 8, 2006 at 12:33 PM.
Moderator
iTrader: (1)
Joined: Mar 2002
Posts: 18,432
Likes: 233
From: Chasing Electrons
Car: check
Engine: check
Transmission: check
Note the $8D:
Both of these give the same result:
mSec = ([N45] * 256 + [N46]) / 65.536
mSec = N * 0.0152587890625
But in the ADS file need to use the multiply function (2nd one shown).
Now the AFR calculation needs to use the divide function in the ADS file.
A/F Ratio = 6553.6 / ([N47] * 256) + 6553.6 / [N48]
RBob.
Code:
;---------------------------------------------------
.word 0x30E4 ; 45. INJECTOR PULSE WIDTH (MSB),
.word 0x30E5 ; 46. INJECTOR PULSE WIDTH (LSB),
; , mSec = ([N45] * 256 + [N46]) / 65.536
; ??? , mSec = N * 0.0152587890625
;---------------------------------------------------
.word 0x30F3 ; 47. AFR, MSB, (445 = 14.7)
.word 0x30F4 ; 48. AFR, LSB
; , A/F Ratio = 6553.6 / ([N47] * 256) + 6553.6 / [N48]
;-------------------------------------------;-------------------------------------------------------------------------------------------- mSec = ([N45] * 256 + [N46]) / 65.536
mSec = N * 0.0152587890625
But in the ADS file need to use the multiply function (2nd one shown).
Now the AFR calculation needs to use the divide function in the ADS file.
A/F Ratio = 6553.6 / ([N47] * 256) + 6553.6 / [N48]
RBob.
Moderator
iTrader: (1)
Joined: Mar 2002
Posts: 18,432
Likes: 233
From: Chasing Electrons
Car: check
Engine: check
Transmission: check
For some strange reason I didn't get an 'edit' button for my last post.
What I was going to add is that the AFR equation as shown in the definition file (A100) is incorrect. Just divide 6553.6 by the 16 bit value from the data stream:
A/F Ratio = 6553.6 / ([N47] * 256 + [N48])
RBob.
What I was going to add is that the AFR equation as shown in the definition file (A100) is incorrect. Just divide 6553.6 by the 16 bit value from the data stream:
A/F Ratio = 6553.6 / ([N47] * 256 + [N48])
RBob.
Originally posted by RBob
For some strange reason I didn't get an 'edit' button for my last post.
For some strange reason I didn't get an 'edit' button for my last post.
It get pushed way off to the right due to the [code]
I spent some time looking for the button one day too.....
The AFR is correct in my TP included 7730 ads.
Just a $58 problem???
Last edited by Z69; Jan 8, 2006 at 12:32 PM.
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
My last line got ya.
Figured after 4000 posts you are required to type it right the first time
Thanks for pointing out the A100 is incorrect.
Figured after 4000 posts you are required to type it right the first time

Thanks for pointing out the A100 is incorrect.
TGO Supporter
iTrader: (1)
Joined: Nov 2002
Posts: 1,132
Likes: 1
From: Grand Island, NY
Car: 1990 Formula
Engine: 305 TPI
Transmission: WC T5
So just to confirm the Inject PW is
mSec = N * 0.0152587890625
for $58 code correct.
Are there any other items?
I see you set your:
iRangeHigh =65535
Isn't that used just for the total range for display purposes such as in ALDL Monitors display.... If you have it that large if you were to look at the running display playback of say Inject PW it would be just a straight linewith a max value of 65535 (max value 1000), however, if you set it to 700 it would display values up to 10.68, which would be static anyway?
mSec = N * 0.0152587890625
for $58 code correct.
Are there any other items?
I see you set your:
iRangeHigh =65535
Isn't that used just for the total range for display purposes such as in ALDL Monitors display.... If you have it that large if you were to look at the running display playback of say Inject PW it would be just a straight linewith a max value of 65535 (max value 1000), however, if you set it to 700 it would display values up to 10.68, which would be static anyway?
TGO Supporter
Joined: Jan 2000
Posts: 1,861
Likes: 0
From: In your ear. No, the other one.
Car: '89 Trans Am WS6
Engine: 350 TPI
Transmission: T5WC
Axle/Gears: 3.08 posi
Originally posted by novass
I see you set your:
iRangeHigh =65535
Isn't that used just for the total range for display purposes such as in ALDL Monitors display.... If you have it that large if you were to look at the running display playback of say Inject PW it would be just a straight linewith a max value of 65535 (max value 1000), however, if you set it to 700 it would display values up to 10.68, which would be static anyway?
I see you set your:
iRangeHigh =65535
Isn't that used just for the total range for display purposes such as in ALDL Monitors display.... If you have it that large if you were to look at the running display playback of say Inject PW it would be just a straight linewith a max value of 65535 (max value 1000), however, if you set it to 700 it would display values up to 10.68, which would be static anyway?
Thread
Thread Starter
Forum
Replies
Last Post
New2Chevy
Engine/Drivetrain/Suspension Parts for Sale
2
Sep 28, 2015 12:35 AM
Night rider327
Engine/Drivetrain/Suspension Parts for Sale
0
Sep 2, 2015 04:17 AM






