BCN_Sean

I've guided with one previously on an older Macbook Pro before using PHD2; but I've not tried it with anything more modern than OS X 10.11 or a Mac that was built after 2012. I don't know how it'd fare with a more modern Mac, as there's been a lot of changes in the last ten years especially in the things like the USB systems on Apple machines so I don't know if they'll be less tolerant to the USB problems the original ASI120 (and by proxy, the T7 which is a clone of) had by design.

Unsure to what to make of it as it seems to be moving away from a lightweight, fizzy little star tracker and closer to another type of EQ-3 class mount; and in to the sort of price territory as other EQ mounts. For the money it seems to be going in for, I really hope they've not gone for the same design in the altitude adjustment in the wedge as they have on the normal Star Adventurer as whilst the sloppy, clicky backlash on a toss in box candy on a ~400€ tracker is stomach-able, not unusable and replaceable, on a 600€ machine that's fixed install would be a bit painful. The 62 Evo is out there, just don't know when it's going to be available. This fella here (youtube) has mentioned it a few times on the Star Adventurer page on Facebook.

That's a big improvement; that reduction in shift is quite considerable. It's just got me thinking about one of the things that the niece is doing on a school project and she was grumping at me about it not returning the expected readings when she last visited; looks like I'll have to put my crazy uncle hat on this weekend and have a look!

I've seen similar behaviour with other temperature sensors before, one of them on the AF units I've built (can't remember the model number off the top of the head) and this may muddy the water a bit for you, but what I traced some of it down to was the 5v line being unstable; so whilst the motor was racking in and out, there was a voltage drop on the 5v which in turn messed around with the calibrated (startup) reference value so the sensor was thinking that the air temperature had changed because of that. In the end I moved that one off an Arduino on to a Wemos D1 Mini as that's the only dev-board I could find that didn't jack around with regulators and current diodes between the USB Vin and the 5v rails.

Here's the datasheet for it https://www.sparkfun.com/datasheets/Sensors/Temperature/DHT22.pdf, according to that, it should have it's own low power state modes.

Why not just read the elevation data in the site management for the mount and pass it that way?

A couple more things to try, in the options for the alignment; in the Scale and Position options, make sure the Use Scale is selected (and also try toggling Use Position), and another one that's caught me out a couple of times on my mount (also via EQMod) is that if the mount is not tracking then it may fail (even if the exposure is short) with the solving for polar alignment. Also another thing I've learned from it is to speed it up a bit is when the mount is pointing somewhere before starting the process, syncing it through the kstars interface to a rough ball park area (right click, eqmod->sync).

If you've already got a Raspberry Pi4, have a look at the Astroberry project; that has the kStars/Ekos software suite built in to it which offers a full pacakge of scheduling, image capture, guiding, and a lot more.

Not the poorly paid, but less accessible to the impatient/inquiet; my AP rig, that's taken 18 months so far from starting to get back in to looking up to the point where I'm starting to be happy with the results I'm getting from it. All in, summed in with a camera I already owned, finding an optic I liked that is close to scale matched, focusers, heaters, guiding (though it doesn't guide in DEC, but it would if I broke out the soldering iron and built a motor bracket) it's cost me less than a week for a family of four at Butlins over easter. Over the same time, a few folk I know have also got in to pointing glass above the karman line, but with their impatience and Pavlov's dog-esque behaviour when given the option of next day delivery have spent a lot more on a lot less. As my grandmother used to say "Prudence and patience pays in the long run, but a fool and his money are easily parted."

Not got that far in to it at the moment; though not had much chance this week what with trying to integrate a new camera to the portable rig and the central heating boiler packing up. There was something that I was looking at the other day regarding the end times, from using the data I'd collected and working backwards it seemed that (though this just could be me) the exposure times were sitting two decimal places to the right compared to where I was expecting them. It's not a problem yet, as it could have easily been me, as I've not had time to sit down and dedicate a few hours to go back in to it without interruption.

@dan_adi, I've had a look under Monterey as well, and it's working the same as on the other one. Also (don't kill me for this!) I've had a bit of a noodle around in the code by adding a function to detect whether MacOS is running dark or light, and set the colours accordingly. Here's on Monterey (Dark) Again but on Light Here's the ETC.py with the changes in And here is a quick and dirty text file generated with diff to show the line numbers where I've made the changes. ETC_Changes.txt ETC.py

These were just numbers I was popping in, when I've found the sensor data for the D810 I'm going have a deeper look in to it to work backwards from the data I've already collected; this just clicking around to see if things were working or not. I think so too, was trying last night to add different (documented) flags in to the configuration and it was throwing errors about certain flags weren't found (fg/foreground being two). Later on I'll put it on the other machine and have a look as that's currently not got Python outside the OS installed version, and pull it all together outside of homebrew as I've a bit of a suspicion that homebrew is installing some different versions of libraries.

I wouldn't say I'm proficient at it, just have it about for working with the occasional script and whatever that pops up; and after looking up a couple of other dependencies I didn't have here's the result. What did interest me, though, was tkinter not accepting the fg setting, Not got time to look in to it further tonight, but have had a couple of runs with it, and nothing noticeable error wise popped out (aside from a memory page error generated by Python, but that isn't an error at the moment as the rig is rendering a heavy video at the same time). So far it looks good, and when I'm caffeinated tomorrow, and got a couple of hours to dedicate to it, I'll have a deeper look in to it and I'll have a look on the other machine (running MacOS12) as well.

Just watched some, and bookmarked that video for later to finish watching, got about 20 minutes in and I realised that I was twirling a hex wrench between the fingers. I've discounted the EQ3 in the past for the balcony mount as with hearing about the friction and bearings every so often it put me off. Just wondering if that red felt one in the dec would be better served with a PTFE bearing instead of a ground shim ring.

Not working on 10.15.7 with Python 3.9 installed; it's throwing up an error that it can't find the runtime locations.