Bumping CPU clock

[mryndzionek]

We are slowly climbing towards 100% of DSP core load. I think we should consider overclocking. Been experimenting with this some time ago and it seems we can safely bump the frequency by 100MHz. I was testing the range 225MHz to 255MHz. Only few milliamps increased current consumption.

[penfold42]

pico or pico 2 ?

Is the cpu clk separate from the PIO running the NCO ?

[mryndzionek]

pico or pico 2 ?

pico

Is the cpu clk separate from the PIO running the NCO ?

It's not separate, but I think the clock.py script can handle it, i.e. compute the right dividers. The accuracy doesn't look worse.

[dawsonjon]

Cool, it's really good to know that we can successfully overclock by so much. Its certainly something that we should keep in mind for the future. I know that the pi-pico is known for its ability to be overclocked, but it is highly desirable to stay within the manufacturer's specification which will take variations in temperature and manufacturing process into account. This might be important if the code was ever used in a commercial product for example. I'm keen to avoid overclocking if we can help it, and would much rather look for opportunities to simplify the code if at all possible.

[mryndzionek]

rather look for opportunities to simplify the code if at all possible.

Haha! Might be difficult.

[MrSVCD]

Is there any possibility to split the workload in half (or 1/3+2/3)?
And if it is possible: Since it is a receiver (so far) a small buffer causing a delay would not be fatal. This would allow the UX core do some of the work without the real time need that the current DSP core have.

I am just guy guessing here since I am a happy user.

On the other hand: If you want to make a commercial product out of this, the RP2354a/b would be a good choice since it has the flash built in like "normal" micro controller.

[dawsonjon]

I don't think it's quite as bad as it looks, and there is still lots of potential to add new features.

The x32 decimation really helps, and adding code after the decimation doesn't have a huge impact on CPU usage. There is also potential to decimate by a further factor of 2 either before or after the modulation depending on the mode, which might be useful if we wanted to do some more sophisticated audio processing.

We can also get a massive speed up by filtering in the frequency domain, rather than the time wherever possible, and I think there is potential to further exploit this.

Transmit functionality shouldn't cause too many problems either, because we can disable the receiver when transmitting, the same would be true for features like audio playback.

There may well come a point where we can't fit all the functionality in a Pico (I'm thinking things like FT8 decoding). At this point it would probably make sense to make an enhanced pico2 version with extra features, we will probably need the extra flash and RAM too.

I don't have any specific plans for a commercial product, but a kit version based on a pi pico is frequently requested...