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.
Thank's I'll check it out.
For my own gear, I took a bit of time to research it and decided to use the Teensy 3.2 I had on hand to put the existing wheel back together for now. It only took about an hour to move wires and update the IDE to handle downloading to the teensy. I was able to use the same i/o mapping, and it looks like it may go right away. The change from cheapduino should clear up my current udev rule issue and make getting the system online easier and faster.
This explains that issue in depth: https://arduino.stackexchange.com/questions/6617/setting-serial-number-on-ch340-usb-serial-device
I've been slowly moving away from ch340 serial arduino units as a result.
Wanting off the front lines. I know that feeling well. Ask Jasem, who has lent me a shoulder more than once. ;>
If you see that error again maybe you could paste it here? It might be a clue. When I have had xml file issues I've gotten stuff like that in indiserver feedback. Sometimes it's just because the settings file has not been made/saved yet. Having a working boot does make sense. I actually have set aside an old git clone and called "everything works" ..so naturally I had to go and find a problem that wouldn't fix. LOL
I was looking for unrelated info and found this:
The ASI cameras not liking external hubs is certainly not helping the situation.
I also remembered having not enough supply input current to the rpi3 main supply causing troubles. If you are using a wall wart, make sure it's not close to limits. Rpi instructions 2A but a 4A supply is better.
Yeah, I agree. I think once opened the system locks the device port so combining drivers would also be needed.
Along the same lines, it might be an interesting project to make an all in one accessory unit. An arduino with a motor shield could be programmed to do focuser, filter wheel, a flip cover, a rotator, and even expandable switched i/o, because those low current low priority devices rarely even run at the same time. Or how bout a motor shield for the RPI3? and moving that up there!
My brain is being more ambitious than my body or available time these days... Fun to think about though.
I'll probably just fix the filter wheel.
Can I call the same usb port twice with two different drivers or would I have to combine the drivers and protocol into a custom one for this to work with indi?
I've had the problem of "cheapduino" usb ID overlap for a very long time and saw an opportunity to kill 2 problems at once when my filter wheel arduino died last week(as if the cameras fighting wasn't enough -.-)
I had the crazy idea of combining the code from my focuser(moonlite protocol) and my filter wheel(Xagyl protocol) into one unit to reduce cables and ports as well as solving the udev duplicate ID problem.