Wont work on Jetson Nano following install instructions

[vic4hub]

Hey thank you for setting this up. I am trying to get this working on Jetson Nano and get the following error when installing per readme:

sudo apt install libasicamera2 Reading package lists... Done Building dependency tree
Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation:

The following packages have unmet dependencies: libasicamera2 : Depends: libasicamera2-bin (= 1.16.3-4) but it is not installable E: Unable to correct problems, you have held broken packages.

[bgottula]

@vic4hub it probably doesn't work because we don't have support for ARMv8, which appears to be the processor on the Jetson Nano if I'm reading correctly. Can you confirm?

@jgottula did some work earlier to support adding ARMv8 from someone else who asked for it, but that person disappeared once it was ready to go so we had no one to test it. If you're willing to actually test it @jgottula might be willing to help with reviving that work.

What are you hoping to use this software to do?

[jgottula]

I had a hangup previously when trying to package the ARM variants of the libs, due to there not being a clear mapping between the ARMv5, ARMv6, ARMv7, ARMv8 binaries from ZWO and the actual ARM architecture names in Debian.

Fortunately I think I have cracked that problem, and it looks like Debian arch to ZWO lib mapping should essentially be this:

• arm64: ARMv8
• armhf: ARMv7
• armel: ARMv6 (and possibly ARMv5 as well; ARMv5 builds aren't even included in more recent libASICamera2 releases)

So maybe now I can get those appropriately packaged so that the listed arch is correct and "just works".

(Reference: https://wiki.debian.org/ArmHardFloatPort#Name_of_the_port)

---

As for zwo_fixer patching support (to fix the stupid problem where libASICamera2 just ignores libusb return values and does stupid things that cause the USB video data stream to hiccup really poorly), see #51 (still unmerged) which implemented ARMv8 support and could be easily brought up-to-date.

---

Oh and also 1.17 exists now. I should probably add that on top of the other things as well.

V1.17
Fix some bugs.

[jgottula]

Ah but wait, I need to figure out what arbitrary triplet they decided to use for each ARM port of Debian as well, sigh...

[jgottula]

Ah but wait, I need to figure out what arbitrary triplet they decided to use for each ARM port of Debian as well, sigh...

Seems to be:

• arm64: aarch64-linux-gnu
• armhf: arm-linux-gnueabihf
• armel: arm-linux-gnueabi

(Reference: https://wiki.debian.org/Multiarch/Tuples)

---

I've pushed new bin packages to the apt repo just now, which, at least in theory, should "just work" when pulled in as dependencies by the libasicamera2 package on an ARM machine.

[jgottula]

As for zwo_fixer patching support (to fix the stupid problem where libASICamera2 just ignores libusb return values and does stupid things that cause the USB video data stream to hiccup really poorly), see #51 (still unmerged) which implemented ARMv8 support and could be easily brought up-to-date.

I've now backported ARMv7 and ARMv8 support for SDK v1.16.3 onto that branch.

[jgottula]

Oh and also 1.17 exists now. I should probably add that on top of the other things as well.

V1.17
Fix some bugs.

This still remains to be done.

[vic4hub]

you guys are awesome! let me know what would be needed from me, I can certainly test stuff. It would be amazing to get zwo to run in v4l2 (I know that's outside of scope of this repo)

[bgottula]

Yeah so next steps to test stuff:

1. You should now be able to run apt update followed by sudo apt install libasicamera2 and get a successful result. Let us know if it still fails.
2. Try to build the capture program. Check out the add_arm_support branch first, since that hasn't been merged.
3. Try running capture with your camera and post some of what it prints to the console so we can tell if @jgottula's "zwo fixer" work-around is successfully applied and working as expected.

[vic4hub]

puked:

~/zwo/capture$ make make -C ../zwo_fixer all make[1]: Entering directory '/home/v/zwo/zwo_fixer' g++ -std=c++17 -fno-exceptions -fno-strict-aliasing -D_GLIBCXX_USE_CXX11_ABI=0 -fdiagnostics-color=always -Wall -Wno-unused-variable -Wno-unused-function -O1 -fuse-linker-plugin -fvisibility=hidden -fvisibility-inlines-hidden -g3 -gdwarf-4 -fvar-tracking-assignments -fno-omit-frame-pointer -fuse-ld=gold -shared -fPIC -fno-plt -fno-gnu-unique -rdynamic -Wl,--no-gc-sections -Wl,--no-undefined -Wl,-z,defs -lbsd -ldl -lelf -lusb-1.0 -o libzwo_fixer.so zwo_fixer.cpp /usr/bin/ld.gold: error: cannot find -lbsd /usr/bin/ld.gold: error: cannot find -lelf collect2: error: ld returned 1 exit status Makefile:15: recipe for target 'libzwo_fixer.so' failed make[1]: [libzwo_fixer.so] Error 1 make[1]: Leaving directory '/home/v/zwo/zwo_fixer' Makefile:53: recipe for target 'bin/capture' failed make: [bin/capture] Error 2

[bgottula]

The README doesn't make it obvious enough but you need to install the dependencies for zwo-fixer listed here: https://github.com/seeing-things/zwo#zwo-fixer

[vic4hub]

ah yes, thought I had all that as I recently compile opencv4.5 and pycuda stuff, anyhow sudo apt-get install libbsd-dev libelf-dev did the trick, build now breaks like so:

g++: error: unrecognized command line option ‘-m64’ Makefile:53: recipe for target 'bin/capture' failed make: *** [bin/capture] Error 1

[bgottula]

Try commenting out the line PLATFORM = x64 in Makefile

[vic4hub]

Yep that did the trick and it works, I actually get the damn camera feed! Anyhow here is part of the log, seems something is still not quite there (or is it? let me know what else you'd like to see):

sudo ./capture [ZWOFixer] PLTHook(libusb_cancel_transfer): constructed [ZWOFixer] PLTHook(libusb_cancel_transfer): installed main thread id: 17589 [ZWOFixer] ZWOFixerInit: OK capture: Found 1 cameras; arbitrarily selecting ZWO ASI178MC. disk thread id: 17595 capture: No filename provided; not writing to disk!

preview thread id: 17596 gain thread id: 17597 [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code capture: GetVideoData failed with error code ASI_ERROR_TIMEOUT [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code capture: GetVideoData failed with error code ASI_ERROR_TIMEOUT Frame count: 000009, Dropped frames: 000010 To-disk queue: 0 frames, to-AGC queue: 0 frames, pool: 63 free frames.

[bgottula]

Okay well that's progress!

It appears as though zwo-fixer is probably working. The messages

[ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code

are emitted every time zwo-fixer intercepts the problematic code path in the ZWO driver. That's expected to happen from time to time, but not nearly as often as what you are showing here. What this probably means is that some combination of hardware/driver/software is struggling to keep up with the expected flow of data. Unfortunately the camera hardware and driver are a bit temperamental, especially when running at the highest frame rate at full resolution.

Some things you can try:

• Run sudo ./capture binning=2 or binning=4 to see if that helps. That reduces the amount of data transferred per frame by quite a lot, but of course isn't full resolution.
• Try adjusting the ASI_BANDWIDTHOVERLOAD driver parameter here: https://github.com/seeing-things/zwo/blob/master/capture/src/camera.cpp#L160-L165 (you'll need to rerun make, of course)
  • Try decreasing this value until capture can run with very few errors or dropped frames.
  • I honestly still don't have a firm grasp of what this parameter does under the hood in the ZWO driver, but it has something to do with how close to full USB 3.0 link saturation it tries to run. It's just a magic knob you have to tune by trial and error. How high you can go may depend on things like USB controllers and other low-level hardware details. Thus the ideal value on your Jetson Nano may very well be different than on my machine.

Let us know what you find.

[bgottula]

Oh another thing you can try: Run htop while capture is running and post some of the output. Tree view (F5) is helpful to group all of the threads from the same process together. In the setup menu for htop (F2), under "Display Options" enable "Show custom thread names" which will help us identify which threads are which.

[jgottula]

It's just a magic knob you have to tune by trial and error.

It's exactly as stupid and awful as you'd expect, sadly.

[jgottula]

I highly suspect you'll find that you're topping out on CPU. In part because USB is somewhat inherently CPU-intensive, and also because of the number of times big buffers get copied around in memory for no especially justifiable reason.

I bet we're able to get away with a fair bit more bandwidth before topping out on our Core i3-7320 system than on that NVIDIA Cortex-A57 SoC. (Also I have no idea how good of a job NVIDIA did at making sure the I/O to their XHCI controller is beefy enough; might be totally fine, might turn out that it can't actually sustain 5Gbps in reality, who knows.)

[vic4hub]

Awesome-sauce! Thank you guys so much, I'm in EST, shall play around with this tonight and report back. My intentions are definitely to not just take, but to give back and help.

[bgottula]

@vic4hub when you resume testing, do a git fetch followed by git reset origin/add_arm_support --hard on the branch. @jgottula fixed an issue that may only have affected me over in amd64 land, but would be good to confirm that it still works for you with that tweak.

[jgottula]

I guarantee that last fix only touched x64; but I guess re-test anyway. There may have been other force-pushes I did prior to that one which potentially affected something else.

[vic4hub]

hey guys, just did, had to clean and comment out -m64 out once again and rebuild. What should I be looking out for when running?

[vic4hub]

I get the following: ~/zwo/capture/bin$ sudo ./capture [ZWOFixer] PLTHook(libusb_cancel_transfer): constructed [ZWOFixer] PLTHook(libusb_cancel_transfer): installed main thread id: 9960 [ZWOFixer] ZWOFixerInit: OK capture: Found 1 cameras; arbitrarily selecting ZWO ASI178MC. disk thread id: 9965 capture: No filename provided; not writing to disk!

preview thread id: 9966 gain thread id: 9967 [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code capture: GetVideoData failed with error code ASI_ERROR_TIMEOUT [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code capture: GetVideoData failed with error code ASI_ERROR_TIMEOUT [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code capture: GetVideoData failed with error code ASI_ERROR_TIMEOUT Frame count: 000006, Dropped frames: 000008 To-disk queue: 0 frames, to-AGC queue: 0 frames, pool: 64 free frames. capture: GetVideoData failed with error code ASI_ERROR_TIMEOUT capture: GetVideoData failed with error code ASI_ERROR_TIMEOUT [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code capture: GetVideoData failed with error code ASI_ERROR_TIMEOUT [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code Frame count: 000013, Dropped frames: 000015 To-disk queue: 0 frames, to-AGC queue: 0 frames, pool: 62 free frames. [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code capture: GetVideoData failed with error code ASI_ERROR_TIMEOUT capture: GetVideoData failed with error code ASI_ERROR_TIMEOUT capture: GetVideoData failed with error code ASI_ERROR_TIMEOUT Frame count: 000021, Dropped frames: 000023 To-disk queue: 0 frames, to-AGC queue: 0 frames, pool: 63 free frames. [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code capture: GetVideoData failed with error code ASI_ERROR_TIMEOUT capture: GetVideoData failed with error code ASI_ERROR_TIMEOUT capture: GetVideoData failed with error code ASI_ERROR_TIMEOUT [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code capture: GetVideoData failed with error code ASI_ERROR_TIMEOUT Frame count: 000026, Dropped frames: 000029 To-disk queue: 0 frames, to-AGC queue: 0 frames, pool: 64 free frames. capture: GetVideoData failed with error code ASI_ERROR_TIMEOUT capture: GetVideoData failed with error code ASI_ERROR_TIMEOUT [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code [ZWOFixer] PLTHook(libusb_cancel_transfer): got LIBUSB_ERROR_NOT_FOUND; fixing broken code ...

[bgottula]

Okay, looks like nothing significant changed, which is expected.

You should be able to just un-comment the PLATFORM = armv8 line at the top of the Makefile now to select your platform architecture (and comment out the PLATFORM = x64 line), rather than commenting out -m64.

Next would probably be useful to look at htop output while it's running: https://github.com/seeing-things/zwo/issues/60#issuecomment-810780623

[vic4hub]

Also here is what the tree looks like, I should also fully disclose that I'm using chromium in here with a few tabs open and yes v@contact lol

[bgottula]

Okay, interesting. So the main threads don't appear to be maxed out on CPU time. (The preview threads run at non-realtime priority, so even though they are using a lot of CPU they shouldn't be able to hog it from the important threads. It used to be possible to close the preview window to kill those threads just to free up CPU, but that isn't working at the moment (#62).)

Yeah I guess next to try would be the other things I mentioned here: https://github.com/seeing-things/zwo/issues/60#issuecomment-810774934

[vic4hub]

all good. just tried binning down to 4 no difference. gonna fool around with the "magic knob" and report back.

[vic4hub]

yep magic knob works and the magic number for nvidia jetson nano is 40 anything above drops frames. Also notable, cpu's are pegged and fps gets an impressive 12fps lol (per sony imx178 tops at 60fps)

[vic4hub]

what are you guys getting on your rigs in terms of fps, also what are your rigs? I think it is likely that one can get better results going headless w/ realtime priority.

[bgottula]

Very interesting, thanks for reporting your findings. I should point out that the frame rate shown in the title bar of the preview window is an estimate of the rate of frames actually shown in that window, which is often lower than the frame rate the software is successfully pulling from the camera. The preview window's thread displays frames as fast as it can but skips frames as needed so it isn't a bottleneck. So you might actually be getting something between 12 and 60. I suppose I ought to add a running frame rate from the camera estimate somewhere. As a crude work-around you can use a stopwatch or something and look at the frame count printed to the console over some time interval.

We are using a Shuttle DH270 with an Intel Core i3-7320 processor and Samsung 960 EVO 500GB SSD. We picked the specs on that machine largely to be capable of keeping up with the firehose of data that comes out of this camera. In our case, we care most about getting all the frames written to disk. We are able to achieve very close to the advertised 60 FPS (after much pain and suffering).