294 replies to this topic

[PeterKom]

To me this looks like backlash (elasticity or belt?) in DEC coupled with overcorrection. You are using the Z-filter algorithm for DEC, which is basically Hysteresis algorithm with Aggression 100%. That seems an unusual choice. If not, switch DEC to ResistSwitch, aggression 60%. Disable backlash compensation for now. See how it goes. For RA Avalon recommends the Lowpass2 algorithm:

https://www.avalon-i...sted-parameters

Thanks, have also tried Lowpass2 and the story was very simmilar. I will try again on the next clear night.

[PeterKom]

Hi Peter, it doesn't look like your file attached.

 

As to the question about the cold, I highly doubt that is a factor. I have used my M-Zero in temperatures close to that and it did fine. Even if it performed slightly worse in cold I doubt the DEC graph would be so choppy (can't see your latest graph, but going by the last one). The mount performs very poorly in wind though, at least with a long-focal length instrument. But again I would not expect that even with wind only the DEC would display such odd behavior.

 

I assume you've emailed Stefano about this?
 

Thanks, Ok I see your from New Jersey so the temperatures should be simmilar in winter There was also no wind on this cold nights...but as you say also a slight breeze would affect both graphs not just the DEC.
I have e-mail Stefano about this yes, but is was already Friday night so I will need to wait a bit for the answer.

[PeterKom]

Definitely contact Stefano about this one, it's a puzzler.

Plus you really need to get a PHD2 graph with no guiding so we can totally eliminate that as the issue. Also needs a reasonably long run. Runs of less than 2 minutes don't really tell us anything. 

You could also try running PHD2 without guiding but using the imaging scope to eliminate any issue with the guide scope.

The most worrying part is the large oscillation in Dec which should normally not move at all. It has a period of around 20s. But it does not show up in the calibrations. 

There is also a slight drift in RA which could be normal Avalon drift but it looks larger than usual.

The calibrations look OK but there are some oddities like the RA leg not fully returning to the start position. Also, the calculated RA rates differ from the rates set in the mount more than I'd expect

Next time you calibrate, turn off the PHD2 option for "fast recenter after calibration or dither" 

 

You may need to see if StarGo logs what it is doing. It might be in the ASCOM log. But I don't use ASCOM anymore.

Thanks Ken. The first thing i will do is check out the guiding assistant. Maybe the issue is really something else. The only thing i can think about are the spacers between the tube and the Losmandy plate. They were produced by my friend on a CNC machine (i have ordered those at Primaluce but were not available at that time).  Because i use Sharpcap to Polar allign I don't know if the OTA is fully parallel to the polar axis of the mount. It should be because the two 30 mm spacers were produced in the same batch. Everything else (leveling, balance, ...) is fine.

[KenS]

To me this looks like backlash (elasticity or belt?) in DEC coupled with overcorrection. You are using the Z-filter algorithm for DEC, which is basically Hysteresis algorithm with Aggression 100%. That seems an unusual choice. If not, switch DEC to ResistSwitch, aggression 60%. Disable backlash compensation for now. See how it goes. For RA Avalon recommends the Lowpass2 algorithm:

https://www.avalon-i...sted-parameters

I don't see any sign of backlash or overcorrection in the log. The corrections are considerably smaller than the deviations. And Z-filter is most certainly not Hysteresis with 100% aggression. I wrote it specifically with the M-Uno in mind because the LowPass2 is a bit of a hack of an algorithm. 

In normal use there is effectively no dec backlash with the Avalon mounts so using Resist switch is counterproductive. If its needed then there is a fault in the mount.

In addition to the guide log it would be useful to see all the Stargo settings. Also, what else is running. The screenshot with the StarGo virtual handset shows that 3 clients are connected. It could be possible that one is sending rogue commands to the mount that PHD2 is unaware of. Its a long shot but this is such an unusual case its worth considering.

[Rasfahan]

I don't see any sign of backlash or overcorrection in the log. The corrections are considerably smaller than the deviations. And Z-filter is most certainly not Hysteresis with 100% aggression. I wrote it specifically with the M-Uno in mind because the LowPass2 is a bit of a hack of an algorithm. 

In normal use there is effectively no dec backlash with the Avalon mounts so using Resist switch is counterproductive. If its needed then there is a fault in the mount.

In addition to the guide log it would be useful to see all the Stargo settings. Also, what else is running. The screenshot with the StarGo virtual handset shows that 3 clients are connected. It could be possible that one is sending rogue commands to the mount that PHD2 is unaware of. Its a long shot but this is such an unusual case its worth considering.

Sorry, you probably know more about this than I do. But the guide log shows clear oscillation in DEC, which I see when the backlash compensation overcorrects (the Mesu mount also has no backlash and I had to turn it off). The documentation of the z-filter algorithm states:

 

“For example, an exposure time of 1s with Exposure Factor of 4 gives a virtual expsoure time of 4s (4 x 1s) and performs similarly to Hysteresis with Agression 100% and Hysteresis 0.0 using an exposure time of 4s. An exposure time of 2s with an Exposure Factor of 2 also has a virtual exxpsoure time of 4s (2 x 2s) and thus performs much the same.”

 

That is what I was referring to.

 

If the mount oscillates and the guiding settings are as recommended for the Avalon, I would just send the mount back to exchange for a refund. Having to install a beta driver to get it working at all seems a red flag. Let the manufacturer work out the bugs of their design, QC and driver and sell a finished product when they are ready. 

[PeterKom]

I don't see any sign of backlash or overcorrection in the log. The corrections are considerably smaller than the deviations. And Z-filter is most certainly not Hysteresis with 100% aggression. I wrote it specifically with the M-Uno in mind because the LowPass2 is a bit of a hack of an algorithm. 

In normal use there is effectively no dec backlash with the Avalon mounts so using Resist switch is counterproductive. If its needed then there is a fault in the mount.

In addition to the guide log it would be useful to see all the Stargo settings. Also, what else is running. The screenshot with the StarGo virtual handset shows that 3 clients are connected. It could be possible that one is sending rogue commands to the mount that PHD2 is unaware of. Its a long shot but this is such an unusual case its worth considering.

Hi, today will be no testing due to overcast weather. But regarding none guided tracking I can tell from my previous experience with the CEM25P and now the M-Uno that when slewing and syncing to a star, the star drifts quite fast from center compared to my CEM25p. So this was the first thing I noticed and got me thinking why this is the case on such a expensive mount. Then I read that this mount is meant to be guided and I tough OK then the bad unguided tracking is nothing to worry about. But now I'm not sure anymore. How is your mount performing unguided?

[KenS]

Hi, today will be no testing due to overcast weather. But regarding none guided tracking I can tell from my previous experience with the CEM25P and now the M-Uno that when slewing and syncing to a star, the star drifts quite fast from center compared to my CEM25p. So this was the first thing I noticed and got me thinking why this is the case on such a expensive mount. Then I read that this mount is meant to be guided and I tough OK then the bad unguided tracking is nothing to worry about. But now I'm not sure anymore. How is your mount performing unguided?

The gearing of the Avalon means it has a slow, irregular drift which I've seen going up to 100" but over 20 minutes or more. So it guides out very easily especially as it is smooth. From the very short runs in your guide log there is a much higher drift getting up to 20" per minute on one run. Still not huge but more than I'd expect. Given that StarGo supports many different mounts and has configurable stepper rates, it may even be that yours is configured incorrectly for the M-Uno.

See if you can dig out the .MCF file that you load into StarGo. It is where the StarGo software is installed. You might want to edit out your lat/lon but I could compare the settings to my own to see if anything jumps out. Also see if you can dig up any ASCOM logs for the StarGo

[KenS]

Sorry, you probably know more about this than I do. But the guide log shows clear oscillation in DEC, which I see when the backlash compensation overcorrects (the Mesu mount also has no backlash and I had to turn it off). 

Yes there is a clear dec oscillation but there is the backlash compensation in PHD2 is disabled and it does not exist in the StarGo driver. The strange normalised guide rates do make me wonder if the Uno configuration has gone awry. If the motor controller moves more than PHD2 expects that would lead to an overcompensation effect. One thing in the debug log that caught my mind is that StarGo is erratic in reporting when it is guiding. Sometimes not responding and other times responding early. The suggests a possible intermittent comms issue. Maybe the guide commands are being held up somewhere and being applied late. Whatever is happening it is competely out of the ordinary.

 

The documentation of the z-filter algorithm states:

 

“For example, an exposure time of 1s with Exposure Factor of 4 gives a virtual expsoure time of 4s (4 x 1s) and performs similarly to Hysteresis with Agression 100% and Hysteresis 0.0 using an exposure time of 4s. An exposure time of 2s with an Exposure Factor of 2 also has a virtual exxpsoure time of 4s (2 x 2s) and thus performs much the same.”

 

That is what I was referring to.

Thats a highly simplified description to explain how to use the exposure factor. The key thing is that even with 1s exposures, the guiding responds similarly to the hysteresis algo with 4s exposures. Aggression and hysteresis with 4s exposures are less critical at 4s compared to 1s. In this specific case the Lowpass2 algo would actually be worse due to the large deviations that would reset its buffer and make it work more like hysteresis with 100% aggression and 1s exposures.

[OzAndrewJ]

Gday Ken

This almost looks like what happened in some IOptrons,

ie do a DEC cal then get bad oscillations with delays in application.

The one big difference is in the IOptrons, during the cal, the mount ran at maybe 1/5th the expected rate

which meant PHD massively undercalculated the real rate so overcalculated the pulses required.

 

If the motor controller moves more than PHD2 expects that would lead to an overcompensation effect.

In this case, during the cal for DEC, the mount ran at 2x the expected speed. ( thus giving a calculated rate 2x expected )

According to the PHD log data, when it started to oscillate, the mount was actually moving 5x the actual distance ( assuming the mounts guide speed was correct ). It should have been way less if it was simple calculation as at this speed, the calculated pulses should have been much smaller ?????

 

Maybe the guide commands are being held up somewhere and being applied late.

It certainly looks that way when oscillating, but it doesnt explain the massive movement vs requested.

 

Have attached 2 plots

One shows the RA then DEC cal sections, followed by the DEC oscillating.

You can see during the cal, it went 2x expected but when oscillating, it went 5x expected?????

The second is a closeup of the oscillation showing how the real DEC was still changing,

well after the last pulse was sent. ( It in no way accounts for the amplitude errors )

No idea whats happening downstream of PHD, you would need to see the comms to the mount

to see if something else is affecting the data being sent from PHD

Andrew Johansen Melbourne Australia

 

 

 

 

 

[Starhawk]

I'll go ahead and ask- are there objects close to the pole you're particularly interested in imaging?  That area's kind of a dead zone for the most part.

 

-Rich 

[KenS]

@ozAndrew thats pretty much how I'm seeing it. Now the StarGo software is designed to work with a large number of mounts so the gear ratio is configurable. For the M-Uno it should be 705.883 but if the M-zero config file is loaded accidentally the gear ratio gets set to 385.027. And if the M-Zero AZ file is loaded then the mount goes into Alt-Az mode and tracking moves both RA and Dec axes. Not saying that's definitely the problem but its worth investigating. The other is to somehow find out what happens downstream of PHD2 - that's where I hope an ASCOM log would help. If not then we'd need to see if @PeterKom can somehow set up an INDI based system to log what is going to the mount and when.

[KenS]

I'll go ahead and ask- are there objects close to the pole you're particularly interested in imaging?  That area's kind of a dead zone for the most part.

 

-Rich 

I don't understand why you are asking this. Who is talking about imaging at the pole?

[OzAndrewJ]

Gday Ken
 

For the M-Uno it should be 705.883 but if the M-zero config file is loaded accidentally the gear ratio gets set to 385.027.

Maybe, but that doesnt explain why the pulses sent during the Cal phase went approx 2x further than expected

but after that, they went 5x farther than they should????

ie whatever happens internally to calc the pulse is irrelevant here,

Its just a simple calc of  pulse time(ms)  * guide rate(arcsec/ms)    calc,

I know why it happens in the IOptron ( as it doesnt change speeds/distance, it just delays application )

but this is totally odd as to why the relative dist changes.

 

Maybe the firmware was written by the same people who wrote VWs code

ie when it knows its being calibrated, it behaves differently

 

Andrew Johansen Melbourne Australia

[KenS]

There are lots of other config files - all with different gear ratios. The StarGo is a stepper controller so it takes whatever pulse length input and uses the gear ratio and nominated guide rate to decide how many steps to add or skip and controls the motor directly. But indeed, you would expect that to be consistent. Whatever it is, something is happening that PHD2 is unaware of.

The main thing in my mind is not necessarily to solve the problem but to gather enough data to see if the mount needs to be returned and show it is not just "user error". That means eliminating other possible causes. Right now I'd say too many confounding variables and not enough data.

[OzAndrewJ]

Gday Ken

That means eliminating other possible causes. Right now I'd say too many confounding variables and not enough data

Agreed.

Thats why we ended up making dedicated scripts to test the IOPtrons.

We still used PHD ( and commander ) to log positions, but used scripted commands to the mount

as that allowed us to control pulse size and time delays, to test for backed up commands etc.

Trying to decipher normal PHD log results by themselves was simply too erratic.

 

Andrew Johansen Melbourne Australia

[PeterKom]

There are lots of other config files - all with different gear ratios. The StarGo is a stepper controller so it takes whatever pulse length input and uses the gear ratio and nominated guide rate to decide how many steps to add or skip and controls the motor directly. But indeed, you would expect that to be consistent. Whatever it is, something is happening that PHD2 is unaware of.

The main thing in my mind is not necessarily to solve the problem but to gather enough data to see if the mount needs to be returned and show it is not just "user error". That means eliminating other possible causes. Right now I'd say too many confounding variables and not enough data.

I have checked the Guiding Assistnat today. The weather was nearly clear with high altitude fog so seeing was constant and cold was also constant
Below the link to the lates log.
After a couple of minutes of guiding I turned on Guidnig Auto Adjustment to see if there is some difference but there was none realy. DEC was all over the place what ever I did. I did not lasted long outside becasue it was freaking cold and doing this kind of test in freezing -8 degrees celsius is going slowly on my nerves. And Avalon did again not respond... I hope we will get to the bottom of this soon.

Attached also the G.A. results. I was not sure if those are included in the log.

I also checked the StarGO configuration file and all seams fine to me. Attached the file.

Log:
https://openphdguidi...2_logs_aS6s.zip

 

Thanks in advance!

Attached Thumbnails

• 
• 

Attached Files

•  User.zip   1.76KB   2 downloads

[OzAndrewJ]

Gday Peter

The new data is still truly weird.

When you did the GA, you had clear PE in RA and a flat ( but drifting ) line for DEC.

You then did the DEC lash test, and once more, the mount appears to go at 2x the commanded rate.

What is very interesting tho is how the distance moved for a common pulse seems to alternate ( massively )

on every second pulse???

for Ken

( following is an extract from the debug log to show the extreme variability in reported moves for common pulses )
 

22:25:10.977 BLT: Entering DecMeasurementStep, state = 0

22:25:10.977 //* =========== Start DEC Lash Test ===========
22:25:11.485 MoveAxis(N, 1357, -) //           ( expect 8.164arcsec
22:25:11.484 Star::Find  X=89.03, Y=344.83 //  dDEC =  -0.733"
22:25:14.824 MoveAxis(N, 1357, -) //           ( expect 8.164arcsec
22:25:14.823 Star::Find  X=88.23, Y=344.87 //  dDEC =  -2.582"
22:25:18.407 MoveAxis(N, 1357, -) //           ( expect 8.164arcsec
22:25:18.404 Star::Find  X=79.71, Y=344.75 //  dDEC = -27.413"
22:25:21.758 MoveAxis(N, 1357, -) //           ( expect 8.164arcsec
22:25:21.756 Star::Find  X=77.43, Y=344.82 //  dDEC =  -7.351"
22:25:25.325 MoveAxis(N, 1357, -) //           ( expect 8.164arcsec
22:25:25.323 Star::Find  X=68.61, Y=344.80 //  dDEC = -28.394"
22:25:28.680 MoveAxis(N, 1357, -) //           ( expect 8.164arcsec
22:25:28.678 Star::Find  X=66.44, Y=345.05 //  dDEC =  -7.023"
22:25:32.250 MoveAxis(N, 750,  -) //           ( expect 4.512arcsec
22:25:32.249 Star::Find  X=57.06, Y=344.91 //  dDEC = -30.179"
22:25:34.995 MoveAxis(N, 750,  -) //           ( expect 4.512arcsec
22:25:34.993 Star::Find  X=54.99, Y=344.74 //  dDEC =  -6.640"
22:25:37.954 MoveAxis(N, 750,  -) //           ( expect 4.512arcsec
22:25:37.952 Star::Find  X=51.38, Y=344.80 //  dDEC = -11.631"
22:25:40.712 MoveAxis(N, 750,  -) //           ( expect 4.512arcsec
22:25:40.710 Star::Find  X=49.63, Y=344.80 //  dDEC =  -5.634"
22:25:43.670 MoveAxis(N, 750,  -) //           ( expect 4.512arcsec
22:25:43.668 Star::Find  X=45.72, Y=344.03 //  dDEC = -12.476"
22:25:46.417 MoveAxis(N, 750,  -) //           ( expect 4.512arcsec
22:25:46.416 Star::Find  X=44.01, Y=344.36 //  dDEC =  -5.554"

 

 

You then did a cal that appeared to work reasonably well ( and gave results that matched the beginning )

and in this case, the DEC appears to have moved almost as requested ( tho with odd spacings per pulse ).

Whats weird is the RA never came back the full distance ( possibly due to PE )

but the DEC returned to zero well before expected.

 

It then started guiding in DEC reasonably, but at a set point,

it got a larger error and then swapped into large oscillations.

The 2 interesting bits here are when it went into large oscillations, it also lost the underlying linearity of the DEC drift

almost as if some pulses have got lost????

Looking closely at the oscillations, you can also see that when they start, the pulses sent to fix them

appear to get ignored?? ( ie Kens theory they are being stacked up somewhere )

This stack up error is whaht we saw in the early IOptron firmwares.

Truly weird

Andrew Johansen Melbourne Australia

 

Full run showing GA, then DEC lash, then Cal, then guiding

Lash Test

Calibrate

Guiding

DEC wobble

[KenS]

The unguided graph is just what I'd expect from an Avalon mount - maybe a bit more RA drift than I've seen. But I think we can eliminate the mount hardware itself as an issue.

The guiding with LowPass2 has the same 20s oscillation as Z-filter so it is not the algorithm or PHD2. Notice how with LowPass2 it is operating like a Hysteresis with 90% aggression and NO hysteresis. This is due to the hack I mentioned earlier where it ceases to be a low pass filter.

I compared your MCF files with mine. Mine has Dec reversal OFF whilst yours is ON. This should not cause a problem as calibration would sort it out. But may be worth trying anyway.

BAsed on Andrew's analysis the only thing I can think of that could hold up the commands is the FTDI chip or the firmware

@PeterKom do you have access yet to the Avalon support forum? Definitely post there with the guide log to show the issue. If you don't have access, I could post on your behalf

 

Edit: I can see your username in teh members list since Jan-15. Check your spam in case the welcome email was diverted. Also, you need to log in at the main support page https://www.avalon-i...pport-2/support then go to the forum from the menu. 

Edited by KenS, 18 January 2021 - 10:56 PM.

[PeterKom]

The unguided graph is just what I'd expect from an Avalon mount - maybe a bit more RA drift than I've seen. But I think we can eliminate the mount hardware itself as an issue.

The guiding with LowPass2 has the same 20s oscillation as Z-filter so it is not the algorithm or PHD2. Notice how with LowPass2 it is operating like a Hysteresis with 90% aggression and NO hysteresis. This is due to the hack I mentioned earlier where it ceases to be a low pass filter.

I compared your MCF files with mine. Mine has Dec reversal OFF whilst yours is ON. This should not cause a problem as calibration would sort it out. But may be worth trying anyway.

BAsed on Andrew's analysis the only thing I can think of that could hold up the commands is the FTDI chip or the firmware

@PeterKom do you have access yet to the Avalon support forum? Definitely post there with the guide log to show the issue. If you don't have access, I could post on your behalf

 

Edit: I can see your username in teh members list since Jan-15. Check your spam in case the welcome email was diverted. Also, you need to log in at the main support page https://www.avalon-i...pport-2/support then go to the forum from the menu. 

Thanks Ken.
The DEC reversal was set on default and I saw in the manual that this should be like that. But I can try no problem.

I assume the FTDI chip is located in the mount itself right. By mount I mean the StarGO module. So this should be replaced then.

Yes I have access to the Avalon support forum. I will post it also there. Many thanks for your help and time. I hope we can resolve this very soon.

 

Thanks again
Peter

[KenS]

Hi Peter

Yes the FTDI chip is inside the StarGo on the USB port. I don't know if that is the problem - that's why you need input from Avalon. But the last logs you provided show the problem pretty well so hopefully they can track it down. It might be as simple as reverting to the old firmware. But best to get their input on that rather than risk bricking your mount. The only other thing you could try is use the ASCOM diagnostic tool to turn on serial port tracing.

https://ascom-standa...8cbf10c52be.htm

That should show what is being sent to StarGo and how it responds and might offer other clues.