Print

[TCWORLD]

This has now been released. Available from the downloads page.


Hi,

I'm preparing a new release of the AstroEQ firmware. Changes as follows:

Firmware:

• Fix major mistake in :f command handling - this should fix most INDIlib issues.
• Add support for TMC2100 (untested)
• Correct one of the DRV8825 microstep modes - this is probably why some were facing issues with the 8.03 release.
• Change configuration structure to include version number and CRC - this should help with future changes

Config Utility:

• Better handling of old or broken EEPROM data - Fixes an issue with upgrading from pre V8 firmwares (https://www.astroeq.co.uk/forum/index.php/topic,226.0.html)
• Handling of new config structure - will automatically update V8.x to new structure (reversible if downgrading from beta)
• Include options for TMC2100 Driver

The beta version is attached to this post - both for Windows (AstroEQUploader3.8(beta).zip) and for Debian Linux (astroequploader-3.8.0.zip).

If you are not in the middle of Astronomy stuff and could spare a moment to test that the new firmware works correctly with your mount, that would be great. If all goes according to plan you shouldn't notice any difference with your AstroEQ.


Update (19/10/2017)

I've uploaded a new version (attached). Found a major mistake when tracking down issues with INDILib.


Note for downgrading

The V8.10 firmware uses a slightly modified EEPROM structure. The changes have been designed to be as minimal as possible (only to header). As such downgrading is possible.
When you downgrade with the current release version of the config utility (3.7.3), upload the firmware and then it will detect the EEPROM as corrupt. Continue to the next step which will attempt to repair it. Once this step is complete and you get to the configuration screen, close the configuration utility. The EEPROM structure will now be back to how it was as functional.

[aletel]

Hello.
I have tried to upload the beta version 8.10 with AstroEQ-ConfigUtility-LINUX and it seems that everything is fine except the one thing. The odd behavior of the motor in Declination. Changes of different speed modes (1x, 2x, 4x, ... 700x) are OK in different micro step setups (8/16/32), but during start of the pointing calibration, the DEC reacts to a short pulse by switching to full speed, so that the star jumps out of picture after the first iteration.
Similar to it the ST4 pulses for DEC goes at full speed. For this reason, I can not use correction for the DEC axis during photo session. This behavior is identical and tested on 3pcs of the Arduino Mega 2560 even on the recently purchased AstroEQ PCB + IC, DRV8825 (tested modified for smoother operation, even without modification). I notice this problem from the version 8.x. In previous versions of 7.x everything was fine and it worked entire season. I use AstroEQ for remote control of homemade mount in KStars configuration (INDI, EKOS, EQMOD on Linux, and Raspberry PI3) and I can not currently realize where the error is.

Thanks, Aletel

[TCWORLD]

@Aletel,

What happens if you try to slew DEC at a speed < 1x in EQMOD?

[aletel]

The RA engine at W / E Rate <1 (0.1, 0.25, 0.5, 0.75) responds correctly, DE motor N / S Rate runs briefly at full speed.

I am sorry for my English....

[TCWORLD]

Could you save your config from the utility and add here as an attachment to a post.

I can't seem to reproduce the problem with EQMOD.

Although given you mentioned Linux I presume you are trying with INDI? I'll have to set up something to test that.

[TCWORLD]

Right, so I've been trying to track down where the issues are arising with INDILib.

I believe I have found the culprit and corrected it. I've uploaded a new version to the first post of this thread.


For those that were interested, basically this has been an issue for 5 years. Yes, 5 years. Since AstroEQ first came in to existence. The information I was using to determine the correct response to the motor status report (:f command) was flawed. This meant that two of the status flags were swapped and inverted.

Interestingly because EQMOD doesn't take full notice of these flags, and the fact that the flags had inverted meaning it never caused a problem. INDILib on the other hand has over time become more responsive to these flags, and the mistake now causes it a world of confusion.

Problems that arise include:

• Tracking not working after initialisation before a go-to movement is performed
• Speeds are incorrectly sent in some scenarios (possibly causing the DEC motor rate issue under guiding)
• Motion commands occasionally getting missed is some scenarios
• Parking/Unparking issues (possibly)

[aletel]

Hi Tom,
(sorry translator)
I uploaded a new version of 8.11 (beta).

There is a change in behaviour, but there is still a problem with the DEC engine in star simulation calibration mode - setting the 5x iterative RA W / E perfectly. Attempting to calibrate the DE S / N, stepper motor is only one repetition (S) and rotates 360 ° quickly, then turn direction (N) again by 360 °. In the simulator, the star returns to the point and the calibration is fine, but then the reaction star, the engine responds with too much correction (again the star outside the image).

I attach my screen with settings and .config.

Thank you Tom = Sherlock Holmes - for search, dedicated time and revealed case with INDI project.

[gehelem]

Hi

so i've made a quit test with my TMC2100
(OMG everybody should try them ! they are so smooth !!)
Uploader gives a few bugs (linux version)
when clicking on "update", error message :

Code: [Select]

------ DC Axis Update ------
Step Angle: 1.8
Motor Gear Ratio: 2.666666667
Worm Gear Ratio: 144
Oct 19, 2017 9:35:15 PM controlP5.ControlBroadcaster printMethodError
SEVERE: An error occured while forwarding a Controller event, please check your code at controlEvent
java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at controlP5.ControlBroadcaster.invokeMethod(Unknown Source)
at controlP5.ControlBroadcaster.broadcast(Unknown Source)
at controlP5.Controller.broadcast(Unknown Source)
at controlP5.Button.setValue(Unknown Source)
at controlP5.Button.activate(Unknown Source)
at controlP5.Button.mouseReleased(Unknown Source)
at controlP5.Controller.setMousePressed(Unknown Source)
at controlP5.ControllerGroup.setMousePressed(Unknown Source)
at controlP5.ControllerGroup.setMousePressed(Unknown Source)
at controlP5.ControlWindow.mouseReleasedEvent(Unknown Source)
at controlP5.ControlWindow.mouseEvent(Unknown Source)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at processing.core.PApplet$RegisteredMethods.handle(PApplet.java:1408)
at processing.core.PApplet.handleMethods(PApplet.java:1603)
at processing.core.PApplet.handleMouseEvent(PApplet.java:2695)
at processing.core.PApplet.dequeueEvents(PApplet.java:2618)
at processing.core.PApplet.handleDraw(PApplet.java:2429)
at processing.awt.PSurfaceAWT$12.callDraw(PSurfaceAWT.java:1540)
at processing.core.PSurfaceNone$AnimationThread.run(PSurfaceNone.java:316)
Caused by: java.lang.IndexOutOfBoundsException: Index: 4, Size: 4
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at controlP5.ScrollableList.getItem(Unknown Source)
at AstroEQUploader$GUIScreen.getScrollableListItem(AstroEQUploader.java:1737)
at AstroEQUploader$GUIScreen.getScrollableListItem(AstroEQUploader.java:1726)
at AstroEQUploader$GUIScreen.getScrollableListItem(AstroEQUploader.java:1721)
at AstroEQUploader$UploaderGUI.getMicrostepMode(AstroEQUploader.java:2263)
at AstroEQUploader$UploaderGUI.controlEvent(AstroEQUploader.java:2825)
at AstroEQUploader.controlEvent(AstroEQUploader.java:561)
... 24 more

I've tried without gearchanging option, it looks to work quite well
With option it's KO : motors are too slow...
Need more testing to give more feedback, of course

but thank you again for the good job

Gilles.

[gehelem]

...
i think my error on uploader was because of loading old config files...
With "legacy" ones, there is no such problem.

[TCWORLD]

Is there a specific value of microstep mode that causes the config utility to give that error?

I can work out where in the code it is crashing from the trace, but can't seem to figure out both why it would be doing it, nor how to replicate it.

I'll look in to the gearchanging thing again - seems to be something there that I can't spot. By "motors are too slow", how slow is too slow (roughly), and under what conditions? (high speed movements? low speed movements? go-tos?).

[gehelem]

uploader : no more errors since i'm using new config files
usteps = always 1/16
motors were too slow when doing a fast goto
i'm sure it's because my conf was not loaded properly
Let me do more tests

Gilles

[gehelem]

more details :
when i use TMC2100 / 16usteps with gear changing i think movements are 8x too small (might be 10x or 6x...)

[TCWORLD]

Do you have a multimeter? If so, could you measure the voltage on the mode select pins after performing a high speed movement. I want to make sure the mode select pins were set to the correct values.

[gehelem]

Sorry !
I've just realized i've removed config pins of drivers to act in shopper mode...
I will put them back tomorrow and try again
Gilles

[gehelem]

well :
config pins are back on the board (sorry again for that)
i still have this problem of "not enough move" when i set gear changing in eeprom

i went back to "no gear change"
movements seem ok
but i see no difference with my multimeter on config pins if motor are stopped or if they are x800
I read only a few mV