randomic

The key part which is being missed is that it's the non-uniformity in the field which is important. If we imagine the Earth as a rigid sphere then: the water closest to the Moon "feels" a stronger acceleration towards the Moon than the Earth does the Earth "feels" a stronger acceleration towards the Moon than the water furthest from the Moon does the net result is that you get a tidal bulge at each side. It's got nothing to do with the springiness of water or pressure or anything like that. You see tidal forces in action in merging galaxies, where stars are (effectively) only interacting gravitationally. You still see two bulges. However, there is a whole other interesting topic which is due to the "springiness" of the system: tidal locking. It's no coincidence that one side of the moon always faces us. If you're in a uniform gravitational field there is no tidal bulging in the direction of the field. This graphic from the wikipedia may help visualise: Graphic of tidal forces. The top picture shows the gravity field of a body to the right, the lower shows their residual once the field at the centre of the sphere is subtracted; this is the tidal force.

astroberry@astroberry:~ $ lsusb Bus 002 Device 002: ID 03c3:462b Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub astroberry@astroberry:~ $ lsusb -vs 2:2 Bus 002 Device 002: ID 03c3:462b Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x03c3 idProduct 0x462b bcdDevice 0.00 iManufacturer 1 ZWO iProduct 2 ASI462MC iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x001f bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 512mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 0x0016 bNumDeviceCaps 2 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType 16 bDevCapabilityType 2 bmAttributes 0x00000002 HIRD Link Power Management (LPM) Supported SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x00 wSpeedsSupported 0x000e Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 3 Lowest fully-functional device speed is SuperSpeed (5Gbps) bU1DevExitLat 10 micro seconds bU2DevExitLat 2047 micro seconds can't get debug descriptor: Resource temporarily unavailable Device Status: 0x000c (Bus Powered) U1 Enabled U2 Enabled If I'm interpreting this correctly, it seems to not report a device name

It's not quite happy with sdk version v1.15.0915 for whatever reason. Here's the log output: astroberry@astroberry:~ $ LD_LIBRARY_PATH=/usr/lib/arm-linux-gnueabihf oacapture libEGL warning: DRI2: failed to authenticate qt5ct: using qt5ct plugin qt5ct: D-Bus global menu: no Unrecognised camera '' open of camera 0 failed Happy to do any further testing if it's useful to you.

Got a Raspberry Pi 4 and the lockup issue seems to not happen anymore. There is some weirdness about data acquisition rates though: if I set a target fps of 20 I get roughly 20, any faster and it starts wildly oscillating, averaging between 10 and 2. (In kstars) Additionally, dmesg gets spammed with messages about the usb device getting "reset". From what I understand, this is normal with ZWO cameras when changing configuration but not during capture. Hoping this is just teething troubles with the drivers/sdk, it is certainly useable now. I'll keep updating this thread with any new info I find but for now the main issue is resolved by not using a Raspberry Pi 3B

Amazing! Thanks so much! Is it built into the binary or is there a directory I can drop the new so to test it out locally?

I just looked at the default nginx config for astroberry and it listens on all port 80, so it shouldn't matter at all from where you're connecting. There is some other problem. Are you able to load the astroberry webpage? Is it just the desktop (VNC) bit which isn't working?

I don't know what causes this but I have seen it in other photos. For example: Although in Olly's picture it appears to have some radial symmetry around the field edges. I've also seen a similar thing appearing as well as the diffraction spikes from Newtonian vanes but I can't find an example right now. What do defocussed stars look like? Maybe there's a clue in there.

You read my mind! I was trying to decide on the RAM. I think I might go for the 4GB version anyway just for futureproofing. Very excited for 10s platesolves, it can easily take 2 minutes+ for me at the moment.

Aand the lock up happened almost straight away. So I think this rules out power as the issue.

I was about to reply saying that, unfortunately, I don't have a way to rule out power to hand. But then an epiphany. My PC monitor has a powered USB hub built in. It only has USB 3 slots so I can't rule out some weird USB 2 problem but I'll give it a shot.

I tried with the Pi1 and although the poor hardware couldn't really keep up with the demands, it didn't lock up in the same way the 3B does. I guess this must be something to do with the hardware. I'll update the original post to specifically reference the Pi 3B Looks like I'm ordering a Pi4 sooner than anticipated!

Yeah I definitely haven't ruled it out. I don't have a powered hub at the moment but I'll be getting one. I'm using the stock 2.5A power supply which came with the Pi, should be more than sufficient. It seems to record from a Logitech C920 with no issues (other than high cpu usage). I was looking at getting a Pi 4 anyway for better performance but I'd rather not do so if it won't work with the camera. I also have an original Pi 1, although it'll probably run really slowly I might pop the SD card in that just to see if I get the same issue on different hardware.

UPDATE: This problem seems to specifically occur with my Raspberry Pi 3B. It did not occur with a Raspberry Pi 1. UPDATE 2: Problem does not occur with Raspberry Pi 4. I do not have a Pi 3B+ but if someone else does and reports their findings I'll edit this post to include them. Just a warning to anyone looking at this camera. Particularly if you're using a Raspberry Pi/Astroberry for your setup: It seems to be unsupported in most software at the moment, for example: FireCapture, oacapture (an update to support the camera in oacapture is on the way! Thanks to @JamesF) Additionally when I tried streaming some video from it in kstars once I hit about 10fps it caused kernel problems in the raspberry pi. This could be a hardware problem with my specific raspberry pi or it could be driver related. The result is the raspberry pi completely locks up, ssh stops responding, clock stops ticking, any executing commands start segfaulting. The only way out is to pull the power. It would be nice to know if anyone's got this camera working with a raspberry pi in a stable way. Additionally the manual for this camera says the max power consumption is 13.9W, which seems ridiculously high for an uncooled camera. I'm pretty sceptical of this given that it's supposed to be powered through USB3 which is specced at ~900mA @ 5V. If it really was drawing nearly 3A I can't see it ever working from a USB port, nevermind a raspberry pi's. I've attached some kernel logs in case anyone's interested but this is more of a PSA than a cry for help 😂 trace.log

