If your Pi hangs while compiling the Kstars/INDI suite with message :
Message from syslogd@fedberry at Sep 20 13:42:39 ...
kernel:thermal thermal_zone0: critical temperature reached (80 C), shutting down
Connection to fedberry closed by remote host.
Connection to fedberry closed.
just remove the ' -j4' parameter in your make command.
Its not a bug, you're just asking too much from a poorly cooled Pi.
You are trying to affect wrong data to your profile! You are trying to define a 6x6 pixels image starting at 5505h and 3670v (The END of your image ! ) Actually the left column is right. 0,0,5505,3670. Enter those values in the right column, then click "Set". Once this is done go to the "Options" tab and click "Save" then "Reload". Your profile should be set correctly.
What I see of your file seems correct. But the file is much bigger... Best thing to do IMHO is delete this file and the "Canon DSLR_config.xml.default" if there is one. This will clean everything about you 6D. You can then restart the procedure.
Have a look at /home/yourlogin/.indi/SomethingLikeCanon\ DSLR-config.xml on the machine that runs the indiserver.
Open it with your fav. editor :
Search for <oneNumber name='CCD_MAX_X'> and set the proper Hres
Search for <oneNumber name='CCD_MAX_Y'> and set the proper Vres
Do the same for <oneNumber name='CCD_PIXEL_SIZE'> and set it. (if you don't know the size of your Pixel use sensor Hsize / Hres)
Do the same for <oneNumber name='CCD_PIXEL_SIZE_X'> ( sensor Hsize / Hres )
Do the same for <oneNumber name='CCD_PIXEL_SIZE_Y'> ( sensor Vsize / Vres )
Exemple: My Nikon D3100 has a 23.1mm sensor. As I know the pixel is squared, I just need to do 23.1 / 4672 = 0,004944349 So my Pixel size is 4.94 : 4672 is the real size of the sensor, not the used size (4608).
Save and restart. If it still does not work, then, as Jasem said, your database is corrupted. In that case, just erase the file (?? DSLR-config.xml), the default file and restart the procedure. This time, it should work
Maybe the simplest way for observing on the field is to use kstarslite on your cellphone, connected to your Pi using the WIFI. I don't use it right now as most of my astro time is dedicated to astrophoto but as far as I remember, it worked well enough.
In the indi setup on klite, you have a paddle to center your object. You also have an all-red nightvision theme. this should meet your expectations.
Sorry, it does not work with the Pi4. I've just read that on a Pi forum :
"The Pi4 uses a different boot loader to the earlier models. It is stored in eeprom on the board instead of part in the chip and part on the SD card. An update and instructions on how to apply it will be issued when the USB and network boot is ready.The old program_usb_boot etc configurations have no effect on the Pi4."
Anyway, it's a work in progress. Let's wait
You can try this :
- Install your image both on the SD card and the USB MSD (Mass Storage Device) as usual.
- boot from the SD card.
- Go to the config.txt file (/boot/efi/config.txt, depending on you distro ?) and add this at the end of the file:
- reboot fom the SD card and enter:
vcgencmd otp_dump | grep 17
The answer should be : 17:3020000a If that is not the case, it's hopeless.
If you get the good answer :
- remove the last line you added to the config.txt (program_usb_boot_mode=1)
- turn off th Pi and remove the SD card.
- Install the USB MSD and boot . That's all !
You are now booting from the MSD. (USB Flash, HDD etc...) in 5 to 10secs.
If that does not work, you may try other MSD, some are compatible, others are not.
You may also need to add one or more of these commands to the config.txt :
- program_usb_timeout=1 (gives a 5 secs delay to the boot instead of the 2secs original delay)
- max_usb_current=1 (1200ma for the USB instead of 600ma, for hungry devices)
If it still does not work, try to install a BLANK SD card to add a new 5secs delay.
If it still fails, then your MSD is incompatible.
This works with a Pi2 --> Pi3B+. Not sure with a Pi4 as I don't have one yet.
In my experience, the choice of direction determines where the inevitable dust build-up will occur. Dust seems to accumulate wherever the air enters the case.
With fans blowing in, you tend to get the most dust build up right in front of the fan. You wouldn't want this happening on the heat sink of your CPU, as the dust acts like an insulating blanket.
On the other hand, with fans blowing out, you get dust in the case near every possible way for air to get in.
Probably the best design I've seen involves having two fans, one blowing in and the other out. The exhaust fan sits near the heat sink of the CPU to ensure good air flow there, w/o the dust problem, and the other fan pulls air into the case to keep the pressure in the case high enough to prevent sucking air (and dust) in through all the other openings.
This depends on many factors ....
- The quality of your mount
- The quality of your polar alignment
- The focal lengh of your scope
- The ratio between your focal lengh and the size of your pixel ((206.265/800) *2.4 )) is totally different from ((206.265/2800)*3.80)
What I mean is that you can't compare a 200/800 with an ASI290mm and a 280/2800 with an ASI1600mm.
If you want to compare, you must do it all things being equal .
from a simple terminal something a bit less violent maybe
ssh -t yourPi poweroff
Well, that's an interesting challenge !
Theoricaly, it's possible with one indi server, two different cameras and two kstars connected to the same server. You can already use one camera for imaging and a second one for guiding, so why not ?. Plus this is the superiority of a server/client architecture like indi
But is it a good idea? remember everything goes through your single Pi. So if there is a problem, you break not only one but your two imaging sessions. Oooops !
Let's try something...
First we start the server
Don't use the indi webmanager to start the server. Make a little shell script to start it manually.
[ -e $FIFO_FILE ] && echo $FIFO_FILE exists ! || mkfifo $FIFO_FILE
/usr/bin/indiserver -v -m 100 -p 7624 -f $FIFO_FILE indi_yourmount_telescope indi_simulator_telescope indi_ccd1 indi_ccd2 indi_focuser1 indi_focuser2 >> /var/log/indiserver.log 2>&1 &
Now on the desktop, start two terminal sessions, under two different logins, each one launching one instance of Kstars.
On the first Kstars your profile will be :
- Your Mount
- The first cameras
- The first focuser
On the second Kstars your profile will be:
- Mount simulator (I'm not sure this is mandatory as Ekos only asks for one camera)
- The second camera
- The second focuser
Remember you must use two different cameras and two different focusers or they will appear under the same name in Ekos.
The best way to avoid the bottleneck of the Pi is probably to start the images on each camera so that at the end of the exposure, the two downloads do not occur at the same time.
Example for a 60 secs exposure :
- One starts the exposure now
- the second starts 20 seconds later.
Well, that is just a start ...
See my post as a box with some ideas to pick, not only for you but for every one here. It's certainly not a complete solution You risk nothing to try ...
PS: I personally use 4 PIs to control 4 scopes from the same laptop. I think it's more secure.
Derpit wrote : "... so it might well be that in your case you did hit an error that fsck could not fix."
Right, but considering Ubuntu has most probably a journaling filesystem, this shoud not even happen and a power loss shouldn't do much damage... Those days when a power loss on Unices systems was a catastrophe are long gone . If fsck could not fix the problem, maybe it's because the card itself has been corrupted ?
You said :
"I am using a 2A power source, but the system is headless and there is no ethernet plugged in, no hard disk, so it should be ok. "
The WIFI (if you don't have ethernet then you have WIFI) drains a lot of power. much more than the ethernet. Again, 2A is not enough !