gilesco

Md5 was used for a while until some people worked out how to change a file without changing the md5sum, so they brought in the sha512sum, which is supposed to be more secure. Obviously it you obtain the checksum from the same place you obtained the file then checking it is somewhat moot, as whoever hacked the executable could have changed the checksum, but if you obtained it by other means then (e.g. bittorrent) then it is a valid check to make.

On the Mac, your options are to: (1) Compile from source, to run the latest, yet unstable (and particularly unstable at the moment while changes go through to 3.5.0 release) (2) Download latest Stable from https://edu.kde.org/kstars/ INDI is a distinct project although related and closely linked, you might get INDI functionality from the Kstars Mac download, or it might be a different process. It had been hoped to have kstars 3.5.0 ready for some time this month, I feel this is being pushed back though, the latest features coming up are great, but not yet stable to the satisfaction of the developers.

We have a guy in the UK who does "hyper-tuning", effectively a service on the motors, that is probably our go to place for issues like this. From what I hear he can replace worn parts etc...

Mine generally sounds smooth, but every so often it gives a little moan, only for a second or so, and only while slewing to a position, I still get 0.7 / 0.8 RMS on a good night. Shipping to California would be expensive from the UK.

Yes, I was just replying to your "am I back to square one" question and the query about multiple-part orders.

Logistics, and and the problem of fulfilling everyone's order in the shortest possible time, is actually a really complicated task. If you have a large order of many parts with different wait times, then it depends. If the distributor for a particular part is unreliable in their lead times then it will throw the retailers out on their planning to fulfil orders. If you have a single part with a very long lead time, with other parts with shorter lead times, then yes - it is acceptable for the short lead-time part to go out and come back into stock in the early stages of the initial order. I am certain that, in the last few weeks before a long lead time part is due to be allocated to your order, that the other shorter lead-time items will get allocated to your bin. If you have particular concerns then the best thing to do is to communicate with your supplier, they will often be happy to part-ship existing items in stock (although if you don't have a use for them before your other items arrive, then not necessarily worth the bother). FLO recently part shipped some items on my order, and I was grateful for getting the Sesto Senso 2 early, as it has allowed me to check the INDI driver, and work out how to modify the code so that it uses a particular hold current which is going to be needed when I get the OTA and Focuser, which is known to slip without a hold current set. So I'd just say, talk with the retailers about your particular order, if they know your requirements for each part, then they will try their best to accommodate you.

This is exactly what crossed my mind when I saw this thread, before getting into imaging I was contemplating eyepiece sets all over, then saw some advice - just get a quality click-step zoom, you can go through most of the sizes very easily, no fumbling around in the dark. I eventually opted for the Baader Hyperion Zoom, and the Baader 2.25x Barlow to fit it, so it takes me through from 3.5mm - 10mm and 8mm - 24mm, in most cases without really needing to mess about in the dark. Since I've got into imaging I've not really used it that much, but it isn't something I plan on letting go of. The Pentax zoom is the other one I hear about.

The one thing that's keeping my frustration at bay... is the weather... that is, if anything arrived I could not use it, just some basic setup preparation and then look to the rain to stop.

Hello and welcome, the good advice already given is start low, see what you can do and what you can't and then come back to the forums on what you can't do. No one piece of equipment will cover all use cases. Believe it or not, I bought a mount before I chose a telescope.

I know, but I remember at least one time in the last few months, where the weather was not forecast to be good until the last minute, and then I found myself complaing that I was setting up in the dark... I guess I just find something to grump about - whatever happens!!

Yes, here to, although the weather forecast says I won't be missing out, unless I move to the desert.

This is due to a lot of forecast data being in 3 or 6 hour block of granularity until we get closer to the time, and the MET office runs another model simulation, which is more granular for the first few hours, and then beyond that moves to 3 hour or 6 hour windows. Couple this with the fact that CO will only update for your location at best once an hour, you shouldn't be using it as a real-time weather monitor.

