开云体育

On Sat, Aug 15, 2020 at 03:30 PM, OneOfEleven wrote:

, I already started writing PC software for it.

Make sure you use the "scanraw" command i.s.o scan or sweep as scanraw can do unlimited points and sends data in binary, much faster

On Sat, Aug 15, 2020 at 07:06 PM, hwalker wrote:

Is that the only change in FW release v1.0-52?

I think so.

On Sat, Aug 15, 2020 at 05:46 AM, Erik Kaashoek wrote:

On Sat, Aug 15, 2020 at 05:41 AM, Erik Kaashoek wrote:

Integrated including using the calculated frequency i.s.o. the frequency array when printing
Will be in next FW release

FW released, version v1.0-52

Erik,
? Is that the only change in FW release v1.0-52?

- Herb

On Sat, Aug 15, 2020 at 04:50 PM, gary wrote:

I intend on using it for general lab work like identifying and quantifying spurious and harmonic emissions.

Great Gary,
? Erik should be a big help if you have questions about either measurement.? You will want to look over the Wiki to learn how to identify spurious emissions within the tinySA itself and how to mitigate them.? Its more of a issue on the HIGH INPUT range because it doesn't have the filtering and attenuation that the LOW INPUT does.

? I recommend that you use an external high pass filter and variable attenuator on the HIGH INPUT if you plan doing a lot of measurements in that range.

- Herb

I intend on using it for general lab work like identifying and quantifying spurious and harmonic emissions.
Gary W9TD

lol, I already started writing PC software for it. Which would also compile for all 3 main OS's - windows, nixies and macs.

I've done a lot of SDR 2D/3D real time panadapter/waterfall spectrum graph coding with intensity grading/fading etc over the years so can use that to do some real posh GL graph displaying you've yet to see ;)? anyone remember the QS1R ? ;)

On Sat, Aug 15, 2020 at 02:35 PM, OneOfEleven wrote:

A scan of the PCB with the covers removed.

OneOfEleven,
? You probably noticed the following:
? 1. The VDD and BOOT pins are available as a last resort for a user that can't access DFU mode in the usual way.
? 2. No SanDisk pads are available, so DiSlords's SanDisk modification for the NanoVNA would require a steady hand and nerves of steel to implement.
? 3. Pads for applying additional shielding are present.? Erik did a ton of experimentation so I'm pretty certain leaving out the shields was not cost savings move.? Still, the pads are there if a user is in an RF rich environment and thinks adding additional shielding will help.
? 4. Lots of space to add a larger capacity battery if longer operating life is needed.
? 5. The sma connectors are soldered securely to the pcb so less chance of shearing off from over torqueing cable connections.
? 6. The display cable does not appear to be connectorized so changing out the display will require above average soldering skills.
? 7. A UART interface is provided for possible RasPi and wireless experimentation.
? 8. A linear regulator is used for less power supply noise.

? Unseen is that the tinySA uses serial console commands so developers familiar with the NanoVNA should face few problems porting tinySA specific versions of their programs (hint, hint).

- Herb

Thank you Herb.

Am trying it with manual ref-level (-10dB) set, all appears OK now.

The auto ref-level code might need some tweaking by the looks of it :)

My heads full of NanoVNA code at the moment so still not got around to looking through the TinySA code. Played with it a lot though :)

On Sat, Aug 15, 2020 at 02:21 PM, OneOfEleven wrote:

The sudden jumps are always 10dB up/down.

OneOfEleven,
? Try setting LEVEL->REF LEVEL_>MANUAL.? Your video shows the reference level changing when the level shifting occur.? In rapidly changing signal environment,? manually setting the reference level and attenuation level will eliminate the bothersome level shifting.

? Nice idea to include the video. "A picture is worth a thousand words".

- Herb

A scan of the PCB with the covers removed.

The sudden jumps are always 10dB up/down.

Hi Erik

I was wondering what you think might cause the base line to jump up and down like this. I'm using your latest firmware as of today, but it was the same with your previous firmware version.

