Howard,

The latest Alpha is missing a define for the lower limit for Max Rate

I added this to make it compile:

// Lower limit (fastest) step rate in uS for this platform #define MaxRate_LowerLimit 16

But not sure if 16 is suitable with the new fractionals.

We are sure that 20 works without mode switching.

There are 12 objects missing from the Herschel catalog. Yet to be identified, and reported to the Open NGC project.

For Messier, there are only 107 objects, instead of 110. The Open NGC data marks M102 as a duplicate. But it is also missing M45 (Pleiades) and M40 (Winnecke 4, a double star).

Trying to compile OnStep Alpha gives the error : Focuser2 enabled without Focuser1 being enabled.

This is traced to Config.Ramps14.h having :

#define FOCUSER2_ON

But earlier FOCUSER1_OFF

Changing to FOCUER2_OFF solves this.

For the last two nights, I did a 6 star align, without touching the alt and az knobs, but got very different results.

All alignment was done via plate solving.

For Aug 24th, I did a Refine PA, and then a 6 star align, the results were:

► 21" ▲ 208"
The raw values from INDI were: Alt +208 Az -16

On Aug 25th, I did not move the mount at all, nor touch the knobs.

A 6 star align got the results:

◄ 175" ▼ 208"
Raw values from INDI: Alt -208" Az 128"

Note the very different values.

Why should that be? An error of 32" one way or the other is fine, but for +208 to be -208? How can that be?

I am using a patch to increase granularity. This makes the code for the STM32 just like Teensy by removing the FAST_PROCESSOR defines in AlignEq.ino. But that should not matter.

With LV8729, there should be no TMC stuff, yet the following error happens:

../OnStep/StepMode.ino: In function 'void enableStepperDrivers()':
StepMode:346:115: error: 'tmcAxis1' was not declared in this scope
  346 |     if (Axis1_EN != -1) { digitalWrite(Axis1_EN,AXIS1_DRIVER_ENABLE); } else { if (AXIS1_DRIVER_MODEL == TMC_SPI) tmcAxis1.setup(AXIS1_DRIVER_INTPOL,AXIS1_DRIVER_DECAY_MODE,AXIS1_DRIVER_CODE,axis1Settings.IRUN,axis1SettingsEx.IHOLD); }
      |                                                                                                                   ^~~~~~~~
StepMode:348:115: error: 'tmcAxis2' was not declared in this scope
  348 |     if (Axis2_EN != -1) { digitalWrite(Axis2_EN,AXIS2_DRIVER_ENABLE); } else { if (AXIS2_DRIVER_MODEL == TMC_SPI) tmcAxis2.setup(AXIS2_DRIVER_INTPOL,AXIS2_DRIVER_DECAY_MODE,AXIS2_DRIVER_CODE,axis2Settings.IRUN,axis2SettingsEx.IHOLD); }
      |                                                                                                                   ^~~~~~~~
../OnStep/StepMode.ino: In function 'void disableStepperDrivers()':
StepMode:358:116: error: 'tmcAxis1' was not declared in this scope
  358 |     if (Axis1_EN != -1) { digitalWrite(Axis1_EN,AXIS1_DRIVER_DISABLE); } else { if (AXIS1_DRIVER_MODEL == TMC_SPI) tmcAxis1.setup(AXIS1_DRIVER_INTPOL,AXIS1_DRIVER_DECAY_MODE,AXIS1_DRIVER_CODE,0,0); }
      |                                                                                                                    ^~~~~~~~
StepMode:360:116: error: 'tmcAxis2' was not declared in this scope
  360 |     if (Axis2_EN != -1) { digitalWrite(Axis2_EN,AXIS2_DRIVER_DISABLE); } else { if (AXIS2_DRIVER_MODEL == TMC_SPI) tmcAxis2.setup(AXIS2_DRIVER_INTPOL,AXIS2_DRIVER_DECAY_MODE,AXIS2_DRIVER_CODE,0,0); }
      |                                                                                                                    ^~~~~~~~
exit status 1
No binary file. Check above output for errors

Align:414: warning: variable 'IH2' set but not used
double IH2=indexAxis1;

I know its just a warning, but it should be an easy fix : )

I have few ideas of what could be improved in SHC:

1. Show active guide rate - perhaps top line at the left
2. Change "Value set" messages to meaningful messages like "Unparked" e.t.c.
3. Add option to Slew/Store Current position/Delete for custom catalogue items (stored in OnStep).
4. Set Park, Return/Reset Home - ask for confirmation (to prevent accidental triggering of model clear)
5. Add symbols for Sidereal/Lunar/Solar tracking
6. Add last error clear - this will require more than SHC code change I believe
7. Goto when tracking disabled - Unknown error message - change to more meaningful message
8. Change Align page number to something like 10 - to allow for easier addition of custom screens (battery voltage in my case) - this is a very minor thing

Edit 1:
9. Display OnStep & SHC firmware version

There is a bug in the new code where the object type (as text) does not show for Herschel objects (but does show for Messier).

This needs to be fixed.

Hi,
I have upload the firmware OnStep on Arduino 2560 with Ramps 1.5. I have tried use within Stellarium, the log file show RA and DEC valid but :MS# returned 3. How can I fixe it.

Best Regards.

I'm experiencing a weird issue related to parking, which causes OnStep to become unresponsive. Here's what happens:

1. I start my brand new OnStep STM32 BluePill board with the mount pointing towards the celestial pole, counterweights down (home position)
2. I play around with the mount using Sequence Generator Pro (SGP) and Cartes du Ciel. Slews and tracking work perfectly
3. To test the parking feature, I set a parking position in a random point of the sky, then park the mount
4. The motors turn off correctly. I unpark and play around some more. Everything OK.
5. I move the mount from the computer until both the OTA and the counterweight bar are parallel to the ground. In this position, the telescope points slightly above the horizon, and the position is correctly shown on Cartes du Ciel. This ensures that my observatory roll-off roof won't hit the telescope when I close it.
6. From SGP, I set that as the parking position
7. I wait some time, then try to unpark from SGP. Unfortunately, at this point things start to get funky. The motors don't turn back on, and after a few seconds, SGP says again that the mount is parked. No matter what I try, my OnStep board is now kinda bricked:
   • I try to unpark several times, from other software too (e.g. Cartes du Ciel). The mount either goes back to parked or doesn't respond to slews, tracking and move commands
   • I power-cycle OnStep, restart SGP, no luck
   • I check the OnStep ASCOM driver, but it says it's connected, and I can apply settings, set time, coordinates, etc

