开云体育

Hi all,

When exporting CSV trace files from TinySA-App connected to my Ultra, the amplitude values in the file are around 10 dBm lower than traces shown in the app.? I tried many different RBW and points per scan and get similar results.? Can anyone try this and let me know if yours are also doing this?? Thanks!

When exporting CSV trace files from TinySA-App connected to my Ultra, the amplitude values in the file are around 10 dBm lower than traces shown in the app.? I tried many different RBW and points per scan and get similar results.? Can anyone try this and let me know if yours are also doing this?? Thanks!

With further study, it seems that the CSV amplitude values range from 10 dBm to 20 dBm lower than the display trace.? Hmm...

Here's an example.? This screen shot shows the tinySA-App trace of a single scan (Moving Average Filter: off, Calc: off) with markers.? The corresponding lines of the saved CSV do not show the same amplitude values as the app markers.? To me, this looks like a scaling error in the CSV export?

545762525.000;?????????? -134.809?????????? (marker shows -117.1)
548322611.000;??????????? -69.185??????????? (marker shows -60.094)
655479516.000;?????????? -135.025?????????? (marker shows -117.28)

Still hoping to get this bug resolved.

To make this even more confusing to figure out, this error is not a simple percentage applied to all amplitudes.? Referring to the example in my previous post:

545762525.000;?????????? -134.809?????????? (marker shows -117.1)
548322611.000;??????????? -69.185??????????? (marker shows -60.094)
655479516.000;?????????? -135.025?????????? (marker shows -117.28)

-134.809 is 115.12297181896% of -117.1
-69.185 is 115.12796618631% of -60.094
-135.025 is 115.13045702592% of -117.28

Would love to see this fixed. Is this being worked on currently? Have to do an additional multiplication of .8686 on the dbm column to get it close to correct when using the TinySA app with my TinySA ultra. Using for RF coordination and would be great if we could just import directly. Thank you.?

I just received my tinySA and found out about this issue after importing the . csv on a RF mics coordination software. I'd love to see this fixed too ! Has it been reported on the Github ?

On Mon, May 1, 2023 at 07:22 AM, <dchadd@...> wrote:

ee this fixed. Is this being worked on currently? Have to do an addition

I just received my tinySA and found out about this issue after importing the csv on a RF mics coordination software. I'd love to see this fixed too. Has it been reported on the Github ?

Any news on this problem of CSV values being offset from onscreen trace values? ?Could it be that, for example, on screen trace is a single scan but CSV is receiving a hold or average trace? ?

On Sun, Jun 25, 2023 at 08:07 AM, Mark McFarlane wrote:

Any news on this problem of CSV values being offset from onscreen trace values? ?Could it be that, for example, on screen trace is a single scan but CSV is receiving a hold or average trace???

I don't believe that is the case, Mark.? The attached Python script logs the onscreen trace values to separate CSV files every 15 sec for 1 minute and the saved trace values are the same as the on-screen values.

All the script does is read the ASCII trace data and trace frequency values into separate arrays and then writes them out to a CSV file.? I believe Erik uses raw data instead of ASCII data when retrieving the trace data and there is a minor conversion error that is creeping in before saving to CSV.??

Hardware is a lot more fun than software and Erik has other hardware projects on the back burner, so the CSV issue is mostly taking him time to get around to.? If you are familiar with Python, then maybe the attached Python script can help in the meanwhile.? I downloaded it a while back off the web and forgot to note who the proper credit should go to.

Herb

On Mon, Jun 26, 2023 at 01:01 AM, hwalker wrote:

I believe Erik uses raw data instead of ASCII data when retrieving the trace data and there is a minor conversion error that is creeping in before saving to CSV.?

We already had a discussion about "scanraw" conversion errors earlier this year:
/g/tinysa/topic/97630860

On Mon, Jun 26, 2023 at 12:52 AM, Ho-Ro wrote:

?We already had a discussion about "scanraw" conversion errors earlier this year:
/g/tinysa/topic/97630860

That's correct. I actually meant transfer instead of conversion.? Probably best to leave the troubleshooting to Erik.? I wish I could understand the TinySA-App code on GitHub and help to improve the application, but C++ is Greek to me.

Erik did a great job of modifying NanoVNA-App into TinySA-App but it still shows vestiges of NanoVNA-App that could be cleaned up and does not fully take advantage of tinySA or tinySA-Ultra's capabilities.? I was hoping an interested third party would take on the task but that hasn't happened yet.??

Herb

On Mon, Jun 26, 2023 at 03:29 PM, hwalker wrote:

TinySA-App code on GitHub

I can't see the wood for the trees right now - can you give me the link?

On Mon, Jun 26, 2023 at 09:01 AM, Ho-Ro wrote:

On Mon, Jun 26, 2023 at 03:29 PM, hwalker wrote:

TinySA-App code on GitHub

I can't see the wood for the trees right now - can you give me the link?

Martin,
? I mis-spoke, only branches for NanoVNA-App are currently available on GitHub.? If you are interested in taking a look at, or forking the TinySA-App code, then you will need to PM Erik and request a copy.?

? Probably at some point in the future Erik will get around to posting TinySA-App to GitHub since One-of-Eleven has released the base NanoVNA-App to open source.? It would allow other programmers to submit commits to Erik's base branch and improve TinySA-App.

Sorry for sending you into the woods :-)

Herb

Are the CSV files saved by the hardware direct to the SD memory card correct?

I'm on a Mac so the TinySA app is inconsequential to me.

Hi Mark,

CSV files saved in SD card with the Ultra are fine.?

Thanks Diogo.