Yes, when I was visually I was doing the 2 star + 4 calib all the way, by the 3rd or 4th Calibration it was bang on target and needed no adjustment. I just wondered as the default calibration star selections seem to be all over the sky, so just wondered if it was doing anything more than just fine tuning the perceived position.

So on my CGX, I have, and certainly if I'm doing visual observing without a PC, usually done a 2-star alignment, and then it asks me for up to 4 calibration stars. Are those calibration stars just fine tuning the alignment, or do they serve as some sort of error correction for the motors (like a rough PEC type thing)?

So from what Olly has said, it sounds as if I don't actually have to do a star alignment at all? Once Polar Aligned I can just slew somewhere and Plate Solve my position?

Yes - unless you have a pressing issue such as power consumption, there is no reason to downgrade a x64_86 system to raspberry pi arm32 / arm64. I am coming from the other direction, eventually looking at upgrading to something a bit more powerful, but I think ARM will reach parity with Intel architectures in the near future.

I think this is a case of experimentation with those kind of settings, MTU and MSS, maximum path packet size. I'm 25 years a network engineer, now architect and this smells of that, especially when you elaborated on the path to where it hangs...

Sounds like a great project, with a possible, modest income too...

@JamesF thanks for your first hand experiences, if by an amazing stroke of luck, I might be able to recount my experience of both chance locations over the same weekend, and new moon cycle. Raining here now

Yes (concur with trying both sites out), I've been reminded that I booked a long weekend of annual leave on that weekend, so I have a 4 night window of possibilities for the weather, but will try the best and hopefully that falls on Friday / Saturday. One of my Powertank's arrived today, so once I've done some testing with life time and power draw I am ready equipment-wise, but was hoping for the new telescope to arrive before hand. Still something I will do either way, old equipment with a fiddly focus procedure or hopefully something better... I will have the same astrophotography target (IC1805) for both Dartmoor and Exmoor, so will be able to hopefully directly compare and produce a comparison review of both (of course, assuming the weather plays into our hands!!! - which given the current forecast of continual clouds, is no guarantee). Once I get paid this month I will be getting a thermos flask!!

Yes, it will be slower, almost painfully slow, but if it is just to kick off the ekos scheduler while you are away from your observatory on your travels then it might be just about bearable. I have actually found xrdp to be much quicker and responsive than vnc, but it is another thing.

Strange, you can ssh so that does indicate connectivity. I have a rather complicated home network, which allows me to access Astroberry from a remote subnet without any issues, so I don't think it is Nginx. On your OpenVPN server can you try, in its config: fragment 1200 mssfix 1200 And on the clients, put in: mssfix 1200 Reasoning is ssh uses small push packets, VNC uses large bitmap packets, which might be being dropped by exceeding the MTU of your tunnel. You will need to restart the OpenVPN server after this change.

I do notice you have both wlan0 and eth0 connected to what appears the same network, I would disable one of these interfaces - either use the ethernet (preferred), or use the wifi, but not both. The metric should take care of this, and OpenVPN is preferred, Ethernet is second then Wifi, but I would start something simple before adding complexity.

So, let's get this right. Your OpenVPN server sits on a external IP - this is on your home network or remotely somewhere? Your OpenVPN client is the Astroberry - you are connecting this to the OpenVPN server? Is the client that you can SSH into the Astroberry on your home network, or is it also remote and also running an OpenVPN client to the same OpenVPN server?

Try with putty, but do this: Add source port 80 Destination localhost:8080 and click Add Then SSH into the astroberry, then just connect on your system to http://localhost:8080, and or try http://localhost:8080/panels.html It might get round any issues, and also possibly obliviate the need to run OpenVPN at all. By the way, your routing table looks fine, and I can't find anything that might cause a problem, the output of: sudo iptables -L -n On the Astroberry might give further details (e.g. If OpenVPN initiates a firewall ruleset on connecting).