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.

randomic

ASI 462MC Raspberry Pi hard-lock

Recommended Posts

UPDATE: This problem seems to specifically occur with my Raspberry Pi 3B. It did not occur with a Raspberry Pi 1.
UPDATE 2: Problem does not occur with Raspberry Pi 4. I do not have a Pi 3B+ but if someone else does and reports their findings I'll edit this post to include them.

 

Just a warning to anyone looking at this camera. Particularly if you're using a Raspberry Pi/Astroberry for your setup:

It seems to be unsupported in most software at the moment, for example: FireCapture, oacapture (an update to support the camera in oacapture is on the way! Thanks to @JamesF)

Additionally when I tried streaming some video from it in kstars once I hit about 10fps it caused kernel problems in the raspberry pi. This could be a hardware problem with my specific raspberry pi or it could be driver related.
The result is the raspberry pi completely locks up, ssh stops responding, clock stops ticking, any executing commands start segfaulting. The only way out is to pull the power.

It would be nice to know if anyone's got this camera working with a raspberry pi in a stable way.

 

Additionally the manual for this camera says the max power consumption is 13.9W, which seems ridiculously high for an uncooled camera. I'm pretty sceptical of this given that it's supposed to be powered through USB3 which is specced at ~900mA @ 5V. If it really was drawing nearly 3A I can't see it ever working from a USB port, nevermind a raspberry pi's.

I've attached some kernel logs in case anyone's interested but this is more of a PSA than a cry for help 😂

trace.log

Edited by randomic

Share this post


Link to post
Share on other sites

Can't you feed the camera power separately?

Maybe you need a bigger power supply for the raspberry pi?

N.F.

 

Share this post


Link to post
Share on other sites

I agree that the power draw is probably a typo, but could still be a power issue. Definitely worth confirming it still happens with a power USB hub.

Share this post


Link to post
Share on other sites

Yeah I definitely haven't ruled it out. I don't have a powered hub at the moment but I'll be getting one. I'm using the stock 2.5A power supply which came with the Pi, should be more than sufficient. It seems to record from a Logitech C920 with no issues (other than high cpu usage).

I was looking at getting a Pi 4 anyway for better performance but I'd rather not do so if it won't work with the camera.

I also have an original Pi 1, although it'll probably run really slowly I might pop the SD card in that just to see if I get the same issue on different hardware.

Share this post


Link to post
Share on other sites

I tried with the Pi1 and although the poor hardware couldn't really keep up with the demands, it didn't lock up in the same way the 3B does. I guess this must be something to do with the hardware.

I'll update the original post to specifically reference the Pi 3B

Looks like I'm ordering a Pi4 sooner than anticipated!

 

Share this post


Link to post
Share on other sites
2 minutes ago, randomic said:

I tried with the Pi1 and although the poor hardware couldn't really keep up with the demands, it didn't lock up in the same way the 3B does. I guess this must be something to do with the hardware.

I'll update the original post to specifically reference the Pi 3B

Looks like I'm ordering a Pi4 sooner than anticipated!

 

Could still be power related - assuming you're using the same PSU, the Pi1 probably uses less power itself. It clearly shouldn't be an issue given your PSU, but Pi's are often sensitive to power, and PSUs designed for phones might be as good as they claim. A different PSU/a powered USB hub would definitely be where I'd start. 

I recently went from a Pi 3 to Pi 4 for Astroberry and it's been a massive improvement - the speed of the interface is now limited by WiFi bandwith  to the garden, whereas the Pi3 creaked a little running Kstars. Plate solving takes <10s, and the download from the camera over USB is a lot better. I got the 4Gb version and never got close to running out of RAM, so you could probably make do with the 2Gb version - I definitely can't see how you'd make use of 8Gb!

  • Thanks 1

Share this post


Link to post
Share on other sites
49 minutes ago, rnobleeddy said:

Could still be power related - assuming you're using the same PSU, the Pi1 probably uses less power itself. It clearly shouldn't be an issue given your PSU, but Pi's are often sensitive to power, and PSUs designed for phones might be as good as they claim. A different PSU/a powered USB hub would definitely be where I'd start. 

