NanoVNA-H4 radio remote trial #1 – HC-05 Bluetooth described intial tests on a Bluetooth remote connection to a NanoVNA-H4 using an inexpensive HC-05 adapter by hc01.com.
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.
I have seen reports that the Bluetooth module can be fitted inside the case. At this stage I am reluctant to do that for several reasons, EMC being one, and a convenient means of turning the power off to the Bluetooth module is another (it might be useful if one of the IO pins signaled that the UART interface was selected).
NanoVNA firmware changes
Dislord made changes to add compression of the screenshot data transfer using a run length encoded (RLE) compression scheme (the capture rle command). This reduced the size of the data transfer from 300kB to around 50kB depending on screen content, and made transfers over a 38400pbs link practical.
Data channel error analysis
The data channel is the path from the NanoVNA to the receiving application software.
NanoVNA UART
The NanoVNA’s UART port is a simple three wire serial port (GND, Tx, Rx) with ASYNC encoding. There is no hardware flow control, no error detection.
The prototype used a short unshielded connecting cable for GND, Tx, Rx, and Vcc.
If the connecting cable is short, there should be only a very small risk of bit errors. That may be worse if the system is subject to high intensity electromagnetic fields.
Simple bit errors that do not result in loss of an entire byte will corrupt the data, and those corruptions to some bytes of the encoded data may be detected as invalid values. Some bit errors will go undetected and be carried through as corruptions of the decoded image. This is no means provided in the data to detect the latter condition.
Bluetooth link
The Bluetooth link segment provides a reliable link at potentially very high air speed. I say potentially as it is a radio path subject to interference and loss of signal strength due to obstructions and excessive path length.
There should not be data corruptions over the Bluetooth link itself, but overrun of the input buffer is an issue.
Whilst the HC-05 appears to contain a sizeable input buffer, it is not sufficient to hold the entire screenshot transfer and so there is a risk of buffer overrun if the Bluetooth channel throughput slows. Buffer overruns would result in loss of complete bytes, one to many.
Loss of complete bytes will very likely result in failure to decode the RLE structure.
Receiving application
Because the end to end link is not a ‘reliable link’, the way in which the receiving application handles apparently lost or corrupted data is important, and there is no ‘standard’ way to do that.
Conclusions
The HC-05 Bluetooth solution is usable. Screenshots are practical with later firmware that supports compressed image files.
At the limits of radio coverage, communications timeouts will make the link unusable.