开云体育

There has been some mention of running the NanoVNA in headless mode - ie:through the USB interface using console commands.

How much processing power would be recovered by disabling and/or removing the display and associated (ie:touch) routines through the Console?

There could be 2 versions of firmware:
1 - Disable all display routines via console command - A power-on reset restores the display
2 - A dedicated headless device with additional flash memory freed-up for other options (TDR?)

A PC, Android tablet, RaspberryPi or other computing device could talk to the hardware through the USB interface and run Python or other applications.

Of course, the Pi could also use the SPI lines but that would be a much bigger task on the Pi side in terms of re-inventing/porting all the low level signal processing routines.

Comments?

Larry,

After a "pause" command all scanning is suspended and only the UI and communication tasks run interrupt driven.
Using the "scan" command I implemented no updating of the ui is done while measuring.
So CPU load is already dramatically reduced.
For a headless device there is no need to do TDR in the NanoVNA so there is no clear need to free up code space.

Or am I missing something?

Erik,
The routines that refresh the LCD take up a certain amount of CPU processing.
Even though the scanning is paused, the LCD is still being refreshed via the SPI lines - no?
Does your firmware version turn off all display refresh ie:display goes blank? (I haven't had a chance to install/play with it yet).

Can we remove the display routines altogether and, let's say, increase the scanning speed/etc.
Would you be able to benchmark your version with the display on while scanning and then completely disabled and scanning?

In other words, what can be gained on the device by modifying the F/W to produce a headless unit? Anything?

Regards,
Larry

"Pause" command is in the standard firmware.
Upper scanning speed seems to be limited by the setup time of the SI5351 (somewhere between 3 and 10ms) and the 2ms (The source is contradicting, comment says 5ms but 96 at 48khz is 2ms) data that needs to be acquired for each point. Moving to 1ms data will increase the noise