Hi Jaseem,
it has been a while since i looked at the code. work got in the way...
Anyway i did install the dev stack of indi and 3rdparty drivers in order to see what can be done with the gphoto_open as you suggested. however I am not sure how much of the args are passed and i cannot make much sense of some of what is happening...
for instance:
1)
gphoto2 --list-portsDevices found: 4
Path Description
--------------------------------------------------------------
ptpip: PTP/IP Connection
ip: IP Connection
serial:/dev/ttyS0 Serial Port 0
serial: Serial Port Devicethis would lead me to believe that a port "ip:192.168.1.12" in the config panel should be passed on correctly to the driver but i cannot get it to pass .
2) i cannot see how
--camera "Panasonic LumixGseries"3) also i do not get how gphoto_ccd and gphoto_driver are connected.
4) i tried to create lumix entry in the indi_gphoto_xml.cmake which does appear correctly on the ksars camera menu but fails at launch.
5) it seems that none of the attempts i made in modding the gphoto_open led to any consideration in the execution almost as if the original driver was called but i did change the target from /usr/local to /usr/ ...
anyway long one to ask for you to look at this probably simple feat for you but quite complex for me. I would be quite keen to go back and forth with you if you cannot test the actual driver against the lumix cameras...
Thanks in advance
Robert
Read More...
i have been working with Marcus Meissner to include Panasonic Lumix cameras in libgphoto2 over wifi/http. ( github.com/gphoto/libgphoto2/tree/lumix ) this is starting to work well form gphoto2 CLI however the --auto-detect option is not yet avail since libgphoto does need the IP address of the camera to connect to it. so at the moment the CLI options for gphoto2 are:
gphoto2 --port ip:192.168.1.14 --camera "Panasonic LumixGSeries"Is there a way to configure the indi gphoto driver to include these options at startup instead of relying on the --auto-detect?
Thanks
Read More...
thanks but in that case will the file still not reside on the Pi? i want to save space really. Reading "both" seems to double the disk space required. Am i getting this wrong?
Read More...
My setup :
canon 6d II via usb//RPi /gphoto/Indi/Ekos-Kstars -
in a session/sequence, is there a simple way not to receive the pix on the RPi?
the remote/client option still assumes that either the Indi server of the Ekos client receives the FITS/native image from the camera. In my case both are on the same machine (RPi). So somehow the image gets onto my RP. I understand this is needed for the astrometry and/or focusing but storing all files fills up the precious little space i have on the RPi .
thanks
Read More...
AstroNerd wrote: I currently use the EQMOD INdI driver, with a serial to USB EQMOD cable, so this replaces that said cable..? And is there one with serial plug for NEQ6 mount..?
Is this better than the Bluetooth dongle that you can get for these mounts..?
Sorry for all the questions..
Yes this replaces the USB/Serial EQMod cable.
The Wifi Adapter from Skywatcher plugs straight into the Synscan Handset. Plug (where you currently plug your EQMOd cable) .
Wifi gives you longer range than bluetooth, also more than 1 device can send commands to the mount in that configuration (best if it is not simultaneaous) . In fact I am both on Indi/rapsberry and sometimes need to switch to ASCOM. with the wifi adapater there is only Indi to turn off and start ascom. no need to go and visit the mount and replug..
Read More...
A flurry of feature requests:
1) remove focuser tab when not needed: if there are no focuser selected in the device list (could be my next purchase!) of INDI would be nice to remove the corresponding tab in EKOS and remove the option from the schedule. Leads to often starting jobs in scheduler with the "focuser" check box on.
2) GPS from DSLR: DSLR cameras have GPS sensors in them. is there a way to extract the data from the exif (or some other way) to include as a new GPS driver?
3) automated mosaiking: could be nice to create an automatic mosaic schedule of an object based on the sensor size. e.g. large objects like m31, Rosetta, North america, etc often are larger than the FoV of sensor/tube combination. (same is true for the Moon/sun) the Guider/scheduler could work together to create a composite of n tiles
4) Horizon: would be nice to borrow the Landscape feature of Stellarium to build an horizon line from 360 images instead of "simpler polygons". (at least for the gnomonic projection (see view from my terrasse as an example)
Read More...
not sure if this works in the same way as the SkyFi but i have connected the EQMod driver over "ethernet" port (instead of USB/Serial) to the skywatcher WiFI Dongle. The procedure is the same as explained in the following post:
www.indilib.org/devices/telescopes/az-gti.html
for AZ-GTI mount.
Read More...
Posting it here as i have not found a positive test of this setup.
This is not a cry for help but rather a post to report that the EQMOD driver works very well with the
SynScan Wifi adapter
to plug in on the the Skywatcher mounts. The procedure is the same as the one published for the
https://indilib.org/devices/telescopes/az-gti.htmlAZ- GTi
.
No need of cables from the Indi Server to the Mount. Just configure "ethernet" enter the IP address of the mount and the Port 11880 and voila. No need of SynScan App either. it truly replaces the direct USB cable...
Clear Skies
Robert
Read More...
Honestly i did not look into it much but found a post that mentioned it solved issues of connectivity with USB/Webcams.
which seems to match my own behaviour where it works fine to start with and then cannot find the device on the port.
www.raspberrypi.org/forums/viewtopic.php?t=197089
Read More...
after some thinkering i have a more stable situation:
- I guide with PHD2
-i changed added to the /usr/boot/conf.txt
dwc_otg.fiq_enable=1 dwc_otg.fiq_fsm_enable=1 dwc_otg.fiq_fsm_mask=0x3
Read More...