Ray Wells replied to the topic 'Indi_asi and indi_xagyl_wheel not playing nice.' in the forum. 14 hours 59 minutes ago

I did try that and verified the file was intact before load, loaded specifically and then the file gets corrupted on save. It's only on my rpi3 though. I have not updated my pc since I started troubleshooting so I'd have a working model to compare to. I stripped the pi of indi completely and re-cloned git, then ran into build errors...a stupid dynamically attached library again that is installed and "not found". I'll have to hunt down the version it needs before I can continue. Meantime I'll try an updated ppa install. I was THIS close to having it all working. The focus module now has the 1000 limit again..(boggle)
I'm going to excuse myself from "daily" if I ever get it all to go at once.


Ray Wells replied to the topic 'Indi_asi and indi_xagyl_wheel not playing nice.' in the forum. 20 hours 30 minutes ago

It does appear to be related and that XML file had the info like I saw when I had it on the desk, but the driver on the pi isn't loading it for some reason. I brought it back upstairs and it ran on the first try with the identical XML so it looks like a build problem of some sort on the pi. The stack message is a compiled c error meaning something similar to buffer overrun, something is bigger than the storage set aside for it. I saved the broken config and then read the changes. It shows filter slot 1 but none of the names. They have been removed from the file even though I had just saved a full version minutes before. I tried this several different ways and it looks like the driver is stripping or not reading these fields properly for some reason.
More as I get it.

At least it's raining gain.

<newNumberVector device='XAGYL Wheel' name='FILTER_SLOT'>
<oneNumber name='FILTER_SLOT_VALUE'>
<newTextVector device='' name=''> <

this is borked.


Ray Wells replied to the topic 'Indi_asi and indi_xagyl_wheel not playing nice.' in the forum. yesterday

Yeah I totally forgot about asking you how this went. :P I'll check it out. Thanks!


Ray Wells created a new topic ' Indi_asi and indi_xagyl_wheel not playing nice.' in the forum. yesterday

I've been working on an indi compatable diy motorized filter wheel. My unit uses an arduino nano that emulates the xagyl filter wheel usb protocol. It works well when using the ccd and mount simulator drivers, but when I connected with real hardware I could not change the filter names or move the wheel.

Unrelated: Also appears to be a missing field in the asi driver. Any Ideas?

2018-02-23T16:42:09: Client 0: new arrival from - welcome!
*** stack smashing detected ***: terminated
Child process 3844 died
2018-02-23T16:42:13: Driver indi_xagyl_wheel: stderr EOF
2018-02-23T16:42:13: Driver indi_xagyl_wheel: restart #1
2018-02-23T16:42:13: Driver indi_xagyl_wheel: pid=3864 rfd=3 wfd=14 efd=17
2018-02-23T16:42:44: Driver indi_asi_ccd: No INumber 'Gamma' in ZWO CCD ASI178MM.CCD_CONTROLS
2018-02-23T16:42:48: Driver indi_asi_ccd: No INumber 'Gamma' in ZWO CCD ASI178MM.CCD_CONTROLS
2018-02-23T16:43:12: Driver indi_asi_ccd: No INumber 'Gamma' in ZWO CCD ASI120MC-S.CCD_CONTROLS
2018-02-23T16:43:13: Driver indi_asi_ccd: No INumber 'Gamma' in ZWO CCD ASI120MC-S.CCD_CONTROLS
2018-02-23T16:43:13: Driver indi_asi_ccd: snooping on XAGYL Wheel.FILTER_SLOT
2018-02-23T16:43:13: Driver indi_asi_ccd: snooping on XAGYL Wheel.FILTER_NAME
2018-02-23T16:43:21: Driver indi_xagyl_wheel: indi_xagyl_wheel dispatch error: Property FILTER_NAME is not defined in XAGYL Wheel.


Ray Wells replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. yesterday

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


Ray Wells replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. yesterday

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.

I hope this is the cause and not some new intermittent weirdness we have to chase.


Ray Wells replied to the topic 'Indi compatable arduino firmware for filter wheel?' in the forum. 3 days ago

