maandag 29 augustus 2016

Case for Meade ETX125 EC

I recently purchased a second hand Meade ETX125.  Unfortunately it came without a case to safely store and transport it in.

I went on a search for an appropriate case and ended up buying a mobile tool box from Keter in a local DIY store.

It jus barely fits my telescope.  But as it is lacking some padding I purchased some hard insulation, pipe insulation and sound insulation.  After going to work with some scissors, box cutters and spay glue I ended up with an already pretty decent housing for my freshly bought telescope.

Empty tool box with tool insert removed

After gluing on some padding on the sides and adding the insulation

The end result with some sound insulation for further padding and a more 'classy' look
I might give this a spin and see if I can later on add some small storage for the GoTo controller, manuals, eye pieces, ...

zaterdag 31 oktober 2015

Scrap wood table

Some time ago I got inspired by this scrap table to make my own version.

I started out by collecting scrap wood from several sources. The table contains wood from an old bed, a coffee table, pallets, rubberwood countertop, ...

I ripped all these to  similar widths, while trying to maximize the number of strips I could get out of one piece of wood.  Each time I had a batch of these strips I marked the positions where the threaded rods needed to be and made the necessary oval openings with a router.

Initially I just drilled these holes, but due the temporary nature of my work setup and the time between working on this project the measurements were not consistent enough.  And having only a 10mm drill bit for 10 mm diameter threaded rods did not leave much room for error.  This became clear after an initial test fitting which almost did not come apart again.

Putting the table top together took a lot of work and repetition.

  • Fit,
  • Glue,
  • Clamp,
  • Repeat
  • ...

Once the table top was assembled, I straightened out the ends with a circular hand saw.

Due to some 'not-so-precise' measurements, I also had to plug some holes in the table top with some spare wood.

Once glued in place I used a chisel to level it roughly and sanded it down further with the manual plane.

I first planned on just sanding the table top flat, but that just generated too much fine dust.  Therefore I switched to a manual plane.  That sure is a workout :-)

The final planing was done with an electric belt sander with very fine grain sand paper.

Eventually I would like to make an extendable table out of this.  This directed the distances between the threaded rods.  But as I need the table sooner than I could make this an extendable table, I made some temporary support structure.

Although, making this into an extendable table will be a future project.  For now, I will enjoy the table as it is.

maandag 29 juni 2015

Raspberry Pi astrophotography

note: this article is a work in progress, stay tuned for updates

I recently bought a very basic telescope (Celestron Travel Scope 70), not exactly a high end telescope, but I'm still able to get some nice views on planets like Saturn, Jupiter and its moons, Venus and off course the moon.

Being enthusiastic about what I could see with this telescope I have tried taking photographs by manually putting my cell phone camera against the eye piece and minimize my trembling while pushing the button to take picture.

Not surprising that image quality is far from good.  For pics of the moon, it sometimes works out ok.

cropped image of the moon taken with my cell phone camera held against my telescopes eye piece

But while the features of Saturn are just distinguishable with the naked eye, it's almost impossible to take a nice picture with the methods described above.

image of Saturn taken with my cell phone camera held against my telescopes eye piece

Also Jupiter and its moons are hard to catch.

image of Jupiter and moons taken with my cell phone camera held against my telescopes eye piece

Taking it up a notch

Due to this less than ideal situation I decided to take things up a notch and use a raspberry pi camera. I printed an adapter for the Pi Camera to slide over my eye piece using my 3D printer.  After some filing and a paint job I have the adapter ready and I secure the Pi Camera into the adapter with some duct tape.

The idea is to eliminate tremor from holding the cell phone against the eye piece and being able to control the camera remotely.  Eventually I would like to be able to take a clear picture of both Saturn and Jupiter (and its moons).

Raspberry Pi setup

  • I started from a regular raspbian install
  • I enabled the camera, allowed ssh, expanded the file system, 
  • disabled the led on the pi camera [Ref]
  • and configure my wireless setup.

Powering the raspberry pi

I use an USB battery to power the Raspberry Pi setup.

Mount Raspberry pi on telescope.

Currently the Raspberry Pi is basically mounted on the telescope with some zip ties.

To be more comfortable I might need to add a longer ribbon cable between the camera and the Raspberry Pi.

Aiming the telescope

