Jump to content

SkySurveyBanner.jpg.21855908fce40597655603b6c9af720d.jpg

Raspberry Pi 3 Model B+ problem !


halli

Recommended Posts

maybe the software updater does something that as you say update and upgrade does not work I found that out the other day as software updater updated indilib I found that strange also. but great you are up and running JamesF sorry my cameras are Qhy and imaging source plus my canon so unable to help hope you get it sorted with the help from Ian

Andy

Link to comment
Share on other sites

  • Replies 277
  • Created
  • Last Reply
25 minutes ago, JamesF said:

If you're comfortable doing this, it would be very handy to know what is displayed if you open a terminal window on the Rpi (with the camera plugged in) and enter the command "lsusb", so I can check that we have the same USB vendor and product IDs.  If that's pushing you out of your comfort zone then no problem :)

Hi James   - 5 devices came up when I performed the lsusb command, 3 were standard microsystems corp, one was Linux foundation and the other was Anchor chips , Inc.

Not sure why there is so many as Ive only the GPCAM plugged in but they may be to do with the Pi USB  hub I guess.

Looks like it may be the Anchor chips as I unplugged the camera and this disappeared

The product ID is 0547:b121 - is that all you need ?

5 minutes ago, fozzybear said:

Happy to have helped that's why we are here Gosh I have been stuck a few times and good old SGL comes to My rescue

Yes - its a very complex hobby and there is nothing worse than an impasse !

 

Link to comment
Share on other sites

10 minutes ago, halli said:

Hi James   - 5 devices came up when I performed the lsusb command, 3 were standard microsystems corp, one was Linux foundation and the other was Anchor chips , Inc.

Not sure why there is so many as Ive only the GPCAM plugged in but they may be to do with the Pi USB  hub I guess.

Looks like it may be the Anchor chips as I unplugged the camera and this disappeared

The product ID is 0547:b121 - is that all you need ?

Yes - its a very complex hobby and there is nothing worse than an impasse !

 

