Problem with SHC


Prasad
 

I have two SHC units, both running ESP32, and kits were from my good friend George Cushing.  

Today I uploaded SHC firmware using the latest "Master" version into one of my ESP32 based SHC. I connected it to my MiniPCB2 controller that runs OnStep v3.16. After the initial wait, I got "Connection Warning" followed by "Coordinates Observed Place..." on the display. 

I disconnected the SHC and kept it aside. I then took out my other (second) SHC that has its firmware v3.16 and connected this SHC to my MiniPCB2. This SHC started up correctly without the error. I got to see the RA and DEC coordinates as it always does. 

My problem seems to be only with one SHC that has its firmware taken from the latest "Master". 

Any tips on what could be going wrong? 

Prasad
Eastern PA, near Philly


Ray650
 

I'm seeing the same issue with an ESP32 SHC and R32/CNC V3 OnStep controller. The controller is running beta version 4.23.m (I'm using the beta to get the CNC3 pinmap), and the SHC is running version 1.9.k.

After the initial "OnStep Teen Astro" splash screen, I see "connection warning" followed by "coordinates" and "observed place" on the next line, then the screen goes blank. The wifi server LED continues to blink and does not establish a serial connection with the R32 board. Also, the android app shows a failed bluetooth connection.

On disconnecting the SHC and restarting the controller, the wifi and bluetooth connections are normal.


Ray650
 

Here's the rest of the story...

I assumed the the problem was a mismatch between the RJ pin assignments on the SHC and on the CNC V3 board. I used an RJ breakout board with jumpers to the shield board.

What works is this:

Pin 1       +5V
Pin 2       GND
Pin 3       RA- (labeled coolant on CNC)
Pin 4       DE- (labeled spn_dir on CNC)
Pin 5       DE+ (labeled hold on CNC)
Pin 6       RA+ (labeled resume on CNC)

In the wiki, the pin labels on the schematic image of the CNC V3 board are somewhat difficult to read. It might be helpful to include a table with the shield to ST4 mapping.
Thanks!


Ken Hunter
 

I found this thread while troubleshooting some of my SHC builds.

I have the problem mentioned on several of my boards. So far I have completed 5 of them
and it seems like only one is working correctly. 2 of them give the Warning Coordinates
Observed error and 2 of them seem to be OK until I want to test the Align sequence.
As soon as I hold the Joystick button depressed for 2 seconds the screen starts to refresh
then the SHC freezes, no button response at all and I have to power down to reset it.
Powering down and resetting does not make the SHC's work correctly for me.

1 good SHC out of 5 seems to be a fairly high failure rate to me. I am confident that my
soldering skills are up to par, NASA didn't complain when I was doing assembly work on
spaceflight qualified boards back in the 70's.

I am using the latest build of OnStep V 4.24a3 and SHC addon associated with that V1.9.1
At one time I saw a simple test sketch for troubleshooting the SHC button response but I
can no longer remember where I saw that. 

One thing I might be doing wrong is I have my MCU's soldered into the circuit boards and
can't remove them easily to re-flash the programs. They seem to flash OK on several different
ESP32 "boards" setup so I don't think that is the problem.

I originally thought I had a bad display since the first one to do this started what
looked like a display refresh when it failed but testing the 2 "bad" displays on the one SHC
that is working properly negates that possibility.

Any thing I am missing? My search for help hasn't shown me anything to verify that this
"bug" has been identified and fixed.

Ken


 

i have the same issue as well...
 
recently i try to upload latest fresh WIFI / SHC / firmware 4.23 , after finish upload everything the SHC show 
"Connection Warning" followed by "Coordinates Observed Place..." 
 
and ones it skip the connation warning massage...error, it still able load the main screen on SHC, but the screen seem froze or go blank while pressing button.

then i tot is firmware issue, so i reupload firmware 3.16 including Wifi and SHC... the issue still same....without SHC no problem detecting GSP from Onstep Apps also able to upload current location.
 
i wonder is ESP8622 module issue or cable or pullup resistor.


John Petterson
 

Ken,

That message indicates that the SHC is unable to communicate with the OnStep. It makes 4 attempts about 4 seconds apart,  It could be the OnStep is not starting fast enough, it could be a baud rate issue.  I have seen that message on startup but then been able to use the SHC normally,  This note just caused me to look at the code to understand why...

