Yes, that is aggravating. But it clearly is Pi4 specific. It does not happen on my Zotac mini-PC, so must have something to do with the Linux implementation on the Pi4.
I am using the same OS you do, but installed it from scratch and then installed KStars and Indi later, so the installation likely differs from your Stellarmate install.
I don't have Pi4 crashes after polar alignment. Mine happen completely randomly during the imaging run. The Pi will happily click away at the stars, download and save the image file and then - poof! - KStars disappears without any warning or prior sign of trouble. Restarting at that point and just reinitiating the scheduler is a matter of a couple of minutes and the imaging picks up from there, no problem.
Obviously, though, it is not possible to rely on a good imaging run under those conditions.

I think I will give a different OS for the Pi4 a try, see whether a leaner system like Manjaro will get rid of the crashes.

As for seeing the other networks: Go to 'Connect to Hidden Wireless Network' and click on the pulldown menu where it says 'New'. The networks you specified previously are shown there. Just select the one you want and connect.

Read More...

knro wrote: There was a fix to a crash in FITS Viewer in nightly builds a few days ago. So it would help to know if you're using nightly or stable. For the advanced users, a <strong>gdb</strong> backtrace would *immensely* helpful.

Unfortunately not.

That was the first thing I did. Establish dedicated profiles for 5GHz and 2.4GHz connections and assign highest priority to the 5GHz profiles. It just wouldn't connect and eventually default to the 2.4GHz connection.

The thing is where I position my rig is in a perfect "Bermuda" Triangle between my wireless extender and my three neighbors. If they have their devices on the same channel as my network and wireless extender, the Pi is bombarded with conflicting signals from all directions. Not much I can do except string an ethernet cable, but that's not worth it. I can run the Pi on the 2.4 band, its just a little more sluggish, but as it is running autonomously on the scheduler through the night anyway, that is really irrelevant.

At any rate, as long as one is aware of the problem, one can work around it.

Read More...

Possible.

Tonight one of my neighbors turned on a Wifi transmitter and I was promptly bumped off. Had to restart the Pi4.
Try to determine whether the same coincidences apply to your situation. You may need to specify a specific channel or use ethernet.

Read More...

Another problem I came across occasionally - and again last night- is that my Pi4 defaults back to Hotspot mode when there are interfering networks in the neighborhood.

Happened repeatedly last night again. I had to get off the 5 GHz band and on 2.4 GHz for the Pi4 to get out of Hotspot mode. Even then, I had to lower the priority of the Hotspot to -20 to give the Pi4 enough time to find my home network.

That could be a major factor as well.

Another factor I suspect is insufficient power to the Pi. Transmitting in 5 GHz may be more susceptible to power drain than on 2.4 GHz.

I ran my Pi4 off battery last night to test how long the battery would last and although it showed 75% full, operations became erratic. I was ultimately unable to acquire any more images, as Ekos reported errors acquiring the image from my Nikon.

At first I thought it was a bug in the driver due to a KStars crash a few minutes earlier, but I restarted the Pi again this morning from inside the house and now the camera connects and downloads perfectly. Only difference was that the Pi4 was now connected to the grid and not to battery power.

I think this may the source of many of the spurious problems we are frequently reading about here.

The Pi4 just needs a lot of power.

Troubleshooting problems when there is an underlying power issue is futile and a waste of time. Likely makes things worse.

Read More...

Remember, I'm not using Stellarmate on the Pi4. I had to find this out the "hard" way.

Stellarmate is making things just too easy!



Read More...

I had the same issue at first, but I appear to have fixed the problem by assigning negative priority connection value to the hotspot in the Wifi connection manager (edit connections in the wifi dropdown menu).
Only when the network finds no other Wifi connections does it now seem to turn on the Hotspot.
Try this out and see if it works for you. I think I gave it a -5 value.
Jo

Read More...

alacant wrote:

knro wrote: This is odd.. what was the original title for this thread?

Hi
'lost guide star: scheduler does not recover'
Thanks

"Anyway, as I understand, my issue was an exception; the repeat the same job every hour is a workaround?"

That's correct.

I also would welcome a solution in which the loss of a guide star for more than 20 s triggers a realignment step - until the clouds are gone, if necessary.

How hard would that be to implement?

Jo

Read More...

stefanr wrote: Hi,
The last post on this topic was written more than a year ago.
Does anyone know if ToupTek cameras (USB 2.0) are working with StellarMate now?

On the camera compatibility list here on indilib.org it looks like all ToupTek cameras are supported, but I want to be sure since I already tried a ZWO ASI camera and failed due to the apparently "well known" issue with ASI USB 2.0 firmware not working correctly with Linux.
And this topic also makes me extra careful about getting a ToupTek camera.

I am thinking about getting this one:
www.astroshop.eu/astronomical-cameras/to...-mono-guider/p,51865

But it must work with StellarMate, otherwise I will return it.

Thanks in advance,