×

INDI Library v1.9.9 Released (30 Nov 2022)

Bi-monthly INDI Library released with new drivers and bug fixes.

Driver OnStep (LX200 like) for INDI

  • Posts: 334
  • Thank you received: 42
Jrsphoto,

I forgot, if you are interested in getting the slsnif cource code (I modified a bit the original) then send me an Email:
to azwing at free dot fr
and make sure the subject is exactly as hereunder otherwise it will end up in the trash :-)
Subject: OnStep_INDI
The following user(s) said Thank You: John Scherer
4 years 11 months ago #23571

Please Log in or Create an account to join the conversation.

  • Posts: 257
  • Thank you received: 22
Hi guys! I've seen this before too but in my case it was the Arduino resetting in response to the port being opened. I've decided that resetting is a serious problem for indi. The time it takes to reboot the arduino is just about right to confuse the indi driver, and then when you retry, it sometimes goes. I solved it by bypassing the reset line in my onstep rig with good results. It goes every time now. I also figured out recently(see above in thread) that a 2 pin header and jumper is nice to have for programming. My filter wheel arduino nano is currently having exactly this problem and is on today's todo list as soon as I find an old motherboard or hard drive to rob the jumper from...and after yard work. :D The patch is simply a small cap from the reset pin to ground to filter out the pulse presented by the serial chip when the port is opened(I think dtr?), with the jumper in series so you can undo it when programming and avoid the constant reset button dance and IDE failures. -- the programmer relies on that reset to get its framing right.

I hope this is the cause and not some new intermittent weirdness we have to chase.
Last edit: 4 years 11 months ago by Ray Wells.
4 years 11 months ago #23574

Please Log in or Create an account to join the conversation.

  • Posts: 334
  • Thank you received: 42
Hi Blueshawk,

I agree with you concerning Arduino, but I still beleive it could be solded by software in the Arduino itself.
Something like seting up the serial comunication with delay after boot.
For sure indi cannot do anything on this side since it is really the serial port on controller that does not behave as expected..

Concerning the diver development I worked a little bit on Focuser and discovered Abort was not working when Absolute or Relative move was requested.
Howard as usual was reacting quickly and solved the issue in Alpha code, I tested it this morning.

I am still reading the Indi Developper manual and play with exemples trying to understand where in my code I could improve overall complance with Indi Standard which would guarantee full Ekos compatibility.

So for the time beeing no further modifications or upgrades so far no critical bug raise up.

My hardware is not yet built, I have some problems getting the 12V switching regulator (seems out of stock in France and Germany.
4 years 11 months ago #23575

Please Log in or Create an account to join the conversation.

  • Posts: 257
  • Thank you received: 22
From the driver standpoint, if it is the reset/delay comm problem, which is what it sure sounds like is happening, having the indi driver wait a bit before sending the chr(06) (ack) might be all that is needed to prevent the comm failure, but I think nailing down that reset line in the arduino is a better solution. There are other side effects of a DTR driven unit reset that are solved by fixing the hardware. For example... With a reset on port attachment, if Kstars crashes you have to redo the alignment and re-find your target from home which is a huge time eater. With DTR reset bypassed at the arduino, this doesn't happen and the whole system just picks up where it left off when you finally stop swearing and reset the software.

Bummer on the parts issue. I'd send you one but it would have a beard when it got all the way over there, as well as probably being out of stock here too. If it becomes a serious problem I could check with parts at work on Monday and see if we have one in the bins.
I forgot to order the 4amp power supply for my new odroid-xu4 so it's sitting on the desk. :/
On the up side the filter wheel is working well...but I'm having some weird issue(what else is new?) where the driver on the pi is acting different than when testing with it on the desk and the very same code compiled on my pc. :boggle:
aaand...more rain. :D

[figured it out. ASI_ccd driver is not running in test but is on mount ..but doesn't pick up wheel data.]
Last edit: 4 years 11 months ago by Ray Wells.
4 years 11 months ago #23577

Please Log in or Create an account to join the conversation.

  • Posts: 51
  • Thank you received: 9
Thanks AZWING, I've been away for a few day but I'm back now. I'll do some further testing with this. I will also test your serial data analyzer suggestion as well. The one thing I notice is that if I connect my MaxPCB to the raspberry pi with the full indilib installed, it seems to connect every time. But only when I have the MaxPCB connected directly to my computer do I see the connection failures. Have you tested this?
4 years 11 months ago #23643

Please Log in or Create an account to join the conversation.

  • Posts: 51
  • Thank you received: 9
Email sent.. Thanks!
4 years 11 months ago #23644

Please Log in or Create an account to join the conversation.

  • Posts: 334
  • Thank you received: 42
Hi Jrsphoto,

I did all my tests with controller directly attached to PC, for convenience.
In the meantime I am testing with Raspberry Pi3 since it is the solution I want go to.

I experienced the disconnection in boith cases, but as I said it was more due to testing, disconnecting, reconnectin,g, plugin in/out and so on so that I sometimes went into trouble.
But each time I could solve it with a terminal.

I tested the following configurations:

1) Using Raspberry only as gateway for the serial port over IP

Onstep <-> Raspberry -- ser2net (/dev/ttyACM0 on port 3000) <-> PC connection via WiFi on Raspi_IP:3000

2) Using Raspberry as the Indiserver and connect with client over IP
OnStep + Camera <-> Raspberry + Indiserver on Raspi <-> PC remote connection with Kstars / Ekos