Checklist is a great idea. Before I made one (albeit a mental one), I had a couple of sessions where I made some mistakes which cost a lot of valuable observing time. For what it's worth here's mine: Take out tripod, extend legs so it's roughly waist high, get it more or less level (not essential but helps with polar-alignment). Take out mount and attach it to tripod. Take out the tripod spreader and put that in place. Carefully, lift each tripod leg off the ground for a moment to make sure it's been spread and won't move later. Polar align, using an app to tell me where Polaris should be in the polar scope. Take out counterweights (for me 2) and put them on the bar roughly where I know balance will be. Make sure clutches are engaged. Take out scope and attach it to mount. Take out imaging train/visual back and attach to scope. Attach any other accessories (e.g. DSLR piggyback, finder scope). Balance in Dec Balance in RA Get my power supply to the mount and plug it in. Attach handset or wire up my raspberry pi depending on what I'm using. Check polar alignment now the mount is loaded (not necessary unless you're doing long exposures). This can be done with the polar scope or in some software. I have a dew heater coming so that'll probably fit in somewhere, probably around 11/12. The most important thing for me was getting everything balanced before starting to plug things in. Also if you adjust the payload, make sure to rebalance.

Just got my 462MC (just in time for good weather to grab some shots of Mars!). According to the diagrams it's 12.5 - 7.5 = 5mm from the chip to the flat surface above the chip. So once I have everything put together, I've measured with calipers from the part of the T-adapter which stops against the end of the thread of the scope all the way down to that flat surface. To hit 133.35mm backspace, I should measure 128.35mm (if I add a 2mm thick filter then I can add about 0.67mm so can round to ~129mm). If there's a gap in the clouds tonight I'll measure the pixel scale. If I'm still far off the numbers given in the whitepaper then I might shoot Celestron an email to see if they can explain why. Perhaps the design has changed slightly since the whitepaper was written.

I had a similar experience watching Mars drift behind my neighbour's house. Rather than cutting off part of the disk as you might intuitively expect, the disk instead gradually got fainter and blurrier until it vanished completely.

I've found pointing it down onto a piece of cardboard does the trick as well. Best thing to do is just prevent it in the first place with dew shield/dew heater but it's nothing to freak out about, the important thing is your view/image quality.

If there's evidence that it's been used/damaged then fair enough. If it's in original packaging and as new then what's the difference?

When you're spending the amount of money we do, without even getting to see the equipment in person, surely you should be able to change your mind. In theory, the store loses exactly nothing, especially if the customer has to pay all the delivery costs associated.

If you have to ask whether or not the mirror needs work, it doesn't. Remember that every part of the mirror focuses light from one point to another, it takes a significant amount of dirt/damage to manifest in reduced performance. You can do a lot more harm than good to a mirror by trying to clean it. I think I read somewhere that you need something like an inch squared of black paint on an 8" mirror before you can start to notice degradation. 8" circle has an area of ~200 square inches so even an entire square inch is only 0.5% of the surface.

Yeah my experience with Rother Valley has been just "okay". Responses to emails were very abrupt and often didn't actually answer my question. If you know what you want and they have it in stock they'll get it to you in a timely fashion but they're miles away from having the great customer service that you get with 365 astronomy and FLO.

Also worth saying that you should play around in this fov tool with various sensors/barlows/reducers and various targets to see what combination gives you the range of targets you're looking for.

I'm no expert regarding EEVA but I will do my best to give you as much information as I can: 1 & 2) You'd probably want a colour cam so that you can live-stack colour images. However, getting a camera with a big sensor gets expensive real fast. Plus you want to make sure that your pixel size gives you a good image scale (0.2-0.5 "/pixel for planetary, 2-2.5 "/pixel for DSO, roughly speaking). This calculator can help here. So you kind of have two options: a) Big sensor with relatively big pixels and your scope at native focal length for DSOs, and then for planetary you slap a barlow on. b) Smaller sensor with small pixels and use a reducer for DSOs and native focal length for planetary. This option could be cheaper at the expense of field size and flatness in DSOs. Great planetary cams are ASI 224MC, 290MC and 462MC 3) SharpCap is pretty well renowned, Oacapture has live stacking capabilities too and so does ZWO's ASIStudio 4) You need something with enough power to do encoding for the livestream. You're not going to be streaming rapidly changing frames so you can get away with a much lower bitrate than, say, game streaming. It's really hard to say up front. You might just have to get set up and adjust the bitrate until you're at a happy balance between cpu usage and stream quality. 5) Depending on how faint the target is, yes. 6) As with 4, you shouldn't need a huge bitrate for this so I would say bandwidth isn't too big an issue. 7) I think it would be awesome and I've thought about doing something similar. I might give it a go from home just as a proof of concept.

That would be awesome. You could pretty easily use something like OBS

You can purchase the OTA without mount (Celestron C8 XLT) but I honestly think it's a great deal. I've used these kinds of mounts before and have never had an issue. Plus, like someone else said, you can always buy an equatorial mount later if you decide you want to do some imaging. It's a nice upgrade path which I nearly went down myself (in the end I jumped straight to an imaging setup at great expense)