I am the one who wrote astro-pipelines and I'm not sure how to fix that! As I explain on the post above, my workaround is to actually write that header down before loading any collection with ccdproc.
Maybe the right way to work it out is to have a part of my pipelines automatically running on each captured frame freshly coming out of Ekos? But then I'm not sure how to properly implement this. Would the best way to have it done through the "post-capture script" hook on Ekos? Or with a separate script that monitors new files in the folder and processes them?
I really don't know anything about how standard that header is, as I've only learned its existence when seeing that error I'm getting from my Python scripts. I solved it by creating the header with the value "adu", so that's what worked for me.
Here is the paragraph about this header in the FITS standard:
KEYWORD: BUNIT REFERENCE: FITS Standard STATUS: reserved HDU: image VALUE: string COMMENT: physical units of the array values DEFINITION: The value field shall contain a character string, describing the physical units in which the quantities in the array, after application of BSCALE and BZERO, are expressed. The units of all FITS header keyword values, with the exception of measurements of angles, should conform with the recommendations in the IAU Style Manual. For angular measurements given as floating point values and specified with reserved keywords, degrees are the recommended units (with the units, if specified, given as 'deg').
I'm trying to write my own Python pipelines to calibrate, platesolve and stack FITS files. My acquisition setup is:
for img, fname in collection.ccds(return_fname=True):
ValueError: a unit for CCDData must be specified.
for hdu in collection.hdus(overwrite=True): hdu.header['bunit'] = 'adu' hdu.header.pop('radecsys', None) hdu.header['radesys'] = 'FK5'
Thank you all for your replies and guidance on troubleshooting. I can confidently say now that it's a power issue on the USB. As Kevin was suggesting, I checked the logs and found indeed low voltage warnings. I ordered a good rugged powered USB hub that will hopefully solve my problems.
In the meantime, I have two "solutions". One of them is to keep rebooting and replugging stuff until it works. I boot the Pi, and once I see it in the network I plug devices one by one, slowly, keeping an eye on the ping. Whenever the ping drops (as in it stops ponging back), I just disconnect stuff and reboot the Pi to try again. About 25% of the time it works, and when it does it's good for hours.
The other solution is to not plug the filter wheel and stick to luminance for now. I noticed the rig is a lot more stable (about 80% success) when there is no filter wheel.
You can guess by reading my "solutions" how frustrated I was when trying to make things work! It worked fine back in the good old days where I had a DSLR, an autoguider and a mount, so I ended up relying a lot on that Pi. But now it's pretty much unusable until I get that hub (hopefully).
For information, it's a Pi4B with 4GB RAM. I also tried with a Pi4B 8GB (by swapping the SD card) but did not notice any improvement.
Frustratingly, when I do so everything works fine. But I suspect that's because my monitor is closer to my WiFi hotspot so the Raspberry doesn't struggle as much to connect to it?
Thank you all for your answers, and sorry for wasting your time... This was just me playing for the first time with a camera that allows you to modify gain and offset. I played a bit with these settings and ended up with images that look a lot more like what they should!
I'm trying to run an astrophoto rig through a Raspberry Pi and I find the latter extremely unstable. The Pi is headless, so I only see it through ping and ssh, and I noticed that it often disappears off the network (to which it is connected via WiFi) when I connect a device.
If I start the Pi with all the gear connected to it, it simply won't show on the network, not sure why. So I have to start it and then connect the gear once it's connected. But even then, while doing so I observe a momentary drop in the ping, and sometimes (around 50%) it just leaves the network and doesn't come back until I reboot it.
Needless to say, this is very frustrating! Is it due to USB power? Would a USB hub solve my issues?
Raspberry is running latest Raspberry Pi OS with all the latest indi drivers (it is not an Astroberry). Equipment is QHY163M (main camera), QHY-5-II-M (guider), EQMod (EQ6) and QHYCFW2 (filter wheel).
I have problems with my QHY163M camera becoming irresponsive after using live view. I don't get any error message, the logs are empty, but the camera doesn't respond. In the INDI control panel it hangs when I try to do anything including disconnecting. I have occasionally also noticed the same issue with my QHY5-II-L guider, but it generally works better. The only way to solve this seems to be killing indiserver and restarting it.
The full setup is:
- EQMod mount (EQ6)
- QHYCFW2 filter wheel
- QHY163M main camera
- QHY5-II-L autoguider
It's all controlled via a Raspberry Pi, but I've also tried this from a laptop running Archlinux with the same results.
Anyone has faced a similar issue?
I managed to get my QHY163M camera working with INDI after copying fxload from the SDK into my /usr/sbin folder. Now everything seems to work, but the images I'm getting from it look like they have a very limited dynamic range: pixels can only be on some certain ADU values and as a result my files look suspiciously homogenous in the background.
This is one dark (FITS file, 600s @ -20C).
Is this normal? Am I missing something simple in the settings? Or is this weird? And could the fxload replacement manip be the reason for this?
Thank you for your help.
That must be the standard then because I can't see it from RaspberryPi OS. I guess my best chance is to try and get this Astroberry repo working on my Pi 400?
Thank you for your answers.
I use an older version that doesn't use StellarSolver. The full output doesn't have any mention of number of stars found:
2021-03-24T23:06:47 Solver failed. Try again. 2021-03-24T23:06:47 Starting solver... 2021-03-24T23:06:47 Solver iteration #1 2021-03-24T23:06:47 Using solver options: -O --no-plots --no-verify --resort -3 195.41 -4 -13.3665 -5 15 -L 1.0315 -H 1.26072 -u app 2021-03-24T23:03:46 World Coordinate System (WCS) is enabled. CCD rotation must be set either manually in the CCD driver or by solving an image before proceeding to capture any further images, otherwise the WCS information may be invalid. 2021-03-24T23:03:45 Detected Astrometry.net version 0.76 2021-03-24T23:03:45 Idle.
kstars/stable,now 5:3.0.0-1 armhf [installed] desktop planetarium, observation planning and telescope control kstars-data/stable,now 5:3.0.0-1 all [installed,automatic] data files for KStars desktop planetarium
I have Kstars/Ekos installed on Raspberry Pi 400 running an up-to-date Raspberry Pi OS. I'm running the Kstars version from the repo (3.0.0, Build: 2018-12-21T13:43:03Z). The offline solver option in Ekos always fails after not even a second with the following output in the console log.
2021-03-24T17:37:35 Solver failed. Try again. 2021-03-24T17:37:30 Starting solver... 2021-03-24T17:37:30 Solver iteration #1 2021-03-24T17:37:30 Using solver options: -O --no-plots --no-verify --resort -3 217.433 -4 -62.6795 -5 15 -L 1.0315 -H 1.26072 -u app
I used to control an HEQ5 with an EQDirect cable - RJ45 version. Now I swapped mount, and I have a NEQ6, which I can still control via EQDirect but the input is DB9, and no longer RJ45.
I've looked online for some RJ45 to DB9 adapters and got a bit confused. They do exist, but they may be different one from another. For example, I find this kind, that needs to be wired. So I assume different adapters should be wired differently? So how can I find out which RJ45 to DB9 adapter will work in my use case? Or, where can I find instructions on how to wire the adapter if I end up buying a non-wired one?
Thanks for you help
Thanks for your answer!
I already own an EQDirect cable, but the RJ45 version. I'm curious as to wether I can simply use the same cable, and just add an RJ45 to DB9 adapter, but it looks a bit more complicated than I thought...