Tag: Astronomy

July 2024 update

Instructables builds

There are now 9 builds listed on the Instructables website, I’ve also had contact from other builders, I guess there are around 20 telescope builds out there. So there’s a small – but amazing – community forming for the telescope now. To create a sort of support group for the project I’ve created a Discord group for people who are building or running a copy of the telescope.

PM me via the Instructables project page for a link if you would like to join.

GitHub for pi-lomar updated

A large number of changes to the package are in the latest release just published on GitHub. There is a list of the changes, and some hints about upgrade options here.

The most significant changes in the new release are

Now runs on Raspberry Pi 5.

The GPIO handling is different on the RPi5, so I had to redevelop and retest the GPIO code to work there. This reinforces the advantages of switching to Bookworm 64bit O/S. The RPi4 and RPi5 both run pilomar happily on Bookworm now. Support for the RPi3B with the old ‘Buster’ build remains, but it cannot support some of the new features in this latest release. If you want to upgrade to the latest version I now strongly recommend a RPi4B or RPi5 as the main computer now.

FITS image handling.

With support from a few people in this project, and also from Arnaud and the Astrowl box project there’s now a way to save .fits format image files. FITS file formats are required by some astro image processing software. The raspistill and libcamera-still utilities will save raw images in .DNG format, but that is not accepted by some software. This new FITS format only works on Bookworm builds because it requires the picamera2 package to be available. You may be able to get this installed on earlier O/S versions, but I think it will need some tinkering. The FITS handling has been done by creating a new standalone Python routine (src/pilomarfits.py) which can be called just like the ‘libcamera-still’ command, but which generates .JPG and .FITS files instead. This is likely to improve further in the future, it’s just an initial attempt to add FITS format.

Smoother motor movement.

A whole bunch of ideas came from other builders, it became clear that microstepping is easy and safe to activate for most people. Microstepping makes movement slower, but smoother and quieter. It required some rethinking of the code on the microcontroller because microstepping generates a lot more motor pulses, a limitation with the clock in CircuitPython became apparent but is now resolved. There is also a ‘slew’ mode available in the latest package. This lets the telescope perform LARGE moves using full steps on the motor – noisy by fast. Then when it starts capturing the observation images it switches to microstepping.
Better microstepping support also means that you can build using the 200step stepper motors now. These are generally easier and cheaper to buy.

Easier configuration changes.

Pi-lomar’s configuration is generally held in the parameter file. You can make a lot of changes to the behaviour there. This latest release has moved even more of the configuration into this one file. However some changes can be quite complex to configure correctly. Therefore the latest software has added a few options to perform some common configuration changes directly from the menus. This ensures more consistent and reliable setup for a few camera options and also for configuring several of the microstepping related issues.

Aurora features.

After the spectacular Aurora displays earlier in the spring, I’ve added some experimental Aurora recording features to the software too. Obviously we now have to wait for some good Aurora displays to fully test this feature, but the basic concept seems to work OK. In Aurora mode the camera points to a likely direction for the Aurora and captures images as quickly as possible. It can also generate a simple KEOGRAPH of the aurora display which may be interesting to study sometimes.

Observations

Well, summer is here now, and the skies are too light, too short and sadly still too cloudy. So no practical observations of anything new to show this time. All the project work has gone into this latest software development round instead.
So I’m now looking forward to slightly longer and darker nights coming in August and September, and hoping that the clouds go away.

What’s next?

I’m currently exploring some modifications to the telescope design.

Now that the RPi5 is supported – it has TWO camera ports! So I would like to explore the idea of having two cameras mounted in the telescope. Ideally a 16mm lens dedicated to tracking, and then a 50mm higher quality lens dedicated to observation pictures. There is also some feedback from other builders which is re-opening the design of the camera tower and camera
cradle. I’m currently thinking to make a slightly wider camera tower to accommodate 2 cameras, and probably reorienting the sensors into portrait mode to improve access for focusing. It may make sense to improve the weatherproofing around the camera boards – as others have already done.

After a chat in the Discord group I’m also looking at adding a permanent ‘lens cap’ to the camera tower. This would sit below the horizontal position of the camera, so that the lens can be parked up against it when not in use. There are a
couple of advantages to this idea. (1) You don’t have to remember to remove or reinstall the lens cap. (2) If the cap is sufficiently dark the camera can take the ‘dark’ control images automatically at the end of each observation.

