Hi Charles,

I was able to test new alignment and I'm not sure it works as expected.
I tested it by PC alignment (#:AA and 2 sync commands by plate solving) and I got 0 as alignment error value by SHC. The alignment icon was properly shown by SHC display after the 2nd sync.
Maybe just alignment error computation is wrong.

CS
Armando

With Main Unit 1.4.2, SHC 1.4.0, after changing mount type from SHC, I get this message: Set Value has failed!
But mount type is correctly changed.

I found a little bug in the TeenAstroUploader (V1.1.2)
When I start the firmware upload to the mainunit, the programm can't find the "Teensy Loader".
It's caused by a space in the folder name. I attached a screenshot from a video capture. There you can see the, that the path is cropped after the space.
Greets, Sebastian

I noticed that Stars and Messier objects with negative Declinations (all?) have incorrect Declinations! Probably the Herschel catalog is that way too, I didn't sample it.

Let me know if you will tackle fixing this, if not I'll do it but I'll take me longer probably as I assume you have a ready to go method of creating the C data arrays.

log VScode

C:\Users\lordz\GitHub\TeenAstro\libraries\TeenAstroLX200io\src\TeenAstroLX200io.cpp: In function 'LX200RETURN SyncGotoLX200(NAV, uint8_t&, uint8_t&, uint8_t&, bool&, uint16_t&, uint8_t&, uint8_t&)':
C:\Users\lordz\GitHub\TeenAstro\libraries\TeenAstroLX200io\src\TeenAstroLX200io.cpp:732:1: error: control reaches end of non-void function [-Werror=return-type]
  732 | }
      | ^
C:\Users\lordz\GitHub\TeenAstro\libraries\TeenAstroLX200io\src\TeenAstroLX200io.cpp: In function 'LX200RETURN SyncGotoUserLX200(NAV)':
C:\Users\lordz\GitHub\TeenAstro\libraries\TeenAstroLX200io\src\TeenAstroLX200io.cpp:757:1: error: control reaches end of non-void function [-Werror=return-type]
  757 | }
      | ^
C:\Users\lordz\GitHub\TeenAstro\libraries\TeenAstroLX200io\src\TeenAstroLX200io.cpp: In function 'LX200RETURN SyncGotoLX200AltAz(NAV, uint16_t&, uint8_t&, uint8_t&, bool&, uint16_t&, uint8_t&, uint8_t&)':
C:\Users\lordz\GitHub\TeenAstro\libraries\TeenAstroLX200io\src\TeenAstroLX200io.cpp:789:1: error: control reaches end of non-void function [-Werror=return-type]
  789 | }
      | ^
cc1plus.exe: some warnings being treated as errors
*** [pio\FRENCH\lib9b3\TeenAstroLX200io\TeenAstroLX200io.cpp.o] Error 1

For latitude < 0, this sequence: Goto Home, Goto Coord. / N causes the mount to perform a full 360º turn instead of staying in place like it should

When performing this test from Home:
goto South, goto East
The mount goes into horizon error and stops with an altitude of below 10 degrees.

Hi Charles,
I'm not sure about the value 64 used to switch from Stealth2 mode to SpreadCycle one

m_tmc5160->TPWMTHRS(64);

Let's assume 300 worm teeth and 4:1 reduction ratio.

  16MHz?
  t_clk=1/16e6 s

  // 24h - 3600s/h - 300 teeth - 4:1 red. ratio - 200 motor steps/rotation - 256 usteps
  1X (sid. speed) <-> ustep_period = 24*3600/300/4/200/256 = 0.001406 s
  t_step = 0.001406 s / t_clck = 22500 (= f_clk/f_usteps) @1X

  TPWMTHRS = 64 -> switch from Stealth2 to SpreadCycle @ 22500/64 X = 351.563X
  351.563X <-> 281RPM (1X <-> 0.8RPM)
  
  According to documentation possible jerk issues occur typically over 30 RPM (jerk is commonly neglected at 10-20-30RPM).

