Topics

UPDATED bitx40mcu, bitx40 sketch using the Si5351mcu lib.

Pavel Milanes Costa <pavelmc@...>
 

Hi to all again.

First sorry, I have to go offline for a while due to a backbone health issue: doctor's give me a full rest period and I was the past week on a bed watching TV and wasting some time.

Before going offline I got a few hits, requests and critics about my Si5351mcu lib; for everybody's joy I have put them together and I have just updated the Github repo with the latest version. (https://github.com/pavelmc/Si5351mcu)

I have folked and modified the vanilla bitx40 code from farhan's repository to work with this lib and you can get it here: https://github.com/pavelmc/bitx40mcu

This sketch will just work, you don't need to mod your hardware, etc... just grab the Si5351mcu lib from https://github.com/pavelmc/Si5351mcu put it on your lib folder and compile/upload the code of the bitx40mcu sketch

Benefits you will get:

* Smaller code (Even smaller than the previous version, by ~400 bytes :-D )

Original bitx40 firmware is 16496 bytes long (51%) of an Arduino UNO, the version with my lib is 9294 bytes (28%) of an Arduino UNO

That's a 56% of firmware size reduction, that will allow some people with only small Arduino boards like the MiniPro with the ATMega168 (only 16K of flash) to use the bitx40 code for it's operation. Smaller firmware means also more room for experimentation.

* Click noise while tuning gone away...

The lib code will not produce click noise, but bad wiring practices can...

Some tips, facts and details about it you NEED to know.

1 - It uses a 27.000 MHz XTAL as original hardware.
2 - It will do the correction procedure but with a different algorithm, so you may need to calibrate your hardware again.
3 - The sketch use the Si5351 at the lowest drive (2mA/50 ohms); you can change that with the setPower() procedure
4 - First do a calibration procedure as usual with the mainstream Randuino code, please note that the calibration procedure WILL HAVE CLICKS, normal operation will not.
5 - Test it and check if the annoying click noise went away.

Comments, critics and any other bad/neutral/good comments are welcomed.


73, Pavel CO7WT


El 13/04/17 a las 13:32, Pavel Milanes Costa escribió:

Hi Andrew, Thanks for answering.

Your request is high in the TODO list for this weekend...

Other users are writing about some other bugs/typos, thanks to all (I just take a short at a glance view of all the emails, I will review in detail later),

I will collect all details and come back with an improved code and lib on the weekend.

73 de Pavel CO7WT.


El 13/04/17 a las 13:25, Andrew Whaley escribió:

Hi Pavel, thanks for the example but is there any reason why the library can't support CLK2 which the Raduino uses for tuning ? This should just be a parameter change in the code compared with having to rewire the BitX just to test your code. I could test your library pretty quickly in my existing sketch if it supported CLK2. 

Thanks, Andrew



Allard PE1NWL
 

Hi Pavel,

Great work, thanks for sharing your improved library.
I will surely try this out!

One question:

"It will do the correction procedure but with a different algorithm, so
you may need to calibrate your hardware again"

In what way is the correction different from the standard library?
In the standard library the correction value is a multiplying factor (in
parts-per-billion). What kind of correction value does your library
expect?

73,
Allard PE1NWL

Pavel Milanes Costa <pavelmc@...>
 



El 24/04/17 a las 12:42, Allard PE1NWL escribió:
"It will do the correction procedure but with a different algorithm, so
you may need to calibrate your hardware again"

In what way is the correction different from the standard library?
In the standard library the correction value is a multiplying factor (in
parts-per-billion). What kind of correction value does your library
expect?

Hi Allard, thanks for asking.

Every (almost) sketch out there are using the PPM (Part Per Million) error and using (some times) complicated math* to take into account the XTAL error.

~~~~~~~~~~~~~~~~~~~~~
* Complicated math

And example from NT7S/etherkit si5351Arduino lib:


===============%<===============================
// Factor calibration value into nominal crystal frequency
// Measured in parts-per-billion

ref_freq = ref_freq + (int32_t)((((((int64_t)correction) << 31) / 1000000000LL) * ref_freq) >> 31);

===============%<===============================

Did you noted the
'int32_t' & 'int64_t' in there, that 32 & 64 bit arithmetic on a poor 8 bit micro controller unit (MCU); that's equal to big binary code at the end (firmware).

Did I mentioned that my code is optimized for 'size'?
~~~~~~~~~~~~~~~~~~~~~

Wait.... did you say XTAL error?... that's just the error from the stated "27.000 Mhz" in the xtal metal can with the real value once you get it to oscillate?

