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.

sgl_imaging_challenge_banner_solar_25.thumb.jpg.f1d5d01d306644f613efd90ef96b314c.jpg

Vox45

Moving to Linux - What works and alternatives

Recommended Posts

Each USB device can have a serial "number" (actually just a string of characters), so in theory at least you could have as many devices as you like with the same VID and PID and still be able to tell them apart by the serial number.  I get the impression that the feature is not widely used however, despite being a far more reliable way of identifying specific devices.  Perhaps because it makes the manufacturing process more expensive?

If the devices are never unplugged then they may always appear at the same position in the USB device tree which might offer an alternative means of identification.  libudev is quite handy for walking the device tree on Linux if you need to do so.

Should anyone have any other nice generic ways to uniquely identify individual instances of identical products connected over USB I'd love to hear them because it would be quite a handy thing to be able to do.

James

Share this post


Link to post
Share on other sites

I use the serial numbers to identify my Atik cameras in the software.

Share this post


Link to post
Share on other sites
2 hours ago, Gina said:

I use the serial numbers to identify my Atik cameras in the software.

They would still have the same GUID in ASCOM and be indistinguishable... Only the direct driver way works, for instance with serial number, but if you load an ASCOM driver and want two instances theyu need to have different GUIDs, so two versions of the driver are needed.

Share this post


Link to post
Share on other sites

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.

Edited by ajk

Share this post


Link to post
Share on other sites

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) 
OK 
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 :) ]

Edited by ajk

Share this post


Link to post
Share on other sites

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.

James

Share this post


Link to post
Share on other sites
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.

James

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

Share this post


Link to post
Share on other sites
3 hours ago, ajk said:

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.

Yes, I've done that sort of thing myself to get my UPS to always connect with the same device name, for instance.  What I don't like about it from an astro point of view though is that it's way outside the comfort zone of the average user, who doesn't want to be editing udev rules files and really, really doesn't want to get involved in debugging them when they don't work for some reason.

What most people really want, I suspect, is to just install a package and have it work without needing to know, for instance, whether installing a udev rules file will just get picked up automagically or if they'll need to force systemd to reload the udev config, or why the system sees their mono Skyris camera and that works without a problem whereas the colour one doesn't at all.  It's very hard to achieve that level of simplicity however, though until software authors do I think Linux-based astro is going to remain quite niche.

(And then there's OSX, where there seems to be a certain level of expectation that the user should just need to drag your installable package to their location of choice and run it and it should all "just work" :)

James

  • Like 1

Share this post


Link to post
Share on other sites

Which explains why Windows is so popular. And people get cross with Windows when it doesn't work. They have no idea how bad it can really get ;)

 

  • Like 3

Share this post


Link to post
Share on other sites
10 hours ago, ajk said:

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)

I did a complete Indi install to a VM a couple of days ago (Ubuntu 16.04, indi-full, kstars-bleeding, gsc, astrometry, etc.) and it all went fine without any problems (and no missing dependencies, no hiccups, no problems).

So I wonder what has changed or if it is related to your VM or something along those lines.

Ian

Share this post


Link to post
Share on other sites

That's good :)  I'm planning to use a Linux box rather than VM anyway so looking good :)

Edited by Gina

Share this post


Link to post
Share on other sites
14 hours ago, ajk said:

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)

I had a similar issue and started a thread on the INDI forum. Someone else also posted this week

" I am running Kubuntu 16.04 LTS, libindi1 installed fine, but could not find package indi-full either. Also a try to install indi-sx failed, no such package."

Answer

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

maybe this is related to the issue you have.

  • Like 2

Share this post


Link to post
Share on other sites
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.]

Edited by ajk
  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, Vox45 said:

we just migrated to GitHub

Ah, this is pleasant music to my eyes (eh, did I mix my metas?). I'm a big fan of Github and it's Fork/PR development workflow.

  • Like 1

Share this post


Link to post
Share on other sites

I went for the ready-made VM... Works great. I am currently adding Qt's development environment in order to at least get a half-decent environment for actually programming. Spoiled by Visual Studio 2015, I am (whatever you think about windows, VS2015 is the most advanced environment out there).

 

/per

  • Like 2

Share this post


Link to post
Share on other sites
On 2 June 2016 at 23:09, ajk said:

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) 
OK 
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 :) ]

 

This is the problem - asicam uses binaries that are provided by the manufacturer for specific architectures, however those like my ARM v8 64bit will fail to build or have a pre-built version in the repository.

 indi-asicam 

Share this post


Link to post
Share on other sites
17 hours ago, ajk said:

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.]

ho the sweet sound of reading this ;) (the game is on)

15 hours ago, ajk said:

Ah, this is pleasant music to my eyes (eh, did I mix my metas?). I'm a big fan of Github and it's Fork/PR development workflow.

