pete_l

Bear in mind the other issue: that MAX232 (and the later MAX3232) chips invert the sense of the data. The FTDI USB-Serial converters will not "understand" inverted data. Hence the need for a different setup between talking to a mount through the handset or directly with an EQ Direct cable.

This is something I have been fiddlin' wih recently on a different mount: an Ioptron SmartEQ Pro. First, my experience with an HEQ5 / EQDirect taught me that the correct level (voltage) is necessary when communicating with the mount. If this is wrong, the mount won't "hear" the data being sent to it. Since EQ Direct works with levels of 0V and +5V that tells me that the handset is also using those voltages. So the handset and the EQ Direct will both work. However the signals that I have to use to plug my serial port into the (Ioptron 8408) handset are different. Instead of being "TTL" level signals: 0 volts and +5, the handset requires something different: RS232 levels. Many people use the term RS232 as meaning serial communications. But there is a subtle difference. First, the voltages are different. My handset requires negative 5 volts and plus 5 volt signals. Also, the sense of the signals is inverted to what the EQ Direct cable sends. 0's are 1's and vice-versa. The simple answer for me, has been to connect the output from my USB to serial converter - an FTDI232 (actually a knock-off, but that's another story) to a MAX232 interface chip that is especially designed to convert the TTL signals into proper RS232. I would not try plugging my MAX232 chip directly into a mount in place of an EQ Direct cable. The voltage difference could cause damage, but the signals are definitely inverted and therefore won't work.

duplicate

Both can produce excellent results. Leaving aside narrow band imaging, I would defy anyone to look at the final result from either and be able to say, without any further information, whether it came from a OSC or mono camera.

You definitely need a heatsink on the Pi4 processor. Without it the CPU will heat up and without any warning slow down its clock speed quite a lot. There are two types of cases that I have experience of. One is plastic and contains a fan that disperses the heat from heatsinks that you stick on various chips. The other is a metal enclosure that has the heatsink integrated into its body and that passively transfers heat to the outside. The plastic one has the advantage of not impeding the on-board WiFi / Bluetooth signal. However, all the ones I have used contain a cheap and nasty little fan that quickly becomes a source of a loud droning noise as the bearings fill up with dust and eventually just stop working. The metal ones have the advantage of no moving parts, so are silent. However, they affect the WiFi very badly indeed. Possibly not an issue of you only want to communicate over 1 or 2 metres at low speed (maybe better at 5 GHz?), but further than that and the best I can say is that the link becomes "iffy". What I would like is a plastic case with a large, metal heatsink built out to the surface. Failing that a fan-shaped heatsink that I could 3d-print a case around.

Even better, you could not buy a 10 Micron pier and have £1000 to spend on other things 😈

You could take a leaf out of the chinese electronics manufacturing handbook and cover all the wires in hot-melt glue!

Yes, provided a replacement connector was available - or the old one salvageable. It's generally considered bad practice to solder wires directly onto a PCB - no strain relief, for one thing. One probably daft suggestion; have the wires been soldered to the correct positions? In the first photo we can only see some of them Maybe a cracked track from when the OP tried to remove the plug? Or the underlying reason why PBS wanted to remove it in the first place.

Yes, it does. The longer the length of the counterweight bar, the more "whippy" it is. And that leads to greater vibration whenever a tracking correction is made. A shorter bar, even if it the same diameter, will be much stiffer. The stiffness decreases much faster with increasing length than the need for less weigh improves the situation. So it is advantageous to have a short bar with more counterweights than a long bar with fewer.

There are loads of similar products. Widely available in hardware shops or online.

Have you tested the cable for continuity with your multimeter? Failing that, try a different power cable

I reckon that nobody sells kit that works well. Not unless they absolutely have to. What does get sold on is stuff that folk are dissatisfied with, things they want to get rid of to buy something better, or pieces that have a problem (which hopefully the seller is honest enough to declare).

Although it is quite easy to bin the smaller pixels of a modern CMOS sensor to get back to the same sort of resolutions as before.

You got me rather worried about that. So I took my prototype "flip-side" rain detector for a test in the Andalucian sun. I'm glad to say that although it was printed with PLA, it survived the 48° afternoon peak. 🥳

The Airy disk is an artifact of diffraction of the incoming photons through an aperture. That has nothing to do with the size of the sensor as the pixels do not cause diffraction. The only time the sensor size becomes an issue is not to do with sampling theory, it is only a factor when compared to the size of the point of focused light (or as we amateur astronomers call it: the "star" ). What optical designers call the spot size. However, even a 1/8 wave optic blurs a star to 4-5 Airy disks [ reference: Schimdt Cassegrain telescope ] - and that is the on-axis spot size! It also takes no account of atmospheric "seeing" that spreads the light out, further. So neither sampling nor diffraction makes any significant difference when applied to real world operations. That is why we still get pretty much rounded-looking stars even with quite large pixels. It is also why star images are spread across many adjacent pixels.

But the camera does not process each photo individually. The other problem is that Nyquist assumes the signal is correlated. Photons are not. At best they are a series of impulses with random arrival times and amplitudes.

Doesn't the Nyquist theorem only apply to continuous signals? It seems to me that imaging produces a discrete result: all the photons gathered in a given time.

You would have to be incredibly unlucky to cause damage removing that - unless the hammer slipped 😆 I've just used a photographers blower-brush to knock things like that off a mirror in-situ. Either that or a makeup brush or whatever other soft material you have to hand.

Make sure it can't blow away 😁 I use a barbecue cover and that seems to be quite successful. If people have doubt about the efficacy of a cheap cover, why not double wrap your gear? Cover it with two!

Books and articles are full of things that just copy ideas from other books and articles. History books in particular are infamous for perpetuating stuff that has no factual basis. So it would not surprise me if someone simply thought this was true, ages ago, and since then every other writer has just copied it. However, it seems to me that this cannot be true. Since it is always before midnight in as many places as it is after midnight at the same time!

A Raspberry Pi Zero-w with a 12MPix HQ camera using a F1.7 lens in a CS-M12 adapter will give you images like this for a 10 second exposure binned 2x2 For reference, the stars just below Sagitarius' "teapot" are 13° above the horizon according to Stellarium

Got one from this morning (Sun. 08 August) and about 2:30 Spain time. It came from roughly the right direction

At the risk of reopening a dead thread, I have started experimenting with an HQ camera. I use an M12 (12mm diameter screw) lens with a 1.7mm focal length and a M12 to CS adapter. Here's an early example of my playing around from last night at around 1 a.m. (Europe time) so the constellations are in roughly the same alignment as the July images. It is very pleasing to get an all-round horizon with this set up. I'm using the actual same lens (1.7mm f/l) as was in the RPi version 2 camera. The larger sensor on the HQ camera expands the field of view. However, I have yet to find a decent software configuration with my Python script as the HQ camera looks to be less sensitive (i.e. doesn't pick up the faint stars from the V2 camera image). Although this is still a work in progress so I'm not complaining.

I wouldn't put too much stock in that. Sky darkness varies greatly, throughout the night and with the seasons. So if that Bortle 2 was measured estimated in mid-winter, without any tourist facilities open (and their lights on) you may well find that in peak season it is an entirely different situation. I'd say just treat it as a holiday. Relax 😎

Excellent news. Please send your granny round.