Hummm, then I can correct it just by summing/resting a int value to the reference, (light bulb on!)

In practice you have the same effect, maybe with some accuracy lost in my case you can live with it. I have tried to measure in my test the error and I not find any difference with one or the other method.

Take an example in simple plain math:

You have a sketch running and you calibrated with a ppm error of -34

Deviation is just -34 * (27.0 M/1M) = -34 * 27 = -918 Hz.

You have your xtal oscillating at 27.0 MHz - 918 hz = 26999082 Hz = 26.999082 Mhz...

What is fast/more code efficient? big math or just summing (-918 Hz) to the base freq of the XTAL.

Yes, NT7S way is more scientifically accurate; mine is more fast with some negligible error, an error that for hamradio homebrewing on SSB/CW in not detected by human ear.

That's why I have used this method against the mainstream ppm method, smaller and efficient code.

Speaking of that, my code can account for errors from +/- 65.535 Khz, that for a 27 Mhz xtal must be sufficient.

73 de Pavel CO7WT.

Allard PE1NWL
 

Dear Pavel,

thanks for you reply.

So in your library the correction value is an offset (in Hz) that is added
to the Xtal frequency, rather than a multiplying factor (in ppb). Correct?

73, Allard PE1NWL

Pavel Milanes Costa <pavelmc@...>
 

El 24/04/17 a las 15:43, Allard PE1NWL escribió:
Dear Pavel,

thanks for you reply.

So in your library the correction value is an offset (in Hz) that is added
to the Xtal frequency, rather than a multiplying factor (in ppb). Correct?
Yes, as simple as that.

The two way are the same at the low level, but this is computationally simpler/easier.

73 Pavel CO7WT.

Allard PE1NWL
 

Pavel,

thanks, I've just quickly tried your example sketch bitx40mcu, along with
your library Si5351mcu. It compiles OK but it doesn't work on my standard
BITX40 that uses the CLK2 from the Raduino.

It seems there is no VFO signal coming from the CLK2 output.

I haven't done any troubleshooting yet, this is just my first observation.

73, Allard PE1NWL

Pavel Milanes Costa <pavelmc@...>
 

Hi Allard, let me recheck the code...