Sure thing Hi-Fye1. :)
Current status on this driver is a bit up in the air while I get around my use of too many "cheapduinos" at once via head scratching and udev rules.
Overall the version at the above github link was working with the Xagyl filter wheel when plugged by itself at my desk pc. I got around the magnet placement and the fix should work for any wheel now. This version is for the cheap little 5v gearhead byj motors with ULN2003 driver boards you can get at ebay or Amazon. after removing the screw, I drilled and tapped mount holes in one cover for the motor, then glued the motor into the threaded hole left by the screw by filling it with epoxy from the other side then screwing the screw back in a bit with the motor in place. Be careful you don't let glued into the motor. I used a bit of tape on it and then just left it in there. The motor runs in unipolar mode. Just plug the motor connector into board and install with a header or wires to the pins on the Arduino. The magnet placement isn't critical but make sure when you mount the hall effect that the board will clear filters and magnet. Placing the magnet anywhere between 4 and 0 (5 and 1) does the trick. The rest is just a process of figuring out steps by trial and error, change and download, until each filter lines up. since they all reference from a known home position the filter positions will be increased by about the amount of of the distance of the first one to the second so after that point things go a bit faster. The distance from the home position sets filter 1. I plan to get the offsets in the indi xagyl driver to actually work at some point which will be great for fine tuning position but right now that part as well as much of the info screen is just placeholders.
Rather than go reverse to get to lower numbers, I chose to eliminate lash issues by having the motor only run one way as much as possible. a lower value (i.e. from 4 to 2) will make the wheel run on around and find home, then run to the stored value of the filter requested. The wheel self calibrates any time it passes home or goes to a filter of a lower position value.

Once on the mount in mixed skies, mine is currently telling me filter_0 not defined and other great errors...I think I've been trying to change the color of my focuser. :P


Ray Wells replied to the topic 'Indi compatable arduino firmware for filter wheel?' in the forum. 6 days ago

I finally got a stopping place on the OnStep stuff and worked on this some. I thought you might like to see the direction I took. I used one magnet and hall effect and got around the backlash issues by making it only go one way. Felt pretty good about that when I found out QHY did the same thing. It indexes and repeats very well. The only bug i' have is my magnet placement makes it fail when going from 5 -1 because it thinks it's already home but on the wrong edge of the magnetic field. I plan to make it run off the magnet and retry next time I work on it.

Cheers and thanks again for the code. It was a real booster.



Ray Wells replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 1 week ago

@James_lan ...I just found your posts in a search! Hello and sorry if I seemed to be ignoring you. I think they didn't show up for some reason. And thanks for your help as well!

Yay snow! :P
After the story below I can report that the latest pull is working pretty well, though I still have some testing and mopping up to do.
I had to return to the earlier version of OnStep, my last working archive, after several hours of head scratching trying to figure out why things were so wrong. Lots of command fails and no motors or tracking at any point despite scouring the new config.classic.h and pins.classic.h . It's possible those aren't getting debugged due to the newer types popularity, so for now I'm going to stick to what is working. I found the broken bluetooth was actually a bad voltage regulator in the Arduino and swapped it from another unit that fell prey to the nodemcu debacle and lost its cpu comm channels. I think the damage was caused by a reset prevention cap causing a short while I fumbled around trying to get the download to go. I'm planning to install a small toggle or dip switch there to just lift that cap and let DTR do its job instead of the silly push button you have to hit at just the right moment to make work - and yet is on nearly every Arduino shield. :dry:
Since I had to return to earlier code I made a few changes while I had the unit apart and turned on the autostart tracking which got the rig running right away. Longitude worked too, unlike the update for some unexplained reason. I saw something in another thread that seems relavent to the whole longitudinal confusion we had(what we have now works). "INDI does not have negative longitude it is 0 to 360 E+" --that does explain a few things.
I noticed that even after fixes it always converts back to a positive 279 for my -80 location. Just something I noticed. I did notice thatI had to enter -80 while trying to use the new arduino code.

I put in skype4linux to patch to Pidgin chat so I can use both skype and discord channels and found at least 4 accounts that have to be yours. :silly: I also finally joined the Onstep ".io" group. Last time I looked that was Yahoo. :blink: It was very busy.

okay...better get back to work changing tiny smt caps on this old 3 phase soft start.


