LED lighting: RF quiet and RF interference from SMPs

I already knew that some Refrakta LED “bulbs” I had bought from Maplin years ago generated a lot of RF. I used a cluster of 3 bulbs with GU10 connectors in the kitchen light fitting. Each bulb had 4 super-bright LEDs so must have had built-in switch-mode power supplies (SMPs) to produce the low DC voltage, SMPs which generated RF. I fitted ceramic 1nF 1kV capacitors (Line-to-Earth and Neutral-to-Earth) and replaced the bulbs with LEDs with longer LED chains 31 LEDs per bulb. This much reduced the problem at VHF.

I did a contest on Top Band (160m) recently and this prompted me to look at my high noise level and start hunting for noise sources.

Disappointingly, the kitchen lights were still a problem, adding about 30dB of noise on Top Band. I tried increasing the suppression capacitors to 100nF 1kV, but this didn’t help much. The bulbs look like this:

Inside there is a little SMP which generates the RF. The LEDs may last for a decade, but the SMPs are unreliable and may fail much earlier. In one bulb I bought recently, it failed within seconds with an audible pop.

I found that the living-room cluster of 4 LED bulbs was RF quiet. They have 80 LEDs on each face.

Looking inside, they seem to have no SMP, just a series capacitor, a rectifier a smoothing capacitor and a few other chip devices.

These RF-quiet bulbs came from zf304160642-1 on eBay.

Club Calls Top Band (160m AFS) contest using N1MM logger

This post is a reminder to me as to how to set up the N1MM logger for the RSGB AFS contests where the club status and club code are required in the sent part of the exchange. It might help you too!

In N1MM I selected RSGBCLUB as the contest.

I set Sent exchange simply as #

The log entry window then prompted for :

Rcv: received report
RcvNr: received serial number
Status: (H for HQ, C for Club Member and N for Not in club)
Club (club code, link to list of clubs in contest rules)

I tried the G7FEK antenna with a loading coil connected across the feed point. The only station who could hear me on 32W SSB was Nick G3DR who is a short distance away. Bob G4APV, also only a short distance away, didn’t hear me. 122 GHz would have been easier!

I gave up on SSB and tried CW/morse code. Stations still struggled to hear me, but gave me 599 reports. Real reports would be more helpful!

My big problem on receive was switch-mode power supply (SMP) RF interference. I had tried adding suppression capacitors (0.1uF 1kV ceramics) to LED light fittings which used SMPs. They helped a bit.

My base noise level was S7 and interference (QRM) could easily add 30dB of noise.

I kept certain RF-noisy lights turned off. I discovered that the back door light (a single super-bright LED) also generated RF on Top Band. It triggered at irregular intervals due to wind.

Top Band is not a pleasant experience here! I gave up early and went to bed.

I generated a Cabrillo file from the N1MM logger and it seemed to load up OK to the RSGB site.

My first microwave reception on Langstone: GB3KEU on 6cm

I had extended the range of the Pluto up to 6 GHz. A new pre-amp from China gave me the opportunity to try the 6cm band.

I lashed up a patch array aerial which I’d been given by Barry G8AGN – it has 64 patches. It looks like the patches have two different lengths. Barry has marked it “15dB”.

I pointed the aerial out of the skylight towards Finningley.

I was rewarded with audio and a waterfall display from GB3KEU at IO93NN, 47km away.

The Pluto seemed to drift up and down gently or perhaps the beacon was drifting a bit too; Peter G3PHO, who assembled the beacon some years ago told me it runs on an ovened crystal.

Beaconspot lists the frequency as nominally 5760.925 MHz, so that is about 20 kHz down from the dial frequency. The Pluto may be a bit out on this band.

I certainly would not have heard the beacon without the pre-amp.

I found that I needed to tilt the aerial up by about 30 degrees to get maximum signal. Perhaps there was some reflection from the window? Or an odd atmospheric effect?

My only other activity on 6cm has been drone module wide-band analogue TV, so this is my first narrow-bandwidth reception on 6cm. It is also my first microwave reception on Langstone.

Portsdown 4 plus Langstone transciever construction

Langstone is basically a combination of a Raspberry Pi 4 and an Analogue Devices ADALM-Pluto. Potentially it should cover 4m, 2m, 70cm plus the microwave bands up to 6cm and possibly beyond via harmonics. It will need appropriate filters and amplifiers. It can be combined with Portsdown 4 for DATV.

There doesn’t seem to be one site for Langstone, so here are the links I have gathered so far:

I ordered a RasPi4 with 7″ touchscreen, PSU, heatsink and 16GB SD card from PiHut and a Pluto from DigiKey UK.