So let's assume to have jerk at 60X (48RPM) - TPWMTHRS = 64*351.563/60 = 375
I'd set
m_tmc5160->TPWMTHRS(375);

More generally I see the need for taking into account the overall reduction ratio to properly set TPWMTHRS.
So if you agree with me I would add a TMC5160 definition in TeenAstroCustomizations to allow TMC5160 tuning when desired.

Hi,

I'm having systematically no responses by Wifi some hours after connection has been established.
If I try to reconnect by ASCOM I get no response or a brief connection after which the issue occurs again.
If I reboot the WiFi module by SHC then connection can be established again.

Adding
WiFi.setSleepMode(WiFiSleepType::WIFI_NONE_SLEEP);
didn't help.

I'm using TeenAstro as a client connected to a router. The issue occurs on several routers. I'm tempted to think that as soon as a disconnection occurs it automatically reconnects but "not properly". In this case maybe an ESP reset could solve the issue.

Still does not work in version 1.2 (to reproduce: set both meridian limits to zero, point to az=179 degrees, switch-on tracking. Mount should stop at 180, but keeps tracking)

Hi,

I'm not sure I properly understood the code related to meridian limit check for German equatorial mounts.

if (!checkMeridian(axis1, axis2, CHECKMODE_TRACKING))
    {
      if ((staA1.dir && currentSide == PIER_WEST) || (!staA2.dir && currentSide == PIER_EAST))
      {
        lastError = ERRT_MERIDIAN;
        if (movingTo)
        {
          abortSlew = true;
        }
        if (currentSide >= PIER_WEST && !forceTracking)
          sideralTracking = false;
        return;
      }
      else if (lastError == ERRT_MERIDIAN)
      {
        lastError = ERRT_NONE;
      }
    }
    else if (lastError == ERRT_MERIDIAN)
    {
      lastError = ERRT_NONE;
    }

Is (!staA2.dir && currentSide == PIER_EAST)) value check meant to exclude slewing to S (while the scope is on the wrong side)?
If the aim is to stop tracking for Southern Emisphere observers I think the code should be

if ((staA1.dir && currentSide == PIER_WEST) || (!staA1.dir && currentSide == PIER_EAST))

:Mge... and :Mgw... commands do not cause any movement in RA. The declination commands :Mgn.. and Mgs... work fine.

Hi,
I gave a look at source code and I found that the SHC makes use of LX200 protocol to set latitude and longitude.
Anyway GPS values are double and it could be possible to tweak the command to keep a better resolution. Also the display could show the ss field.
What about improving GPS management?

Thanks!
Armando Beneduce

What are the right axis1 limits values? I'm on an equatorial mount..

By SHC axis1 min can't be less than -180deg. Lower values are rejected also by web server.
By SHC axis1 max can't be greater than 180deg. Greater values are rejected also by web server.

The controller currently is not usable. What's the latest working release?
I'm assuming your last indications related to right axis1 limits values (-270deg, 90deg) are still valid...

When I set "apparent" instead of "true", the mount goes into a crazy position (it goes horizontal when pointing Deneb, which is about 45 degrees altitude).

When switching-off the unit, the current slew speed setting is lost, and always initializes as "Guiding" when powering on.

I just tested current release 1.4 branch on the field on my equatorial mount and I found that PC alignment doesn't work anymore.
As soon as I activate PC alignment, just one sync (by PC) makes the SHC showing the alignment icon and the coordinates are wrong.
The same issue occurs also when trying to align by SHC. As soon as the first alignment sync occurs (after the the first star has been manually centred by SHC) coordinates are wrong and alignment fails.

dans le SHC, le ratio moteur est affiché avec une division par 100, et réécrit avec x100