Ray Wells is friends with Alain Zwingelstein

This looks interesting.

Ray Wells replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 2 weeks ago

Debugging sounds like a plan. I need to spend time on other projects as well. I'm currently comparing code to get Onstep updated. I got most of the config and pins last night but my bluetooth module failed to light up. I think the new pinout may have used a pin I used to power it or something. With luck and some searching I should have it running on the new code in the next day or two, as well as nailing down any loose bits I changed that don't agree with the update.
I also fried at least one wifi module, spent a week with them and gave up, installing an hc-06 bluetoth instead. I still want wifi though. The Nodemcu modules are also problematic. You might try over flashing the whole esp8266 as that sometimes revives them but they are pesky little buggers for sure. I'm considering trying a wired ethernet module at some point.

Still raining!


Ray Wells replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 2 weeks ago

I don't understand a few of those points yet myself. :unsure: Good to know the buttons weren't just out to get me. :P

I now think we have different firmware due to different arduino's and that may cause some things to work different too ...though the command structure should be the same for everybody. I need to retest and see if I can narrow my issues a bit. Soemthing like that could have even been supply related. More time needed.

For the record, I'm using an Arduino Mega2560 with DRV8825 stepper modules and belt driven 5:1 nema17 steppers to drive the slow motion controls of a Celestron Omni CG-4 with various implements of destruction mounted on it. Another arduino nano handles the focus. currently 2 ZWO cameras(asi178 asi120) send me images and guide via a powered hub to a raspberry pi3b running as a server connected at 1gig wired. Supply is 12v via battery and charger.

My current onstep.cpp shows:
"11 21 17"
FirmwareNumber "1.0b"

I have a config.h instead of Config.MaxPCB.h
I plan to look over old and new code to try to update if needed but I still need to work on my almost done filter wheel project sometime too.

I think I may have moved that autostart define to config.h myself after finding it commented out elsewhere in code in order to troubleshoot why my motor drivers wouldn't start. It is still commented out on mine. Or Maybe it was just removed as too problematic, Not sure. We're well past the point of needing it anyway. I was just thinking some people may set it to go at startup, in which case the park/unpark might not follow unless polled at startup. I need to read what you've done with it in code maybe that will help me understand.
I also think having a single straightforward and workable procedure to get up and running is what really matters in the end. Also, I like being able to shut down the motors and leave the mount set up and running so some sort of stop/start that leaves the thing aligned is nice, and maybe we don't need too many ways to do it.
For example, in the coming weeks I'll(hopefully) be setting up before I sleep then getting up before dawn to try to get some video data of Jupiter and possibly Saturn which are highest at that time for me.

re: Layout. What if we removed the track on/off completely and just added an off next to the different rates? so:
off || sidereal || lunar || Solar || custom
and that would take care of which one as it is already saved I think?
since parking is for settling into support mounts for big rigs it might be bad to track from there. That would also be handled by doing the above. ...unless I'm trying to reinvent the wheel while the car is moving.

I would do skype but I'm a chicken. :P Social situations wear me out very quickly. I may get up the courage at some point to try though. My family uses a program called Discord chat for gaming sometimes. Never have done skype much. Maybe a group chat with my older son along as a translator just in case. Have to be on a weekend though as I'm at -5utc which puts me (and him too) at work for reasonable times. Anxiety mode..engage... :S


Ray Wells replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 2 weeks ago

uhoh...misunderstanding. These things happen. :) No need to work around. I just (also) can't test onstep's focuser because I use an external driver. I emulated moonlite when I made it and my focuser works fine like that. I may choose to integrate it at some point to reduce usb load. We will have to wait for someone who does have the onstep focuser wired in before we can get a good test on it.
The tab did show up anyway ad looks nice.

Here's my messy report from last night. I'm planning to redo the test.

The control panel should show park at start (and cold start/reset) getting the status at startup should fix this even if the user has

Setting tracking on or starting alignment procedure should unpark the mount and track sidereal.

Cold start should also reset alignment buttons and status.
(stayed on align and status at alignment completed when park clicked - scope did home)

I have a 2-10 second lag on commands I had not noticed previously, turned off debug to see if it helped.

