Hi Fra,
thanks for mentioning the tip on stopping the RA motor via FS2 commands!
Concerning Your question
the AstroElektronik versions page states the following change with version 1.21 (May 3, 2002)Does anyone know if it is really mandatory that fs-2 has version 1.26? Maybe can be related with all of the problems?
translating to "corrected error: incorrect execution of commands :Qn and :Qs".V1.21 Fehler korrigiert: Die Ausführung der LX200 Befehle :Qn und :Qs war nicht korrekt.
stating that under certain circumstances the Dec motor would trip resulting in a small image shift.V1.25 Fehler beseitigt: In allen bisherigen Software-Versionen war ein Fehler der sich so bemerkbar macht: Wenn eine höhere Betriebsspannung als 12V verwendet wird und wenn M2_Freq2 auf 0 Hz eingestellt ist, dann gibt es manchmal einen kleinen Ruck wenn der Deklinations-Motor anhält. Das fällt insbesondere dann auf, wenn die Getriebeuntersetzung klein ist, und wenn mit einer kleinen Korrektur-Geschwindigkeit gearbeitet wird.
stash is correct about the power consumption of DSLRs as well as all separately powered devices draw hardly any current from the hub.
However beware that non-powered USB2 devices can draw up to 0.5 A and USB3 devices up to 0.9A per port. Using a 10 port hub with a 2.5A power supply might be on the low side.
To complicate things even more the USB-C connector (which I have not seen on astro devices yet but only on cell phones and tablets) may draw up to 3A per port. So don't charge Your cell phone from the same hub when using it for internet connections
And to top all this: USB-PD (USB Power Delivery) may request 5V, 12V or even 20V and up to 5A (= 100W max power) from the charging device! These values are considered for USB connected displays for example. But it will take some time before we see devices like these at our telescopes.
Read More...
This is an answer to a question calberts asked in a
thread on FS2 controllers
. I Thought it better to open a new thread to answer.
Hi Chris,
USB hubs (or rather USB as such) are a major and most annoying topic. You will find an number of concerning topics in this forum
Only recently we tested 7 different powered USB hubs (USB2 as well as USB3) connected to the controlling PC of our public observatory and than connected to two different Fujitsu laptops, all running KStars/EKOS/INDI
.
The hubs were connected to the PC/laptops by high qualitiy "active" 3m USB2 and USB3 cables which had been tested successfully separately with every single device. The hubs then were step-wise "loaded" with a Canon 750D, a QHY5LII mono, a MGen autoguider, and a SonyA7II - no mount controller was attached since that worked over a RS232 serial connection. But I found mount controllers are a minor issue on hubs.
Result of our tests: only 3 out of 7 hubs worked at all with all devices attached (one USB3 hub, the two others were USB2) - but only one of the USB2 hubs worked satisfying when connected to the laptops as well!
Connected to the laptops one or another hub would work with more or less devices attached. Some hubs worked part-time with only some of the devices connected, some combinations of hub and devices failed completely. Different USB cables between hub and devices were tested and these obviously come in different qualities as well. Starting streaming from the QHY also seemed to degrade the stability of the connections. And to some extent bugs or some kind of sensitivity on the side of the INDI drivers might as well interfere and stop devices from working at all.
Our results which, i am afraid, will differ from those of others with different setups, are as follows:
USB2 tends to be more stable/reliable with most devices; hub power should be at least 3,5A at 5V. Use high quality cables as well. The male connectors should fit firmly and not shaky. And make sure not to use a mere charging USB cable! (Happened to us while testing) Streaming devices should connect directly to an USB port at the PC. We believe one has to try out combining material until it works reliable - and that may change with an additional device.
I still wonder how people get these USB devices to work, especially cameras, connected to a RasPi?!
PS: At our observatory we changed to a compact € 300 PC with 10 USB ports that are connected to two internal hubs (USB2 and USB3) and use long (>= 2m) USB cables to connect to the devices. (OK, one USB hub is used to power some cross-hair LEDs).
CS
Michael
Read More...
I confirm this problem.
Only when using the virtual mount controller and manually repositioning the mount closer to the destination coordinates (looking at a highly enlarged KStars view) the status of the mount changes from "slewing" to "tracking". From what I see in my logs Herrhausen has precisely described the probable cause.
At present I have no working setup therefore I can only give some speculative thoughts on this:
- in the FS2 configuration menu there is a choice between two different formats for RA/Dec coordinates. Possibly the selected format has an influence on how the FS2 tries to reposition.
@ Herrhausen: did the lx200basic always successfully change to tracking on consecutive slews? (Just wondering?!)
CS
Michael
Read More...
Thank You, Eric, for clarifying.
And yes, sometimes user don't behave as expected - I ought to know after having developed user applications for some years long ago.
CS
Michael
Read More...
Hi Eric,
thanks for replying that fast.
.
My mount is parked at the meridian at DEC 0° and synchronized with KStars at that position. Comparing the actual sky with the sky map of KStars already showes the offset.How do you observe that the hour angle is offset?
Well, at first look: yes it did. My location is 8° 30' east of Greenwich which I entered as -08 30 in the KStars location settings (as used to from other software).Is your real location really matching the geographic location setting in KStars ?
I came back to KStars/Ekos/INDI just a couple of weeks ago.
Present Problem:
The KStars star map is 1h (15°) late with respect to the meridian. I.E. the hour angle of every object on the star map is off by -1 h.
I checked the system time/date information using the timedatectl command that gave correct values:
=> timedatectl