It can be the latest addition of the enable/disable functions last night (that's the only change since I tested it on real hardware)

I will be back.

El 24/04/17 a las 17:02, Allard PE1NWL escribió:
Pavel,

thanks, I've just quickly tried your example sketch bitx40mcu, along with
your library Si5351mcu. It compiles OK but it doesn't work on my standard
BITX40 that uses the CLK2 from the Raduino.

It seems there is no VFO signal coming from the CLK2 output.

I haven't done any troubleshooting yet, this is just my first observation.

73, Allard PE1NWL



Pavel Milanes Costa <pavelmc@...>
 

Yes, confirmed.

I put together my own randuino like setup and it's not working...

I will review it in the coming days now that I have a randuino like breadboard hardware setup.

I will try to make a hybrid sketch between my arduino-arcs and the bitx/randuino hardware, to allow randuino users to try all the features in the arduino-arcs project; time... time is the problem...

73.

El 24/04/17 a las 17:02, Allard PE1NWL escribió:
Pavel,

thanks, I've just quickly tried your example sketch bitx40mcu, along with
your library Si5351mcu. It compiles OK but it doesn't work on my standard
BITX40 that uses the CLK2 from the Raduino.

It seems there is no VFO signal coming from the CLK2 output.

I haven't done any troubleshooting yet, this is just my first observation.

73, Allard PE1NWL



Pavel Milanes Costa <pavelmc@...>
 

Hi,

Tests shows that it's a problem with the lib, I assumed that the lib works with a 27 Mhz xtal, raduino uses 25 Mhz and the internal max PLL VCO is way beyond the range of the max with a 25 Mhz xtal, the the PLLs VCO are unlocked and output is disabled internally.

I wrongly used 27 Mhz in my early tests, that's why it don't worked in latest tests, when I was using a 25 Mhz xtal.

I will update the lib to work with any xtal you pass to it withing specified range (Max PLL VCO will be dynamic)

A question for the group:

The 25 Mhz xtal is the standard for the raduino?

There are raduinos out there with 27 Mhz XTALs?

73 de Pavel CO7WT

El 25/04/17 a las 09:58, Pavel Milanes Costa escribió:
Yes, confirmed.

I put together my own randuino like setup and it's not working...

I will review it in the coming days now that I have a randuino like breadboard hardware setup.

I will try to make a hybrid sketch between my arduino-arcs and the bitx/randuino hardware, to allow randuino users to try all the features in the arduino-arcs project; time... time is the problem...

73.


El 24/04/17 a las 17:02, Allard PE1NWL escribió:
Pavel,

thanks, I've just quickly tried your example sketch bitx40mcu, along with
your library Si5351mcu. It compiles OK but it doesn't work on my standard
BITX40 that uses the CLK2 from the Raduino.

It seems there is no VFO signal coming from the CLK2 output.

I haven't done any troubleshooting yet, this is just my first observation.

73, Allard PE1NWL





Jerry Gaffke
 

All Raduinos built by hfsigs have a 25mhz crystal:  http://www.hfsigs.com/bitx40v3_circuit.html

Some people are using other Si5351 based breakout boards:

    https://www.etherkit.com/rf-modules/si5351a-breakout-board.html

    https://www.adafruit.com/product/2045

    http://qrp-labs.com/synth.html

There's probably others.   The first two above have a 25 mhz crystal, the third has a 27mhz crystal

The Si5351 datasheet says the crystal should be be between 25 and 27mhz.

The datasheet also says you could use an external reference clock of anything between 10 and 100 mhz.  

Many TCXO's and and lab quality reference oscillators operate at 10 mhz. 

I suggest you allow the user to specify the reference clock frequency at initialization to be anywhere between 10 and 100mhz.

Jerry, KE7ER


On Wed, Apr 26, 2017 at 06:54 am, Pavel Milanes Costa wrote:

Tests shows that it's a problem with the lib, I assumed that the lib works with a 27 Mhz xtal, raduino uses 25 Mhz and the internal max PLL VCO is way beyond the range of the max with a 25 Mhz xtal, the the PLLs VCO are unlocked and output is disabled internally.

I wrongly used 27 Mhz in my early tests, that's why it don't worked in latest tests, when I was using a 25 Mhz xtal.

I will update the lib to work with any xtal you pass to it withing specified range (Max PLL VCO will be dynamic)

A question for the group:

The 25 Mhz xtal is the standard for the raduino?

There are raduinos out there with 27 Mhz XTALs?

 

Pavel Milanes Costa <pavelmc@...>
 

El 26/04/17 a las 10:17, Jerry Gaffke via Groups.Io escribió:

All Raduinos built by hfsigs have a 25mhz crystal: http://www.hfsigs.com/bitx40v3_circuit.html

Some people are using other Si5351 based breakout boards:

https://www.etherkit.com/rf-modules/si5351a-breakout-board.html

https://www.adafruit.com/product/2045

http://qrp-labs.com/synth.html

There's probably others. The first two above have a 25 mhz crystal, the third has a 27mhz crystal
Many thanks for the explanation Jerry, very complete reference for my goal.

The Si5351 datasheet says the crystal should be be between 25 and 27mhz.
That's why I will make the Max value of the PLL VCO of the lib dependent on the xtal you use, I found a few 26.134 Mhz Xtals in my junk box I will try to test the new lib.

The datasheet also says you could use an external reference clock of anything between 10 and 100 mhz.
That's taking into account that if lower than 25 Mhz the max freq output will be reduced (as max PLL VPC freq will be limited) and if greater than 27 Mhz you will need to trigger tome internal division bits to get it at the end in the 25 to 27 Mhz...

I will kep it simple and assume a xtal is on the 24 to 30 Mhz and launch and make it not working beyond that limit. (I have a few 24 & 28 Mhz xtals to test that)

Many TCXO's and and lab quality reference oscillators operate at 10 mhz.

I suggest you allow the user to specify the reference clock frequency at initialization to be anywhere between 10 and 100mhz.
That's my intention, by default 27 Mhz and if you user a different xtal then you have to pass it on the init function.

Jerry, KE7ER
Cheers Pavel CO7WT.

Jerry Gaffke
 

According to AN619, the VCO operates between 600 and 900 MHz, regardless of the reference clock or crystal we provide.  PLLA and PLLB have dividers appropriate for any reference clock between 10mhz and 100mhz to steer the VCO into the specified range, I doubt the reference clock choice affects the possible output frequencies.

However, the datasheet does say that only the Si5351C has provision for the external reference clock, the Si5351C is in a 20 pin QFN package and is way way expensive (around $10 USD), so I doubt anybody on this forum would consider using it.  ;-)    As far as I know everybody here is using the $1 USD Si5351A in the 10 pin MSOP, which is restricted to using a reference crystal between 25 and 27 MHz. 

Jerry, KE7ER