Howard can talk more about how that link works, but there is an audio tone sent between the two devices that they use to detect one another.  Once that happens, they revert to a data send/receive on 2 lines and keep the audio tone on the others so they can detect loss of connection (it you unplug the SHC). The SHC sends a request to the OnStep for a mode selection to use for the coordinate mode for the aiming location.  If no response is received after 4 attempts, it displays that message and then defaults to using the Observed Place method, and continues.  If in fact the onStep then finishes its startup, the SHC should work even though it has displayed that message.

That connection does seem to be a weak point overall in the OnStep operation.

So the first question is, do you have pull-up resistors on all 4 data lines at both ends of the cable?  The issue could be either end not seeing the message from the other device.

Then I would get out an oscope and look at each of the 4 data lines on the one that works and log those, then see what is not working the same in the ones that fail now that you know what to watch for.  (I am assuming if you were assembling boards for NASA you have access to and can use a scope...)


 

after change a better quality cable and make sure the SHC configuration ST4_INTERFACE     ON_PULLUP, all work fine ! error connection warning.. all go away


Ken Hunter
 

Thanks John... Where did  you get the info on how OnStep works, communicates with the SHC etc? I am learning a bit at a time as I come across these issues. Would be nice for Howard to start up a tech school LOL.
Yes, I do have a scope and a whole shelf of other goodies, mainly for RF generation and measurement (HAM Radio since 1960).

Funny thing is... I take a working SHC off my CNC3 build and plug the cable into the non-working SHC and get the conditions described then reconnect the working SHC and it does the connection and works ... Nothing changed or touched except the SHC at the end of the same cable. It also works this way with at least 2 of my MaxESP builds so I can't see it being anything but the SHC's. Something is running right on the edge of working/not working and that is probably why so many are having troubles with their builds and giving up astronomy to taking up knitting. I am not one to give up and I am also NOT a programmer I struggle to understand what is happening and really appreciate when someone such as yourself gives me insight in to what OnStep is doing.

I'll try another cable (I have 30 of them for the SHC's I'm building) and see if it behaves differently. Will also do scope tests on the data lines to see if anything pops out. If I find anything I will document it and report back.

Still need to find the SHC button test sketch again...

Ken


John Petterson
 

Howard has maintained that the cable needs to be short, but with the pullup resistors I have long (8-10 feet) coiled cords on mine with normally no issues.  I had one problem recently that I still do not have an answer for, but I have 5 working SHCs.  Note that I am using the Teensy version, using a board that I designed (and the 5 devices include at least 3 different generations of that board...) I started with design that and never switched although I will likely have to now.

Some of my knowledge is from issues I had and help I got from others on here, other parts is from reading the code.  I have a little electronic background but a career of writing code.  That is both a benefit and a curse as I don't take someone else's word for much  until I peruse the code and check it out myself.

I agree it is something at the edge.  Either timing or voltage levels.... those are the two things that could be marginal.  Do try plugging in one of the ones that gives that error message, wait a minute after that comes up, set date and time and start tracking and then see if the SHC actually works.  Press directional buttons to activate the motors,
 go through the menus.


Ken Hunter
 

OK... Not yet connected to the motors but I must admit that I was able to fix 2 of them...
The C1 electrolytic capacitors were soldered in perfectly - backwards on all 4 of the non-working SHC's.
Can't imagine doing that myself. Must have been Murphy trying to help. The 2 still non-working SHC's
lose the signal on pin 3 and they disconnect (SHC freezes) whenever I double click or long click the
joystick. All of the switches are pulling the signal lines low as they should but the MCU is losing lock
somehow. Getting late and I need to get some beauty sleep before I get too tired and start doing bad
things... Like soldering capacitors in backwards...

Even though I haven't connected the motors yet, the CNC3 controller sounds (beeps) when I lose the
connection When I command an alignment or GOTO the buzzer announces the start and end of slewing
so I think that is all working OK.

