Charles Wright replied to the topic 'Mount is parked after polar alignment - why?' in the forum. 3 months ago

Hi again,

The procedure worked great, I think, but now I have a conflict between the results from the polar alignment tool and PHD2's Guide Assistant.

I did not bother with parking; just used the HC to turn the mount to 4 hours east by the hour angle reading. I don't have any screen captures or logs, but I recall the measured polar misalignment was less than an arcminute. I've repeated this procedure several times, each time the error vector is very short (~ 10-20 pixels long), and it's difficult to make any improvements. With my image train I'm running at 0.63 arcsec/pixel, if that helps.

When I use PHD2's Guiding Assistant, it tells me the misalignment is ~ 7 arcmin. I have to wonder which measurement is correct. My guess is that PHD2 is more correct, since I can watch the DEC error slowly increase over time. If anything, maybe their scale factor is wrong, but I sort of doubt it.

Anyway, perhaps I should start a different thread on this, but I'd be interested to hear any advice. I'll get back with screen captures and logs next time I go out.

Thanks,

Charles

Read More...

Charles Wright replied to the topic 'Mount is parked after polar alignment - why?' in the forum. 3 months ago

Thanks, guys, this will be helpful.

The CEM60 leans heavily on "zero position" (pointing at the pole with telescope vertical) - or maybe I do, since the hand controller insists on you powering off the mount after a park. I have not tried setting a park position in EKOS, thinking that would do the same thing.

My method has been to run the polar alignment several times, starting at zero position and returning to zero position after each run of the procedure. I don't have a permanent setup so I do this frequently.

I like the idea of rotating in RA more than 30 degrees during the alignment process, and also the idea of taking the images from both sides of the mount. Tell me if this is a good idea:
1) Set a park location with an RA 60 deg east and the scope pointed at the pole.
2) Run the polar alignment process, moving 60 deg west each time
3) Auto-park back to the first position

Good idea?

Thanks again for the help,

Charles

Read More...

Charles Wright replied to the topic 'Guiding nightmare' in the forum. 3 months ago

Hi,

I highly recommend using PHD2 for guiding. I had problems like you are describing for at least a year, up until early July, which is when I switched to PHD2. Since then, guiding has been much much better.

PHD2 is fairly well integrated with EKOS, but it does require that you start it up separately from kstars/EKOS. This has not been a problem for me.

A very useful part of PHD2 is Guiding Assistant. I highly recommend using it for 2x or 3x your worm period before you start guiding.

Anyway, I don't mean to diss the guiding in EKOS, but it seems that implementing a guiding algorithm is a lot harder than it might seem at first. PHD2 has so much good stuff in it, plus excellent documentation. I don't know what the magic is, but I'd give PHD2 a try.

Charles

Read More...

Charles Wright created a new topic ' Mount is parked after polar alignment - why?' in the forum. 3 months ago

Hi,

I am just now able to try out Kstars 3.3.6, after having used 3.3.4 for some time. Everything is good, except for what happens after the polar alignment procedure. I go through the mount adjustments, then click "Done", and the mount starts moving. The first time this happened, I panicked, but it turns out the mount was apparently commanded to park. This behaviour is different than the previous kstars/EKOS behaviour, in which clicking "done" just stopped the image looping and left the mount where it was (either RA +60 or -60 from zero position).

I don't like this. I never park my mount. A CEM60 wants you to power off the mount after it is parked - I don't want to do that for lots of reasons, not least of which is why should I power cycle my mount just because I polar aligned it? Parking means end of the night, not just another step in getting ready to image.

Anyway, perhaps I'm doing something wrong, or have missed an option somewhere. Thanks for any help with this.

Best,

Charles Wright

Read More...

Charles Wright replied to the topic 'A better FITS viewer?' in the forum. 4 months ago

Thanks for pointing out that about fitsviews. I was not suggesting that all be separated from Ekos, just that the fitsviewer might run in its own process or thread.

But anyway, I have not looked for any Linux FITS viewers out there. Perhaps this link is a good start? fits.gsfc.nasa.gov/fits_viewer.html

Read More...

Charles Wright replied to the topic 'A better FITS viewer?' in the forum. 4 months ago

Hi all,

I'm late to the conversation, but this topic has been in my head for a couple months now. I'd like to chime in.