3) And last using Raspberry tas a sort of usb hub over IP
OnStep, Camera <-> Raspberry + usbip server <-> PC with usbip client and connected everything as if it is connected to PC

I have a preference fo number 2 because it is an independent solution, can be bundled with controller in one box and supports Windows, OSX and Linux as client.
Combined with number 1 and/or 2 it even can bring support for non Indi software as well. I tested for example Kstyars on Windos togehter with APT for my Canon.


Number 3 offers really good throughput since I tested with all the 4 ports to stream cameras, I used the Canon EOS and three Webcams and I had real time vido on my PC as if the devices were connected to the PC itself.

Numlber 2 was just for fun but could be a solution for other devices.
4 years 11 months ago #23651

Please Log in or Create an account to join the conversation.

  • Posts: 51
  • Thank you received: 9
Hi azwing,

I was testing this out tonight, trying to get the serial line sniffer program to work but every time I tried to use it, indi would fail to connect to onstep. If I stopped the serial sniffer program, indi was able to connect to onstep. With that in mind, my results are for the most part, identical to your findings. For some reason, onstep seems to become confused when trying to talk with indiserver. I went into minicom and issue the :GD# or :GR#. As you have mentioned, I did not get output for the first command, but the second one I did. After exiting minicom, indiserver loads and connects to onstep.

At present, I don't have this stuff installed on my telescope mount. My mount is a G-11 ( an older Celestron version) and I'm waiting for some parts to arrive so I can finish rebuilding it.. I can't wait to get all this stuff working together. The power of KStars, Ekos, and Indilib/Indiserver is really amazing.


Last edit: 4 years 11 months ago by John Scherer.
4 years 11 months ago #23762

Please Log in or Create an account to join the conversation.

  • Posts: 334
  • Thank you received: 42
Hi Jrsphoto,

When you start slsnif do you get in return the following?

alain@alain:~$ slsnif -n -l log.txt -u -s 9600 /dev/ttyACM0
Serial Line Sniffer. Version 0.4.4
Copyright (C) 2001 Yan Gurtovoy (This email address is being protected from spambots. You need JavaScript enabled to view it.)
Started logging data into file 'log.txt'.
Opened pty: /dev/pts/3
Saved name of the pty opened into file '/tmp/slsnif_pty'.
Opened port: /dev/ttyACM0
Baudrate is set to 9600 baud.

it is the /dev/pts/3 that you need to enter as port in the option tab before connection

Happy to hear the trick with minicom does work, still the problem is here but located
The following user(s) said Thank You: John Scherer
4 years 11 months ago #23769

