Rubidium Reference – BITE

The Efratom LPRO-101 has a Built in Test Equipment (BITE) signal available on Pin 6. This pin is connected to the 5V logic within the module. When the BITE signal goes LOW (0V) then the physics engine has achieved lock within roughly +/-5×10-8 of it’s absolute frequency. Thankfully it can do this within 3-4 minutes of operation.

When I’m out in the field it is certainly useful to know what the reference is doing or if something has gone wrong without having to pull it apart and get out a multimeter. So on the front panel I’ve placed two LEDs one for power and the second to show lock.

The lock signal will be nothing more than the BITE signal inverted, which can be done with one transistor. I’ve seen some quite elaborate two and three transistor circuits, but we only really need one. The circuit I’ve draw below is straight out of my engineering log book, it’s so simple I couldn’t be bothered firing up Altium to draw it;

Basically we use one transistor to shunt the LED so that it is OFF while the BITE signal is HIGH. There is no rocket science here. With the heaters in the reference drawing 1.2A at startup throwing an additional 15mA through a transistor until it’s locked should be no big deal. The entire current drawn is approx 30mA, they are certainly bright enough in daylight, they might require turning down after using this at night, time will tell.

The circuit above is so simple I built it dead bug style on a piece of vero board. I did this so I could simply use double sided tape to hold it to the box and not short anything out.

One minor annoyance I’ve found is at the time power is applied the BITE output remains LOW for half a second or more before it goes HIGH. This means that the locked LED will light momentarily, then go out for 3-4 minutes as the reference warms before it lights again. The video below shows what I mean, for such a simple circuit I’m happy to put up with this feature;

You can hear the first click of the power supply, the Locked LED will light and go back out again. This was done when the reference was already warm so it takes less than 20s to regain lock again.

Anyway I’m certainly pleased with the simplicity. However now I’ve got ideas to use a micro a DAC and give this thing some intelligence. More notes in the log book for when I find time to come back to this again, for now it’s time to get out in the field and use it in anger !

Posted in EME

Rubidium Reference – The Retest

It can take a GPS disciplined oscillator a while to stabilise and settle down. When I first tested my new free running rubidium reference the GPS disciplined rubidium reference had spent no more than an hour making it’s observations and corrections. So I left it running over night with the intention of measuring things again in the morning.

So after 16 hours the frequency error has reduced more than three decades, should be good to go. I also have a precision TXCO reference (SDI FEL-10A) so I thought I’d measure this first and see what sort of stability and accuracy this can achieve. Both the free running TXCO and Rubidium were switched on 30 minutes and left to stabilise before measurements were made;

So that is quite a respectable result, being within +0.318Hz of our 10MHz target. Then for the main event it was time to re-measure the free running rubidium;

So this is a little higher that what was measured last night, but +0.009Hz or +9mHz is still a great result. To put this into perspective if I were to use this reference to lock a series of transverters this is the final frequency accuracy I would expect;

F(carrier) | F(error)
[MHz] | [Hz]
-----------+-----------
50.195 | +0.45Hz
144.135 | +1.30Hz
432.070 | +3.88Hz
1296.070 | +11.66Hz

I think if I were to go higher than 70cm then a GPS disciplined oscillator is in order (there is a Trimble Thunderbolt in a box somewhere), at least I have some idea now what the upper workable limit is. One of these days I may yet get in and tweak the external C-Field input and see if I can tighten this frequency error up a little, that will have to wait for a 12-digit counter.

The free running TXCO also has a reference input so for a laugh I attached the free running Rubidium to the TXCO and waited to see what happened. The lock LED lit pretty much instantaneously and the result was;

Exactly the same as the Rubidium on it’s own. What I do like about the TXCO is the 6 channel output with >120dB of isolation between channels. At least now I have some idea how stable this oscillator is, so now I can start thinking about what I’ll do with it.

Posted in EME

Rubidium Reference – Final Tests