First, I'd like to add to the list of people who experience whole stack crashes when fitsviewer has a problem. It seems to happen for arbitrary use of features in fitsviewer, seemingly anything that goes beyond zooming, panning and using some of the information tabs (e.g., FITS header). The behavior is that suddenly I notice that nothing kstars-related will respond to clicks (kstars, fitsviewer, EKOS, INDI windows), then, after some time has passed, all windows disappear. I use a RPi for running INDI server and an Intel desktop machine with 32 GB RAM for kstars etc. so I don't think it's the RPi's limited memory causing this. (I've seen it happen when I just start up kstars to view FITS files and don't connect to the RPi)

Anyway, aside from an obvious suggestion to fix that problem, here are some other suggested improvements:

  1. Make fitsviewer stand-alone. I'd like to use Linux to do quick views of FITS files, and fitsviewer would be handy for that independent of kstars. This also might make the system more robust, since if fitsviewer were its own process (is it now?) it would be less likely to bring the whole system down when it crashed.
  2. I agree that manipulating the histogram and such gives the feeling that there's a permanent change in the FITS file. I'm glad there isn't. OTOH, it would be great if it were a lot easier to scale intensity. The best example of this is from Nebulosity: just type in the lower and upper values defining black and white and use a linear mapping of values between those limits. Neb does this extremely fast - no waiting for processing to happen. To go beyond that, the scaling that CCDStack does, providing a black point and a white point, plus DDP and gamma also happens very fast, but in my opinion is a "nice to have" (others may think differently). At the very least, it should be easier to understand what the black and white points are in the existing fitsviewer. Not clear at all if that information is present. An "autoscale" button would provide the default scaling; I like the idea that Guido had about saving a scaling (item 2 in his list).

Thanks for listening!

Charles

Read More...

Charles Wright replied to the topic 'QHY5 not found by Ekos' in the forum. 6 months ago

AradoSKYindi wrote: Hello CRW4096,
This session variable is setup in 85-QHY-Cameras.rules. The 85-QHYCCD.rules has the device parameters.


There *is* no "85-QHY-Cameras.rules" file. There is only "/lib/udev/rules.d/85-qhyccd.rules". I have grep'd the entire system:
$ sudo find / \( -name '*QHY*.rules' -o -name '*qhy*.rules' \) -print
/lib/udev/rules.d/85-qhyccd.rules
/home/pi/git/indi/3rdparty/libqhy/85-qhyccd.rules
These are the only rules file for QHY products, and as you can see, one of them is in my copy of the git repo and hence not active. I am attaching this file for your scrutiny.

Charles

Read More...

Charles Wright replied to the topic 'QHY5 not found by Ekos' in the forum. 6 months ago

Hi,

I played around with "udevadm monitor" while plugging in the QHY5-II-M. I don't know what to make of it. It does seem to follow Guido's description of what happens when one of these cameras is plugged in, except for the fxload error. I'm including various logs for your scrutiny.

This is the syslog as I plugged in the device:

Jun 18 21:55:27 indi-pi kernel: usb 1-1.3.5.4: new high-speed USB device number 14 using dwc_otg
Jun 18 21:55:27 indi-pi kernel: usb 1-1.3.5.4: New USB device found, idVendor=1618, idProduct=0920, bcdDevice= 0.00
Jun 18 21:55:27 indi-pi kernel: usb 1-1.3.5.4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Jun 18 21:55:27 indi-pi mtp-probe[890]: checking bus 1, device 14: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.5/1-1.3.5.4"
Jun 18 21:55:27 indi-pi mtp-probe[890]: bus: 1, device: 14 was not an MTP device
Jun 18 21:55:27 indi-pi systemd-udevd[889]: Process '/sbin/fxload -t fx2 -I /lib/firmware/qhy/QHY5II.HEX -D ' failed with exit code 255.
Jun 18 21:55:27 indi-pi kernel: usb 1-1.3.5.4: USB disconnect, device number 14
Jun 18 21:55:29 indi-pi kernel: usb 1-1.3.5.4: new high-speed USB device number 15 using dwc_otg
Jun 18 21:55:29 indi-pi kernel: usb 1-1.3.5.4: config 1 interface 0 altsetting 0 bulk endpoint 0x81 has invalid maxpacket 64
Jun 18 21:55:29 indi-pi kernel: usb 1-1.3.5.4: config 1 interface 0 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
Jun 18 21:55:29 indi-pi kernel: usb 1-1.3.5.4: New USB device found, idVendor=1618, idProduct=0921, bcdDevice= 0.00
Jun 18 21:55:29 indi-pi kernel: usb 1-1.3.5.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jun 18 21:55:29 indi-pi kernel: usb 1-1.3.5.4: Product: QHY5-II          
Jun 18 21:55:29 indi-pi kernel: usb 1-1.3.5.4: Manufacturer: QHY-CCD  
Jun 18 21:55:30 indi-pi mtp-probe[896]: checking bus 1, device 15: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.5/1-1.3.5.4"
Jun 18 21:55:30 indi-pi mtp-probe[896]: bus: 1, device: 15 was not an MTP device

