×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

ASI178 Camera Performance on Rasperry PI 4

  • Posts: 28
  • Thank you received: 17
Anyone interested in this topic?
Is the subject of Raspberry PI still not popular in astrophotography with high-speed cameras?

Over the past weeks, I have analyzed a large part of the LibASICamera2.a library. The most important classes of CCameraFX3 and CircBuf have not been properly implemented for their intended purpose.
For example, the startAsyncXfer method sets up bulk transfers to usb, and then waits for them to be processed, without preparing any more transfers. Then the data is copied in the CircBuf class.
The authors used asynchronous libusb functions to create synchronous communication.

Initial tests of the wrapped library showed that I was able to achieve the full throughput (60fps) without any problems.

My suggestion is to write an overlay to the library to provide asynchronous communication and queuing of buffer pointers,
as well as the new ASIGetVideoDataPointer function to get a data buffer without duplicating data unnecessarily.
Possibility to monitor the size of the queue so that the data from usb up to processing is in the same buffer (streammanager class in Indi).
I also think it is possible to be compatible with new libAsiCamera2 releases.
The following user(s) said Thank You: Jasem Mutlaq, Alfred, Jim, Karsten Buxtehude
3 years 4 months ago #63624

Please Log in or Create an account to join the conversation.

  • Posts: 220
  • Thank you received: 27
Pawel,

this is interesting stuff and you are doing a great job. I have never got this camera to work properly on Linux systems (even the big ones). That's why I still need a W10 box for Solar work (high frame rate/16bit). On the same computer (AMD 1500, USB3.1 under W10 it works without any glitch, but had to get rid of W10-2004) If on the same hardware I run a 64bit Ubuntu mate, lots of errors and dropped frames. (Usuallt error 11 from the ASi libs under firecapture) If I drop the the USB limit to 80 it gets better, but in 16bit capture I don't get the same performance as in W10.

If you have a solution for that, it would be very helpfull getting rid of microsoft. (Maybe if you have a solution you should contact Sam at ZWO)

Regards,

Paul
3 years 4 months ago #63625

Please Log in or Create an account to join the conversation.


That's extremely promising results Pawel! I also agree with Paul that this should also be communicated back to Sam to see if they can improve it on their end. Nevertheless, it would great to try this out. How can we test this now?
3 years 4 months ago #63627

Please Log in or Create an account to join the conversation.

  • Posts: 28
  • Thank you received: 17
Currently, the library wrapper is intended to verify proof of concept on the ARMV8 architecture and ASI178M camera.
Now I'm trying to unify the library for each camera and architecture. Additionally, I have to get rid of one more redundant copy in the GetImage method.

Without library sources, I have a lot of work to do decompiling and creating new code to be easily injected.

Main issues of the library from ZWO:
  • synchronous USB communication.
  • incorrectly handled communication errors - one error causes an avalanche of errors.
  • too much data copying (3x per frame).
  • I suspect the inability to run several cameras on the same instance of the library (common static variable)

On Raspberry PI, the biggest problem is data copying.
The copying speed is ~ 1400 - 2000 MB / s.
The original library does 3 copies per frame + a copy in libusb from USB.
$ make && ./asitest Exposure 10000 HighSpeedMode 1 BandWidth 100 Gain 100
g++ -o asitest main.cpp -I./libasi/include -I./ -lpthread -lusb-1.0 ./libasi/lib/armv8/libASICamera2.a -Wl,--wrap=memcpy -O2
Set 'Exposure' is 10000
Set 'HighSpeedMode' is 1
Set 'BandWidth' is 100
Set 'Gain' is 100
[!!!] Big copy detected: 6439680 Bytes
[!!!] Big copy detected: 6439680 Bytes
[!!!] Big copy detected: 6439680 Bytes
timeframe:   280ms                                 <--- issue
[!!!] Big copy detected: 6439680 Bytes
[!!!] Big copy detected: 6439680 Bytes
[!!!] Big copy detected: 6439680 Bytes
timeframe:   546ms                                 <--- issue
[!!!] Big copy detected: 6439680 Bytes
[!!!] Big copy detected: 6439680 Bytes
[!!!] Big copy detected: 6439680 Bytes
timeframe:   546ms                                 <--- issue

For a 6MB frame, at 60fps this is 6MB * 4 * 60 = 1440MB/s

Speed ​​test for Raspberry PI 4 (64bit userland)
$ ./ramspeed 6
std::vector, size: 6 MB, copy: 0.0043 s, speed: 1396.592 MBps
std::vector, size: 6 MB, copy: 0.0042 s, speed: 1416.900 MBps
memcpy, size: 6 MB, copy: 0.0039 s, speed: 1544.185 MBps
memcpy, size: 6 MB, copy: 0.0039 s, speed: 1546.861 MBps
 