I recently went from a Pi 3 to Pi 4 for Astroberry and it's been a massive improvement - the speed of the interface is now limited by WiFi bandwith  to the garden, whereas the Pi3 creaked a little running Kstars. Plate solving takes <10s, and the download from the camera over USB is a lot better. I got the 4Gb version and never got close to running out of RAM, so you could probably make do with the 2Gb version - I definitely can't see how you'd make use of 8Gb!

I was about to reply saying that, unfortunately, I don't have a way to rule out power to hand. But then an epiphany. My PC monitor has a powered USB hub built in. It only has USB 3 slots so I can't rule out some weird USB 2 problem but I'll give it a shot.

Share this post


Link to post
Share on other sites

Aand the lock up happened almost straight away. So I think this rules out power as the issue.

Share this post


Link to post
Share on other sites
54 minutes ago, rnobleeddy said:

I recently went from a Pi 3 to Pi 4 for Astroberry and it's been a massive improvement - the speed of the interface is now limited by WiFi bandwith  to the garden, whereas the Pi3 creaked a little running Kstars. Plate solving takes <10s, and the download from the camera over USB is a lot better. I got the 4Gb version and never got close to running out of RAM, so you could probably make do with the 2Gb version - I definitely can't see how you'd make use of 8Gb!

You read my mind! I was trying to decide on the RAM. I think I might go for the 4GB version anyway just for futureproofing. Very excited for 10s platesolves, it can easily take 2 minutes+ for me at the moment.

Share this post


Link to post
Share on other sites
On 16/10/2020 at 20:04, randomic said:

It seems to be unsupported in most software at the moment, for example: FireCapture, oacapture

I'd guess that's because there's a new release of the ZWO SDK that I've not got built into oacapture.  I'll make sure that's done for the next release.

James

  • Thanks 1

Share this post


Link to post
Share on other sites
59 minutes ago, JamesF said:

I'd guess that's because there's a new release of the ZWO SDK that I've not got built into oacapture.  I'll make sure that's done for the next release.

James

Amazing! Thanks so much! Is it built into the binary or is there a directory I can drop the new so to test it out locally?

Share this post


Link to post
Share on other sites

Got a Raspberry Pi 4 and the lockup issue seems to not happen anymore. There is some weirdness about data acquisition rates though: if I set a target fps of 20 I get roughly 20, any faster and it starts wildly oscillating, averaging between 10 and 2. (In kstars) Additionally, dmesg gets spammed with messages about the usb device getting "reset". From what I understand, this is normal with ZWO cameras when changing configuration but not during capture.

Hoping this is just teething troubles with the drivers/sdk, it is certainly useable now.

I'll keep updating this thread with any new info I find but for now the main issue is resolved by not using a Raspberry Pi 3B

Share this post


Link to post
Share on other sites
5 minutes ago, randomic said:

Amazing! Thanks so much! Is it built into the binary or is there a directory I can drop the new so to test it out locally?

