Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
1
General Discussion / Re: On start up my AstroEQ tries to drive the DEC axis more than a full circle
« on: September 05, 2024, 21:28:35 »
If you park the AstroEQ, disconnect and power down, then power up, reconnect and unpark, does it work correctly? i.e. the EQMOD reconnects with the mount knowing where it was before.
I'm not sure how EQMOD stores the parked position, but at a rough guess it stores the raw encoder values. If that is the case and you then use and park the other mount, then unless EQMOD stores different park positions for each mount (don't know if it does), the encoder values would make no sense to the other mount and result in it thinking it was somewhere completely different.
For reference the encoder values are not in degrees, but rather a number of micro steps of the motor - so mounts with different gear ratios etc. would have effectively completely different unit sizes.
I'm not sure how EQMOD stores the parked position, but at a rough guess it stores the raw encoder values. If that is the case and you then use and park the other mount, then unless EQMOD stores different park positions for each mount (don't know if it does), the encoder values would make no sense to the other mount and result in it thinking it was somewhere completely different.
For reference the encoder values are not in degrees, but rather a number of micro steps of the motor - so mounts with different gear ratios etc. would have effectively completely different unit sizes.
2
General Discussion / Re: On start up my AstroEQ tries to drive the DEC axis more than a full circle
« on: September 04, 2024, 23:09:37 »
Which versions are you using (AstroEQ firmware, EQMOD), and what is your mount config?
3
General Discussion / Re: Astroeq problem has stopped working
« on: April 17, 2024, 22:56:29 »
Looks like something must have shorted out the motor connector and killed the old driver board.
If you have a multimeter, probably worth doing a continuity check on each of the connector pins to make sure they are still connected.
Does the RA motor make any sound (humming/buzzing) or is it completely silent?
If you plug the RA motor into the DEC connector (and vice versa) is it still the RA connector that is non-functional?
If you have a multimeter, probably worth doing a continuity check on each of the connector pins to make sure they are still connected.
Does the RA motor make any sound (humming/buzzing) or is it completely silent?
If you plug the RA motor into the DEC connector (and vice versa) is it still the RA connector that is non-functional?
4
General Discussion / Re: No motor movement with 8.20-21 firmware
« on: February 08, 2024, 22:45:47 »
I'd already packaged up 8.21, just never got around to merging the branch to master as I have little free time with my current job. So the plan is to simply abandon the 8.21 version and release the fixes as 8.22 (just in case anyone else has 8.21 flashed).
There are a couple other changes and a bit of tidying up to include in the new one, I just need to get a chance to test them.
There are a couple other changes and a bit of tidying up to include in the new one, I just need to get a chance to test them.
5
General Discussion / Re: No motor movement with 8.20-21 firmware
« on: February 04, 2024, 16:54:59 »
There's a new branch here: https://github.com/TCWORLD/AstroEQ/tree/dev-v8p22
Could you see if that fixes things?
Could you see if that fixes things?
6
General Discussion / Re: No motor movement with 8.20-21 firmware
« on: February 04, 2024, 16:31:13 »
Found the issue.
I added proper error code responses to the firmware (e.g. `!03\r` instead of just `!\r`) in order to support the Skywatcher hand controllers. But the config utility is not expecting them (it is looking for specifically `!\r` instead of just any string starting with `!`). As a result it doesn't see the response from the AstroEQ indicating the EEPROM is blank/corrupt, and so never reinitialises it.
This then means the version and ID is not written to the start of the EEPROM (hence read back as 255), and so the AstroEQ assumes it is blank and doesn't boot to protect the mount.
I'll push an updated version of the firmware shortly.
I added proper error code responses to the firmware (e.g. `!03\r` instead of just `!\r`) in order to support the Skywatcher hand controllers. But the config utility is not expecting them (it is looking for specifically `!\r` instead of just any string starting with `!`). As a result it doesn't see the response from the AstroEQ indicating the EEPROM is blank/corrupt, and so never reinitialises it.
This then means the version and ID is not written to the start of the EEPROM (hence read back as 255), and so the AstroEQ assumes it is blank and doesn't boot to protect the mount.
I'll push an updated version of the firmware shortly.
7
General Discussion / Re: No motor movement with 8.20-21 firmware
« on: February 04, 2024, 11:24:35 »
Need to see what the software actually wrote to the EEPROM as opposed to what the config utility told it to write. There is an Arduino demo program that will dump the whole EEPROM contents to the serial console here: https://docs.arduino.cc/learn/programming/eeprom-guide/#eeprom-read
8
General Discussion / Re: No motor movement with 8.20-21 firmware
« on: February 04, 2024, 01:36:52 »
Right, so that's very weird. The mount responding to the `:F1` command with `!04` means that it is in programming mode, not run mode. As a result it won't enable the motors (a protection feature when using the config utility).
There are only two ways of entering programming mode, sending `:O2` twenty times (which isn't happening), or otherwise failing to read its EEPROM (e.g. if corrupt or blank). Would you be able to run the Arduino "eeprom_read" sketch to dump the contents of the EEPROM, and upload the result here?
There are only two ways of entering programming mode, sending `:O2` twenty times (which isn't happening), or otherwise failing to read its EEPROM (e.g. if corrupt or blank). Would you be able to run the Arduino "eeprom_read" sketch to dump the contents of the EEPROM, and upload the result here?
9
DIY AstroEQ / Re: Issue with Oblong Stars, maybe RA axis?
« on: January 30, 2024, 09:48:21 »
Sounds like it might be either a balancing or binding issue, or possibly the motors not having enough torque.
What is most likely happening is the micro-stepping doesn't have enough power to move the mount for a few micro-steps. Then once it moves close to the next half step, it jumps into position. That would cause jumps of up to 9 arc-seconds. Essentially as if the micro-stepping were not being done.
I'd start with a quick double check the mount is free-moving on the worm (not too tight) and that the scope it is well balanced. After that make sure that the stepper drivers have the current limit properly adjusted as under or over current can cause micro-stepping issues.
What is most likely happening is the micro-stepping doesn't have enough power to move the mount for a few micro-steps. Then once it moves close to the next half step, it jumps into position. That would cause jumps of up to 9 arc-seconds. Essentially as if the micro-stepping were not being done.
I'd start with a quick double check the mount is free-moving on the worm (not too tight) and that the scope it is well balanced. After that make sure that the stepper drivers have the current limit properly adjusted as under or over current can cause micro-stepping issues.
10
General Discussion / Re: No motor movement with 8.20-21 firmware
« on: January 21, 2024, 11:00:49 »
Could you follow the instructions here:
https://www.astroeq.co.uk/forum/index.php/topic,141.msg946.html#msg946
(You may need the new version of SerialEcho, attached to this post: https://www.astroeq.co.uk/forum/index.php/topic,275.msg1941.html#msg1941)
This should give a log of communications between EQMOD and the AstroEQ which will help debug communications problems.
https://www.astroeq.co.uk/forum/index.php/topic,141.msg946.html#msg946
(You may need the new version of SerialEcho, attached to this post: https://www.astroeq.co.uk/forum/index.php/topic,275.msg1941.html#msg1941)
This should give a log of communications between EQMOD and the AstroEQ which will help debug communications problems.
11
General Discussion / Re: No motor movement with 8.20-21 firmware
« on: December 27, 2023, 11:14:14 »
Right, so this is a custom pinout.
I see that you are using pins 30-37. As per the Arduino Mega schematic, these 8 pins must NOT be used.
The registers that drive them are being used as fast access register flags in the interrupt routines (the 2560 lacks the general registers that the 162 has, so I had to get creative).
So the GPIO pins are going to be messed around with, which may cause weird mis-detection of hand controllers, as is the direction pin for the RA axis.
Also, how are you compiling the custom firmware? I've only tested with Atmel Studio 7. The Arduino IDE does all sorts of weird preprocessing so I have no idea whether that will work.
Is there any particular reason why you are using a custom pinout rather than the tried and tested one?
I see that you are using pins 30-37. As per the Arduino Mega schematic, these 8 pins must NOT be used.
The registers that drive them are being used as fast access register flags in the interrupt routines (the 2560 lacks the general registers that the 162 has, so I had to get creative).
So the GPIO pins are going to be messed around with, which may cause weird mis-detection of hand controllers, as is the direction pin for the RA axis.
Also, how are you compiling the custom firmware? I've only tested with Atmel Studio 7. The Arduino IDE does all sorts of weird preprocessing so I have no idea whether that will work.
Is there any particular reason why you are using a custom pinout rather than the tried and tested one?
12
General Discussion / Re: No motor movement with 8.20-21 firmware
« on: December 27, 2023, 00:34:32 »
What is the status LED doing on the board when it is not responding to EQMOD?
I've attached a debug version of the config utility. Could you attach the console output from when writing the configuration.
I've attached a debug version of the config utility. Could you attach the console output from when writing the configuration.
13
General Discussion / Re: No motor movement with 8.20-21 firmware
« on: December 25, 2023, 00:09:10 »
Can you confirm that your board matches the schematic here, including the 1k resistor (R21) between Arduino digital pins D21 and D23?
14
DIY AstroEQ / Re: TB6600 Driver
« on: September 24, 2023, 01:43:32 »
I've not tried it, but it should be possible to use this stepper driver.
The pulse (step), direction, and enable signals can be connected to the ATMega/Arduino directly. The following connections should work:
Connect the following TB6600 pins to the following nets in the AstroEQ ATMega162 or Arduino Mega schematics.
In the AstroEQ configuration utility, select the DRV8825 option from the dropdown, and set the microstep level as per the settings you selected on the TB6600 DIP switches, and ensure the "uStep Gear Changing" option is set to disabled.
The pulse (step), direction, and enable signals can be connected to the ATMega/Arduino directly. The following connections should work:
Connect the following TB6600 pins to the following nets in the AstroEQ ATMega162 or Arduino Mega schematics.
- "Pulse-" -> "Step"
- "En+" -> "En"
- "Dir-" -> "Dir"
- "Pulse+" -> +5V
- "Dir+" -> +5V
- "En-" -> GND
In the AstroEQ configuration utility, select the DRV8825 option from the dropdown, and set the microstep level as per the settings you selected on the TB6600 DIP switches, and ensure the "uStep Gear Changing" option is set to disabled.
15
DIY AstroEQ / Re: Change code to support LV8729 1/64 microstepping for mega2560
« on: May 22, 2023, 21:46:14 »
Welcome to the wonderful world of integer precision 
The values in the synta protocol are maximally 24bit, which limits them to circa 16million. This is unfortunately not something I can control - increasing the size would only be possible by changing the protocol and all programs which speak it.
There are also other considerations as well. As these numbers get larger, the step rate gets higher and higher. There reaches a point where the MCU simply cannot keep up. In hindsight using multiple MCUs (one for each motor, plus a main controller) would probably helped here, but the goal of AstroEQ was to make non-Goto mounts able to talk to the PC as simply as possible.
Both of these are the reason why I never added 64 ustep modes to the firmware - it's really beyond the capabilities of the controller, and precision can be better acheived using higher gear ratios.
The values in the synta protocol are maximally 24bit, which limits them to circa 16million. This is unfortunately not something I can control - increasing the size would only be possible by changing the protocol and all programs which speak it.
There are also other considerations as well. As these numbers get larger, the step rate gets higher and higher. There reaches a point where the MCU simply cannot keep up. In hindsight using multiple MCUs (one for each motor, plus a main controller) would probably helped here, but the goal of AstroEQ was to make non-Goto mounts able to talk to the PC as simply as possible.
Both of these are the reason why I never added 64 ustep modes to the firmware - it's really beyond the capabilities of the controller, and precision can be better acheived using higher gear ratios.