Wednesday, July 24, 2024

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





Sunday, July 21, 2024

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

Friday, July 19, 2024

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


Wednesday, July 10, 2024

Homebrew sBitx on 64 bit and Subthreshold Conduction Resolved


KK4DAS sBitx on 64 bit build by W9JES

The homebrew sBitx is now on the 64 bit version of the OS and software. Thanks to W9JES, JJ and team for their work on this upgrade to the factory sBitx Raspberry Pi image and sofware distribution. JJ and team have made some significant upgrades to the core - most important bringing it to the lates stable 64 bit release of the OS. In addition JJ has developed a suite fo add on applications that provide additional functionality. When I first booted it up I was not able to decode FT8 sigals in teh native sBitx app. JJ worked with me and we found that since I did not have a RTC clock installed the new version of the app was not using the correct time - and for the WSJT protocol to work the time must be in sync wiht UTC. He made the fix so the software will fall back to NTP if no RTC is installed and I am back in business! Thanks JJ.

While I was testing the 64 bit build the rig begain to exhibit another RFI gremlin - the Tx/Rx relay would begin to click randomly - sometimes one click at a time and other times it became a real chatter - annoying enough that I temporarily disconnected the connection from the Pi to the relay so I could get on with testing. I thought it was RFI from the Pi -- maybe related to the Pi's wifi - it seemed to get better when I turned off wifi. My build of the sBitx puts the rig in to Tx by putting a signal on a GPIO line that goes through a dropping resisitor to the base of an NPN transistor that turns on the relay. I suspected RFI was getting into the GPIO line. I put the scope at the base on it and I could see the voltage spikes that were triggering the relay. I put a .1 cap to ground where the line connects to resistor. That didn't help. I put ferrite beads on the line. That didn't help. I switche from a single piece of stranded wire to shielded coax. That didn't help. So I did what I often do when stuck on a thorny circuit problem, I asked my friend Pete, N6QW. Once again the Wizard of Newbury Park diagnosed my problem fromm across the country.

Here is Pete's response in its entirety:

"It may be a case of subthreshold conduction (a leaky transistor), 

I would do the following. 

Use a 2.2K versus a 220 Ohm. Get some small ferrite beads and slip those over the base lead and change out the 2N3904 transistor to a TIP31C.

Your narrative indicates it is a recent problem and you didn’t see spiking on the GPIO. The signs suggest a leaky transistor (or not). But the above steps are positive and should be done as good practice.

Leaky transistors are not limited to digital electronics and in fact this problem is in the analog hardware."

I didn't have a TIP31C in the drawer and since it was working previously I replaced the no-brand 2N3904 with a new known-good one from my MOUSER hoard, I changed the resistor value per Pete's advice and left the ferrite beads on the signal line.

Bob is my uncle!  No more chattery relay.  Key point above - this is an analog circuit problem that likely had little or nothing to do with the digital circuit - subthreshold conduction just means the transistror turns on when it is not supposed to.

Thanks Pete!

Here is Pete's blog post explaining in detail:

July 10, 2024. Subthreshold Conduction (n6qw.blogspot.com)

Next steps - install the RTC module and the directional coupler for the SWR and power meter 73 from Great Falls
Dean
KK4DAs

Sunday, July 7, 2024

Homebrew to Homebrew with KA4KXX - sBitx to Bitx

 


Walter, KA4KXX and I had an extended QSO yesterday from my QTH in Virginia to his in Florida.  And the most remarkable thing is we were both working homebrew version of  BITX rigs.  I was using my homebrew sBitx and Walter was using his most recent 20 meter SSB and CW rig. 

Here are pictures of the two rigs as used on the air!

KA4KXX 20 M SSB CW BITX STYLE


KK4DAS sBitx

Thanks Walter for the fun QSO.  A rare pleasure talking with another homebrewer - particularly one who isn't afraid to let his geat go al-fresco!

In other big hombrew sBitx news I completed a clean sweep of the 13 Colonies special event last night - all on SSB working from my garage workshop location wiht my 80M off center fed dipole.  I managed to bag the elusive K2K, New Hampshire last night after many tries over many days.  So once again the colonies are united and ready to win the war!  Fun fact - New Hampshire was the 9th state to ratify the US Constitution making it the official law of the land.  So why then were they so reluctant to close the deal with me?  

Still waiting for 10 meters to open again so I can check out the peformance on the high bands.

73 from Great Falls,

Dean

KK4DAS