franco I goto the Moon it misses by a country mile

If this refers to the ASIAIR, do not go directly to the Moon, because a plate solve will almost always fail (due to insufficient dynamic range).

Instead, as the target, input the RA of the Moon, but with a declination that is a couple of degrees away from the declination of the Moon (this will place the mount on the same pier side as the pier side for the Moon).

Do a plate solve there, and then a Sync And GoTo to this off-Moon target. Repeat if neccessary to get the precision that you need.

After you have sync'ed to that off-Moon target, select the Moon as the target and do a single GoTo.

This should place the Moon smack in the center of the frame, since you are only moving a couple of degrees in declination. Even a cheap mount should get you very close. With most mounts, the Moon will be centered so well that you don't need to make any furthur adjustments, as long as the previous Sync and Goto operations get you close to that off-Moon target.

Chen

franco A refinement would be to have 2 main camera profiles where you set the FL, then there's no conflict or confusion with a guide camera.

Actually, the GUI would be much more general if it allows multiple (more than 2 even) cameras, with one that can be designated as the guide camera. The cameras can then work independently, but cooperate in dithering, etc.

If all cameras have plate solving capability, you won't even need to switch anything. Just send the plate solving command to the camera that is designated as the guide camera in your case. The plate scale is based on the focal length of the OTA that belongs to the camera you asked to plate solve with.

If you have enough CPU power, you can be autofocusing all cameras concurrently. Each camera has an EAF assigned to it, instead of like in ASIAIR where the EAF is a global property, instead of a property of an OTA/camera/EAF set, where you have to go select the EAF (I have an EAF on my guide scope too, and focusing with the ASIAIR is a PITA).

Same with EFW -- it is a property of the OTA/camera set, and not of the global property, as in the ASIAIR.

Ditto ST-4 guiding -- it can be sent through any ST-4 device (or camera that supports ST-4). There is no reason that a camara that is used for guiding is the only one than can be used as an ST-4 interface.

I.e., visualize the GUI as a tops-down approach, instead of a bottoms up approach.

Chen

franco The star size was greater than 10 which seems to be the upper limit.

Have you tried binning the camera? (Or it is already binned?)

The problem with ASIAIR's autofocus is that it does not take into account of the image scale and how large a focused star would look on the sensor. It also does not take into account telescopes that have secondary obstructions, where the very defocused star looks like a donut instead of an Airy disk.

I didn't want to go outside in the cold so I just used the diffraction spikes from the spider.

Yep, that works just fine. Just takes getting used to which direction to move the drawtube since all spikes are 90º from one another. But you are right that defocus will just create an offset (same as with a Bahtinov mask; angles don't change, but one set of diffraction spikes is offset from the other two sets).

Just like you, I use a mask in summer and resort to a V-curve program (not the ASIAIR U-curve) in winter :-).

BTW, for planetary focal lengths, I have always wondered about mounting a Barlow in some kind of filter wheel. Then calibrate the optics to find the change in drawtube between Barlow and no Barlow. You can then just focus using no Barlow, and apply the offset to the drawtube when the Barlow is rotated in place. If most optometrists still change diopter settings manually, then so can we, right? :-) Can also dial in a shorter focal length for plate solving :-).

Chen

enaiman You have a lot of space under your scope which you could use to hold your AA.

Bad idea to mount something with an antenna on a platform that moves during the night. Antennas such as the one on all models of the ASIAIR, are not omidirectional, much less isotropic. You can easily loose WiFi connectivity during a Meridian flip.

@franco has the right idea. I do the same thing even when I use direct Ethernet connection -- my ASIAIR sits in a waterproof ABS box at the base of with tri-pier (and my mount) which sits outdoors 24x7x365 (under waterproof bags when not in use).

Even with @franco's setup, the WiFi antenna directivity can still be affected by the massive metal OTA that is moving through the night. If I were using WiFi, I would place the ASIAIR closer to the house, and separate from the tripod by a half a meter or so (one wavelength at 2.4 GHz is about 2.5 cm, so half a meter should be sufficient). At least in @franco's case, notice that his ASIAIR USB connections can be nicely separated away from the WiFI antenna (likely 50% of the WiFi woes that you read about in the ASIAIR Facebook page).