Wrongly shows parked in ekos during alignment.

1 star align worked okay once I waited out the slew command.

Park returned home but failed to disable the motors?

Mount control "pad" shows error in status on opening during 3 star alignment - related to below i think.

after slewing to second star, could not click align. control panel Button already down. (something broke I think.)

This may not matter but PEC might be set to off by defult or maybe remember the previous setting.
I wonder how to store things in the save files. That would fix it too.

unit did not complete second slew from dubhe to capella
After doing meridan flip, stopped part way and showed error but no status reported as I had turned off
debug mode to see if it would speed things up.
-claims cannot stop slew to any command, cannot abort.
--this is my weird thing happened for the day.

could not cold start after error.

...it got late. I'd like do another run this evening if i'm not cleaning up water in the basement again and see if I can narrow down the issue.


Ray Wells replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 2 weeks ago

I used an extra arduino nano and drv8825 to make my focus module so I've not tried it either. I did notice it loaded in the tab after tonight's pull from azwing/indi. I'm not sure what the status is of focus in my version, or if it was even implemented yet. I suppose I should update that. I'm worried I'll have to redo changes I made to get things running again in the mount if I do, a lengthy code comparison may be needed before updating.
More on tonights indoor testing tomorrow as I ran out of time tonight.



Ray Wells replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 2 weeks ago

Oh wow that sounds good. I'll try to do some tests soon.


Ray Wells replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 2 weeks ago

Just setting up...that is not right. The bug is exactly as it was before Jasem patched it with sync working then reporting target below horizon while I'm looking at it. Frantically reverting in hopes of getting some Orion data tonight. Try flipping your fix? Pretty sure I can test in the rain since it's the interface with the problem. One star alignment with the phone and proper location went right to target. Then with no changes to location kstars shows telescope indicator underground. (more china!?) LOL


Ray Wells replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 2 weeks ago

I think the main Indi git has it already. -- yep. found it. We should probably keep an eye on it for OnStep related Issues. I think we can "watch" it to get notifications. Doesn't seem very busy, probably because of the forum and main website.


Ray Wells replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 3 weeks ago

I haven't seen the latest but it's already working better than the intro one that he has now so it should be okay. We might even get more testers and or bug reports. :D


Ray Wells replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 3 weeks ago

I also found/in agreement:
Aperture and focal length do work, as well as when used in guiding.
Unpark started motors but not tracking.
Track on/off did work to starting tracking.
Speed changes work great now.
pad sync seems to describe lots of problems I've had with it.
***Park failed to follow meridian flip(possible firmware problem) details below.

When I tried to park from a southwest target last night the RA went the wrong way home and I didn't find out till I went out to retrieve the mount. I found it had tried to make its way home via china which is not healthy for it.. Nothing was broken that I saw though some cables were a bit tight. I'll do a function check before I put it outside next time.
On mine unpark appeared to work but tracking stayed off. The tracking button in control panel kept turning back off but did eventually work, possibly due to usb or cpu loading.
When I unparked with the phone sidereal tracking started right away. While most EQ mounts would be fine with it, folks might not want a big scope sitting on its parking yoke support to start tracking immediately. Maybe a check box option could be offered to start or not start tracking on unpark. Tracking and parking are currently on different pages. Consolidating (un)park, tracking modes, tracking on off, home, reset home and reset park onto one tab might help the startup flow a bit.
On alignment, Ekos has a couple nifty methods already with one star via goto/center/sync, plate solving sync and centering via astrometry.com, a polar alignment aid, and a multi target mount tuning routine I haven't tried yet. The OnStep arduino code has a section marked experimental for multi point mount tuning as well. It may be possible to interface the Ekos routine with the mount one I haven't tried any of that beyond just a quick look as yet.

Unrelated: I've actually had some issues getting guiding and plate solving to work in recent builds. I need to try PHD2 guiding to see if it is related to a report made recently or there really is something wonky(maybe translates to déréglé?) on my mount.

I think you do just fine on English, much better than I would into French even with an online translator. My older son is fairly fluent but lives three states away. You're certainly getting farther on the programming than I would have at this point.

I'll try the latest git soon.
Clear skies!



3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!