gmath.cpp in master: line 1206-1207

    in_params.integral_gain[0] = Options::rAIntegralGain();
    in_params.integral_gain[1] = Options::rAIntegralGain();

Should probably be:
    in_params.integral_gain[0] = Options::rAIntegralGain();
    in_params.integral_gain[1] = Options::dECIntegralGain();


Read More...

Rick Bassham replied to the topic 'Moonlite focuser doesn't move with 3.4.3 KStars MacOS' in the forum. 1 month ago

The only side-effect should be a slight delay as the kernel driver waits for the data to be handed off to the hardware.

Read More...

Rick Bassham replied to the topic 'Moonlite focuser doesn't move with 3.4.3 KStars MacOS' in the forum. 1 month ago

Fair enough. Definitely safer to only add it to the Moonlite drivers, or others that do multiple writes in quick succession.

Read More...

Rick Bassham replied to the topic 'Moonlite focuser doesn't move with 3.4.3 KStars MacOS' in the forum. 1 month ago

Yeah, a lot of serial code I've used in the past just always put a tcdrain after a write. With the amount of data any of our drivers send, the delay caused by adding tcdrain should be very short, single digit milliseconds in most cases. Adding it to the tty_write function in indicom.c may prevent these kinds of issues from cropping up in all other serial drivers as well.

Read More...

Rick Bassham replied to the topic 'Moonlite focuser doesn't move with 3.4.3 KStars MacOS' in the forum. 1 month ago

That will probably also work. I'm willing to bet there's just a minor difference in the serial implementation in the linux kernel vs the xnu kernel.

Read More...

Rick Bassham replied to the topic 'Moonlite focuser doesn't move with 3.4.3 KStars MacOS' in the forum. 1 month ago

Yeah, I'm trying to test now, but looking at Moonlite::sendCommand, it calls tcflush(PortFD, TCIOFLUSH) immediately before calling tty_write_string. tcflush is going to discard all unsent and unread data in the serial port at that moment, and since we are immediately calling tty_write back to back, I don't think the underlying serial port has actually sent the data yet. I think we need to add tcdrain in indicom.c. I'll give it a test as soon as I get it to compile on my Mac.

Read More...

Rick Bassham replied to the topic 'Moonlite focuser doesn't move with 3.4.3 KStars MacOS' in the forum. 1 month ago

Adding a tcdrain call after write inside tty_write in indicom.c might do the trick.

Read More...

Rick Bassham replied to the topic 'Moonlite focuser doesn't move with 3.4.3 KStars MacOS' in the forum. 1 month ago

Think the issue is the back-to-back sending of the data with no delay? I'd be curious if it is a timing issue, since both cases are sending two separate commands back to back with no delay in between, and the first one isn't sent. I wonder if a buffer somewhere isn't flushed out to the serial port before it is overwritten by the next command.

Read More...

Rick Bassham replied to the topic 'Dither affecting RMS error?' in the forum. 1 month ago

Jo, the more I remember the guiding I've done before, the more I think you might be correct. I've noticed in processing that the offsets when aligning are pretty small even over several images, leading me to believe we aren't actually getting much out of the dither.

Read More...

Rick Bassham replied to the topic 'Moonlite focuser doesn't move with 3.4.3 KStars MacOS' in the forum. 1 month ago

I've been testing my Arduino Moonlite focuser, and found that on a Mac the Arduino doesn't always receive the SN command. I setup a second serial connection to the arduino that just echoes everything it receives from the indi_moonlite driver, and monitored it with screen. I see the FG command, but not always the SN that precedes it. Everything works great on Linux though. About 1 in 20 times the SN command will be there and the focuser moves like it should. Again, works great in Linux, but very inconsistent on Mac.

Read More...

Rick Bassham replied to the topic 'Dither affecting RMS error?' in the forum. 1 month ago

Looking at gmath.cpp, calc_square_err is looping through all values of the drift array to calculate the RMS error, and I believe performProcessing is adding all movements (including dither movements) to the drift array, but I'm also not familiar enough with the guiding code to jump in and make any changes.

Read More...

Rick Bassham created a new topic ' Dither affecting RMS error?' in the forum. 1 month ago

Does the internal guiding module count the movement caused by dithering when calculating the RMS error? I've noticed that my RMS error will trend down while capturing an image, then jump up after the dither. Definitely not a major issue, just something I (think I) noticed.

Read More...