Topics

new FYSETC S6 build

Markus Kempf
 

I recently got my Fysetc S6 board, planned as a replacement for my MKS-GenL 1 build I did two years ago. Yesterday I finally found some time to do a bench build. The very good news is that it went very smoothly. After about 2 hours I had installed the Arduino SDK, updated for the 3D printer boards, downloaded the STM programmer, OnStep (code 4.9g and Ascom driver), did some config.h editing and compiled and uploaded to the board and the Wemos (Lolin) D1 mini pro. Just following the Wiki page, everything worked immediately.
The only very minor hurdles were the unknown voltages at the UART1 port, I researched the schematics and actually measured with my multimeter. Vcc is 5V (good for the Wemos) and logic levels are 3.3V, so no need to do any shifting. Another concern is the voltage protection of the TMC2130 I use. To be safe I still follow the advice in the MKS-GenL Wiki but would be good to know if this is really necessary.
After connecting the motors (Nema17, 0.9deg, 1.7A rated current) and the power supply (old notebook type with 20V, 4.5A) the RA motor started. I was able to connect to the web server and connect the ASCOM driver with Interstellarum. Some further settings done and the first GOTO was successful (both motors turned :-).
With the default gear setting, I get 5.6deg/s as max slew speed. The motors don't get warm, I can still touch the TMC2130 after a few hours (Irun = 600mA, Islew=1200mA).
Up to this point this is amazingly perfect (btw, the TMC2130 status gets displayed as OK, I enabled this feature without knowing that it is not supposed to work).
The board has a lot of potential and many yet unused features, the pinmap is still quite short.

Wishes:
- more serial ports (looking at the schematics, the STM32 offers 7 serials, currently used 2 1/2 (USB, UART1, GPS). At least one more for a Bluetooth module would be nice
- usage of the RGB LED socket for some "cool" stuff
- usage of the LCD port for some on the box graphical feedback and maybe direct control

ToDos:
- test my two RTC units (DS3231, DS3234). Direct connection to the I2C/SPI sockets on the PCB or some special pins? pinmap?
- test my GPS module, pinmap?
- test my Ethernet W5500 module (pinmap?)
- test my weather module
- test my bluetooth joystick

Question:
I observed a runaway of the displayed time on the status webpage. After about 3h (time set by the ascom driver with connec) the difference is now 50s.
Site:
7/09/20 12:47:03 UT (web browser)
07/09/20 12:47:53 UT (08:35:13 LST)
Will this be better with a RTC/GPS attached or is there something wrong or just badly configured?

Markus

Dave Schwartz
 

On 2020-07-09 8:56 a.m., Markus Kempf wrote:
To be safe I still follow the advice in the MKS-GenL Wiki but would be good to know if this is really necessary.
If it were necessary to ensure the sequence of voltages during power-up, my 2130s would have been toast long ago. I have been forgetting all about this and plugging in the USB (powers up the whole logic side) before turning on the 12V, and vice versa, pretty much randomly at least a hundred times now. With all the stuff I have connected now (S6, LED, WeMos, GPS w/active antenna, ESP SHC) I think connecting only the USB first is exceeding the current capacity of my USB hub on the bench because sometimes the SHC fails to start or browns-out randomly). From now on I'm going to try connecting/disconnecting the USB only when the 12V is on.
(btw, the TMC2130 status gets displayed as OK, I enabled this feature without knowing that it is not supposed to work).
For me, enabling DRIVER_STATUS TMC_SPI caused a motor fault to be detected at startup and randomly thereafter so that no movement operation was allowed. Maybe I should try turning it on again.
The board has a lot of potential and many yet unused features, the pinmap is still quite short.

