Strange calculus, need help

Header of program:

//volatile uint32_t LSB = 219850000ULL;
//volatile uint32_t USB = 220150000ULL;
volatile uint32_t LSB = 1199850000ULL;
volatile uint32_t USB = 1200150000ULL;
volatile uint32_t bfo = LSB; //start in lsb

Calculated and function call:

uint32_t vco =bfo-(vfo * SI5351_FREQ_MULT);
si5351.set_freq(vco, SI5351_PLL_FIXED, SI5351_CLK0);
//you can also subtract the bfo to suit your needs
//si5351.set_freq((vfo * SI5351_FREQ_MULT) + bfo , SI5351_PLL_FIXED, SI5351_CLK0);

Serial.print("bfo : ");Serial.println(bfo);
Serial.print("vfo : ");Serial.println(vfo);
Serial.print("mult : ");Serial.println(int(SI5351_FREQ_MULT));
Serial.print("vco : ");Serial.println(vco);

When i call the si5351.set_freq with the old smaller values for usb/lsb->bfo (2.2Mhz is the result)
and call the function with (vfo * SI5351_FREQ_MULT) - bfo then it works.

But as the frequency is 'inverted' when using this, i am now referencing this in electronic terms versus the IF frequncy of around 12Mhz (usb/lsb slight frequency shift). So roughly 12Mhz-VFO (on the display) would result in 5Mhz clock oscilator setting.

Looking at the individual values they are what is expected.

However if i print the calculus (int) type casted for what is now vco (compiler gives long long int...ambigues errors otherwise), the results of the calculation are negative. Strange as the result with the calculation via vco now gives a solid result of 4.9985000.

Is there some kind of overflow occuring when using the calculus direct in the function call?

help or advice appreciated.

You need to post the complete program so we can see what the functions do.

...R

Don't see any options to attach a file (ino) so you have the whole program.

How can i do this?

PA3FAT:
Don't see any options to attach a file (ino) so you have the whole program.

How can i do this?

Use the Reply button rather than Quick Reply

...R

volatile uint32_t LSB = 1199850000ULL;

?

I don't get this. How does 1199850000ULL fit in an unsigned int?

Added the full sketch.

With the old commented values for usb/lsb–>bfo

(vfo * multiplier) -bfo it works (7…*100) - 222… resulting in clk0 becomming 480… (4.8Mhz)

but when i do

bfo (approx 12) - (vfo * multiplier) it isn’t working.

As stated calculating via VCO variable and inspecting it in serial monitor i see correct values and clk0 would become 500…(5Mhz)

if the 119…value fits in a unsigned int. Don’t know but when printed it shows the correct value.

so the sequence how i actually calculate vco (intermediate variable) or direct in the function call seems to differ, where the result slightly differs.

Receiving 7.0 Mhz should give a 5Mhz result compared to IF of 12Mhz.
Receiving 7.2 Mhz should give a 4.8Mhz result compare to IF of 12Mhz.

That’s the only reason i altered the calculus of ‘vco’.

MultiFeaturedVFO_new.ino (14.9 KB)

a video of what we are trying to achieve

groundfungus:
?

I don't get this. How does 1199850000ULL fit in an unsigned int?

The variable type is unsigned long, not int. Though why the value is typed unsigned long long is mystery.

@PaulS,

Paul if you could point me into the direction how to do it properly that would be great.

The sketch is found on internet for many people are experimenting with the SI5351 chip/board.

I see versions using UL also. Any type will do.

There is for what i can see now one limit. The SI5351 (Etherkit_SI5351) library is external.
The constant SI5351_FREQ_MULT is defined in the external library (v1.1.2, v2.0 experimental but we are not using it yet).

The value for:
volatile uint32_t vfo = 710000000ULL / SI5351_FREQ_MULT; //start freq - change to suit
is used througout the program. And devided first by SI5351_FREQ_MULT(value=100) giving a 7000000 which matches the basis for the actual display 7.000.000 regarding the actual listening frequency. It is via step setting incremented with +/1, +/-10 etc to change the frequency in the readout.

So any type definition that maintains the used frequency/bfo is fine otherwise the rest of the program needs to be adapted.
If this resolves my unexplainable not working calculations it would be great.

the first parameter of SI5351.set_freq is of type uint64_t
second param als unint64_t (parameter defined in same library)
third is an enum of also defined construct in same library.

assume that the calculation done will fit in this as the basis is extracting two uint32_t results.

within 1 hour i will get some feedback if the intermediate vco calculus is resolving the issue.
fellow Ham in usa just woke up....

at least using vco variable as intermediate step the sketch is working.
Tomorrow test to put the calculation back into the function call.