Re: Problem with SHC


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.

Join main@onstep.groups.io to automatically receive all group messages.