This is the brief output from udevadm:
udevadm monitor -k -u
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[10242.584954] add      /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.5/1-1.3.5.4 (usb)
KERNEL[10242.587013] add      /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.5/1-1.3.5.4/1-1.3.5.4:1.0 (usb)
UDEV  [10242.716144] add      /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.5/1-1.3.5.4 (usb)
UDEV  [10242.737332] add      /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.5/1-1.3.5.4/1-1.3.5.4:1.0 (usb)
KERNEL[10242.902631] remove   /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.5/1-1.3.5.4/1-1.3.5.4:1.0 (usb)
KERNEL[10242.903221] remove   /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.5/1-1.3.5.4 (usb)
UDEV  [10242.912296] remove   /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.5/1-1.3.5.4/1-1.3.5.4:1.0 (usb)
UDEV  [10242.917210] remove   /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.5/1-1.3.5.4 (usb)
KERNEL[10244.879284] add      /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.5/1-1.3.5.4 (usb)
KERNEL[10244.881772] add      /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.5/1-1.3.5.4/1-1.3.5.4:1.0 (usb)
UDEV  [10245.000575] add      /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.5/1-1.3.5.4 (usb)
UDEV  [10245.013969] add      /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.5/1-1.3.5.4/1-1.3.5.4:1.0 (usb)

I plugged in a second time with more extensive logging (udevadm -k -u -p). That output is in the attached file. From above, it looks like the device attaches, removes, then reattaches. In the attached log, it looks like the first group of ADD events have something to do with the product ID "0920" and the second bunch of ADD events are related to product ID "0921".

Mind you, the camera works in Ekos. I am happy to provide any other info if you think it will help figure out why there's an fxload error in the syslog. Otherwise, I'm calling this "fixed"...

Thanks for all the help,

Charles

Read More...

Charles Wright replied to the topic 'QHY5 not found by Ekos' in the forum. 6 months ago

I grep'd through the rules under /etc/udev/rules.d. There are only 3-4 files there, one of which I put there to assign fixed serial port names to my focuser and telescope.

I did a "sudo find / -name '*.rules' -print" to make sure there weren't unexpected places where rules files were lurking. This correctly found all the rules files under /etc/udev and /lib/udev, as well as under the INDI git repo clone, and no other places.

I've reading about the "udevadm monitor" command this morning. Might this be useful to seeing what's going on when the camera is plugged in? "udevadm test" might be useful, too...

Read More...

Charles Wright replied to the topic 'QHY5 not found by Ekos' in the forum. 6 months ago

Well anyway, it does work now. lsusb shows the product id is now "0921", and Ekos recognizes the device and can loop in guiding to get images. No idea why it's working.

I don't know why that error shows up in the logs indicating that fxload failed. The argument for -D is supposed to be "$env{DEVNAME}", and the fact that it's an empty string certainly seems wrong since every rule in /lib/udev/rules.d/85-qhyccd.rules has the same command argument, which makes a person think it's important...

I grep'd all .rules files on the system and the only one specifying vendor ID "1618" and product ID "0920" is the QHYCCD ruleset under /lib.

So, something else must be loading the firmware, or otherwise hooking the device up? Mystery to me...

Read More...

Charles Wright replied to the topic 'QHY5 not found by Ekos' in the forum. 6 months ago

So I tried anyway and installed fxload. It doesn't seem to work. Below is the output from journalctl -f, and attached is the output from indiserver -v indi_qhy_ccd. I think I'll be uninstalling fxload.

Charles

