2000 47pF Caps ...

 

An unexpectged package arrive in the mail today.  Did you ever wonder what 2000 47pF NP0 capacitors look like?  Thanks to John, AB2XT I will never run out of 47pF caps. These caps will find their way into future projects and inject a little more soul into the machine. Thanks John.

Homebrew sBitx - Fldigi

 

Homebrew sBitx - Fldigi

Now that I have the hardware tamed I'm turning my attention to some of the more itnteresting and useful features of the sBitx.  With the sBitx software running on a Raspberry Pi 4B there is plenty it is possible to run a variety of digital mode software programs right on the Raspberry Pi itself - there is no need for a separate computer. FT8 is built directly into the sBitx software so there is no need to run WSJTX, but for other digital modes including RTT, FSTK, Olivia, etc. you need to get the Linux versio of those programs and configure them to talk to the sBitx via the Hamlib interface.  

This was my first attempt at using Fldigi and I managed to make several good connections with myvfriend Don. KM4UDX.  The one pictured above was using the Olivia 16/1K mode.  Pretty impressive, but I still have more tuning up to do. While Olivia modes decode flawlessly - I was not able to receive and decode PSK, RTTY, and others.  I need to work on getting audio at the  correct level to not over-drive the SDR. 

I can turn the IF down on the sBitx.  I can also make some adjustments to the filtering in the Fldigi softwatre itself.

More to come on this one.

73 from Great Falls,

Dean 

KK4DAS

Homebrew sBitx - LPF Leak Stopped!

Quick update - I have resolved the problem with the LPF module in my homebrew sBitx.  The observed problem was that the transistors that control the relays sometimes were conducting when they were not supposed to resulting in more than one filter being switched in at a time.   The solution turned out to be adding a cap to ground at the low side of the relay coil where it connects to the transistor.  The hypothesis was that RF was being induced onto the inexpensive non-RF-rated relay coils.  I also swapped the NPN transistors for 2N7000 MOSFETS - the 3V threshold voltage guarantees that they won't turn on from minor fluctuations on the Raspberry Pi GPIO lines.   Reliable informaion on the high and low logic values for the Pi GPIO have been difficult to find.  Data sheets for the Pi 1.0 suggest logic "low" could be as high a 800 mV which could turn-on an NPN transistor, so the MOSFET seemed a safer bet.

Here is the final circuit:

 

Thanks to everyone for their suggestions and ideas.  The wisdom and entrhusiasm of the crowd really helps.

73 from Great Falls,

Dean

KK4DAS

Homebrew sBitx - Fault Tree Analysis

 

KK4DAS sBitx Low Pass Filter Board

My friend Pete, N6QW recently mentioned the problem I was having with the low pass filter board in his excellent blog post describing the enginerring process of fault tree analysis, a systematic approach to understanding and resolving failures of complex systems.  This post will describe the observed problem with my LPF board and walk through some of the steps I am taking to resolve it.

First, some context.  The LPF board consists of four low pass filters covering the HF bands from 80 meters to 10 meters.  My board uses relay switching to select the correct filter for the band I am  operating on.  The relays are are fed +12V on transmit and each relay is switched with an NPN transistor.  The transistors are are turned on by a GPIO signal from the Raspberry Pi, there is a seperate GPIO line for each relay and only one line is "high" at a time.

Here is the typical circuit for controlling a relay from a GPIO line...

GPIO Controlled Relay Switch

In addition to the four LPF relays there is one more relay with the idential circuit that is the Tx/Rx relay which enables the +12Tx bus to provide power to the transmit chain.  I built and tested the LPF board on the bench and it was working perfectly, one relay at a time coming on, one filter at a time in theTx line, but when I put it in the rig things immediately went haywire. As soon as I would transmit on any band all of the relays would start chattering, machine gun style.   I checked-in with sBitx designer Farhan, VU2ESE and he recommended adding a .1uF cap to each contrrol line to keep RF off the control lines - I hadn't done that so I added the cap (Q2 in the schematic) and that immediately calmed things down ... mostly.