Now the million dollar question is does it work ? Testing one of these rubidium references means you need a reference and counter that’s more accurate that the reference you’re trying to measure.

Fortunately one of my club members has a GPS disciplined Rubidium Oscillator that can attain some silly levels of stability and accuracy. Giving this device a few hours to watch satellites and let it discipline the internal oscillator is enough to then make some very accurate measurements. Even in the first 16 minutes this oscillator is able to achieve a frequency error less than what we need to make our measurements, after a further hour this number decreases yet another decade.

Once you have the uber accurate reference and accuracy you still need a counter with enough digits. This turns out to be something of a problem, all of the frequency counters I can find seem to stop at 8 digits. Which means you can only measure to the nearest hertz.

At work we have been cleaning up more than 25 years of Engineering mess and while we were cleaning we found a HP 5385A frequency counter stashed in a cupboard that no one knew was there, this particular counter can accept an external 10MHz reference. Combine this with a gate time of 10s it’s able to extend it’s display to a full 11 digits, meaning we can see down to the nearest milliHertz. So that just had to come home for the weekend to test it was working you see. They are actually reasonably priced on Ebay, so I can see a purchase coming on in the not too distant future.

So the measurement of my free running Rubidium reference is now rather simple. The GPS disciplined Rubidium drives the external reference of the HP 5385A counter, our test rubidium is then attached to the appropriate input. Then we need to give everything a good hour to reach thermal equilibrium and stablise. We can then make our final measurement.

I’ve not yet placed a thermocouple on the heat sink and made any measurements but it is certainly much cooler to the touch then when I ran it with just the enclosure.

So above is all of the test gear spread out on the kitchen table (shhh !) the GPS cable exits out a door so it can see the sky. The multimeter is reading the buffered Lamp Voltage, ideally this should be between 6-9 volts for a healthy Rubidium. Alas this rubidium probably has only a few years life left in it before it has to be refurbished.

However from this distance it’s a bit hard to read the counter, so here’s the closeup;

That is an awful amount of zeros, however it shows that my free running rubidium is running just +5.0 milliHz fast or +5.0×10^-9 Hz in scientific notation. Wow it works !

As you can see I’m now looking for that 12-digit frequency counter so that I can see just how good this rubidium is.

