Watching this thread with interested, I have the SXVR M25c and a few years ago that also had similar issues with the driver and weird images, this was sorted by one of the Indigo authors, Peter Polakovic I think his name is, he was very helpful maybe ask him,
The other option is to use the indigo server with ekos, it works just the same and the camera will work with that driver...
I am looking at buying an M26c as I want the smaller pixels...will work better with my scope... :)


AstroNerd replied to the topic 'FOV labels unreadable' in the forum. 3 days ago

Are you using on a 4k monitor, if so then this the least of your worries, it’s all awful on 4k, I have been asking for ages to get it sorted, but it falls on deaf ears I’m afraid.... ☹️


endlessky wrote:

dmsummers wrote: - Pi4 + USB3 + blind hotspot is ok (i.e. NOT mapped back to a 2.4Ghz "infrastructure" internet source).

I use my Astroberry in hotspot mode and VNC into it. Usually everything goes fine, but tonight I couldn't get the hotspot and my devices connected to USB 3 to work.
Could you kindly explain to me how to create a hotspot that works in the 5GHz instead of 2.4?

Right click on the network icon, and then choose settings, in there you choose the hotspot, and settings again, then on one of the tabs you will see the option to have either 2.4, 5ghz or auto, change it there.... :)


FYI, the ASI120MC USB 2 version DOES NOT work properly at all on INdI, even with the ASI firmware update, as has been said it’s not even supported anymore by ASI. Some people have managed to hack together something that works, but you really need to know what you are doing, and even then I am not sure how consistent it really is....


Maritime wrote: I’ve recently begun using a raspberry pi 4 and astroberry with my IPad. I have a 64 gig sd card, and am slowing beginning to understand the various programs, but God the touch responses take forever and screens move like molasses.

What am I doing wrong?


What resolution do you have the RPI set to display over VNC...??


I had this same issue on the M25c a couple of years ago, Jasem will remember. And it was solved after much work, so now works perfectly in the latest INdI and I use on ekos all the time.... :)


geehalel wrote: The motor controller firmware only allows to set speed and direction of motors, there is no notion of tracking state in the firmware. And EQMod can't know that you're pressing a button on the handset before eventually restarting tracking. The same applies to the handset which does not know (or look) whether the mount was tracking before the manual move. A solution would be to start tracking on the handset before the manual move.
When using the synscan driver, it talks to the handset firmware itself, there is an unique state of the mount, I believe.

So how do you explain it happening with no handset connected or used, just ekos with the EQMOD driver...??


switux wrote: Hi Jasem,

Fair enough, however, I tried your synscan driver instead and unless I am mistaken (there is no motor status available), tracking still ran after I played with the handset: same use case, different behaviour (yours makes more sense, if you ask me). I would be quite happy going for the synscan driver except that when I switched tracking off in ekos, it would not switch back on unless I slewed to another target (or the same, I imagine). No indication whatsoever that it even tried to switch tracking on (and failed). I guess I just traded one issue for another ;-)


This error actually happens to me sometimes when I manually move the mount in Ekos, it just stops tracking in RA, no handset attached or used, so it is a bug, and not just when handset is used, the last time I had to completly reset and start over, but if you click “sync” after making any manual movments it does not seem to happen...... :(


AstroNerd replied to the topic 'HiPS in latest git is broken' in the forum. 4 weeks ago

Cerro Torre wrote:

AstroNerd wrote: I have let him know... :)

There is a new commit, time to test.

Yes, he said he would revert...:)


AstroNerd replied to the topic 'HiPS in latest git is broken' in the forum. 4 weeks ago

I think it may be to do with Jasem trying to get it to work properly on 4k monitors, as there were issues....and it did not work well at all.... maybe he broke something....I have let him know... :)


AstroNerd replied to the topic 'Alternatives to Raspberry Pi4?' in the forum. 4 weeks ago

Aurneth wrote: My current rig employs a Lenovo ThinkCentre M93P 'Tiny' "desktop" machine, though it uses a laptop power connector.

The specs of mine include 5 USB 3.0 ports (no 2.0), an Intel Dual-Core i5-4570T Processor up to 3.60 GHz, 8GB RAM and a 240GB SSD. I installed Kubuntu 20.10 alongside Win10Pro. I bought it refurbished so I didn't spend an enormous amount. It also came with a rather lame USB 2.0 2G wifi stick, a cheap keyboard and a mouse that rattles (for real). I upgraded the USB wifi to a USB 3.0 5G dongle with an antenna. I also made some changes to the BIOS to allow booting without a keyboard. I run krfb on it as a remote desktop server (it seems to default to 1024x768 when no monitors are plugged in).

It's about the size of a counterweight and weighs almost as much as well. To mount it I also bought a VESA bracket that holds the computer and which is usually intended to suspend the unit off the back of a monitor or television (obviously not one that's actually mounted to a VESA mount). I built a receiver for the VESA bracket out of plywood that attaches to the end of my EQ6's counterweight bar, so it acts as a counterweight.

It almost weighs enough to properly counterweight the rest of the rig (!), at least when the Evostar72 is on and would probably do so if the guidescope were omitted. I only have 10lb weights (the mount originally carried a 10" Newtonian which I still have) and if I add even one right at the top of the bar it dramatically overbalances the counterweight end, so I'll need to find a way to add some smaller weights to the rig but it is pretty close to balanced already.

As you can see I have a powered USB 3.0 hub velcroed to the backside of the EQ6, so all rig-related USB cables emerge from here. The hub itself uses 12v, so it can be powered from the same distribution centre as everything else, which I have velcroed onto the control panel side of the EQ6.

What's great about this is that the SSD is big enough for all the FITS for plate solving and with fast processors aboard it solves in a second or two. The SSD also has legions of space for saving FITS from the camera.

Nice idea...BUT
One should never run an imaging rig with the counter weight that far down the shaft, it can cause huge loads on the motors when slewing, it’s much better to have much more weight and further up towards the mount head, there has been a lot of research done on this, the initial inertia with a weight that far down I’d bad for the mount.... :)