On Wed, Apr 26, 2017 at 07:30 am, Pavel Milanes Costa wrote:

That's taking into account that if lower than 25 Mhz the max freq output will be reduced (as max PLL VPC freq will be limited) and if greater than 27 Mhz you will need to trigger tome internal division bits to get it at the end in the 25 to 27 Mhz...

 

Jerry Gaffke
 

Though the Etherkit breakout board with an Si5351A has the option for a 25mhz TCXO, so it is driving an external clock into what SiLabs says is a 25-27mhz crystal oscillator.  The C part allows you to switch between the crystal oscillator and an external reference.  Driving what is meant to be a crystal oscillator from an external oscillator is typically allowed on this sort of part.  I've found the Si5351 documention to be full of omissions and outright errors, it's quite possible we could drive the Si5351A with an external clock between 10 and 100 mhz in spite of what the datasheet suggests.  Maybe they went cheap on reviewing the documentation for a part they sell for $1, the higher end parts such as the Si5338 are more thoroughly described and much of that material applies to the Si5351.

Would not be surprising if they inverted the Si5351 drive level bits as you have found to be the case.

Jerry, KE7ER


On Wed, Apr 26, 2017 at 08:01 am, Jerry Gaffke wrote:

However, the datasheet does say that only the Si5351C has provision for the external reference clock

 

Pavel Milanes Costa <pavelmc@...>
 

El 26/04/17 a las 11:01, Jerry Gaffke via Groups.Io escribió:
According to AN619, the VCO operates between 600 and 900 MHz, regardless of the reference clock or crystal we provide. PLLA and PLLB have dividers appropriate for any reference clock between 10mhz and 100mhz to steer the VCO into the specified range, I doubt the reference clock choice affects the possible output frequencies.
Hi Jerry, the 600 to 900 Mhz are suggested for the 25 to 27 Mhz range.

There is a multiplier constraint that when you calculate it for 25 Mhz can't reach the 900 Mhz hardcoded in my lib; that makes the PLL unlock itself. (If I don't recall wrong it feel short for a few Mhz...)

I have the math write down at home, I'm at work now.

I pretend to make the max PLL VCO calculated from the supplied xtal in the init process and this multiplier.

73 de Pavel CO7WT

Jerry Gaffke
 

Pavel,

I haven't tried coding for the Si5351, you could be right.  However, on page 3 of AN619:

3.2. Feedback Multisynth Divider Equations        fvco = fxtal * (a * b/c)

where    a+b/c    "has a valid range of 15 + 0/1,048,575 and 90 +0/1,048,575"

How the multisynth dividers get described is one of my primary issues with the Si5351 docs.   I read that to mean  a+b/c can take on pretty much any fractional value between 15.0 and 90.0.  I looked over some of the other Si5351 libraries available a couple years ago and concluded that the Si5351 doc did not adequately describe the the multsynth dividers.  However, a+b/c can take on non-integer values, with the fractional part having a resolution down to one part in a million.  It is not just a simple divider.   As the Si5338 docs describe, this is done by having a tapped delay line that follows a divider jumping between two adjacent integer values, some math is done for each outgoing clock edge to determine the optimum delay line setting to minimize jitter for that particular edge.

Since Etherkit is successfully using an external 25mhz TCXO, I suspect fxtal on an Si5351A could successfully be driven by an external oscillator with anything between 10mhz and 40mhz as suggested at the top of page 3 of AN619.  At 10mhz the required range for a+b/c would be between 600/10 = 60.0 and 900/10=90.0.  At 40mhz, the required range for a+b/c would be between 600/40= 15.0 and 900/40 = 22.5.    That agrees nicely with the range of 15.0 and 90.0 stated previously for a+b/c.  If using a crystal, it must be between 25 and 27mhz just to make sure the internal oscillator starts up properly.  If using the external clock pin on the Si5351C (that expensive 20 pin QFN), you can have an external clock of up to 100mhz, using CLKIN_DIV to bring the reference clock down somewhere between 10mhz and 40mhz.

But I am not actually trying to program an Si5351 like you are.  Just reading some very confusing docs.  I am curious what multiplier constraint you see an issue with.  Getting our own Si5351 library going so we can reduce code size and smooth out any tuning disruptions for our particular application should prove valuable here.  Especially given the constraints imposed by the Nano processor board.

Jerry, KE7ER 

 

 On Wed, Apr 26, 2017 at 08:32 am, Pavel Milanes Costa wrote:

There is a multiplier constraint that when you calculate it for 25 Mhz can't reach the 900 Mhz hardcoded in my lib; that makes the PLL unlock itself.