×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

ASI178 Camera Performance on Rasperry PI 4

  • 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 3 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 3 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 3 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 3 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 3 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 3 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 3 months ago #64271
Attachments:

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

  • Posts: 28
  • Thank you received: 17
I meant the confusion about the original ZWO library.
I didn't mean why you need 16-bit mode ;)
Above I wrote my thoughts on USB and the library.
They divide each transfer into 1MB. For the ASI178 camera, 7 bulk transfers are created for the 8-bit mode and 14 for the 16-bit mode.
This is what I suggested when writing the wrapper.
Now I have modified it so that the transfer is not split into parts in the application layer.

My goal is to fix the ZWO library so that it is usable on Linux. Because that's where the main problem lies.

Looking at your attachment I can see that everything is fine! right?
When receiving the frames, none got lost and you achieved fps above the manufacturer's declaration.
I do not understand.
You don't want to run the camera on Linux on RPi?
Are you running it on W10 on RPi? How do you use the camera?
How long are your videos? How can I help you?
I don't understand what you're referring to.
The last modification was based on a smaller number of larger buffers. And in fact, on their distribution of addresses for transfers. I operate on megabytes here, I am far from hardware limitations.

In my project I want to use RPi for wireless transmission of high-speed cameras. After optimizing the code, I think it is real. That's why I started working.
Writing directly to the disk should not be a problem either. Additionally, by introducing a simple lossless compression, it is possible to reduce the size by half.

You can describe how you currently use the hardware/software and how you would like to use it?

After some tweaks, I think libASICamera2Boost will be ready. I still have to fix the Indi Library so that no frame gets lost.
3 years 3 months ago #64276

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

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

mainly i am trying to use the RPI for deep-sky (with an ATIK camera). For planetary (not at the moment oppositions are done) and solar i still use a W10 system because of the problems with that ASI178.

Planetary/Solar I use (now) an W10 PCc (AMD Ryzen3 1200 - 16GB memory - Harddisk + M2 SSD (PCI mode) Wireless 5G Network (800+Mb/s) I connect to the PC via a VNC desktop connection.
During solar session I usually collect > 50GB of data. (~1000 frames at full resolution per video). For Mars (but that was with ROI) 10000 frames per video ~3 minutes per filter. (RGB and L or IR). Captures are done on the M2 SSDC. Using a vnc from my desktop. Afterwards I copy the files over wireless network to my desktop PC for processing. I easyly get the listed speeds of the camera without any frame loss.
Capturing is done with FireCapture. (also tried Ubuntu on that machine : dropped frames all over the place)

If I can get an RPI working at reasonable speed it will become an option for planetary. (Solar don't really know but if the AMD can get up to speed, I can drop Windows)

Hopes this clears it a bit?

Still some questions on how the final result will work. Will everything needs to be compiled with your solution or will it be possible to have it as a "drop in" replacement for the ASI libraries.

Regards,

Paul
Last edit: 3 years 3 months ago by PDB.
3 years 3 months ago #64277

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

  • Posts: 28
  • Thank you received: 17
Hello Paul!

The library will be prepared so as to it could be easily replaced. As described in README.md.
Replacement is not an efficient solution because the interface of the original library is prepared to copy data.
However, if you can modify the code I have provided function to get frames without copying.

In short, you will be able to swap the library - it will work better than the original library.
Indi Library (I'll add some fixes) will use the additional features implemented in libAsiCamera2Boost - it will work even better.

I am thinking about adding the possibility to configure the library from the configuration file. This makes it easy to adjust the parameters in the case of a simple replacement.
I bought my first telescope and I'm more in code than under the sky ;)
When I find out what programs you are using, I will try to suggest improvements to this programs.
The following user(s) said Thank You: Jasem Mutlaq
3 years 3 months ago #64308

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

  • Posts: 220
  • Thank you received: 27
Thanks Pawel.

Unfortunately there is no way I can modify the FireCapture code (not open source, I can ask the author if he would be willing ....)
Further testing with my ASI178 gets me more and more frustated. (keeps me from spending more money on a new bigger cooled camera if I am not sure it is going to work).
On the RPI4 connected via USB3, wifi disabled (avoid interference) Gbit network cable connected.
Start Indi and start a framing session, 10 second exposures
From time to time (fairly frequent) there is status 3 (instead of 2) in AsiGetExpStatus (so exposure is retried. No a problem on 5 second exposures, but really a pain if it happens on 300 second exposures)


Then I tested on my AMD Ryzen.
Here I coud not see any retries
But with videocapture as soon as either highspeed or 16 bit is enabled it stats to spit out error 11.
(same for Indi streaming as for FireCapture)
If on the same PC I boot W10 no problems with video.

Is it the camera hardware? I doubt, looks more like the SDK. I wonder if this onlt the 187 or how do others run cams with even more megapixels on an RPI.

Paul
3 years 3 months ago #64326

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

  • Posts: 28
  • Thank you received: 17
Hi Paul,

when you write about tests, you mean the original, unmodified ASI library? right?
If I finish some minor fixes on high-frame speed recording, I'll move on to fixing long exposure.
Apart from the hiccups when starting high-speed recording, it seems to me that the situation in my library is under control.

I am also planning to buy a bigger camera from ASI and I think I will get the situation under control as well.
What kind of camera would you buy? Maybe I'll buy the same one.

I put the 8/16-bit version on branch master, which works fine for me. I added the ability to set the size of buffers using the function and using the configuration file. Everything well described in the README and header file.
My next step is to fix timeouts and run capturing smoothly.

Maybe tonight, Polish time, I will manage to find some time and get it over with ;)
After completing the library and Indi, I'll take a look at other programs. FireCapture added to the list.
3 years 3 months ago #64331

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

Moderators: Radek Kaczorek
Time to create page: 1.620 seconds