It should be doable but let me look back at the source. I haven't touched that code in a while and it may take me a few days because work is really crazy at the moment. I will reply here when I get an answer.
Read More...
jaimea wrote: Thanks, hope you had a great Thanksgiving!
Yes, the ::connect is definitely doing something (it's called also for UDP), but as far as I know this should only set the default destination address:port.
In fact I'm able to send, and my equipment receives, packets using the standard tty_write... But I totally fail to receive. I was expecting / hoping to see a "bind" or "recvfrom" in your code... no luck. So for me the mystery is how you are able to receive from the mount. But your code is nice and clear and I can't find the answer.
I still have a few things to try, eventually will manage to have this working, I hope.
Thanks for your time!
jaime
Glad to try and help. Unfortunately I am out of ideas.
Read More...
jaimea wrote: After digging a bit I still don't get how you manage to receive messages using the standard tty_read functions - as far as I know a bind or recvfrom is required, and I find none!
In my tests, using the code "as is", I can get data sent to destination, but nothing received.
Enlightenment, pleaseeee?
(I must say I'm a bit surprised of finding gemini specific code in the indicom files - I can understand sometimes there's no other way, though)
Thanks
Sorry for the delayed response. The Thanksgiving holiday kept me busy.
I think the ::connect() call on line 140 in connectiontcp.cpp handles the bind if the socket type is STREAM. Other than that sockets works basically the same whether it is a STREAM or DATA_GRAM socket.
I didn't really want to put Gemini specific code in indicom.c but I didn't want to duplicate all the tty code either. So I decided that a bit of Gemini specific code in indicom.c was the lesser of two evils.
Read More...
I am the one who added UDP support. It is used in the Gemini telescope driver.
The UDP support was not designed to be a server or to do broadcast messages, just as an alternate way to connect other than TCP.
Read More...
I think it may have to do with the Western GoTo Limit. Like Jasem said the software causes a meridian flip by issuing a goto with the same coordinates. What I think is happening is that if the mount has not crossed (or gotten close to) the Western GoTo Limit then the mount won't flip. I do not have a complete understanding of exactly how this setting works but if you haven't you should join the Gemini Yahoo group. There are many Gemini experts on that group that could explain the settings much better than I can.
Read More...
knro wrote: It's in the code:
if (fabs(targetPosition - initialFocuserAbsPosition) > maxTravelIN->value())
So it checks against current position vs initial position at all times to make sure it is within range.
There is documentation in INDI site, but here is a more up-to-date one: stellarmate.com/support/ekos/focus.html
Your link explained it great. The only issue I have that is not answered in the documentation is why does it make such large adjustments. I will take a look in the code and see if I can understand what is happening.
Read More...
knro wrote: Ekos doesn't do meridian flip per se. When the mount cross the meridian and Ekos wants to "flip it", it simply issues a new GOTO command to the _same_ coords the mount is already tracking. Mounts (depending on their settings) would then automatically perform the meridian flip.
That is the way I understand that the Gemini systems works as well. I think there are some settings in the Gemini that control how far past the meridian it will track before it flips.
Most of the targets I have been imaging since I got the mount are close enough to the meridian that my mount will tend to start out pointing west and looking "back" past the meridian to the east so no flip is necessary during the session.
Read More...
knro wrote: You can limit how much it moves by adjust the Max Travel value. You can select a different algorithm to see if you can get better results.
Does Max Travel mean the max the focuser can travel each movement or the total it can travel during the entire focusing sequence?
I have tried different algorithms with the same results.
Is there any documentation on how each setting works? Or maybe a video?
Read More...