Forum
Please or Register to create posts and topics.

FIXED: CSV Export from Spectrum in dBμV/m for EMV testing

Hi,

I am creating an EMV-testing process right now, where we measure the electric field strength of our test subject with the Spectran V6 connected to a HyperLOG antenna. Because of the specific national EMV requirements, i do reprocess the measurement data from the RTSA Suite within Matlab, mostly for easyer documentation for massive amounts of data.

I had the technical support over phone help me with unit conversion, as the csv-export from the spectrum block only gives me data in dBm, and i need the data to be in dBμV/m. If i have the unit "dBm" selected in the spectrum View settings, the csv-exported data can be correctly converted back to dBμV/m within Matlab (i confirmed the manually converted data against the displayed data in RTSA), but if the "unit" setting within the Spectrum Block is set to "dBμV/m", the csv-exported values are still seemingly in dBm, just slightly offset, seemingly dependant on the frequency, which makes me think that the exported values now disregard the calibration settings?

 

Example: I recorded a test run for one second and replayed it "once" in the file reader until the end point. When i set the unit in the spectrum block to "dBm" and export it with the export button in the top right of the spectrum block, i get (rounded) -120,7 dBm at ~915 MHz. If i repeat the exact process, just with the unit set to "dBμV/m", the exported file contains -100,1 dBm at the exact same spot.

The -120,7 dBm @ 915 MHz converted with the manual method in matlab equals 15,7 dBμV/m. If i convert the -100,1 dBm i get 36,3 dBμV/m, so at this point there is a ~20 dB offset. If i set a marker on that frequency in the dBμV/m View in the Spectrum-Block, it reads 15,6 dBμV/m, so if i export from "dBm" the data seems correct. The Data was measured with the HyperLOG 60100, the 1m SMA cable and the Spectran V6, all from Aaronia and all calibrated for. This offset is seemingly happening on all the data, i just used a specific point to give an example. For example at ~400 MHz i measured a 13 dB offset, instead of 20 at ~900 MHz.

(What i also randomly found: When the measurement is stopped in the Filereader, and i change the unit from dBμV/m back to dBm (in the Spectrum Block View settings), it displays the second, "wrong" Value of -100,1 dBm at that spot. If i restart the measurement, the Value instantly jumps back to the "correct" ~-120 dBm. Maybe this helps with identifying the problem.)

 

 

My problem is, that during the actual EMV test, i need the testing engineer to see the values in dBμV/m in the RTSA Suite, as i have imported EMV-power limits into RTSA, so that the engineer can see the measurement in realtime against the given limits, to adjust and get a feel for how the test is going.

Is there a way to circumvent the test engineer having to manually change the view setting for every time he wants to export the spectrum csv-file? This seems to me like more of a bug than an intended feature. Or is an export in the displayed unit possible, that would be even better! Anyways, fixing this would save propably hours of effort and time on every test run (the amount of settings and setup configurations that need to be cycled for the nation-specific EMV laws are quite something). I also really dread going through the completed test run, where i luckily recorded every measurement with the Filereader, and replaying+exporting every measurement from the dBm view per hand.

Thanks for the help and greetings from Germany,

Janik

Hello,

it seems you found an issue with the export function, that when using any  /m or /m^2 units the data apparently is exported as dBmW/m^2 instead of dBm or the actually configured unit. We'll have our software engineers look into that, and see if we can get it changed to export in the unit actually configured for the view, and somehow list the unit in the exported file for clarity.

Thanks for your feedback.

Janik Ruge has reacted to this post.
Janik Ruge

Fixed with build 10504 and higher.