Padraic M

Hi Frank @Atreta, yes I've tried that. Once you select the correct camera, there's no issue. It will connect and work correctly. However, there's no indication which camera is #1 and which is #2, and the numbers are not consistently assigned. You can tell APT to connect to #1 or #2 automatically, but there's no indication which physical camera is connected except for the sensor dimensions. If I had two identical cameras, there would be no way to know other than to shine a lamp down the OTA and see if the camera sees it!

Huge Nevada 13.8V power supply on the way! 10A through the cigarette socket, can supply up to 20A in total. That should be enough!

@bottletopburly and @Merlin66 thanks guys, yeah I thought so, time to beef up. I suspect my ebay power brick isn't quite as advertised. Difficult to source 15V 10A converters.

I had a very frustrating time last night trying to set up for imaging. Nothing worked for me! Hard to know where to even start to resolve the various issues. Here's a summary. I will open separate threads on each of these issues as and when I get the time. The purpose of setting up last night, even though the forecast was only so-so, was to test out guiding on my HEQ5 Pro, having just astrobaby-tuned it, and before I install the Rowan belt mod. Problems: 1. The weather. Nothing any of us can do about this I suppose, but the actual weather was a harsh interpretation of the CO forecast to say the least. I found myself at 2am trying to decide which was better - rain damage or mechanical trauma - as the night was getting very blustery with a few drops of rain. Eventually got sense and decided to risk neither, and had a realtively early night with no results to show. @Gina is currently working on a read-only weather station. I've no doubt that when she has that done she will do a version with full update functionality so we can actually change the weather conditions at will. 2. The HEQ5 Pro mount, post astrobaby strip-down and tune-up. Certainly no quieter than it was before; a noticeable ~2mm of play in the RA axis once loaded with scopes and cameras. All obviously not well from the start. Sharpcap polar alignment worked fine, with Excellent PA result. However, Phd2 considered PA to be 13.2 arcmins. Seriously? But then, phd2 errored 'Unable to move mount in RA....' so guiding was not possible. Worth adding that manually the RA axis moves very smoothly with the clutches off, or with the Synscan handset. I can also control it fine using the scope controls in APT, so mechanically it's working, and the connection to mount is working. Could the excess play in RA be preventing guiding? Testing today in daylight suggests that the worm gear alignment was at fault; the RA worm shaft float adjuster was loose. 3. Had some head-scratching minutes trying to sort out my camera until I noticed that APT had automatically connected to the guidecam (290mc) instead of the imaging camera (1600mm). Used the name of the imaging camera alright, but the sensor dimensions were obviously from the guidecam. Resolved this by reconnecting until the imaging camera was selected. No problem cooling to -20C. It looks like APT's CCD 1 and 2 slots are being allocated 'randomly' to the two cameras; so while I can set APT to always connect to camera 1 or 2, is there a way to consistently allocate the camera numbers to specific cameras? Otherwise, it's hit and miss every time. 4. Focus. I installed the Celestron electronic focus motor on the C8 SCT recently. Didn't realise at the time that you lose all manual focus capability with this focuser unless you have a Celestron mount handset. I couldn't find any out-of-focus star to start the autofocus routine, no matter how hard I searched. Pure black image with each capture, with the odd completely white image. Spent ages focusing with small steps to try to find a donut somewhere, but failed except for one short period. I now think that the camera connection was not working for some reason, and I was not getting an image at all. No errors reported from any part of the imaging chain. I didn't manage to get focused before the clouds rolled back in, so had to finish up for the night. I wish I'd gone for a PLL ESATTO, although they're very pricey, but at least I would have coarse focus under manual control. Has anyone made a focus hand controller for the Celestron SCT focus motor? I can't reproduce this today. I'm working on the assumption that there is USB contention somewhere along the line; my hub is USB2.0, but the ASI1600mm imaging camera is USB3.0. Always worked before, but with imaging cam, guide cam, focuser, mount and efw all on the hub, maybe there's too much traffic. 5. Mount LED flashes when the mount is slewing. I noticed this previously but hadn't paid much attention to it, although it didn't seem right. I did some experimentation with it today and unfortunately I think I have a power issue. I have a 10A 12V power brick with a cigarette socket output. I also have a 4-way cigarette splitter, so that I can power the mount, camera cooler and dew heater. 10A should be plenty of juice for that combination. If I connect the mount only, directly to the power brick output, the input voltage as measured by the handset is 11.4V. When slewing both motors, it drops to around 11.2V, and the LED stays on constantly. If I connect the mount through the 4-way adapter into the power brick, the voltage drops below 11V, and the LED sometimes drops out. Lastly, if I also connect the dew heater to the 4-way, the voltage drops down to 10.5V and the LED flashes like a Christmas tree. This isn't a mobile setup, so the power brick is plugged directly into the mains. Any suggestions on how to power such a setup? I'm assuming that I will need to power the mount directly from mains with a separate 12V converter. Apologies for the long rant. Any or all suggestions on these topics greatly appreciated!