Wishes:
- more serial ports (looking at the schematics, the STM32 offers 7 serials, currently used 2 1/2 (USB, UART1, GPS). At least one more for a Bluetooth module would be nice
Please note that the port for the GPS is it the process of being moved to RX3/TX3 on EXP1 to reduce the connector count
- usage of the RGB LED socket for some "cool" stuff
- usage of the LCD port for some on the box graphical feedback and maybe direct control

ToDos:
- test my two RTC units (DS3231, DS3234). Direct connection to the I2C/SPI sockets on the PCB or some special pins? pinmap?
DS3231 definitely won't work. It contains an EEPROM subdevice that conflicts with the exact same device already on the S6 itself. OnStep won't even start with it connected to the I2C header
- test my GPS module, pinmap?
GPS is working but has a bug we're in the process of straightening out (in addition to the serial port move)
- test my Ethernet W5500 module (pinmap?)
- test my weather module
I've tried my BME280 on the I2C header but my result has been that OnStep only starts up 1 out of about 6 times. I've gone so far as to change the voltage on the I2C header to 5V because I know that works on the STM32 PCB but without luck.
- test my bluetooth joystick

Question:
I observed a runaway of the displayed time on the status webpage. After about 3h (time set by the ascom driver with connec) the difference is now 50s.
Site:
7/09/20 12:47:03 UT (web browser)
07/09/20 12:47:53 UT (08:35:13 LST)
Will this be better with a RTC/GPS attached or is there something wrong or just badly configured?
It was devilishly difficult for Khalid and Howard to get the timer initialization right. The S6 has a main clock crystal but all that means is that it should be consistent but manufacturing tolerances are such that it may not be 100% accurate. I'm not sure an accurate clock was high on FYSETC's list of priorities... 3D printers don't need a very accurate clock.

But PPS sync, which I have verified from my GPS to the PPS_SENSE pin works, should take care of that.

A number of these things are covered by the disclaimer 'subject to change without notice' of an under-development project.


Markus

Markus Kempf
 

thank you very much Dave for the tips. Will try to help out with testing
if needed. OnStep is an under-development project since I joined the
group in 2016 and build the first implementation on a breadboard with a
Mega2560 (the reason I own the RTCs).

I must be a lucky men, just connected my DS3231 to the S6 I2C header and
OnStep (now 4.9j) started up and displays almost the right time (the RTC
was not used for 2years). Then I set date/time with the web interface
and removed power for 5min. After switching on again it showed the right
time. Don't know if this is the expected behaviour :-) Are there other
ways to prove that the RTC is working (USB is not connected). I have not
yet connected the PPS pin. The S6 OnStep time is still running fast.

My DS3231 is pretty huge with a blue pcb and "MH" in the upper left
corner and a CR2032 battery on the backside. I could take a photo if needed.

Markus

Am 09/07/2020 um 17:00 schrieb Dave Schwartz:


On 2020-07-09 8:56 a.m., Markus Kempf wrote:
To be safe I still follow the advice in the MKS-GenL Wiki but would
be good to know if this is really necessary.
If it were necessary to ensure the sequence of voltages during
power-up, my 2130s would have been toast long ago. I have been
forgetting all about this and plugging in the USB (powers up the whole
logic side) before turning on the 12V, and vice versa, pretty much
randomly at least a hundred times now. With all the stuff I have
connected now (S6, LED, WeMos, GPS w/active antenna, ESP SHC) I think
connecting only the USB first is exceeding the current capacity of my
USB hub on the bench because sometimes the SHC fails to start or
browns-out randomly). From now on I'm going to try
connecting/disconnecting the USB only when the 12V is on.
(btw, the TMC2130 status gets displayed as OK, I enabled this feature
without knowing that it is  not supposed to work).
For me, enabling DRIVER_STATUS TMC_SPI caused a motor fault to be
detected at startup and randomly thereafter so that no movement
operation was allowed. Maybe I should try turning it on again.
The board has a lot of potential and many yet unused features, the
pinmap is still quite short.

