pavelmc / si5351mcu Goto Github PK

There is a problem with the level of the signals generated near and around 150.000 MHz.

The signals increase smoothly above the mean set by setPower() as soon as you are reaching 140.000 MHz and drop drastically just about 1Hz above 150.000 MHz (where they shows a maximum peak); they recover slowly and reach normal level as high as 180 Mhz.

Other libs don't show this behavior, the level is ok from 8kHz to about 140MHz, and from ~180Mhz up to 225 Mhz. So bitx users in HF range are safe.

If you use a almost pure resistive load you may not notice this as the effect is almost noticeable, but as soon as you place a LC filter in this band of freqs the effect is evident and noticeable, the peak and dip moves in a span estimated of about 6 dB.

I'm working on the math and logic behind this.

Pavel CO7WT.

If frequencies in steps of powers of 2 are selected, the second set of I2C writes are not executed.

To reproduce, e.g.

setFreq( 0, 100000 )
setFreq( 0, 50000 )
setFreq( 0, 25000 )

re-reading the registers shows that the update has not taken place. Oscilloscope readings confirm this.

Fix will be to change Si5351mcu::setFreq()

if (omsynth[clk] != outdivider) {

The above line needs to additionally check R value against a new cached version of that variable.

Discovered in implementing a test harness for Issue #8.

Great library! That you were able to include as much functionality as you did with as small a footprint is amazing! I have one suggestion for a feature to add, and that is the ability to enable or disable the spread spectrum feature. I know that feature is implemented in the 1.4.X version of Adafruit's library, but your library is much better and I'd love to see that feature added.

Hi Pavel,

I found this library and it seems just what I need. I am using a "China" Attinny85 board with an original Adafruit SI5351 breakout board.

I tried a simple program to run 1 clock (0) at 16 Mhz. However when I measure I get an output of 14.8 Mhz instead. I think the Si.init(25000000); command seems to be ignored somehow (The Adafruit uses a 25Mhz crystal.

When I use Si.init(); I get also 14.8 Mhz on the output.

Am I doing something wrong ?

Thanks !

And that leds to jitter/errors on the output.

This error was identified by DWaite and notified me directly, thanks to him for this.

DWaite also provide an effective fix, just disable the spread spectrum register on the initialization phase.

Feature request: a way to control the CLK0 and CLK1 outputs on or off independently.

Just for tuning/setup or for example CW generation via BFO carrier on either CLKx

It should be possible to run both clock 1 and clock 2 at the same time if they are set to the same frequency. Why do this? So they can be run 90 degrees apart in phase to drive an I/Q demodulator. It seems that just loading the phase registers with the correct constant and having the PLL run at an even multiple of the desired frequency should do this according the the eitherkit library readme file.

In the code is says

if (outdivider < 6) {   // low: below 6

but this limits the max output frequency to 150 MHz with maxPLL of 900MHz.

Should it not be

if (outdivider < 4) {   // low: below 4

From section 5, Fig 7 on data sheet

"A write burst operation is also shown where every additional data word is written using to an auto-incremented address."

Hey,
I just tested the library on my ESP8266 board.
It had just one type specifier error here:

Is freq supposed to be an uint32_t by chance?
Changing it to that fixes compilation :)

The library has no provision for a bad communication or even the IC not present, the sketch will simply hang and will not work.

It must has a way to alert the user that the IC in not there or even that there is no IC. In it most basic form it must not hang the full sketch for this.

When I upgraded https://github.com/ramapcsx2/gbs-control to the latest library 0.7.1 (cbbd806) and built it in Arduino v1's "Compiler warnings: All" mode, I got many new warnings originating from this library.

I found that the library's header file includes useless const qualifiers on return types, as well as non-pointer scalars (useless in forward-declarations but not definitions), which trigger compiler warnings. Additionally, the source file reg_bank_26 etc. includes bit-shifted integers in a uint8_t array.

I've tried fixing the warnings in my vendored copy, at ramapcsx2/gbs-control#440. I decided to remove unnecessary consts in the header, and suppress -Wnarrowing in the source file rather than fixing the warnings, because adding uint8_t casts was visually harder to read and edit (making the code worse than before).

I also removed trailing whitespace in that PR. Is this something you want to fix upstream to cleanup the code formatting, or leave it in to avoid creating large diffs?