I've done the self test and the level calibration with a through lead. All OK.

Their are no nearby strong signals (that I can find), it's on it's own little antenna. It also sometimes does it with no antenna connected.

I've not changed any setting but set it to high input and the start/stop frequency. All other settings as default.

On Sat, Aug 15, 2020 at 11:50 AM, gary wrote:

Thanks all for the clarification.
Gary W9TD

Gary,?
? What is your current application of the tinySA?? Knowing how the tinySA is being used by its users would probably help Erik to beef-up the Wiki in those relevant areas.

- Herb?

Thanks all for the clarification.
Gary W9TD

I checked.
On purpose I let the resolution filters overlap somewhat? so this helps the interpolation.
There is no I/Q signal and FFT but 57 resolution filters ranging 2.4kHz to 600kHz and then a log? detector chip delivering a single dBm value.
Have a look at the technical desciption in the wiki:?

That little bit of code I put here only really helps if the carrier of interest is somehow spread across 2 or 3 spot frequencies (bins in the FFT world). Otherwise it has little to no effect at improving the indicated frequency. It's main use is with FFT's, but I thought might help here too.

I haven't looked at the receiver architect in your TinySA, so I don't yet know how you detect the amplitude of the carriers as you scan across the frequency range. Do you just have a single real value given to you from the detector chip, or do you have an I/Q pair which you use to create the power spectrum lines I wonder ?

Is there a schematic available ?

Mines been working OK, though have noticed a couple of firmware bugs at times. I really like the unit, extremely handy for RF sniffing while out in the car, interesting what you come across at times ;)

On Sat, Aug 15, 2020 at 05:41 AM, Erik Kaashoek wrote:

Integrated including using the calculated frequency i.s.o. the frequency array when printing
Will be in next FW release

FW released, version v1.0-52

On Sat, Aug 15, 2020 at 04:26 AM, OneOfEleven wrote:

You can get a better frequency estimate for a marker that is set to "Tracking the peak". I modified this bit with some extra code to estimate the actual carrier frequency .

Integrated including using the calculated frequency i.s.o. the frequency array when printing
Will be in next FW release

Line should be ..

if (idx > 0 && idx < (sweep_points - 1))

You can get a better frequency estimate for a marker that is set to "Tracking the peak". I modified this bit with some extra code to estimate the actual carrier frequency ..

=========
sa_core.c line 2070

????? while (m < MARKERS_MAX)
????? {
??????? if (markers[m].enabled && markers[m].mtype & M_TRACKING)
??????? {?? // Available marker found
????????? markers[m].index = max_index[i];
????????? markers[m].frequency = frequencies[markers[m].index];

????????? { // calculate the predicted frequency - OneOfEleven .. parabolic method (their are other methods)
??????????? const int idx????????? = markers[m].index;
??????????? if (idx > 0 && idx < sweep_points)
??????????? {
????????????? const float y1???????? = actual_t[idx - 1];
????????????? const float y2???????? = actual_t[idx + 0];
????????????? const float y3???????? = actual_t[idx + 1];
????????????? const float d????????? = 0.5f * (y1 - y3) / ((y1 - (2 * y2) + y3) + 1e-12f);
????????????? //const float bin????? = (float)idx + d;
????????????? const int32_t delta_Hz = abs((int64_t)frequencies[idx + 0] - frequencies[idx + 1]);
????????????? markers[m].frequency?? += (int32_t)(delta_Hz * d);
??????????? }
????????? }

????????? m++;
????????? break;????????????????????????? // Next maximum
??????? }
??????? m++;????????????????????????????? // Try next marker
????? }
????? i++;

=========

It doesn't yet use the calculated carrier frequency on my TinySA that this calculates as the display is still getting it from the frequencies[] array rather than the marker[].frequency value. I'll leave that to Erik if he so wishes to use the code.

But this would display a more accurate frequency that simply using the spot frequency from the frequencies[] array.