Wishes:
- more serial ports (looking at the schematics, the STM32 offers 7
serials, currently used 2 1/2 (USB, UART1, GPS). At least one more
for a Bluetooth module would be nice
Please note that the port for the GPS is it the process of being moved
to RX3/TX3 on EXP1 to reduce the connector count
- usage of the RGB LED socket for some "cool" stuff
- usage of the LCD port for some on the box graphical feedback and
maybe direct control

ToDos:
- test my two RTC units (DS3231, DS3234). Direct connection to the
I2C/SPI sockets on the PCB or some special pins? pinmap?
DS3231 definitely won't work. It contains an EEPROM subdevice that
conflicts with the exact same device already on the S6 itself. OnStep
won't even start with it connected to the I2C header
- test my GPS module, pinmap?
GPS is working but has a bug we're in the process of straightening out
(in addition to the serial port move)
- test my Ethernet W5500 module (pinmap?)
- test my weather module
I've tried my BME280 on the I2C header but my result has been that
OnStep only starts up 1 out of about 6 times. I've gone so far as to
change the voltage on the I2C header to 5V because I know that works
on the STM32 PCB but without luck.
- test my bluetooth joystick

Question:
I observed a runaway of the displayed time on the status webpage.
After about 3h (time set by the ascom driver with connec) the
difference is now 50s.
Site:
   7/09/20 12:47:03 UT (web browser)
   07/09/20 12:47:53 UT (08:35:13  LST)
   Will this be better with a RTC/GPS attached or is there something
wrong or just badly configured?
It was devilishly difficult for Khalid and Howard to get the timer
initialization right. The S6 has a main clock crystal but all that
means is that it should be consistent but manufacturing tolerances are
such that it may not be 100% accurate. I'm not sure an accurate clock
was high on FYSETC's list of priorities... 3D printers don't need a
very accurate clock.

But PPS sync, which I have verified from my GPS to the PPS_SENSE pin
works, should take care of that.

A number of these things are covered by the disclaimer 'subject to
change without notice' of an under-development project.


Markus


Markus Kempf
 

ok, I found another DS3231 attached to one of my Raspi's. And now I can
observe exactly the same symptoms. It does not work. This module is much
smaller, has a small yellow button battery, no extra chip , no power led
and the text "DS3231 For Pi". So it does depend on the type of module.
Most likely the larger one with the separate chip (eeprom?) has
different type/size of eeprom.

Markus

Am 09/07/2020 um 18:05 schrieb Markus Kempf:

thank you very much Dave for the tips. Will try to help out with testing
if needed. OnStep is an under-development project since I joined the
group in 2016 and build the first implementation on a breadboard with a
Mega2560 (the reason I own the RTCs).

I must be a lucky men, just connected my DS3231 to the S6 I2C header and
OnStep (now 4.9j) started up and displays almost the right time (the RTC
was not used for 2years). Then I set date/time with the web interface
and removed power for 5min. After switching on again it showed the right
time. Don't know if this is the expected behaviour :-) Are there other
ways to prove that the RTC is working (USB is not connected). I have not
yet connected the PPS pin. The S6 OnStep time is still running fast.

My DS3231 is pretty huge with a blue pcb and "MH" in the upper left
corner and a CR2032 battery on the backside. I could take a photo if
needed.

Markus

Am 09/07/2020 um 17:00 schrieb Dave Schwartz:

On 2020-07-09 8:56 a.m., Markus Kempf wrote:
To be safe I still follow the advice in the MKS-GenL Wiki but would
be good to know if this is really necessary.
If it were necessary to ensure the sequence of voltages during
power-up, my 2130s would have been toast long ago. I have been
forgetting all about this and plugging in the USB (powers up the whole
logic side) before turning on the 12V, and vice versa, pretty much
randomly at least a hundred times now. With all the stuff I have
connected now (S6, LED, WeMos, GPS w/active antenna, ESP SHC) I think
connecting only the USB first is exceeding the current capacity of my
USB hub on the bench because sometimes the SHC fails to start or
browns-out randomly). From now on I'm going to try
connecting/disconnecting the USB only when the 12V is on.
(btw, the TMC2130 status gets displayed as OK, I enabled this feature
without knowing that it is  not supposed to work).
For me, enabling DRIVER_STATUS TMC_SPI caused a motor fault to be
detected at startup and randomly thereafter so that no movement
operation was allowed. Maybe I should try turning it on again.
The board has a lot of potential and many yet unused features, the
pinmap is still quite short.