Thanks @bottletopburly I may well do that. Gathered the necessary evidence today - it's definitely happening intermittently but more often than not; and it doesn't depend on which camera is attached first. I thought that perhaps camera 1 is the first connected but not so. I wonder where the camera numbers are applied? See the screenshot - latest APT version; 1600MM was attached when APT was started; 290MC attached afterwards. APT connected to the 290MC and correctly detected the sensor size, but incorrectly identified it as the 1600MM. The biggest hint that something is wrong is that the cooling aid isn't available, but otherwise it will happily let me use the 290mc. Causes lots of head-scratching especially if it's also connected to phd2.

How can I set up APT so that it always connects by default to my imaging camera? I have an irritating problem that APT will regularly connect to my guide camera, even though that camera is already connected in Phd2. I have created two APT shortcuts on the desktop, one specifying camera 2 (which usually is the guidecam) and the other specifying camera 1 (which is usually the imaging camera), but it looks like cameras 1 and 2 are not absolutely assigned to the ASI1600mm (imaging) and ASI290MC (guiding). At APT startup, in the log it will say 'Connected to ASI1600mm' and then imediately say 'sensor size 5.6mmx3.2mm'. Then I know I have a problem as it's obviously not the 1600! I can usually sort it out by disconnecting, Shift-Connecting (to get the camera selection dialog), and selecting cameras 1 and 2 until I get the correct sensor size. There must be a better way?

Top corner menu - select "Configuration Nodes" Double-click your mqtt broker node and update the IP address in the configuration menu. You'll need to redeploy your flow.

Influx is ideal for sensor data. It's optimised for storing time series data on the basis that most of the data will be written but rarely read. Grafana is the generally the dashboard of choice. Great memo here https://www.influxdata.com/blog/running-the-tick-stack-on-a-raspberry-pi/ on running it on Pi.

It's fantastic to get the opportunity to practice with some 'real' data, and to see what to aspire to. Processed in Startools 1.6, HST SHO with 50% Ha, and some tweaking to Gimp to whiten the stars and add contrast.

I started with this scope and was very happy with it for the price - it is excellent value for money. If you're not sure whether you want to invest in astronomy, or don't have the (very significantly more) money to go for a robust goto/tracking mount, this is a very good starting place. You will be able to see many space wonders, but photography will be very basic. The mount has two slow-motion controls for Dec and Right Ascension. You get into the approximate area of sky with the RA and Dec clutches, and then fine-tune using the slo-mo controls. The Dec slo-mo can be used to track the object manually. The red-dot finder that comes with it is very helpful to find objects initially. Don't forget to switch it off once you're done, or the battery will run down quickly. I wouldn't agree that it is difficult to find objects like Saturn and Jupiter - at least you can see them with the naked eye as bright stars, so once you get used to it it's really quite straightforward to get the scope pointed directly at them. As mentioned above, the motor drive will not help you find an object. It may help with tracking an object once you find it - I never managed to get the motor drive to work for me, so I don't recommend it. Others have used it successfully. My issue was that it takes over the Dec slo-mo control point, so you can't manually fine-tune the mount any more, You need to constantly adjust the motor speed up and down to 'catch up' with the object, and to reverse once you 'pass it out'. Personally, I would suggest that you save €50 and not buy the MD version. On the plus side, objects such as Saturn or Jupiter don't move particularly quickly with wide-angle eyepieces. As you increase the magnification, they will move across the field of view faster. There's no problem following them with the slo-mo Dec control. It really only causes stress if you're showing objects to other people; you will have to adjust the Dec control every ~20 seconds or so at highest magnification, and because you can't see while they're watching, you need to get them out of the way quickly! I would certainly recommend this scope at that price - you can get a very usable mount and scope with an acceptable level of quality for €300 (aud499). You will definitely be able to see the planets and the brighter nebulae e.g. Orion. I was amazed at what I saw through mine. Just bear in mind that if you want better optical quality, a stable mount and goto/tracking capabilities you will need to spend 5 times this amount. If you want to take pictures that impress your friends, you will need to spend 5-10 times this amount.