What I need to do to get OnStep back running:

1. Put the BOOT0 jumper to 1 and restart OnStep
2. Set NV_FACTORY_RESET to true in OnStep.ino, upload, wait, set to false, re-upload
3. Restore the jumper and restart OnStep with the mount in the home position
4. Repeat the all tests above. OnStep bricks itself as soon as I set the definitive parking position.

What I tried to fix the issue:

• Re-upload the sketch
• Thinker with Config.h
• Install an OnStep 4.23 release from a few months ago. Exact same issue

Description of my OnStep setup:

• BluePill STM32 PCB
• Genuine STM32F103C8T6 BluePill
• No ESP8266, no hand-controller
• 2x TMC2130
• 12V 3A power supply
• Config.h available here
• Gemini G53F mount
• Built with STM32duino 1.9.0

Other notes:

• The TMC2130 drivers are definitely not the issue. I've tested them thoroughly with an Arduino on a breadboard
• The RTC module and its EEPROM work. Time, date, GPS coordinates and UTC offset are preserved between power cycles
• The OnStep ASCOM driver has all the correct settings for my location and astro-setup.
• I'm an electrical engineering student, and I've also built two other identical OnStep boards for my friends (so I have some experience with OnStep, it's not my first board). They haven't experienced this issue so far, but I can't ask them to make this specific tests. They lack the knowledge and I don't want to brick their boards, too.

I have absolutely no idea of where the problem could be. I've spent the afternoon repeating this tests. I absolutely need to set the correct parking position to close the observatory. Sorry for the long message - hopefully it helps to solve the issue. I'm available for debugging and testing.

Marco

My first report is here: https://groups.io/g/onstep/message/9343

The sequence is : power on (unparked), enable tracking in the website, enable full comp dual axis (without this the issue was not observed), select Vfast (probably not needed), guide N and S few times, then guide N and S via SHC -> the dec stepper does not move immediately after pressing N or S but it takes about 3 sec to start moving, sometimes it stalls like no acceleration ramp is there. RA axis behaves normally.

This issue is likely not related to SHC. Also, it is not related to Website (when Full Comp Dual axis is enabled from SHC the issue is still there). However, it's not 100% repeatable - it may depend on time of the day I think. Sometimes it shows up after few seconds after enabling Full comp Dual Axis, sometimes it takes few minutes, sometimes it starts after first few slews. However no matter what it is there after less than half an hour. As a consequence Full comp Dual axis is not usable for me. Can you please test if you can also see this issue?

It would be great if yesterday's change to the STM32 HAL file got the following comment. It will remind me of what we did, in case we need to change that in the future.

Needs to go to master and 2.22.

Thanks

//   The hardware USART serial ports and pins for STM32F103 are:
//     USART1: TX PA9,  RX PA10 (connected to the CP2102)
//     USART2: TX PA2,  RX PA3 (unused, the pins are used for Axis 2)
//     USART3: TX PB10, RX PB11 (connected to the WeMOS D1 Mini WiFi)
//
// The only supported upload method for flashing OnStep to the Blue Pill is the Serial method, via the CP2102.
// No other upload method is supported!
// Verified to work with Arduino_STM32 repository snapshot as of Dec 26, 2019 or later.
// Should work with earlier versions too.

Right now, the output does not say what either the MCU architecture or the pinmap is.

It would be informative if they did.

To do so, we need to add something like this to each HAL file:

#define MCU "STM32F1"
#define MCU "Teensy 3.5"
#define MCU "ESP32"

And in each pinmap file, there would be:

#define PINMAP_DESC "Blue Pill PCB"
#define PINMAP_DESC "MaxPCB v2"
#define PINMAP_DESC "W32+CNCv3"

Then it is a matter of printing the above strings ...

As I dive more into the code for OnStep, I come across areas that I have questions on ...

Including:

• What is T4C for? This is the Texas Instruments Tiva C board, but we don't have a build for it, unless these defines are used for something else.

• What is Energia for?

If the above is obsolete code, then it would be best to remove it from Alpha and future versions to make the code more readable and more maintainable.

• There are two distinct EEPROM function sets, using two call formats, one Object Oriented in style (EEPROM_LP.ino), and the other is regular procedural calls (EEPROM.ino). It would be best if these are unified in one style, and one .ino file, again for clarity and easier maintenance.

More to come ...

I am willing to work on the above, if you would accept pull requests for them.

I just downloaded the last version of the OnStep and my windows Defender blocked a trojan in OnStep files:
*OnStep-release-4.24 (2).zip->OnStep-release-4.24/addons/WiFi/Globals.h
*OnStep-release-4.24 (2).zip->OnStep-release-4.24/addons/Ethernet/Globals.h
*webfile:OnStep-release-4.24 (2).zip|https://codeload.github.com/hjd1964/OnStep/zip/refs/heads/release-4.24|pid:496,ProcessStart:133151572927477066
Please take action on this!

Would be nice to have the object name for Messier and Caldwell. Storage on the Teensy 3.2 should be able to accomodate 109 x 2 x 12 bytes of extra storage.

Hi ,

I get this too :

fatal error: Validate.MaxESP.h: No such file or directory
#include "Validate.MaxESP.h"

Progress on extracting star and DSO data.

First the data structure to store this in (goes into Catalog.cpp).

typedef star {
  const char Constellation; // Constellation code
  const char Bayer; // The Greek letter for the star)
  const short Magnitude;
  const short RA;
  const short DE;
} star;

star cat_star[211]  = {
// Stuff generated from script below go here
};

A similar structure for DSOs would replace the Bayer designation by Object_Type (Galaxy, Nebula, ...etc.).

Now, extracted data from the HYG Database.

For stars, the extract/transform program requires the magnitude as a command line argument (star fainter than this will not be extracted):

The fields are:

• Constellation (need to be converted to a char)
• Bayer Designation (need to be converted to a char, maps to the Greek letter)
• Magnitude (multiplied by 1,000)
• RA (multiplied by 10000)
• Declination (multiplied by 10,000)

The comments on the same line preserve the original values so as to make debugging easier, as well include the proper name

Here is an example run, which returns 211 stars

./extract-stars.py 3.2 | sort | less
{And, Alp, 2070, 1398, 290904}, // And Alp Alpheratz 2.070 0.139791 29.090432
{And, Bet, 2070, 11622, 356206}, // And Bet Mirach 2.070 1.162194 35.620558
{And, Gam-1, 2100, 20650, 423297}, // And Gam-1 Almaak 2.100 2.064984 42.329725
{Aql, Alp, 760, 198464, 88683}, // Aql Alp Altair 0.760 19.846388 8.868322
{Aql, Gam, 2720, 197710, 106133}, // Aql Gam Tarazed 2.720 19.770994 10.613261
{Aql, Zet, 2990, 190902, 138635}, // Aql Zet  2.990 19.090169 13.863478
...
{UMi, Alp, 1970, 25298, 892641}, // UMi Alp Polaris 1.970 2.529750 89.264109
{UMi, Bet, 2070, 148451, 741555}, // UMi Bet Kochab 2.070 14.845105 74.155505
{UMi, Gam, 3000, 153455, 718340}, // UMi Gam  3.000 15.345483 71.834016
{Vel, Del, 1930, 87451, -547088}, // Vel Del  1.930 8.745059 -54.708821
{Vel, Gam-2, 1750, 81589, -473366}, // Vel Gam-2  1.750 8.158876 -47.336588
{Vel, Kap, 2470, 93686, -550107}, // Vel Kap  2.470 9.368562 -55.010668
{Vel, Lam, 2230, 91333, -434326}, // Vel Lam  2.230 9.133268 -43.432589
{Vel, Mu, 2690, 107795, -494203}, // Vel Mu  2.690 10.779488 -49.420255
{Vir, Alp, 980, 134199, -111613}, // Vir Alp Spica 0.980 13.419883 -11.161322
{Vir, Eps, 2850, 130363, 109592}, // Vir Eps Vindemiatrix 2.850 13.036278 10.959150
{Vir, Gam, 2740, 126943, -14494}, // Vir Gam Porrima 2.740 12.694345 -1.449375

For DSOs, I have another script that works and extracts Messier and Caldwell. The first argument is the catalog (M = Messier, C = Caldwell)

The fields are:

• Messier number
• Constellation (see above)
• Object Type (also needs to be converted to a char)
• Magnitude (see above)
• RA (see above)
• Declination (see above)

./extract-dso.py M 20 

{001, Tau, Neb, 8400, 55755, 220144}, // M 1 Tau  Neb 8.4 5.57553 22.0144
{002, Aqr, GC, 6600, 215581, -8231}, // M 2 Aqr  GC 6.6 21.5581 -0.823056
{003, CVn, GC, 6300, 137031, 283756}, // M 3 CVn  GC 6.3 13.7031 28.3756
{004, Sco, GC, 5400, 163932, -265253}, // M 4 Sco  GC 5.4 16.3932 -26.5253
{005, Ser, GC, 5700, 153094, 20828}, // M 5 Ser  GC 5.7 15.3094 2.08278
{006, Sco, OC, 4200, 176724, -322542}, // M 6 Sco  OC 4.2 17.6724 -32.2542
{007, Sco, OC, 3300, 178975, -347928}, // M 7 Sco  OC 3.3 17.8975 -34.7928
{008, Sgr, Neb, 5800, 180614, -243803}, // M 8 Sgr  Neb 5.8 18.0614 -24.3803
...
{106, CVn, Gxy, 8700, 123160, 473042}, // M 106 CVn  Gxy 8.7 12.316 47.3042
{107, Oph, GC, 7800, 165422, -130528}, // M 107 Oph  GC 7.8 16.5422 -13.0528
{108, UMa, Gxy, 10200, 111920, 556733}, // M 108 UMa  Gxy 10.2 11.192 55.6733
{109, UMa, Gxy, 9900, 119600, 533744}, // M 109 UMa  Gxy 9.9 11.96 53.3744
{110, And, Gxy, 8200, 6728, 416906}, // M 110 And  Gxy 8.2 0.67275 41.6906

Works the same for Caldwell.

Howard, please check if the multipliers are adequate, and that using short integer can store these values with reasonable accuracy.

The rest is to work is:

• Mapping the above mentioned values that need to be mapped to char,
• Extract Herschel 400 objects
• Modify the code within SHC to use the catalog the same way they are used now
• Optionally add code for filtering, e.g. by magnitude

Hi

I've made a onStep mega based, and after testing, it's like the spreadsheet is giving a doubled value on
StepsPerDegree and StepsPerWormRotation. I've checked the m0,m1 and m2 voltages and it seems to be ok. Weird...

I have been doing more testing on the tracking precision. I thought that here we can have a developer discussion without confusing the end users.

I have 3 configurations:

• My GEM, 28,800 steps per degree
• Verloop's GEM, 1,777.777 steps per degree
• Zeppy's Alt-Az 12,214.793 steps per degree

First observation: increasing the seconds to average from 40 to 120 in Timer.ino:ClockSync() improves precision.

Second, increasing 2L to 4L seems to make the 3 mounts happy, as below:

My GEM, 120 seconds, 4L
2018-11-15 21:51:42 04:35:55#+1630:29# 68.980174,16.508056#
2018-11-15 21:53:42 04:35:55#+1630:29# 68.980243,16.508056#
2018-11-15 21:55:43 04:35:55#+1630:29# 68.980264,16.508056#
2018-11-15 21:57:43 04:35:55#+1630:29# 68.980354,16.508056#
2018-11-15 21:59:43 04:35:55#+1630:29# 68.980403,16.508056#
2018-11-15 22:01:43 04:35:55#+1630:29# 68.980465,16.508056#
2018-11-15 22:03:43 04:35:55#+1630:29# 68.980528,16.508056#
2018-11-15 22:05:43 04:35:55#+1630:29# 68.980590,16.508056#
((68.980174-68.980590)/(5+9))6060 = 0.106"/min

Verloop's GEM, 120 seconds, 4L
2018-11-15 22:11:15 04:36:53#+1633:30# 69.221271,16.558313#
2018-11-15 22:13:15 04:36:53#+1633:30# 69.220875,16.558313#
2018-11-15 22:15:15 04:36:53#+1633:30# 69.221000,16.558313#
2018-11-15 22:17:16 04:36:53#+1633:30# 69.220896,16.558313#
2018-11-15 22:19:16 04:36:53#+1633:30# 69.220834,16.558313#
2018-11-15 22:21:16 04:36:53#+1633:30# 69.220771,16.558313#
2018-11-15 22:23:16 04:36:53#+1633:30# 69.220709,16.558313#
2018-11-15 22:25:16 04:36:53#+1633:30# 69.220084,16.558313#
2018-11-15 22:27:17 04:36:53#+1633:30# 69.220334,16.558313#
2018-11-15 22:29:17 04:36:53#+1633:30# 69.220229,16.558313#
2018-11-15 22:31:17 04:36:53#+1633:30# 69.220084,16.558313#
2018-11-15 22:33:17 04:36:53#+1633:30# 69.220021,16.558313#
2018-11-15 22:35:17 04:36:53#+16*33:30# 69.219438,16.558313#
((69.221271-69.219438)/(35-11))6060 = 0.204" to 0.305"/min

Note that his goto pointing is a bit off.

Zeppy's Alt-Az, 120 seconds, 4L
2018-11-15 22:40:51 04:36:56#+1633:23# 69.233334,16.556401#
2018-11-15 22:42:51 04:36:56#+1633:23# 69.233299,16.556461#
2018-11-15 22:44:51 04:36:56#+1633:24# 69.233306,16.556552#
2018-11-15 22:46:51 04:36:56#+1633:24# 69.233357,16.556624#
2018-11-15 22:48:51 04:36:56#+1633:24# 69.233313,16.556761#
2018-11-15 22:50:52 04:36:56#+1633:24# 69.233272,16.556850#
((69.233334-69.233357)/(46-40))6060 = 0.022"/min in RA
There is something else going on in DEC precision. I am not sure why that is.
Also, Goto is a bit off.

First, I hope my calculations are correct.
The results are certainly better than 2L, and 40 seconds in ClockSync.

I played around with increasing the value of 4L more, and even adaptive code (e.g. if StepsPerDegree for axis >= 28000 use 32L or 1024L, if StepsPerDegree for axis > 12000 use 4L, ...etc.) but could not conclude something concrete that will work for all configurations.

I also thought that there may be a Config.STM32 parameter that could override the 4L
When you get a chance of building the STM32, the new :GXFE# command may come in handy, and you can validate the results above. I am sure you will also have more insight into the underlying reasons for all this, rather than my trial and error method so far.

In the meantime, it seems that 4L is a good compromise providing better tracking across the board.

It would be nice to support the cheap and dowerfull Re-ARM Platform, that is a mainly 5V tollerant 32Bit arduino replacement. Nice would be some hints how to design a HAL to successfully build on Arduino IDE or on PlatformIO IDE. My current tryes ends up in a sellection of the DUE by PlatformIO Ide and not as expected the LPC1768 what works fine on my Marlin FW fork. but the HAL from Marlin, i do thik,, will not work on onstep caused by different define expectations.

if there is a How To create a HAL for OneStep, then i'd spend the time to realize and test it.

• HAL_ReArmRAMPS
• Pins.ReArmRAMPS.h
• Config.ReArmRAMPS.h

Also i'd spend some basic config sets for EQ3, Exos-2 and EQ3 Thingiverse DIY Motor Set.
this may be a start for entry point OnStep installations for given mounts and motor Sets.

Hi,

Currently I add support of a custom board and I found this. I think it's a mistake :

In the file Constants.h :

#define AltMega2560                  3 // Obsolete

In the file src/pinmaps/Models.h :

#if PINMAP == Mega2560Alt
  #define PINMAP_STR "Alternate"
  #include "Pins.Mega2560Alt.h"
#endif

I can't find usage of AltMega2560 and I can't find definition of Mega2560Alt.
Names are not aligned, is it normal ?

I work on the release-4.24.

Note : I take the opportunity to thank you for this amazing job ! 🥇

Astro.ino:
double trueRefrac(double Alt, double Pressure=1010.0, double Temperature=10.0)
double apparentRefrac(double Alt, double Pressure=1010.0, double Temperature=10.0)

Alt = Alt+trueRefrac(Alt,)/60.0;
Alt = Alt-apparentRefrac(Alt)/60.0;
double Alt1_ = Alt1 - ( trueRefrac(Alt1) / 60.0 );
double Alt2_ = Alt2 - ( trueRefrac(Alt2) / 60.0 );

These two functions are built, but an error occurs and the compiler prompts for the wrong default and number of arguments, respectively:
373:78: error: default argument given for parameter 3 of 'double trueRefrac(double, double, double)' [-fpermissive]
413:27: error: too few arguments to function 'double trueRefrac(double, double, double)

If I change the code a little, it builds fine:
double trueRefrac(double Alt, double Pressure, double Temperature)
double apparentRefrac(double Alt, double Pressure, double Temperature)

Alt = Alt+trueRefrac(Alt, 1010.0, 10.0)/60.0;
Alt = Alt-apparentRefrac(Alt, 1010.0, 10.0)/60.0;
double Alt1_ = Alt1 - ( trueRefrac(Alt1, 1010.0, 10.0) / 60.0 );
double Alt2_ = Alt2 - ( trueRefrac(Alt2, 1010.0, 10.0) / 60.0 );

Can I do that?

This code segment in STM32F1's HAL file is wrong:

What is in git is:

//   The hardware USART serial ports and pins for STM32F103 are:
//     USART1: TX PA9,  RX PA10 (connected to the CP2102)
//     USART2: TX PA2,  RX PA3 (unused, the pins are used for Axis 2)
//     USART3: TX PB10, RX PB11 (connected to the WeMOS D1 Mini WiFi)
//
// The only supported upload method for flashing OnStep to the Blue Pill is the Serial method, via the CP2102.
// No other upload method is supported!
// Verified to work with Arduino_STM32 repository snapshot as of Dec 26, 2019 or later.
// Should work with earlier versions too.#define SerialA Serial1
#define SerialB Serial3

It should be:

//   The hardware USART serial ports and pins for STM32F103 are:
//     USART1: TX PA9,  RX PA10 (connected to the CP2102)
//     USART2: TX PA2,  RX PA3 (unused, the pins are used for Axis 2)
//     USART3: TX PB10, RX PB11 (connected to the WeMOS D1 Mini WiFi)
//
// The only supported upload method for flashing OnStep to the Blue Pill is the Serial method, via the CP2102.
// No other upload method is supported!
// Verified to work with Arduino_STM32 repository snapshot as of Dec 26, 2019 or later.
// Should work with earlier versions too.
#define SerialA Serial1
#define SerialB Serial3

As per the Marlin 2.0 pinmap for the S6, the following pin should be corrected:

diff --git a/src/pinmaps/Pins.FYSETC_S6.h b/src/pinmaps/Pins.FYSETC_S6.h
index 6d8ec10..78d81d7 100644
--- a/src/pinmaps/Pins.FYSETC_S6.h
+++ b/src/pinmaps/Pins.FYSETC_S6.h
@@ -73,7 +73,7 @@
 #define Axis1_HOME         PB10     // Sense home position Axis1
 
 // Axis2 Dec/Alt step/dir driver
-#define Axis2_EN           PD8     // Enable
+#define Axis2_EN           PD9     // Enable

Hi ,

while compiling I get this error:

Validate.h:380:4: error: #error "Configuration (Config.h): You must specify a PINMAP!"
#error "Configuration (Config.h): You must specify a PINMAP!

Any idea. Thanks

I spend 1 day on investigating why the focuser rate is so different between SHC and Android OnStep Application.
Finally I have found that when SHC sends :FS# command the OnStep sets 0.001mm/s rate. Android OnStep Application is using 0.01mm/s.

It seems it is a bug, because everywhere in doc and sources, :FS# command is described with rage 0.01mm/s.

Created pull request #176 to fix this bug. After fixing both SHC and Android application behaves the same.

I think there is an unintentional negative array index used in the Command.h:ready() function:

    bool ready() {
      if ((cb[cbp-1]=='#') && (cbp==1)) flush();
      return (cb[cbp-1]=='#');
    }

If cbp=0, which I think it would be on the receipt of the first character of a command then memory outside of the cb array would be accessed. I think the following should work around this (untested):

    bool ready() {
      if (!cbp) return false;
      if ((cb[cbp-1]=='#') && (cbp==1)) flush();
      return (cb[cbp-1]=='#');
    }

Target: Classic_ON (Mega2560)
MOUNT_TYPE_GEM
No RTC
Arduino Preferences: Compiler warnings: All

In the latest OnStep releases, with all compiler warnings enabled, a bunch of warnings are generated. These are all associated with unused parameters, but should be corrected to clean up the code base.

In file included from HAL/HAL_Mega2560/HAL_Mega2560.h:56:0,
                 from HAL/HAL.h:27,
                 from OnStep.ino:61:
HAL/HAL_Mega2560/../drivers/RTCw.h:134:10: warning: unused parameter 'JD' [-Wunused-parameter]
     void set(double JD, double LMT) {

HAL/HAL_Mega2560/../drivers/RTCw.h:134:10: warning: unused parameter 'LMT' [-Wunused-parameter]

HAL/HAL_Mega2560/../drivers/RTCw.h:139:10: warning: unused parameter 'JD' [-Wunused-parameter]
     void get(double &JD, double &LMT) {

HAL/HAL_Mega2560/../drivers/RTCw.h:139:10: warning: unused parameter 'LMT' [-Wunused-parameter]

In file included from OnStep.ino:64:0:
lib/St4SerialMaster.h:151:6: warning: unused parameter 'baud' [-Wunused-parameter]
 void Mst4::begin(long baud)

AlignEq.ino:341:6: warning: unused parameter 'Lat' [-Wunused-parameter]
 void TGeoAlign::equToInstr(double Lat, double HA, double Dec, double * HA1, double * Dec1, int PierSide)

AlignEq.ino:406:6: warning: unused parameter 'Lat' [-Wunused-parameter]
 void TGeoAlign::instrToEqu(double Lat, double HA, double Dec, double * HA1, double * Dec1, int PierSide)

Home.ino:49:12: warning: unused parameter 'fast' [-Wunused-parameter]
 GotoErrors goHome(boolean fast)

Hi, everyone Merry Christmas!
Please.....there is somebody able to save me from this Black hole!
Even if I verify in Arduino IDE the OnStep firmware without the boar or with board still showing this error.
I followed all the steps.
What I'm doing wrong?

OnStep- release 4.24
Arduino: 1.8.19 (Windows 10), Board: "DOIT ESP32 DEVKIT V1, 80MHz, 921600, None, Disabled"

In file included from C:\Users\Alexandre\Documents\Arduino\OnStep\src\HAL\ESP32\ESP32.h:71,

             from C:\Users\Alexandre\Documents\Arduino\OnStep\src\HAL\HAL.h:90,

             from C:\Users\Alexandre\Documents\Arduino\OnStep\OnStep.ino:68:

C:\Users\Alexandre\Documents\Arduino\OnStep\src\HAL\ESP32\Analog.h:54:97: error: default argument given for parameter 3 of 'void tone(uint8_t, unsigned int, long unsigned int)' [-fpermissive]

attribute ((weak)) void tone(uint8_t pin, unsigned int frequency, unsigned long duration = 0)

                                                                                             ^

In file included from sketch\OnStep.ino.cpp:1:

C:\Users\Alexandre\AppData\Local\Arduino15\packages\esp32\hardware\esp32\2.0.6\cores\esp32/Arduino.h:207:6: note: previous specification in 'void tone(uint8_t, unsigned int, long unsigned int)' here

void tone(uint8_t _pin, unsigned int frequency, unsigned long duration = 0);

  ^~~~

exit status 1

Error compiling for board DOIT ESP32 DEVKIT V1.

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

in the validate.h file may be a tipo

#ifndef AXIS4_STEP_RATE_MAX
#if AXIS5_DRIVER_DC_MODE == ON

should probably be
#ifndef AXIS4_STEP_RATE_MAX
#if AXIS4_DRIVER_DC_MODE == ON

Hello.

I bought a 2.3 "screen based on SSD1309 I would like to know if it is possible to add it to the list of supported screens?

https://www.diymore.cc/collections/led-display-module/products/2-42-inch-12864-oled-display-module-iic-i2c-spi-serial-for-arduino-c51-stm32-green-white-blue-yellow

I was reading through the formulas for creating the pointing model and all of them agree with Patrick Wallace's paper except:

AlignEq.ino line 155:
TFd =TF*(cosLat*cosHa-sinLat*cosDec);

https://sites.astro.caltech.edu/~srk/TP/Literature/Wallace_Telescope_Pointing.pdf page 6 defines TFd as:
TFd = TF*(cosLat*cosHa*sinDec-sinLat*cosDec);

is the omission of sinDec voluntary?

This is a small change to allow the user to override spiral search time limit in Config.h

diff --git a/Validate.h b/Validate.h
index 1d4cbee..ca4df9f 100644
--- a/Validate.h
+++ b/Validate.h
@@ -72,7 +72,9 @@
 #define SEPARATE_PULSE_GUIDE_RATE ON
 
 // default time for spiral guides is 103.4 seconds
-#define GUIDE_SPIRAL_TIME_LIMIT 103.4
+#ifndef GUIDE_SPIRAL_TIME_LIMIT
+  #define GUIDE_SPIRAL_TIME_LIMIT 103.4
+#endif
 
 // automatically set MaxRate from SLEW_RATE_BASE_DESIRED
 #define MaxRate ((1000000.0/SLEW_RATE_BASE_DESIRED)/AXIS1_STEPS_PER_DEGREE)

I've noticed a problem with the maxRate variable and NV.
It's quite possible I've introduced the problem myself while modifying OnStep (apologies if so), but it seems to me that the problem is also present in the original codebase...

The problem:

When initializing the NV in initWriteNvValues() we call maxRateLowerLimit().
However, in maxRateLowerLimit() function, we have:

r_us=(r_us_axis1+r_us_axis2/timerRateRatio)/2.0;

The problem is the variable timerRateRatio. This is defined in Global.h:

volatile double timerRateRatio;

but not initialised. We only initialise it once we read the NV memory in initReadNvValues:

timerRateRatio    = axis1Settings.stepsPerMeasure/axis2Settings.stepsPerMeasure;

So when setting maxRate, we call maxRateLowerLimit, which is a problem because the non initialized variable initReadNvValues causes a division by zero.

I've fixed this in my version by simply moving the variable initialization to the definition:

volatile double timerRateRatio = axis1Settings.stepsPerMeasure/axis2Settings.stepsPerMeasure;

Am I missing something, or does the above make sense?

mega2560 boards configured to use timer4 as CTC (which is used for axis2)
meantime the timer4 handles the pwm functionality for the D6, D7 and D8.
D7/D8 are connected to mosfets on mks gen-l boards, which means, we cannot use 2 of the ports as pwm output

is it possible to change the timer4 for axis2? (maybe timer5? it isnt used at the moment)

The current WiFi web page reads:

"Enable either station OR AP mode, both enabled can cause performance issues
However, if just setting up or testing it can be desirable to enable both modes temporarily to guard against being locked out.
If locked out of the ESP8266, a Sketch uploaded to the MCU (Teensy3.x, STM32, Mega2560, etc.) which sends an 'R' at 9600 baud on the serial interface in reply to any '#' received will cause a reset to AP only enabled and the default SSID/Password."

A better copy would be:

"Enable either station OR AP mode, both enabled can cause performance issues."
"However, if just setting up or testing it can be desirable to enable both modes temporarily to guard against being locked out.
"
"If locked out of the ESP8266, you can use the Arduino IDE to reset the flash memory (and hence go back to defaults.) From the Tools menu, change Erase Flash "Only Sketch" to Erase Flash "All Flash Contents" and upload this WiFi-Bluetooth sketch again."

Also, the first two sentences can be improved to recommend enabling Station Mode and OnStep will fallback to its own AP mode.

Now that Dave Schwartz and myself have working SHC (based on ESP32), it is time to discuss new features and changes, to get consensus before submitting pull requests for them.

- I like to move the Tracking menu from Settings to be under the main menu. This is because sometimes you need to start tracking to do certain tasks (e.g. polar alignment in KStars). It would be below Parking and above PEC.

- Related: I like to add the King Tracking rate, which is missing from the Android App (and KStars too).

• Related: is there a way to display the current tracking rate?

• Local time display is odd. Right now it is 16:12 EST, but the SHC displays 04:12. The UTC offset is 05 hrs. All this does not seem to affect how OnStep is running, since the STM32 has an RTC that stores the date/time/..etc.

- There is a discrepancy between the target RA/Dec, and what is slewed to. For example, I align on Alpha Andromeda and the SHC says are RA 00:08:12 and Dec +29:04:00. After the slew is complete, the display shows 00:09:03 and +29:00:00. This is verified by CdC over USB showing that it is off target. It seems that the calculation of the coordinates in CatMgr::ra() and CatMgr::dec() is not right. But before I tackle this, I am wondering if this is issue shows only on ESP32 SHC, or you are seeing the same on a Teensy SHC (which neither one of us has)

Jamie on the mail list was confused by this part, with a Gen-L and WeMos:

#define SERIAL_C_BAUD_DEFAULT         OFF //    OFF, n, ON for ESP32 Bluetooth.
#define SERIAL_C_BLUETOOTH_NAME  "OnStep" // "On..", Bluetooth device name for ESP32.

So better comments can help avoid this confusion:

#define SERIAL_C_BAUD_DEFAULT         OFF //    OFF, n, ON ESP32 internal Bluetooth. Only applies for the MaxESP PCB
#define SERIAL_C_BLUETOOTH_NAME  "OnStep" // "On..", Bluetooth device name for ESP32 MaxESP PCB.

Sorry to be pickey. Some lines appear to be out of order
#define FEATURE4_PURPOSE OFF // OFF, SWITCH, ANALOG_OUT, DEW_HEATER, INTERVALOMETER. Option
#define FEATURE4_TEMP OFF // OFF, DS1820, n. Where n is the ds18b20 s/n for DEW_HEATER temperature. Adjust
#define FEATURE4_PIN OFF // OFF, AUX, CHAIN (ds2413 gpio1,) n. Where n=0 to 255 (pin#.) Adjust
#define FEATURE5_NAME "FEATURE5" // "FE..", Name of feature being controlled. Adjust
#define FEATURE4_DEFAULT_VALUE OFF // OFF, ON, n. Where n=0..255 for ANALOG_OUT purpose. Adjust
#define FEATURE5_PURPOSE OFF // OFF, SWITCH, ANALOG_OUT, DEW_HEATER, INTERVALOMETER. Option
#define FEATURE5_TEMP OFF // OFF, DS1820, n. Where n is the ds18b20 s/n for DEW_HEATER temperature. Adjust
#define FEATURE5_PIN OFF // OFF, AUX, DS2413, n. Where n is ds2413 s/n (gpio0) or n=0 to 255 (pin#.) Adjust
#define FEATURE6_NAME "FEATURE6" // "FE..", Name of feature being controlled. Adjust
#define FEATURE5_DEFAULT_VALUE OFF // OFF, ON, n. Where n=0..255 for ANALOG_OUT purpose. Adjust
#define FEATURE6_PURPOSE OFF // OFF, SWITCH, ANALOG_OUT, DEW_HEATER, INTERVALOMETER. Option
#define FEATURE6_TEMP OFF // OFF, DS1820, n. Where n is the ds18b20 s/n for DEW_HEATER temperature. Adjust
#define FEATURE6_PIN OFF // OFF, AUX, CHAIN (ds2413 gpio1,) n. Where n=0 to 255 (pin#.) Adjust
#define FEATURE7_NAME "FEATURE7" // "FE..", Name of feature being controlled. Adjust
#define FEATURE6_DEFAULT_VALUE OFF // OFF, ON, n. Where n=0..255 for ANALOG_OUT purpose. Adjust
#define FEATURE7_PURPOSE OFF // OFF, SWITCH, ANALOG_OUT, DEW_HEATER, INTERVALOMETER. Option
#define FEATURE7_TEMP OFF // OFF, DS1820, n. Where n is the ds18b20 s/n for DEW_HEATER temperature. Adjust
#define FEATURE7_PIN OFF // OFF, AUX, DS2413, n. Where n is ds2413 s/n (gpio0) or n=0 to 255 (pin#.) Adjust
#define FEATURE8_NAME "FEATURE8" // "FE..", Name of feature being controlled. Adjust
#define FEATURE8_TEMP OFF // OFF, DS1820, n. Where n is the ds18b20 s/n for DEW_HEATER temperature. Adjust
#define FEATURE8_PIN OFF // OFF, AUX, CHAIN (ds2413 gpio1,) n. Where n=0 to 255 (pin#.) Adjust
#define FEATURE7_DEFAULT_VALUE OFF // OFF, ON, n. Where n=0..255 for ANALOG_OUT purpose. Adjust
#define FEATURE8_PURPOSE OFF // OFF, SWITCH, ANALOG_OUT, DEW_HEATER, INTERVALOMETER. Option
#define FEATURE8_DEFAULT_VALUE OFF // OFF, ON, n. Where n=0..255 for ANALOG_OUT purpose. Adjust

MaxPCBv3
Compiling the software generates this error
Arduino:1.8.13 (Mac OS X), TD: 1.53, Scheda:"Teensy 3.6, Serial, 180 MHz, Faster, US English"

Features: In function 'void featuresPoll()':
Features:38: error: expected '}' before 'else'
if (feature[i].pin >= 0 && feature[i].pin <= 255) digitalWrite(feature[i].pin,feature[i].value==feature[i].active_state); else {
^
Features:43: error: 'else' without a previous 'if'
} else
^
Features:44: error: 'i' was not declared in this scope
if (feature[i].purpose == ANALOG_OUT) {
^
Features:45: error: 'v' was not declared in this scope
if (feature[i].value != v) {
^
Features:51: error: 'v' was not declared in this scope
if (feature[i].value != v) feature[i].dewHeater->enable(feature[i].value);
^
Features:61: error: 'v' was not declared in this scope
feature[i].value=v;
^
/Users/corradogamberoni/Documents/OnStep/Features.ino: At global scope:
Features:72: error: expected declaration before '}' token
}
^
expected '}' before 'else'

Hello,

I was just compiling the latest beta release of OnStep and I ran into an issue about a typo related to AXISn_FAULT.

While it is defined in Config.Ramps14.h in capital case, in OnStep there are mentions for it in first letter as capital only (Axisn_FAULT), which resulted in failure to compile.

I was manually able to fix it by correcting the case of the letters however I am not sure if this is the case for the other config files or this is a specific for Config.Ramps14.h only.

The definition in Config.Ramps14.h is at line 183 and 184
The wrong instances in OnStep.ino are in lines:
361
364
372
375

Just thought I leave this for your kind information and check!
Regards

In order to reduce confusion, we should let the machine derive the values rather than calculate them externally.

The worksheet will still be used for planning, and doing 'what if' scenarios on various gear ratios, microsteps, ...etc. and to ensure that the values chosen are sane, and not exceed the hard limits.

So, the configuration Config.xxx.h can start with something like this:

// Number of steps per full rotation for your specific stepper motor.
// This should be 200 for 1.8 degree motors, or 400 for 0.9 degree motors
Axis1MotorStepsPerFullRotation     200

// Microsteps used for sidereal tracking. You can't use a lower fraction
// (i.e. higher number), unless your stepper driver supports it. For example,
// A4988 has a minimum of 1/16, DRV8825 has 1/32, LV8729 has 1/128.
// The Trinamic TMC2100, TMC2130, TMC2208 does interpolation of 1/256 internally
Axis1MicroStepsForSidereal         64

// This is any transfer gears or pulleys that are in between the worm wheel
// and the motor. Use 1 if you directly coupled the motor to the worm gear.
// Don't forget to account for the gears inside the motor if yours have them
Axis1TransferGearRatio             3

// This is your main worm wheel number of teeth. For CG5 and other Vixen Super
// Polaris clones, this is usually 144
Axis1WormWheelStepsPerFullRotation 144

// Same as above for your other axis
Axis2MotorStepsPerFullRotation     200
Axis2MicroStepsForSidereal         64
Axis2TransferGearRatio             3
Axis2WormWheelStepsPerFullRotation 144

Then in Globals.h, we can add the following snippet:

#define Axis1StepsPerWormRotation (Axis1MotorStepsPerFullRotation * Axis1MicroStepsForSidereal * Axis1TransferGearRatio)
#define Axis2StepsPerWormRotation (Axis1MotorStepsPerFullRotation * Axis2MicroStepsForSidereal * Axis2TransferGearRatio)

#define Axis1StepsPerDegree  ((Axis1StepsPerWormRotation * Axis1WormWheelStepsPerFullRotation) / 360)
#define Axis2StepsPerDegree  ((Axis2StepsPerWormRotation * Axis2WormWheelStepsPerFullRotation) / 360)

If you like this idea, I can create pull requests for Global.h and all the configs.

OnStep/Guide.ino: In function 'void ST4()':
Guide:568:41: error: 'GR_PLUSEGUIDE' was not declared in this scope; did you mean 'GR_PULSEGUIDE'?
568 | startGuideAxis1(newDirAxis1,GR_PLUSEGUIDE,GUIDE_TIME_LIMIT*1000,false);
| ^~~~~~~~~~~~~
| GR_PULSEGUIDE

In Config.h, this

// Stepper driver models (also see ~/OnStep/sd_drivers/Models.h

Should say:

// Stepper driver models (also see ~/OnStep/src/sd_drivers/Models.h

In Initialize.ino, line 342, there is this:

#if !defined(RememberMaxRate_ON) && !defined(REMEMBER_MAX_RATE_ON)
The RememberMaxRate_ON seems to be an error, since it is not defined anywhere.

Also, isn't this code reversed? Shouldn't it be without the '!', like so:

#if defined(defined(REMEMBER_MAX_RATE_ON)
//... EEPROM write
#endif 

Hi,

I have a Arduino Nano Atmega328p and driver A4988 already configured for 1/16 resolution. Is possible create the configuration file to use them?

Best regards.

Howard,

may be I found a typo within OnStep.ino (a minus sign before degreesPastMeridianE)
Removing it Meridian Flip works again.

@@ -675,7 +675,7 @@ void loop2() {
if (getInstrPierSide() == PierSideWest) {
if (getInstrAxis1() > degreesPastMeridianW && (!(autoMeridianFlip && goToHere(true) == CE_NONE))) { generalError=ERR_MERIDIAN; stopSlewingAndTracking(SS_LIMIT_AXIS1_MAX); }
} else

•    if (getInstrAxis1() < -degreesPastMeridianE) { generalError=ERR_MERIDIAN; stopSlewingAndTracking(SS_LIMIT_AXIS1_MIN); }
  

•    if (getInstrAxis1() < degreesPastMeridianE) { generalError=ERR_MERIDIAN; stopSlewingAndTracking(SS_LIMIT_AXIS1_MIN); }
   }
  

  }
  double a2; if (AXIS2_TANGENT_ARM == ON) { cli(); a2=posAxis2/axis2Settings.stepsPerMeasure; sei(); } else a2=getInstrAxis2();

When you do align, select the star, goto it, and then you realize it is behind an obstacle (roof or tree in my case) there is no way how to select another star or cancel alignment. You can cancel alignment when the scope is still slewing but not when the goto has finished. Can this be modified? Perhaps, long press of Shift button to re-enter star selection dialogue?

This change is needed to prevent OnStep from polling Serial3 on the EXP headers. That way, Serial3 can be used when TIME_LOCATION_SOURCE is set to GPS.

It was tested by Dave and verified to work.

diff --git a/src/HAL/HAL_STM32F4/HAL_STM32F4.h b/src/HAL/HAL_STM32F4/HAL_STM32F4.h
index 3573e7f..5a82b71 100644
--- a/src/HAL/HAL_STM32F4/HAL_STM32F4.h
+++ b/src/HAL/HAL_STM32F4/HAL_STM32F4.h
@@ -25,11 +25,9 @@
 
 #define SerialA Serial
 #define SerialB Serial1
-#define SerialC Serial3
 
 // SerialA is always enabled, SerialB and SerialC are optional
 #define HAL_SERIAL_B_ENABLED
-#define HAL_SERIAL_C_ENABLED
 
 // New symbol for the default I2C port -------------------------------------------------------------
 #define HAL_Wire Wire