1.9.4 is out, so let me know if you have any problems with it crashing, especially if you have logs.
The instructions here should work (they worked for me when I did it originally, and with a second one when I went back to it) indilib.org/forum/ccds-dslrs/3320-experi...eximage-cameras.html It should also show up with the correct pixel size (2.2um)
As far as it detecting the laptop webcam, it will probably be /dev/video1 (as opposed to /dev/video0) You can usually double check that with "dmesg | grep video" (or "sudo dmesg | grep video" when you plug it in.)
Another good program for testing if it's working is guvcview.
Note that you might be able to use the gige driver as is without the firmware update. (I've since become aware of that using avaris, but on another USB camera it hasn't worked, and I haven't yet tried it on the NexImage 5.)
Note that the Bulb mode over USB triggering not being supported is an issue up to the D5300 (Some people said D5200 works, I know the D5100 doesn't work) and D7200 (D7100?) and impossible (Nikon left it out) on D3xxx series. I'm not sure on the more expensive cameras.
A trick I got introduced to if you have an IR port is NikonRemote ( github.com/outofjungle/NikonRemote ) Which you can feed into INDI's serial port and it works. Which uses just a Uno, resistor and IR LED. (It may not work with clones as is because it relies on the reset behavior of the Uno, but if you are relying on an external thing (or gpio like from a Pi), you can trigger it by the arduino's reset pin.)
Looking at those logs, @azwing is correct, about it being related to things fixed. Those errors will not occur anymore with the current master. Which will be INDI 1.9.4 whenever @knro bumps the version and releases it. I went through and fixed a lot of that after 1.9.3 was released and the specific functions it crashes on there aren't called. (Which is usually about 2 months, and right now it's 2months + 1 day from 1.9.3 (Nov 10), so it should be relatively soon.)
If you want it to not happen before then, you can build it from source. (Not sure what all getting set up to build that includes on mac, but the master repository is here if you want to try: github.com/indilib/indi )
Finally started trying to test this and as soon as the port is bound via rfcomm and thus properly setup as /dev/rfcommX (provided it's powered on) I can't seem to reproduce it on my bluetooth board. (Basically what the Instructable does.)
So I'm inclined to think it may be an OS level connection problem, but I'm not entirely sure that's the case.
In the past bluetooth has been finicky as heck. (So that's good for me, but bad for solving the problem unless the above was the problem?)
However, I have discovered: It does sometimes crash kstars if it's disconnected, I'm surprised by that, with all the fixes I did to prevent that, not sure why it would only show up on bluetooth. I'll need to look into that later. (ARGH! I realized I was testing an old branch, so I need to go back and check this again after some updates/rebuilds.)
Apologies my French is not good, but for LiveView over USB, the max resolution for Nikon cameras, is about 640x424 (or something close) on SOME of the new ones, D5? D6? , there's a setting which can work I believe, to get up to (from memory 1024x???)
For the D5100:
* USB Liveview: 640x424
* HDMI: 720p or 1080i (at some frame rate)
* Record: same as the above.
* Record and capture (via USB): same as above.
You can (as I do) use a HDMI capture card to grab the higher resolution video from the HDMI output.
Note that remote control via USB and HDMI are mutually exclusive.
As far as the Z7: I think there's a setting, it MAY be: LiveViewZoomArea to get it up to a bit better resolution? or /main/capturesettings/moviequality seems to have 1280x720, so that might work? (Might be the recording setting?)
The PR included that difference in timeouts, as well as a bunch of verification so that if there's a timeout it will warn, and abort the update.
It will probe and detect focusers and rotators, as has always been done. (Which on serial should amount to the 0.1 sec timeout, or 2 sec on network.) So yes, those will cause timeouts on startup.
I did add a little gating based on version to something with rotators. Up to V3 lacks the commands. rI rM rT and has no equivilent (at least in the current version and prior versions I looked at.) That and checking for OnStepX focusers (when version is OnStepX or unknown) are the only gating like that. As for the most part the commands are pretty consistent across versions.
So in multiple day+ long tests, I see plenty of network timeouts, but 0 crashes, even while accessing it with multiple things. About 6-ish per hour at 2 second timeouts on my network.
I did go ahead and change to LOG_WARN and to return true to ReadScopeStatus. (Focusers/Rotators and such are still LOG_ERROR) so the scope doesn't go into error status.
Unless anyone sees a problem I'll see about a PR to main tonight.
NOTE: The logs will have a combination of INFO/WARN/ERROR. I mostly kept the wording the same, but I'm not sure I like it: This update aborted, will retry... (Kept the same for easy find/replace.)
Mount will not change state due to the LOG_ERRORs. (To prevent stopping captures, sequeneces, etc.)
Mount will not disconnect.
TODO (related or discovered due to this):
Convert the Focusers & such that are in functions other than ReadScopeStatus to others.
One issue is that the scope doesn't register as disconnect when on the network, I believe this is the case with the existing network code as well. (But you were more likely to have a crash than notice that.)
LX200 adjustable timeout. This is a bit trickier than I thought needing to touch a lot more things, so I'm going to make it separately. (This is IMO better than just OnStep, and will get all the LX200 functions we use, plus it should benefit anyone using a network adapter for an lx200, TeenAstro or others.)
Alain's investigations into the rotator differences on SWS vs direct.
Park: I'm not sure I'm understanding the process right (I don't use it normally), but when I set a position it's now slewing to it.
Question: Should I raise the network timeout from 2 sec to 3 sec or higher?
I see little reason to not keep the serial at 0.1 sec, I don't see errors with it, even on the slowest platform we have. There is one edge case: serial to wifi or bluetooth to serial might be slower, but only if it's setup as a serial port, as opposed to accessing the serial port over a network. I don't have a bluetooth serial module to test right now. (and I've had horrible luck with them.) That should be resolved with the adjustable timeout patch later on.