Don't think there's any reason not to use I2C for both. Adding I2C and SPI will complicate both software and hardware. In your sketch extract, you started the the same bme twice - maybe you've spotted this. I also don't like using 'and' in this context because it won't trap if one of the sensors fails. How about: bool status1, status2; // Assumes that Adafruit_BME280.begin() returns 0 on fail, <>0 on success? if (!(status1 = bme.begin(0x76) ) { Serial.println("Could not find BME280 sensor on 0x76, check wiring!"); } if (!(status2 = bme2.begin(0x77) ) { Serial.println("Could not find BME280 sensor on 0x77, check wiring!"); } if (!(status1 and status2)) { // traps if either sensor fails. Serial.println("Sensors not connected!"); while (1); }

I can't find the reference now, but the recommendation for pressure monitoring is to take readings inside, to avoid any impact from large external temperature changes.

Yes - the line to change is // Attempt to connect if (client.connect("ESP8266Client")) This is a hard-coded mqtt client ID. The client referred to in the PubSubClient is a network client to use on connection.

Interesting point.... You're creating a WiFiClient earlier in the sketch, and using the return value as the mqtt client ID. I would imagine (though can't confirm) that WiFiClient returns a unique code of some sort, that would satisfy the unique mqtt client id requirement. Personally, I use the MAC address of the client device as the mqtt client id, and apparently you can get that with WiFi.macAddress()

Yes, humidity may be correct - you'll just need to leave it be (or bring it inside) to see if it adjusts. Puzzled by the pressure spikes. I've found the BMP280 sensor to be very reliable - the calculation is so complicated you're unlikely to end up with an incorrect result! I just checked my database and the min/max values for the last two days are 986-991. No outliers in 33,000+ data points. Also your spikes are invalid pressure figures - 400hPa, 1,200hPa etc...? Is it windy where the outdoor sensor is located? Possibly it's a failed call to the sensor, and the un-initialised result is being recorded anyway...? A quick fix could be to apply thresholds and drop the invalid values, but you'd prefer to get an explanation for it. I can't imagine that the RPi Zero mqtt would struggle to keep up with such a small number of messages. When I see drop-outs, it's almost always because of a wireless connection issue. I find wireless routers so unreliable - even modern routers. I have a Chromecast dongle that manages to disrupt almost all communications on its wifi channel. If you disconnect the outside sensor does the indoor one start recording again? btw, I've just installed MQTT Explorer. Hadn't come across it before, and I'm enjoying watching my messages flow through. Thanks for that tip.

I've plugged DIP chips into their sockets upside-down, and then spent ages debugging with power applied. As long as you don't release the magic smoke everything should be fine! 🙂

Glad you sorted that out.... ! I've never had issues with DHT22s - other than one that has recently taken to consistently reporting 99% humidity. And yes I did check if it had fallen into the water. Looks like there's a short somewhere near your device. Was about to say that the BMP/BMEs have switchable I2C addresses but I see the issue is with your breakout boards. I suspect with a scalpel and a soldering iron you can fix that?

@BZd fantastic work! Thanks for this post, it will unfortunately be very useful to others. I would be very interested in knowing more about your protection circuits. That's interesting about the LED. The LED on my HEQ5 board flashes constantly while powered on - at about 1Hz, but not regular enough to be a feature. I don't think it's supposed to. Does anyone else have this behaviour?

In my experience these devices are very hard to kill, and I've tried lots of ways. Are you definitely on /dev/ttyS0? Are you using a separate usb-to-serial adapter for your serial console - or have you anything connected to one of the UART pins? It gets me sometimes when I have a separate UART connected to the tx/rx pins - can't remember the details off-hand but one of these pins needs to be toggled by the flasher, and the serial adapter prevents it. It fails with a timeout similar to yours - I have to disconnect the UART and reflash.

