Re: Problem with SHC

John Petterson

On Tue, May 4, 2021 at 04:37 PM, Dave Schwartz wrote:
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).
Umm, no.  The SHC provides both pin 3 and pin 6 12.5 hz signals.  It looks for the much higher rate clock on pin 4 from the OnStep box, then shuts off the pin 6 tone and uses that line for its TX data.  Here is the code that does the send tone on both RAe and RAw (3 and 6).
void shcTone() {
  static volatile boolean tone_state=false;

  if (tone_state) {
    if (millis()-SerialST4.lastMs>2000L) {
  } else  {
    if (millis()-SerialST4.lastMs>2000L) {

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.

OnStep actually has to see BOTH of the SHC tones before it will set up the link. It does that by starting the clock on pin 4, at which time the SHC turns off the tone on pin 6 and uses that for TX data.  Again, here is the code that detects the SHC is present:

  if (st4e.hasTone()) {
    if (!shcActive) {
      if (st4w.hasTone()) {
        pinMode(ST4DEs,OUTPUT);    // clock
        pinMode(ST4DEn,OUTPUT);    // send data
        digitalWrite(ST4DEs,HIGH); // idle
        VLF("MSG: SerialST4 mode activated");


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.

This is true, although it is the SHC itself that is obliterating its own send data until it sees the clock.

I can show you the dual trace oscilloscope output that prove this sequence if anyone want to see them.

Join to automatically receive all group messages.