$ ./ramspeed 6
std::vector, size: 6 MB, copy: 0.0025 s, speed: 2403.668 MBps
std::vector, size: 6 MB, copy: 0.0025 s, speed: 2409.675 MBps
memcpy, size: 6 MB, copy: 0.0025 s, speed: 2374.098 MBps
memcpy, size: 6 MB, copy: 0.0025 s, speed: 2378.751 MBps

A large number of copies causes the loss of data from the USB.
Each frame in my case consists of 7 transfers (bulk). If one of them is "damaged" the library cannot handle it in an elegant way.
Apart from the fact that there is no copy space in other programs or on the system.

I think in 2 weeks, I will be able to publish my work.
I still had to eliminate one copy per frame and a lot of tests.
./asitest-boost Exposure 10000 HighSpeedMode 1 BandWidth 100 Gain 100
[ASIOpenCamera]: grab CameraID 0
[libusb_open]: grab libusb_device_handle 0x559d731cd0
[CCameraBase::InitVariable]: grab CCameraBase 0x559d73c9b0
[CirBuf::CirBuf]: link CirBuf 0x559d73afe0 and CCameraBase 0x559d73c9b0
[CirBuf::CirBuf]: link CCameraBase 0x559d73c9b0 and libusb_device_handle 0x559d731cd0
[CirBuf::CirBuf]: link iCameraID 0 and CCameraBase 0x559d73c9b0
Set 'Exposure' to 10000
Set 'HighSpeedMode' to 1
Set 'BandWidth' to 100
Set 'Gain' to 100
[CameraBoost::CameraBoost]: created
[CCameraFX3::initAsyncXfer]: init CameraBoost device 0x559d731cd0, endpoint 0x81, buffer size 6439680
[CirBuf::ReadBuff]: 1 1 0x7f7e85f010
[!!!] Big copy detected: 6439680 Bytes
timeframe:   261ms                       <---- warming up
[CirBuf::ReadBuff]: 2 2 0x7f7c15a010
[!!!] Big copy detected: 6439680 Bytes
timeframe:    16ms                        <---- yeah!
[CirBuf::ReadBuff]: 3 3 0x7f778ff010
[!!!] Big copy detected: 6439680 Bytes
timeframe:    17ms                        <---- yeah!
[CirBuf::ReadBuff]: 4 4 0x7f771fe010
[!!!] Big copy detected: 6439680 Bytes
timeframe:    17ms                        <---- yeah!
[CirBuf::ReadBuff]: 5 5 0x7f7c15a010
[!!!] Big copy detected: 6439680 Bytes
timeframe:    16ms                        <---- yeah!
[CirBuf::ReadBuff]: 6 6 0x7f778ff010
[!!!] Big copy detected: 6439680 Bytes
timeframe:    16ms                        <---- yeah! 60 fps
....

By queuing buffers and passing pointers, there will also be some work with the Indi library to take advantage of the new possibilities.
I will also add the ability to restore the original behavior of the library, without the need to compile or replace files.
The following user(s) said Thank You: Jasem Mutlaq, Alfred, Jim, Andrew Burwell, Karsten Buxtehude
Last edit: 3 years 4 months ago by Paweł Soja. Reason: fix formatting
3 years 4 months ago #63670

Please Log in or Create an account to join the conversation.

This is simply stunning. It takes great in depth knowledge to analyze a binary blob. Looking forward to the updated interface to test!
3 years 4 months ago #63723

Please Log in or Create an account to join the conversation.

  • Posts: 28
  • Thank you received: 17
Hi!

I uploaded the first version on github.
The library still requires a lot of cosmetic work, but it can already be pre-tested.

github.com/pawel-soja/AsiCamera

Currently I only have one camera and it's hard for me to test everything.
I am asking you for tests on your cameras. Share the information you have cameras by attaching information from the AsiCameraPerformance program.

Below is a detailed description of how I tested the camera.
  • download Raspberry Pi OS Lite (Release date: December 2nd 2020, Kernel version: 5.4)
  • enable ssh by placing an empty "ssh" file in the /boot/ directory
  • run Raspberry PI 4
  • connect ethernet cable and login via ssh
  • install pre-requisites from "Install Pre-requisites" section
  • build project from "Get the code and build" section
  • copy udev rule:
    sudo cp ~/Projects/AsiCamera/libasicamera2/lib/asi.rules /etc/udev/rules.d/
  • connect camera to USB 3.0
  • run AsiCameraPerformance
    ./example/performance/AsiCameraPerformance Exposure 10000 HighSpeedMode 1 Gain 100

Of course you can test it on different hardware or operating system and skip a few steps if you know what you are doing.

If something went wrong, run:
./example/simply/AsiCameraSimply Exposure 10000 HighSpeedMode 1 Gain 100
And then post the program result as a text attachment on the forum.

If someone has problems getting through the testing procedure, I can prepare a simple script to do everything for you.

I expect problems for cameras with resolutions above 10MPixel and color cameras. Please confirm.
3 years 4 months ago #64219

Please Log in or Create an account to join the conversation.

  • Posts: 220
  • Thank you received: 27
