Topics

FYSETC S6 and OnStep - proposal for update


martin@...
 

Hello,

I have forked the main branch of OnStep and modified the code (I am more HW guy (my code is not nice but it works :) ) - so I am not brave enough to fork and pull - yet :) ) - despite that here are my 50cents to FYSETC S6 branch:

https://github.com/MartinLaza/OnStep

- code is suitable for my EQ5
- dew heater on Aux 4 - thanks Khalid!!
- Auxiliary functions with default values on startup - useful for fan control, or reticle as aux on web interface without reticle feature ;) - this shall be implemented in main branch I think...
- Reticle led on Aux2 with simplied control and inverted logic - this is very FYSETC specific due to availability of fan/heater controllers - it is completely up to us how to wire it
- Wemos for Wifi
- GPS as time source, at this moment without PPS
- 4 LED for status - STAT1, STAT2, WEMOS LED, GPS LED


Khalid Baheyeldin
 

Nice build.
I don't see wires for the Boot0 pins of the V2 board.
How are you flashing it?

Where did you get the ribbon cable from?

For managing Config.h specific stuff, I just add this like to Config.h:

#include "MyConfig.h"

Then I have my own values in a file called MyConfig.h, with #undef for the value before
the #define.

Regarding the rest of the firmware, here is a list of changes.

https://github.com/hjd1964/OnStep/compare/master...MartinLaza:master


martin@...
 

Hi Khalid!

Boot0 is handled with a jumper now - it will be added as a push button and available on the enclosure for easy flashing

Ribon is homemade - it is nothing complicated - just a IDC10 connector and ribbon cable. Than jsut crimp it in a small desktop wise - done :)

Thank you with the tip for myconfig :) as said - I am not a real sw guy :)

unfortunately it doesnt solve all of my changes - like features :)


THere is one more interesting change - and for you Khalid important - AnalogWrite needs range 0-1023 instead of 0-255 - that is probably the reason why your heater is not that hot ;)

Martin


martin@...
 

This shall work :)

https://de.aliexpress.com/item/33029492417.html?spm=a2g0o.productlist.0.0.d2117dacjkFlr9&algo_pvid=691fa94f-bbae-4c20-96a5-8eedbc46f843&algo_expid=691fa94f-bbae-4c20-96a5-8eedbc46f843-4&btsid=2100bde316065200281551910ea3e7&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_


Khalid Baheyeldin
 

On Fri, Nov 27, 2020 at 06:26 PM, <martin@...> wrote:
Thank you with the tip for myconfig :) as said - I am not a real sw guy :)
unfortunately it doesnt solve all of my changes - like features :)
It doesn't, but it is good practice not to change the base software as much as
possible. MyConfig.h solves that for me, as I don't need other changes in the
code.

THere is one more interesting change - and for you Khalid important - AnalogWrite needs range 0-1023 instead of 0-255 - that is probably the reason why your heater is not that hot ;)
That is a good find!

What Howard can do in the code is to have a value called MAX_ANALOG_RANGE.
Then in the S6 pinmap, set that value to 1023. The default will be to check if that
value is defined, and if it is not, it is set to 255. That way, no need to have the
maximum defined in every pinmap, only in the one that needs it to be 1023.

Howard, do you want me to submit a pull request for this?


Khalid Baheyeldin
 

On Fri, Nov 27, 2020 at 06:35 PM, <martin@...> wrote:
This shall work :)
Yeah, I have seen ones like it, and they were 50cm, way too long.
These are 30cm, still long, but

The reason is: I am thinking of having a daughter board for everything that goes
into EXP1 and EXP2 and connecting them with two ribbon cables.

But it is not urgent, since what I have works for now ...


martin@...
 

This could be also done like board specific - easier and for nomal user "hidden", they dont need to bother themself with it...


martin@...
 

That is also on my roadmap - like a small panel which fits one side of the enclosure (LEDs, GPS, Wemos, Weather) and just connect that with ribbon cable..maybe we shall join our effort here :)


Howard Dutton
 

On Fri, Nov 27, 2020 at 03:38 PM, Khalid Baheyeldin wrote:
Howard, do you want me to submit a pull request for this?
I added analogWriteResolution(8) to the STM32 HAL instead.  Please test and let me know if that does the trick.

Wow, that's an unfortunate situation STM32Duino defaulting to 12bit but I'm sure there's backwards compatibility considerations, so I understand.


martin@...
 

I can try my first pull with those default values for aux features :) lets see :)


Brian Davis
 

Beware with respect to the GPS.  Here's the output of my Pi3 timeserver, running an Adafruit Ultimate GPS, external antenna,  and PPS enabled (along with GPSD and NTPd):

