What you need

• 2x MLX90614 thermopile sensors
• 1x Arduino Nano
• 1x W5500 ethernet adapter (I use the tiny one for this project)
• 1x IP camera cable
• 1x IP camera POE module (optional if your cable puts out 12V)
• 1x RJ45 connector
• a bunch of jumpers
• waterproof enclosure (I printed one)
• Some way to mount it over the ground

If you want to print out my housing, you’ll also need the following…

• A 3D printer (obviously) and weather-resistant filament (I use CPE/PETG)
• Silicone
• 1/4-20 nut
• tripod ball mount

How to do it

Although, for the most part you’ll be following the instructions in my MKI post, there are a couple of steps that are different. Instead of exposing the RJ45 jack on the W5500 to the world, you’ll be running the IP camera cable through the housing and then crimping an RJ45 connector onto the the Tx and Rx wires of the cable. The 12V and ground wires will be soldered directly to the Nano on the input power pins 29 and 30 (GND and Vin). That is if you’re sure that the on-board voltage regulator is good for 12+ volts.

More to come…

The post Cloud monitor MKII (now with POE!) first appeared on OBAFGKM.

The post Cloud monitor MKII (now with POE!) appeared first on OBAFGKM.

The theory

We could get in to the theory of blackbodies (maybe later), but it is sufficient to say that…

1. Clouds are warmer than a clear sky.
2. The infrared spectrum of an object can tells us something about its temperature.
3. If you can measure the temperature of the sky, you should be able to say something about whether it’s cloud-free or not.

To measure the temperature we need some sort of contact-less thermometer that can be pointed at the sky (and ground, more on that later).

What you need

• 2x MLX90614 thermopile sensors
• 1x Arduino Nano
• 1x W5500 ethernet adapter
• a bunch of jumpers
• waterproof enclosure (I printed one)
• Some way to mount it over the ground

If you want to print out my housing, you’ll also need the following…

• A 3D printer (obviously) and weather-resistant filament (I use CPE/PETG)
• Silicone
• 1/4-20 nut
• tripod ball mount

When you print, you’ll want to print with supports. This design has a cupped bottom and a rounded top to, hopefully, keep some of the rain out. I printed on an Utlimaker 3 using Innofil transparent PET filament with Ultimaker breakaway for support. It worked well, but I don’t really like the UM breakaway material with the Innofil filament. Cleanup was time consuming.

Putting it together

The MLX90614 sensors ship with a fixed i2c address. 0x5A, to be exact. You can have many i2c devices on the same bus, but each must have a different address. So, you need to figure out a way to change the address on one of the sensors. Fortunately, this is fairly easy to do.

1. Make sure that the SparkFun MLX90614 library is installed
2. Connect one (only one) sensor to your Arduino. SDA goes to pin A4, SCL goes to A5.
3. Open the MLX90614_SetAddress example
4. Make sure that oldAddress is set to 0x5A and newAddress is set to 0x5B
5. Upload to your Arduino
6. Open a serial monitor set to 9600 baud
7. Follow the instructions
8. Easy, peasy, lemon squeezy.

Now that there are two different i2c addresses, both devices can be hooked up to the Arduino. At this stage I test using the following code…

//*******************************************************************************
// Reads from two MLX90614 thermometer boards and prints the object temperatures
// and the difference between the two.                                          
// 
// Modified from the MLX90614_Serial_Demo found in the library at,
//https://github.com/sparkfun/SparkFun_MLX90614_Arduino_Library
//*******************************************************************************

#include Wire.h; // I2C library, required for MLX90614
#include SparkFunMLX90614.h; // SparkFunMLX90614 Arduino library

const byte IRAddress1 = 0x5A;
const byte IRAddress2 = 0x5B;

// Create 2 IRTherm objects
IRTherm therm1;
IRTherm therm2;

void setup() 
{
  Serial.begin(9600); // Initialize Serial to log output

  // Initialize the sensors and set the units
  therm1.begin(IRAddress1);
  therm1.setUnit(TEMP_C);
  therm2.begin(IRAddress2);
  therm2.setUnit(TEMP_C);
}

void loop() 
{
  // Call thermx.read() to read object and ambient temperatures from the sensor.
  if (therm1.read())
  {
    Serial.print("Object 1: "); Serial.print(therm1.object()); Serial.println("*C");
  }
  
  if (therm2.read())
  {
    Serial.print("Object 2: "); Serial.print(therm2.object()); Serial.println("*C");
    Serial.print("Temperature Difference: "); Serial.print(therm1.object()-therm2.object()); Serial.println("*C");
  }
  
  Serial.println();
  
  delay(2000);
}

