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.

On 08/02/2022 at 14:38, Adam J said:

Yes its a duel axis goto version of the star-adventurer that has been banded about.  But you never know with Sky-watcher they announced an entire range of telescopes in the form of the EVOLUX a couple of years back with a flyer like that one. Those never materialised at all. I say because i see those same scopes mounted in that picture. 

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.

2 hours ago, kbrown said:

I repeated the above test with the changed electronics and code so that I only turn on the DHT22 for two seconds once every minute to take a reading. The results are much better. I ran it this way for two hours and got only about 0.2 degree variance on the temperature reading.

 

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.

2 hours ago, kbrown said:

I don't know what the power requirements for it are.

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.

18 hours ago, kbrown said:

Not that it really matters in my application (I won't be using the elevation information for anything other than displaying it) but it would be nice (=geeky) to get this working a bit better. So my current thinking is that I send the current sea-level pressure to the device from the INDI driver which would get this information online. Here lies my question: where can I obtain this information from? I know it is broadcast somewhere as aircraft pilots use it. Has anyone got any insights on this?

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

On 08/02/2022 at 19:26, dan_adi said:

@BCN_Sean, found two bugs. 

1st in device.py, line 12, Central obstruction should be converted from mm to meters.

2nd in ETC.py, functions ExposureTimePoint and ExposureTimeExtended, pixel surface should equal imageScale **2, because I've already included binning in image scale computation, so delete * binning **2

I didn't catch the bugs early because I've tested with CO=0 and binning=1  😁

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.

4 hours ago, dan_adi said:

must be a bug in Tkinter

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.

1 hour ago, dan_adi said:

Thanks for trying, I will search for a fix. If you have python installed, and I presume you know how to use it

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.

1 hour ago, dan_adi said:

Anyway, if someone uses a Mac, please test the app. Unzip, then run it.

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.

7 hours ago, dan_adi said:

I included CCD and CMOS mono cameras, I'll have to find some DSLR sensor specs and see if it works, or if the results make sense. Given that they already capture color data, the color filters won't make sense, but for luminance and narrow band maybe

Don't go too hard at it, if it's just me showing interest on SLR/OSC type sensors. I think from looking at the cameras I've on the desk at the moment it may be a bit frustrating to work out anything but luminance, as a couple of my cameras share the same sensor the manufacturer differences with the integrated filter show different results with things like wavelength response and colour response.

That looks a great little too.  Is there any way for the user to add their own sensor data to it?  It's quite often I've stood out the back with one of my cameras (all SLR, so may be tricky to find the sensor data) and pondered how long something is going to take.

Start from the bottom and work your way upwards; invest in a tracker and then when you've got a feel for what you are doing, you'll have a better idea of what sort of length of optic you'll want to image through.

If it's small stuff, or a fast prototype, then it's perf-board and point to point; if not it's a fast turn around short order from a fab house in China as it's a lot easier (and when time is calculated in, cheaper as well) than listening to the other half nag on about nasty brew in the kitchen.

I've not used a mount in them temperatures, since I picked up a prosthetic knee a few years ago anything lower than minus 10C is not fun; but have photographed terrestrially in similar previously.  What with the advice about the batteries and cables is good another thing I'd suggest doing is to leave your electronic/photography equipment outside whilst the temperature is higher and let it cool slowly, and then on the other side let it warm up slowly in an unheated environment (garage/outbuilding) or if you do have to bring it in, place it in an airtight box whilst whilst it's out doors and not open it for six to twelve hours after you've brought it in to the warm. 

Just remember to take any memory cards out of the camera before you do as if not they are going to be stuck there until it's warmed through. 

Too fast a transition in temperature (coupled with humidity) can cause condensation to build up, not just externally but internally as well.

I've never managed more than 90 seconds at 200mm with a satisfactory level of keepers with good polar alignment unguided.  Guided on the other hand, it'll sit all night at 300mm on 120 second subs and have a keep rate above 90%; never tried anything above 120 though.  All my stuff is with prime lenses and a full frame camera hanging off the back, so a weight on the dec of about 3.5kg.  Out of the box, it does need a bit of a tune, things like the backlash adjuster, maybe a clean and re-grease of the hub and also some noodling with the wedge; but all in, it's not a bad little mount to work with. 

However, the big elephant in the room is dec movement, or the lack of it... If you're wanting full guiding, or needing dithering look at the AZ-GTI instead.

Aside from talking to environmental health or breaking out the .22", something like a fishing bivvy or a day shelter may be an option to look at.

Just now, andy fearn said:

very nice image, i would be more than happy with that.   Happy new year.

Perhaps I need a resolution then "Stop being so exigent!" 

Happy New Year, Andy!

New Year, and in to the lions den...

Last night the choice was TV or out the back with the Star Adventurer (and if you've ever seen Spanish NYE or Christmas TV, there was no choice!) 

I'm not 100% happy with this image, never am and that's probably why I've not posted any before, the framing is a little off, them diffraction spikes (though a mask set is on the to-do list) and could have done with some 15 second exposures on it to stop the centre from being as bright.  Anything else that sticks out to more seasoned eyes, then hit me with them.

Technical wise it's 30 minutes of 30 second exposures, 60 minutes of 60 second exposures, 2.5 hours of 120 second exposures at ISO 800, Nikon D810, a ratty old Sigma 300mm F:/4 on a Star Adventurer, stacked in SiriL and tidied up in Photoshop.

Looking at the hardware side of it, it may be quicker and easier to modify the firmware for the focuser itself to recognise as and accept commands as if it was a MoonLite clone than looking around to try and translate the drivers from one platform to another.