@tech@zwo#46749
Test Procedure
@tech@zwo#46749 Attached a file include our test procedure
Here is a GitHub Gist with the following log files:
- The output of the commands in
test-procedure.log which match the commands that you run in your demo_log_8288x5644_16bit.txt.
- The run of the demo program at 8288x5644@16bit is separated into its own file at
test-run-at-full-resolution-16-bit-depth.log as the log output is large. This is the same as the last command that you run in your demo log file.
- I should note that this test procedure is very similar to tests that I have already performed. I hope that you have been reading the previous logs and test runs that I have been performing, as they take some time to perpare and run.
- Additionally, I have included the output of a separate test run at 8288x5644@8bit in the file
test-run-at-full-resolution-8-bit-depth.log
- Additionally, I have included the output of a separate test run at 4144x2822@16bit in the file
test-run-at-half-resolution-16-bit-depth.log
https://gist.github.com/vector-kerr/9140e1cbe15f8990c3dcde61cd371065
USBFS Memory
@tech@zwo#46749 And could you check the CMD：cat /sys/module/usbcore/parameters/usbfs_memory_mb
recommend to set 200M
Yep. I did that 2 weeks ago:
Vector And I have also verified that the USBFS Memory Allocation is set as required:
pi@raspberrypi:~ $ cat /sys/module/usbcore/parameters/usbfs_memory_mb
200
And I've also done that today:
pi@raspberrypi:~ $ date
Sat 29 May 14:11:21 AEST 2021
pi@raspberrypi:~ $ cat /sys/module/usbcore/parameters/usbfs_memory_mb
200
New Raspberry Pi 64 Bit Release
There is a new release of Raspberry Pi 64 Bit.
It is named raspios_arm64-2021-05-28 and is located here:
https://downloads.raspberrypi.org/raspios_arm64/images/
I will be downloading and installing it and trying some tests on that new version while I am waiting to hear back from you.
Where We Are At
I believe that I have very fairly demonstrated in detail that:
- The hardware (raspberry pi, camera, cable) all work independently
- Your own demo applications demonstrate that I can take 8288x5644@16 images on raspberry pi 32 bit successfully
- Your own demo applications demonstrate that exposures at 8288x5644@16 images on pi 64 bit always fail
I have tried performing tests on 4 x 64-bit versions of raspberry pi, a 32-bit version of raspberry pi, and a 64-bit linux machine to determine the common factor between the exposure failed message.
I have used your snap and video demo programs, as well as my own test programs against your API, with versions 1.16, 1.17, and 1.18 of your SDK, as well as custom libASICamera2.so files which you have recently supplied.
I have provided an abundance of log files with all requested output, as well as extra information which could be useful for debugging.
After a brief search, it appears that I am not the first person to experience exposure failures with ZWO cameras.
I purchased the set of equipment that I currently own (64-bit raspberry Pi, ASI294MM-Pro) because:
- The pi is low-power and portable, which is ideal for performing astrophotography in remote locations
- The ASI camera has a high resolution, high bit depth, and very sensitive sensor
- ZWO supply 64-bit ARMV8 linux drivers for ASI Cameras, which (should) allow me to use the camera on a 64-bit operating system which allows observatory applications to operate with more than 4GB of memory when required
- this was identified as important because under a 32-bit operating system I was receiving out of memory exceptions.
As it currently stands, I have spent countless hours (days?) performing test after test, submitting logs, writing operating systems to SD cards, installing updates, compiling source files, writing test applications, and all the rest, in order to use the product that I purchased in the way that I intended to use it when I purchased it.
Ultimately, determining the cause of this problem and resolving it will benefit me because I will be able to use the camera for its main purpose - to take photos - but it will also benefit you, because you will have a more stable and reliable product to offer consumers. Resolving this issue will also demonstrate to your customers that you are interested in supporting your own products.
If somebody purchased a Canon camera and it failed to take photos at its full resolution, it would be considered a significant issue for their product. I am almost baffled by the fact that I seem to have to push to come to a resolution for this issue, because not only is this camera failing to perform its primary job (taking photos!), there is no other method to control this camera or retrieve images from it other than through USB. If it was a point-and-shoot DSLR at least the push-button could be used to take photos, and the SD card could be removed to get the photos off it. With this camera, that is not an option.
As it currently stands, this camera with the supplied drivers does not perform the advertised function of taking photos at full resolution (8288 x 5644 @ 16-bit resolution) on an operating system with supported drivers (armv8) using compatible hardware (one device connected directly to a USB 3 port using a USB 3 cable) using supplied testing software (your snap and video demo programs).
Next Steps
I am happy to continue to perform tests and work with you to come to a resolution to this problem, however there must be some kind of substance to these tests. Continued test runs of the snap and video demo programs must have some kind of demonstrable purpose. The tests that I have performed over the last 2 months have very clearly shown that the issue lies at a minimum specifically with the ARMV8 / AARCH64 system.
There is exhaustive evidence above suggesting that there may either be a problem with the the camera driver, as the hardware is entirely capable of working correctly under specific circumstances. This may extend to the camera firmware, but I cannot make any claim either way here as I do not know how the firmware has been programmed or operates.
Under a 64-bit armv8 operating system, the failures experienced appear to directly correlate to larger file sizes that need to be transferred. If the bit depth is reduced or the image dimensions are reduced, then exposures seem to succeed more frequently.
Please let me know how you intend to proceed from here in order to resolve this exposure failure issue.
