SHC


Robert Benward
 

I finally got the SHC loaded.  Here are a few of the things I found.  If the WEMOS wifi is not connecting, it inhibits the SHC to controller communications.  I would plug in the WEMOS (before I got this to connect), and the SHC would fail the comm link.  When I pulled the WEMOS out, it worked fine.  When I finally got the WEMOS working (the new SWS code & baud rate change), the SHC connected fine.

Working the SHC:
  • The scroll rates when entering numbers are pretty fast.  The rates also change rather quickly.  It's easy to overshoot your mark and difficult to get within a minute of desired time.  Setting of coordinates (in goto) has the same issue.
  • When entering local time, what ever number you put in, is modified when you say "yes" to the DST.  If you put in 1400hrs, and then say "yes" to DST, the number recorded would be 1300hrs.  So you need to add 1hr to local, then say yes to DST and the time will be correct. But don't do it twice (see below)!  A little confusing if you don't know what is going on.
  • When repeating the process, the previous time entry is correct (that is after the DST modifies it, e.g. enter 9hrs, hit DST, 8hrs is recorded), but DST returns to the default value of "no". Change it to "yes", and now your recorded time goes to 7hrs. You think you are correcting the DST setting, but it actually subtracts 1hr each pass through.
  • When trying to slew below the horizon, it just stops and no warning is given.  When looking at RA & DEC, you end up scratching your head.
  • When I power off and back on, the SHC does not remember the time.
  • Selecting sites.  I can pick a site, but not clear how to program it or change the name

Note that I have hard coded the WEMOS and the controller to 57600 baud (per a comment in the wiki).  It did not seem to be able get beyond the handshaking mode.  I will cover this in another topic on my WEMOS issues, but I note it here in case there is an interaction.

Bob


Robert Benward
 

P.S., I am using the MaxESP with the RTC.  I assume the RTC has something to do with the SHC or Onstep controller remembering the time.
Bob


Dave Schwartz
 

The SHC has no clock. The only date and time it can show to you is what it retrieves from the controller. If there is an RTC in the controller it should be pretty accurate from the start but if it comes from a GPS fix I really don't know what its relationship to the real time would be if you get the SHC to access it before the fix occurs.


On May 25, 2021 4:57:44 p.m. EDT, "Robert Benward via groups.io" <rbenward@...> wrote:
P.S., I am using the MaxESP with the RTC.  I assume the RTC has something to do with the SHC or Onstep controller remembering the time.
Bob

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Robert Benward
 

Dave,
I figured the SHC doesn't have a clock, but when I enter the time into the SHC, doesn't that pass it on to the RTC to update it?  What's the battery for then? The RTC doesn't come ready to go out of the box does it?

Bob


Dave Schwartz
 

By saying 'no issues' I meant that there were no discernable differences between the way the new and old code performed, not that there might not be room for improvement in the way they did things in common.

For example, the difficulty of entering large numbers such as hours:minutes:seconds as one number by scrolling up and down could eventually be addressed by doing each element separately... entering the triple starts by scrolling just the hours portion, accepting that goes to scrolling the minutes then accepting that goes to scrolling the seconds. With this, the scroll rate while in the individual elements could be much lower and therefore have less problem with overshooting.


On May 25, 2021 4:55:22 p.m. EDT, "Robert Benward via groups.io" <rbenward@...> wrote:
I finally got the SHC loaded.  Here are a few of the things I found.  If the WEMOS wifi is not connecting, it inhibits the SHC to controller communications.  I would plug in the WEMOS (before I got this to connect), and the SHC would fail the comm link.  When I pulled the WEMOS out, it worked fine.  When I finally got the WEMOS working (the new SWS code & baud rate change), the SHC connected fine.

Working the SHC:
  • The scroll rates when entering numbers are pretty fast.  The rates also change rather quickly.  It's easy to overshoot your mark and difficult to get within a minute of desired time.  Setting of coordinates (in goto) has the same issue.
  • When entering local time, what ever number you put in, is modified when you say "yes" to the DST.  If you put in 1400hrs, and then say "yes" to DST, the number recorded would be 1300hrs.  So you need to add 1hr to local, then say yes to DST and the time will be correct. But don't do it twice (see below)!  A little confusing if you don't know what is going on.
  • When repeating the process, the previous time entry is correct (that is after the DST modifies it, e.g. enter 9hrs, hit DST, 8hrs is recorded), but DST returns to the default value of "no". Change it to "yes", and now your recorded time goes to 7hrs. You think you are correcting the DST setting, but it actually subtracts 1hr each pass through.
  • When trying to slew below the horizon, it just stops and no warning is given.  When looking at RA & DEC, you end up scratching your head.
  • When I power off and back on, the SHC does not remember the time.
  • Selecting sites.  I can pick a site, but not clear how to program it or change the name

Note that I have hard coded the WEMOS and the controller to 57600 baud (per a comment in the wiki).  It did not seem to be able get beyond the handshaking mode.  I will cover this in another topic on my WEMOS issues, but I note it here in case there is an interaction.