pi@tappertime:~ $ ntpq -crv -pn
associd=0 status=0115 leap_none, sync_pps, 1 event, clock_sync,
version="ntpd 4.2.8p12@1.3728-o Fri Oct  2 15:12:16 UTC 2020 (1)",
processor="armv7l", system="Linux/5.4.51-v7+", leap=00, stratum=1,
precision=-20, rootdelay=0.000, rootdisp=1.090, refid=PPS,
reftime=e36c10b9.bc25c591  Fri, Nov 27 2020 17:56:41.734,
clock=e36c10c0.8d41913e  Fri, Nov 27 2020 17:56:48.551, peer=36753, tc=3,
mintc=3, offset=0.000407, frequency=-2.907, sys_jitter=0.000954,
clk_jitter=0.001, clk_wander=0.000, tai=37, leapsec=201701010000,
expire=202012280000

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
o127.127.22.0    .PPS.            0 l    7    8  377    0.000    0.000   0.001
x127.127.28.0    .GPS.            1 l    7   16  377    0.000  -473.98  34.068
*127.127.28.2    .SHM2.           0 l    9   16  377    0.000    0.000   0.001

The .GPS. clock is the NMEA time broadcast by the GPS constellation.  The .PPS> clock is the NMEA output conditioned to the GPS PPS signal.  Note, the jitter in the .GPS. clock.  That's a lot.  The offset value is about half a second, meaning that the average time given is about half a second off from the start of second (PPS).  That's not a big deal, because the alignment process will take care of the error.  But the jitter, means that every time the system clock gets updated, its going to change the clock (system tick counter) by a significant amount.  If you can update once, then ignore the GPS, great.  If you set up PPS, even better.  But don't run it on NMEA time.

Virus-free. www.avast.com


On Fri, Nov 27, 2020 at 4:17 PM <martin@...> wrote:
Hello,

I have forked the main branch of OnStep and modified the code (I am more HW guy (my code is not nice but it works :) ) - so I am not brave enough to fork and pull - yet :) ) - despite that here are my 50cents to FYSETC S6 branch:

https://github.com/MartinLaza/OnStep

- code is suitable for my EQ5
- dew heater on Aux 4 - thanks Khalid!!
- Auxiliary functions with default values on startup - useful for fan control, or reticle as aux on web interface without reticle feature ;) - this shall be implemented in main branch I think...
- Reticle led on Aux2 with simplied control and inverted logic - this is very FYSETC specific due to availability of fan/heater controllers - it is completely up to us how to wire it
- Wemos for Wifi
- GPS as time source, at this moment without PPS
- 4 LED for status - STAT1, STAT2, WEMOS LED, GPS LED


martin@...
 

Thanks Brian,

I am waiting for GPS module with PPS signal - Is combination of GPS and RTC supported in OnStep?


Khalid Baheyeldin
 

On Fri, Nov 27, 2020 at 07:14 PM, Brian Davis wrote:
The .GPS. clock is the NMEA time broadcast by the GPS constellation.  The .PPS> clock is the NMEA output conditioned to the GPS PPS signal.  Note, the jitter in the .GPS. clock.  That's a lot.  The offset value is about half a second, meaning that the average time given is about half a second off from the start of second (PPS).  That's not a big deal, because the alignment process will take care of the error.  But the jitter, means that every time the system clock gets updated, its going to change the clock (system tick counter) by a significant amount.  If you can update once, then ignore the GPS, great.  If you set up PPS, even better.  But don't run it on NMEA time.
I have a GPS with PPS on my S6 (and so does Dave Schwartz).

The way I understand it (Howard will correct me) is that OnStep waits until the GPS gets a lock, then reads the coordinates
and time, then does not bother with those anymore for the rest of the session.
PPS is just that: one second pulses from the GPS, and they are just one pin that OnStep averages to sync its timing.


Brian Davis
 

I'm an INDI user, and I ended up putting the GPS on the RPi4 running INDI.  I wanted the added benefits of gpsd and NTP, and the INDI server can use the time to sync all my attached gear to the same timebase.  I bring the PPS output from the Pi to the MKS Genl using the Pin Howard designated for that purpose.  So far as I can tell, it works very well.  It you're using PPS, you can update the rig  continuously if you want, which ensures a very accurate timebase, and minimizes error here and there.

Howards approach sounds appropriate to me.  One and done is the safest all around way to use a GPS.  Continuous update of very precise time (not location) has some benefits, but at the cost of a lot of hassle and code.  Location should never be updated continuously.

When my rig is home, I just tie it to  the house timeserver, an RPi 3 running the Adafruit GPS, fully phase locked with PPS, and running at Stratum one.  I send the address for this in DHCP, and use the PPS output for radio gear as well as astro.  Every network device in my house runs on the exact same time, and it's correct to the microsecond.  

