Hi guys! Just popped in to post an idea and saw this. Been rockin that eq6r, if I could only get some decent sky :')
@Paul K: Checked the video and that does look weird. Stepper mounts are open loop and have no way to tell if the mount actually went to target, which is also why we plate solve. The software should drive right over there even with motors off(ie.unplugged) so it just about has to be some setting that's limiting slew/track.
The Indi Eqmod has some overlapping alignment toys that can be a bit confusing. You might try resetting the Sync and alignment pages so they aren't trying to include old data, I've had the mount balk completely while plate solving with old align data. I also use the in mount align algorithm on mine as the driver one is overcomplicated when I just want to get close for plate solve to work.
Also, meridian limits in software and mount can sometimes get confused and stop the mount. Also-also, you might check your horizon limits.
Hope this helps
I'll chck it out! Expect weird unsolvable problems.
Thought I'd mention this just because I thought it was neat when someone shared the tip with me... When I'm imaging across the meridian, pretty much always due to trees, I turn off all the auto flips and set the mount to east facing west, then "back" it over to east to pick up the high target, watching for mount clearance. That way I can track all night and don't have to reset everything when it flips.
Yep. I agree it still could be software, especially when I later tried using a usb3 notebook with plenty of power available as the indiserver. :/ _ forgot i'd done that and it shoots the whole power thing in the foot.
My power issues were caused by adding another sbc to the system and trying to run both at once, that said, my asi178mm OR my asi120-s was working fine in usb3 when run standalone - and for awhile I thought it was something interacting between the cameras.
This thread journals that similar saga: asi-178mm asi120-s must stop one...
I don't have the asi1600 but both mine are also usb3. When I had them plugged into an Odroid-xu4 I could run either one but not both...and the symptom was exactly the same as you are getting, shutter/time down/retry without download. After much t-shooting, I finally rigged them into an rpi3b with usb2 ports and they both worked.
It could still be something weird in the usb3 port hardware, but I also think this could be power related.
Usb3 ports limit current at 900ma, and that adds up, especially when your hot SBC is already drawing 3A(at times) of the 4A recommended. The supply can drop out of regulation and still operate the lower voltage sbc circuits, but peripherals may start acting very strange. It's like apollo 13 on the ground! After researching and testing in the shop, I now recommend more supply for any of the hotter sbc's or busy Observatory/remote setups. I also recommend running a powered hub for all accessories that don't demand a host port to keep current down in the sbc supply.
To fix my problem I just installed a 5A 12v-5v buck converter to run just the Odroid, and then only run the ASI178mm into the usb3 host port on that unit, while the rest is on a separate buck regulator and usb2 ports on an RPi3b/powered hub. I'd seen others going to 2 computers and realized this would give me more isolation as well as a remote desktop for high speed planetary work.
---this rig is currently not quite working, t-shooting right now to figure out why the asi178mm is not found on the network system.
I decided to turn this problem into a net gain by chaining my Odroid to the pi only for the main camera and added a small network switch to my powerbox to handle both units. This way I can also VNC into the Odroid and run planetaryimaging, asicap or Oacapture to get high speed data collection using either ASI camera and still let indi handle all the rest when I'm chasing planets....OR just operate normally without(hopefully) shenanigans from shared port irq's, my current best guess for the above problem.
A big shout out and thanks to Jasem for this tutorial which made server chaining look easy.
Won't stop me from finding the ONE way to break it though. lol
@Charles: Following this. I like the simple scope of this teensy only version of onstep. Try to keep that KISS attitude as you guys go forward.
I was reminded recently that keeping units separate has the benefit of making troubleshooting easier and processor redundancy, as in the case of using a standalone focuser or filter wheel, allows you to continue to operate the others if any one unit goes down. This just seemed like a good place to share that bit of wisdom.
@Kbhaley: Good idea! Maybe you can give them a short example of how the linking works?
I mean, if they still need it?
@Herrhausen I'd continue to use the version that's working for you. I think the idea here is to make the project more approachable for people just starting out.
just my 2c. :-*
Charles wrote: Hi Khalid,
Dragonlost asked me if I can develop an INDI driver for TeenAstro.
If think it is much easier for both community to have 2 drivers one for onstep and one for TeenAstro. Indeed all the beauty of OnStep is the flexibility and the beauty of TeenAstro is to keep the thing as simple as possible.
The good news is that TeenAstro overlap to 95% with ONStep and has significantly less feature. For example no PEC and No multiStar alignment...
My only problem is that I have no experience with LINUX...
You might get collaborative help on this if you start a new thread suggesting it. Something like: Teenastro Development might do the trick. I think it would limit cross talk if we did that. Let us know if you make one so we can subscribe and help out too.