That episode focused my attention on the relays and I observed something I had seen once or twice before but not given much thought to - sometimes the Tx/Rx relay would switch spontaneously, I noticed it particulalry during rig power-up but I had attributed it mostly to the floating state of the GPIO pins during initialization.  Pete suggested the problem could be subthreshold conduction, the transistor conducting when a weak (below turn on voltage) signal is present on the GPIO lines.  I measured the GPIO lines and found that in the logic "off" state they still had about 600mV on each line. That's fine for digital logic but pretty close to turn on voltage for an NPN switch.   R1 was orignally 220 ohms and Pete suggested bumping it up to 2.2K and using a TIP switching transistor in place of the the 2N3904.  A member of our Maker's group suggested adding a pull down resistor to the base of the transistor. The Pi has internal pull-downs but the thought was and external resistor might pull the line closer to 0.  The external pull-down didn't help so I took Pete's advice and that solved the spontaneous transmit switching problem.

With the spontaneous transmit problem now resolved, and with hyper-awareness to the relays I noticed that there was a faint whirring noise coming from the relay board that occured during transmit - particulalry on FT8 or CW.  I also noticed that sometimes power output was significantly below what I expected.  The whirring noise almost sounded like a fan - but there is no fan on the board.  I hypothesized that it could be the relays fluttering.  One of the keys to solving a problem in a complex system is to to be able to discern where the problem is occuring.  To help me literally "see" if the relays were turning on when they were not supposed to I added an LED to each relay.   Here is the result:

So that was a clear indication that the transistors were conduction during Tx in the presence of strong RF.  I thought that perhaps the relatively high "off" voltage on the GPIO lines combined with the RF floating around the rig might cause the transistors to partially turn on.  Sometimes they would turn-on strong enough to switch the relays and sometimes not.  I thought that maybe if I added a voltage divider to the base of the transistor that would knock down the voltage enough to make the problem disappear.  Unfortunately, as is often the case when working on a homebrew rig, one problem leads to another and I had a side trip to solve a couple of other problems.  The main one was that the main Tx/Rx relay starting sticking in Tx.  I could tap it with a pencil to get it to shut off.  The relay was problably weakened during my early testing when it was machine gun chattering on Tx.  Here is a short video describing the next steps:

So back to fault tree analysis - what do I know now?  First the problem is related to RF and it varies with drive level.  So, per Pete's advice - lets see if its on the DC line or the control lines or just RF floating around the booard.  I disconnected the off-band GPIOS and the LEDs still blinked.  I put the relays on a separate power supply, and the LEDs still blinked.  Remembering that changing the 2N3904 to a TIP-110 has helped solve the Tx/Rx switching problem I decided to swap one of the 2N3904s for a TIP-110 on the LPF board.  That helped a lot. Here's the video demonstration of all of the above:

So here is where things stand.  I have replaced all the 2N3904s with TIP-110s and the LEDs no longner flicker on 80, 40, and 20 meters, but as frequency increases the LEDs start flickering again - and they are strongest on 10 meters.  The higher the frequency the more RFI.  If I lower the drive to about 10 watts it goes away on all bands. 

So to summarize the changes since I started.  I added RF bypass caps to the control lines.  I added a voltage divider to the base of the transistors, and increased the current limiting resistor from 220 ohms to 10K, and I swapped all the 2N3904s for TIP-110 switching transistors. Here is what the relay circuits look like now:

At this point, even though the LEDs flicker a bit on higher power and higher frequencies, I don't believe any of the relays are switching on, so if I remove the LEDs, which I only added for visibility, the problem may be "out of sight, out of mind."

I'd still like to solve the problem - because even if I can't see it, I'll still know its there.  Leave comments below if you have any suggestions.

73 from Great Falls,

Dean

KK4DAS

Arduino Nano as ISP programmer for ATTINY85

 

My breadboard ISP programmer started falling apart, and I would often bend the pins on the ATTINY85 plugging and unplugging repeatedly while working a project.  I took an hour this morning and soldered up a permanent programmer circuit.   There are number of good online tutorials for how to do this.  Here is one I used as a refernce:  Hao's Blog - Programming ATtiny85 with Arduino Nano  (Note: for the sBitx SWR Bridge we use a different board manager core than the one Hao demonstrates.  See my blog post KK4DAS - Amateur Radio Explorations: Homebrew sBitx - Power and SWR Meter Working for details.)  The official Arduino document for using an Arduino as a programmer is here: Arduino as ISP and Arduino Bootloaders | Arduino Documentation