I’ve also read that it’s possible to trim the frequency of the 10MHz oscillator a little using the C-trim input pin (#7).. Hmm I guess that is how the GPS disciplined Rubidium does it !?! So with a multi-turn pot (10-20T) it may be possible to trim the frequency to be better than 1×10^-10 with luck and crossing of eye’s. However from what I’ve observed this may be pushing the limits of the thermal stability of these units and the error of the GPS disciplined oscillator will start to come into play.

Anyway I’m reasonably confident now that this Rubidium 10MHz reference will be able to keep my Elecraft K3 transceiver locked onto the right frequency for any EME experiments even in the dead of night.

Now I’ve just got to get the LEDs on the front panel working correctly and how I’m going to power this unit in the field. With a power supply requirement of 24V @ 0.45A this isn’t insignificant.

Posted in EME

Rubidium Reference – Front Panel

Usually I don’t bother making intricate front panels for my projects, but this reference just didn’t look right. At the front are two LEDs one for power and the other displays when the module achieves the atomic lock. On the rear is a SMA connector for the output along with power.

So for this project I decided to make a front panel, this Rubidium has some bragging rights after all. I’ve read a few blogs recently that suggested using a printable sticky label covered by one half of those non-heated laminate pouches. So a quick trip to the office supplies shop saw me come home with some Avery labels that take up roughly half a (A4) page and some pouches that are also sticky.

Not having any vector/raster tools on this computer saw me install Inkscape for the first time. I’m impressed, it wasn’t hard for the first time to use many of the functions your looking for are easily found. So the label I knocked together is below;

So through the laser printer it went and then laminated. A scalpel made quick work of the holes for the LED bezels. Then using two drills through the holes for alignment the label was carefully lowered onto the front panel and then pressed firmly but slowly onto the surface to prevent air bubbles. For those that were forced to contact their books for school would be well training in the appropriate technique, otherwise hit the scrap booking blogs and websites.

So here’s the final result;

I’ve since shown this to one of my fellow club members and he’s suggested next time I put a 2D bar code that links you to either Wikipedia or YouTube that then explains what a rubidium reference is. I could even refer them back to this blog… Hmm… I’m going to have to try that one day !

For now however my Rubidium reference has a front panel that says it’s all mine and explains the LED’s. I’m certainly happy with the result.

Posted in EME

Rubidium Reference – Thermal Management

These rubidium oscillators run hot, very hot. The Rubidium lamp chamber is heated to over +106°C before ignition occurs, the resonant cavity is kept at +70°C to maintain it’s thermal stability. This means that heat needs to go somewhere, usually to the ambient if we can.

So when I decided to mount my rubidium module to the bottom of my die-cast enclosure I’ve used silicon thermal transfer tape. This material is roughly 0.5mm thick, sticky on both sides and came in a 100x100mm sheet. This is thick enough so suck up any mechanical differences between the die-cast box and rubidium enclosure ensuring the thermal tapes makes contact. This material is typically available from Mouser, Digikey and Element14; however I purchased mine from our local electronics shop Jaycar (NM2790).

Would you believe in the rush I didn’t take any photo’s of this silicon thermal transfer tape being applied, maybe on the next unit I’ll remember !

A few back of the envelope calculations suggested that this material would achieve a worst case thermal resistance of 0.085°C/W, provided the mounting screws were done up tight. This then ensures the difference in temperature between the rubidium module and enclosure could be limited to less than 3°C (worst case).

So to satisfy my own curiosity I decided to mount the rubidium module to the die-cast enclosure without a heat sink and see how hot things got. After 30 minutes of continuous operation the enclosure over the top of the physics engine was found to be the hottest, reaching +40°C in an ambient of +25°C. In a home or lab this would probably be OK, but I’m intending to take this reference with me out into the field in ambient temperatures up to +50°C.

The reference guide recommends using a heat sink with a thermal resistance better than 2.0°C/W in these situations which sounds like a good idea. So just a back of the napkin double check;

Rth(Si) = 0.09°C/W   [silicon pad]
Rth(Al) = 0.008°C/W [die-cast box]
Rth(JG)= 0.25°C/W [jump grease]
Rth(HS) = 2.0°C/W [heat sink]
Tambient = +50°C [typical Australian Summer !]

Rth(total) = Rth(Si) + Rth(Al) + Rth(JG) + Rth(HS)
= 2.438°C/W

Pdiss = 28.8W (peak) 9.6W (average)

Trise = Pdiss * Rth(total)
= 28.8 * 2.438
= 67°C

Tmax = Tambient + Trise
= 50 + 67
= 117°C

OK so this will just scrape in under the typical +125°C limit for silicon devices within this rubidium module. Ditto on the capacitors.

Placing thermal paste between the heat sink and enclosure will also ensure the thermal dissipation is kept low. I prefer to call thermal paste jump grease. Since from the moment you open the tin it will somehow jump on to your elbow and then get everywhere. It’s tricky stuff to master.

I didn’t see any point placing this grease towards the bottom of the box, since the majority of the heat comes from under the physics engine. Once this was done then the heat sink was married up to the die-case enclosure, it’s a good sign when you can see the paste squeeze out from under the heat sink slightly.

This then just requires a bit more cleanup with Turpentine, the odourless stuff is best ! Just watch this stuff, since it has a habit of squeezing out for a while if applied too thick.

Posted in EME

Rubidium Reference – Machining

The Efratom LPRO-101 reference guide has the necessary drill pattern for mounting the reference oscillator within an enclosure. The one thing to watch, that caught me out, is the two screws in the middle are not on the centre line of the unit, it’s offset. It doesn’t look like it until it’s too late. So make sure you measure twice and drill once or you will write off a die-cast box or two.

This module is somewhat difficult to mount to a heat sink since the spacing of the mounting holes do not line up neatly with any heat sink profiles I could find. So instead I’ve mounted my module to the bottom of my die-cast enclosure with countersunk screws and will then mount the die-cast box to the heat sink. So the die-cast box is effectively sandwiched between the rubidium reference enclosure and heat sink.

As a graduate engineer I was once shown by a senior tech a great way of marking up and drilling die-cast boxes without marking the face. Basically you cover the areas where you want to drill holes with masking tape and use a pencil or drafting pen to mark the tape. You can then centre punch your holes, remove the tape and drill. Below is the bottom of my Hammond 1590D enclosure marked out with the holes for the Rubidium reference.

Here I’ve drilled the mounting holes for the Rubidium for a test just prior to making the decision to drill the heat sink holes. After drilling and tapping all necessary holes the box and lid received two coats of etch primer and then two coats of gloss black. There are times I just hate gloss black, it shows all the imperfections and it is so easy to mark. I’ve learnt that if you want a good finish, make sure you spray and bake the final coat in a small toaster oven set to 70-80°C for an hour. So after painting it looked like this;

Paint has a terrible thermal conductivity, so I’ve taken the time to mask off the top of the box so I can put thermal paste (white goo aka jump grease) between the heat sink and box at final assembly. Above you can see the black heads of the 1/2″ 4-40 UNC 2B screws required to pull the rubidium up against the lid. In the thermal management section I’ll talk a little more about how I’m going to get the heat out of this module. This is what it looks like when turned over;

If you look closely you’ll see it’s centred within the enclosure, which means I was paying attention to the two holes in the middle of the enclosure being offset (*grin*). There are also holes in either end of the enclosure for LED’s, SMA connector and power to be connected when final wiring takes place.

Once the body of the box had been done I could turn my attention to the heat sink that mounts on top. Again I used my tape mask trick to mark and drill the holes that went between the fins. Each of these holes was tapped with a M3 thread so that screws could be mounted without the aid of nuts and washers.

The heat sink unfortunately was a little large and had to be cut down. I am luck to have a workshop at work with an engineering band-saw fitted with a bi-metal blade. So it wasn’t difficult to cut the heat sink down to the right size and then repaint. One of these days I must learn how to do black anodising with dye. So dry assembled we get this effect;

Which looks rather snazzy. Now to finish off the thermal design.

Posted in EME

Rubidium Reference – Initial Tests

It is always a good idea to test surplus gear, before trying to mount it in a box. This unit can be tested without a heat sink for periods up to 30 minutes. So I started by making a very simple loom to connect power, monitor the BITE and LAMP VOLT outputs and feed the RF output into my spectrum analyser. Thankfully there is a label on the side of the unit that has all of the information that we need to wire it up.

When powered from cold the unit draws 1.2A at 24V, it heats up for 1-2 minutes and then the current begins to drop. Once unit has warmed up (keeping in mind the Rb chamber is +106degC) the unit will achieve atomic lock and the BITE output drops to zero. Once the unit has reached thermal equilibrium the current drawn falls back to 0.4A or there about.

It should be no surprise that the output of the module was measured at +7dBm and that the frequency was bang on 10.0000MHz which is the limit of my Spectrum analyser internal resolution.

The LAMP VOLT output requires a special mention since it can be used to estimate the remaining life within the physics engine. As the Rubidium lamp ages it’s output level drops until eventually the unit can no longer achieve atomic lock. A good or healthy Efratom LPRO-101 should output between 6-9V, below 3V they do not lock. The unit I have outputs 4.6V, so it is definitely used and perhaps a few years of continuous use away from the end of it’s life. So used sparingly it should certainly last me a good many years. I will however be out looking for a spare in case I need a replacement, time to hit Ebay.

There are two very good repair guides available on the internet that are not hard to find;

  • “Erfratom LPRO-101 Repair Reference Guide” – Fred de Vries PE1FBO
  • “Efratom Model FRS-C 10MHz Rubidium Clock” – Gerald Molenkamp VK3FGJM

I cant thank both authors enough for sharing their experiences with repairing these units. Once I obtain another unit I may very well be confident to attempt repairing one of my units and “refurbishing” the Rb lamp.

Posted in EME

Rubidium Reference – Spot On !

Being on the right frequency at the right time to make a QSO is always important. Certainly in these modern times of ultra narrow weak signal digital modes this couldn’t be more true.

Recently I was searching through a box marked “various projects” when I uncovered a Rubidium frequency reference that I’d purchased some time ago and squirrelled away for a rainy day. Now that I’ve rekindled an interest in VHF weak signal digital modes it seemed an appropriate time to finally do something with it.

So continuing to rummage around in the “surplus, half completed and one day” project boxes I managed to find a unused heat sink and Hammond 1590D die-cast box that would easily house this project. So with nothing more to purchase I could simply put it together.

Efratom LPRO-101 Rubidium Reference

The Rubidium frequency reference I have is the Efratom LPRO-101 made in the USA. These units were all the rage for a while on places like Ebay and were apparently removed from mobile telephony bases. With a design life of 10 years continuous use before requiring replacement it’s a bit of a gamble on the remaining life you’ll achieve once built. However I’m sure that for intermittent use this will last me a number of years.

There is a heap of information on the inter-webs about these references. There are many others that have made their own frequency references from these devices, the links below are how I put mine together YMMV.

The links above will be completed as I go. However below is a teaster of how the front panel of the unit looks already;

More to come !

GPSd and the HP un2420

At a recent radio club technical night we ran through the setup of ntpd and GPSd for time syncing laptops. This is important when running modes like FT8 and JT65 where transmissions are synchronised to the nearest second, or for satellite tracking.

Picture of HP2420 Modem

During the tech night we used a external USB GPS, however my laptop has a HP un2420 broadband modem inside that includes a built in GPS. So after the tech night I decided to see if I could get GPSd to work with this module.

In a previous post I found that you could send a string to the last of three USB serial ports that this module creates [ttyUSB0-2], that would then activate the GPS functions within the module you can read this here (click).

So to use this module we need GPSd to send a “\$GPS_START” string to the GPS before it tries to use it. It also needs to send a “\$GPS_STOP” string to the GPS when GPSd stops.

It turns out GPSd has internal mechanisms to do this via a device-hook that you can find in the man page, however there aren’t many examples of “how” to do this on the internet.

The device hook file is nothing more than a simple bash script that is called by GPSd as it starts or stops the GPSd service. It will call this bash script using two parameters, the first is the name of the device, the second is the action required i.e.”activated” or “deactivated”. So all we need is a basic script, there are probably more elegant ways to write this script than what I’ve used, but it works for me.

So using your favourite editor create the file below with the following contents;

/etc/gpsd/device-hook

#!/bin/bash
#
#device hook script to start and stop HP2420 internal GPS
#
if [ "$1" = "/dev/ttyUSB2" ] && [ "$2" = "ACTIVATE" ];
then
echo "\$GPS_START" > "/dev/ttyUSB2"
sleep 5
else
if [ "$1" = "/dev/ttyUSB2" ] && [ "$2" = "DEACTIVATE" ];
then
echo "\$GPS_STOP" > "/dev/ttyUSB2"
fi
fi

This script simply matches the USB serial device the HP un2420 creates with the word ACTIVATE and fires the magic string into the USB serial device and will return 0 to GPSd. The same happens when GPSd wishes to stop the GPS device. These internal GPS devices do not like starting then immediately stopping, it can bork the device to the point it requires the laptop to be rebooted. So to prevent this a short sleep delay has been added just after we activate the GPS. I could have equally added it after or before the STOP command, but this might not be a good idea as laptops have a tendency to hibernate and we would like the GPS to stop.

Now that we have our script we need to make sure it’s executable by GPSd. I found that if you start GPSd and don’t let it daemonise for debugging, it will tell you which user and group that it starts with, we just need to make our permissions match;

$ sudo gpsd -N -D3 -F /var/run/gpsd.sock /dev/ttyUSB2
gpsd:INFO: launching (Version 3.17)
gpsd:INFO: listening on port gpsd
gpsd:INFO: stashing device /dev/ttyUSB2 at slot 0
gpsd:INFO: running with effective group ID 20
gpsd:INFO: running with effective user ID 122

gpsd:INFO: startup at 2019-03-07T23:52:07.000Z (1552002727)

I’ve highlighted the two lines we’re looking for. We can go and match these ID numbers to the specific user and group in the /etc directory. If you press Ctrl-C then GPSd will stop. Looking at the ID’s on my laptop this was user ‘gpsd’ and group ‘dialout’, YMMV.

So now we can set the right owner and permissions for our device-hook file;

$ sudo chown root:dialout /etc/gpsd/device-hook
$ sudo chmod 750 /etc/gpsd/device-hook
$ ls
legend@HP-ProBook:/etc/gpsd$ ls -al
total 20
drwxr-xr-x   2 root root     4096 Mar  8 09:54 .
drwxr-xr-x 130 root root    12288 Mar  8 00:06 ..
-rwxr-x---   1 root dialout   280 Mar  8 09:54 device-hook

Basically owner is left as root and we’ve given read and execute permissions to group dialout. This will allow GPSd to read the file and only sudo users able to edit it.

So using the same command line as before start GPSd in a window. Now in a second window launch a client like cgps. In the GPSd window we should see something like this;

legend@HP-ProBook:$ sudo gpsd -N -D3 -F /var/run/gpsd.sock /dev/ttyUSB2
gpsd:INFO: launching (Version 3.17)
gpsd:INFO: listening on port gpsd
gpsd:INFO: stashing device /dev/ttyUSB2 at slot 0
gpsd:INFO: running with effective group ID 20
gpsd:INFO: running with effective user ID 122
gpsd:INFO: startup at 2019-03-07T23:52:07.000Z (1552002727)
gpsd:CLIENT: => client(0): {"class":"VERSION","release":"3.17","rev":"3.17","proto_major":3,"proto_minor":12}\x0d\x0a
gpsd:CLIENT: <= client(0): ?WATCH={"enable":true,"json":true};\x0a
gpsd:INFO: running /etc/gpsd/device-hook /dev/ttyUSB2 ACTIVATE
gpsd:INFO: /etc/gpsd/device-hook returned 0

gpsd:INFO: SER: opening GPS data source type 3 at '/dev/ttyUSB2'
gpsd:INFO: SER: speed 9600, 8N1
gpsd:INFO: attempting USB device enumeration.
gpsd:INFO: 8087:0020 (bus 2, device 2)
gpsd:INFO: 1d6b:0002 (bus 2, device 1)
gpsd:INFO: 05c8:0403 (bus 1, device 4)
gpsd:INFO: 03f0:251d (bus 1, device 8)
gpsd:INFO: 8087:0020 (bus 1, device 2)
gpsd:INFO: 1d6b:0002 (bus 1, device 1)
gpsd:INFO: vendor/product match with 091e:0003 not found
gpsd:INFO: SER: speed 9600, 8O1
gpsd:INFO: SER: speed 9600, 8N1
gpsd:INFO: SER: speed 9600, 8N1
gpsd:INFO: SER: speed 9600, 8N1
gpsd:INFO: gpsd_activate(2): activated GPS (fd 8)

< BIG SNIP>

^Cgpsd:WARN: received terminating signal 2.
gpsd:INFO: closing GPS=/dev/ttyUSB2 (8)
gpsd:INFO: running /etc/gpsd/device-hook /dev/ttyUSB2 DEACTIVATE
gpsd:INFO: /etc/gpsd/device-hook returned 0

gpsd:WARN: exiting.

The two lines we need to find I’ve highlighted above. Basically we want to see GPSd execute our script with a return value of 0 (success). I’ve snipped a sizeable amount of information out of the above window to make it more readable. You should also see where I’ve hit Ctrl-C which generates a warning to cgps that GPSd has shutdown, which is neat !

Ok so now we have GPSd starting and stopping the GPS device in my laptop correctly. However this is not the end of the story, laptops are able to be suspended so we need to take care of this as well. So using your favourite editor create/edit the following file;

/etc/pm/sleep.d/96_gpsd

#!/bin/bash
#
# what we want done with our GPS in the laptop
case "$1" in
hibernate)
#stop GPSd
systemctl stop gpsd.socket
systemctl stop gpsd
;;
suspend)
#stop GPSd
systemctl stop gpsd.socket
systemctl stop gpsd
;;
restart)
#restart GPSd
systemctl restart gpsd
;;
esac