The RasPi4 came with various connectors and leads. I stuck the heatsink on the RasPi4‘s processor can.

After some digging about for information, I connected the jumper leads to the screen connections:

  • Red: 5V
  • Green: SDA
  • Yellow: SDL
  • Black: GND

And at the RasPi GPIO connector end:

  • Red: pin 2
  • Black: pin 6
  • Green: pin 3
  • Yellow: pin 5

Note which way round the ribbon cable goes (white with blue marked ends). The conducting contacts are on the reverse side of the blue. They must mate with the conducting contacts on the boards. Pull out the plastic wedges just enough to slide the ribbon end in, then click the wedges in again to clamp the end of the ribbon, so it looks like this:

Above shows the RasPi4 board screwed in place. I attached the PSU lead & plugged it in:

A pink LED lit up (lower left on the RasPi). The SD card came with a system on it. Turning the boards over showed this display:

I wanted to integrate Portsdown 4 for DATV, so I started at the Portsdown 4 Wiki. This said: “You MUST start with a fresh build of Raspios Buster (NOT Raspbian) on an SD Card of 8 GB or greater”.

Back to Colin’s site, I followed the instruction to download Raspbios Buster Lite. He has instructions for downloading to a Windows PC, but I downloaded to my Ubuntu Linux PC and then installed Raspberry Pi Imager for Ubuntu. I extracted the image from the zip file. I ran the imager & selected the image via the Custom option and the SD card (from the RasPi4 in a USB adapter) and clicked Image. The image seemed to transfer OK. Remounting the SD card on the Ubuntu Linux PC I got two drive icons: rootfs and boot. In boot, I right-clicked and used New Document>Empty File to create a new file: ssh (as instructed in Portsdown 4 Wiki).

I moved the SD card back to the RasPi4 and powered it up. It flashed up a message resizing something on the screen and then went through the usual boot stream of messages, ending in Raspbian GNU/Linux 10 raspberrypi tty1 and a login prompt.

I cut the power to the RasPi4 and remounted the SD card back in my Linux PC. I launched a terminal window and entered the command sudo gedit and selected /rootfs/etc/dhcpcd.conf file on the SD card.

With my router at 192.168.1.1 and 192.168.1.51 the address I’d chosen for the RasPi4, I edited the static ip configuration lines to read:

interface eth0
static ip_address=192.168.1.51
static routers=192.168.1.1
static domain_name_servers=192.168.1.1

With the SD card back in the RasPi4 and an ethernet cable connecting to the local network I applied power to reboot. The RasPi4 start-up message sequence included:

  • Started Hostname
  • dhcpcd on all interfaces
  • Reached target network

In a terminal window on my PC I typed ping 192.168.1.41. Packets arrived OK. I typed putty and in the putty session I entered 192.168.1.41 in the Host Name (orIP address) field. I got the message connection refused.

I realised I had the address wrong. I pinged 192.168.1.51. Packets arrived. I unplugged the RasPi4 from the network. Packets stopped arriving. I had the right address!

My internet router is on the 192.168.1 subnet, so altering the RasPi4 IP address above means that the necessary internet access is there to install Portsdown 4 and install Langstone. On my Linux PC I entered 192.168.1.51 in putty. I got a login prompt. I logged in as user pi with password raspberry. Paste didn’t work, so I typed in three commands (slide the scroll bar right to get all of the long command):

wget https://raw.githubusercontent.com/BritishAmateurTelevisionClub/portsdown4/master/install_portsdown.sh
chmod +x install_portsdown.sh
./install_portsdown.sh

I got: Installing BATC production version of Portsdown 4

As instructed, I went for a cup of tea. When I got back, the Portsdown 4 menu was displayed.

I entered the Langstone Options submenu via menu M2.

I touched Install Langstone. It said Installing Langstone Software, Please Wait for Reboot.

A short while later, it re-booted and the Portsdown 4 menu returned.

I plugged the Pluto into the RasPi4 via its USB lead. The Ready LED lit and LED1 flashed. In M2 I touched Switch to Langstone.

I got the Langstone screen with the message: Lang_RX.py not responding.

I ordered the recommended audio USB device. While I waited for that to arrive, I searched the junk box. I found a “3D Sound” USB dongle. It wouldn’t fit against the other USB plugs, so I took its covers off. I added a mouse and also plugged in Minitiouner, fed from my Es’Hail2 satellite dish.

Re-booting and running Portsdown4 on receive, I got a lovely decode of the Es’Hail2 beacon, using the Play with ffmpeg VLC option, with sound from the RasPi jack socket.

Colin G4EML has provided some useful diagnostic programs. I set the putty session going again and entered:

