|
On Wed, Nov 9, 2022 at 04:08 PM, Erik Kaashoek wrote:
How to extract a pixel from the two byte pixel data:
const uint16_t pixel = (first received pixel byte) | (second received pixel byte)<<8;
const uint8_t red =? (pixel >> 0) & 0xf8;
const uint8_t grn = ((pixel << 5) & 0xe0) | ((pixel >> 11) & 0x1c);
const uint8_t blu =? (pixel >> 5) & 0xf8;
?
Erik, Thank you very much, but that's the easiest part. My question was more about the stream format and timing - I've reverse engineered it now using the NanoVNA source and got it working for tinySA, but the mouse click handling is still unstable at the moment and with the NanoVNA the mouse click doesn't work at all. Developed under debian stable.
Remote control for the?tinySA?- mirror the screen to your PC and operate the device with the mouse. The keys?+?and?-?zoom in and out,?s?takes a screenshot with timestamp,?ESC?quits the program.
Work in progress - the mouse click is not fully working, currently no NanoVNA support.
usage: tinySA_remote.py [-h] [-d DEVICE] [-t | -n] [-z {2,3,4}]
optional arguments:
-h, --help show this help message and exit
-d DEVICE, --device DEVICE
connect to serial usb device
-t, --tinySA use with tinySA (default)
-n, --NanoVNA use with NanoVNA (not yet implemented)
-z {2,3,4}, --zoom {2,3,4}
zoom the screen image
Martin
|
NanoVNA?uses the same code as Tiny for Remote Desctop.
On any blit or fill operation to display send area coordinates and data to CPU.
Mouse click work as serial command from CPU
|
The rest is simple
bool __fastcall TForm1::requestCapture()
{
addSerialTxCommand("capture");
return true;
}
?
bool __fastcall TForm1::requestMouseDown(int x, int y)
{
if (x > 0 && x <480 && y > 0 && y < 320 ) {
String s;
s.printf(L"touch %d %d", x, y);
addSerialTxCommand(s);
}
Sleep(30);
return true;
}
?
bool __fastcall TForm1::requestMouseUp(void)
{
addSerialTxCommand("release");
Sleep(30);
return true;
}
?
bool __fastcall TForm1::autoRefresh(bool enable)
{
if (enable) {
pauseComms(true);
addSerialTxCommand("refresh on");
} else {
addSerialTxCommand("refresh off");
}
Sleep(30);
return true;
}
?
--
For more info on the tinySA go to https://tinysa.org/wiki/
|
Martin, You are making it too complex. Use two tasks, one tinySA send task to read the mouse events and send commands to the tinySA and one tinySA receive task to decode whatever is received from the tinySA. These tasks run independent Start with one "capture" to load the initial bitmap and then set "refresh on" The tinySA will send updates of whatever has changed so there is no need to do anything intelligent at the PC side, just decode the received "bulk" and "fill" into the bitmap and display the update. The receive task may also receive echo's from the commands send to the tinySA and these can all be ignored All mouse events have to be translated into the correct mouse down/up commands and that is all. --
For more info on the tinySA go to https://tinysa.org/wiki/
|
On Fri, Nov 11, 2022 at 10:00 AM, Erik Kaashoek wrote:
You are making it too complex.
Use two tasks, one tinySA send task to read the mouse events and send commands to the tinySA and one tinySA receive task to decode whatever is received from the tinySA.
These tasks run independent
Erik, that's my problem when starting from the wrong side, I started with the terminal, then wrote a ten-liner, sent some commands and looked at the response. I should remember to build one script to through it away and start again from scratch when I solved the protocol But nevertheless I have this kind of task separation: - mouse events send? "touch"/"release" commands in the callback function (I'll go back to the simple MOUSE_DOWN -> send "touch" and MOUSE_UP -> send "release" to support marker dragging as I did in the beginning, the current click-behaviour was the useless try to solve some other instability) - the "inWaiting()" part of the state machine loop parses the incoming bytes. I have to concentrate on a more robust "bulk"/"fill" handling to ignore spurious "touch"/"release" and other responses. On Fri, Nov 11, 2022 at 10:00 AM, Erik Kaashoek wrote:
Start with one "capture" to load the initial bitmap and then set "refresh on"
Thx, that's the missing point! I was already to deep in the protocol analysis with block-level thinking to imagine this simplest solution. Your support is highly appreciated. Martin BTW: Did you look at my linux-build PR at GitHub?
|
Now it works quite stable with NanoVNA and tinySA after finding small differences in timing and format of serial transfer.
I've renamed it to nanovna_remote.py to integrate it seamlessly into my zoo of nano tools.
|
Hello, I like the the idea. However, can you provide a exacutable program for Windows for those of us that are not programers? Clyde KC7BJE?
Now it works quite stable with NanoVNA and tinySA after finding small differences in timing and format of serial transfer.
I've renamed it to nanovna_remote.py to integrate it seamlessly into my zoo of nano tools.
|
Clyde,
I do not use Windows - all my work is done on Linux because it makes tools like this so much easier.
This program is a script, no need to compile or build, just put it where you like, go to this directory and execute "python nanovna_remote.py" and it should work. Maybe you have to load some python modules (opencv, PIL, numpy, but also this is no rocket science). The only prerequisite is that you have installed a driver for USB access to the device. This should be the case if you use other tools for tinySA access.
Maybe someone from the other side (Windows) can support in this topic.
Martin
|
Use TinySA-App or NanoVNA-App this windows software In it on screenshot window possible enable Remote desctop (Remote box) 
|
Thank you Martin, I will give it a try. My Son has a Mac. If Windows 11 doesn't like it, I will try his. Reminds me of the old DOS days. Thank you again.? Clyde KC7BJE?
Clyde,
I do not use Windows - all my work is done on Linux because it makes tools like this so much easier.
This program is a script, no need to compile or build, just put it where you like, go to this directory and execute "python nanovna_remote.py" and it should work. Maybe you have to load some python modules (opencv, PIL, numpy, but also this is no rocket science). The only prerequisite is that you have installed a driver for USB access to the device. This should be the case if you use other tools for tinySA access.
Maybe someone from the other side (Windows) can support in this topic.
Martin
|
Small update, should also work for the bigger ones now - untested because of the HW not (yet) available.Martin
usage: nanovna_remote.py [-h] [-d DEVICE] [-n | --h4 | -t | --ultra] [-z {2,3,4}]
?
optional arguments:
? -h, --help? ? ? ? ? ? show this help message and exit
? -d DEVICE, --device DEVICE
? ? ? ? ? ? ? ? ? ? ? ? connect to serial usb device
? -n, --nanovna? ? ? ? ?use with NanoVNA-H (default)
? --h4? ? ? ? ? ? ? ? ? use with NanoVNA-H4
? -t, --tinysa? ? ? ? ? use with tinySA
? --ultra? ? ? ? ? ? ? ?use with tinySA Ultra
? -z {2,3,4}, --zoom {2,3,4}
? ? ? ? ? ? ? ? ? ? ? ? zoom the screen image
?
|
I have installed this script, but I think that I am not specifying the comport correctly.
My attempt to list ports gives this:
dmesg | grep tty
[??? 0.112805] printk: console [tty0] enabled
[?? 73.156225] AMD0020:00: ttyS4 at MMIO 0xfedc6000 (irq = 10, base_baud = 3000000) is a 16550A
[?? 73.157050] AMD0020:01: ttyS5 at MMIO 0xfedc8000 (irq = 11, base_baud = 3000000) is a 16550A
[602297.254857] cdc_acm 2-1:1.0: ttyACM0: USB ACM device
[602324.263919] cdc_acm 2-1:1.0: ttyACM0: USB ACM device
To start the script I have been trying :
sudo python3 nanovna_remote.py -d dev/ttyACM0 -z2
Traceback (most recent call last):
? File "/usr/local/lib/python3.8/dist-packages/serial/serialposix.py", line 322, in open
??? self.fd = os.open(self.portstr, os.O_RDWR | os.O_NOCTTY | os.O_NONBLOCK)
FileNotFoundError: [Errno 2] No such file or directory: 'dev/ttyACM0'
So, am I using incorrect comport syntax, if so what format should I use.
Thanks.
73 de Andy
|
On Sat, Jan 28, 2023 at 06:41 PM, Andy G0FTD wrote:
sudo python3 nanovna_remote.py -d dev/ttyACM0 -z2
Traceback (most recent call last):
? File "/usr/local/lib/python3.8/dist-packages/serial/serialposix.py", line 322, in open
??? self.fd = os.open(self.portstr, os.O_RDWR | os.O_NOCTTY | os.O_NONBLOCK)
FileNotFoundError: [Errno 2] No such file or directory: 'dev/ttyACM0'
So, am I using incorrect comport syntax, if so what format should I use.
Andy, The error is: "-d dev/ttyACM0", must be "-d /dev/ttyACM0" But no need to use the -d unless your device is at an unusual port, e.g. on a mac. Just use: sudo python3 nanovna_remote.py -z2 What's your system, how did you install? On Debian (or another system based on Debian, e.g. Mint or Ubuntu) you can simply type "make deb" and "make debinstall" that installs also the correct udev rule that allows user access to the USB serial port - no need to run as root which is always a bad thing. ? Otherwise you should install also the file "60-nano-tiny.rules" into "/etc/udev/rules.d". Martin
|
On Sat, Jan 28, 2023 at 06:15 PM, Ho-Ro wrote:
The error is: "-d dev/ttyACM0", must be "-d /dev/ttyACM0"
But no need to use the -d unless your device is at an unusual port, e.g. on a mac.
Just use:
sudo python3 nanovna_remote.py -z2
What's your system, how did you install?
On Debian (or another system based on Debian, e.g. Mint or Ubuntu) you can simply type "make deb" and "make debinstall" that installs also the correct udev rule that allows user access to the USB serial port - no need to run as root which is always a bad thing.
Hi Martin, I realised my mistake soon after posting, the leading / for the comport was missing. To be honest this test was part of a something I abandoned many months ago on my Linux Mint 20.3 machine. I was curious to see if it worked with the old original Nano VNA (not H), but alas it doesn't. I just get an error about the screen size. $ sudo python3 nanovna_remote.py capture error - wrong screen size? Normal I think, since your software is not for the old Nano VNA ;-) Anyway, I shall be purchasing a Tiny SA soon, so the effort will not be wasted. Hopefully I can make it work on my Raspberry Pi3B+ too. Vy 73 de Andy
|
On Sat, Jan 28, 2023 at 08:16 PM, Andy G0FTD wrote:
Normal I think, since your software is not for the old Nano VNA ;-)
I think it it the other way round :) - The old firmware doesn't allow remote control, but you could try a firmware update that also provides other useful functions.
|
On Sun, Jan 29, 2023 at 11:06 AM, Ho-Ro wrote:
The old firmware doesn't allow remote control,
The error message is now clearer:
'capture error - does the device support the "capture" cmd?'
I also added better device type detection (name and screen size) - GitHub updated:
|
On Sun, Jan 29, 2023 at 10:06 AM, Ho-Ro wrote:
I think it it the other way round :) - The old firmware doesn't allow remote control, but you could try a firmware update that also provides other useful functions.
Thanks Martin. My Nano VNA is still original, 0-950MHZ or so, I never did any firmware upgrades. It worked well, so I left it alone ;-) 73 de Andy
|
Ho-Ro
Clyde Lambert