Thankfully as soon as we tell GPSd to stop it calls /etc/gpsd/device-hook and DEACTIVATES the GPS module for us. Now we also need to set the permissions correctly;

legend@HP-ProBook:/etc/pm/sleep.d$ chmod 755 96_gpsd
legend@HP-ProBook:/etc/pm/sleep.d$ ls -al
total 20
drwxr-xr-x 2 root root 4096 Mar  8 11:09 .
drwxr-xr-x 3 root root 4096 Apr 27  2018 ..
-rwxr-xr-x 1 root root  273 Mar  8 11:09 96_gpsd

Testing of this script is as simple as calling it with the correct first parameter. Testing that our distros are calling this file is a little harder and may be the subject of yet another post. I’m thinking that I need to measure if there is a performance difference with the GPS running while hibernated or not, this sounds easy but will take many hours. Still pondering.

There we go, the internal GPS within the un2420 should now be available, it would be worth rebooting your machine to make sure everything is working well.

MoonSked and Ubuntu 18.04LTS

Recently I was indoctrinated into the world of 6m EME when a few club members and I decided to give it a try on something of a whim. With a bit of encouragement from Lance W7GJ we raided and cherry picked our way through a few fellow club members shacks and sheds and pieced together a “small” portable 6m EME station. You can read about the activation on our club website once it’s published (click). The picture below speaks volumes;

