It seems to take about 6ms to execute the set frequency function - ??si5351.set_freq(f , SI5351_CLK0); I determined this by toggling an output pin before and after this line of code. Is that normal? Is there any way to do it faster?

?

I am updating an AD9850 based CW xcvr I built a few years back. It switches the DDS from (Freq-IFOffset) on receive to (Freq) on transmit. I need to key the transmitter ON after the Si5351 has been set to the transmit freq and OFF before I set it to the receive freq. My CW element length will then be at least 6ms too short. At 30 WPM that is about 15% shorter than normal and I don’t think that will sound good.

?

I guess I could just use two clock outputs – one for the transmitter and one for the receiver, but I would like to do it all with one clock if possible. ?Thanks and 73 - Jerry - W0PWE

Most codes go to Tx at key-down (6ms delay) and stay there until more than # ms after last key-up (beyond last CW character and word-space time) then back to Rx (delay imperceptible). That delay only applies semi-intrusively to first key-down - is that too slow?

Not sure which library you are using, perhaps Etherkit?

The current code from Allard uses si5351bx_setfreq() and a frequency update takes about a dozen bytes,
or 100 bits of i2c writes to the si5351.
The i2c clock rate on the Nano is probably around 100khz, so would take around 1ms to get those 100 bits out.
Math is strictly 32 bit integer or less.

The Etherkit library does a bunch of 64 bit floating point, which will take some time on an 8bit uC. ?
And the Etherkit library may do a bunch more register writes, or may not do them as a write burst.

Might be possible to bump up the i2c clock rate to 400khz.
Tempting to try to avoid writing to si5351 registers that don't change, but I doubt this would save much if anything.
Or could convert to an si5341 and use a 20mhz spi bus, if you are really serious about this ? ;-)

Jerry, KE7ER

A quick bench test revealed an ON time delay of 800uSec using set_freq() and a 480uSec delay in turning it off with output_enable(). This was with the Etherkit version 2.0.6. I pulsed a digital pin before and after each activation of the '5351 to duplicate your test and measured with a 100 MHz DSO
I use that method at speeds up to 35 WPM without noting any difference. However others may disagree. This is not the "normal" way of turning it on, just a shortcut that works faster than the output_enable() method for me. 73, Don,ND6T

Update: The measurements I took earlier seemed odd. Further experiments (better setup) displayed actual delay for both operations are closer to 735 uSec each. Makes more sense. 73, Don, ND6T

Thanks for all the great suggestions. Looks like I have the Etherkit library version 2.01 so I updated to 2.10. This makes a noticeable improvement to around 2.5ms but I can't duplicate Don's results of 735us. I don't understand how our results could vary so widely. Could it be frequency dependent? I am switching back and forth between 7.030Mhz and 11.946Mhz.

So then I followed one of Jerry's (KE7ER) suggestions and modified my sketch to use his?si5351bx code. That was really easy to do and?si5351bx_setfreq()?took about 2ms to execute. Not bad - at 30WPM that is about 5% of the morse element length.?

Here is an ADDED BONUS.... I think Jerry wrote that code to save code space and wow did it ever. Using his code instead of the Si5351 library cut my code size from 22.4K (72%) down to 12.4K (40%). That is awesome! Thank you Jerry!! Even if I eventually decide to use two outputs for this I will stay with the si5351bx code for the code size reduction.
73, Jerry, W0PWE

I'd guess?Don is running with a faster i2c clock.
The Etherkit library supports lots of features we don't happen to need on the Bitx40.

True, and I feel fortunate to have both options available - 1. a full featured library that will do whatever you need to do and 2. streamlined code designed for this particular task.?

On Thu, Nov 9, 2017 at 08:03 pm, W0PWE wrote:

So then I followed one of Jerry's (KE7ER) suggestions and modified my sketch to use his?si5351bx code. That was really easy to do and?si5351bx_setfreq()?took about 2ms to execute

I just measured it on my own Raduino, and found that Jerry's routine takes 1768 us, to be precise.

73 Allard PE1NWL

开云体育

You can try also this lib, it's focused on small size and optimizations for MCU operations

73 CO7WT.

Thanks for all the great suggestions. Looks like I have the Etherkit library version 2.01 so I updated to 2.10. This makes a noticeable improvement to around 2.5ms but I can't duplicate Don's results of 735us. I don't understand how our results could vary so widely. Could it be frequency dependent? I am switching back and forth between 7.030Mhz and 11.946Mhz.

So then I followed one of Jerry's (KE7ER) suggestions and modified my sketch to use his?si5351bx code. That was really easy to do and?si5351bx_setfreq()?took about 2ms to execute. Not bad - at 30WPM that is about 5% of the morse element length.?

Here is an ADDED BONUS.... I think Jerry wrote that code to save code space and wow did it ever. Using his code instead of the Si5351 library cut my code size from 22.4K (72%) down to 12.4K (40%). That is awesome! Thank you Jerry!! Even if I eventually decide to use two outputs for this I will stay with the si5351bx code for the code size reduction.
73, Jerry, W0PWE

-- 
73 CO7WT, Pavel.