That might not be a bad idea, as in almost all case it'd be able to share code.

We'd need to copy it and change the base class to probably INDI::Device and we could keep the Interfaces for the others which load as is, if we wanted something in parallel and quick and dirty, or we could see about moving from INDI::Telescope to INDI::TelescopeInterface and we could load it as needed, similar to the rotators and other things which are detected on connection.

After looking a bit, Actually scratch that, there's no telescopeinterface. :( Probably the only project that might consider it is OnStepX (heh). More fun with flexible open source software!


Finally got my changes uploaded:

Mostly amounts to checking on probe (I think all OnStep > 3.6 are good. However, Not sure if all versions will return or if they'll timeout.) Changing types to use double specifically vs the int (and it handles that error, if not doubles) and moving it to it's own update function.


The (BMP/BME)280 series temperature isn't the most reliable for ambient conditions, as the temp sensor is intended mostly to compensate the pressure sensor. It will be a bit hotter than all the other sensors I've tested by 1-2C, unless read only rarely. (30sec+) It is good for low power though. I've used them for wifi sensors that last for a *long* time on batteries.


OnStep will never be in Focuser or Rotator, but in FoucserInteface, WeatherInterface, etc, as all of the non interfaces inherit the base classes and Interface classes. The exception is Telescope. (Though OnStepX doesn't always technically have that.) OnStep, I think, has the most Interface classes of all INDI drivers. And unfortunately, is also kind of a pain about multiple interfaces. (See the whole multiple focuser stuff that works but yeah.)

The rotator is gated by version, so versions 1,2,3 don't work. (3 may be made to work, but lacks commands to map it well, as I recall. There's not a derotator interface in INDI. It also detects it on startup, So, without looking much see if :rG# returns something if you don't see the focuser. That's so that it doesn't recheck it (and have to timeout) if not present. (Similar to mentioned above.)

Unfortunately the INDI interfaces doesn't map well to OnStep in a number of cases. (OnStep isn't very traditional in how it works, which makes it great but also sometimes a pain. Ex multiple focusers)

I used simulated hardware on a mega (with nothing connected) for most of my testing.

Alain, sorry I've been delayed on that pull request. I plan to work on it this morning. I'll look at the diffuser not showing up


I've got a few suggestions on it, which mainly are to use the sendOnSteCommand() over sendOnStepCommandBlind (As most of that returns 0/1) and test for it. That will let us add a check so if it doesn't support it to not do it again, but I'll issue a pull request to you in the next day or two if you want.

I still think that it being chatty isn't an issue except that it often runs into some of the timeouts if something isn't supported, and if we keep doing it, and triggering the timeout, or leaving things in the buffer compared to: If we check it once the timeout happens near enough to startup. We can also gate that with OnStep version check, but I haven't dug into things enough to know when those were added.


Doublechecking what Alain said, since there's a proposal in the thread, to confirm there's no way to have the focuser interface output temperature.

I've created a branch here

This should report it in the weather interface, but it won't be the main temperature. It would be possible to test it, and see if it was a good thing. (I'm very suspicious, I haven't touched the code in a while, and it compiled without error the first time.) If you can test that, we can at least report it and I can see about adding a button to swap it.

OnStep (maybe X only?), If I recall correctly also does the temperature compensation automatically. (Or can) I need to double check that statement, and I probably need to get some new hardware to test...


It's generally lost connection or a communication error. So it skips the rest of the update on error. You'd need to have verbose logs on and find where that is to see what's going on. Could be parsing a reply (maybe a change in OnStep) or something else.


1.9.4 is out, so let me know if you have any problems with it crashing, especially if you have logs.


james_lan replied to the topic 'Confirm NexImage connected' in the forum. 2 years ago

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) 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 ( ) 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: )