Archive for the ‘radio’ Category

Contest Morse Code, Computers, and an Icom Rig

This past weekend (third full weekend in February, February 15-16, 2020) is the ARRL International CW Contest (ARRL DX CW link: http://www.arrl.org/arrl-dx ). This is interesting to my study of radio signal propagation as a columnist and as an amateur radio operator​ because of the contest objective: “To encourage W/VE stations to expand knowledge of DX propagation on the HF and MF bands…” This contest is a good way to get a feel for current propagation–though there are caveats.

Speaking of Morse code and the CW mode on our amateur bands: those of you using CW during contests, do you send by hand or by computer?  Do you copy the code by head, or do you use a computer for decoding?

Do you use a computer for Morse code operation?

Just curious about those of you who use CW. Do you send by hand or computer? Receive by head or computer?

In most contests like the ARRL DX CW contest, I copy by ear, and send mostly by rig keyer. If needed, I use a single paddle key with the Icom rig’s internal keyer to answer unique questions and so on.

Below is a quick demo of using the internal Morse code keyer in my Icom IC-7610 transceiver.

V47T, in the Saint Kitts and Nevis Island in the Caribbean, is calling CQ TEST in the ARRL DX CW contest.

Using the programmable virtual buttons, in which I programmed my callsign, NW7US, and other info, I answer and make a complete contest QSO.

In activity like the Straight Key Century Club (SKCC – https://SKCCGroup.com) K3Y special event, it is all manual. I send my Morse code using a WWII Navy Flameproof Signal Key, and decode with my ears.  It is contextual for me.

How do you do contesting Morse code?  Bonus question: How do you do logging while doing contest operation?

73 es best dx = de NW7US dit dit

 

How Did You Fare in CQ WW CW Contest Weekend?

Man, lots and lots of Morse code on the ham bands, this weekend. The CQ Worldwide CW Contest weekend was hopping with signals!

How did you do this weekend? How were conditions on the various contest bands?

Comment here and your report may make it into the propagation column in an upcoming edition of the Radio Propagation column in CQ Amateur Radio Magazine.

Here are a few moments as heard at the station of the CQ Amateur Radio Magazine propagation columnist, in Lincoln, Nebraska (yeah, that’s me, NW7US).

Here are the results of my dabbling with the Icom rig and this contest:

 NW7US's Contest Summary Report for CQ-WW
 Created by N3FJP's CQ WW DX Contest Log
 Version 5.7  www.n3fjp.com

 Total Contacts = 55
 Total Points = 8,979

 Operating Period: 2019/11/24 10:23 - 2019/11/24 22:51

 Total op time (breaks > 30 min deducted): 3:58:46
 Total op time (breaks > 60 min deducted): 4:45:17

 Avg Qs/Hr (breaks > 30 min deducted): 13.8


 Total Contacts by Band and Mode:

 Band       CW   Phone     Dig   Total       %
 ----       --   -----     ---   -----     ---
   80        8       0       0       8      15
   40        7       0       0       7      13
   20       25       0       0      25      45
   15       15       0       0      15      27
            --   -----     ---   -----     ---
 Total      55       0       0      55     100

 Total Contacts by State \ Prov:

 State       Total     %
 -----       -----   ---
                52    95
 HI              3     5

 Total = 1


 Total Contacts by Country:

 Country                      Total     %
 -------                      -----   ---
 Canada                           6    11
 Brazil                           5     9
 USA                              5     9
 Argentina                        3     5
 Costa Rica                       3     5
 Hawaii                           3     5
 Bonaire                          2     4
 Cayman Is.                       2     4
 Chile                            2     4
 Cuba                             2     4
 Japan                            2     4
 Mexico                           2     4
 Aruba                            1     2
 Bahamas                          1     2
 Barbados                         1     2
 Belize                           1     2
 Curacao                          1     2
 Dominican Republic               1     2
 French Guiana                    1     2
 Haiti                            1     2
 Honduras                         1     2
 Martinique                       1     2
 Montserrat                       1     2
 Nicaragua                        1     2
 Senegal                          1     2
 St. Kitts & Nevis                1     2
 St. Lucia                        1     2
 Suriname                         1     2
 US Virgin Is.                    1     2
 Venezuela                        1     2

 Total = 30


 Total DX Miles (QSOs in USA not counted) = 151,407
 Average miles per DX QSO = 3,028


 Average bearing to the entities worked in each continent.
 QSOs in USA not counted.

 AF =  83
 AS = 318
 NA = 124
 OC = 268
 SA = 137


 Total Contacts by Continent:

 Continent   Total     %
 ---------   -----   ---
 NA             32    58
 SA             17    31
 OC              3     5
 AS              2     4
 AF              1     2

 Total = 5


 Total Contacts by CQ Zone:

 CQ Zone   Total     %
 -------   -----   ---
 08           13    24
 03            7    13
 09            7    13
 07            6    11
 11            5     9
 13            3     5
 31            3     5
 04            2     4
 05            2     4
 06            2     4
 12            2     4
 25            2     4
 35            1     2

 Total = 13

From Lightning Comes a New Icom IC-7610 (First Transmission)

Wow. What a radio!

One of the most useful (and, to me, amazing) features of this Icom IC-7610, is the IP+ function, which, when turned on, improves the Intermodulation Distortion (IMD) quality by optimizing the direct sampling system performance. This function optimizes the Analog/Digital Converter(ADC) against distortion when you receive a strong input signal. It also improves the Third-order Intercept Point (IP3) while minimizing the reduction of the receiver sensitivity.

In short: I was listening to an s-0 (i.e., no strength-meter movement) weak signal of a DX station, when right adjacent to the frequency came an s-7 signal, wiping out my ability to copy that weak signal. I turned on the IP+ and the distortion of the adjacent signal disappeared, and once again, I heard the weak signal IN THE CLEAR! WOW!

This video is a quick capture of my running the Olivia Digital Mode on HF, on the 30-Meter band. The transmissions are of a two-way Olivia digital-mode radio conversation between station K8CJM and station NW7US on 12 November 2019 (UTC date). K8CJM is located in Dayton, Ohio, and I am located in Lincoln, Nebraska. I’m running the radio at full power. The radio is rated as being able to handle 100% duty cycle at full power. The radio ran cool, no significant heating.

A few months ago, a lightning strike took out my ham radio station. The antenna was NOT connected, but I did not unplug the power supply chain and my computer from the wall. The surge came in through the power mains, and fried my uninterruptable power supply, the interfaces between my PC and radio, and fried the radio. Thankfully, all of that was covered by my homeowner’s insurance policy, less the steep deductible. My insurance covered all of the blown items, and that provided me this chance to obtain a repack version of the Icom IC-7610. I bought an extended four-year warranty.

CAUTION: Check the documentation of your transceiver/transmitter. NEVER run your radio’s power out at a level that exceeds what it can handle in reference to the duty cycle of the mode you are using. Olivia, for instance, is a 100-percent duty cycle mode. Morse code is NOT quite 100% duty cycle. Nor is SSB, a mode that operates with a duty cycle much lower than 100%. Your radio’s manual should tell you the specifications regarding the duty cycle it can handle! If you run more power than your radio can handle with the given duty cycle of the mode in use, you will blow your radio’s finals or in some other way damage the radio! Beware! I’ve warned you!

Compression and ALC!?

Some have noted that it appears that I’ve left on the Compression of the transmitted audio. However, the truth is that compression was not being used (as is proof by carefully taking note of the zero meter movement of the Compression activity). I had the radio set for 20-Meter USB operation on the Sub VFO. Compression was set for standard USB operation. Note also that the radio was transmitting USB-D1, which means the first data/soundcard input to the radio.

Also, some people complain about my use of ALC, because, in their view, ALC (automatic level control) is a no-no for data modes.

The notion that one must NEVER use ALC when transmitting digital modes is not accurate.

Multi-frequency shift keyed (MFSK) modes with low symbol rate–such as the Olivia digital modes–use a single carrier of constant amplitude, which is stepped (between 4, 8, 16 or 32 tone frequencies respectively) in a constant phase manner. As a result, no unwanted sidebands are generated, and no special amplifier (including a transmitter’s final stage) linearity requirements are necessary.

Whether the use of ALC matters or not depends on the transmitted digital mode.

For example, FSK (Frequency-Shift Keying; i.e., RTTY) is a constant-amplitude mode (frequency shift only). In such a case, the use of ALC will NOT distort the signal waveform.

PSK31 does contain amplitude shifts, as an example, therefore you don’t want any ALC action that could result in distortion of the amplitude changes in the waveform.

On the other hand, the WSJT manual says that its output is a constant-amplitude signal, meaning that good linearity is not necessary. In that case, the use of ALC will NOT distort the transmitted signal-amplitude waveform. You can use ALC or not, as you choose when you run WSJT modes, or Olivia (MFSK).

Clarification

Nowhere in this am I advocating running your audio really high, thinking that the ALC will take care of it. I am not saying that. I am saying that some ALC is not going to be an issue. You MUST not overdrive any part of the audio chain going into the transmitter!

Transmit audio out of the sound card remains at a constant amplitude, so there will be no significant change in power output if you adjust your input into the radio so that the ALC just stops moving the meter, or, you can have some ALC meter movement. You can adjust your audio to the transmitter either way.

If the transmitter filters have a significant degree of ripple in the passband then you may find that RF power output changes with the selected frequency in the waterfall when there is no ALC action. Allowing some ALC action can permit the ALC to act as an automatic gain adjustment to keep the output power level as you change frequencies.

Linear and Non-Linear

Regarding linear and non-linear operation (amplifiers, final stages): While a Class-C amplifier circuit has far higher efficiency than a linear circuit, a Class-C amplifier is not linear and is only suitable for the amplification of constant-envelope signals. Such signals include FM, FSK, MFSK, and CW (Morse code).

If Joe Taylor’s various modes (in WSJT software) are constant-envelope signals, than class-C works, right? At least, in theory.

Some Additional Cool History

The digital mode, Thor, came out of DominoEX when FEC was added. Here is an interesting history of FSQ that seems to confirm that FSQ is like MFSK, so no problem with a bit of ALC.

The following is from https://www.qsl.net/zl1bpu/MFSK/FSQweb.htm

History – Let’s review the general history of Amateur MFSK modes. The first Amateur MFSK mode developed anywhere was MFSK16, specified by Murray Greenman ZL1BPU, then first developed and coded by Nino Porcino IZ8BLY in 1999. Before MFSK16 arrived, long-distance (DX) QSOs using digital modes were very unreliable: reliant, as they were, on RTTY and later PSK31. MFSK16 changed all that, using 16 tones and strong error correction. Great for long path DX, but nobody could ever say it was easy to use, never mind slick (quick and agile)!

Over the next few years, many MFSK modes appeared, in fact too many! Most of these were aimed at improving performance on bands with QRM. Most used very strong error correction, some types a poor match for MFSK, and these were very clumsy in QSO, because of long delays.

The next major development, aimed at easy QSOs with a slick turnaround, was DominoEX, designed by Murray Greenman ZL1BPU and coded by Con Wassilieff ZL2AFP, which was released in 2009. Rather than using error correction as a brute-force approach, DominoEX was based on sound research and achieved its performance through carefully crafted modulation techniques that required no error correction. The result was a simpler, easier to tune, easily identified mode with a fast turn-around.

DominoEX is widely used and available in many software packages. A later development by Patrick F6CTE and then Dave W1HKJ added FEC to this mode (THOR) but did not add greatly to performance, and at the same time eroded the fast turn-around. The final DominoEX- related development was EXChat, a version of DominoEX designed specifically for text-message style chatting. While completely compatible with DominoEx, it operates in ‘Sentence Mode’, sending each short over when the operator presses ENTER. EXChat was developed by Con ZL2AFP and released in 2014.

Back in 2013, Con ZL2AFP developed an MFSK mode for LF and MF which used an unusual decoding method pioneered by Alberto I2PHD: a ‘syncless’ decoder, which used a voting system to decide when one tone finished and another began. The first use of this idea was in JASON (2002), which proved to be very sensitive, but very slow, partly because it was based on the ASCII alphabet. The new mode, WSQ2 (Weak Signal QSO, 2 baud) combined the syncless decoder with more tones, 33 in total, and an alphabet specially developed by Murray ZL1BPU, which could send each lower case letter (and common punctuation) in just one symbol, resulting in a very sensitive (-30 dB SNR) mode with a 5 WPM typing speed.

In the subsequent discussion in late 2014, between the developers ZL2AFP and ZL1BPU, it was realized that if the computer had enough processing power to handle it, WSQ2 could be ‘sped up’ to become a useful HF chat mode. This required a large amount of development and retuning of the software to achieve adequate speed was involved, along with much ionospheric simulator and on-air testing used to select the most appropriate parameters.

Tests proved that the idea not only worked well, but it also had marked advantages over existing HF MFSK modes, even DominoEX. As expected, the new mode was found to have superior tolerance of signal timing variation, typically caused by multi-path reception, and would also receive with no change of settings over a wide range of signaling speeds.

So this is how FSQ came about. It uses the highly efficient WSQ character alphabet, IFK+ coding, the same number of tones as WSQ (33), but runs a whole lot faster, up to 60 WPM, and uses different tone spacing. The symbol rate (signaling speed) is modest (six tones per second or less), but each individual tone transmitted carries a surprising amount of information, resulting in a high text transmission speed. And it operates in ‘Chat’ (sentence) mode, which allows the user to type as fast as possible since they type only while receiving.

The ability to send messages and commands selectively has opened a huge array of communications possibilities.

What Makes FSQ Different

Incremental Keying – FSQ uses Offset Incremental Frequency Keying (IFK+), a type of differential Multi-Frequency Shift Keying (MFSK) with properties that make it moderately drift-proof and easy to tune. IFK+ also has excellent tolerance of multi-path reception.

IFK was developed by Steve Olney VK2XV. IFK+ (with code rotation) was proposed by Murray Greenman ZL1BPU and first used in DominoEX. IFK+ prevents repeated same tones without complex coding and provides improved rejection of propagation-related inter-symbol interference. In the context of sync-less decoding, the IFK+ code rotation also prevents repeated identical tones, which could not have been detected by this method.

Efficient Alphabet – In FSQ, a relatively high typing speed at a modest baud rate comes about because the alphabet coding is very efficient. All lower case letters and the most common punctuation can be sent in just one symbol and all other characters (the total alphabet contains 104 characters) in just two symbols. (The alphabet is listed below). This is a simple example of a Varicode, where it takes less time to send the more common characters. The character rate is close to six per second (60 WPM), the same as RTTY, but at only 1/8th of the baud rate. (RTTY has only one bit of information per symbol, 7.5 symbols per character, and wastes a third of its information on synchronization, and despite this, works poorly on HF).

No Sync – Another important factor in the design of FSQ is that no synchronizing process is required to locate and decode the received characters. Lack of sync means that reception is much less influenced by propagation timing changes that affect almost all other modes since timing is quite unimportant to FSQ; it almost completely eliminates impulse noise disruption, and it also contributes to very fast acquisition of the signal (decoding reliably within one symbol of the start of reception). Fast acquisition removes the need for the addition of extra idle characters at the start of transmission, and this leads to a very slick system. Add high resistance to QRM and QRN, thanks to the low baud rate, and you have a system so robust that it does not need error correction.

Cool.

See you on the bands!

Ham Radio Operating Ethics and Operating Procedures

In 2008, John Devoldere, ON4UN, and, Mark Demeuleneere, ON4WW, wrote a comprehensive document entitled “Ethics and Operating Procedures for the Radio Amateur.” The purpose of this document was for it to become a universal guide on operating ethics and procedures.

This document was accepted by the IARU (International Amateur Radio Union) Administrative Council as representing their view on the subject. During subsequent Regional IARU meetings it was emphasized that the document be made available to the Amateur Radio Community via all available means, at no cost, and in as many languages as possible.

The document has since been translated into more than 25 languages. In some countries, the document is also offered in printed format and many Amateur Radio websites have a link to the document. Our most sincere thanks go to all our friends who spent hundreds of hours to take care of these translations.

To achieve easier access to all of the existing versions and languages of the document, the authors have set up the Ham Radio Ethics and Operating Procedures web site at:

https://www.hamradio-operating-ethics.org/versions/

It contains a listing of all versions/languages, sorted by country, where you can download the translations in any of the following forms:

*PDF or Word documents from various countries
*Directly from the different Radio Societies’ web sites
*A downloadable PowerPoint Slideshow Presentation (available in one of three languages–English, French and Dutch)

John, ON4UN, and Mark, ON4WW

On t’fells

Whilst the weather may not have been as warm as last year at this time it has been a very dry few weeks so I have taken the time to get out on the fells and do a few SOTA activations. Nothing too demanding but the local ones around Wasdale and a visit to Keswick.

Keswick can offer a few things. Skiddaw and Blencathra are the two in the frame today. It also offers swarms of people in expensive technical clothing wandering round the town and people on the fells in flip flops. Skiddaw is popular as you can walk from the town. Both of these walks were up and back the same way. A bit dull I know but they can both be very busy if you leave it past about 9am


Both of these walks I had Angus (the dog by the way) with me to keep me company / attempt to pinch other peoples sandwiches. They are nice enough walks but can be a bit busy so if it is solitude you’re after avoid these. There were kids playing in the remains of the snow on the steep slopes in bare feet!

Next up was a trip to Wasdale. Well to be specific it was Mosedale in Wasdale to start with but Pillar and Kirk Fell were the targets. The route take you up black sail and is quiet. You can go up the very steep slope to the left to Pillar but it’s hard going and not as quick as you might think. Pillar is a lovely spot, great views across Ennerdale and Wasdale and on a good day over to Keswick and out towards Penrith. We had a small refusal from Angus at the top of Kirk Fell, where the red splodge is. There is a steep slippery section with some 2+m bits of scramble. He couldn’t get up so we turned round and went round Boat How. Much gentler and less likely to involve Mountain Rescue.

Lastly in this section was Great Gable and Scafell Pike. I’ve not been up Great Gable for a couple of years and it was nice to go up via Sty Head tarn and then up to the war memorial on the summit. It started to snow on the top and was still snow just a few hundred meters from the tarn. Carry straight on and that takes you along the corridor route up Scafell Pike. Quieter and less eroded. There are alwways a few odd sights up on the summit, from people who look like they are going to collaspe through to runners bagging the summit. Best to use the small remains of the hut just below the summit on the south side for activations.

The summits were cold that day and the valley reasonably warm and free from wind, there were some very cold looking people on the summit and at least one dipstick who forgot a patch lead, so no hf activation for me!

I’ve not been over to Helvellyn so that might be next on the list list for this year. Plenty of time to get out and about if the weather stays like this. There were a few dried up tarns and I wonder if this is a result of last summer when it was nearly 30c in Wasdale.

The total so far for SOTA is 198 points. A long way off mountain goat but enjoying the time on the fells all the same.

T1D Toys

Lets start this with a clear statement – This is not a ham radio post 😉

Introduction

My youngest was diagnosed with Type 1 diabetes a little over 12 months ago. Type 1 is a bit different from Type 2 diabetes in that it is auto immune and there is no insulin available. This means a regular tightrope of carbohydrate intake and insulin being administered. In our case this is through a pump.

In the good old days that meant taking a bit of blood from your finger. measuring it for blood glucose and then acting on the information. This could mean correcting to meet a magic number (6 mmol) or just before a meal.

In the modern connected world there are a few toys that can help you. Freestyle Libre continuous glucose monitoring, Nightscout, XDrip+, Miao Miao, Smart watches…….This is my experience of setting a few of these things up. Hopefully in a non techie way.

Setup prior to new toys

  • Omnipod Insulin delivery with the Insulet PDM
  • Old android phone
  • Freestyle Libre Continuous Glucose Monitor (CGM)

The game goes like this. Offer up your phone to your patch, it reads the sensor and you get a BG reading on your phone. Make any adjustments using the PDM Nothing too exciting there.

The problem

The problem with this is that at night there is still a regime of checking. The CGM is collecting data and it needs a human to wave a phone near an arm (invariably the wrong one, in fact sometimes it takes three goes to get the correct arm!)

There are no alarms or warnings

After a few poor nights of sleep it is easy to miss a check and hence mistakes will happen

A solution

Here’s the basic wish list. Use the CGM to it’s potential without waiting for a commercial integrated solution. This means connecting a few things together and for the information to be displayed on a smartwatch in such way that it provides an adequate indication of the state of BG play. So here are the ingredients

  1. Freestyle Libre – The CGM
  2. Miao Miao – A bluetooth device that sits on the Libre patch
  3. Android Phone – The hardware glue
  4. Fitbit Verso – A reasonably priced smart watch
  5. xDrip+ – Software glue
  6. Glance – A watch face to display the info

The system works by the Libre monitors the BG, The Miao Miao collects the data every 5 minutes, xDrip+ receives the data and manipulates it and lastly the Verso shows you whats going on. All this because there isn’t a straightforward off the shelf solution (yet).

What I want is this….

Steps

First thing to remind yourself is that this is not a medical device or set of devices. This is the equivalent of bleeding edge homebrew, short only of a step that makes the adjustments for you.

You’ll need a bit of time – A good hour or two depending on your skills

Set up the FitBit

This bit should be relatively straightforward. Download the App, sign your life away to megacorp and do the updates it prompts for. This took about 30 minutes and to be honest wasn’t smooth. The software could be a bit better but eventually it works. At the end of all this you should have a working FitBit with the default screen.

Set up the Miao Miao and xDrip+

Luckily for me there is a good guide on the Miao Miao website so as long as you can follow that you should be ok. As this stuff is a bit techie it assumes you understand what repositories are and installing apks from sources other than Google Play for example. It’s not as hard as you might think and if you struggle here’s one of few thousand tutorials.

At the end of this you should have a phone that is collecting data every 5 minutes from the Libre patch and giving you a pretty picture. An optional step would be to add a follower to xDrip+. This might be handy if like me you are a parent and you’ll effectively mirror the data on your phone as well as the kids phone. The developers have done a nice video that will show you what to do.

Next up – displaying the information on your FitBit

Again, all the hard work is done for you. Using the phone you used to install xDrip+ and connect to the FitBit and navigate to this page on a browser. There is a good wiki but there are basically two steps to this.

Change some settings in xDrip+

Changing the settings allows the xDrip+ software to send the information to the watch but it is easy. Go to settings, then InterApp settings, then xDrip Web Service. Change this to on

Add a ‘Watch Face’ to the FitBit

The wiki gives you a warning about making sure you’ve done the first step. Make sure you do this. Follow the link to ‘Latest version of Glance’. This will open up the FitBit app and after some time will install the watch face.

Some problems I found

  1. You need to make sure the Miao Miao is well and truly stuck to the Libre patch. Even a mm is enough for it to not connect.
  2. The xDrip+ software is really very capable. A slip with the fingers and a wrong setting will stop it working. For example a FitBit verso is not an Android watch. Take care when setting things up.
  3. This is a do it yourself system and there are a whole bunch of people that can help, but it moves from plain English to TechSpeak pretty quickly and can look daunting. It need not be like this.



Cloudlog on a RPi zero w

As many will testify. I’m not that bright when it comes to clever computer stuff. I can follow instructions quite well and normally this gets me by. So I thought for December I would set myself a challenge of setting up Cloudlog (A really nice looking logging application from Peter 2M0SQL). Only I would be putting it on a Raspberry Pi zero w, without a safety net…or any knowledge of sql, php or any other such acronyms. Here’s what happened.

First things first – You need a LAMP server.

A LAMP server (Linux, Apache, MySQL, PHP) is the thing that will run Cloudlog. We’ll have the Linux part because we’re going to use the normal Raspbian Lite image for our RPI zero w. Apache is installed, as is MySQL and PHP. So first things first. This post is like a nice meal, you’ll not be having bread first, just the starter. Just don’t rush it.

Starter

Do you have a RPi zero w? – If you struggle to find one then use a nice search engine that doesn’t follow you round with a notepad checking on what you’re up to. Perhaps buy from an independent retailer or support your local Pi shop, it might cost a couple of quid extra but you can feel smug about it.

  1. Have you got the latest Raspibian lite image? If not download it here
  2. Is is burnt to a suitable micro SD card? I use Sandisk class 10 ones as they seem to be quickest and reliable enough. Try your high street. If not try and support you local Pi shop. This will be the OS ready to go.
  3. Have you connected to the internet using the command line? it’s pretty easy really, just use this guide.
  4. Have you enabled SSH on your RPI zero w? RPi headquarters can help again.
  5. Do you know the ip address of your RPi zero w? in the command line just type. hostname -I. It will spit out your ip address. For example mine is 192.168.1.113. Make a note of this you’ll need it
  6. Have you logged into your RPi zero w using SSH? Section 4 will help you here

 

Main Course

So I was really comfortable with the starter. It wasn’t too heavy and just got me feeling a bit peckish for some more. This is where I was a bit uncomfortable and thought that I may have bitten off a bit more than I could chew. But it all worked out nicely in the end.

Installing the server

I followed this guide. I believe that it is de rigueur to caveat this part with some statement that ‘your mileage may vary’ or some such waffle. It might, but if this guide is wrong please shout up and I will correct it. It worked for me but it would be a lot easier if it worked for everyone. You’ll do some straightforward and not so straightforward stuff.

  1. Make sure everything is up to date
  2. Install Apache & do a bit of tidying up
  3. Install PHP
  4. Install MySQL & do a bit of detective work
  5. Setup FTP

Everything seems to go well until you hit part 4 where something goes a bit wonky with permissions. I spent quite a bit of time on this and found out that the permissions on the default myphpadmin account weren’t up to scratch and there is a bit of jiggery pokey to do. This should sort it.

Get yourself into MySQL and change the users

From what I could gather the default user does not have enough privileges to do anything, nor does it have access to the users tab in myphpadmin to create a new one. We have to go into MySQL and create

mysqladmin -u root password 'password'

Log in to MySQL

mysql u root

Then do the following. I think I understand, you create a new user using the GRANT command

GRANT ALL to 'username' @ 'localhost' identified by 'password';

where believe it or not the ‘username’ and ‘password’ are exactly that, but for a new user. We’ll use this later

Install Cloudlog

This bit is dead easy. The Cloudlog wiki is exactly what you need. I won’t repeat it here. So for me I downloaded the files from the GitHub page, unzipped them and then uploaded them with an FTP program (Filezilla is popular) to the /var/www folder in the RPi.

Go to your web browser and type in the url you got earlier when you did the hostname -I (Something like 192.168.1.113) only add /install at the end, so for completeness is should be

192.168.1.113/install

Up pops a dialogue. Fill in your details and you are away.

Note: I mucked about a few times when I was sorting out privileges and ended up forgetting the username and password, but the dialogue was good enough to me and I just re-entered everything and it went the second time.

You can now log in as the guest account m0abc which is notes at the bottom of the dialogue.

Dessert

There are a few things to do to get everything ship shape. Firstly delete the demo account and put in your own. Then upload an adif of your existing log (should you have one)

Delete account and create your own

Really easy Admin > Users

Create yourself and give yourself the admin rights

Delete m0abc

Done

Upload adif

So, it turns out that not all adifs are the same. The header in the example below is not to the right format

image

Whilst this is

image

Note the ‘#’ at the beginning of every line in the header. If you are going to upload an adif this needs to be checked

Sitting in a comfortable chair and snoozing

I didn’t find this nearly as daunting as it first looks. There is plenty of information on the Cloudlog wiki and to be honest the only hard bit was sorting out the permissions. You don’t need to be an expert in computering. I now have a log I can access on my Linux laptop, Tablet and phone. If I was really down with the kids it wouldn’t be hard to have it web based (I think that can be done for you by MagicBug).

I would say that you’ll probably need a couple of hours to do it but the reward is a good looking, simple to use log that is agnostic to OS.

Give it a go, if any of the instructions are wrong, can be made better or are glaringly stupid because they’ll steal your soul (or sole if you’re not looking) then let me know and we can make this post really handy.


Subscribe FREE to AmateurRadio.com's
Amateur Radio Newsletter

 
We never share your e-mail address.

Please support our generous sponsors who make AmateurRadio.com possible:

KB3IFH QSL Cards

Hip Ham Shirts

Georgia Copper
Expert Linears

morseDX

Ni4L Antennas

Ham-Cram
R&L Electronics

Do you like to write?
Interesting project to share?
Helpful tips and ideas for other hams?

Submit an article and we will review it for publication on AmateurRadio.com!

Have a ham radio product or service?
Consider advertising on our site.

Are you a reporter covering ham radio?
Find ham radio experts for your story.

How to Set Up a Ham Radio Blog
Get started in less than 15 minutes!


  • Matt W1MST, Managing Editor




Sign up for our free
Amateur Radio Newsletter

Enter your e-mail address: