ALDL Updates was DIY-WB Output Voltage Scaling

[Malcolm Robb, LC 0112G]

Not strictly true. Sure if you just request the standard ALDL data stream 
of 63 odd bytes you can't exceed 10 ish frames per second, but there are 
other ways to kill a cat.

1) The byte stream the scanner sends TO the ECU to tell it to send data 
back (Mode 1) is $F4,$57,$01,$00,$B4 (for my car). The $00 at byte 4 tells 
the ECU to transmit 'Frame 0'. ECU Software then looks up the address of a 
table for 'Frame 0' and starts transmitting the data specified in that 
table. One of the bytes in the table header specifies how long the frame 
is. As most of you know, frame 0 is usually 63 bytes of data long, plust 
another 3 bytes of header and a checksum, making 67 in all. In my ECU, the 
only frame defined is 'Frame 0', but if memory serves me right, the frame 
table lookup table is 8 locations in size. Therefore, it is possible to add 
your own extra frames containing only the value's you are interested in - 
things like RPM, MAP, MAT etc. They need only be as long as the data you 
want to transmit. Then you could request the ECU to transmit that frame 
much more often using a command string like $F4,$57,$01,$01,$B5 (to request 
More 1, Frame 1).  To do this, you only need to modify the Frame Pointer 
table, and locate some unused EPROM to store the pointers to the variables 
you want to transmit. Depending upon the length of the frame, you should be 
able to achieve frame rates of 10 to 50 frames a second.

2) You can add frames to the heartbeat table too. This would mean that the 
ECU automatically transmitted the values you were interested in, instead of 
you having to 'ask' for them. This should give you increased data rates, 
because you don't have to send the 5 byte Mode 1 request to the ECU. It may 
even be possible to 100% load the bus, giving you hundreds of samples per 
second.

3) This is something I've been meaning to try, and never got round to it. 
There is also a Mode 3 request string, which allows you to request the ECU 
to send you back the value (or values) of up to 4 memory locations. If you 
know which locations in RAM are used to store the paramaters you are 
interested in, then you could use a Mode 3 request to get a higher sample 
rate - Without blowing a new EPROM. Assuming you wanted 4 values read back, 
you would have to send a 12 byte mode 3 request string to the ECU, and it 
would respond with an 8 byte reply. Hence 20 bytes per request, instead of 
the 70 odd for a standard Mode 1, so you should get close to 40 samples per 
second.

The only thing that's fixed is the baud rate (8192 baud) which means you 
will never achieve more than 800 or so bytes per second. The mode 1 request 
string is 5 bytes long, so 10 requests a second accounts for 50 bytes, or 
6% of the bus bandwidth. In the Mode 3 request, the request string accounts 
for 60% of the bandwidth.  For increased sample rates the way to go (IMHO) 
is to fiddle with the heartbeat table, in which case you have no request 
overhead. I'm guessing, but I expect that's what Richard W has done. But 
most of you tuners are already modifying tables for fuel and spark, so it 
isn't too much of a giant leap to start modifying ALDL tables as well.

But as Bruce (kind of) implied, getting more data is one thing, but 
deciding what it means, and what to do with it is another. Sorry if any of 
you thing this is just programmer techno-babble, but if anyone is really 
interested I'm sure I could try and explain more fully.

Cheers,
Malcolm  Robb, LC 0112G - Back to lurk Mode 0 till I have something else I 
think I can add.

-----Original Message-----
From:	Ken Richardson [SMTP:krichar at ns.sympatico.ca]
Sent:	Saturday, September 01, 2001 11:44 AM
To:	diy_efi at diy-efi.org; gmecm at diy-efi.org
Subject:	Re: DIY-WB Output Voltage Scaling

I don't want to be dragged into this feud but Scot is correct. A claim of
100 frames per second would *have* to repeat frames, many frames. I just
looked up a spec for one of GM's P4 datastreams (picked at random). One
frame is 63 bytes, add a stop and start bit to the bytes and you get 630
bits per frame. The ECM transmits the data at 8192bps so the most you could
ever get is 13 frames per second. You will never get this because of the
nature of the communications. The scan tool must request the data and there
is a period of "no activity" between ECM/Scan Tool transactions. So
pratically you can't even get 10 frames per second. A claim of 100 frames
per second is pure advertising BS, period.

The experiments I've done with a '93 Beretta gave me around 5 - 6 frames 
per
second.

Ken R.


----- Original Message -----
From: "Richard Wakeling" <kojab at optushome.com.au>
To: <gmecm at diy-efi.org>; <diy_efi at diy-efi.org>
Sent: Friday, August 31, 2001 10:07 PM
Subject: Re: DIY-WB Output Voltage Scaling


> Hi Scot and All,
>
> Scot Sealander wrote:
>
> > Richard Wakeling wrote:
> >
> >
> > > Our new DST  (Scan tool)  is like no others that we
> > > know of. There is no other GM type scan tool that operates at better
than 100 frames
> > > per second.
> >
> > Now that is just a piece of pure advertising hype.  All the P4's run at
> > the same speed of 8192 bps, you have just shortened up the list of
> > variables to send the same variable more often.  No more "frames" per
> > second, because more frames would mean more overhead, it's just more of
> > the same variable per second, repeated in a frame.
>
> I was pleased you wrote this to the list as it proves two things to me 
and
the group.
>     You have accused me of steeling ideas and knowledge from the group.
You say that what
> I have shown and said is not possible. Firstly this means that if what I
had said "is"
> possible  proves the idea or information did not come from the group.
Secondly you don't
> know what you are talking about, there are certainly "more frames per
second"
> compare the first two logs here.  http://dickselectronics.cjb.net
You see more
> because there are more frames per second.
>
> You are wrong Scot. Please don't cause any more unnecessary drama.
>
> Cheers Richard.
>
>
>
> 
--------------------------------------------------------------------------
--
> To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the
quotes)
> in the body of a message (not the subject) to majordomo at lists.diy-efi.org
>
>

------------------------------------------------------------------------  
----
To unsubscribe from gmecm, send "unsubscribe gmecm" (without the quotes)
in the body of a message (not the subject) to majordomo at lists.diy-efi.org

----------------------------------------------------------------------------
To unsubscribe from gmecm, send "unsubscribe gmecm" (without the quotes)
in the body of a message (not the subject) to majordomo at lists.diy-efi.org