Bob

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Dave Schwartz
 

The thing about the SHC not connecting if the WiFi module was in but not connecting is certainly strange but not likely to be the fault of the SHC as the SHC and Wifi are supposed to be two independent devices on two separate ports so the interaction can only be at the controller level. I've never heard of this before but don't deny it could be some sort of bug that's been there for a long time. However, since it goes away once you get the WiFi connection working (and it works forevermore) it seems like it would be a low priority to fix and probably wouldn't ever need to be addressed except in OnStepX.


On May 25, 2021 4:55:22 p.m. EDT, "Robert Benward via groups.io" <rbenward@...> wrote:
I finally got the SHC loaded.  Here are a few of the things I found.  If the WEMOS wifi is not connecting, it inhibits the SHC to controller communications.  I would plug in the WEMOS (before I got this to connect), and the SHC would fail the comm link.  When I pulled the WEMOS out, it worked fine.  When I finally got the WEMOS working (the new SWS code & baud rate change), the SHC connected fine.

Working the SHC:
  • The scroll rates when entering numbers are pretty fast.  The rates also change rather quickly.  It's easy to overshoot your mark and difficult to get within a minute of desired time.  Setting of coordinates (in goto) has the same issue.
  • When entering local time, what ever number you put in, is modified when you say "yes" to the DST.  If you put in 1400hrs, and then say "yes" to DST, the number recorded would be 1300hrs.  So you need to add 1hr to local, then say yes to DST and the time will be correct. But don't do it twice (see below)!  A little confusing if you don't know what is going on.
  • When repeating the process, the previous time entry is correct (that is after the DST modifies it, e.g. enter 9hrs, hit DST, 8hrs is recorded), but DST returns to the default value of "no". Change it to "yes", and now your recorded time goes to 7hrs. You think you are correcting the DST setting, but it actually subtracts 1hr each pass through.
  • When trying to slew below the horizon, it just stops and no warning is given.  When looking at RA & DEC, you end up scratching your head.
  • When I power off and back on, the SHC does not remember the time.
  • Selecting sites.  I can pick a site, but not clear how to program it or change the name

Note that I have hard coded the WEMOS and the controller to 57600 baud (per a comment in the wiki).  It did not seem to be able get beyond the handshaking mode.  I will cover this in another topic on my WEMOS issues, but I note it here in case there is an interaction.

Bob

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Robert Benward
 

I am sorry, I misunderstood you.  Please add my comments to the issues pile.

Any insight on the clock issue?

Bob


Dave Schwartz
 

The RTC doesn't have a battery out of the box... did you install a good one (+ side up)?


On May 25, 2021 5:32:22 p.m. EDT, "Robert Benward via groups.io" <rbenward@...> wrote:
Dave,
I figured the SHC doesn't have a clock, but when I enter the time into the SHC, doesn't that pass it on to the RTC to update it?  What's the battery for then? The RTC doesn't come ready to go out of the box does it?

Bob

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Robert Benward
 

Yes, 3.2V in circuit.  "+" side up.

Bob


Dave Schwartz
 

The date/time set through the SHC is definitely set in the RTC. I just tested it using my STM32 BP controller which has an RTC. I set the date/time using the new SHC to a few days in the future and many hours different and as I entered each, those values showed up on a web server status page being shown on a tablet connected through the WiFi. I then turned off the power and restarted and the values were retained after having been powered off for about 10 minutes.


On May 25, 2021 6:11:20 p.m. EDT, "Robert Benward via groups.io" <rbenward@...> wrote:
Yes, 3.2V in circuit.  "+" side up.

Bob

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Robert Benward
 

That is my other problem I'll be talking about in another topic, getting my WEMOS to work.  I get the wifi signal but cannot retrieve a web page at either 192.168.0.1 or 192.168.0.1:9999.  So right now I can't confirm the time that way.  Funny, I removed the WEMOS to program it, but powered up Onstep anyway.  The time was remembered...I put the WEMOS back in, and time was lost at first, but after hitting "set date/time" on my phone via app and bluetooth, the time came back.  maybe I am not waiting long enough?

I am now seeing your comment about the com ports.  Yes, it was strange, but with it working now, I will leave sleeping dogs lie.


John Petterson
 

On Tue, May 25, 2021 at 03:55 PM, Robert Benward wrote:
When entering local time, what ever number you put in, is modified when you say "yes" to the DST.  If you put in 1400hrs, and then say "yes" to DST, the number recorded would be 1300hrs.  So you need to add 1hr to local, then say yes to DST and the time will be correct. But don't do it twice (see below)!  A little confusing if you don't know what is going on.

Bob,

This is expected operation.  The OnStep does not deal with DST. So if the time you are entering is DST, it changes it to standard time before setting its clock.

John


Howard Dutton
 

On Tue, May 25, 2021 at 01:55 PM, Robert Benward wrote:
  • The scroll rates when entering numbers are pretty fast.  The rates also change rather quickly.  It's easy to overshoot your mark and difficult to get within a minute of desired time.  Setting of coordinates (in goto) has the same issue.