This worked straight away - its great to have a soldered up board - and with the zero insertion force socket - no more bent pins.

73 from Great Falls

Dean

KK4DAS

Homebrew sBitx - Power and SWR Meter Working

 

KK4DAS sBitx Screen in Tx PWR and SWR Meter

Victory is at hand.  In my previous post I described the Tale of Woe regarding the power and swr meter sensor

As I have suspected for a while the problem turned out to be the some combination of the Arduino board and the Wire library.  Rafael Diniz, from the groups.io BITX20 forum suggested I load the ATTinyCore from Spence Konde which I did, but the problem remained - always -1 returned for FWD and REF power.  Perusing the Arduino support forum I was pointed to an alternative to the Wire library called TinyWire.  I loaded that and changed all the references from Wire to TinyWire and that worked.  Here are the details.
 
1. IDE: Arduino IDE 2.3.2
2. Board Manager: ATtinyCore by Spence Konde, GitHub - SpenceKonde/ATTinyCore: Arduino core for ATtiny 1634, 828, x313, x4, x41, x5, x61, x7 and x8 (NOTE - because of SSL certificate errors it doesn't currently load using the Arduino IDE board manager.  I had to search for a procedure to manually install it.)
3. Board Selected:  ATtinyCore -> ATtiny25/45/85 (No Bootloader)
4. Chip Selected:  ATtiny85
5. Programmer: Arduino as ISP  (I built a programmer using a spare Arduino Nano)
6. Install the the TinyWire library: GitHub - lucullusTheOnly/TinyWire: Composite Master and Slave I2C library for Atmels ATTiny microcontrollers
7. In swr_bridge.ino change all referencs to Wire to TinyWire and change:  

TinyWire.write(message, 4);

to

TinyWire.send(message, 4);

 

Compile, upload and be happy for the rest of the afternoon.

 

I can't explain why ATtinyCore and Wire worked for Rafael.  I never did learn what the original build environment for the SWR bridge was.  The comments in the code refer to DIYTiny - I searched and found that one - it didn't work for me either.

 

The Arduino ecosystem is terrific - unfortunately thre are so many people contributing board managers and libraries - some are great quality - some are marginal - but there is no authoritative place to go to find what works.

Now, finally on to final calibration and packaging!

 

73 from Great Falls,

 

Dean

KK4DAS

Homebrew sBitx - RTC and Power Meter - ATTINY85 Tale of Woe

 

sBitx RTC and SWR/PWR Meter

I'm getting down to the end of the sBitx build.  The last two functional modules are the RTC and the SWR/PWR meter.  Both are attached to the sBitx bitbang I2C bus.  What is a bitbang bus and why are we using it?

In Farhan, VU2ESE's original build of the sBitx he found that the WM8731 codec chip and the SI5351 clock generator did not play well with each other on the same I2C bus.  (I2C is a ubiquitous communications bus for microcontrollers and peripherals - its how the Raspberry Pi controls thes other modules in the sBitx).  Farhan decided to implement a second I2C bus using alternate GPIO pins on the Pi - and for that he needed a software implementaion of the I2C protrocol - that is the I2C bitbang.  He left the codec on the dedicated hardware bus and put the SI5351 and later the Real Time Clock and SWR/PWR meter modules on the bitbang bus.

The RTC is an Adafruit module that is a battery backed up clock for the Pi.  So if you take your RTC-enabled sBitx to the field with no internet you can be confident that the time will still be correct and your FT8 QSOs will work.  The SWR/PWR meter consists of a Stockton Bridge directional coupler and an ATTINY85 microcontroller to sample the forward and reflected power from the bridge and send it on the the Pi for processing. 

The picture at the top of the post is the board with the RTC and ATTINY95 sitting next to the directional coupler - just prior to wiring it all up.   The RTC meter worked perfectly on first power up  -so far, so good.  

Here is how the PWR and SWR meter sampling works.  On transmit, the main sbitx program running on the Pi sends an I2C command to the ATTINY85 telling it to sample the forward and reflected power pads on the coupler and send the results back to the Pi.  The ADC on the ATTINY85 should return values from 0-1023 which linearly represent 0 - 3.3V DC.  

TALE OF WOE BEGINS HERE

Directional Coupler - PWR/SWR Bridge 

ATTINY85 PWR/
SWR Sensor

To test, I put the sBitx in CW mode at max power on 40 meters which should be approximately 20 watts into a dummy load so the SWR should be 1:1.   I keyed down and the power meter on the sBitx read 0 and the SWR read 1:1.  Not good.  I also had an external analog power meter in the circuit and it dutifully swung up to 20 watts.  So power out is ok, but the sBitx power sensor is not working.

First question was - is the directional coupler working?   The Stockton bridge samples the forward and reflected power and rectifies to a DC voltage from 0 to about 3 volts.  I put a DC power meter on the FWD pad and keyed down - the result was 1.5V DC.  Check!  For good measure the REF pad measured about 120 millivolts - so pretty close to 1:1 as expected.

Next I add print statements to the sBitx code to print out the values received from the ATTINY85.  This would tell  me two things.  First - was the ATTINY85 sending back anything - and what was it sending back.  I keyed down while observing the console window - yes the ATTINY85 was sending back data on transmit, but instead of being 0-1023 the value was always -1 (all 1s binary).  

Next question - is the problem in the ATTINY85 ADC or the I2C exchange.  So to do that I made changes to the code in the ATTINY85 to send hard-coded values.  That takes the ADC out of the equation.

On receipt of a an I2C command from the Pi an interrupt fires and the ATTINY85 samples the FWD and REF pads of the coupler and sends the data back to the Pi.  The code is brief enough that I can include the whole sketch right here:  

#include <Wire.h>

int16_t fwd, ref;

byte message[4];

// function that executes whenever data is requested by master

// this function is registered as an event, see setup()

void requestEvent() {

  fwd = analogRead(A2);

  ref = analogRead(A3);

  message[0] = fwd & 0xff;

  message[1] = fwd >> 8;

  message[2] = ref & 0xff;

  message[3] = ref >> 8;

  Wire.write(message, 4); // 4 bytes message with fwd and ref

}

void setup() {

  Wire.begin(8);                // join i2c bus with address #8

  Wire.onRequest(requestEvent); // register event

}

void loop() {

}

So for my next test I hard-coded vfw and vref, programmed a new ATTINY85 and tried again.  No change - still receiving only -1.

Next step - is the problem on the ATTINY85 side or the Raspberry Pi side.  To figure this out I wanted to look at the I2C packets as they traversed the bus.  Fortuitously my Rigol Oscillocpe will decode digital signals including I2C.  I hooked probe channel one up to the Clock line (SCL) and channel two up to the Data line (SDA) and after some fiddling and a couple of Youtube videos I managed to capture a single message going from the ATTINY85 to the Pi.

I2C Decode on Rigol DS1202 Scope

Just an aside. This is super cool! I can see the whole protocol, the ones and zeros and acks and nacks. And the Rigol even decodes it for me.  Its such a pleasure to work with good test tools - and at such reasonable prices.  Just a few years ago protocol analyzers ran into the thousands of dollars. Moderns digital scopes and tools like the NanoVNA and TinySA open up a whole new world to homebrew radio enthusiasts.

So hardware probe results confirm the software testg - the ATTINY85 is sending back on all 1s is the data frame.  

So that is where the tale of woe stops at the point. I am certain at this time that this is a software problem in one of the ATTINY85 Ardunio libraries,  I've done some internet sleuthing and found that others have had this identical problem going back almost 10 years.   I suspect the issue is with either the board manager I loaded for the ATTINY85 or a bad version of the WIRE (I2C) protocol code for the ATTINY85.  Like much in the open-source Arduino world there are several competing libraries with either identical or very nearly identical names and there is rarely a definitive version. There are multiple board definitions for the ATTINY85 and multiple versions of the WIRE protocol.  Its not clear which one Farhan used in the original build (he's checking), but I am pretty sure I have the wrong one.  

Away from the bench for a few days - but in the meantime if you have any suggestions, leave them in the comments below.

73 from St. Michaels, MD on the Eastern Shore of the Chesapeake Bay,

Dean

KK4DAS

St. Michaels Harbor