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?

Read More...

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').

My understanding is that the value would pretty much always be "adu" for all uses specific to consumer-grade astronomical cameras. Maybe in some research environment a camera can be directly counting individual photons, but for what we all do here it should be "adu".

Read More...

Hi all,

I'm trying to write my own Python pipelines to calibrate, platesolve and stack FITS files. My acquisition setup is:

  • QHY163-M / QHYCFW-2 / QHY-5-II (guider) / EQMod (EQ6)
  • indiserver ran via indi-web on a Raspberry Pi
  • Kstars/Ekos with local patesolving

In my script, I load all files in a ccdproc collection and try to iterate on it like this:
for img, fname in collection.ccds(return_fname=True):
But then I get the following error:
ValueError: a unit for CCDData must be specified.

From what I've read here , this seems to be due to a missing BUNIT header in the FITS file. So I've wrote the following workaround:
    for hdu in collection.hdus(overwrite=True):
        hdu.header['bunit'] = 'adu'
        hdu.header.pop('radecsys', None)
        hdu.header['radesys'] = 'FK5'
The problem is that it somehow resets the "created at" value of the FITS file and generally feels like bad practice.

So my question(s) is (are): Are we really missing a BUNIT header or is my code wrong? If we're missing it, is there a way to tell Ekos to write it in?
Bonus question: Say I wanted to run each newly acquired FITS file through a simple pipeline (write the BUNIT value and update the WCS with a freshly solved one), what would be the best way to do it?

Thanks!

Read More...

Adrien Barrajon replied to the topic 'Very unstable Raspberry Pi' in the forum. 1 year ago

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.

Read More...

Adrien Barrajon replied to the topic 'Very unstable Raspberry Pi' in the forum. 1 year ago

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?

Read More...

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!

Read More...

Adrien Barrajon created a new topic ' Very unstable Raspberry Pi' in the forum. 1 year ago

Hello everyone,
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).
Thanks!

Read More...

Hi all,
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?
Thanks!

Read More...

Hello everyone,
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.

Read More...

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?

Read More...

Thank you for your answers.

@hy:
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.

@PDB: I am 90% sure the version I have comes from the native repos of Raspberry Pi OS. apt search kstars shows this:
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 did attempt to install the nightly version on this same install but it was too buggy so I backed off. Now everything works fine except for that solver.

Read More...

Hi everyone,

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

However, if I open the command line to run solve-field instead on the same image, with the same options, it works. Granted, it's not the fastest thing in the world, but I guess a result within 30s or so. The case with the above output is while using "load & slew" but I have the same problem when capturing and solving.

Note that my Astrometry.Net (solve field version: Revision 0.76, date Mon_Sep_3_15:20:15_2018_-0400) is properly configured and I have all the necessary index files too. As I said, solve-field does work alright indeed. Just not with Ekos.

What could be the problem? I can't seem to find any log other than what's shown in the output window ('/home/pi/.indi/logs: No such file or directory').

Clear skies

Read More...

Hi all,

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

Read More...

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...

Read More...