I found in a message (thread #32637) saying that I can connect Aux2 to the Buzzer on my MaxESP's
By #define TonePin 4 in the config.h file and setting the buzzer frequency. I'm gonna try that tomorrow
though I have no idea how to set the frequency. My buzzer just needs voltage to sound off so I hope that
will work OK. If not I'll double check with Howard for clarification.

Ken


Dave Schwartz
 

For the real story on how the SHC comms work, see https://onstep.groups.io/g/main/message/32803

I'm surprised the electrolytic capacitors didn't go 'pop' when reversed biased.  That's been done before on controller boards by soldering them in backwards but that was 12V backwards on a 50V capacitor instead of 5V on a 35V one. Check to make sure the top is not swelled upward - that's what they do when they fail in only a minor way. Usually the more serious failures tears them open at the designed-in stress relief (the pressed 'X' on the top) which relieves pressure before it can really go 'bang'.

On 2021-05-04 3:55 a.m., Ken Hunter wrote:
OK... Not yet connected to the motors but I must admit that I was able to fix 2 of them...
The C1 electrolytic capacitors were soldered in perfectly - backwards on all 4 of the non-working SHC's.
Can't imagine doing that myself. Must have been Murphy trying to help. The 2 still non-working SHC's
lose the signal on pin 3 and they disconnect (SHC freezes) whenever I double click or long click the
joystick. All of the switches are pulling the signal lines low as they should but the MCU is losing lock
somehow. Getting late and I need to get some beauty sleep before I get too tired and start doing bad
things... Like soldering capacitors in backwards...

Even though I haven't connected the motors yet, the CNC3 controller sounds (beeps) when I lose the
connection When I command an alignment or GOTO the buzzer announces the start and end of slewing
so I think that is all working OK.

I found in a message (thread #32637) saying that I can connect Aux2 to the Buzzer on my MaxESP's
By #define TonePin 4 in the config.h file and setting the buzzer frequency. I'm gonna try that tomorrow
though I have no idea how to set the frequency. My buzzer just needs voltage to sound off so I hope that
will work OK. If not I'll double check with Howard for clarification.

Ken


John Petterson
 

On Tue, May 4, 2021 at 09:27 AM, Dave Schwartz wrote:
For the real story on how the SHC comms work, see https://onstep.groups.io/g/main/message/32803

Dave,

That may have been true in the past, but it no longer appears to be.  This is  the initialization code in the SHC after getting the display initialized and flushing the comm port buffer to the OnStep:

  DisplayMessage(L_ESTABLISHING, L_CONNECTION, 1000);

  // OnStep coordinate mode for getting and setting RA/Dec
  // 0 = OBSERVED_PLACE (same as not supported)
  // 1 = TOPOCENTRIC (does refraction)
  // 2 = ASTROMETRIC_J2000 (does refraction and precession/nutation)
  char s[20]="";
  int thisTry=0;
again:
  delay(4000);
  if (GetLX200(":GXEE#", s) == LX200VALUEGET) {
    if (s[0]=='0') {
      telescopeCoordinates=OBSERVED_PLACE;
      DisplayMessage(L_CONNECTION, L_OK "!", 1000);
      VLF("HCM: SHC Connection established");
    } else
    if (s[0]=='1') {
      telescopeCoordinates=TOPOCENTRIC;
      DisplayMessage(L_CONNECTION, L_OK "!", 1000);
      VLF("HCM: SHC Connection established");
    } else
    if (s[0]=='2') {
      telescopeCoordinates=ASTROMETRIC_J2000;
      DisplayMessage(L_CONNECTION, L_OK "!", 1000);
      VLF("HCM: SHC Connection established");
    }
  } else {
    if (++thisTry <= 4) goto again;
    telescopeCoordinates=OBSERVED_PLACE;
    DisplayMessage(L_CONNECTION, L_WARNING "!", 1000);
    DisplayMessage(L_COORDINATES, L_OBSERVED_PLACE ".", 2000);
  }
}

This is the 4 tries to get a response that I described after putting up the Establishing Connection message.  There does not appear to be any waiting for a tone, and there is not yet any other code running as this is in the initialization routine of the Arduino code.  OnStep's response to that :GXEE message is:

              case 'E':
                // coordinate mode for getting and setting RA/Dec
                // 0 = OBSERVED_PLACE
                // 1 = TOPOCENTRIC (does refraction)
                // 2 = ASTROMETRIC_J2000
                reply[0]='0'+(TELESCOPE_COORDINATES-1);
                boolReply=false;
                supress_frame=true;
              break;
            

So that is all it appears to take to get the comm link up.

 

 


Dave Schwartz
 

Well, I have to believe my own eyes.

Last week I verified exactly what I wrote. Using my digital oscilloscope, I saw a 12.5Hz square wave on pin 6 the instant the SHC powered on and this persisted as long as the power was on.

Switching the probe to pin 3 on the next session, a 12.5Hz square wave appeared there shortly after OnStep started. This waveform persisted for about 15 seconds and then disappeared. The SHC display going from 'Establishing connection' to the main information display coincided with the 12.5Hz waveform on pin 3 going away.

Pin 3 then showed sporadic and non-regular square waves exactly as if it were being used for data transfer as described in the comment at the top of ST4SerialSlave.cpp:

ST4 port data communication scheme:

5V power ---- Teensy3.2, Nano, etc.
Gnd ---------

HC              Signal               OnStep
RAw  ----        Data         --->   Recv. data
DEs  <---        Clock        ----   Clock
DEn  <---        Data         ----   Send data
RAe  ---- 12.5Hz Square wave  --->   100% sure SHC is present,
switches DEs & DEn to OUTPUT

Data is exchanged on clock edges similar to SPI so is timing
insensitive (runs with interrupts enabled.)

One data byte is exchanged (in both directions w/basic error
detection and recovery.)  A value 0x00 byte
means "no data" and is ignored on both sides.  Mega2560 hardware
runs at (fastest) 10mS/byte (100 Bps) and
all others (Teensy3.x, etc.) at 2mS/byte (500 Bps.)

On 2021-05-04 11:12 a.m., John Petterson wrote:
On Tue, May 4, 2021 at 09:27 AM, Dave Schwartz wrote:

For the real story on how the SHC comms work, see
https://onstep.groups.io/g/main/message/32803
<https://onstep.groups.io/g/main/message/32803>

Dave,

That may have been true in the past, but it no longer appears to be.  This is  the initialization code in the SHC after getting the display initialized and flushing the comm port buffer to the OnStep:

DisplayMessage(L_ESTABLISHING, L_CONNECTION, 1000);

  // OnStep coordinate mode for getting and setting RA/Dec
  // 0 = OBSERVED_PLACE (same as not supported)
  // 1 = TOPOCENTRIC (does refraction)
  // 2 = ASTROMETRIC_J2000 (does refraction and precession/nutation)
  char s[20]="";
  int thisTry=0;
again:
delay(4000);
  if (GetLX200(":GXEE#", s) == LX200VALUEGET) {
    if (s[0]=='0') {
telescopeCoordinates=OBSERVED_PLACE;
DisplayMessage(L_CONNECTION, L_OK "!", 1000);
VLF("HCM: SHC Connection established");
    } else
    if (s[0]=='1') {
telescopeCoordinates=TOPOCENTRIC;
DisplayMessage(L_CONNECTION, L_OK "!", 1000);
VLF("HCM: SHC Connection established");
    } else
    if (s[0]=='2') {
telescopeCoordinates=ASTROMETRIC_J2000;
DisplayMessage(L_CONNECTION, L_OK "!", 1000);
VLF("HCM: SHC Connection established");
    }
  } else {
    if (++thisTry <= 4) goto again;
telescopeCoordinates=OBSERVED_PLACE;
DisplayMessage(L_CONNECTION, L_WARNING "!", 1000);
DisplayMessage(L_COORDINATES, L_OBSERVED_PLACE ".", 2000);
  }
}

