开云体育

Hi Jerry, read inline.

Pavel,

I looked over you Si5351 library. ?I like that it is kept simple and easy to understand.
I think it could be a good starting point for a stripped down library specific to the Bitx40.

I'm working with Allard to make a folk of it with the exact interface of the mainstream Si5351 that is in use now, to make them interchangeable by just changing the declaration (include), not the entire code; that will help the transition a lot.

The main goal is KISS, that's why the name: tuned to MCU size & needs.

It operates the VCO at the highest acceptable frequency (near 900 mhz max) that is an even multiple of the desired output frequency, The even multiple of two allows the output multisynth divider to always operate in integer mode, which reduces phase noise and simplifies programming those output multisynth registers.

And give the "2 of 3" effect commented on the Readme.md file...

Given the vco frequency fvco and the 25mhz crystal oscillator frequency int_xtal, all that remains is to find non-negative integers a, b and c with b less than c such that ? fvco/int_xtal == (a + b/c)?

Your code to do this has one floating point number f which is used in the computations of a, b, c.
I believe that is the only place in the entire sketch where floating point is used.
The amount of flash consumed would be reduced considerably if we could do without floating point.

Good point, I must confess, the main library idea was not mine, I borrowed ideas all over the Internet from several GPL libs out there for PIC, AVR and others about the Si5351 (see the lib headers)

My contribution was to get it able to drive all the outputs, control the power an pack it on the form of a lib for the Arduino, so improvements like this may happen in the future, I'm going to try your code and get back soon.

Thanks!

(Note, I have not tried either your code or my integer only code on Si5351 hardware,
I don't have access to my Bitx40.)

The integer only code above should give accurate frequency synthesis better than 100ppb,
similar to your original code. ?It is possible to gain another factor of 5 or so in the accuracy
of the computations for (a+b/c) by going to 64 bit arithmetic, but we have already exceeded
the short term stability of our 25mhz crystal oscillator using 32 bit arithmetic, so not much point.

Exaclty: there is no point into looking extreme "software" accuracy when a cheap 25.000 Mhz xtal can't keep up, so any firmware space spend on that is wasted firmware space.

Any reference to Jason lib here is intentional, at least for our use case it's true.

I know that there must be applications where that lever of accuracy is needed/desired, and a lib like that must exist, but that's not our case.

The above code for finding a, b and c could be applied to the output multisynth dividers without any change.
In this case we are looking at the ratio of the vco to the output clock, instead of vco to 25mhz crystal oscillator.
On the bitx40, I'd tend to make CLK2 the VFO (as it is now), and CLK0 the BFO, each operating from a separate VCO.
The third output CLK1 could operate from the same VCO as the BFO (since the BFO rarely changes in frequency) and could be set to well within a Hz of the desired frequency using the output multisynth divider.

No, if you use integer mode and use a schema as simple as this lib uses you can't use the third output, as the PLL is recalculated every time for any output that is using it.

That's the "2 of 3" idea in the Readme.md, I have tried it and making all the 3 outputs working will require more code space (bigger lib) and my main goal is KISS (Simple/Small).

There is no such thing as "Free lunch"...

Perhaps I don't understand what you are doing on the S meter, but looks like the two diodes are drawn backwards.

Ha!!!!

It's true, they are show in reverse, that the late hours spent on it playing back... sorry.

My mistake, I will correct it ASAP.

[Github repo updated with the correct diode direction]

Does your circuit improve on what Don Cantrell posted here??
? ??
Don shows a 1n32, a part I am not familiar with. ?Perhaps he meant 1n34a, that germanium diode would
be considerably more sensitive than a 1n4148. ? A schottky diode such as the Bat54s would also work.
As Don notes, his S meter is not very accurate.

Yes, for the diodes any germanium/schottky diodes will make it more sensitive in the low levels. (BAT54 will work better)

I don't have any BAT/Germanium at hand when making the hack, so the ubiquitous 1N4148 took place.

Don's circuit is a simple detector, mine is a doubler detector; mine will give ~twice as voltage as Don's circuit in the same conditions.

In my test a simple detector will give ~3 volts in presence of a 100W signal at 1km from my house, the doubler gives ~6 volts for the same signal.

With the doubler we has more dynamic range, and the series resistor is to limit the over-voltage beyond 5.0 volts (the input pin has a diode and will make the pin sink current beyond the 5.2 V to the +Vcc rail, so it's there to make it safe for strong signals)

Also, be aware that one S unit is a difference of 6 dB in signal strength, an S meter ideally has a logarithmic response. A really good (but relatively expensive) way to implement this would be to use an AD8307 or AD8310.

Sure the S-meter will show "relative" output power, not accurate in the sense of one S per 6dB, but some meter is better than none.

Maybe some people in the list has the proper equipment to make a table of ADC values (input volts) vs. dBuV at the antenna input, with that info making a software mapping to match one unit per 6dB will be trivial... (and also will help in the AGC control)

And a AD8307 or AD8310 will be a hammer to break an egg, but hey: it's a valid solution.

Best Regards,
Jerry Gaffke, KE7ER

Thanks for your ideas and mistake findings, that's an example that Together Everyone Achieves More: TEAM

73 de Pavel CO7WT.