The 12.5Hz tone on pin 3 is coming from the controller, not generated by the SHC (it only does that on pin 6 100% of the time). So until the controller sees the SHC's 12.5Hz tone on pin 6, responds with its own tone on pin 3 and then turns it off some seconds later and reconfigures its use of the data lines, the SHC will not be successful on sending any commands to the controller on pin 3. So its not a real cause-and-effect (the SHC is not waiting for it to go off) its just that it will not be successful at sending any commands into that noise until is gets switched off by the controller.
toggle quoted messageShow quoted text
On 2021-05-04 5:08 p.m., John Petterson wrote:
On Tue, May 4, 2021 at 10:38 AM, Dave Schwartz wrote:
Well, I have to believe my own eyes.
So on further checking, the tones are separate from the send/receive exchange and display of the message on the SHC screen we were talking about. The tones have to be there in order for the OnStep to look for data signals on the receive data line (otherwise it expects to simply debounce those lines and look for button pushes from a basic hand controller). However, the tones themselves do not turn on the SHC - it is trying to get that first message to the onStep and get a response to tell it what coordinate mode to use. Since the receive data line (to the SHC) is the same line that the SHC transmits its second tone on, it has to be turned off in order for the SHC to see any responses from the OnStep. I am not sure exactly what it uses to turn that off, perhaps seeing the clock signal start to come in from the OnStep? In any case, from reading the code it appears that the messages and screen display are asynchronous to the tones on the lines that you are seeing, and they are both required for the link to come up.