Wishes:
- more serial ports (looking at the schematics, the STM32 offers 7
serials, currently used 2 1/2 (USB, UART1, GPS). At least one more
for a Bluetooth module would be nice
Please note that the port for the GPS is it the process of being moved
to RX3/TX3 on EXP1 to reduce the connector count
- usage of the RGB LED socket for some "cool" stuff
- usage of the LCD port for some on the box graphical feedback and
maybe direct control

ToDos:
- test my two RTC units (DS3231, DS3234). Direct connection to the
I2C/SPI sockets on the PCB or some special pins? pinmap?
DS3231 definitely won't work. It contains an EEPROM subdevice that
conflicts with the exact same device already on the S6 itself. OnStep
won't even start with it connected to the I2C header
- test my GPS module, pinmap?
GPS is working but has a bug we're in the process of straightening out
(in addition to the serial port move)
- test my Ethernet W5500 module (pinmap?)
- test my weather module
I've tried my BME280 on the I2C header but my result has been that
OnStep only starts up 1 out of about 6 times. I've gone so far as to
change the voltage on the I2C header to 5V because I know that works
on the STM32 PCB but without luck.
- test my bluetooth joystick

Question:
I observed a runaway of the displayed time on the status webpage.
After about 3h (time set by the ascom driver with connec) the
difference is now 50s.
Site:
   7/09/20 12:47:03 UT (web browser)
   07/09/20 12:47:53 UT (08:35:13  LST)
   Will this be better with a RTC/GPS attached or is there something
wrong or just badly configured?
It was devilishly difficult for Khalid and Howard to get the timer
initialization right. The S6 has a main clock crystal but all that
means is that it should be consistent but manufacturing tolerances are
such that it may not be 100% accurate. I'm not sure an accurate clock
was high on FYSETC's list of priorities... 3D printers don't need a
very accurate clock.

But PPS sync, which I have verified from my GPS to the PPS_SENSE pin
works, should take care of that.

A number of these things are covered by the disclaimer 'subject to
change without notice' of an under-development project.


Markus



Dave Schwartz
 

Perhaps your DS3231 is a version with just the RTC. I was using the DS3231 name in the generic sense that it has become known as but it really is called the ZS-042 module which combines both the DS3231 RTC and EEPROM subdevices. Both were needed on the STM32 PCB so I had a number of them left over. Could you send pictures of your module? It seems that you have just confirmed one type of I2C RTC that works with this board. You should try hooking up its PPS output to the pin allocated for PPS sense, enable that in the Config.h and see if you get the PPS SYNC indication on the Web server status page... works for me with PPS from the GPS. Also see if that solves your clock drift issue.

If your time is correct each time you turn it on, then that is probably the RTC at work. The STM32F446 on the S6 has an internal RTC but it's not possible to hook up a battery to Vbat so I have observed that the S6 date/time just freezes at whatever it last was while powered off and only becomes current


On July 9, 2020 12:05:40 PM EDT, Markus Kempf <gmke@...> wrote:
thank you very much Dave for the tips. Will try to help out with testing
if needed. OnStep is an under-development project since I joined the
group in 2016 and build the first implementation on a breadboard with a
Mega2560 (the reason I own the RTCs).

I must be a lucky men, just connected my DS3231 to the S6 I2C header and
OnStep (now 4.9j) started up and displays almost the right time (the RTC
was not used for 2years). Then I set date/time with the web interface
and removed power for 5min. After switching on again it showed the right
time. Don't know if this is the expected behaviour :-) Are there other
ways to prove that the RTC is working (USB is not connected). I have not
yet connected the PPS pin. The S6 OnStep time is still running fast.

My DS3231 is pretty huge with a blue pcb and "MH" in the upper left
corner and a CR2032 battery on the backside. I could take a photo if needed.

Markus

Am 09/07/2020 um 17:00 schrieb Dave Schwartz:

On 2020-07-09 8:56 a.m., Markus Kempf wrote:
To be safe I still follow the advice in the MKS-GenL Wiki but would
be good to know if this is really necessary.
If it were necessary to ensure the sequence of voltages during
power-up, my 2130s would have been toast long ago. I have been
forgetting all about this and plugging in the USB (powers up the whole
logic side) before turning on the 12V, and vice versa, pretty much
randomly at least a hundred times now. With all the stuff I have
connected now (S6, LED, WeMos, GPS w/active antenna, ESP SHC) I think
connecting only the USB first is exceeding the current capacity of my
USB hub on the bench because sometimes the SHC fails to start or
browns-out randomly). From now on I'm going to try
connecting/disconnecting the USB only when the 12V is on.
(btw, the TMC2130 status gets displayed as OK, I enabled this feature
without knowing that it is  not supposed to work).
For me, enabling DRIVER_STATUS TMC_SPI caused a motor fault to be
detected at startup and randomly thereafter so that no movement
operation was allowed. Maybe I should try turning it on again.
The board has a lot of potential and many yet unused features, the
pinmap is still quite short.