//Hardware Hookup:
//MLX90614 ------------- Arduino
//  VDD ------------------ 3.3V
//  VSS ------------------ GND
//  SDA ------------------ SDA (A4)
//  SCL ------------------ SCL (A5)

Once the two sensors are working properly, the W5500 ethernet adapter can be connected and tested. The adapter is an SPI device and can be connected as follows…

When writing the code for the W5500 adapter you’ll need to keep in mind that you want to be using the ethernet2 library. Also, these modules typically don’t come with a fixed MAC address – you’ll be setting your own in the code, so you can get creative. For this, I’d recommend choosing a ‘proper’ locally administered MAC address instead of something completely random. By proper, I mean that the least-significant bit of the first octet of the address needs to be a 1. So your address needs to look something like…

where the x’s can be hex value you want. I chose BA:D1:DE:A5 to fill my first 4 octets and use the last two to number the devices on the network. A quick google search will yield lots of interesting hex ‘words’ that you can use if you want something memorable.

The code

I’ll be the first to admit that I’m not a master coder when it comes to C/C++. I get by on the Arduino thanks to the help of the ‘Googs’ and the examples that are often provided with libraries. This project is no different. Thanks to the SparkFun MLX90614 and Ethernet2 libraries, I was able to cobble something together that works reasonably well.

What I wanted to do was simply talk to the cloud monitor every once in a while to ask for current readings and record them in a local log file. As well as creating a log, I also wanted to plot the data at regular intervals and save a PNG that could be copied to a web-accessible place for viewing.

Insert code here…

Running it

Once everything is assembled and the silicone has dried, the cloud monitor can be connected to a computer or 5V power supply through the mini-USB connector. A network cable can be connected and then you should be able either navigate to its webpage or request packets UDP packets depending on what code you’ve uploaded to the Nano.

Some results

Some initial tests of the monitor show that it’s pretty good at detecting cloudy skies. The image above (several days of data) shows that, when it’s cloudy (seemingly all of the time right now), the temperature difference between the sky and ground sensor is only a few degrees. When it starts to clear up, however, the difference increases dramatically and can be up to 35 degrees during daytime clear skies. Although temperature differences of 20 degrees are a lot better than the cloudy sections, the skies are often still covered with a thin cloud.

Plotting a single day of data (below) we see the typical appearance of a large, ca. 30 degree, difference during the daytime when it’s clear and ca. 20 degree differences during night time clear periods.

Coming up

I don’t like having a separate power cable for this unit, so Mark II will have POE. It turns out that it’s a pretty simple mod that I wish that I had made the first time around.

The post Building a network-connected cloud sensor (MKI) first appeared on OBAFGKM.

The post Building a network-connected cloud sensor (MKI) appeared first on OBAFGKM.

For many years, this was the Watec 902 series. They are good with resolutions of 720 lines on an (up to) 1/2″ CCD chip. Their sensitivity is estimated at down to levels of 0.0001 lux. And, if you wanted to kick things up a notch, you could always put an intensifier in front of it (while driving cost and complication up, of course). Great, but is it the best solution for low-light video-rate imaging? Nope.

A few years ago I was introduced to Denis Vida. We talked about meteor observations with his RMS software and whether we could use cheap IP board cameras instead of analogue cameras with frame-grabbing dongles. Since then, we’ve now tested a number of low-light CMOS cameras from Sony’s Starvis line and found that these cheap network cameras can outperform cameras costing an order of magnitude more. Sweet.

So what does this have to do with building a finder scope? Well, since a lot of my work has been with prime focus telescopes where there was no possibility for inserting an eyepiece and since we have no finder scopes, it seemed logical to take these cameras and modify them for use as a finders.

Choosing a lens

When choosing a lens you want to get as much light as possible onto the chip. Which means finding one with as large an aperture as possible. There are currently a number of very good short focal length (4-8 mm) lenses with f#’s less than 1 but most longer lenses are somewhat slower. In addition to maximizing light on the chip, you also need to consider your desired field of view. For meteor work we typically work with fields of view from about 20 degrees to all-sky. For a telescope finder, however, something narrower is desirable.

To calculate the field of view of a particular lens you only need to know its focal length (fl) and the dimensions of your chip. The IMX291 is a 1920×1080 sensor with 2.9 μm pixels. This gives a size of 5.6 mm by 3.1 mm with a diagonal of 6.4 mm. The plate scale (measured in arcseconds/mm) is given by the following,