Please Log in or Create an account to join the conversation.

  • Posts: 68
  • Thank you received: 2
This bug reminds me of a bug that I had with the old version of the driver that needed to send an initialization command via the serial link before I could use Indi.

I did not have this problem with a Mega arduino. Only with the Teensy.
To fix this bug you need to install the Teensy udev:

www.pjrc.com/teensy/49-teensy.rules
sudo cp 49-teensy.rules /etc/udev/rules.d/

I hope it will help you.
The following user(s) said Thank You: John Scherer
Last edit: 4 years 11 months ago by durand Sébastien.
4 years 11 months ago #23771

Please Log in or Create an account to join the conversation.

  • Posts: 51
  • Thank you received: 9
Thanks for that bit of info. Its funny because during my testing last night, I starting looking into udev rules because of this page:


I figured that there must be a udev rule for the teensy but I didn't see that on Pauls site. I'll test this out today for sure. Also, in the udev rule he provides is this little bit of info:
# If using USB Serial you get a new device each time (Ubuntu 9.10)
# eg: /dev/ttyACM0, ttyACM1, ttyACM2, ttyACM3, ttyACM4, etc
#    apt-get remove --purge modemmanager     (reboot may be necessary)

So now at least the serial port used by the teensy will remain constant!


4 years 11 months ago #23778

Please Log in or Create an account to join the conversation.

  • Posts: 51
  • Thank you received: 9
Thanks azwing! That was indeed my problem. Its funny because I saw the /dev/pts/XXX line before and thought to myself that maybe I should be using that in ekos but for some reason never tried it. Ok, so I have attached two log files, one WITHOUT the udev mods that Dragonlost suggested, and one WITH the mods he suggested.

I need to do more testing, but it seems that Dragonlosts udev suggestion fixed my problem at least. I'll do more testing to comfirm. Here is the /etc/udev/rules.d file I'm using:
# UDEV Rules for Teensy boards, http://www.pjrc.com/teensy/
#
# The latest version of this file may be found at:
#   http://www.pjrc.com/teensy/49-teensy.rules
#
# This file must be placed at:
#
# /etc/udev/rules.d/49-teensy.rules    (preferred location)
#   or
# /lib/udev/rules.d/49-teensy.rules    (req'd on some broken systems)
#
# To install, type this command in a terminal:
#   sudo cp 49-teensy.rules /etc/udev/rules.d/49-teensy.rules
#
# Or use the alternate way (from this forum message) to download and install:
#   https://forum.pjrc.com/threads/45595?p=150445&viewfull=1#post150445
#
# After this file is installed, physically unplug and reconnect Teensy.
#
ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="04[789B]?", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="04[789A]?", ENV{MTP_NO_PROBE}="1"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="04[789ABCD]?", MODE:="0666" SYMLINK+="onstep"
KERNEL=="ttyACM*", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="04[789B]?", MODE:="0666"
#
# If you share your linux system with other users, or just don't like the
# idea of write permission for everybody, you can replace MODE:="0666" with
# OWNER:="yourusername" to create the device owned by you, or with
# GROUP:="somegroupname" and mange access using standard unix groups.
#
#
# If using USB Serial you get a new device each time (Ubuntu 9.10)
# eg: /dev/ttyACM0, ttyACM1, ttyACM2, ttyACM3, ttyACM4, etc
#    apt-get remove --purge modemmanager     (reboot may be necessary)
#
# Older modem proding (eg, Ubuntu 9.04) caused very slow serial device detection.
# To fix, add this near top of /lib/udev/rules.d/77-nm-probe-modem-capabilities.rules
#   SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="04[789]?", GOTO="nm_modem_probe_end" 
#

The only difference between mine and the one from prjc's site is I added: SYMLINK+="onstep" to the end of the SUBSYSTEMS line. This creates a symlink from "onstep" to whichever port the teensy attaches to. You can put what ever you want for the name, I just used onstep. Then in Ekos, I just put /dev/onstep as the port.


4 years 11 months ago #23792
Attachments:

Please Log in or Create an account to join the conversation.

Time to create page: 2.268 seconds