You will need to handle mqtt disconnect messages and automatically reconnect. Not saying that this is you current problem, but.... I find that wireless is always the most unstable link in the chain, whether Wi-Fi or other. I agree with local control for critical control applications. Detect and resend should be fine for non-critical control applications, and best effortsmay work for most sensor data.

Apparently some guy called Ricky Wilson.... never heard of him!

Yes Gina, I've been using node red to control my sensor network for years. I find it extremely useful and very reliable. I use it in two ways - on an Amazon web services linux server as the core of the sensor network, and also on Raspberry PIs when I need to solve any local problems like interfacing from a Flukso power meter to the cloud, or consuming publicly-available open-data datasets etc. Quick and easy to set up, and very easy to create the flows. Node red on my AWS linux box has no problem managing 10's of mqtt messages per second, running 24x7 for weeks at a time. CPU and memory usage on an AWS t2.micro box is minimal. I don't use the dashboard - found it fiddly, and never figured out a way to embed it in my own website (also actually hosted from within node red). The central set-up uses mysql for configuration data, and influxdb for time series sensor data. Node red talks to both databases. Grafana is the dashboard front-end. Communications from sensors and access points to the server uses mosquitto mqtt which is very straightforward, both within node red, and as a stand-alone linux mqtt broker in AWS. Node red can create mosquitto topics on the fly, just by specifying the 'topic' property on input to a mqtt output node. The topic doesn't have to pre-exist. Nginx proxy server sits in front of everything, and controls access to the node red admin gui, the custom website, mosquitto, and granfana. The databases are firewalled and not accessible from the public network. Sample screenshot from the website, which uses the Bootstrap framework: Sample grafana screenshot: I should add that a lot of work has gone into this.... and more is required. My brother in law uses esp8266s with openhab to get a similar result, but I haven't gone down that route. My sensors are a mixture of custom-designed boards with TI msp430 mpu, nrf24l01 radio transceiver, esp8266, and Dragino HE. the msp430 is an ultra low-power arduino equivalent; I don't use arduino as I'm proficient in C and am interested in embedded C programming so I wouldn't get any benefit from the arduino IDE. Dragino is an openwrt linux module - I'm a big fan, having first gotten to grips with openwrt on the TP-Link wr703n router and the Dragino is a big step forward from that. I see raspberry PIs as overkill for what I do - it's really a small form-factor desktop rather than an embedded platform. However, I do have a bunch of them lying around for various uses including a cross-compile platform for the esp8266. I'm gradually moving towards having all sensors based on esp8266 - it's such a versatile chip, although philosophically I have an issue with simple sensors having a complete TCP/IP stack built in, and using up to 200mA in active mode (the msp430 /nrf24 combo uses 20mA max). I use oshpark.com for PCB printing (very cheap and good) and assemble myself, or for more difficult work, macrofab.com prints and assembles small batch boards (very good but quite expensive). I only use them if I'm using components that are too small to hand-solder (like a bmp280!) and if I've gone past the break-out board prototyping stage. HTH! Padraic.

If it ain't broke.... much as I like Liam Neeson, no one could possibly match Richard Burton. This one is 'for the new generation'. I don't see this on my wish list!

Very excited! Don't think I'll get to set it up tonight though... ⚡🌩️ Field flattener still on the way.

Not sure that there will be a quality difference as such between the 100 and the 120 - both will be excellent - but a field of view difference, as they have different focal lengths. Check the various fov calculators online or input these scopes into Stellarium and see the difference the focal length makes to fov. Many folks on here use the Esprit 80 or similar as their primary scope, matched with the ZWO ASI1600MM. The HEQ5 will carry this combination comfortably with the usual accessories e.g. focuser, filter wheel, guidecam and camera; and you'll save a heck of a lot of money over the 100 or 120. It just depends on what you want to image - large nebulae (go for the Esprit 80) or small galaxies/planetary nebulae (go for longer focal length). With the shorter FL at least you have the option of cropping. With a long FL you don't have that choice, and it makes guiding more difficult.