Hi, thanks for getting back to me on this Yeah I'm pretty sure that I clicked the Write Data button, I have a ParkData.xml file with the following data in it:

I assume that this data should be restored automatically one next driver use? I'll try and get out today to have another test with the mount, I can do that in daylight

As for my webcam, it's controlled via a usb->serial device, on the RTS line. It's the most basic mod, just to get LX frames, I haven't done the amp off. In wxAstroCapture I have all the tick boxes selected for RTS, except amp control, and perhaps the key thing is the Inverted Logic option for LX Frame is selected too. I guessed that the equivalent option was the HIgh->Low / Low->High setting in the LX settings. Perhaps you can give me a rough idea as to what settings I should be using for this type of device?

Thanks!

Ok, the position has been saved but the figures here correspond to the default position (NCP). Maybe you can have a quick test if you manually change these 2 figures directly in the file, the reticle should not be on NCP anymore. Another point is the name of the device , "EQMod Mount" here, which is checked when loading Park data (in case you have several mounts). So it should be the same when restarting the indiserver.
I had a look to wxAstroCapture, the settings panel is confusing regarding some schematic diagram I've found: if I consider the default settings (this is what you use if I understand), the transition for LX Frame is on DTR, not RTS (which is for LX amp). The schematic given with K3CCDTools however shows the contrary. Which modification diagram did you use?
By the way, you're right that the Low/high and High/Low setting is equivalent to inverted logic.

Ok, so I've just been out in the sunshine to test the mount driver, and I take it all back, it works perfectly! It did take me a couple of tries to get it right... I deleted my ParkData.xml file, and manually set the mount and scope to the home position. Then I slewed the mount to a custom park position, hit the current button, and then write data. Then I hit the park button. I disconnected and powered everything off, and then fired it all up again, and the driver remembered that the mount was parked and where it was pointing Hitting park to unpark the mount didn't result in a slew to anywhere, previously it shot off back to the home position. So clearly that issue was entirely down to user error. Sorry for wasting your time.

And as for the LX webcam, well a picture speaks a thousand words:



To be honest I'm not sure if I need all of those options ticked or not, but that's what I currently have, and it works. I shall have to experiment further to see if any of those are unnecessary so I can get a better handle on how I need to configure the indi driver.

I just tested with wxastrocapture: with your config it sets RTS (pin 7) from -6V to +6v when starting the LX exposure. The indi_v4l2_ccd do the same using the Low to High transition which is the default. Did you set the used port ('Lx Port' just above setting DTR/RTS/Command) to the correct value (/dev/ttyUSB0 in your config) ? It is set by default to /dev/ttyS0 (I first forgot that when I tested...).

Hi, sorry about the delay getting back to you, life has just been doing that annoying thing of getting in the way of my hobbies!

I've brought the LX Webcam out of my observatory so I can tinker about with it on my desk, which is much easier. Here is a screen grab of the LX settings tab:



I think those settings are what I should be using, I have tried both the Low to High and High to Low options, but with the same results... I get an image back, but it appears to be a regular frame from the camera, not an LX one. It doesn't matter how long I set the exposure for, the image remains the same. And testing indoors, during the day I would expect it to white out really quickly! For reference, this is the guide I followed to make this webcam long exposure: Philips SPC900NC uncovered

Hi,
Sorry for the delay, quite busy these times.

Did you look to the indiserver log messages ? There could be a permission issue when the driver process tries to open your serial /dev/lx_webcam port. Such an issue should be reported by the driver. Otherwise my last idea about this issue is that the driver does not capture the right frame as it does when using the LED mod. It could be a timing problem as the driver first toggles the LX signal then enables streaming in the kernel video driver to capture the first incoming frame. The LX frame may have been dropped or lost between these 2 events.

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.