Topics

Si5351 audio pops and PLL Lockups


WB9YZU
 

Hi Folks, I'm sure you folks have fielded this question before, but search results haven't been very fruitful.
My rig is a Forty-9er that I have modified to accept a VFO instead of a XTAL. I based the idea from a 2016 article in QST where the author used a I2C DDS and a parallel display.

I decided to take on the design and programming of the Arduino backbone myself and went with a Si5351a and put the display on the I2C bus via an adapter card that just piggybacks on the display. Nothing fancy. I'm using an inexpensive digital encoder to change frequencies.

The frequency is constantly being updated to the Si5351a, this is because keying requires that I change from a receive to a transmit frequency on the fly, and to avoid transmitting while the Si5351 is changing frequencies, I am keying the Forty-9er with the Arduino.

Everything seems to work pretty well, the radio does what it's supposed to do, and I have made a number of nice QSOs.
However the enjoyment is somewhat muted by this annoying popping and PLL dropout when dialing the rig.
When the PLL goes to lunch, I can't recover and I need to reset the radio. Though the symptom can appear most anywhere, it is much more prevalent around 7.055.

Steps I've taken do date:
Scoured the code and internet for clues. I am on my NthX2 attempt to write a decent code, the last attempt actually made it worse!
I verified that I am using the latest Etherkit Si5351a Library; version 2.1.4.
I tried to debounce the encoder by using an interrupt call and a debounce routine on the interrupt.; I also added .01uf caps across the encoder CLK and DT Lines to GND.

I read that the LCD is a noise source, so I installed 100uh coils on the power feed (+ & -)  to the display board. That cleaned up some audio noise.

From the number of Si5351a based QRP rigs, I assume a solution(s) has been found? What has worked for you folks?
--
, Ron WB9YZU


Nick WA5BDU
 

Hoo boy, the joys of programming up a synthesizer for your rig!

I've been doing a lot of programming on a Si5351a with I & Q outputs recently but haven't had it actually connected to a receiver much as yet.

However, doing similar things with a Si570 I have heard that noise while tuning. It can be pretty pronounced and distracting but I'm grateful it's gone when I stop turning the knob.

In the early days of the KX3, Elecraft was fielding a lot of questions about this. The noise was referred to as "zipper noise".  Theirs was again an Si570 and the noise wasn't loud but was noticeable. I think they mainly used careful routing of certain wires to mitigate it. This may have been the I2C signals, I don't remember for sure.

Since it might come from one or more of three areas, you might try software experiments to see which makes the noise, or makes the most noise.  

First, have your encoder signals active but your MCU not sending any Si5351a control signals or LCD updates.

Next, have your MCU continuously updating the Si5351a with no encoder input and no LCD updates.

Third, have the MCU continuously updating the LCD with no encoder or data to the Si5351a happening.

As far as the chip losing PLL synch ... I'm not sure I've seen that on my Si5351a project but I used to see it some with the Si570 and I concluded it was RF interference. If my output from the chip was unterminated I'd have the problem, but if it were properly terminated, it did not occur. I think this happened mostly at VHF though.

In my current I/Q Si5351a project, I'm adding the bells and whistles to make it into a full featured VFO with things like band selection and having a keyed line input to tell it when to do the offset shift, plus RIT. 

As far as shifting between TX and RX goes ... it works fine but I realized a bit late I could have used the 3rd clock to go to the TX while the other two provide I & Q for the RX and there would be no need for switching when going from RX to TX and back.

I'm not using a library for the Si5351a control, which makes it easier to examine the code. I do have libraries for LCD and Wire (I2C).

73-

Nick, WA5BDU


On Tue, Mar 17, 2020 at 8:09 AM WB9YZU via Groups.Io <wb9yzu=yahoo.com@groups.io> wrote:
Hi Folks, I'm sure you folks have fielded this question before, but search results haven't been very fruitful.
My rig is a Forty-9er that I have modified to accept a VFO instead of a XTAL. I based the idea from a 2016 article in QST where the author used a I2C DDS and a parallel display.

I decided to take on the design and programming of the Arduino backbone myself and went with a Si5351a and put the display on the I2C bus via an adapter card that just piggybacks on the display. Nothing fancy. I'm using an inexpensive digital encoder to change frequencies.

The frequency is constantly being updated to the Si5351a, this is because keying requires that I change from a receive to a transmit frequency on the fly, and to avoid transmitting while the Si5351 is changing frequencies, I am keying the Forty-9er with the Arduino.

Everything seems to work pretty well, the radio does what it's supposed to do, and I have made a number of nice QSOs.
However the enjoyment is somewhat muted by this annoying popping and PLL dropout when dialing the rig.
When the PLL goes to lunch, I can't recover and I need to reset the radio. Though the symptom can appear most anywhere, it is much more prevalent around 7.055.

Steps I've taken do date:
Scoured the code and internet for clues. I am on my NthX2 attempt to write a decent code, the last attempt actually made it worse!
I verified that I am using the latest Etherkit Si5351a Library; version 2.1.4.
I tried to debounce the encoder by using an interrupt call and a debounce routine on the interrupt.; I also added .01uf caps across the encoder CLK and DT Lines to GND.

I read that the LCD is a noise source, so I installed 100uh coils on the power feed (+ & -)  to the display board. That cleaned up some audio noise.

From the number of Si5351a based QRP rigs, I assume a solution(s) has been found? What has worked for you folks?
--
, Ron WB9YZU


Dave Benson
 

Ron-