Share this post


Link to post
Share on other sites

@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

Share this post


Link to post
Share on other sites
14 hours ago, ajk said:

@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.

 

This is so cool :) thank you for working on this as this was my last hurdle. How do you plan on publishing the driver ? Will it be added to the INDI package ? What is the next step to get it publicly availlable ?

Good timing also as I will receive my Raspberry PI on monday and just finished my powerpanel... This way I can have the RpI and powerpanel at the mount and control from a laptop over WIFI or ethernet if WIFI fails on me ;) no more 5m USB cable or VNC on 2 laptops.

Share this post


Link to post
Share on other sites
29 minutes ago, Vox45 said:

...This way I can have the RpI and powerpanel at the mount and control from a laptop over WIFI or ethernet if WIFI fails on me ...

My limited experience with my RPi3 is that the Wi-fi signal is not great.  I've tested both in and out of case and not a lot different (as my case is metal but has vent holes and I thought it would make a massive difference but it didn't).  Even a few meters from an Access Point and out of the case I'm 1 bar below full signal (though not done any detailed readings yet).  It could be partly because the Wi-fi is only 2.4 GHz and I'm used to good signal at 5GHz (so I've had to put in a few more APs running at 2.4 and most of mine as not dual bandwidth).  Though early days and I've still got more playing around and t look closer at the real data rate (i.e. iwconfig rather than the crude bars in the GUI).  Main concern to this point has been getting everything installed and running.

It works, not getting annoying dropouts.  So solid but where you'd expect to be at full signal full rate, I'm not.  The speed limitations were noticeable when I was testing with my Canon DSLR on 18 megapixel and the test images were taking a fair time to download (RPi->2.4Ghz->cabled net->5Ghz->laptop).

I'm thinking about getting an outdoor access point with a high gain antenna to cover where I set-up my scope.  I need some coverage out there (nothing spilling out from the house).

I find the INDI Web Manager a very useful tool http://indilib.org/support/tutorials/162-indi-web-manager.html.  Avoids having to SSH into the device to start the indi server.Ian

Edited by psamathe
  • Like 1

Share this post


Link to post
Share on other sites
6 hours ago, Vox45 said:

How do you plan on publishing the driver ?

https://github.com/A-j-K/hitecastrodcfocuser

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

Share this post


Link to post
Share on other sites
18 hours ago, psamathe said:

My limited experience with my RPi3 is that the Wi-fi signal is not great.  I've tested both in and out of case and not a lot different (as my case is metal but has vent holes and I thought it would make a massive difference but it didn't).  Even a few meters from an Access Point and out of the case I'm 1 bar below full signal (though not done any detailed readings yet).  It could be partly because the Wi-fi is only 2.4 GHz and I'm used to good signal at 5GHz (so I've had to put in a few more APs running at 2.4 and most of mine as not dual bandwidth).  Though early days and I've still got more playing around and t look closer at the real data rate (i.e. iwconfig rather than the crude bars in the GUI).  Main concern to this point has been getting everything installed and running.

It works, not getting annoying dropouts.  So solid but where you'd expect to be at full signal full rate, I'm not.  The speed limitations were noticeable when I was testing with my Canon DSLR on 18 megapixel and the test images were taking a fair time to download (RPi->2.4Ghz->cabled net->5Ghz->laptop).

I'm thinking about getting an outdoor access point with a high gain antenna to cover where I set-up my scope.  I need some coverage out there (nothing spilling out from the house).

I find the INDI Web Manager a very useful tool http://indilib.org/support/tutorials/162-indi-web-manager.html.  Avoids having to SSH into the device to start the indi server.Ian

Thanks for this heads up. I only plan to use Ekos on the laptop and everything else at the mount, so no need for bandwith to download anything as I will use an SSD hard drive at the mount

Share this post


Link to post
Share on other sites
12 hours ago, ajk said:

https://github.com/A-j-K/hitecastrodcfocuser

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 :) )

Great! I will test this as soon as possible.

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 :)

Share this post


Link to post
Share on other sites
1 hour ago, Vox45 said:

Thanks for this heads up. I only plan to use Ekos on the laptop and everything else at the mount, so no need for bandwith to download anything as I will use an SSD hard drive at the mount

Don't forget auto-guiding (if you are using it) which can require reasonable bandwidth to download the auto-guider images to Ekos.  Or you may be able to use Rapid Guide (depending on your guide camera) where the star location is worked out by the guide camera driver on the RPi and only the star position reported back to Ekos (reducing bandwidth significantly).  The Indi developers have done well keeping Indi "light-weight" (i.e. not requiring mega resources) but it does have a lot of dependencies and there is a rumour about making it much more resource intensive (which will not be good).

Ian

  • Like 1

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

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