I'd be surprised if it was a permissions thing, as the usb serial device for the dslr bulb control works, and everything has been set up the same way. I think that your suggestion of the incorrect frame being grabbed is more likely. I know that other apps like wxAstroCapture and SharpCap on windows employ a technique of grabbing several frames immediately after the LX is ended, and then the brightest one is grabbed and returned.

I'm not familiar with the LED mod, I've just done a quick google to read up on it. It's interesting that you haven't had issues with incorrect frames being returned with that particular implementation. My understanding of the mod is that a stream of "frames" is returned even during an LX frame, but that they're effectively empty, and then when the LX ends a frame gets the dump of data. I think that's why sometimes just grabbing the next frame after the LX ends might not be the correct one.

May you post the indiserver log ? So we can be sure this is not an access problem to the LX port. I run Fedora 19 where every serial port are permanently opened by the modem manager (setting RTS and DTR to 1), only some particular USB/serial chips are unhandled by the modem manager as they are listed in a blacklist file (those used for Arduino....). Actually there may be many reasons for such a problem. You could perhaps make a test using your dslr bulb control along with indi_v4l2_ccd: if a picture is taken then V4L2 LX control should be ok.
The log will also show the pwc kernel version used: the driver has been rewritten since kernel 3.2 and I think that the problem of incorrect starting frames has been solved (they are directly dropped by the pwc driver). By the way I could have a look to the wxAstrocapture code as it is now open source I think.

Hi,

Given the fact that wxAstroCapture is working ok using the same port I think access must be ok, but I'll set up another test session and grab the log files from it to be 100% sure

Hi,

On my ubuntu 12.04 wxastrocapture executable is owned by root user. Do you run indiserver as root ?

Regards,
Jean-Luc.

Hi there,

I've been away for a while but have been having the same issue as Samtheeagle as per my previous thread (www.indilib.org/forum/general/231-v4l2-lx-mod.html) and have got back to trying to sort this out.

To answer the question you put to Sam, I am indeed running indiserver as root.

I suspect you're right in that it's probably a timing issue. I note that qastrocam seems to use V4L's IO_METHOD_READ rather than the IO_METHOD_MMAP employed by default in v4l_base.cpp. I wonder if this is to guarantee the timing. I've tried changing to _READ and _USERPTR, but indi_v4l2_ccd doesn't work with only that change -- it hangs.

I'm trying to learn enough about V4L2 to see what else I have to implement to make _READ work, as I suspect that's the key. Any input would be appreciated.

I attach one debug log (hardly anything in it) and one fuller dump from indiserver.

Many thanks,

BW.

Just a quick update. Definite progress!

I've managed to get an image displayed via the read() mechanism and there is definite variation in exposure when I enable or disable the serial port.

At the moment I haven't figured out how to synchronise the read() callback with the LX routines and I need to implement some kind of frame-dropping system as with the read() method, frames back up causing even worse synchronisation issues -- but certainly this is a significant advance on where I was before.

Regards,

BW.

Progress!

I've managed to get the long exposure serial mod working with my Phillips SPC 900NC webcam. I attach an image of a 5-second exposure of me waving around a bike light as evidence.

I'll try to tidy what I've done down to the minimum required and submit a patch when possible.

Thanks,

BW.

Hi BW,

That's great, I was really wondering what went wrong with the current implementation. I'm curious to know the difference between Led and serial LXmod when capturing a frame.

Thanks,
Jean-Luc.

Right. This is what I've managed to distill it down to:

• My gut-feeling that the read() method was required to sync the frames proved to be unfounded. So I've removed all that conversion work;
• Capturing needs to start when the LX signal is triggered. The output can be discarded during this time as it just returns a black frame, however;
• The frame immediately after the LX signal is deactivated is, confusingly, not the frame that will return the picture. It needs to be discarded and the subsequent frame kept^*.

To that end, I've added a variable to the v4l2_base class that keeps a track of the LX state (capturing/discarding), plus has a third state for the penultimate frame (after LX is deactivated, but before we want to read the frame). I've also triggered capturing when the startLx() function is called, where the LX method is serial rather than LED. This is an attempt to keep it backwards-compatible with the LED mod. There are also helper functions to access those states.

I'd be interested to know if this works for Samtheeagle too. It seems pretty reliable here. The diff against rev 1596 is attached.

Thanks!

BW.

* This worries me. It seems accurate and reliable as I gleaned the information from qastrocapture and have tested it with webcam monitor tools and by manually flicking the RTS line on my camera. It is however, counterintuitive and I hope I'm not introducing a race condition as the structure of this driver is that the frames are read by callback which isn't part of the class that's controlling the serial levels so synchronisation is not obviously assured.

Can you please resubmit the patch against the current INDI SVN TRUNK please?

Hi,

Is this better?

Regards,

BW.

Thanks!! Patch applied with few modifications. More testing is now required from other users.