The moon at moon set (4am) with our 6m EME station – photo by Scott VK5TST

While looking at various Apps and trying to work out how this EME thing works, I discovered MoonSked written by David GM4JJJ.

At first glance it appeared to be a cross platform application that would help me plan and understand how this EME thing works without wasting too many late nights outside. What I liked most is I could run it on both Windows or Linux. My main computer in the shack still runs Windows (for reasons), however for laptop(s) and servers I prefer various flavours of Linux. So the installation of MoonSked on my main shack computer was straight forward, however things rapidly fell apart when I tried the same on my Laptop that runs Ubuntu 18.04LTS. I downloaded the zip file, placed it in my home directory and then tried to run it, sigh it didn’t work.

After a quick check of the website I noticed the last version of Ubuntu that MoonSked was built to run on was 9.10 (karmic koala) which went end of life years ago (2013). Being a binary distribution means recompiling and linking this against 64-bit libraries was not an option, sigh; we had to do this the old fashioned hard way.

So having grown up using Linux for more years than I’d care to admit I had a fair idea that this would be the classic “shared library dependency problem”. I wasn’t to be disappointed and even learnt a little about how the new linux multiarch (well new to me) system worked.

So the crux of the problem was MoonSked was compiled against 32-bit binary libraries and my Ubuntu 18.04LTS distro is entirely 64-bit. It is little wonder that MoonSked couldn’t run. So the place to start with any dependency problem is the infamous ‘ldd utility’. Let’s poke inside MoonSked and see what libraries are under the hood;

