[Gmecm] Sunbird/$58 ALDL protocol

[Robin Handley]

I think I've got to the bottom of why my test program was breaking down
after 3 successful data message requests. It was our good friend,timing,
again. There was no bug in the program except for the fact that, after
dumping 3 messages worth of hex to the screen, at the next message request
the PC had to scroll the screen. The time taken to do that was enough to
ruin the handshake with the Sunbird code. Although the previous messages had
kicked the Sunbird code out of 'chatter' mode, I was displaying my data
request message bytes on consecutive lines, so there was a slight time delay
BETWEEN BYTES as the screen was scrolled between them being sent out. The
Sunbird code seems to be highly sensitive to this as well!!!

Despite hours of trying, I still haven't managed to get ALDLMON to lock on
quickly to the Sunbird ALDL. It gets there in the end as it keeps chucking
out a data request and eventually the timing must be right. I've tried to
patch in the equivalent of my 'C' code to the Pascal in ALDLMON (waiting for
the end of the chatter message and sending out a data request ASAP after),
but so far no joy and I don't know why. Very frustrating!!!

Robin

----- Original Message -----
From: "Mark Mansur" <mmansur at hotmail.com>
To: <gmecm at diy-efi.org>
Sent: 04 June 2006 19:33
Subject: Re: [Gmecm] Sunbird/$58 ALDL protocol


> Hi Robin -
>
> I've had much recent experience with $58 in my work to make TunerPro much
> more robust.
>
> Indeed $58 is rather chatty and timing sensitive. The ECM/BCC send "I'm
> alive" chatter message ($F0 $55 $BB) every 200ms (if I remember
correctly).
> In order to get that to stop, you need to listen for the chatter message
and
> respond with a MODE 1 dump request in the window between the chatter
> messages. Some docs seem to mention that you can send the message at any
> point between, but that doesn't seem to be the case. I send the mode 1
> request 1ms after I receive the $BB. Note that many other ECMs that
function
> like this actually require a mode 8 command to silence chatter (and a Mode
0
> to restart normal comms), but $58 requires a mode 1 dump. If you get a
> successful reply from the mode 1 dump request, the ECM will be silent for
as
> long as you continue to send requests to the ECM. If your requests cease
for
> 5 seconds, the chatter will once again begin.
>
> What you describe does indeed sound like a bug in your test program (are
you
> flushing the FIFO as you should be?).
>
> More helpful information from Blacky can be found here:
> http://www.diy-efi.org/gmecm/archive/html_gm_archive_num_12/msg08681.html
>
> Hope this helps, and good luck!
>
> Mark
>
>
> ----- Original Message -----
> From: "Robin Handley" <Robin at FuryWorld.fsnet.co.uk>
> To: <gmecm at diy-efi.org>
> Sent: Sunday, June 04, 2006 9:26 AM
> Subject: Re: [Gmecm] Sunbird/$58 ALDL protocol
>
>
> Hey Bill,
>
> I think you're dead right about the timing sensitivity. I'm really
surprised
> that GM made the $58 code behave differently from the $8D, though. My
> current $58 test program waits until it sees the $BB checkum of the
chatter
> message and immediately after sends a request for Mode 1 data - which the
> $58 responds to with data, and the chatter message is inhibited for a few
> seconds. It seems that, if the Mode 1 request doesn't come out at just the
> right time, it is ignored and the chatter messages just churn out. That
> isn't the case with $8D. The weird thing is that, with my test program,
the
> $58 code gives me the Mode 1 data 3 times consecutively from my program
> start and then ignores subsequent requests! If I stop and restart my
program
> it does the same again. This sounds like a bug in my program, but I tried
> the program with ANHT/$8D and it worked fine! I know the $58 should work
> repeatedly because, once locked on, ALDLMON works. This is really
confusing
> me ATM! :-)
>
> BTW: Yes, the Turbo P4 doc is the one I was referring to. Following what
it
> describes, I've been testing the Mode 4 ability to turn the fan on, like I
> did for ANHT/$8D, and having problems with that too, using $58! I expected
> it to work straight away! :-(
>
> BR,
>
> Robin
>
> ----- Original Message -----
> From: "Bill Shaw" <b.shaw at comcast.net>
> To: <gmecm at diy-efi.org>
> Sent: 04 June 2006 16:29
> Subject: Re: [Gmecm] Sunbird/$58 ALDL protocol
>
>
> > Hi Robin,
> >
> > The $58 code is very timing sensitive.  It's been a while since I've
> played
> > with it so the details are a bit fuzzy,  but as I remember you have to
> send
> > a mode change within a couple hundred milliseconds of the 'chatter'
packet
> > to get it to shut up and start taking commands.  Once you change mode
> it'll
> > respond OK to your commands until it times out aned returns to 'chatter'
> > mode.  Do you have the Turbo-P4 doc?  It's spelled out pretty well in
> there,
> > look for 'turbo_p4' or something like that on incoming.
> >
> > Best,
> >
> > Bill
> >
> > > From: "Robin Handley" <Robin at FuryWorld.fsnet.co.uk>
> > > Reply-To: gmecm at diy-efi.org
> > > Date: Sun, 4 Jun 2006 15:45:12 +0100
> > > To: <gmecm at diy-efi.org>
> > > Subject: [Gmecm] Sunbird/$58 ALDL protocol
> > >
> > > I've noticed different behaviour on ALDL between ANHT/$8D and
> Sunbird/$58
> > > code in my '727. The ANHT/$8D seems to behave more
> 'sensibly/predictably.'
> > > than the Sunbird/$58 code!
> > >
> > > I'm currently trying to find a robust algorithm to talk to the
> Sunbird/$58
> > > code. I have modified ALDLMON (which works but takes longer to lock on
> than
> > > it does with ANHT/$8D) and played around with some noddy programs of
my
> own
> > > (not w/o some issues, which I'm still trying to get to the bottom of).
> Has
> > > anybody played with ALDL from Sunbird/$58? The code chucks out $F0 $55
> $BB
> > > repeatedly. The Turbo code doc. indicates that the ALDL monitor should
> > > reply, but does not appear to say with what. Anybody know what the
> correct
> > > response is?
> > >
> > > Robin