I have a redesign of the motorcontroller PCB nearly ready, with improved power performance for the microcontroller. There will probably be another couple of improvements made to it, and then I’ll try getting some samples printed up. I considered switching from the Tiny2040 microcontroller to something larger with more GPIO pins, but have decided to stick with the current setup. There seems to be a practical memory limit on the RP2040 chip in the microcontroller, it has around 200K of working memory available to it, and the current functionality consumes it all. I cannot even get the current code to run on CircuitPython 9.x yet, so it’s still limited to 7.2 and 8.2. It may be worth waiting to see if any 2nd generation microcontroller comes from RPi in the near future before finalising the design.

February 2024 update

Instructables builds

There are 5 ‘I made this’ posts on Instructables now for pi-lomar, and a few other builders have been in contact with questions and suggestions over the last two months. I’m really looking forward to seeing what people manage to do with the telescope and get some feedback and improvement ideas.

GitHub for pi-lomar updated

The January issues branch in GitHub became quite a monster, there is a list of all the changes available here. I’ll cover a few of the interesting items here.

UART communication problems

A few people have had problems getting the communication to work between the RPi and the Tiny2040. This has been due to a few different issues, but it became clear that more help was needed to identify where the problems are when communication doesn’t work. If something is wrong in the communication chain you might get an error message, or you might simply get a ‘dead telescope’ which refuses to move. So I’ve added features to detect and complain more clearly if something is wrong, and also a way to monitor and test the communication in realtime.

Software versions

The original build required very specific versions of CircuitPython and the Raspberry Pi O/S. I’ve addressed a few of the limitations now so you can use the most recent copies of both. I’ve now got a telescope running happily with Bookworm 64bit on an RPi4 and CircuitPython 8.2 on the microcontroller. This means you can use whatever the current version is – you don’t have to go looking for archived copies anymore. The released version does not work on the RPi5 yet – I’m going to rework the camera handling for that beast first.

Motor configurations

The original design was heavily dependent upon specific stepper motor designs. This was quite restricting for some because they are not always easy or cheap to source. The new software has moved the motor and gearing configuration into the parameter file instead of being hardcoded. So now it is simpler to set up alternative motors AND you can still take updates to the software without having to repeat your own hardcoding changes.

Removing the infrared filter

In the last blog I mentioned that I had removed the infrared cutoff filter from one of the camera sensors. I had to wait a while for a clear enough night, but eventually grabbed a few shots of the region around the Orion Nebula. It was not a great observing night, there was considerable haze and some random cloud, but I got a few images.

I am happy to confirm that it really made a difference though. New objects appeared and previously faint objects are clearly enhanced by expanding the vision of the sensor.

After stacking and some enhancement in The GIMP, this is the region with the new infrared capability. I was not able to remove ALL the haze, but if you are patient you can reduce it considerably.

For clarity I’ve marked the major items that are now visible below.

There is clearly a colour tint still to these images which I need to play with some more, but there are definitely new details here.

Orion Nebula

There seems to be a larger area of nebula visible in this image. The colour variation is not as good as earlier images but I think that’s something I can still work on.

Flame Nebula

This was faintly visible before the infrared cutoff filter was removed, but it seems to be more clear now. Hopefully when I can gather more images to stack I can pull more clarity from that still.

Horsehead Nebula

With the infrared filter in place you could see a very faint hint of the Horsehead Nebula surroundings, but they were very subtle. You had to know there was something there and then play with image enhancement to get even a slight hint of it. But it is now more clear.

Barnard’s Loop

Orion is surrounded by a large ‘infrared only’ area of gas. I’ve never seen this before in any observations I’ve made, but suddenly it’s there. Barnard’s Loop is to the left of the belt, and although faint, there’s no doubt it’s now detected. The gas cloud extends lower down around Orion too, but in this shot it’s hard to separate urban haze from actual gas cloud.

Urban Haze

This brings me to by current problems, urban haze. There is light pollution and generally poor quality atmosphere around here. I’m not living in a big city but the conditions are visibly deteriorating as time goes by.

The IR image above is taken with the 16mm lens, I have now removed the IR cutoff filter from the 2nd telescope with the 50mm lens too. That also has a light pollution filter added. The brief chance I’ve had to test it suggests that it does indeed make a difference to the haze that’s creeping into all the shots. The question is- does it also reduce the infrared wavelengths too? The next clear moonless night may answer that.