legend@HP-ShackBook:~/MoonSked$ ldd MoonSked
linux-gate.so.1 (0xf7f48000)
libgtk-x11-2.0.so.0 => not found
libgdk-x11-2.0.so.0 => not found
libgmodule-2.0.so.0 => not found
libglib-2.0.so.0 => not found
libgthread-2.0.so.0 => not found
libgobject-2.0.so.0 => not found
libgdk_pixbuf-2.0.so.0 => not found
libpango-1.0.so.0 => not found
libpangocairo-1.0.so.0 => not found
libpangoft2-1.0.so.0 => not found

libpthread.so.0 => /lib32/libpthread.so.0 (0xf7f07000)
libdl.so.2 => /lib32/libdl.so.2 (0xf7f02000)
libXi.so.6 => not found
libXext.so.6 => not found
libX11.so.6 => not found

libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7d7c000)
libm.so.6 => /lib32/libm.so.6 (0xf7cb1000)
libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf7c93000)
libc.so.6 => /lib32/libc.so.6 (0xf7aba000)
/lib/ld-linux.so.2 (0xf7f4a000)
libcairo.so.2 => not found

Ok so there are a few libraries missing and thankfully I can see some of the lib32 libraries are being found. What is not immediately apparent is that 32-bit libraries can be installed separately and sit alongside the very same 64-bit libraries. The multiarch features of the latest linux kernel and GNU tools is what confuses MoonSked trying to find it’s libraries. So to get MoonSked we need to solve the shared library dependencies separately. So watch the following carefully.