Wishes:
- more serial ports (looking at the schematics, the STM32 offers 7
serials, currently used 2 1/2 (USB, UART1, GPS). At least one more
for a Bluetooth module would be nice
Please note that the port for the GPS is it the process of being moved
to RX3/TX3 on EXP1 to reduce the connector count
- usage of the RGB LED socket for some "cool" stuff
- usage of the LCD port for some on the box graphical feedback and
maybe direct control

ToDos:
- test my two RTC units (DS3231, DS3234). Direct connection to the
I2C/SPI sockets on the PCB or some special pins? pinmap?
DS3231 definitely won't work. It contains an EEPROM subdevice that
conflicts with the exact same device already on the S6 itself. OnStep
won't even start with it connected to the I2C header
- test my GPS module, pinmap?
GPS is working but has a bug we're in the process of straightening out
(in addition to the serial port move)
- test my Ethernet W5500 module (pinmap?)
- test my weather module
I've tried my BME280 on the I2C header but my result has been that
OnStep only starts up 1 out of about 6 times. I've gone so far as to
change the voltage on the I2C header to 5V because I know that works
on the STM32 PCB but without luck.
- test my bluetooth joystick

Question:
I observed a runaway of the displayed time on the status webpage.
After about 3h (time set by the ascom driver with connec) the
difference is now 50s.
Site:
   7/09/20 12:47:03 UT (web browser)
   07/09/20 12:47:53 UT (08:35:13  LST)
   Will this be better with a RTC/GPS attached or is there something
wrong or just badly configured?

It was devilishly difficult for Khalid and Howard to get the timer
initialization right. The S6 has a main clock crystal but all that
means is that it should be consistent but manufacturing tolerances are
such that it may not be 100% accurate. I'm not sure an accurate clock
was high on FYSETC's list of priorities... 3D printers don't need a
very accurate clock.

But PPS sync, which I have verified from my GPS to the PPS_SENSE pin
works, should take care of that.

A number of these things are covered by the disclaimer 'subject to
change without notice' of an under-development project.


Markus







Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#23017): https://onstep.groups.io/g/main/message/23017
Mute This Topic: https://groups.io/mt/75396394/1100908
Group Owner: main+owner@onstep.groups.io
Unsubscribe: https://onstep.groups.io/g/main/leave/defanged [Dave.Schwartz@...]

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

Markus Kempf
 

ok, found the PPS pin on the SPI header CD (upper row most left pin) and connected it to the DS3231 module. Immediate success! Before connecting, I got no status web page, then it showed up and displays:

  Tracking: On (PPS Sync)

THANK YOU!!!

Markus


Markus Kempf
 

ok, found the PPS pin on the SPI header CD (upper row most left pin) and connected it to the DS3231 module. Immediate success! Before connecting, I got no status web page, then it showed up and displays:

  Tracking: On (PPS Sync)

THANK YOU!!!

Markus


Dave Schwartz
 

Hmmm, mine are all different from that. They all say ZS-042 where yours says DS3231. Also, only one of mine has the diode and resistor to the left of and above the SCL label on the right (those form the battery charging circuit and the lack of those components on mine are probably why I've never had a problem using non-rechargeable CR2032 batteries).

The big chip is the DS3231 but the small chip is the EEPROM. Perhaps your module has it at an address that doesn't duplicate the S6's onboard EEPROM which confuses the library which is why OnStep doesn't start (those A0, A1 and A2 pads are supposed to be jumpers you can bridge to change the EEPROM's address on the module but I tried that and it didn't work).

The PPS pin is on PB10, which is on EXP2 above the ground pin. Its probably easier to connect there because you will be making extensive use of the EXP connectors anyway. Not sure how your PPS SYNC works with it connected to the SPI header unless that a duplicate path (they do that for some things).

For my own S6, I'm creating a daughter board made from stripboard that has many 'essential' components and only uses the two EXP connectors and UART1 (plus wires to the motor outputs because I've put RJ connectors for 5 axes on the daughter board too but those are not essential). Eventually I'll post a Fritzing layout for that but its not finalized yet.

On 2020-07-09 1:40 p.m., Markus Kempf wrote:

ok, found the PPS pin on the SPI header CD (upper row most left pin) and connected it to the DS3231 module. Immediate success! Before connecting, I got no status web page, then it showed up and displays:

  Tracking: On (PPS Sync)

THANK YOU!!!

Markus


Markus Kempf
 

I tried your pin on the EXT2 header and it works there too. I discovered
the SD pin by searching the S6 schematics PDF. PB10 goes to both headers
but EXT2 is more practical. A nice case would be nice if someone could
do a 3D design and print.

I'm lost in finding the GPS TX/RX pins. The pinmap says RX2/TX2
(PA2/PA3) is on the Y+ and Z+ end stops, but the PCB print tells me
something different.

Markus

Am 09/07/2020 um 20:49 schrieb Dave Schwartz:

Hmmm, mine are all different from that. They all say ZS-042 where
yours says DS3231. Also, only one of mine has the diode and resistor
to the left of and above the SCL label on the right (those form the
battery charging circuit and the lack of those components on mine are
probably why I've never had a problem using non-rechargeable CR2032
batteries).

The big chip is the DS3231 but the small chip is the EEPROM. Perhaps
your module has it at an address that doesn't duplicate the S6's
onboard EEPROM which confuses the library which is why OnStep doesn't
start (those A0, A1 and A2 pads are supposed to be jumpers you can
bridge to change the EEPROM's address on the module but I tried that
and it didn't work).

The PPS pin is on PB10, which is on EXP2 above the ground pin. Its
probably easier to connect there because you will be making extensive
use of the EXP connectors anyway. Not sure how your PPS SYNC works
with it connected to the SPI header unless that a duplicate path (they
do that for some things).

For my own S6, I'm creating a daughter board made from stripboard that
has many 'essential' components and only uses the two EXP connectors
and UART1 (plus wires to the motor outputs because I've put RJ
connectors for 5 axes on the daughter board too but those are not
essential). Eventually I'll post a Fritzing layout for that but its
not finalized yet.

On 2020-07-09 1:40 p.m., Markus Kempf wrote:

ok, found the PPS pin on the SPI header CD (upper row most left pin)
and connected it to the DS3231 module. Immediate success! Before
connecting, I got no status web page, then it showed up and displays:

  Tracking: On (PPS Sync)

THANK YOU!!!

Markus


Dave Schwartz
 

On 2020-07-09 5:17 p.m., Markus Kempf wrote:
I tried your pin on the EXT2 header and it works there too. I discovered
Yes... they have a habit of duplicating some pins from elsewhere of the board on the EXP headers... I guess this is one of them.
the SD pin by searching the S6 schematics PDF. PB10 goes to both headers
but EXT2 is more practical. A nice case would be nice if someone could
do a 3D design and print.
I'm working on it.

I have a design with the base exactly fitting the S6 PCB with a 2mm gap all around, 2mm thick walls and a bottom covered with half-way-through 2mm holes so you can drill open as many as you want for ventilation. The S6 board is 4mm above the bottom of the case. All walls from the base on extend upward at least to the level of the top of the USB connector and there are openings for the USB connector and reset button. The wall beside the power strip is taller... goes up to where I mount my daughter board 35mm above the S6 so you can mount a power switch, power inlet and possible heater outputs in it without having those wires mount into the walls of the upper half. Those other walls are lower because you have to be able to access lots of headers around the edge to plug in the cables to the daughter board and that's just too difficult with higher walls.

The top has walls that automatically adjust their depth to meet the corresponding wall from the base. It also has the top covered with those not-quite-through ventilation holes. It also has a column (a 'finger') extending down through a hole in the daughter board to just above the BOOT0 button so you can poke something (up to 3mm in diameter) to press the BOOT0 button when you need to reflash with the top on.

I'm almost satisfied with it but in my working copy I keep removing the filletted edges because FreeCAD has a bad habit of totally gorking your file if you try to make a change to a sketch when they are present.


I'm lost in finding the GPS TX/RX pins. The pinmap says RX2/TX2
(PA2/PA3) is on the Y+ and Z+ end stops, but the PCB print tells me
something different.
We've moved the GPS to USART3-RX3 and -TX3 (PC11 and PC10 on EXP1). The HAL has been updated to not define this serial port as one to be polled for LX200 commands if SERIAL_C_BAUD_DEFAULT is defined as OFF (which it is in the default Config.h file). All you need to do is connect your GPS TX to PC11, GPS RX to PC10, your PPS to PB10 (and 5V/GND from either of the two EXP connectors, I use them from EXP1 for everything on my daughter board so far. To enable it, I set TIME_LOCATION_SOURCE to GPS and add '#define SerialGPS Serial3'. All this is in the most recent master.

Markus

Am 09/07/2020 um 20:49 schrieb Dave Schwartz:
Hmmm, mine are all different from that. They all say ZS-042 where
yours says DS3231. Also, only one of mine has the diode and resistor
to the left of and above the SCL label on the right (those form the
battery charging circuit and the lack of those components on mine are
probably why I've never had a problem using non-rechargeable CR2032
batteries).

The big chip is the DS3231 but the small chip is the EEPROM. Perhaps
your module has it at an address that doesn't duplicate the S6's
onboard EEPROM which confuses the library which is why OnStep doesn't
start (those A0, A1 and A2 pads are supposed to be jumpers you can
bridge to change the EEPROM's address on the module but I tried that
and it didn't work).

The PPS pin is on PB10, which is on EXP2 above the ground pin. Its
probably easier to connect there because you will be making extensive
use of the EXP connectors anyway. Not sure how your PPS SYNC works
with it connected to the SPI header unless that a duplicate path (they
do that for some things).

For my own S6, I'm creating a daughter board made from stripboard that
has many 'essential' components and only uses the two EXP connectors
and UART1 (plus wires to the motor outputs because I've put RJ
connectors for 5 axes on the daughter board too but those are not
essential). Eventually I'll post a Fritzing layout for that but its
not finalized yet.

On 2020-07-09 1:40 p.m., Markus Kempf wrote:

ok, found the PPS pin on the SPI header CD (upper row most left pin)
and connected it to the DS3231 module. Immediate success! Before
connecting, I got no status web page, then it showed up and displays:

  Tracking: On (PPS Sync)

THANK YOU!!!

Markus



Howard Dutton
 

On Thu, Jul 9, 2020 at 02:17 PM, Markus Kempf wrote:
I'm lost in finding the GPS TX/RX pins. The pinmap says RX2/TX2
(PA2/PA3) is on the Y+ and Z+ end stops, but the PCB print tells me
something different.
PA2/PA3 is from the schematic.

But actually, I made a little typo in the comment in the pin-map file...
PA2 is TX2 and PA3 is RX2 where the comment would lead you to believe it's the other way around.

There is nothing forcing you to use one location over the other for GPS, OnStep doesn't care RX2/TX2 or RX3/TX3.

Howard Dutton
 

On Thu, Jul 9, 2020 at 04:33 PM, Howard Dutton wrote:
There is nothing forcing you to use one location over the other for GPS
Not that I know of anyway!

Dave Schwartz
 

For me it was just less complicated to connect the GPS to PC10 and PC11 on EXP1 (Serial3) with two wires into a connector I was already using rather than two new connectors into Y+ and Z+. The daughter board I am building is already cumbersome enough to connect and disconnect with 6 connectors (one to the middle and 5 on two edges) without adding another two in the middle.

On 2020-07-09 7:33 p.m., Howard Dutton wrote:
On Thu, Jul 9, 2020 at 02:17 PM, Markus Kempf wrote:

I'm lost in finding the GPS TX/RX pins. The pinmap says RX2/TX2
(PA2/PA3) is on the Y+ and Z+ end stops, but the PCB print tells me
something different.

PA2/PA3 is from the schematic.

But actually, I made a little typo in the comment in the pin-map file...
PA2 is TX2 and PA3 is RX2 where the comment would lead you to believe it's the other way around.

There is nothing forcing you to use one location over the other for GPS, OnStep doesn't care RX2/TX2 or RX3/TX3.

Dave Schwartz
 

P.S. You have to think about how you're going to package this so that someone could have a reasonably-sized box in the field. Prototyping boards or components scattered all around connected by oodles of Dupont wires going to headers all over the S6 is all fine and good on the bench... not so usable that way though.

On 2020-07-09 7:44 p.m., Dave Schwartz wrote:
For me it was just less complicated to connect the GPS to PC10 and PC11 on EXP1 (Serial3) with two wires into a connector I was already using rather than two new connectors into Y+ and Z+. The daughter board I am building is already cumbersome enough to connect and disconnect with 6 connectors (one to the middle and 5 on two edges) without adding another two in the middle.

On 2020-07-09 7:33 p.m., Howard Dutton wrote:
On Thu, Jul 9, 2020 at 02:17 PM, Markus Kempf wrote:

    I'm lost in finding the GPS TX/RX pins. The pinmap says RX2/TX2
    (PA2/PA3) is on the Y+ and Z+ end stops, but the PCB print tells me
    something different.

PA2/PA3 is from the schematic.

But actually, I made a little typo in the comment in the pin-map file...
PA2 is TX2 and PA3 is RX2 where the comment would lead you to believe it's the other way around.

There is nothing forcing you to use one location over the other for GPS, OnStep doesn't care RX2/TX2 or RX3/TX3.

Markus Kempf
 

FYSETC S6 amnesia

usually OnStep should remember the last used location, UTC offset and some other settings. Unfortunately this is not the case with my S6 setup. After every power cycle,  I have to set location and UTC offset again and switch on automatic meridian flip. Time setting with my RTC does work, although with the wrong UTC offset.

Since this morning and version 4.9l there is another bug. I can set the UTC offset to arbitrary values, the used value is always 1.

Site:
  7/10/20 08:55:21 UT (web browser)
  07/10/20 09:55:22 UT (05:46:10  LST)
  Long. = -008*55, Lat. = +48*43

config.h values

#define MFLIP_SKIP_HOME               ON //    OFF, ON Goto directly to the destination without visiting home position.      Option
#define MFLIP_PAUSE_HOME_MEMORY       ON //    OFF, ON Remember meridian flip pause at home setting across power cycles.     Option
#define MFLIP_AUTOMATIC_MEMORY        ON //    OFF, ON Remember automatic meridian flip setting across power cycles.         Option
 

Markus

Howard Dutton
 

On Fri, Jul 10, 2020 at 02:16 AM, Markus Kempf wrote:
Time setting with my RTC does work, although with the wrong UTC offset.
Remove the RTC and try again.

Markus Kempf
 

tried to enable the GPS module, that does not work yet, but the UTC offset works again.

Site:
  7/10/20 11:00:01 UT (web browser)
  07/10/20 11:00:01 UT (06:51:00  LST)
  Long. = -008*55, Lat. = +48*43

Markus

Am 10/07/2020 um 12:16 schrieb Howard Dutton:

On Fri, Jul 10, 2020 at 02:16 AM, Markus Kempf wrote:
Time setting with my RTC does work, although with the wrong UTC offset.
Remove the RTC and try again.

Howard Dutton
 
Edited

On Fri, Jul 10, 2020 at 04:01 AM, Markus Kempf wrote:
tried to enable the GPS module, that does not work yet, but the UTC offset works again.
So the RTC was messing with the S6's onboard EEPROM.

There was some confusion about this RTC module (with EEPROM of its own) working as being "something new"...

I suspect the code I recently added which validates what comes out of NV (EEPROM) allowed OnStep to work even with the EEPROM not functioning where before it would simply crash.  If you set DEBUG ON and watch the serial monitor I bet you'll see a bunch of errors at startup.  The errors are logged and values from NV that are out of range are brought back into range or set to defaults.  Eventually I'll add a flag to alert the user that something bad happened, not there yet.

Markus Kempf
 

Hi Howard,

I stripped of the RTC (TIME_LOCATION_SOURCE OFF, SDA/SCL removed, PPS, Vcc, GND still connected, PPSsync works) and the S6 regained its memory after a power cycle. So your assumption seems to be correct, the RTC eeprom messes up the memory handling.

I tried to enable the debug verbose output and used the Arduino Serial Monitor but did not saw any output. I can enter a command eg :GV?# and the output is:

MSG: CMD_CH_A "GV?1:GV?", Error {⸮G⸮P@

Markus

Am 10/07/2020 um 13:26 schrieb Howard Dutton:

On Fri, Jul 10, 2020 at 04:01 AM, Markus Kempf wrote:
tried to enable the GPS module, that does not work yet, but the UTC offset works again.
So the RTC was messing with the EEPROM.

There was some confusion about this EEPROM module working as being "something new"...

I suspect the code I recently added which validates what comes out of NV (EEPROM) allowed OnStep to work even with the EEPROM not functioning where before it would simply crash.  If you set DEBUG ON and watch the serial monitor I bet you'll see a bunch of errors at startup.  The errors are logged and values from NV that are out of range are brought back into range or set to defaults.  Eventually I'll add a flag to alert the user that something bad happened, not there yet.

Howard Dutton
 

On Fri, Jul 10, 2020 at 05:50 AM, Markus Kempf wrote:
MSG: CMD_CH_A "GV?1:GV?", Error {⸮G⸮P@
It's saying the command isn't recognized.

The {⸮G⸮P@ is a bug related to changing the debug mode #define form.  I fixed it:

MSG: CMD_CH_A "GV?", Error command unknown

It is correct in that you had a malformed command frame followed by a command that doesn't exist :GV?#, but framed properly.  The ? after GV gets filled with one of these:

// :GVD#      Get Telescope Firmware Date
//            Returns: MTH DD YYYY#
// :GVM#      General Message
//            Returns: s# (where s is a string up to 16 chars)
// :GVN#      Get Telescope Firmware Number
//            Returns: M.mp#
// :GVP#      Get Telescope Product Name
//            Returns: s#
// :GVT#      Get Telescope Firmware Time
//            Returns: HH:MM:SS#