This is the 4 tries to get a response that I described after putting up the Establishing Connection message.  There does not appear to be any waiting for a tone, and there is not yet any other code running as this is in the initialization routine of the Arduino code.  OnStep's response to that :GXEE message is:

case 'E':
// coordinate mode for getting and setting RA/Dec
// 0 = OBSERVED_PLACE
// 1 = TOPOCENTRIC (does refraction)
// 2 = ASTROMETRIC_J2000
reply[0]='0'+(TELESCOPE_COORDINATES-1);
boolReply=false;
supress_frame=true;
break;

So that is all it appears to take to get the comm link up.


Ken Hunter
 

// Switching the probe to pin 3 on the next session, a 12.5Hz square wave appeared there shortly after OnStep started. This waveform persisted for about 15 seconds and then disappeared. The SHC display going from // 'Establishing connection' to the main information display coincided with the 12.5Hz waveform on pin 3 going away.

I see the intermittent square waves until I press the joystick for 2 seconds then ALL GOES AWAY, nothing after that. One thing I noticed is that I do not have 5 volts on Pin 1 or pin 3. It is more like 3 volts p/p.

Still some of the SHC's work, some don't.

Where is the "button Test" sketch hiding?

Ken


Ken Hunter
 

From the CNC3 WIKI instructions...


ST4 interface:This is enabled by setting ST4_INTERFACE  ON in the configuration file.  If the ST4_HAND_CONTROL ON option is used additional capabilities become available, read the configuration file for more information.  The order of most pins match those of the RJ12 jack they should be connected to (search eBay for "RJ12 breakout"):

Pin 1: +5v or NC
Pin 2: Gnd
Pin 3: RA- (I34)
Pin 4: Dec- (IO18)
Pin 5: Dec+ (IO4)
Pin 6: RA+ (I35)

Note: you MUST add 2k pull-up (to 3.3V) resistors to each ST4 line (RA-, Dec-, Dec+, RA+.)  You can how one user added the pull-up resistors here.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

