Quote:
Originally Posted by
kur4o
I checked the logs and it looks like the bus freeze at mode 08 bombardment and than resumes normal communication.
it does clear the buffer completely after sending that 'bombardment' (because we need to get rid of a lot of echos, and there's no point reading them). i think that's what the 'gap' you're seeing is. i don't think it ever stops. freezing the bus for a sec can't really be a bad thing.
Quote:
Can you try to give a 4-5 attempts burst than wait for silence, than again 5 attempts,than wait for silence. I think when the mode 8 went through at least 5 second silence can be observed.
that is exactly how the old routine worked...but it didn't work on anything except an fbody.
the problem is the chance of those 'attempts' being timed properly and landing completely between that 9ms window is too low. there is just too much latency for it to work
Quote:
What is the normal silence on end of message , can we use that to identify the end of messages, For example read byte to byte delay and when a pause longer than the expected 8192 baud is received the end of message can be flagged and the buffer dumped.
i'm willing to try anything, but nothing i've done so far will let us send a message at exactly a time relative to the input. there seems to be just way too much latency. i want a different approach... this one that trust the OS to send a serial message at an exact time always results in someone not being able to use the software due to their interface and combination being different.
Quote:
As always if there's anything else at all I can do to help just lemme know--I will likely have more 94-95 Corvettes in the future, so I'd love to join your F-body flash party. :)
can you run eehack and get an 'idle traffic log'? it's in the raw command window