This series of articles documents a trial of an Bluetooth link for remote operation of a NanoVNA-H4.
There are risks in fitting a radio transmitter in close proximity to RF measurement equipment. Those risks can be mitigated by just not doing it, but with care, it may be possible to achieve the utility of remote operation without degradation of the instrument.
The Bluetooth adapter is an external HC-05 adapter, <$5 on Aliexpress, configured for 38400bps.
The trial started with NanoVNA-D v1.2.35 firmware.
This should be straightforward as people claim to have this working.
Note than HC-05 modules are not all the same, and different performance may be obtained from different manufacturers products and different firmware versions. The one tested here was labelled hc01.com… but it is Chinese product and Chinese are copyists, it means little. Firmware reports version hc01.com v2.1.
AT+VERSION +VERSION:hc01.comV2.1 OK
The module uses a CSR BC417 Bluetooth chip. The Windows end is unknown, but relatively new.
Some loopback throughput tests using Ezurio terminal
Above, results hint high protocol overhead.
Above, close to ideal throughput for async encoding.
Problems encountered
System hangs sometimes
It sort of worked, but there was excessive delay in running a single scan from NanoVNA-App, though continuous scanning worked ok (after the same start up delay).
To help locate the problem:
- a test was run of the UART connection to the VNA using a USB to serial adapter, so a wired connection; and
- an extended bit error rate test was run on the Bluetooth link looped back at the HC-05.
Both comms links were reliable so the problem was the NanoVNA or NanoVNA-App.
Throughput at 38400 was 77%, quite close to the async encoding limit of 80%. Throughput at 230400 was 42%, not much better than half the async encoding limit of 80%.
A communications trace revealed that the NanoVNA appeared to hang on a pause command.
The issue was reported to Dislord, and the defect in NanoVNA-D v1.2.35 firmware fixed quite quickly (NanoVNA-D v1.2.37).
Downloading screenshots fails
I have a script set that are derived from a script published by Ho-Ro, and my script failed on the slow link.
That turned out to be a read timeout as the transfers are quite large, eg 307k which takes about 80s on an error free uncongested Bluetooth connection at 38400bps.
Higher speeds were tried, 115200bps failed, so I reverted to 38400bps which seems reliable.
In any event, the script needs facility to adjust timeout appropriately.
To do that, a baudrate parameter was added to the script, and it calculates a timeout equal to twice the time to transfer the calculated transfer size. If no baudrate is specified, it defaults to 1s timeout.
The Python script is published at https://github.com/owenduffy/tinydevicecapture .
UART connector
For more convenient access to the UART pins, I installed a SIL 6w female header and cut a 3x18mm opening in the back for access.
Beware
I have purchased some other Bluetooth adapters, and some HC-05 that did not have the hc01.com label on the board mask and they have had low throughput.
I have a bunch of hc01.com product from more than 10 years ago, and I purchased a new one in the past weeks, the hc01.com labelled ones all perform the same as each other.
Dislord claims he measured 460kbit throughput, but the ‘genuine’ HC-05 does not deliver that throughput with my recent purchase Lenovo Windows 11 notebook.
Conclusions
This is not quite the no-brainer. The problems encountered were related to the specific firmware and my script (though Ho-Ro’s script may have the same issue). One is left wondering whether there were unresolved problems in some claimed implementations using this firmware.
That said, the prototype appears to work ok. It now needs to be packaged and some tests made of EMC including noise floor degradation.