Print

[grizli21]

Fresh news.
Still no chance with the hardwareserial.h code instead of your own one...
I'm not giving up. Thinking about timing issue, i may try soon to the oscillo if i see something about timing .

What serialecho.exe does have so special about ?

[TCWORLD]

The only thing I can think of is if the hand controller baud rate is significantly out, or the signals are getting distorted somehow.

A scope would be useful to identify both cases.

[grizli21]

Here is the result.
Left is astroeq, right azeq6.
Yellow :handpad
blue:motorboard

Signal looks clear.
Notice that first sentence is different, but why?
Both motorboard answers seems identical. Timing looks ok, i may look closer.
Something interesting is the lower tx voltage of azeq6.

Nothing more to the astroeq side, the handpad goes mute and screen says "dec/alt no response".

[grizli21]

I don't think this is a timing issue as there is just 40microseconds difference for the same message.
left azeq6, right astroeq.
Astroeq is not noisier, it is the acquire sampling that is different.

[TCWORLD]

Really have no idea.

If you want to try Serial 1, I've made some changes to the SerialLink file to make it possible.

Attached is the new .cpp file. If you look on line 6, you can now change which serial port to use by changing the #define. For example to use Serial1, change the #define value to 1.

[grizli21]

I'm happy to say that the synscan handbox is now working with astroEQ 
See attached picture.

Finally there were two things that prevented it to work.
- chd340 usb to ttl interfering with uart0.
- wrong timing ( those tiny 30 micro seconds earlier)

Initialisation at 9900bps made the difference. Starting like a charm now.
Will make further test in days to come.
Regards

[grizli21]

Thanks Tom for the last upgrade 

[TCWORLD]

I wonder if the oscillator on the clone board is inaccurate - if it is a simple resonator (quite possible), then it's accuracy will be probably +/-5%, which could lead to timing issues if the hand controller is very sensitive to baud rate. It would also mean that any timing for say the sidereal rate would be out.

It would be worth trying to accurately measure with the scope the length of one packet (10bits) and see how close to 9600baud it really is.

[grizli21]

Hello Thom,
I had some time to play with astreq and synscan today and i think the tracking issue after slew is located.

After comparing the azeq6 communication with handcontroller then the astroeq, we found out a little.

We did not see difference about com between the boards, but more of a missing loop .
Looks like the motorboard is not listening when it is in deceleration phase so handscan has to wait deceleration has finished to send the last sentence:

I mean the difference is that the azeq6 board is sending another f1 value until the decelleration is done.
Only when it stopped ,azeq6 is sending the last f1 value so then handcontroler is answering and az board can listen to it and return back to tracking.

For the astroeq it immediatly sends the end f1 value, and handcontroler  respond as well but the deceleration is still going one and so on astroeq is not validating it.

I hope it is suffient self explanatory as my English is a little poor. If not i could be happy to had some explanation.

Unfortunatly i don't feel i have the capability to make the modification myself so i won't be helpful .
And also i do think that this issue and the handcontroler goto issue is the same problem and if this issue is elimated the handcontroler will be fully workable.

[grizli21]

The serial command attached.

[TCWORLD]

It shouldn't matter that deceleration is not complete, AstroEQ is quite happy to accept new commands while decelerating.
 
From what I could tell in the previous commands you showed, basically the hand controller is not sending a new ':Gn##' command after the slew, meaning that it starts tracking in the wrong direction because the direction isn't changed.

[grizli21]

As always thanks for responsivness,
I try to understand why this issue is not happening with azeq6 board, does synscan motor board not using high speed microstep change ?

You are right about decelerating loop, i used to disabled deceleration for any speed, and it does not change anything about tracking back to normal.


Line 46 commands.cpp : cmd.minSpeed = 0;
But doing this we discovered a very interesting thing!
I don't know why but now the goto from handpad is working, the catalog  is fully fonctionnal as well as X stars alignement.
Can i help somehow resolving this point?

[grizli21]

The only thing i see is that the g110 value is done silently in the synscan motor board when a sideral tracking is calledback again.

[grizli21]

I don't know why but now the goto from handpad is working, the catalog  is fully fonctionnal as well as X stars alignement.

My mistake,it start but then it is moving forever ...

Attached the starting of a goto with synscan handpad.
While i understand the 'G' and 'J' command, i do not see why the 'S'  in this context.
I also noted that this 'S' command is not called in eqmod for goto but only with handpad one.

I also have some difficulties with 'f' command and how to interpret it.

[grizli21]

The way handpad goto are failing with astroeq :