cd ~/Langstone
./stop
./HW_Test

HW_test let me check the screen touch and also verified the mouse buttons and wheel were working.

./Pluto_Test

This verified the throughput, 1919, in my case was close to the expected 1900.

./Sound_Test

Sound_Test is now superseded by set_sound. Sound_Test found my audio dongle giving the details:

Unable to find the default sound device
hw:CARD=Headphones,DEV=0
hw:CARD=Set.DEV=0

I amended Lang_RX.py and Lang_TX.py as suggested and restarted Langstone. Running Sound_Test again via putty, it still said “Unable to find the default sound device“. However when I restarted Langstone it did not complain about a missing sound card. I still got the message: Lang_RX.py not responding.

Then I noticed Colin had updated Langstone to include a new utility, set_sound. I updated Langstone on the RasPi4 by entering the following commands in the putty session on my Linux PC:

cd ~/Langstone
./stop
./update
./run

set_sound found only one device, the 3D Sound dongle. I selected 1 and it edited the Lang_RX.py and Lang_TX.py for me. Neat!

I also made sure all the USB plugs were properly seated in the RasPi4 sockets and that the Pluto and MiniTiouner plugs (with the thick black leads in the picture below) were in the USB3 (blue) sockets.

Restarting Langstone gave me a waterfall for the first time. Plugging headphones in the 3D Sound dongle gave noise, so that looked and sounded promising.

I connected the Pluto to the 70cm pre-amp & yagi & pointed the yagi at GB3FNY:

My first reception on Langstone! The horizonal stripes are probably OTH radar swipes.

