开云体育

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

Then you use DfuSeDemo Upload, you made full flash dump from microcontroller (128k flash) Firmware not use full size, flash at end not used (but in this area stored settings)

The latest firmware file is: tinySA_v1.3-429-gc224fa9.dfu and is 110.989 bytes in size. This firmware version is the actual one in mu device. In the DfuSeDemo program from STMicroelectronics it is

It's in both modes -- For more info on the tinySA go to https://tinysa.org/wiki/

I thought that was the phase noise in Spectrum Analyzer mode.? Is it the phase noise in one of the Signal Generator modes? Roger

To connect two signal generados together you need a combiner. Such device may be simple in HF but not so in VHF or UHF. The combiner isolates both signal generators to prevent IMD products that spoils

Thanks guys. -- John AE5X https://ae5x.blogspot.com/

Here you can find the? tinySA specs https://tinysa.org/wiki/pmwiki.php?n=TinySA4.Comparison tinySA tinySA Ultra Phase noise at 10kHz offset -83dBc/Hz -92dBc/Hz Not sure this is good enough -- For

Hello John, for this to make sense the signal generator with the higher output level needs to have a very good Phase noise performance if the frequency difference is that small. So if you are flexible

I'm wondering if it's possible to use two tinySA's (in signal-generator mode) to make tests of a receiver's dynamic range. In ARRL reviews of various radios, two signals are injected 2 kHz apart with

A short video demonstrating the tinySA Ultra mode performance and limitations. Important to understand if you are looking at signals above 800 MHz. https://youtu.be/BfxRW4KH87g -- For more info on the

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

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

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 <

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

I still liked the 8566B the best. Mike C.

Interesting history, Dave. Thanks. It is a beautiful instrument. I have honestly gotten more use out of my Tiny SA but I had to take the 8585B home or it would have gone into to the scrap bin. 73 -Jim

That's the down side. The 3585B would hold a decent sized boat in place. 73 -Jim NU0C "Mike C." <mg@...> wrote:

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,

Something similar already exists: http://www.albfer.com/en/2020/02/21/satsagen-2/ It uses a Pluto (other hardware optional) to use the TX and RX parts as a TG and SA. May be Alberto could update it if