LX200RETURN readTotGearLX200(const uint8_t& axis, float& totGear)
{
  char out[LX200sbuff];
  LX200RETURN ok = axis == 1 ? GetLX200(":GXMGR#", out, sizeof(out)) : GetLX200(":GXMGD#", out, sizeof(out));
  if (ok == LX200_VALUEGET)
  {
    totGear = 0.01 * (float)strtol(&out[0], NULL, 10);
  }
  return ok;
}
LX200RETURN writeTotGearLX200(const uint8_t& axis, const float& totGear)
{
  char cmd[LX200sbuff];
  sprintf(cmd, ":SXMGX,%u#", (unsigned long)(totGear * 100));
  cmd[5] = axis == 1 ? 'R' : 'D';
  return SetLX200(cmd);
}

pour que ça soit affiché correctement, il faut modifier ça

bool SmartHandController::menuSetTotGear(const uint8_t &axis)
{
  float totGear;
  if (!DisplayMessageLX200(readTotGearLX200(axis, totGear)))
    return false;
  char text[20];
  sprintf(text, T_GEAR " M%u", axis);
  if (display->UserInterfaceInputValueFloat(&buttonPad, text, T_RATIO, &totGear, 1, 60000, 5, 2, ""))
  {
    return DisplayMessageLX200(writeTotGearLX200(axis, totGear), false);
  }
  return true;
}

mais dans le main, c'est géré bizarrement

      // :SXMGn,VVVV# Set Gear
      int i;
      bool ok = false;
      if ((command[4] == 'D' || command[4] == 'R')
        && strlen(&command[6]) > 1 && strlen(&command[6]) < 11
        && atoi2(&command[6], &i))
      {
        if (command[4] == 'D')
        {
          if (!motorA2.isGearFix)
          {
            double fact = (double)i / motorA2.gear;
            cli();
            staA2.pos = fact * staA2.pos;
            sei();
            StopAxis2();
            motorA2.gear = (unsigned int)i;
            XEEPROM.writeInt(getMountAddress(EE_motorA2gear), i);
            ok = true;
          }
        }

"i" n'est pas défini, et on divise le ratio par i ??

et ensuite, c'est utilisé tel quel dans mainunit.ino

void updateRatios(bool deleteAlignment, bool deleteHP)
{
  cli();
  geoA1.setstepsPerRot((long)motorA1.gear * motorA1.stepRot * (int)pow(2, motorA1.micro));
  geoA2.setstepsPerRot((long)motorA2.gear * motorA2.stepRot * (int)pow(2, motorA2.micro));

il faudrait retrouver le rapport de 100

lors de mes tests, le ratio utilisé pour bouger les axes est bien à x1
si je mets "16" depuis la telco, ça prend en compte 1600 et tourne 100x trop vite

si je divise par 100 dans UPDATE_RATIOS ça retrouve un fonctionnement normal

void updateRatios(bool deleteAlignment, bool deleteHP)
{
  cli();
  geoA1.setstepsPerRot((long)motorA1.gear / 100 * motorA1.stepRot * (int)pow(2, motorA1.micro));
  geoA2.setstepsPerRot((long)motorA2.gear /100 * motorA2.stepRot * (int)pow(2, motorA2.micro));

Hi,

a delay seems to be required for GPS initialization.
I need to figure out how to keep my old fork while trying to properly make new pull requests: I see some features have been discarded.
In the meantime this is the small GPS patch:

diff --git a/TeenAstroMainUnit/TeenAstroMainUnit.ino b/TeenAstroMainUnit/TeenAstroMainUnit.ino
index 0c72bda..18e024a 100644
--- a/TeenAstroMainUnit/TeenAstroMainUnit.ino
+++ b/TeenAstroMainUnit/TeenAstroMainUnit.ino
@@ -147,6 +147,7 @@ void setup()
 #if VERSION != 220
   GNSS_Serial.begin(9600);
 #endif
+  delay(1000);
   hasGNSS = GNSS_Serial.available() > 0;
 
   //Focuser connection

Please check the effective motor speed. With the new update they move a 1/100 or less than the normal.
During goto you could hear the sound of the motors but barely see the movement.
I tested two different teenastro on two different mount and i uploaded data with two different .tac files.
I tried another spare teenastro with 1.2.x on the same mount and worked, also reinstalling a 1.3.x firmware where it was 1.4.10 worked well.