A known issue, I'm busy with other stuff.

  • When entering local time, what ever number you put in, is modified when you say "yes" to the DST.  If you put in 1400hrs, and then say "yes" to DST, the number recorded would be 1300hrs.  So you need to add 1hr to local, then say yes to DST and the time will be correct. But don't do it twice (see below)!  A little confusing if you don't know what is going on.
  • When repeating the process, the previous time entry is correct (that is after the DST modifies it, e.g. enter 9hrs, hit DST, 8hrs is recorded), but DST returns to the default value of "no". Change it to "yes", and now your recorded time goes to 7hrs. You think you are correcting the DST setting, but it actually subtracts 1hr each pass through.
I see no issue here.  Note that UTC Offset should always be the standard time value.

  • When trying to slew below the horizon, it just stops and no warning is given.  When looking at RA & DEC, you end up scratching your head.
My SHC shows the icon "Err up/dn arrow" (above overhead or below horizon limit.)

  • When I power off and back on, the SHC does not remember the time.
My MaxESP3 with DS3231 remembers the time just fine across power cycles.

  • Selecting sites.  I can pick a site, but not clear how to program it or change the name
That feature is not supported on the SHC and probably never will be.  Too cumbersome to key in.


Robert Benward
 

John,
Now that I know, I can deal with it.  It was puzzling operating from just the hand controller, you think you are going in to verify the time, but you get to DST and it keeps going back to the "no" position.  Put it back to "yes" and you keep decrementing the time.  Now it all makes sense...
Thanks,
Bob


Howard Dutton
 
Edited

Note testing was done with the latest: SWS, SHC, OnStep release-4.24 on a MaxESP3 and with an WeMos D1 Mini Pro running the SWS.

I tested both the ESP32 SHC and Teensy SHC....

The ESP32 SHC usually would not come up (no display) when cycling MaxESP3 power while its ST4 was plugged in.  Unplug and plug back in ST4 and it came up and connected.  I doubt this is software related.

The Teensy SHC was 100% reliable in all cases.


Dave Schwartz
 

On some processors that have an internal RTC (ESP32, STM32) the time may remain across a power down but it won't be advancing without a battery to keep the RTC clock running. You can tell if the MCU has an RTC by whether it has a Vbat line (whether or not the dev kit board actually maps it to an external pin).

One thing that may be confusing to you is that OnStep keeps time internally only in UTC . This is because local time is irrelevant to OnStep... all it needs is UTC, date and longitude to calculate the local sidereal time (LST) upon which all pointing calculations are made. It will give you local mean time if asked but this is only UTC modified by the UTC offset and makes no allowance for daylight time.

So when you enter the time on the SHC you are entering it in local time as if you are reading it from your wristwatch or a clock on the wall and then telling it whether that is a daylight time or not. The SHC converts what you entered to standard time (subtracting 3600 if you said you entered a daylight time) and then sends that to the controller as the local mean time (LMT) where the conversion to UTC (using UTC offset, so it's important to set that properly before setting the time) is then performed before the value is stored in the RTC. Whether the original entry was in daylight time or not is lost and is not stored anywhere. That is why when you enter the value 20:00:00 in the SHC and say it was daylight time, it appears as 19:00:00 when you go back to time entry... it's just showing you the local mean time because it doesn't know if that's daylight time or not. If you were to accept the 19:00:00 and say that it was not DST then everything would still be correct.


On May 25, 2021 7:52:11 p.m. EDT, "Robert Benward via groups.io" <rbenward@...> wrote:
That is my other problem I'll be talking about in another topic, getting my WEMOS to work.  I get the wifi signal but cannot retrieve a web page at either 192.168.0.1 or 192.168.0.1:9999.  So right now I can't confirm the time that way.  Funny, I removed the WEMOS to program it, but powered up Onstep anyway.  The time was remembered...I put the WEMOS back in, and time was lost at first, but after hitting "set date/time" on my phone via app and bluetooth, the time came back.  maybe I am not waiting long enough?

I am now seeing your comment about the com ports.  Yes, it was strange, but with it working now, I will leave sleeping dogs lie.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


John Petterson
 

On Tue, May 25, 2021 at 03:55 PM, Robert Benward wrote:
Selecting sites.  I can pick a site, but not clear how to program it or change the name
The location name, and entry of location lat/lan information can be done with either the Android App or the web browser interface.


Howard Dutton
 
Edited

On Tue, May 25, 2021 at 05:11 PM, Howard Dutton wrote:
  • The scroll rates when entering numbers are pretty fast.  The rates also change rather quickly.  It's easy to overshoot your mark and difficult to get within a minute of desired time.  Setting of coordinates (in goto) has the same issue.
A known issue, I'm busy with other stuff.
I added code to regulate the scroll speed when navigating the u8g2 interface, this includes the menus and also controls for setting values.

Rather than using a fixed scroll speed I implemented acceleration, so at first it moves slowly then after about 5 seconds it's very fast.  This is needed since some of the catalogs are quite large and would take forever to scroll through otherwise.

Seems to be working quite nicely here.