While the Raspberry Pi camera is on the telescope it would be hard to aim it very precisely.  Therefore, I setup streaming so I could check the aiming of the telescope with a laptop or cell phone (as long as I am within reach of my WiFi network) by following this guide.

Taking pictures with Raspberry Pi

Once I  somewhat correctly aimed my telescope I could use the regular Raspberry Pi Camera commands to take pictures of the celestial bodies.

Impressions so far

The pictures I took were not so good as the ones taken with the cell phone, but that is probably due to the low resolution used to take the pictures with the Raspberry Pi Camer.

The way the current adapter is made, it is very fidgety to get it well aligned with the projection from the eye piece.  I have the impression I will have to redesign the eye piece adapter even further to make fitting the adapter on the eye piece easier and to put the raspberry pi camera lens even closer to the eye piece.

Luckily both the Raspberry Pi and the laptop used for aiming were both within reach of my WiFi.

The USB battery could provide sufficient power for the 1 hour I have been testing my setup.

Some test results from 29/06/2015:

Moon in 640x480 resolution

Saturn in 640x480 resolution
Test results 30/06/2015:

moon in 2592 x 1944 resolution

saturn in 2592 x 1944 resolution

arcturus in 2592 x 1944 resolution
Although shot in higher resolution, the improvement is not that great.  The Saturn pic at least shows some interesting shadows.  Not sure whether this is due to my setup, or taking pictures in 'automatic' mode (without defining ISO, brightness, contrast, ...), atmosphere (very warm when pictures were taken) or the limits of my telescope (although naked eye observatory is quit good).

Future ideas / improvements

  • I need to improve the resolution (max resolution is 2592 x 1944, would much better than 640 x 480)
  • Definitely need to start experimenting with my camera settings to get better images
  • automated following / finding, although my Raspberry Pi setup is streaming so I can aim the telescope somewhat while looking at my laptop screen, it would be cool to punch in a celestial body to find and/or follow
  • touchscreen control on Raspberry Pi
  • Have the raspberry pi act as its own APD (or the laptop that is controlling the Raspberry Pi camera) for when I'm not within my home's WiFi range.


donderdag 9 april 2015

Solving pauzes in 3D print when using OctoPrint

After I installed OctoPrint on my Raspberry Pi 2 model B running Raspbian, my prints regularly paused, resulting in bad prints with lots of blobs.

When googling around for this, a lot of solutions came down to replacing a defective USB cable with a new one.  However, in my case I was sure that the issue was not caused by a bad USB cable as printing directly from laptop using the same USB cable went fine.

The solution to this problem simply came down to adding the following line to the /boot/config.txt file of my Raspbian install:


Please also read the following article providing some more information.

zondag 30 november 2014

From drift wood to tea light holder in 10 minutes flat

This summer, on the beach, I found a nice piece of drift wood that I brought home with me.

I let it dry for a few months and yesterday I transformed it in a tea light holder in just a few minutes.

I started out be positioning some tea lights on the wood to see what would look nice. I marked the location of the tea lights on the log and took it outside.

Once outside, I mounted a hole saw on my hand drill and carefully started to drill out the marked locations. I made sure I was not drilling whole the way through.  After this, I cleaned up the holes with a small chissel.

So after 10 minutes of work I had a nice present for my wife. :-)

donderdag 13 maart 2014

No POST / beep / boot after memory upgrade

I'm in progress of getting an old backup server back in service for taking backups of my fathers computer.  One of the upgrades, next to external storage, was to replace current 4GB memory with 4 x 4 GB memory DIMMS.

So after consulting the manual of my Asus M4A785TD-V EVO to see what memory was supported, I  bought a 16GB Corsair memory kit.

To my horror, after installing the DIMMS, the server no longer boots!!!!!!

So I tried all kinds of DIMM configurations, reset the CMOS, removed the motherboard battery, unplugged all devices, BIOS upgrade, ... all to no avail

Major panic, sweat, sickness, anger,....

Then I noticed after the n'th test that when inserting the new DIMM's a LED flashed on the motherboard.  Than it hit me, the DIMMS are situated next to the motherboard's power connector and when pushing on the power connector, it nudged itself slightly deeper into the socket.


TADAAAAA a working system!!!!

Finally I can continue setting up this system. Lesson learnt: always check all connectors.

