Guys -

I've got a buddy near by with a Typhoon (7749, $58 of course). I had a hell of a time getting TunerPro to connect to the thing. After many attemps in the debugger, we found a way to get it to connect (which will lead to an entire re-write of my ALDL connection code, and possible the ads file format). The problem is that his "version" of the $58 code is chatty as all getout, and you need to send it not one, but many "shut up" commands, and do so in a very narrow window, in order to get it to silence its default spew enough to actually allow TunerPro to get a packet request in (shall we say, "edgewise"? =). Its like talking to my wife, man!

Now then, I know there are a number of people running $58 code that have no issues getting TP to connect.

This leads me to believe that perhaps some BCCs of $58 code are more chatty than others. Does anyone have info on this or has anyone verified so?

 

i dont know anything specific per se, but I do know there are quite a few so called "proprietary" chips with options like 3 bar map sensor and the like. Possibly the code rewrites contribute to some of this?

later
Jeremy

 

I wonder if this is the problem I am getting with my 7730 $8d. Motes software works great, can't get tuner pro to connect no matter what.

How do you send a "shut up" command?

here is the other thread explaining what I have done so far.

 

Wouldn't be the problem with $8D.

 

Of the half dozen 58 BBCs I have, none have any code changes.

Using various scanners, shows a difference in how they link. Some seem to be faster then others.

 

Chatter is dependent upon the BCC, not the mask. Along the lines of some women chatter a lot while others are OK. All the same mask (female), different calibrations

Within the calibration data area there is a table of 16 addresses (uhh, back to the ECM. . .). Each entry points to either a packet descriptor or is 0. If 0, then nothing happens. Else a packet is sent.

This table is round-robin'd with the next entry being served after each minor loop.

Takes some finesse to get a 'stop chattering' (SC) packet in edgewise. Without really good timers to check for the inter packet gap, a rolling character counter works.

This operates as such: start at a character count of 4, then send a SC packet. If continues to chatter, wait for 4+1 characters and send a SC packet, if continues to chatter, wait for 4+2 characters and send a SC packet, and so on.

It is also required to hesitate a tad before sending the stop chatter (SC) request packet. The ECM needs to turn the port around.

Once the ECM stops chattering the code can then drop to a request/receive data packet mode. However, the logic needs to be such that if data packets stop being received that it will first re-request a data packet and then possibly fall back to the SC routine again.

Of course if one can convince the PROM guy to zero out the chatter table (broadcast table) then all this is for nought.

RBob.

edit: I need to add to the rolling counter process. Once a maximum charactor count is reached the counter needs to then be decremented. A max term of 32 bytes usually works. All depends upon the max size of a chatter packet (they are typically small).

So in essence the rolling counter will increment then decrement between an upper and a lower limit.

 

What is the purpose for this table?

 

Thanks Bob. This much I knew (as you might have noticed from the post). I was just wondering why some running $58 don't seem to run into any issues connecting, whilst others do. Seems to remain a mystery.

 

There can be anywhere from 0 to 16 chatter packets being sent. If all 16 are in use it is going to be difficult to get a SC packet in, edgewise or otherwise.

If only one is in use then it is only moderately painful to get a SC packet in edgewise. If no chatter packets are in use then it becomes easy to connect.

For those folks that it is difficult to connect, ask them to zero out the broadcast table. Then there won't be any chatter to deal with.

RBob.

 

Using a AYBN bcc I've never had much problems linking.

 

I have a 93 typhoon and I was having trouble getting it to talk to my labtop with data master but it worked perfect on my buddies 92 typhoon. I then found in data master I had to change a timing speed in the program to get it to talk per there instructions. I think this is what you are talking about?? I have not tried tunerpro on my typhoon but I would be willing to try some stuff if you want me to?