BYN and ASCOM

[vidrazor]

I just got an iOptron CEM26 that I'm setting up, and I loaded all the ASCOM stuff up and I'm seeing this strange action in BYN when I try to slew the mount. They say a picture is worth a thousand words, so a video must be worth millions. 🙂

So please watch this video and let me know what you think: https://youtu.be/Y90ET0PJ2_U

Thanks.

[astroman133]

Do you know what Axis Rates the telescope driver supports?

If you launch the ASCOM DeviceHub, from the ASCOM Platform 6 folder on the Start Menu. and connect it to the mount, without BYE, it will show you the available axis rates on the Telescope Capabilities screen. A single axis rate has a minimum and a maximum and there can be multiple rate ranges.

It can be a single range say from 0-5 deg/sec or it could be 0-.6667 and 1.0-2.0 like the simulator. The min and max values can be the same value such that if the range is 1.0-1.0 then 1.0 would be valid, but 0.99 or 1.01 would not be valid. Also the RA and Dec rate ranges can be different.

I have never understood how BYE can translate a percentage value into a valid rate when a mount has multiple ranges or defines discrete values.

It seems that when you click on one of the buttons, the command to the driver is changing the rate to 1x. What I also don't understand is what does 1x mean. ASCOM rate values are in degrees per second. Does 1x mean 1x sidereal? If so, moving at the sidereal rate could be just the same rate as the scope is tracking, if it is tracking at the sidereal rate.

[admin]

ummm.. one clue for me was when you hit the slew button in BYN.... when it automatically changed from MAX to 1x in you ASCOM driver.... did you also notice that the mount went from not tracking to tracking?

This could be the reason it went back to 1x.

It's been my experience over the years that most telescope requires that it is tracking for the MoveAxis to work, and for this reason, I set tracking before issuing the MoveAxis command.  I wonder if iOptron is the opposite?

var isTracking = Telescope.Tracking;
try
{
    if (Telescope.CanSlew && Telescope.CanSetTracking)
    {
        Telescope.Tracking = true;

        switch (direction)
        {
            case TelescopeSlewEnum.Up:
                MoveAxis(TelescopeAxes.axisSecondary, 1 * speed);
                break;
            case TelescopeSlewEnum.Down:
                MoveAxis(TelescopeAxes.axisSecondary, -1 * speed);
                break;
            case TelescopeSlewEnum.Right:
                MoveAxis(TelescopeAxes.axisPrimary, -1 * speed);
                break;
            case TelescopeSlewEnum.Left:
                MoveAxis(TelescopeAxes.axisPrimary, 1 * speed);
                break;
        }

        return true;
    }
}
catch (Exception ex)
{
    LogError(ex);
}
finally
{
    Telescope.Tracking = isTracking;
}

 

[vidrazor]

At this time I'm not going to worry about it too much until I can get the unit out in the field and actually shoot something. I aimed my rig at Polaris in it's home position in my apartment using Skymap, then I typed in coordinates to a target in the advanced plate solve tab in BYN and clicked on slew, and the unit slewed to the location I typed in at full speed, and the mode switched from slew to tracking when it reached it's virtual target. So other than the manual slew controls in BYN, things appear to be working. My only real concern, which I won't know until I'm actually shooting, is that there will be effective communications between BYN and PHD2 so the unit will properly dither while a session is in progress. Seeing what I've seen so far, I suspect it will, so the fact that I can't control slewing from the BYN buttons is not a big deal, after all I have the iOptron virtual and actual handsets to manually slew if I should need to.

Thanks.

[vidrazor]

15 hours ago, astroman133 said:

It seems that when you click on one of the buttons, the command to the driver is changing the rate to 1x. What I also don't understand is what does 1x mean. ASCOM rate values are in degrees per second. Does 1x mean 1x sidereal? If so, moving at the sidereal rate could be just the same rate as the scope is tracking, if it is tracking at the sidereal rate.

That is exactly what it's doing, going to tracking speed, which is bizarre. As I mentioned above, I'm not going to worry too much about this now, I just have to get the rig out in the wild and shoot to see what happens. As long as BYN and PHD2 can work together and properly guide, track, dither, and shoot, then I'm golden.

[astroman133]

Gee, usually people want to iron out their issues before trekking out into the wild and wasting a dark night.

 

[astroman133]

Guylain,

Thanks for providing the code fragment. What is the value in the speed variable? You log any exception, but do not give any visible indication to the user.

Perhaps having vidrazor provide a log file would be helpful in seeing what is happening. It might also be useful to include the speed and axis value that caused the exception into the log. Depending on the telescope driver the exception may not contain that information.

Here is code that I have used:

        public void StartJogMoveAxis( TelescopeAxes axis, double rate )
        {
            ValidateMoveAxisRate( axis, rate );

            try
            {
                MoveAxis( axis, rate );

                SetFastPolling();
            }
            catch ( Exception xcp )
            {
                throw xcp;
            }
        }

When this is called, the sign of the rate value has already been adjusted to indicate the direction.

Here is the code for the ValidateMoveAxisRate method:

        private void ValidateMoveAxisRate( TelescopeAxes axis, double rate )
        {
            bool rateValid = false;

            // Check the requested rate against the valid rates.

            IAxisRates axisRates = AxisRates( axis );
            double tolerance = 0.00001;

            for ( int i = 1; i <= axisRates.Count; ++i )
            {
                IRate axisRate = axisRates[i];

                double minimum = axisRate.Minimum - tolerance;
                double maximum = axisRate.Maximum + tolerance;

                if ( Math.Abs( rate ) >= minimum && Math.Abs( rate ) <= maximum )
                {
                    rateValid = true;

                    break;
                }
            }

            if ( !rateValid )
            {
                StringBuilder sb = new StringBuilder();
                sb.AppendLine( "The requested move rate is invalid." );
                sb.AppendLine( "" );
                sb.AppendLine( "A valid rate must be in one of the following ranges:" );

                foreach ( IRate axisRate in axisRates )
                {
                    sb.AppendFormat( "{0} - {1}\r\n", axisRate.Minimum, axisRate.Maximum );
                }

                throw new Exception( sb.ToString() );
            }
        }

I validate the provided axis rate against the list of valid rates that was read from the driver at connect time, recognizing that the rates may not be the same for all axes. This code can be called from two paths. Path 1) is via the U/I by pressing a NSEW button. Path 2) can come through the exposed telescope driver from a connected client application.

The exception is caught elsewhere and causes a message box to be displayed. This should be rare because the U/I is supposed to only let the user choose a valid rate and hopefully any connected application does the same.

I hope this is useful.

[vidrazor]

23 hours ago, astroman133 said:

Gee, usually people want to iron out their issues before trekking out into the wild and wasting a dark night.

Well, it's going to be the only way I can see if it works, I can't track, guide, dither, and shoot in my apartment. 😉

[astroman133]

But you can track and shoot in your apartment. You do not care where the scope is tracking or what you are taking a picture of. Just that both functions are working.

Anyway your issue is not related to tracking, guiding, dithering, or shooting. You reported that you had a problem trying to jog your scope with the movement buttons in BYN. That is easily tested in your apartment. If it is due to some setting that you can change the sooner that you can provide more details the sooner it will be resolved. If it is due to a bug in BYN then the sooner that you can provide the info to the developers, the sooner they can fix it.

If you would please provide the axis rates that your driver and mount support per my previous post, they can get started. If you want to wait until you get out in the field then that is OK too. You are the one with the problem