There’s another place where haze becomes an issue. That’s in the drift tracking mechanism of the telescope. Pi-lomar checks its position by taking a live image and comparing it with a calculated image of the sky. It uses the difference between star locations to correct the position of the camera. It’s not perfect, but it works well enough for the images to be stackable. But if there is strong haze in the sky the Astroalign package can struggle to recognise and match stars between the images. You can get a cloud of false stars at the bottom of an image which confuses things.

To work around that I use OpenCV to try to enhance the stars in the live tracking image. Basically trying to reduce noise and enhance just the real stars. This requires tuning some OpenCV filter functions to work nicely with MY particular observing conditions. That’s a problem for people in other locations, they may need to tune the filter functions differently.

So I’ve modified the software to make these OpenCV filter functions into ‘scripts’. You nolonger have to play with hardcoded function calls in the software, you can simply edit the scripts and test them rapidly against your conditions. I hope this is a good benefit for people. I will probably refine the configuration and testing further in future versions. This is clearly an area where a graphical interface would help. An early test of this new feature looks promising when trying to filter out tree branches from someone’s live tracking images. It looks like we can still pull stars out of quite busy and noisy shots.

Next steps

I am not intending to develop the software further now until the summer. The latest update needs to be taken into use and tested in more environments, so I want to limit any new changes to bug fixes or tuning related to that. Spring is approaching, it’s better to spend time observing!

December 2023 update

Finally published

So the telescope project is finally out! 50% of the project time seems to have gone into making the instructions. Mainly because life is busier now than during the Pandemic, and partly because of all the lessons learned while making them. Like so much of the project, the instructions included a lot of firsts for me too. A few mistakes have turned up in the build guide, but I’ve always received very kind and positive feedback and corrected any mistakes as quickly as possible. I still need to complete a full ‘bill of material’ list though!

New issues


Feedback from builders has revealed a few issues, I’m expecting more items to appear in the coming weeks as people get the telescopes up and running. What worked for me, may not work for others, we’ll find out what was luck and what was bullet-proof soon! There are so many different ways to build every element of the project that there will ultimately be variations in every model.

PCB design

The PCB has been an unexpectedly interesting part, the build videos included a PCB that I made over a year ago as part of an exercise to learn how to use EasyEDA to design circuits. It included experiments and some development features – and also included a mistake in one of the tracks. But with some careful track sculpting with a Dremmel I got it running.

The circuit for the project is simple, and with hindsight could be even simpler. I understand that it’s more comforting to have a proven circuit board rather than building your own solution. So an immediate side project fired up, a few people were kind enough to offer help to create a proper design for the PCB which could be published. As I type this, I have 2 different prototypes on my desk for testing. If both pass the tests then I’ll add the Gerber Files into the GitHub repository so that people can get their own boards made up too.

I still wonder if there is a suitable commercially produced HAT that would perform the same function. I’ve not found anything yet which has the onboard logic AND powerful enough stepper motor drivers. If one ever appears it would be sensible to rework the project to make use of that. There are similar ideas out there for robotics I suppose, but I’ve not yet found an appropriate specification.

I’m running the Tiny2040 microcontroller on very low voltage, out of an abundance of caution really. When I measured it recently it’s showing about 2.5V across the Tiny2040. Apparently 3.0V is the recommended minimum, but two telescopes have been running nicely on 2.5V for a long time so far. However I’ll revise the component specifications with the new PCB design to increase the voltage a bit, that might increase tolerances for different designs.

3D printing

My humble 3D printer, limited printing skills and multiple design iterations meant that my builds took MONTHS to produce. You can imagine my amazement when people started posting photographs of the telescope structure nearly complete after just a few days! They are all really nice quality prints too. It quickly appeared that at least one of the published STL files was from an older iteration – but it is corrected now. I’m resisting the temptation to evolve the designs further at the moment until a few more people have got the current design up and running. Then I can have more useful insight into areas for improvement.

Simplified kit

One question that appeared quickly was ‘How do I make one if I haven’t got a 3D printer?’. It sounds like sending the STL files to a commercial printing company is too expensive, and probably there are too many parts to make them all at a local maker workshop. At first I thought that would rule out making the telescope completely, but after a couple of conversations I started to think differently about it. The only thing that you really need to get 3D printed is the mechanism. Basically the gears and cogs are useful, everything else can be made from any material you like. So I’m wondering if there’s a side project possible here, a cut down version of JUST the mechanism, maybe 10 parts, slightly redesigned so that they can attach to anything. A drive-only kit would be more manageable to get printed. I’ve not designed anything yet, but if I get another cloudy winter with little observation done it might make a good evening project.

