Alain, All

I have it working!! So the USB part of connection. I executed your steps. The speed of the serial rate was to high and hardware flow control on. I changed it and i got response of the OnStep. My USB serial part was messed-up i think. Also i was googling and i found the following the Arduino forum forum.arduino.cc/index.php?topic=129647.0 Also called: The Linux ttyACM0 Drama. The thing what it did for me was

sudo chmod 777 /dev/ttyACM0
sudo apt-get --purge remove modemmanager

So the USB Part is Fixed all function including Slew are working

Now the wifi part i need to fix.
The connection to the OnStep via Wifi works information collected like site information etc etc.
But the status in Mount control of ekos is "Status:Error" This must be tracking
The RA and DEC Are correct compared with Onstep
I connected OnStep to my local network and promoted the OnStep to an Access Point no differents
So Slew is not working, how to fixes this issue, What to to check i have the last ESP01 software active from the git, Has this to do with the WIFI on the ESP?
I think aim not the only one with this issue.

The logs show me
==> Update OnSTep Status
CMD <:FG#>
RES <-2>
CMD <GR#>
The Error Reading RA/DEC
CMD <GR#>
The Error Reading RA/DEC
endless loop

Or must we discuss this on the Onstep Forum?

Chris

I also have a couple unusable nodemcu modules from that experiment, and usb was more reliable. Be sure to cut the power wire from the usb cable going to the arduino or the 3 pin regulator will cause device contention in the supplies.

sudo chmod 777 /dev/ttyACM0 --Make sure you are a member of the dialout group. The problem with changing permissions of the serial port is that you will have to keep redoing it every time you connect the cable.

sudo usermod -a -G dialout $USER

Removing modemmanager will help stop port creep acm0, acm1,acm2 etc. when reconnecting, but look into adding udev labels to end the madness.(unless like me you have too many cheapduinos)

Happy Friday!

Also Alain the mushroom hunter. touche!