Without knowing what's in your firmware, I'll comment on those bypass caps to ground at the encoder.  When the contacts are in the 'open' state, the caps are being charged to 5V through a pullup resistor.  When the contacts close, though, the charge on the caps is discharged to ground at a pretty high instantaneous current.  That's a source of unwanted noise.  It can be remedied by adding a fairly low resistance (say, 100 ohms) in series from the caps to the encoder contacts.

If you're using a high-resolution encoder, there's an off chance you're generating frequency updates faster than the Si5351 can accept them.  Not sure what it would do then.  My recollection is that the updates take 5-10 milliseconds. It may also help to command the Si5351 outputs 'off' prior to any update and restore them only after the command sequence is complete. I was working with an earlier version of NT7S's library, though, and haven't kept current on newer library versions.

73- Dave,  K1SWL



Virus-free. www.avast.com


On Tue, Mar 17, 2020 at 9:09 AM WB9YZU via Groups.Io <wb9yzu=yahoo.com@groups.io> wrote:
Hi Folks, I'm sure you folks have fielded this question before, but search results haven't been very fruitful.
My rig is a Forty-9er that I have modified to accept a VFO instead of a XTAL. I based the idea from a 2016 article in QST where the author used a I2C DDS and a parallel display.

I decided to take on the design and programming of the Arduino backbone myself and went with a Si5351a and put the display on the I2C bus via an adapter card that just piggybacks on the display. Nothing fancy. I'm using an inexpensive digital encoder to change frequencies.

The frequency is constantly being updated to the Si5351a, this is because keying requires that I change from a receive to a transmit frequency on the fly, and to avoid transmitting while the Si5351 is changing frequencies, I am keying the Forty-9er with the Arduino.

Everything seems to work pretty well, the radio does what it's supposed to do, and I have made a number of nice QSOs.
However the enjoyment is somewhat muted by this annoying popping and PLL dropout when dialing the rig.
When the PLL goes to lunch, I can't recover and I need to reset the radio. Though the symptom can appear most anywhere, it is much more prevalent around 7.055.

Steps I've taken do date:
Scoured the code and internet for clues. I am on my NthX2 attempt to write a decent code, the last attempt actually made it worse!
I verified that I am using the latest Etherkit Si5351a Library; version 2.1.4.
I tried to debounce the encoder by using an interrupt call and a debounce routine on the interrupt.; I also added .01uf caps across the encoder CLK and DT Lines to GND.

I read that the LCD is a noise source, so I installed 100uh coils on the power feed (+ & -)  to the display board. That cleaned up some audio noise.

From the number of Si5351a based QRP rigs, I assume a solution(s) has been found? What has worked for you folks?
--
, Ron WB9YZU


WB9YZU
 

Thanks for the responses Nick and Dave!

I looked at the Hilltopper schematic tonight, and code to see how the encoder pull up was handled since it didn't appear to have any.
The encoder I am using is a KY-040; inexpensive and has 3 pull ups built in. I removed them, and configured the code and hardware to approximate the Hilltopper encoder, but used 220ohm instead of 470ohm resistors in series due to junk box availability.

All in all, between the 100uh chokes on the LCD power, and the revised configuration of the CLK/DT/Button pull up/supression, I don't seem to be getting the popping, but the PLL still unlocks occasionally ... Which still sucks as it involves shutting the rig off/reset and looses my place ;)

Before I made these changes though, I did play with separating the dial and frequency updates, and minimizing the LCD display routine to one lcd.print line.
The problem actually got worse, and that may have to do with Dave's insight on update times.

I'll continue to play with it. If I can't ""fix it"", I may just blame the corona virus ;)

--
, Ron WB9YZU


Ron Carr
 

You have the Si5351 and your LCD both on the I2C bus.  That is a lot of I2C activity.  ( Personally I think the Wire library is brain dead as it uses interrupts but still blocks until all the activity is done. )

The Wire library has a buffer size of 32.  If the buffer is full, the code just drops the data and sets an error.  So you may be dropping some writes to the Si5351 when things get busy.

Here is the code from the wire library where it drops data...

size_t TwoWire::write(uint8_t data)
{
  if(transmitting){
  // in master transmitter mode
    // don't bother if buffer is full
    if(txBufferLength >= BUFFER_LENGTH){
      setWriteError();
      return 0;
    }

To see if this is the issue you could edit the library to increase the buffer size.  The file to change is Wire.h.

On my computer ( I installed to directory Arduino ) the path is:   C:\Arduino\hardware\arduino\avr\Libraries\Wire\src
If you have other versions of Wire in your own libraries, then you will need to find the one the compiler uses.

Ron   K1URC


Ron Carr
 

There is another buffer of length 32 defined in directory utility in file twi.h
Without wading through all the code, I would guess you would need to increase this one also.


WB9YZU
 

Thanks Ron!

This is my first Arduino project, and though I was wondering why so many Arduino based radios used IO lines instead of the I2C Bus(it seemed to me they were going through a lot of effort), now I know why!

I haven't gotten to hacking libraries yet.
However, after making the HW changes that Dave suggested (which involved removing the pullups from the encoder/moving them to code), and changing 2 parameters in the code, all seems well. I've been tuning all over the dial with no pops, clicks, or PLL drop outs.

The 2 lines of code I changed were:

attachInterrupt(digitalPinToInterrupt(PinA), Dial, FALLING) ... instead of LOW

and
if (interruptTime - lastInterruptTime > 10) { ... instead of 5

Changing from calling DIAL on a LOW to calling DIAL on a FALLING edge made the largest change.
Increasing interupt debouce was just added insurance ;)

--
, Ron WB9YZU