Thank you pawel. I quickly compiled it on my desktop intel, and tested without problems. (in highspeed mode just a bit faster than firecaptur) Will do the test on an RPI4 later today.

Just one question: is there a possibility to set the camera to 16 bit? That is on my desktop machine I see the biggest problems.

Paul
3 years 4 months ago #64221

Please Log in or Create an account to join the conversation.

  • Posts: 220
  • Thank you received: 27
Hi,

tested ASI178MM and ASI120MM-S on Rpi4 Ubuntu 20.04 64bit

logs attached. Both cams seem to get their target speed. ASI120 in high speed just a tad faster than in Ekos/Indi

Paul
3 years 4 months ago #64223
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 28
  • Thank you received: 17

The library supports 16-bit resolution. I added the "Format" parameter to the programs.
On RPi in 16-bit mode, frames are lost a bit.
I need to do some size adjustments for buffers and transfers to get reliable communication.
I prepared a "16-bit" branch.
Branch "16-bit" is not good for 8-bit mode.

As for me, it looks better:
./example/simply/AsiCameraSimply Exposure 10000 HighSpeedMode 1 Gain 100 Format 16bit
[ASIOpenCamera]: grab CameraID 0
[CameraBoost]: created
[__wrap_libusb_open]: grab libusb_device_handle 0x1f9d338
[__wrap__ZN11CCameraBase12InitVariableEv]: grab CCameraBase 0x1f9f670
Set 'Exposure' to 10000
Set 'HighSpeedMode' to 1
Set 'Gain' to 100
Set 'Format' to 16bit
...
timeframe:  1000ms, status: 11
timeframe:   148ms, status: 0
timeframe:    51ms, status: 0
...
timeframe:    33ms, status: 0
timeframe:    34ms, status: 0
timeframe:    33ms, status: 0
timeframe:    33ms, status: 0
timeframe:    33ms, status: 0
timeframe:    34ms, status: 0
...
[releaseAsyncXfer]: catched

For the ASI178MM camera, the maximum frame rate is reached.
|---------------------------------------------------------------------------------------------------------------------------------|
| BW [%] |                                            Frame duration [ms]                                                         |
|---------------------------------------------------------------------------------------------------------------------------------|
|  100%  |   16    27    33    33    33    34    33    33    33    34    33    33    33    33    33    33    33    34    33    33 |
|---------------------------------------------------------------------------------------------------------------------------------|
 
Best bandwidth is 100%, it has 30.4 FPS

Is it the same for you?
3 years 4 months ago #64232

Please Log in or Create an account to join the conversation.

  • Posts: 220
  • Thank you received: 27
will do that test tomorrow. (RPi is hooked to the main scope right now)
Your results look good.
Paul
3 years 4 months ago #64235

Please Log in or Create an account to join the conversation.

  • Posts: 28
  • Thank you received: 17
I'm confused.
The USB (libusb) works like this, you send a request for how much data you want to receive. If device has data to send, a reply is given.
The amount of data received may be equal to or less than in the request. In an ideal world, a request should be sent with the length of the entire frame. Ideally, several such requests, so that there is always one ready for new data.
Of course, on the lower layer, the request can be split into smaller ones, but at the application layer, you shouldn't be interested in that.
After all, in the library I split the packages into a maximum size of 1MB. I made a suggestion about this size when decompiling the original library.

In the "16-bit" branch I increased this limit to 256MB, and the number of frame queries to 4. Of course, the limit is a limit, if the frame size is, for example, 10MB, a 10MB transfer is initiated (4 times).

You can modify these values ​​in the lib/src/cameraboost.h file.
    enum // constants
    {
        Transfers = 4, // TODO limit to maximum possible transfers
        InitialBuffers = Transfers + 1,
        MaximumTransferChunkSize = 256 * 1024 * 1024 //
    };

At the moment, in the "16-bit" branch, I don't see any problems with the 8/16-bit mode.
3 years 4 months ago #64258

Please Log in or Create an account to join the conversation.

  • Posts: 220
  • Thank you received: 27
Confused? Don't really understand. Reason I asked if there is 16 bit support is for larger/faster systems with lots of memory. In some cases (solar work) I need high-frame rates, large dynamic range (16bit). As I explained earlier when doing this on Linux the camera starts spitting out starus code 11 and drops lots of frames. This behaviour is unpredictable (sometimes going ok, sometimes loosing frames by the dozen) On the same hardware with W10 not a single frame lost. (and happens with every capture software so must be in ZWO or Linux usb handling)

Not really want to do this on an RPI (write speed to disk will slow dow probably as well). Looks logic that you need to keep buffers smaller to have it run on the smaller Rpi's.

Anyway, compiled your 16bit branch on the RPI and the results for 8bit and 16bit attached.

Regards,

Paul
3 years 4 months ago #64271
Attachments:

Please Log in or Create an account to join the conversation.

Moderators: Radek Kaczorek
Time to create page: 1.217 seconds