We start by double checking that we are in fact running a full 64-bit system;

legend@HP-ShackBook:~/MoonSked$ uname -m
x86_64
legend@HP-ShackBook:~/MoonSked$ dpkg --print-architecture
amd64

Excellent the kernel is 64-bit and we are using the 64-bit package repository that should be linked against 64-bit libraries. Now we check the following;

expert@HP-ShackBook:~/MoonSked$ dpkg --print-foreign-architectures
i386

Ah Ha ! This is excellent as it means that we can install the 32-bit libraries with the dpkg/apt tools without having to configure dpkg. If you find that i386 isn’t defined as a foreign architecture you’ll need to use dpkg to enable it. There are plenty of websites on the net that can assist here (YMMV), Ubuntu 18.04LTS comes pre-configured for 32-bit and 64-bit multiarch out of the box.

So now we can simply use apt-get to install the dependencies. I simply use a process of elimination to work out what is missing. First I’d use apt-cache and the name of the shared lib to search for library names or resort to the internet, then I’d use apt-get to install it and then re-run ldd again to see the result. The following line works well when the output from ‘ldd’ gets more than a page or two;

$ ldd MoonSked | grep "not found"

This will basically print out any library dependency that was not found to the display. Slowly but surely you work your way through to the end of your list, making notes as you go for your blog (*grin*). Rather than document all of the above steps I’ll just give you the short list;

sudo apt-get install libc6:i386 libpango-1.0:i386 libcairo2:i386 libpangocairo-1.0:i386 libgtk2.0-0:i386 libcanberra-gtk-module:i386 libatk-adaptor:i386 gtk2-engines-murrine:i386 libdlm3:i386

Now the observant will notice at the end of each package is a colon and i386. This tells apt/dpkg to install the 32-bit library and not the default 64-bit package. Depending on what apps you have on your linux machine already some of these packages may already be installed and up to date. If you do find this is the case then simply drop the name off the list above and keep trying.

As I wrote at the very beginning of this post, these are the steps that worked for me on my Ubuntu 18.04LTS installation. I’m hoping that the process used to seek and destroy the missing dependencies makes sense it’s certainly not the only way to do it, works for me YMMV.

At least now I can fire up MoonSked on Ubuntu 18.04LTS and continue my 6m EME experiments. Thanks again to David GM4JJJ for writing MoonSked !