oacapture should just pick the library up if it is installed (and it will use the INDI version if it is present), so you should be able to change it if you want.  Unfortunately I don't know where the version that comes with INDI is on an RPi as I don't have it installed on any of mine :(

What you might be able to do is to download the latest SDK and extract it and then set the LD_LIBRARY_PATH environment variable to the directory containing libASICamera2.so, then run oacapture:

$ export LD_LIBRARY_PATH=<path-to-directory>
$ oacapture

I'm not 100% sure that will work, but it's worth a try.

  • Thanks 1

Share this post


Link to post
Share on other sites
3 minutes ago, JamesF said:

oacapture should just pick the library up if it is installed (and it will use the INDI version if it is present), so you should be able to change it if you want.  Unfortunately I don't know where the version that comes with INDI is on an RPi as I don't have it installed on any of mine :(

What you might be able to do is to download the latest SDK and extract it and then set the LD_LIBRARY_PATH environment variable to the directory containing libASICamera2.so, then run oacapture:


$ export LD_LIBRARY_PATH=<path-to-directory>
$ oacapture

I'm not 100% sure that will work, but it's worth a try.

It's not quite happy with sdk version v1.15.0915 for whatever reason. Here's the log output:

astroberry@astroberry:~ $ LD_LIBRARY_PATH=/usr/lib/arm-linux-gnueabihf oacapture
libEGL warning: DRI2: failed to authenticate
qt5ct: using qt5ct plugin
qt5ct: D-Bus global menu: no
Unrecognised camera ''
open of camera 0 failed

Happy to do any further testing if it's useful to you.

Share this post


Link to post
Share on other sites

Hmmm.  Not sure what might cause that at the moment.  I'll have to give it some thought.

James

  • Thanks 1

Share this post


Link to post
Share on other sites

With the camera plugged in, could you give me the results of running "lsusb", please?

Thanks,
James

Share this post


Link to post
Share on other sites
9 hours ago, JamesF said:

With the camera plugged in, could you give me the results of running "lsusb", please?

Thanks,
James

astroberry@astroberry:~ $ lsusb
Bus 002 Device 002: ID 03c3:462b  
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
astroberry@astroberry:~ $ lsusb -vs 2:2

Bus 002 Device 002: ID 03c3:462b  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         9
  idVendor           0x03c3 
  idProduct          0x462b 
  bcdDevice            0.00
  iManufacturer           1 ZWO
  iProduct                2 ASI462MC
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x001f
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              512mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength       0x0016
  bNumDeviceCaps          2
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000002
      HIRD Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   3
      Lowest fully-functional device speed is SuperSpeed (5Gbps)
    bU1DevExitLat          10 micro seconds
    bU2DevExitLat        2047 micro seconds
can't get debug descriptor: Resource temporarily unavailable
Device Status:     0x000c
  (Bus Powered)
  U1 Enabled
  U2 Enabled

If I'm interpreting this correctly, it seems to not report a device name

Share this post


Link to post
Share on other sites

Thanks for that.  I often wonder myself if I'm interpreting the output of lsusb correctly :D

James

  • Haha 1

Share this post


Link to post
Share on other sites
On 21/10/2020 at 09:42, JamesF said:

Thanks for that.  I often wonder myself if I'm interpreting the output of lsusb correctly :D

James

Out of boredom I built oacapture from source this afternoon and you'll be pleased to know that the ASI462MC is now recognised correctly. It seems to work fine although only manages to record at 6 fps.

On a semi-related note, is a 67 frame SER supposed to be ~500MB?

Share this post


Link to post
Share on other sites

Each frame from the 462MC as it comes off the camera is going to be just over 2MB I think.  If it's converted to RGB rather than stored as raw colour then that will triple, so 67 frames would be over 400MB plus the overheads of the file format (probably not much for 67 frames).  So you're probably in the right ballpark there.

Reducing the frame size or not converting the frame to RGB would probably improve performance, and you'd not need to save so much data.

I have been wondering if the demosaic process might be something suitable for pushing off onto a GPU.  Definitely something to look at for the future.

James

Share this post


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

So you're probably in the right ballpark there.

Hot damn, I'd better make sure I crop the frame!

Share this post


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

I have been wondering if the demosaic process might be something suitable for pushing off onto a GPU.

Hypothetically, couldn't everything happen on the gpu? Since as long as the frames end up in the right order it doesn't matter in what order they're processed (assuming you don't run out of vram).

Share this post


Link to post
Share on other sites
2 minutes ago, randomic said:

Hypothetically, couldn't everything happen on the gpu? Since as long as the frames end up in the right order it doesn't matter in what order they're processed (assuming you don't run out of vram).

My understanding is that some jobs work well on a GPU whilst others don't, depending on the nature of the code.  I suspect most raw colour to RGB conversions can be done with a kernel for combining pixels, so I think that might work well.  It's a bit of a moot question at the moment however, as I don't currently have a suitable GPU to work with.

James

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

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