[Gmecm] Sunbird/$58 ALDL protocol

Mon Jun 12 20:14:30 UTC 2006

Your timing issue sounds familiar. I just ran into a (perhaps identical, if 
not) similar issue over the weekend. Until Saturday, I could connect up to 
$58 just fine on the test bench with no packet errors. Strangely, on 
Saturday I began to get packet errors on certain UI screens in my test app. 
Only certain screens caused these errors; others did not. The same code is 
being run in all screens. This suggests a timing issue related to UI update. 
What doesn't make sense, though, is that there's no way that timing could 
affect my acquisition code, really. As you mention, only the inter-byte 
timing could be affected (since the message timing times out at ~5 seconds, 
and I'm definitely not going over that!). My inter-byte timing is long 
enough (I've got it at 50ms, I think. I'm not in front of the code at the 
moment). At least I thought.

I wonder if we're hitting the same issue.

What's more, although I can connect fine on the bench, when I try on my 
buddy's Typhoon, it won't connect reliably. Stupid $58 code is sensitive!

I'm going to try clearing out the message scheduler's table in the $58 code. 
That should shut the chatter up and hopefully open things up for simple 
connection, although doing so is only a short term solution (it's not right 
to expect users to do this).

Mark

----- Original Message ----- 
From: "Robin Handley" <Robin at FuryWorld.fsnet.co.uk>
To: <gmecm at diy-efi.org>
Sent: Monday, June 12, 2006 1:05 PM
Subject: Re: [Gmecm] Sunbird/$58 ALDL protocol

>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
>
> _______________________________________________
> Gmecm mailing list
> Gmecm at diy-efi.org
> http://lists.diy-efi.org/mailman/listinfo/gmecm
> 