开云体育

Hello All, I was wondering would it be possible to test CATV (46MHz to 850MHz) signal from the local carrier on a Nano? Thank you Daniel

Greetings, I recently ordered my first NanoVNA, an SAA-2N V2.2 from R&L Electronics (brand unknown). I haven't used a VNA in about 20 years (HP 8510) but I always wanted to have one as I found it to be a phenomenal tool. -- 73's, Don W5MML...?

The Version information (thus Version screen content) should include the commit hash to indicate the github repo commit it comes from. Also the build date/time is not necessary, imho. Moreover, the build date string within the binary would mess the checksum of the binary. A possible solution is to have the Version information as follows (from comm in 1of11 app): 49.818 rx: ch> version 49.828 rx: 0.7.1-158-g6845a32 49.838 rx: ch> info 49.850 rx: Board: NanoVNA-H 4 49.859 rx: 2016-2020 Copyright @edy555 49.867 rx: Licensed under GPL. See: https://github.com/ttrftech/NanoVNA 49.876 rx: Version: 0.7.1-158-g6845a32 49.885 rx: Info: 1.0.13Mod beta New UI, 12k offset, 768k ADC, built by igor-m 49.894 rx: Kernel: 4.0.0 49.903 rx: Compiler: GCC 8.2.1 20181213 (release) [gcc-8-branch revision 267074] 49.911 rx: Architecture: ARMv7E-M Core Variant: Cortex-M4F 49.921 rx: Port Info: Advanced kernel mode 49.930 rx: Platform: STM32F303xC Analog & DSP

Disclaimer: I do not own the FreeRepositories github. I do not produce the releases at the FreeRepositories github. As indicated in my previous posts, the status of former pre-Aug-6th-2020 sources is unknown. https://github.com/FreeRepositories/NanoVNA-H4/releases I've done a quick test of the release 0.9.0.1 (H4 with the SDcard). The 1of11 nanovna app shows: 55.369 rx: ch> version 55.369 rx: 0.9.0.1 55.369 rx: ch> info 55.369 rx: Board: NanoVNA-H 4 55.369 rx: 2016-2020 Copyright @edy555 55.385 rx: Licensed under GPL. See: https://github.com/ttrftech/NanoVNA 55.385 rx: Version: 0.9.0.1 55.385 rx: Build Time: Aug 9 2020 - 19:48:58 55.385 rx: Kernel: 4.0.0 55.385 rx: Compiler: GCC 7.2.1 20170904 (release) [ARM/embedded-7-branch revision 255204] 55.385 rx: Architecture: ARMv7E-M Core Variant: Cortex-M4F 55.385 rx: Port Info: Advanced kernel mode 55.385 rx: Platform: STM32F303xC Analog & DSP The version screen shows the same, there are minor graphic artifacts visible, the Compiler line does not fit on the H4 screen, however. It saves to SDcard, nanovna-saver can read the s1p file. Other functionality has not been tested yet.

While building the firmware from the sources you get hex format (and a couple of other outputs as well). Conversion to .dfu format (it is required when you want upload to H4 via USB with help of DfuSeDemo from STM) is pretty easy. AFAIK you have got 2 choices basically: 1. to use "Dfu File Manager" app (it is included in the STM's package "DfuSe v3.0.6" you may download free from STM) 2. to use HEX2DFU.EXE utility written by Clive from STM (you may download it free from the STM's users forum). Both work, even I once registered a small difference in the resulting .dfu file size (2 bytes).

As most of active nanovna users know, the main active github repository with NanoVNA firmware has been deleted on August 6th 2020 by a member. At the same time the binaries were deleted from nanovna-users group (by the moderators or owners). The real reasons behind this abrupt step are unknown. There are still dozens of github repositories available around the World, however (around 130 forks were made). Based on the search through the web one of the latest sources seem to be available at following githubs (there could be forks and mirrors/backups there with various earlier dates as well): https://github.com/ttrftech/NanoVNA [Edit: the github from version screen] https://github.com/igor-m/NanoVNA-Z [Edit: the latest backup from Aug 6th 2020] https://github.com/RandMental/NanoVNA [Edit: the latest fork] etc.

Building .dfu binaries for H and H4 is easy. Provided you have sources available.. I tried with latest available github sources "NanoVNA-Z" and "H sources and H4 binary mod" published by a nanovna-users group member on Wed, 5 Aug 2020 at 21:03. I cannot find the 16224 message on the nanovna-users forum anymore, it seems.. ..Linking build/ch.elf Creating build/ch.hex Creating build/ch.bin Creating build/ch.dmp text data bss dec hex filename 85812 884 40488 127184 1f0d0 build/ch.elf Creating build/ch.list .. After conversion of .hex to .dfu I flashed the binary into the H4. The OneOfEleven's application shows: 09.671 rx: ch> version 09.679 rx: 0.7.1-156-gb91e9df 09.686 rx: ch> info 09.694 rx: Board: NanoVNA-H 4 09.701 rx: 2016-2020 Copyright @edy555 09.708 rx: Licensed under GPL. See: https://github.com/ttrftech/NanoVNA 09.715 rx: Version: 1.0.13 beta New UI, 12k offset, 768k ADC, compiled by DiSlord 09.723 rx: Build Time: Aug 7 2020 - 22:33:21 09.731 rx: Kernel: 4.0.0 09.738 rx: Compiler: GCC 8.2.1 20181213 (release) [gcc-8-branch revision 267074] 09.746 rx: Architecture: ARMv7E-M Core Variant: Cortex-M4F 09.753 rx: Port Info: Advanced kernel mode 09.761 rx: Platform: STM32F303xC Analog & DSP The version screen on H4 shows version 1.0.13 beta as well. It freezes after a while, however. EDIT: as the first step a patch file needs to be created to see and apply the diffs (the "mod" came from outside the git). Then a rebuild and flashing with clearconfig and calibration.

There are "pre-SDcard/RTC era" releases - "stable releases" - for H and H4 in binary form floating around. They are considered "stable". The new firmware versions (also in binaries) with numbering 1.0.xx are considered "beta demo versions", built up without RTC and SDcard support (as of today). According to the authors they serve testing purposes only and are considered unstable (ie. freezes). It seems the major reason for the instability is an ongoing experimenting with pushing up the limits of the parts used (ie. AUDIO CODEC, I2C bus, etc.) on existing hardware. Another indicated source of instability is the overheating of the master clock generator Si5153, especially in H versions. The "stable releases" could be built out of the available sources as they are of older date (provided you know the commit and you reset to that respective commit), whether you will get the binaries in the exact form out of the available sources is unknown.