Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.



  • Content Count

  • Joined

  • Last visited

Posts posted by ajk

  1. Thanks for starting this thread. I'm just starting out getting into this subject, totally new for me. I will have my yagi mounted this weekend (a 2m for Graves and a 6m for BRAMS). Unlike you people however, I'll be using my dongles with home made code using GNU Radio. My intention is to build a simple standalone recording system using either a ROCK64 or Raspberry Pi 3 B+ but that's some way off yet, I have a lot to learn. Forum threads like these are very useful indeed!

    • Like 1

  2. On 10/16/2016 at 19:36, johnrt said:

    Hmm, that's not good to hear Stuart, Alignmaster was going to be my next option, my AZEQ6 does have some backlash especially in DEC.

    Hmm indeed, my AZEQ6 also has backlash in DEC.

    I am lucky enough to use a Polemaster as the trees to my north are still low enough for the Polaris view (and should stay that way as they seem to have maxed out).

    I saw the other two photos you posted, you really are hemmed in there @johnrt

    The Alignmaster was just a suggestion, I haven't actually tried it but seem like the only computerised alternative to a Polemaster which could have helped. It's a shame others have noted it has issues.

  3. 10 hours ago, Vox45 said:

    Just for my understanding, when you say out of tree does this mean that it is not yet included in the INDI project but will be in the future ? I can't wait to see your work added to the list of supported hardware on the official INDI page

    Correct. I will do the work to ask Indi maintainers to pull it into their repo at some point, but before I do that I need at least another pair of eyeballs on it, that's where you come in :)

    I fully expect feedback from you in the form "this doesn't work", "this doesn't work as I expect" or "this is great! But can I also have it do foo as well please?". Lets get it polished up. Then we'll go for inclusion in the main code base of Indi :)


    • Like 1

  4. 6 hours ago, Vox45 said:

    How do you plan on publishing the driver ?


    Note, I did an "in tree build" with the INDI source tree. The repo up there is an "out of tree" build. Let me know how you get on (please use the Github issue tracker and not this forum thread to discuss the driver, building and installing as that way future people will find the discussions we have in the right place, where the code is, buried in a forum here helps no future people :) )

    • Like 1

  5. @Vox45 @JamesF @perfrej @Gina

    OK, I have a working version of the HitecAtroDCFocuser now. Well, it moves anyway. Can control the slew speed and number of steps. 

    The HitecAstro software allows for the slew speed to be set from 1 to 100. I matched this. However, I have found that values below 25 don't appear to deliver enough power to the motor to overcome even it's own gear train (found with my Indi driver and their own branded software). However, I will leave the min/max at 1/100 as per their software as other people may have different tolerances on their hardware (btw, I am using a 10 Amp bench power supply so it's not a dead battery!).

    On a side note, I am going to start working on Indi more. In discussions with the maintainers I am starting by adding unit/integration tests and Travis CI integration. Fun times ahead :)


    • Like 1

  6. 3 hours ago, Vox45 said:

    " we just migrated to GitHub and re-building the whole packages again, so please try again in a day or two." 

    I will wait a day or two then.

    In the mean time you'll all be glad to hear I now have the USB HID Class Reports for controlling the focuser :)  It was pretty basic.

    [edit: by reverse eng using an Ellisys Explorer. I haven't heard back for HitecAstro officially.]

    • Like 1

  7. 1 minute ago, JamesF said:

    The only thing that immediately springs to mind is that perhaps you have an x86 VM and the indi-asicam package is only 64-bit (or the other way around)?  Either that or it just can't find the indi-asicam package.


    I always use 64-bit. It seems they have a package they simply cannot build for what ever reason and so 3rd Party code (full-indi) cannot be installed.

    On a side note I downloaded the code from SF (trunk) and I managed to build Indi Core at least. However, without being able to install kstars-bleeding (which itself needs indi-fiull) there's no point me carrying on with this. I will trash this VM and wait for the Kubuntu ISO to download and try that out. If that fails I'll have to email the maintainers. Not good given this is "step one" and many steps. Despite being a huge advocate of FOSS this is the one thing that annoys me about it, it's a time sink. And people complain about Windows. Windows "still wins" because a) it's easy and ii. for the most part "it just works" and doesn't totally sink your time (I've been at this ALL NIGHT and not jumped the first hurdle and I'm suppose to be a super-techie/developer/nurd, goodness help normal non-techie users)

    • Like 3

  8. So, installing INDI. I had some Ubuntus lay about but failed to install, I noticed INDI wanted 15.04 minimum for their latest code.

    So, download 16.04 Ubuntu ISO. Hour later and the VM is running. Let's install INDI now....

    root@ubuntu:~# apt-add-repository ppa:mutlaqja/ppa  
      Latest INDI Library and drivers!  More info: https://launchpad.net/~mutlaqja/+archive/ubuntu/ppa 
      Press [ENTER] to continue or ctrl-c to cancel adding it 
    gpg: keyring `/tmp/tmp_y2chf3d/secring.gpg' 
    created gpg: keyring `/tmp/tmp_y2chf3d/pubring.gpg' 
    created gpg: requesting key 3F33A288 from hkp server keyserver.ubuntu.com 
    gpg: /tmp/tmp_y2chf3d/trustdb.gpg: trustdb created 
    gpg: key 3F33A288: public key "Launchpad INDI" imported 
    gpg: Total number processed: 1 
    gpg:               imported: 1  (RSA: 1) 
    root@ubuntu:~# apt-get update 
    <snipped lots of updates>
    root@ubuntu:~# apt-get install indi-full 
    Reading package lists... Done 
    Building dependency tree       
    Reading state information... 
    Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: 
    The following packages have unmet dependencies:  
      indi-full : Depends: indi-asicam but it is not installable 
    E: Unable to correct problems, you have held broken packages. 

    I believe this is the main reason people pay for Windows (whilst students with plenty of free time don't). If someone wants to let me know when Indi becomes installable on Ubuntu I will continue with the focuser driver development. (And please no, don't ask me to use another distro, if it doesn't work on Ubtunu it's "too exclusive" a requirement for me).

    [edit: yes, I Googled it and nothing obvious sprang up in the way of a fix for Indi. I guess I could get the source code and compile from scratch but I'd like the main user installs to at least work before putting effort into a project]

    [edit2: developer manual recommends Kubuntu (http://www.kubuntu.org/getkubuntu/) for actual development. Downloading ISO now and will try that. If it works then this would be my recommended distro if you want to use Indi. If it doesn't work I'll ping the maintainers and bark at them a bit :) ]

  9. James, I know about the serial number etc. It's as @perfrej points out, it's ASCOM that hasn't been built to allow for arrays of similar devices so HitecAstro have had to work around the short coming by making them look like two different devices.

    And about the devices appearing in different places when you plug/unplug. True, but on Linux you can use the device mapper to use the vid/pid/serial-num to remount the device repeatedly in the same place :) Just Google for device mapper and serial ports and there will be plenty of howtos for doing that.

    I suspect INDI will probably handle arrays of similar devices better than ASCOM but I am yet to find out, cross that bridge when I get there.

  10. 6 hours ago, perfrej said:

    That is so that they can use two instances of an ASCOM driver. ASCOM does have the slight disadvantage of only permitting one device per GUID, but on the other hand, if you had two focusers with the same data in the hardware description, how would you keep track of which focuser is which? You really need to give them separate IDs some way.



    So ASCOM is the pinch point in it all. Not used Indy yet, we'll see if they have the same issue.

  11. 18 minutes ago, psamathe said:

    If it were me I'd be going for the Indi driver route

    I intend to. The focuser presents itself to the OS as a HID Class device and it loads up a standard driver anyway. All that needs reverse engineer here is the command structure they are using. In essence "what button press/wheel spin represents what control of the focuser?"). No bespoke USB code required so the Indy driver would be the natural route.

    • Like 1

  12. 1 minute ago, JamesF said:

    I'm fairly sure that's not enforceable in Europe.  As far as I recall there's a European Directive that effectively enshrines in law the user's right to reverse engineer software and those rights can't be taken away by the EULA.

    Generally, if I cannot affords a lawyer to clarify this in court and I may loose I prefer not to engage.

  13. Ian

    Yeah, I can understand that point of view. I may email themselves so "present my CV" so they can have some faith (I've been writing device drivers in C and Assembler for 30 odd years now).

    One thing does pop out at me though. They sell a second DC Focuser with an alternative PID code and separate driver install so people can use two focusers at the same time. Strictly speaking this isn't how you are suppose to implement USB devices (image not being able to use two or more printers/serial ports/etc of the same type). So, they either did what they did to save of development costs at the expense of wasting a PID or they don't fully understand the USB specification (my guess is the former as it's cheapest simplest solution). Until you want to add a third focuser that is :)


    • Like 1
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.