If you have a Mac, you can actually use my antenna modeling program to test some of the placements out.

http://www.w7ay.net/site/Manuals/cocoaNEC/index.html

By the way, I suspect that most of the problems with the flakey ASIAIR WiFi connections that you read about on Facebook are caused by poor SNR at the receiving end of the ASIAIR, and not the transmit signal strength from the ASIAIR. The receiving end has to also contend with interference from neighbors WiFi and microwave ovens). (Remember the Reciprocity Theorem that we studied in antenna theory classes? The directivity of an antenna when used as a receiver is the same as the directivity of the same antenna when used to transmit. But the SNR is not the same!)

Chen

w7ay Why would be a bad idea to lose WiFi during a meridian flip? The tablet/laptop/phone has absolutely nothing to do with the MF and the AA is wired to the mount.
I am having all my AA units on OTA, all using station mode and sometimes the signal strength will drop depending on the antenna position; it will drop from the usual 7MB/s transfer speed to 1-2MB/s but nothing more than that. It takes longer to download the images but that works good even with my 6200MM camera.
If antenna position is so important, we can always use a separate antenna and place it wherever we need so the OTA won't get in the way - like this one. OnmiDirectional antenna
Personally I see only benefits from having the AA at OTA level.
I always respect your opinions Chen but on this one we have to disagree.

enaiman this one we have to disagree.

Your choice. I can just explain the technical details, I cannot make you accept them. As you youself have just stated, the SNR change is already causing you to lose transmission rate through the night.

Good luck. Hope your neighbor does not install a big honking mesh network.

Chen

franco the Pro to a Slate that is tied to a tripod leg

Hah! I did see something else with a WiFi antenna :-).

However, through the night, the antenna's pattern can change as the big honking metal OTA moves around near it. Check up on "multipath distortion."

the totally useless Pro WiFi.

I agree completely. When others design metal enclosure around a Raspberry Pi, they often leave some slots for signals to go through. The slots need to be at least 1/2 wavelength wide for any chance of the signal passing through -- when we design dish antennas with metal mesh instead of a solid parabolic surface, the mesh just needs to be 1/4 wavelength or smaller to perform almost as well as a solid surface.

The first day I received the second generation ASIAIR, I went and measured the hole sizes of its metal box, and decided then and there that I could not use WiFi reliably, and bought a travel router :-).

FWIW, I do use a first generation ASIAIR on WiFi for an All Sky camera. Works fine on Station Mode, especially after the eero network Band Steered it to use the 5 GHz band. A caveat being I do not use any Raspberry Pi enclosure at all, but with the ASIAIR board naked inside the large ABS enclosure of the All-Sky camera.

Both of my second generation ASIAIRs (one in the house for experiments, and one outdoors) are tied by Ethernet to one of the mesh routers and get about 80 to 90 MBytes/sec from the Samba server. My Raspberry Pi 4 running INDIGO Sky works so well with WiFi that I don't even bother using wired Ethernet; but so far, just on the desk while I write and test my application.

Chen

franco I've tried it before but wasn't impressed hence why I bought a 2 micron camera.

Yep, I bought that camera just because of the pixel size. I do have a couple of the TeleVue PowerMates (from 1.5x to 5x) but still prefer smaller pixels than using even the telecentric PowerMates (you can check out Baader's white paper on telecentric barlows vs "normal" Barlows).

From Baader's diagrams, you can see why a simple Barlow's magnification depends on the "backfocus" distance. Some of my PowerMates have a mgnification change, and some have almost constant magnification, independent of the "backfocus."

Unfortunately, the ASI678 camera is useless with ASIAIR since I could not get 2 FPS guiding through it. The ASI678 works with other systems though -- only the ASIAIR could not keep up.

But it is a good camera to have around for planetary work.

Chen

Are the ROI resolutions in video mode predefined in hardware or can they be set arbitrarily in the software?
If memory serves, with ZWO's camera, you just have to make sure that the frame dimension is some integer multiple (like 8 bytes or 16 bytes) of a power of two.

Other than that restriction, you should be able to get any ROI (as long as you don't use the artificially crippled ASIAIR). You can even use a thin ROI that is 1024 x 16, if memory serves (useful if you just need one strip of data).

Chen