Jun 16 19:27:06 indi-pi kernel: usb 1-1.3.5.4: new high-speed USB device number 8 using dwc_otg
Jun 16 19:27:07 indi-pi kernel: usb 1-1.3.5.4: New USB device found, idVendor=1618, idProduct=0920, bcdDevice= 0.00
Jun 16 19:27:07 indi-pi kernel: usb 1-1.3.5.4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Jun 16 19:27:07 indi-pi mtp-probe[543]: checking bus 1, device 8: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.5/1-1.3.5.4"
Jun 16 19:27:07 indi-pi mtp-probe[543]: bus: 1, device: 8 was not an MTP device
Jun 16 19:27:07 indi-pi systemd-udevd[542]: Process '/sbin/fxload -t fx2 -I /lib/firmware/qhy/QHY5II.HEX -D ' failed with exit code 255.
Jun 16 19:27:07 indi-pi kernel: usb 1-1.3.5.4: USB disconnect, device number 8
Jun 16 19:27:09 indi-pi kernel: usb 1-1.3.5.4: new high-speed USB device number 9 using dwc_otg
Jun 16 19:27:09 indi-pi kernel: usb 1-1.3.5.4: config 1 interface 0 altsetting 0 bulk endpoint 0x81 has invalid maxpacket 64
Jun 16 19:27:09 indi-pi kernel: usb 1-1.3.5.4: config 1 interface 0 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
Jun 16 19:27:09 indi-pi kernel: usb 1-1.3.5.4: New USB device found, idVendor=1618, idProduct=0921, bcdDevice= 0.00
Jun 16 19:27:09 indi-pi kernel: usb 1-1.3.5.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jun 16 19:27:09 indi-pi kernel: usb 1-1.3.5.4: Product: QHY5-II          
Jun 16 19:27:09 indi-pi kernel: usb 1-1.3.5.4: Manufacturer: QHY-CCD  
Jun 16 19:27:09 indi-pi mtp-probe[548]: checking bus 1, device 9: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.5/1-1.3.5.4"
Jun 16 19:27:09 indi-pi mtp-probe[548]: bus: 1, device: 9 was not an MTP device


Read More...

Charles Wright replied to the topic 'QHY5 not found by Ekos' in the forum. 6 months ago

Hi Guido,

I am back and tried your advice. Short story: errors appear in the syslog because /sbin/fxload does not exist on my RPi! I am puzzled by this. If firmware has always been loaded, how did my system work if fxload does not exist? Anyway, see below for details.

Here's the output from journalctl -f when I plug in the camera:

Jun 16 18:42:56 indi-pi kernel: usb 1-1.3.5.3: new high-speed USB device number 10 using dwc_otg
Jun 16 18:42:56 indi-pi kernel: usb 1-1.3.5.3: New USB device found, idVendor=1618, idProduct=0920, bcdDevice= 0.00
Jun 16 18:42:56 indi-pi kernel: usb 1-1.3.5.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Jun 16 18:42:56 indi-pi mtp-probe[710]: checking bus 1, device 10: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.5/1-1.3.5.3"
Jun 16 18:42:56 indi-pi mtp-probe[710]: bus: 1, device: 10 was not an MTP device
Jun 16 18:42:56 indi-pi systemd-udevd[711]: failed to execute '/sbin/fxload' '/sbin/fxload -t fx2 -I /lib/firmware/qhy/QHY5II.HEX -D /dev/bus/usb/001/010': No such file or directory
Jun 16 18:42:56 indi-pi systemd-udevd[709]: Process '/sbin/fxload -t fx2 -I /lib/firmware/qhy/QHY5II.HEX -D /dev/bus/usb/001/010' failed with exit code 2.
Jun 16 18:42:56 indi-pi systemd-udevd[712]: failed to execute '/sbin/fxload' '/sbin/fxload -t fx2 -I /lib/firmware/qhy/QHY5II.HEX -D ': No such file or directory
Jun 16 18:42:56 indi-pi systemd-udevd[709]: Process '/sbin/fxload -t fx2 -I /lib/firmware/qhy/QHY5II.HEX -D ' failed with exit code 2.

Of all the files mentioned in the command line, it's /sbin/fxload that doesn't exist. I searched for "ubuntu fxload" and found a link back to INDI (Raspberry Pi) , which says this:

fxload version in Raspian does not support uploading firmware to newer cameras (fx3). So in order to support these cameras, you need to build a recent version with fx3 yourself.

Perhaps this is the issue? (BTW, I don't understand what it means)

This is the first time I built INDI from the git repo. Before this, I downloaded compiled packages from that same URL. Things magically worked, but if I make it myself, perhaps there are other prerequisites I need?

Thanks,

Charles

Read More...