I plugged the Pluto USB cable into my Linux PC. I edited config.txt as below (leaving the original lines as # comments), saved it & ejected the Pluto “drive”.

[NETWORK]
hostname = pluto
#ipaddr = 192.168.2.1
ipaddr = 192.168.1.41
#ipaddr_host = 192.168.2.10
ipaddr_host = 192.168.1.52
netmask = 255.255.255.0

Although putty on my Linux PC linked fine to the RasPi4, I failed to get it to link to the serial port on the Pluto, so I decided to try kermit. In a terminal session, I executed: sudo apt install ckermit

I knew ttyACM0 was the serial device for Pluto. In terminal I ran:

kermit -l /dev/ttyACM0 -b 115200
C-Kermit 9.0.302 OPEN SOURCE:, 20 Aug 2011, for Linux+SSL+KRB5 (64-bit)
Copyright (C) 1985, 2011,
Trustees of Columbia University in the City of New York.
Type ? or HELP for help.
(/home/gray/) C-Kermit>

At the C-Kermit> prompt I entered c for connect and later root and analog for the Pluto login name and password respectively:

(/home/gray/) C-Kermit>c
Connecting to /dev/ttyACM0, speed 115200
Escape character: Ctrl-\ (ASCII 28, FS): enabled
Type the escape character followed by C to get back,
or followed by ? to see other options.
Welcome to Pluto
pluto login: root
Password: analog
Welcome to:
_ _ _ __________
| _ \ | | | / | _ \ \
| |/ / | | |
\ --.| | | | |_/ / | __/| | | | | __/ _ \--. \ | | | / | | | | || | || () /_/ / |/ /| |\ \
_| ||_,|____/____/|_/ _| _|
v0.30
http://wiki.analog.com/university/tools/pluto
^C

I entered the following commands (shown in bold) and got the following responses:

fw_printenv attr_name
Error: "attr_name" not defined
fw_printenv attr_val
Error: "attr_val" not defined
fw_setenv attr_name compatible
fw_setenv attr_val ad9364
reboot

Communications disconnect (Back at Lab)
(/home/gray/) C-Kermit>exit
Closing /dev/ttyACM0…OK

Barry G8AGN referred me too a youtube video which set a third parameter, maxcpus, on the Pluto. I checked the first two parameters and added the third:

fw_printenv attr_name
attr_name=compatible
fw_printenv attr_val
attr_val=ad9364
fw_setenv maxcpus
reboot

I copied pluto.frm file dated 21-Aug-2020 into the Pluto “drive”. I ejected the Pluto drive. LED1 flashed rapidly. Eventually the Ready light came on again and LED1 flashed slowly as usual.

I’ve noticed the config.txt file on the Pluto had reverted its IP addresses back to the original. I don’t know what has done this; possibly the firmware update?

I browsed 192.168.2.1 and got Welcome to the ADALM-PLUTO QO-100/DATV custom firmware:

Rather than powering the RasPi4 via the little (Mini?) USB connector, I opted to supply 5.1V via two pins on the GPIO connector: pin-9 for negative (Gnd) and pin-4 for positive.

Misc scribbles:

[I installed libiio on my Ubuntu 18.04 Linux PC by executing this command in a terminal session: sudo apt install libiio-utils]

from youtube video:

Pluto tools: SDRangel

325 MHz to 3.8 GHz

In putty session:

fw_setenv attr_name compatible
fw_setenv attr_val ad9364
fw_setenv maxcpus
reboot

Unplug Pluto and plug it back in again.

46.875 MHz to 6GHz

To reset Pluto to original spec:

fw_setenv attr_name
fw_setenv attr_val
fw_setenv maxcpus 1

Hack Green SDR’s aerials

I’ve been using Hack Green SDR as a way of evaluating my experimental G7FEK aerial.

Tony G1HMO has let me know the aerial configuration:

The VHF and UHF SDR antennas are folded dipoles at about 40m up the tower. They both have bandpass filters and tower-mounted amplifiers at about. They are then fed down the tower using LDF-450 Heliax cable.

The 70MHz receiver is a folded dipole at about 25m, fed with LDF-250 cable.

The 10m receiver is fed from the HF SDR antenna multicoupler, the antenna is a double sized G5RV at about 30m one end, and 10m the other end. The antenna is connected to an 8 output multicoupler designed and built by G7CKX. This gives just enough gain to overcome the loss of the splitter and lots of isolation between the 8 ports.

I still need to find a way of evaluating the G7FEK antenna on 30m.

I’ve mainly made comparisons on 20m, but, as it stands, my version of the G7FEK aerial, when feeding the K3 does not show signals as better than Hack Green SDR (HGS). The signals are often as good on signal strength as HGS. An obvious problem is that I have an S-point or so of extra noise, so generally, the signal-to-noise ratio using the G7FEK is not as good as HGS.

Portsdown 2020: Unable to connect to GitHub – specifying network gateway address

When I tried to upgrade the Portsdown software I was getting: “Unable to connect to GitHub to check the latest version“.

In console mode, I went to the Linux command line.

route -n showed no gateway address. I could ping my router on at 192.168.2.1 so the connection to my local private network was working, but pinging google at 172.217.169.3 failed.

I found a suggestion from Arpit Agarwal who suggested route add default gw 192.168.2.1 eth0. I found sudo route add default gw 192.168.2.1 eth0 worked. route -n showed the gateway address. I tried a Portsdown software update & it worked fine.

So that gave me a work-around.

My problem is that the gateway address is lost again after a reboot. I’ve tried modifying the ip= command in the cmdline.txt file (see viewtopic.php?f=103&t=6742) to specify a gateway address, but I didn’t get it to work.

How can I make my gateway address persist?

I tried removing my ip= command from /boot/cmdline.txt , in case it was overriding your commands, but still no joy.

Dave G4FRE helped me out on the BATC forum.

I edited /etc/dhcpcd.conf so that it had the commands:

interface eth0
static ip_address 192.168.2.47
static routers=192.168.2.1
static domain_name_servers=192.168.2.1


route -n now shows I have a gateway!

Portsdown 2020: Specifying IP address in cmdline.txt in situ

I had boxed up the RasPi and then discovered that in order to try OBS that I needed to specify an IP address on a file on the SD card buried in the box. https://wiki.batc.org.uk/OBS_-_Open_Broadcast_Studio
I wanted to avoid dismanteling it so I experimented and found the following approach using console mode seemed to work. I used a remote device, a PC running Linux in my case, to run console mode.

In menu M2, use the Info button and make a note of the IP address. Make sure you have a network connection between the RasPi and your remote device.

Start a putty session on the remote device. In PuTTY Configuration, enter your noted IP address in Host Name (or IP address) and click Open.
Login as: pi
password: raspberry

You should see Portsdown DATV TX etc.
Select Shutdown and reboot options.
Select Exit menu to command prompt. You should get a Linux prompt like pi@raspberrypi:~$. Enter:
cd /boot – the prompt will change to /boot $
dir – this should list cmdline.txt as one of the files.
sudo nano cmdline.txt – opens a text editor. You should see a big long line of text with commands in it. Use the arrow keys to navigate towards the end of the line and just after rootwait type in ip=192.168.2.47 (substituting the IP address that you want to allocate instead of 192.168.2.47). Space it like the other commands. Enter ctrl-O to Write Out and save the amended file, then ctrl-X to exit the nano editor. Enter exit to quit the putty session.

When you reboot Portsdown, M2/Info should show the new IP address.

I don’t know my way round the Portsdown system & I’m not a Linux expert, but I am sharing this in case it helps.