Virus-free. www.avast.com


On Fri, Nov 27, 2020 at 8:14 PM Khalid Baheyeldin <kbahey@...> wrote:
On Fri, Nov 27, 2020 at 07:14 PM, Brian Davis wrote:
The .GPS. clock is the NMEA time broadcast by the GPS constellation.  The .PPS> clock is the NMEA output conditioned to the GPS PPS signal.  Note, the jitter in the .GPS. clock.  That's a lot.  The offset value is about half a second, meaning that the average time given is about half a second off from the start of second (PPS).  That's not a big deal, because the alignment process will take care of the error.  But the jitter, means that every time the system clock gets updated, its going to change the clock (system tick counter) by a significant amount.  If you can update once, then ignore the GPS, great.  If you set up PPS, even better.  But don't run it on NMEA time.
I have a GPS with PPS on my S6 (and so does Dave Schwartz).

The way I understand it (Howard will correct me) is that OnStep waits until the GPS gets a lock, then reads the coordinates
and time, then does not bother with those anymore for the rest of the session.
PPS is just that: one second pulses from the GPS, and they are just one pin that OnStep averages to sync its timing.


Khalid Baheyeldin
 

On Sat, Nov 28, 2020 at 09:11 AM, Brian Davis wrote:
I'm an INDI user, and I ended up putting the GPS on the RPi4 running INDI. 
Me too, but not on an RPi, rather a laptop.

In KStars, there is an option on who is the authoritative source for location and time.



If the mount has GPS, then use that, and KStars/INDI will get that info from there.

So, there are many ways to skin this cat ...


Brian Davis
 

Indi's GPSNMEA driver also restricts dongles to a single update, as needed.  In my case, I run Stellarmate on the Pi (Rpi4 running on NVMe/M2 SSD, with Adafruit Ugps, external antennas for GPS and WiFi) with the Pi using pps/ntpd/gpsd and running at stratum one, and the INDI gpsd driver.  I use "GPS Updates.." in Ekos, because the Pi time is more accurate than any other chip in the system.

Do you need a Stratum 1 timeserver in your rig?  Well, no.  But if it's basically free to turn your Pi into a dead nuts accurate clock, which in turn can condition many of the other critical clocks in the rig, hey!  Bonus!  A mount is nothing but a big clock at it's heart.  Dead nuts accurate is always better than wambly, except in sexual intercourse and suicide attempts.

I VNC into the Pi to run the rig, although Jasem and Co. have really done a great job overhauling the App/Liveview interfaces, and I'm finding myself using an iPad to run the rig more and more.  I don't even need to be in the same State to run my rig now, and at least one of my buddies has already borrowed the rig for a night, to shoot something he was interested in (7 hours of 3 minute subs of the Pleides.).  The only thing I did, was put the t-shirts on for flats, when I woke up in the morning.

Virus-free. www.avast.com


On Sat, Nov 28, 2020 at 2:26 PM Khalid Baheyeldin <kbahey@...> wrote:
On Sat, Nov 28, 2020 at 09:11 AM, Brian Davis wrote:
I'm an INDI user, and I ended up putting the GPS on the RPi4 running INDI. 
Me too, but not on an RPi, rather a laptop.

In KStars, there is an option on who is the authoritative source for location and time.



If the mount has GPS, then use that, and KStars/INDI will get that info from there.

So, there are many ways to skin this cat ...


Khalid Baheyeldin
 

On Fri, Nov 27, 2020 at 07:01 PM, Howard Dutton wrote:
On Fri, Nov 27, 2020 at 03:38 PM, Khalid Baheyeldin wrote:
Howard, do you want me to submit a pull request for this?
I added analogWriteResolution(8) to the STM32 HAL instead.  Please test and let me know if that does the trick.

Wow, that's an unfortunate situation STM32Duino defaulting to 12bit but I'm sure there's backwards compatibility considerations, so I understand.
Howard,

Initial testing using ANALOG_OUTPUT for the Heater0Pin heater on the S6 says it works.
At 53%, the dew strip was at 15C when ambient was 4C.

One thing I noticed is that the LED for the heater is on all the time, but gets
brighter as I increase the output, and dimmer when I dial it back. That is different
from when it was set as a DEW_HEATER, which is digital, and therefore blinked.

Will test it out more tonight and report if anything is different.


Howard Dutton
 

On Fri, Nov 27, 2020 at 04:02 PM, <martin@...> wrote:
I can try my first pull with those default values for aux features :) lets see :)
That's a good idea, thank you.  There were conflicts with what I was working on here at the moment so I coded similar instead of merging.

The master branch has it.