maandag 6 januari 2014

Cubieboard based NAS


This is still a work in progress and if you got tips or comments, let me know.  I will update this blog post as I am further in my setup.

One of the downsides of using a Raspberry pi as a NAS solution is a somewhat low speed in transferring data.  This is partially caused by the fact that in my previous NAS setup I'm using external USB HD's.

I came across some the cubieboard and what jumped out to me in the specs is that it has a SATA connector on the board, so I immediately wanted to give it a try.

Through ebay I bought a 'Cubieboard A10 ARM Development board luxurious package'.  This kit contained a cubieboard one (developer edition), an enclosure, a 3.5" HDD addon board, a TTL to Serial cable, a breadboard with VGA connector, a uSD breakout PCB and a heatsink.  I was especially interested in the 3.5" HDD addon board as I am planning to combine the cubieboard with a Seagate 2TB SSHD.

To make this whole setup work I had to buy a microSD card to host the OS and an external power adapter (Ansmann APS 1500 traveller) to supply adequate power to the cubieboard and the HD.

Hardware setup

  1. Seagate 2TB SSHD 3.5"
  2. Cubieboard mounted in its enclosure
  3. 3.5" HD adapter
  4. external power supply (providing 12V, 1500mA)

Writing a linux image to the microSD card

The microSD card came with an adapter card that could easily be plugged into my computer.
I downloaded/unpacked the Cubian image and write it to the microSD card.

I first went for the Lubuntu image, but that starts a XWindows by default, which is too much overhead for what will essentially be a headless node.  Turning off the XWindows environment would be too much work so I decided to go for the Cubian image, which is a debian derivative.  As the raspberry pi NAS also uses a debain flavoured distro, I think this might be the safest path to take.

Wiring up the whole things boils down to:

  • plugging in the power adpater into the HDD adapter
  • running an USB to barrel connector cable fro mthe HDD adpater to the cubieboard
  • plugging the SATA connector in the SSHD drive
  • plugging the yellow/black cable of the SATA connector into the HDD adapter board's 12V OUT connector
  • plugging the SATA data cable and the 5V red/black cable into the cubieboard
  • plugging in the microSD card with the freshly written Lububntu image

Configuring Cubian

Changing keyboard settings
As I'm not living in the US, the default keyboard mapping needs to be changed. I tried
sudo dpkg-reconfigure keyboard-configuration
but that didn't help changing my keymap.

sudo apt-get install console-data

If this does not automatically starts the interface for setting your keymap, execute the following.

sudo dpkg-reconfigure console-data

Change the hostname:
sudo hostname cubienas

Updating the system

sudo apt-get update

sudo apt-get upgrade

Securing the cubieboard

Adjust Cubie user
The default user is 'cubie' with password 'cubie'.  So that definitely needed to change to start securing the cubieboard.  

Add new users
I added my own user to the system for 'day-to-day' access.  This same user is used on several of my systems.

SSH access
By default sshd is enabled but beware, cubian has sshd running on port 36000.  So for logging into the cubie NAS you need to define the port:
ssh <user>@<ip address of cubieboard> -p 36000

password-less SSH access
When enforcing ssh login without providing password you need to copy your public key to the cubieboard.  Unfortunately, ssh-copy-id assumes default port 22.  You can circumvent this, as indicated here, like so:
ssh-copy-id-i ~/.ssh/ "<user>@<ip address of cubieboard> -p 36000"

Disabling ssh for cubie user

Other security related configurations following o.a. this blog or this blog (last one is more specific to raspberry pi, but most things can be applied to the cubieboard).

Sharing the data

Preparing the SSHD
First thing to do is to foresee a file system for the hard drive:

sudo fdisk -l
sudo fdisk /dev/sda
sudo mkfs.ext3 /dev/sda1

Mount the hard drive

sudo mkdir /home/shares
sudo mkdir /home/shares/public
sudo cp /etc/fstab /etc/fstab.old
copy fstab file, just to be sure
sudo vi /etc/fstab
/dev/sda1  /home/shares/public  ext3 defaults  0  1
sudo apt-get install samba
sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.old
sudo vim /etc/samba/smb.conf

I had some trouble accessing my samba share but this is the current entry in smb.conf that works for me.