New lens

I know that the project began with the question “Can the RPi camera components make a working telescope?”, but of course I’m now chasing better quality. I suspect a lifelong challenge. The telescope works mechanically well with the RPi 16mm lens, but that’s got about 20Degrees field-of-view so things are small. I have been using the 50mm Arducam lens for about a year now and that magnifies much better, about 5Degrees FOV, but the question in my mind now is … are the optics high enough quality?


I’ve noticed that even quite poor images are rescued very well by the stacking software, but I couldn’t help trying a higher quality 50mm lens. So I’ve fitted a Nikon-to-C adaptor and mounted a regular 50mm Nikkor SLR lens to the telescope. I grabbed about 20 frames during a brief unexpected gap in the clouds the other night.


Some immediate thoughts…
Focusing is MUCH easier with an SLR lens. It was quite fiddly with the little C/CS lenses, but the SLR lens was producing crisp star points in minutes.
The camera cradle is JUST big enough to squeeze the 50mm lens in, but the weight of the lens is an issue. I modified the camera cradle to make use of the tripod mount hole at the bottom of the HiQ sensor. That should take the weight of the lens better and reduce the pressure on the rest of the PCB. It’s generally a better design even for the smaller lighter lenses.


It’s raised an unexpected problem though, the new images have a definite CYAN tint to them. Is that a feature of the SLR lens coating? Is it because the image is just more crisp? Is it only in the JPG images or is it in the .DNG raw files too? Experiments and/or other people’s advice is needed here.
I have STILL not been brave enough to take the IR filter off the sensor.

Software

The first few people to start builds have identified some fixes which are in the next software release, I really appreciate their patience while we get all this working easily for everyone. My main focus at present is to improve the problem solving capabilities of the software.
Some examples:

I am adding a feature to help tuning the telescope’s Tracking Function. You have to balance two or three parameters to get it running smoothly, so a tool to help find good values seems sensible.

Debugging communication has been an exercise for everyone, so I’m cleaning up some error messages to make things a little more clear there.

There are a couple of extra ‘version’ messages in the log files now so we can see what versions of components are installed.

Raspberry Pi 5

I could not resist so I ordered one online… and had to wait… meanwhile I was in the Raspberry Pi shop in Cambridge the other day and they had a bunch on the shelves… I very nearly bought another.

The current project is restricted to the ‘Buster’ operating system and the RPi4B. (The RPi3B seems to work too, but is slower.) Both are aging, I fear something critical may one day become unavailable. I already had the problem that the Buster image vanished from the official installer tool about the same time I published the instructions. Luckily there is an archive of all the old versions available. So I need to plan for an updated build eventually.

The RPi5 is sufficiently different architecture that the setup and some functions will need rethinking. But if I can get the telescope working on the RPi5 there are useful new capabilities.

  • libcamera replaces the old raspistill camera handler. I’m hoping that makes handling of the RAW image data simpler. Let’s see.
  • The RPi5 of course is more powerful, which improves performance. Maybe onboard image stacking becomes viable if I can find a LINUX live stacker package somewhere.
  • The RPi5 supports 2 cameras simultaneously. This is very useful. Today the telescope uses a single camera for IMAGES and also for DRIFT TRACKING. In practice a single lens cannot be optimised for both functions, but 2 separate lenses solves that. I think a 16mm lens for the drift-tracking and a 50mm SLR lens for capturing the observations would be great. That may allow different tracking strategies too.

My heart sinks at the thought of fighting through all the package dependencies again, perhaps I should still wait a while for everything to stabilise.

Observing!

Of course the purpose of a telescope is to actually make observations! So I’m really hoping that we have a better winter than last year. So far the forecast has been quite poor, but we’re occasionally getting unexpected clear periods in otherwise total cloud cover. It means you have to keep an eye out for the breaks in the cloud because the forecasts are picking them up. A fully weatherproof telescope would be a real bonus here, then you could grab the brief random opportunities that present themselves. The light pollution has been quite bad around our village too, we’re close to the coast which seems to leave mist in the air, and recent building development is adding to the lighting problems. The need to make this thing fully portable is growing!