just to add I also have 3 standard microsystems plus one linux foundation and the rest related to my wireless keyboard gps dongle ( I currently don't have my cameras  attached as left on next to my pc to help Ian if needed) so same as you then

Link to comment
Share on other sites

17 minutes ago, fozzybear said:

maybe the software updater does something that as you say update and upgrade does not work I found that out the other day as software updater updated indilib I found that strange also. but great you are up and running JamesF sorry my cameras are Qhy and imaging source plus my canon so unable to help hope you get it sorted with the help from Ian

Andy

I think the updater does an apt-get dist-upgrade (or is it full-upgrade these days?). dist-upgrade does a more complete job than an upgrade but apart from that I'm not that clear on the difference.

The Altair is indeed the Anchor device. There are two drivers that can work with it. The Altair and  the Toupcam/Touptek drivers should both work. The Altair is a rebadged Toupcam and its driver is basically identical except it has call like Altair_put_option vs Toup_put_option. The Toupcam driver had issues with color a short while back but those appear to have been fixed. I think I saw a comment that the two drivers will be merged so they can be kept in synch.

Added. Plus the linux code provided by Touptek is being updated pretty regularly in response to the likes of INDI and PHD2 devs. These may take a while to filter through to Altair.

Link to comment
Share on other sites

21 minutes ago, kens said:

I think the updater does an apt-get dist-upgrade (or is it full-upgrade these days?). dist-upgrade does a more complete job than an upgrade but apart from that I'm not that clear on the difference.

The Altair is indeed the Anchor device. There are two drivers that can work with it. The Altair and  the Toupcam/Touptek drivers should both work. The Altair is a rebadged Toupcam and its driver is basically identical except it has call like Altair_put_option vs Toup_put_option. The Toupcam driver had issues with color a short while back but those appear to have been fixed. I think I saw a comment that the two drivers will be merged so they can be kept in synch.

Added. Plus the linux code provided by Touptek is being updated pretty regularly in response to the likes of INDI and PHD2 devs. These may take a while to filter through to Altair.

just looked on indilib forum and they say to type "sudo apt-get install indi-full gsc" to install the latest library releases does this include driver's? having first done a "sudo apt-get update"

https://indilib.org/download.html

I have searched high and low on the indilib web site and when they say they released an update they do not tell you how to effect the update for us lay person's they tell you all about what has been amended and included but do not tell you how that maybe is why a lot off people who are not familiar with linux commands give up or face a brick wall I was at first....

 

Link to comment
Share on other sites

1 hour ago, halli said:

Hi James   - 5 devices came up when I performed the lsusb command, 3 were standard microsystems corp, one was Linux foundation and the other was Anchor chips , Inc.

Not sure why there is so many as Ive only the GPCAM plugged in but they may be to do with the Pi USB  hub I guess.

Looks like it may be the Anchor chips as I unplugged the camera and this disappeared

The product ID is 0547:b121 - is that all you need ?

That's perfect, thank you.  It is indeed the correct camera.  Anchor chips make the USB interface hardware for these cameras I believe, and whilst you're supposed to change the ID if you use them in another product  (because what happens if someone else doesn't bother either and uses the same ID as your hardware?), sometimes that just doesn't happen.

Strangely, my model of the same camera does not have the same vendor/product ID pair.  Mine is 16d0:0b2a.  Which might go some of the way to explaining why yours works and mine doesn't.

Thanks again for your help,

James

Link to comment
Share on other sites

1 hour ago, kens said:

I think the updater does an apt-get dist-upgrade (or is it full-upgrade these days?). dist-upgrade does a more complete job than an upgrade but apart from that I'm not that clear on the difference.

The Altair is indeed the Anchor device. There are two drivers that can work with it. The Altair and  the Toupcam/Touptek drivers should both work. The Altair is a rebadged Toupcam and its driver is basically identical except it has call like Altair_put_option vs Toup_put_option. The Toupcam driver had issues with color a short while back but those appear to have been fixed. I think I saw a comment that the two drivers will be merged so they can be kept in synch.

I have the impression that the current Altair library is just a rebuild of the Touptek one with additional entry points for "Altair_..." that just redirect to the standard Touptek entry points.  Oh, and the camera name strings and USB IDs are different, obviously.

James

Link to comment
Share on other sites

One to remember too, when a new version of INdI is being built, the updater won’t install it, so there may have been a crossover when you did your update, whereas now you have done again and it’s worked...

I did think all along it was an updater problem, and looking at your images, it enforced that even more...

Glad you got sorted now.. :)

Link to comment
Share on other sites

4 hours ago, JamesF said:

I have the impression that the current Altair library is just a rebuild of the Touptek one with additional entry points for "Altair_..." that just redirect to the standard Touptek entry points.  Oh, and the camera name strings and USB IDs are different, obviously.

James

That’s right. I don’t think the USB IDs matter. Sharpcap always recognised my rebadged Toupcam as an Altair and offered the Pro version for free. The Altair library, being a rebuild, will lag behind the Toupcam releases. 

Link to comment
Share on other sites

Just to close off on the Altair camera support issue, last night my brain was looking for something to do so I picked apart the code in the Altair library and found the section that recognises which cameras it will support.

It appears that only cameras with a USB vendor ID of 16d0 and 0547 are supported, which is probably as I'd expect since these are the only two USB vendor IDs associated with Altair cameras that I know of.  However, in the table of product IDs it appears that my camera's ID (0b2a) does not appear, whilst some others of similar vintage do.  I don't have an exhaustive list of Altair product IDs, but I believe some others that may have been supported in the past are not present either.  I'd therefore cautiously suggest that my camera isn't supported and in general one can't know ahead of time whether any other camera is supported unless someone else has already confirmed that it does work (and as similarly branded models may have different USB vendor ID/product ID pairs, even knowing it's the same model as another working one may not be sufficient).

I have raised the issue of my camera not being supported on the Altair google group over the last week or so, but thus far have met with stony silence.  From comments elsewhere on SGL this wouldn't appear to be uncommon.

I may be able to hack the library to enable support for my camera and quite possibly I'll give that a go.  Or if I get no response from Altair over the next few weeks perhaps I'll take it up with Touptek directly and see if I can get any joy from them.

James

Link to comment
Share on other sites

And I've just received a message from Altair saying that "legacy cameras are not supported in the new Linux SDK".  I've asked which cameras are actually considered legacy cameras, otherwise people could waste a lot of time trying to get cameras to work when they aren't supported.

James

Link to comment
Share on other sites

45 minutes ago, stash_old said:

Strike them off my list when looking for a new camera - none of he camera's are that old IMO.

It's not to my taste either, but seems to be endemic in our modern consumerist throw-away society.  I'm aware that people have been asking QHY for their libqhyccd project (which again ties in with INDI) to support older cameras and the response has been along the lines of "We don't possess any of  those any more, we've lost the source code for the firmware, we don't have a copy of the driver, we can't do it".

I spent a "happy" few hours last night twisting things about so my major interest (oacapture etc.) will work with my Altair camera and I can still use the most recent driver library where it supports the camera, but it's a bit nasty.  I have thought of another way to do it, but that involves patching the executable once it's running, which is even nastier and not exactly portable.  Perhaps if I'm really bored one day I'll just bite the bullet and write my own open-source driver for it.

James

Link to comment
Share on other sites

Just a quick update on my Astroberry imaging rig progress

Have successfully connected EQMOD,  ASI1600mm-c,  ATIK EFW2 and ALtair GPCAM.  The USB hub on the ZWO is quite useful as it means I have only one USB connection to the Pi as the EQMOD is via bluetooth.    I have downloaded Kstars for windows and now able to connect to the Pi with Kstars/Ekos  on my desktop as a client and my mount tracks and slews under Kstars control fine

I noticed that in the CCD and filter wheel page of Ekos where you set the image capture sequence - it does not appear to be possible to change the sequence from performing the capture for each filter wheel completely (say 'x' times) before moving on to the next position or going through each filter position eg L,r,g,b one at a time then repeating the complete sequence 'x' times.  The latter is normally set by  setting it as a vertical plan in APT.   I may have missed it though !

I will also miss the EQMOD polar alignment feature as it is nice and simple and works very well for me.  I can always do this as a manual activity outside Astroberry I guess.

Next step is to move the rig outside for some field tests under a dark sky to get the guiding working and to try and capture some images also have a muck around with the plate solving function which I find essential.  The weather tomorrow looks promising so I may be able to try then.

Also I normally use a LAN connection extended via some PLC mains interface kit  to my router in the house so also need to get that form of connection working with the Pi as the wifi wont quite reach !

In summary Astroberry looks quite feature rich and stable and Im not sure what else I would get from Stellarmate !   

 

 

Link to comment
Share on other sites

1 hour ago, halli said:

In summary Astroberry looks quite feature rich and stable and Im not sure what else I would get from Stellarmate ! 

May I suggest its time to get yourself onto the Indilib forum - if you haven't already done so, to leave your thoughts and wishes there ?

Link to comment
Share on other sites

Hah!  Engage "smug mode".

Whilst waiting for some water to heat for a shower this evening I have hacked up something in oacapture which can be used to patch the new Altair library so it supports my camera, at least on Linux x86.  Nasty as modifying code whilst it's executing is, it is quite a simple process in this case.  Doing the same for MacOS shouldn't be too hard.  The 32-bit and 64-bit RPi versions might be more tricky as I don't speak ARM assembler, but how hard can it be? :)

I believe the same process should work for INDI too, should anyone wish to take my code and try it there.  I'll check it into github a bit later.

James

Link to comment
Share on other sites

19 minutes ago, JamesF said:

Hah!  Engage "smug mode".

Whilst waiting for some water to heat for a shower this evening I have hacked up something in oacapture which can be used to patch the new Altair library so it supports my camera, at least on Linux x86.  Nasty as modifying code whilst it's executing is, it is quite a simple process in this case.  Doing the same for MacOS shouldn't be too hard.  The 32-bit and 64-bit RPi versions might be more tricky as I don't speak ARM assembler, but how hard can it be? :)

I believe the same process should work for INDI too, should anyone wish to take my code and try it there.  I'll check it into github a bit later.

James

James,

I envy you I know no programming language yet I still struggle with french. Good on you mate it is all foreign to me. Great job

Link to comment
Share on other sites

3 hours ago, halli said:

I noticed that in the CCD and filter wheel page of Ekos where you set the image capture sequence - it does not appear to be possible to change the sequence from performing the capture for each filter wheel completely (say 'x' times) before moving on to the next position or going through each filter position eg L,r,g,b one at a time then repeating the complete sequence 'x' times.  The latter is normally set by  setting it as a vertical plan in APT.   I may have missed it though !

I will also miss the EQMOD polar alignment feature as it is nice and simple and works very well for me.  I can always do this as a manual activity outside Astroberry I guess.

re: filters. You can set up the filter sequence in the Capture module and save it in a file. In the Scheduling module you can then run that sequence any number of times.

EKOS has one similar to Sharpcap in that it uses plate solving near the pole to determine where the RA axis is pointing. There's also 3 PA tools in PHD2. These all use your guide scope or imaging scope rather than the polar scope.

Link to comment
Share on other sites

Thanks Ken. 

Ah yes I see now how you can change the mode of the capturing sequence  - very useful !

Wrt polar alignment I guess everyone has their favourite method  - Im just used to using EQMOD as its quite transparent and straightforward .  I will give the Ekos method a go if I have a chance. 

Its a shame we dont have enough imaging hours in the UK and there is always pressure to use the time imaging instead of trying new techniques when you know the ones you use work already !  

Cheers

Ian

Link to comment
Share on other sites

Question for Ian,

On Astroberry do you login via vnc or via a web browser the reason I ask is via web browser my keyboard has stopped working i.e opening firefox on rpi unable to type anything it is as I have some sticky-key option. yet if open a terminal window I am able to type. weird? Yet via vnc ok.

Andy 

Link to comment
Share on other sites

46 minutes ago, RadekK said:

Hi there!

I have just joined the forum so all Astroberry issues will be resolved on the spot now ?

Clear skies!

Radek Kaczorek
Astroberry Server | NEQ6 | Atik 460EX | Atik EFW2 | ASI 120MM

Radek,

Please for the life of me a strange problem if I use my browser on my pc then goto astroberry:local I login i cannot press enter key to accept password i have to use the mouse button to validate password also when opening web browser enter key not working and other keys for that matter. I've checked my keyboard layout and lang on rpi but when try to update languages it goes of to update then fails.

Do i have to reimage my sd card as something is going wrong?

Andy

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.