I was looking around in the code an noticed that the FPU is not enabled, but there is some compile option available.
I rebuild and did some checks and my unit supports the FPU, I ordered from tindie, with SOL and cables.

Does anyone have a clue?

Just speculating: the FPU is probably single precision, but the
calculations require double precision. I'm not sure an FPU will speed up
double precision calculations.

> I was looking around in the code an noticed that the FPU is not enabled, but there is some compile option available.
> I rebuild and did some checks and my unit supports the FPU, I ordered from tindie, with SOL and cables.
>
> Does anyone have a clue?
>
>

I think not all devices have the FPU because there are still early
batches of the GD32F303 from 2017 circulating in the market (those
didn't have the FPU because of chip errata). It was found that execution
speed without FPU is adequate so I have it disabled by default in the
firmware releases to accommodate NOS parts.

https://webcache.googleusercontent.com/search?q=cache:Kkmiig-j0uEJ:https://www.amobbs.com/thread-5719892-1-1.html+&cd=1&hl=en&ct=clnk&gl=us&client=firefox-b-e

Sorry I cannot read Chinese, but Google translate helped enough to figure out what went wrong: No FPU support.
Anyway my nanovna2 (I guess mine is one of the first production runs as it was the second batch on tindie) has a proper FPU. I guess testing for FPU is not done during QA?
So we will never know if all nanovna2 have an FPU. Bummer.

And Reinier I did a quick grep thru the code and did not see the word double. Only float. It would have surprised me as the ADC is only 12 bit.

While at it. there is support in the current code for multiple XO frequencies. Is that really anticipated?
Also running the Si5351 on 24Mhz is out of spec according to the datasheet, but then again it assumes a crystal not an XO.

In my prototypes about half the chips had a FPU and half did not. Each
manufacturer sources parts differently and I assume that shenzhen market
parts will always find a way into the supply chain, but it is also
possible that old stock is already flushed out by now. The test setup
does check for FPU, but QC is not gated on it. I can ask the
manufacturer to record FPU statistics next batch.

In V2 all sweep timings are fixed and interrupt driven, so a firmware
build either "passes timing" or it doesn't, an optimized firmware will
not sweep any faster than an unoptimized one, but if timing deadlines
are not met you will simply see garbage on the screen. Therefore I
recommend only enabling the FPU in "aftermarket" firmware variants that
actually require it; optimizing code beyond meeting deadlines doesn't
make a difference.

I don't think any oscillator frequency other than 24MHz will be used in
production, since 24MHz was found to give lowest ADF4350 phase noise.
It's always a powered oscillator and not a crystal.

On 28/05/2020 02:51, pa3wle@gmail.com wrote:

> Sorry I cannot read Chinese, but Google translate helped enough to figure out what went wrong: No FPU support.
> Anyway my nanovna2 (I guess mine is one of the first production runs as it was the second batch on tindie) has a proper FPU. I guess testing for FPU is not done during QA?
> So we will never know if all nanovna2 have an FPU. Bummer.
>
> And Reinier I did a quick grep thru the code and did not see the word double. Only float. It would have surprised me as the ADC is only 12 bit.
>
> While at it. there is support in the current code for multiple XO frequencies. Is that really anticipated?
> Also running the Si5351 on 24Mhz is out of spec according to the datasheet, but then again it assumes a crystal not an XO.
>
>
>

>
> In my prototypes about half the chips had a FPU and half did not. Each
> manufacturer sources parts differently and I assume that shenzhen market
> parts will always find a way into the supply chain, but it is also
> possible that old stock is already flushed out by now. The test setup
> does check for FPU, but QC is not gated on it. I can ask the
> manufacturer to record FPU statistics next batch.
>
We will have to live with the possibility of no FPU anyway.

> In V2 all sweep timings are fixed and interrupt driven, so a firmware
> build either "passes timing" or it doesn't, an optimized firmware will
> not sweep any faster than an unoptimized one, but if timing deadlines
> are not met you will simply see garbage on the screen. Therefore I
> recommend only enabling the FPU in "aftermarket" firmware variants that
> actually require it; optimizing code beyond meeting deadlines doesn't
> make a difference.

I have not yet figured out how the ADC is triggered. I did see some __sync code and then understood that there is a quite a large amount of code running from the ISR context. I am not sure why a __sync would help with any of this. There is no L1 caching for an M4 as far as I know. Unless DMA has some weird different memory view?
Yes performance is not an issue, code size however might become an issue (~still 50% free at the moment). And having a working FPU allows to drop the softfp code.

> I don't think any oscillator frequency other than 24MHz will be used in
> production, since 24MHz was found to give lowest ADF4350 phase noise.
> It's always a powered oscillator and not a crystal.
>

Thanks for the info, dropping that code would allow some more data to become constant and thus save a few bytes RAM and CODE. I hope I can play around with this next week.

On another subject is the ADF4350 shutdown when not in use; when using the VNA between 0 and ~140Mhz? The blue LEDS seems to stay on. And I guess the ADF4350 will consume quite a bit of power and disabling could save a bit of battery charge. Or is there a good reason to keep them on? Temperature drift?

> On 28/05/2020 02:51, pa3wle@gmail.com wrote:
> > Sorry I cannot read Chinese, but Google translate helped enough to figure
> out what went wrong: No FPU support.
> > Anyway my nanovna2 (I guess mine is one of the first production runs as it
> was the second batch on tindie) has a proper FPU. I guess testing for FPU is
> not done during QA?
> > So we will never know if all nanovna2 have an FPU. Bummer.
> >
> > And Reinier I did a quick grep thru the code and did not see the word
> double. Only float. It would have surprised me as the ADC is only 12 bit.
> >
> > While at it. there is support in the current code for multiple XO
> frequencies. Is that really anticipated?
> > Also running the Si5351 on 24Mhz is out of spec according to the datasheet,
> but then again it assumes a crystal not an XO.
> >
> >
> >
>

Well, the factory told me they almost never see the "GD32F303 early
batch" message, maybe when we actually run out of flash there can be two
releases, e.g. a nofpu variant with slightly less features.

__sync_* memory barriers also tell the compiler not to reorder memory
accesses, so are necessary since interrupt context and main context are
"simultaneous". Usually the barriers are only strictly required in main
context, but actually ISR can be preempted by another higher priority
interrupt as well.

ADC acquisition is always running in the background by the DMA
controller without any CPU involvement. It writes to a ring buffer. A
timer interrupt tim1_up_isr() calls adc_process() which processes
outstanding ADC samples. See tim1Period and dsp_timer_setup().

ADF4350 shutdown just hasn't been thought of yet, try it.

The biggest power consumer is the AD8342 mixer I think; it can in theory
be replaced with a IAM-81008 but I know for a fact that special tricks
are needed to get the same level of power supply noise immunity (the 5V
rail is noisy at LF and can not be filtered, the baseband circuitry must
deal with it).

Is factory using another firmware build then? Since the message will only come if using FPU enabled libopencm3? Or at least with the build option "GD32F3_NOFPU" not defined.

The __sync is not functional for an M4, write orders are guaranteed by volatile declaration, since the write cannot happen out of order for an M4.
The compare swap is useful, but only if an ISR is actually setting it. Perhaps switching to C++ atomic types make it more clear?

The ADF4350 has a powerdown mode, unfortunately the code is spread out over two repos. But it is doable.

Thanks for the update.

the question is what 24 megs tcxo is used and if it is worth replacing it with a better one (lower ppm value and/or lower noise)
and ... why not add a LOW NOISE 3v regulator ic ONLY for that tcxo?!? that would clean up the cw signal for sure (it now sounds a bit rough)
....
and about the display i have a question ... how much room is left in the gd32 cct6<???
if space is tight i would not be fear to replace it against a gd32f303cgt6 (same pinout but bigger memory)
now we can get a firmware with 4 inch (and more pixels to be calculated and sent to display)
for a 5 to 8 inch 800x480 display we need even more space and i do not know how much room is left
but with a bigger chip we could store calibration permanently in the chip (or add other nice gimicks in the firmware)
also more scan points (yes with a slower readout but with a finer resolution) would be possible with the cgt6 chip
so ... a big big display ... more scan points (if user wants) ... permanent storage of calibration ... and use a bit bigger chip (thats maybe needed anyway if we replace the display to an 800x480 pixel device)
WDYT?!?
greetz sigi

On Sun, Jul 12, 2020 at 03:36 PM, Siegfried Jackstien wrote:

>
> for a 5 to 8 inch 800x480 display we need even more space and i do not know
> how much room is left
>
For display not need bigger flash size. Need faster bus for send data.
Only SPI bus for this CPU possible use, and this also limit LCD display selection (no SPI bus display bigger then 4` and low cost).
Parallel interface need more pins on CPU for control

i was guessing that more pixels does need more memory ... not??

i know that more data sent over a serial port lowers the speed ... we
had a similar thingy in the mchf project ... you could use serial or
parallel port on our display and also the firmware could handle both
(stmf4 with 100 pins used) ...

the question is ... could it be done ?? even if speed would be a bit
lower ... a bigger memory could store more "pixels" for the display and
also store more "scan points" (if you really want that higher resolution
with lower scan speed) ... make it user setable

even if  5 to 8 inch display plus maybe a bigger cpu would nearly double
the price at the end ... FOR MY UNIT I WOULD DO THAT ...

i know ... 5 to 8 inch are not to be bought for 8 to 10 bucks (like the
4 inch) ... but thats not the point ...

i would like to have a big big display (it would still be a very
portable unit i think) ...

ok .. i think i have to stay with the 4 inch for now ... but if a clever
programmer ("like YOU!!") would write a firmware for a bigger display as
the 4 inch i would surely use that ...

i am NOT a clever programmer ... more power user, beta tester, hardware
guy ... (example modding adalm pluto for ham use) ... so it is complete
out of my knowledge to make such a firmware (i am lucky that uploading a
new fw is easy)

so ... "DiSlord" ... how difficult would it be to adapt the fw to an
800x480 pixel display?? ... even if such a display would cost near same
price as the v2 alone ...

could it be done (enough space left in cpu)???

greetz sigi dg9bfc


Am 13.07.2020 um 13:42 schrieb DiSlord:

> On Sun, Jul 12, 2020 at 03:36 PM, Siegfried Jackstien wrote:
>
>> for a 5 to 8 inch 800x480 display we need even more space and i do not know
>> how much room is left
>>
> For display not need bigger flash size. Need faster bus for send data.
> Only SPI bus for this CPU possible use, and this also limit LCD display selection (no SPI bus display bigger then 4` and low cost).
> Parallel interface need more pins on CPU for control
>
>
>

>i was guessing that more pixels does need more memory ... not??
Small display have 320x240 16bpp pixels, need 320x240x2 = 153600 bytes for full display data, i think 150k bytes of memory not found on any small CPU

So this ampunt of memory not used, screen divide on cells size varous, used 32x32 pixels (in v2 used 2 cell buffer for render in one, and DMA send from other)
So screen size not depend from memory

Bigger screen need more time for draw, and more time for data send

At current cpu no more free pins for display, and used SPI bus, and if for 320x240 pixels need ~50ms time for send data, for 800x480 need 5x time
yes not need update full screen every time, but render SMITCH chart - very slow

Yes possible use another CPU (like in NanoVNA-F) and use parralel 8 or 16 bit mode for faster send data on LCD...

>so ... "DiSlord" ... how difficult would it be to adapt the fw to an 800x480 pixel display?? ... even if such a display would cost near same price as the v2 alone ...
Not big problem, but need new hardware, and port this software on it. For bigger display render need only redefine screen size and use bigger font. And for new display need write new driver.

PS exist 7` displays on RA8875 driver vs SPI bus, and possible try use it.
PSS possible use raspberry Pi or something and V2 as external device

https://de.aliexpress.com/item/4000278663573.html
I think can be used on current software (RA8875 support SPI as on datasheet)

https://de.aliexpress.com/item/32978278905.html
This lt7686 - on vendor page write support SPI, but i not found datasheet on it

https://de.aliexpress.com/item/32916913295.html
https://de.aliexpress.com/item/32914924330.html
This SSD1963 not allow use SPI only parralel interface

But you shoul understand, need write driver for support it (as minimum need read datasheet, write correct init sequence and see display command and fix it usage if need)
Second - touch, i don`t know what touch driver used on this panels, if it different from current XPT2046.