开云体育

Hi to all.

Since I have now a [borrowed] real bit40v3_smd + raduino I can test and tune some things...

I have put together a test sketch based on the Allard's code version 1.15 (1.15 not 1.15.1) that has an S-meter for the RX part, I'm testing with the TX part [hardware] and playing [successfully!] with software controlled AGC...

What you get if you dare to test it:

• Full compatibility with Allard's code.
  
• Smaller code: you need to download the Si5351mcu lib, see readme and code.
  
• Smeter on RX, see the simple hardware mod in the smeter-mod.png file.
• TX power meter, is the same for the Smeter but need a hardware mod that is on test at the bench.
  
• Software support for AGC (I'm tunning the hardware/software parameters, so no schematic for now: soon...)

All this mods can be incorporated on Allard's code once they are tested and requested.

Do you dare? :

73 de Pavel CO7WT.

Where is agc_software.png ?

开云体育

开云体育

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.
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.
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.

I suggest you replace this:
######################################
    #define c 1048574;
    uint8_t a;
    unsigned long b, fvco, int_xtal;
    float f;
    ....
    a = fvco / int_xtal;
    f = fvco - a * int_xtal;
    f = f * c;
    f = f / int_xtal;
    b = f;
######################################


with something like this:
######################################
    uint8_t a;
    unsigned long b, c, fvco, int_xtal;
    unsigned long f; 		// temp variable, no longer a float
    ...
    a = fvco / int_xtal;	// find the quotient of the divide
    b = fvco % int_xtal;	// find the remainder of the divide
    c = int_xtal;
    while (c & 0xfff00000) {
        b = b>>1;		// divide by two till fits in 20 bits
        c = c>>1;
    }
######################################

(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.?

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.?




Perhaps I don't understand what you are doing on the S meter, but looks like the two diodes are drawn backwards.
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.
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.


Best Regards,
Jerry Gaffke, KE7ER

开云体育

WARNING !!!

Diodes are backward in this picture!

The original picture was corrected by now in the github repository.

Sorry by the mistake, Pavel.

with the diodes in the describes position the oputput voltage would be negative instead of powitive-- so reverse both diodes!

Henning

Am 23.06.2017 um 18:15 schrieb Pavel Milanes Costa:

开云体育

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.

Pavel,

I think your approach is best for use on the Bitx40, leave the output dividers in integer mode, adjust the VCO to change the operating frequency. ?We don't need three outputs. ?If we were to use that third output as a signal generator for debugging the rig, that could be at the low resolution we get from integer mode, just dividing down whatever is available from the CLK0 VCO. ?I plan to use CLK0 to replace the analog BFO as done on the uBitx.

However, if three high resolution clocks were required, it's possible without too much additional code. ?The third output divider would not use nteger mode
and the (a+b/c) for the output multisynth computed to create the desired output clock from one of the other two VCO's. ?Since we already have code in place to compute (a+b/c), the additional code required is mostly a matter of loading the registers. ?I am not recommending we do this, just saying it is possible if necessary.

We could simplify the code further, specific to the Bitx40, by using fixed output divider values. ?Could also remove support for the R divider and for the special case of an output frequency of VCO/4. ?But none of that saves much in code space.
?
I did simulate my integer mode (a+b/c) computation in python, seems to work fine.?

Your voltage doubler has two diode drops involved. ?It will double the voltage out for strong signals, but will require a larger minimum signal. ?I suspect Don's simple detector will work better, on an S meter we are concerned about seeing weak signals. ?It will still have to be a fairly strong signal just to get through the single diode detector. ?At relatively low signal levels, the current through the diode will be logarithmic, which is exactly what we want. ? ?At high signal levels it will be linear (limited by the resistor to ground), this could be converted to logarithmic with a table lookup in firmware if anybody cares.

Best Regards,
Jerry, KE7ER

开云体育

Check it again, I have updated the code...

73, Pavel CO7WT.

开云体育

开云体育

Video of a recording of the bitx40 + Raduino with the Si5351mcu lib working, video recorded by Alex AC7HU in FL/USA.



Just 10W of output, into a wire doublet for 40m with a homebrew manual tuner and 9m of homebrew open wire feeder, working good...

73 de CO7WT.

开云体育

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.

Hi to all.

Passing trough the process of plan and design the compatible library I found a few issues that spoil the KISS (simple and small) principle:

• Need to program dummy procedures or procedures with dummy parameters.
• Program an automatic reset() of the lib to avoid PLL unlook and click noise
• Include all sort of enums and flag vars.

That will make the lib bigger than my simple lib, and at the end we will need to change the lib on the raduino code if Allard approve it; then why not just changing the Raduino code?

So, I officially drop the idea of make a Si5351aarduino compatible folk/version, from my point of view it's worthless.

73 de CO7WT.

I think we just hack Allard's code to try smaller Si5351 solutions, or to add other features. ? Perhaps use #ifdef's so it is easy to select various features and libraries as room on the Nano allows. ? If Allard decides what we wind up with is good, he can incorporate it. ?Lots and lots of stuff in the Etherkit library we don't need, could use that flash for other stuff.

Line 307 of version 2.0.5 of the Etherkit code has the pll_reset() commented out for output frequencies less than 100 mhz. ?That's probably what was giving us tuning clicks in recent versions. ?CLK[0,1,2] all use PLLA with that VCO frozen to 800mhz, it is only the output divider msynth's that get messed with. ?An exception is made for output frequencies greater than 100mhz, but that does not apply to us.

A google search for "si5351 pll reset" suggests that Pavel's code where the VCO ?is changed with each touch of the tuning knob may occasionally need a PLL reset. ?We could reset the PLL's only on major excursions from where last reset, could read the Si5351 lock status and reset only when needed, or follow Etherkit's lead and only mess with the output dividers. ? I doubt the slight added phase noise of non-integer output dividers would ever be much of an issue for the Bix40.

One curious thing I see: ?the "c" of (a+b/c) was getting set to 0xFFFFF by the Etherkit code, now it is set to an even million so 0xF4240. ?Pavel's code sets it to 1048574, which is 0xFFFFE. ? ?Why not 0xFFFFF?

Here's python code for an algorithm to compute (a+b/c)I haven't seen elsewhere. ? All values are integers, the divides need to handle 64 bits.of dividend. ?Without the final correction to c, I get slightly better accuracy than I do with the downshifting trick of the code previously posted. ?This is about the same algorithm as what's in the Etherkit library. ?With the final correction, it is five times better.

    c = 0x100000-1
    a = v/x
    b = ((v%x)*c)/x
    c = b*x/(v%x)

Jerry, KE7ER
?