comment = disk
path = /home/shares/public
create mask = 0775
directory mask = 0775
browseable = yes
guest ok = yes
#valid users = @users
#force group = users
read only = no
public = yes
writable = yes

sudo service samba restart
restarts samba and activates the changes you added

sudo smbpasswd -a <username>
adds the day-to-day user to the samba users

I was able to mount the cubie NAS share automatically on my notebook by adding the following in /etc/fstab and running sudo mount -a afterwards:

// /home/someuser/central_storage/cubiedisk cifs username=sambauser,password=sambapassword 0 0

I also wanted to access the raspberry pi NAS from the cubieboard in a similar fashion to allow me to copy the content more easily. So I added the following to the cubienas' /etc/fstab:

// /home/someuser/central_storage/Disk1 cifs username=somePiUser,password=thePassowrd 0 0

However this did not initially work I had to install some extra software on the cubieboad to make it work:
sudo apt-get install ciffs-utils

After installing the ciffs-utils and running sudo mount -a, I had access to the raspberry pi's data.


First test I did was copy an  734MB iso file from my notebook to both the raspberry pi nas and the cubienas.
$ time cp ~/Downloads/ubuntu-12.04.4-desktop-amd64.iso ./cubiedisk/
real 6m31.366s
user 0m0.004s
sys 0m2.992s

time cp ~/Downloads/ubuntu-12.04.4-desktop-amd64.iso ./Disk1/
real 6m29.708s
user 0m0.000s
sys 0m2.888s

What?! It took approx as much time to copy it to the raspberry pi NAS setup as it did to copy it to the cubieboard.  The only explanation I have for this is that I'm connecting to these NAS setups via powerlan.  And that might just be too slow to make a difference when transferring data.

When I'm having my laptop connected to the switch close to the NAS setups these are the results:

$ time cp ~/Downloads/ubuntu-12.04.4-desktop-amd64.iso ./cubiedisk/
real 1m13.440s
user 0m0.020s
sys 0m4.916s

$ time cp ~/Downloads/ubuntu-12.04.4-desktop-amd64.iso ./Disk1/
real 1m41.975s
user 0m0.036s
sys 0m3.432s

When doing a similar test on the NAS' themselves these are the results:
$ time cp ./ubuntu-12.04.4-desktop-amd64.iso ./copy.iso
real 0m28.707s
user 0m0.080s
sys 0m10.910s

$ time cp ./ubuntu-12.04.4-desktop-amd64.iso ./copy.iso
real 1m38.976s
user 0m0.260s
sys 0m43.710s

Some other options to tests are:

  • Newer and (hopefully) better performing powerLAN devices.
  • Setup a wireless router connected to the switch next to the NAS setups.
  • See if mounting the disks using NFS might be better performing than mounting them as Samba mounts

Unresponsive CubieNAS

Each attempt at synching the cubieboard overnight with my other storage ended up with an unresponsive CubiebardNAS setup.  I could enter the necessary credentials for ssh, but I never get to a prompt.  After a few times even booting no longer succeeds.  The last message appearing on my screen is "Mali: Mali device driver loaded" and than nothing.  To be sure there was nothing else happening in the back ground I connected a UDB-serial cable to the cubieboards TTL connector and executed:

cu -s 115200 -l /dev/ttyUSB0

just after booting.  This showed me similar data as on the connected screen but it also showed

[ OK ] Activating lvm and md swap...done.
[....] Checking file systems...fsck from util-linux 2.20.1
/dev/sda1 contains a file system with errors, check forced.

and a progress bar showing the fsck progress.

So several cold reboots caused some errors on de file system.  So I guess I will need to be patient until the fsck is finished.

I continued to check the hard drive using the SMART disk monitoring tools, following this article. These tests did not turn up any hard drive problems, so basically cold rebooting the cubieboad NAS caused the file system errors. I haven't looked at setting up SMART as a daemon, but I'll investigate it in the future to have this setup on all my machines.

The next test I performed was to start syncing again between my raspberry pi NAS and the cubieboad NAS and redirecting all output to log files on the SATA drive.  If something was going to happen during sync I hoped the log files might contain some clues after I reboot the system.  But actually, after a lot of big syncs the cubieboard was still up and running.  So I guess the system freezes were caused by any output of the syncing not being redirected to output files.