[edited due to Sake'(and other stupid things I drank)]

At least for me, the user running INDI was in the dialout group. So that's not the problem.

Edit: I did have modemmanager, which I removed as well, so that's still a suspect.

@azwing Everything working now? I've got another pull, for some of the alignment stuff, but I wanted to make sure everything was settled for you before I did it.

@Blushawk and James

thank you for helping Chris

@Chris
Now that your USB works make sure you freeze all the settings as described by Blueshaw / James.

Concerning WiFi hosnestly I cannot help further since I don't have the same setup.

@Blueshawk
Yes finally after Jasem's fix everithing works.
I am just playing a arround git and branches before I start any modifications on OnStep.
The Git version is OK.
I added a branch "OnStepTest".
Intention is to work on this branch and then to merge to master before sending a pull request
But what I do not yet understand is how to keep this branch up-to date with upstream.

Alain, All

Thanks for your support, I am happy that we have solution now
I am still diving in in to the wifi issue.

I have some question:
1. Who created this driver, he is the one who can help us here
2. Is there some one where communication with the OnStep mini works over WIfi? After connection it start not slewing but mount is in error Status
3. Wat tis the different in the lx200 communication flow in the Driver Code from USB compair to WIFI are this two separated set of codes or is this one function?

The reason i asked. I enabled logging as explained by Alain. I compared the working USB startup with Not Working Wifi Setup. (It starts not Tracking in INDI while Onstep is doing tracking and there for the mount in INDI report de status:error).

I discover the following: By starting up it makes the conclusion "Telescope altitude is below minimum altitude limit of 0. Aborting motion..." and that is strange
because CMD <:GA#> was not needed or requested any way not see in the debug information. (If the code is the same i expect the same error)

[2018-12-01T13:45:34.975 CET INFO ][ org.kde.kstars.indi] - LX200 OnStep : "[INFO] Mount is unparked. "
[2018-12-01T13:45:34.976 CET DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[DEBUG] InitPark Axis1 0.00 Axis2 0.00 "
[2018-12-01T13:45:34.982 CET INFO ][ org.kde.kstars.indi] - LX200 OnStep : "[INFO] =============== Parkdata loaded "
[2018-12-01T13:45:34.983 CET DEBG ][ org.kde.kstars.indi] - < LX200 OnStep >: < RETICULE_BRIGHTNESS >

---

This below is not true
[2018-12-01T13:45:35.884 CET INFO ][ org.kde.kstars.ekos.mount] - "Telescope altitude is below minimum altitude limit of 0. Aborting motion..."
[2018-12-01T13:45:35.886 CET DEBG ][ org.kde.kstars.indi] - ISD:Telescope: Aborted.

---

Strange

---

Round this time a Error is see in the console "Error Slewing Failed"
[2018-12-01T13:45:35.935 CET DEBG ][ org.kde.kstars.indi] - < LX200 OnStep >: < AlignStar >
[2018-12-01T13:45:35.996 CET DEBG ][ org.kde.kstars.indi] - < LX200 OnStep >: < Align Process >
[2018-12-01T13:45:36.039 CET DEBG ][ org.kde.kstars.indi] - < LX200 OnStep >: < Slew elevation Limit >

In the USB sequence no issue here

Next After that the Configuration is loaded It request the object coordinates and telescope is updated succesfullly and configuration saved.
Then the Scope Asked for [SCOPE] CMD <:GR#> with as result Error reading RA/DEC. Why does he need to request there a extra RA

[2018-12-01T13:45:37.955 CET DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[DEBUG] Configuration successfully loaded. "
[2018-12-01T13:45:37.955 CET DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:GR#> "
[2018-12-01T13:45:37.956 CET DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <13:48:15> "
[2018-12-01T13:45:37.956 CET DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] VAL [13.8042] "
[2018-12-01T13:45:37.956 CET DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:GD#> "
[2018-12-01T13:45:37.956 CET DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <+49*13:06> "
[2018-12-01T13:45:37.957 CET DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] VAL [49.2183] "
Above get the object from OnStep
[2018-12-01T13:45:37.958 CET DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:GU#> "
[2018-12-01T13:45:37.958 CET DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <Npza/ET0> "
[2018-12-01T13:45:37.974 CET INFO ][ org.kde.kstars.indi] - LX200 OnStep : "[INFO] Mount is unparked. "
[2018-12-01T13:45:37.975 CET DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:Gm#> "
[2018-12-01T13:45:37.975 CET DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <E> "
[2018-12-01T13:45:37.976 CET DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:%BD#> "
[2018-12-01T13:45:37.976 CET DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <0> "
[2018-12-01T13:45:37.976 CET DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:%BR#> "
[2018-12-01T13:45:37.976 CET DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <0> "

[2018-12-01T13:45:37.977 CET DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "==> Update OnsTep Status "
[2018-12-01T13:45:37.978 CET DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:FG#> "
[2018-12-01T13:45:37.979 CET DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <-8> "
[2018-12-01T13:45:37.985 CET INFO ][ org.kde.kstars.ekos.mount] - "Telescope info updated successfully."
[2018-12-01T13:45:37.993 CET INFO ][ org.kde.kstars.indi] - LX200 OnStep : "[INFO] Saving device configuration... "
[2018-12-01T13:45:37.999 CET INFO ][ org.kde.kstars.indi] - LX200 OnStep : "[INFO] Device configuration saved. "
[2018-12-01T13:45:37.999 CET DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[DEBUG] Configuration successfully saved. "
[2018-12-01T13:45:38.000 CET DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:GR#> " Why this command

---

First Time that CMD <:GR#> did get in error
[2018-12-01T13:45:38.000 CET DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "Error reading RA/DEC. "
[2018-12-01T13:45:38.015 CET INFO ][ org.kde.kstars.indi] - OnFocus : "[INFO] OnFocus is online. Getting focus parameters... "
[2018-12-01T13:45:38.020 CET INFO ][ org.kde.kstars.indi] - OnFocus : "[INFO] OnFocus is online. "
[2018-12-01T13:45:38.021 CET INFO ][ org.kde.kstars.ekos] - OnFocus is connected.
[2018-12-01T13:45:38.021 CET DEBG ][ org.kde.kstars.ekos] - 3 devices connected out of 4


My last conclusion is but the forum must confirm this. After starting all equipment in indi, the telecope mount in de INDI gui must be directly in to tracking status when tracking is active in de Onstep and must not be in the status idle. This is wat happend with in the USB connection (OnStep). It will be in tracking after the first slew but i don't know what the correct behaviour must be or that this is a bug it report idle but its tracking

I hope some can look in de code to check what i discovered can be explained and be fixed


Chris

Chris,

I just did set-up a wemos on my Arduino to test you issues.

I did set-up in control panel as you can see in attachement

and after connection all went well as per attachement

So I did nothing elese tha Flashing the Wemos, connecting it to the Arduino Mega
Wemos Arduino
TX ===> RX1
TR ===> TX1
5V ===> 5V
Gnd ===> Gnd

and heunder the logs of the connection
Are you sure you did setup the right port in OnStep?

============ log under /home/alain/.indi/logs/2018-12-01/indi_lx200_OnStep/
INFO 0.002935 sec : Session log file /home/alain/.indi/logs/2018-12-01/indi_lx200_OnStep/indi_lx200_OnStep_17:16:01.log
DEBUG 0.006140 sec : Active Snoop, driver: Dome Simulator, property: DOME_PARK
DEBUG 0.006761 sec : Active Snoop, driver: Dome Simulator, property: DOME_PARK
INFO 19.362766 sec : Connecting to 192.168.0.1@9999 ...
DEBUG 19.364743 sec : Connection successful, attempting handshake...
DEBUG 19.364871 sec : Testing telescope connection using ACK...
DEBUG 19.368476 sec : Testing successful!
INFO 19.368587 sec : LX200 OnStep is online.
DEBUG 19.372537 sec : Configuration successfully saved for CONNECTION_MODE.
SCOPE 19.373428 sec : CMD <:GR#>
SCOPE 19.380086 sec : RES <11:42:58>
SCOPE 19.380134 sec : Coordinate format is high precision.
SCOPE 19.380148 sec : <ACK>
SCOPE 19.380159 sec : CMD <0X6>
SCOPE 19.383983 sec : RES <P>
SCOPE 19.384026 sec : <getTimeFormat>
SCOPE 19.384041 sec : CMD <:Gc#>
SCOPE 19.389915 sec : RES <24>
SCOPE 19.389973 sec : <getSiteName>
SCOPE 19.389988 sec : CMD <:GM#>
SCOPE 19.397218 sec : RES <Schoenau>
DEBUG 19.397247 sec : Site Name <Schoenau>
SCOPE 19.397272 sec : <getTrackFreq>
SCOPE 19.397281 sec : CMD <:GT#>
SCOPE 19.404310 sec : RES <0.00000#>
SCOPE 19.404400 sec : VAL [0]
SCOPE 19.404421 sec : <getSiteLatitude>
SCOPE 19.404429 sec : CMD <:Gt#>
SCOPE 19.411109 sec : RES <+48*13>
SCOPE 19.411171 sec : VAL [48,13]
SCOPE 19.411181 sec : <getSiteLongitude>
SCOPE 19.411189 sec : CMD <:Gg#>
SCOPE 19.418669 sec : RES <-007*39>
SCOPE 19.418720 sec : VAL [-7,39]
DEBUG 19.418738 sec : Mount Controller Latitude: 48.2167 Longitude: 7.65
DEBUG 19.419281 sec : Configuration successfully saved for GEOGRAPHIC_COORD.
SCOPE 19.419351 sec : CMD <:GG#>
SCOPE 19.424602 sec : RES <-01>
SCOPE 19.424672 sec : VAL [-1]
SCOPE 19.424701 sec : CMD <:GL#>
SCOPE 19.432255 sec : RES <13:31:06>
SCOPE 19.432319 sec : VAL [13.5183]
SCOPE 19.432338 sec : <getCalendarDate>
SCOPE 19.432349 sec : CMD <:GC#>
SCOPE 19.440733 sec : RES <12/01/18>
DEBUG 19.440819 sec : Mount controller UTC Time: 2018-12-01T11:31:06
DEBUG 19.440835 sec : Mount controller UTC Offset: 1.00
SCOPE 19.440860 sec : CMD <:GVD#>
SCOPE 19.449614 sec : RES <Dec 1 2018>
SCOPE 19.449693 sec : CMD <:GVT#>
SCOPE 19.457610 sec : RES <18:06:16>
SCOPE 19.457676 sec : CMD <:GVN#>
SCOPE 19.465316 sec : RES <1.17b>
SCOPE 19.465370 sec : CMD <:GVP#>
SCOPE 19.471376 sec : RES <On-Step>
INFO 19.471573 sec : Mount is unparked.
DEBUG 19.471766 sec : InitPark Axis1 0.00 Axis2 0.00
INFO 19.471796 sec : =============== Parkdata loaded
SCOPE 19.472040 sec : CMD <:FA#>
SCOPE 19.476162 sec : CMD <:fA#>
INFO 19.481287 sec : Mount is unparked.
DEBUG 19.481473 sec : InitPark Axis1 0.00 Axis2 0.00
DEBUG 19.481502 sec : Setting Default Park Axis1 to 0.00
DEBUG 19.481519 sec : Setting Default Park Axis2 to 48.22
SCOPE 19.482163 sec : CMD <:Sg352:21#>
SCOPE 19.490033 sec : CMD <:Sg352:21#> successful.

Alain

Yes i did. Is this test on raspberry with mate?

See attached screen shots,

Where can i find the configuration of my profile so i can clean it like new set-up?

Chris

"I discover the following: By starting up it makes the conclusion "Telescope altitude is below minimum altitude limit of 0. Aborting motion..." and that is strange"

If I've got this translated correctly, I've seen this one a few times. What is happening is that your mount is actually parked, but the wrong message is being used. Drove me nuts too. The slew control button window status is usually correct and will show IDLE when it's home and park or TRACKING when running.

I also recommend running the bluetooth or wifi OnStep android app for troubleshooting mount status, also handy for quick checks when you go out to the mount.

@azwing Wifi, Wow! That's neat!

Hey Guys i did a compair of the log first started via USB
second start via WIFI

In this case its not home parked but tracking on target

strange behaviour still

I thing to move my laptop OS to mate, it seem to work best if i google rond on this forum

Chris

@Blueshawk,
WiFi, bof , I just did the setup to try to help Chris!
I am not convinced WiFi is the right thing to drive a scope.
During my previous life an an automation engineer, I was many times in front of the choice to use or not WiFi and the proposed solutions were quite professional and expensive but I always did take the choice of reliability over comfort.
But I had some colleagues working in Nuclear plants and swearing WiFi is the future .... fear the future ...
Matter of education I think!
checking this "Telescope altitude is below minimum altitude limit of 0. Aborting motion..."
in which portion of code do you find this? I didn't.


@Chris
I did the test on Debian Buster with an Arduino since I have nothing else to test.
Just realized your question, If you search the culpit of all this mess, I am the guy that wrote the driver

I fully agree with azwing here. WiFi is not the correct network stack to drive a telescope. There is just too much instability, interference, slowness, ...etc.

What I do is drive the telescope over USB from a laptop that sits alongside the telescope, then access the laptop over WiFi.

The difference is that if my remote desktop session times out, the laptop is still driving the telescope as normal, and I just reconnect and I am at the same place.

On the other hand, if you are driving the telescope over WiFi, and there is a timeout, the software that is driving the telescope does not have any knowledge of the telescope's status (where it is pointing, is it tracking or slewing, ...etc.) Very dangerous ...

Hi Khalid,

thank you to support me on this side
My dream is:
- Communication CRC based (howard started to implement this)
- Watchdog that would emmergency stop the scope (based on toggle bit or counter)

But as Khalid said, "the best is the enemy of the good " I could fix the latest bug and now I would like to work a little bit on the new release