scale = 206265/fl

The two lenses that I considered were a 25 mm f1.2 and a 50 mm f1.4. So, from the above equation I would expect the angular size of the sensor to be

(206265/(25*3600))*5.6 = 12.8 degrees in width

by

(206265/(25*3600))*3.1 = 7.1 degrees in height

for the 25 mm lens and half that (6.4×3.6 degrees) for the 50 mm lens.

What you need

• IMX291 IP board camera
• 25 mm or 50 mm lens with a wide aperture
• POE module (or do you?)
• IP camera POE cable
• 6 1cm long M2 standoffs
• an enclosure for the camera
• POE injector
• 2 network cables
• software like CMS, ONVIF manager, Shinobi, etc.
• silicone sealant
• M2 and M3 taps
• 4 short M3 bolts for fastening the lid to the case

Putting it together

1. Mount a CS mount to the camera board (be sure to peel the protective film off the chip window if there is one).
2. Screw a lens into the mount and set the camera module aside
3. If using my enclosure design, you’ll want to glue or silicone a 1/4-20 nut into the side of the enclosure. This allows you to attach the camera to a mounting plate/adapter for your scope.
4. Next, I would open up the holes for the standoffs and run an M2 tap into them to clean up the threads
5. Turn 3 or 4 standoffs into the M2 holes and then feed the IP camera cable into the enclosure
6. Put the connectors on the loose wire ends
7. Connect the appropriate connectors to the POE module
8. Fasten the POE module to the standoffs with another round of standoffs
9. Plug the POE-camera cable into the camera board
10. Fasten the camera module to the exposed standoffs with the long standoffs provided with the camera module

Likely, the IP cable came without the connectors attached and may or may not have yellow and grey (or gray, if you prefer) wires. If you’re using a POE module, the cable can be connected as follows…

Testing the camera

Testing the camera is pretty straightforward. The only thing to remember is that it has likely shipped with an IP address of 192.168.1.10 or 192.168.0.10. If in doubt, you can plug it in to your router and see if a new device has shown up with a new IP address. Alternatively, you can plug it into the ethernet port on your PC, setup the networking and run arp -a and see if it shows up in the results.

For camera setup I always start with CMS as it gives me easy access to all of the camera settings. ONVIF manager gives you some control, but CMS is a better tool for setup. And if the cameras are going to be run on Linux… I recommend finding a windows machine for the setup and then switching back to Linux when running the cameras.

The basic settings that you’ll be changing are: frame rate, video format, bw/colour, AGC, and integration.

To test and setup…

1. Plug in a network cable to the camera cable
2. Plug the other end into the POE port on the POE injector
3. Plug another cable into the LAN port of the POE injector
4. Plug the other end of that cable into your PC or router
5. Open up ONVIF manager or CMS and setup a new camera
6. Open up the new camera
7. Do you see an image? If so, focus. If not, bugger.
8. If you’re using CMS, camera setup is pretty easy.

No doubt all of this can be done on Linux, but it is a bit of a pain. So we always setup our cameras under Windows before moving them onto Linux systems.

Installation

There are plenty of options for mounting the camera. You’ll need to figure out what works best for your situation, but here’s what I’ve done.

Using the finder

Since there are a number of cameras in this installation, I decided to install an application that could manage multiple cameras. Any of the finders, status cams, and security cameras can be accessed from any of the domes. Very handy. After a quick search for opensource software that would do the trick, I settled on Shinobi.

How good are they?

I guess that it depends on what is meant by ‘how good…’ They solve the problem at hand, so I consider that pretty good.

In terms that we can relate to, the limiting magnitude of the finder shown here (50 mm lens) is about M11 under dark skies. Which is pretty much what you’d expect if you were visually observing with a 2″ finder scope. To make this claim, I’ve simply taken some snapshots from the cameras and then compared them to a star map. If you really wanted to get technical, though you might want to let a computer do the work. Which I have also done.

To do that, you just need to follow my instructions for a quick and dirty limiting magnitude calculation. Basically, what I do is compare detected sources in the images with real sources from the Gaia database and look for the point at which correlation drops off. The following two examples show this…

More to come…

The post A cheap, low-light IP finder ‘scope’ first appeared on OBAFGKM.

The post A cheap, low-light IP finder ‘scope’ appeared first on OBAFGKM.