This is after removing the resistor because the ESP32 is NOT a 5 volt device...

Could the "Borderline" operation be due to this?


John Petterson
 

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.


Dave Schwartz
 

The ESP32 itself (the bit with the square silver metal shield that comes from Espressif Inc. a.k.a. the MCU) is a 3.3V device but the carrier (the 'development kit C board') it is mounted on is built to operate from 5V. This is because of the 5V sourced from the USB port  which is not part of the MCU. The USB 5V can be used to run the MCU. The 5V from the USB is put through a 5-to-3.3V regulator and both those voltages are used to operate the cp2102 (yes, it has one of those) and MCU subcomponents.

When you are not operating the MCU from the USB power, external power can be supplied to either the 5V pin (which runs to the input of the 5-to-3.3 regulator (the same as from the USB) or by providing 3.3V on that pin which is normally the output from the regulator (but you will not have USB functionality because the cp2102 won't be getting its 5V reference).

Since 5V is the standard for the optional voltage on an ST4 connector that's why the power for the DevKitC module is taken from there.

The official DevKitC board uses an NCP1117 regulator which, in its 3.3V version says that the input needs to be between 4.75V and 5.3V.

So for any ESP32 SHC, if the voltage measured at the 5V pin is lower than 4.75 volts, possibly due to voltage loss in a connector or the cable) then it is not guaranteed to operate. If by some miracle it were to operate below this range, the ncp1117 regulator is only rated to supply 10ma at the best of times and therefore any button use (which by definition is shorting a pulled-up GPIO to ground and thus consuming some current) is highly likely to brown out the regulator when running with an out-of-spec input. That may be why your MCU is resetting when you hold down a button.

While the ESP32 is not rated for 5V on the GPIO lines, nearly everybody who's used one says that it is 5V-tolerant so that's why we can get away with pulling it up to 5V. And since we do it through a 2.2K resistor, the current that can be supplied to the GPIO is limited to below its 28ma 'letting the smoke out' rating anyway.

The SHC itself does not pull up the 4 signal lines - that's done on the controller. For similar reasons as above, the ESP32 will be OK with those lines being pulled up to 3.3V or 5V because the pull-up resistors there also limit the current.

Similar situation on the OnStep controller MCU on the other end of the signal lines... even if the GPIO lines there are not rated to be 5V-tolerant (all STM32's are) the current is restricted to below their 'let the smoke out' limit.

The signal voltages don't have to go between exactly 0 and 3.3V to be logic high or low. All MCUs will have a similar spec but for the ESP32-WROOM-32, 'low is anything below .25xVdd and 'high' is anything above .75xVdd (when Vdd = 3.3V, low <= 0.825V and high >= 2.475).

The diagnostics sketch is in the assembly document: https://docs.google.com/document/d/1Yqapj0lpiI2ryzUzsBS99wqcaYcddTj4RX0LUBaBIEE/edit#heading=h.aewrbh38x497

On 2021-05-04 3:12 p.m., Ken Hunter wrote:
// Switching the probe to pin 3 on the next session, a 12.5Hz square wave appeared there shortly after OnStep started. This waveform persisted for about 15 seconds and then disappeared. The SHC display going from // 'Establishing connection' to the main information display coincided with the 12.5Hz waveform on pin 3 going away. I see the intermittent square waves until I press the joystick for 2 seconds then ALL GOES AWAY, nothing after that. One thing I noticed is that I do not have 5 volts on Pin 1 or pin 3. It is more like 3 volts p/p.

Still some of the SHC's work, some don't.

Where is the "button Test" sketch hiding?

Ken


Dave Schwartz
 

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.

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.


George Cushing
 

You'll notice I have female headers on this SHC.
SHC Mule.jpg

I use this SHC to test the ESP32 modules before I solder them to a PCB. I've just received some of these "bare" boards;

bare board.jpg
The ESP32S will be mounted on the bottom and the pins aren't soldered. So these can be mounted under the board in female headers. 


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) {
    tone_state=false;
    digitalWrite(ST4RAe,HIGH);
    if (millis()-SerialST4.lastMs>2000L) {
      digitalWrite(ST4RAw,HIGH);
    }
  } else  {
    tone_state=true;
    digitalWrite(ST4RAe,LOW);
    if (millis()-SerialST4.lastMs>2000L) {
      digitalWrite(ST4RAw,LOW);
    }
  }
}

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
        shcActive=true;
        SerialST4.begin();
        VLF("MSG: SerialST4 mode activated");
      }
      return;

 

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.