-
while trying to make minimal differences of 2 signals visible via the math channel, I found some behaviour I can not explain.
[...]
Hi Peter,
with both input channels acquired at 100 mV/div and the math channel displayed at 500 µV/div, the math trace is effectively showing the difference between both channels at about 200x vertical magnification relative to the acquisition scale.
This is somewhat similar to taking a single-shot acquisition at 100 mV/div, stopping the scope, and then zooming it vertically to 500 µV/div. The trace may look very clean at 100 mV/div, but after that much vertical magnification the remaining acquisition noise becomes quite obvious.
Also keep in mind that subtracting two channels does not subtract their uncorrelated noise. Instead, the noise from both channels contributes to the math result.
The Magnova has a very low-noise front end, but at this amount of vertical magnification even the remaining noise becomes clearly visible. Using HiRes and/or averaging, as you already mentioned, can reduce the visible noise significantly (the acquired 12-bit ADC data is processed and stored with 16-bit resolution).
If the goal is to measure a very small difference between two relatively large signals, a suitable low-noise differential probe may also be worth considering. This would allow the differential component to be presented directly to the ADC at a more suitable input range, instead of relying on such a large vertical magnification of the subtraction result.
Regarding the different DVM AC RMS readings: you noted about 530 µVrms at 100 mV/div (800 mV full screen) versus 70 µVrms at 10 mV/div (80 mV full screen), with no applied signal and without filtering, averaging, or HiRes at 350 MHz bandwidth. These values are good, and they match the information in our data sheet. The input-referred noise floor of the acquisition path is significantly lower at the 10 mV/div setting. So the change in the DVM reading is expected even though the external input signal itself has not changed.
Best regards,
Andre -
Hi Andre,
thank you very much for fast clarification! Regarding the DVM one must be clear about that the existence of sub mV scales does not necessary means, that precison is sufficient in every case.
For the difference of an external short and the internal GND setting I guess there must be some additional muting in the digital domain.
b.r.
Peter
ps: I already considered the acquisition of a differential probe, but primarily for high voltage circuits. I have to go deeper in this field. For the actual measurements I will use a 2 input high sensivity LF voltmeter - I just wanted to explore before at which voltage scale I would end up. -
thank you very much for fast clarification! Regarding the DVM one must be clear about that the existence of sub mV scales does not necessary means, that precison is sufficient in every case.
For the difference of an external short and the internal GND setting I guess there must be some additional muting in the digital domain.
Hi Peter,
I have one additional detail to add regarding the oscilloscope DVM: although the DVM processing runs in parallel with the normal oscilloscope acquisition, it does not have a separate measurement front end. It uses the same analog signal path and the same ADC data.
Therefore, the selected vertical range has a significant influence on the DVM noise floor and measurement accuracy. At 10 mV/div the input signal can make much better use of the ADC range than at 100 mV/div, so the input-referred noise is considerably lower as well.
A dedicated precision DMM is usually optimized for much higher voltage accuracy and resolution. The scope DVM serves a somewhat different purpose: it uses the oscilloscope's high-speed acquisition path, so it can measure signals with much higher sampling rate and bandwidth. There is a tradeoff between those two approaches.
Regarding internal GND: yes, this is handled differently from simply shorting the BNC input externally. Internal GND is a defined internal reference condition rather than a normal signal acquisition from the input connector.
Best regards,
Andre -
Hello Andre,
thank you for the additional explanation which is really helpfull for understanding. I appreciate the good support from you and your colleagues!
All the best,
Peter -
Question:
I try to save a FFT as CSV but my problem (or issue) is, that the stored file contents more data then I would expect.
FFT config is "FlatTop" from -1MHz to 11MHz (I want to measure a 10MHz sinus)
but when I store this data as CSV (notation is Basic), I get a 18MByte file with the first entry :Code: [Select]frequency in Hz,amplitude in dBm
0,16.1454887979076
762.939453,15.9385173526038
1525.878906,13.3055244161149
2288.818359,5.36509117926091
3051.757812,-10.6657555785911
3814.697265,-43.0133926725808
4577.636718,-64.2355115825378
5340.576171,-63.5112260073501
6103.515624,-61.1944315639434
...
and ends with:Code: [Select]399993133.479387,-86.890482359017
399993896.41884,-88.1015246335283
399994659.358293,-85.3007784036304
399995422.297746,-82.316570242416
399996185.237199,-80.7752461769722
399996948.176652,-80.2946646262134
399997711.116105,-80.7086019593274
399998474.055558,-82.0799550920783
399999236.995011,-85.7636750861821
399999999.934464,-92.9785939270364
so the last entry is at 400MHz... ?!?
do I miss a configuration here....or is this a 'bug'?
-
The CSV export always saves the complete FFT data set. The currently selected FFT view range, e.g. -1.2 MHz to 11 MHz in your case, only limits what is shown on screen. It does not limit the frequency range written to the CSV file.
The reason your export stops at about 400 MHz, even though the sample rate is 1.6 GSa/s, is the FFT point limit. In your setup, it was set to 1 Mpts, so the FFT does not use the full 1.9 Mpts/channel acquisition record. If you increase the FFT size to 2 Mpts or more, the FFT range in this example would extend up to about 800 MHz.
As a workaround, you could also reduce the FFT point limit. For example, with 32 kpts, the FFT range with these settings would be limited to about 12.5 MHz, and only that range would then be saved to the CSV.
Would it be useful for you to have an option to limit the FFT range saved to CSV to the currently displayed range? This should be possible to add in one of the upcoming updates. -
Would it be useful for you to have an option to limit the FFT range saved to CSV to the currently displayed range? This should be possible to add in one of the upcoming updates.
I think that would be good to have as an option. Having the extra data could be helpful, but sometimes the opposite. -
Would it be useful for you to have an option to limit the FFT range saved to CSV to the currently displayed range? This should be possible to add in one of the upcoming updates.
Maybe there could be an option to save only the selected frequency range.
In my case that would reduce the filesize down to ~480kByte with only ~14.000 entries instead of the original 520.000 :-)
The file would be than easier to handle from a 3rd party software.
P.S.
Your "workaround" generated exactly this file....so good to know
(although I am not quite sure why the behavior is then here different) -
And maybe a silly follow up question:
In the save dialog there is an option to select the FFT unit:
[dBm, dBV, dBmV, dBuV, Vpp, Vrms]
but in the actual FFT config the unit options are:
[dBm, dBV, dBmV, dbuV, Vrms]
why is [Vpp] an option to save but not to display?
P.S.
a similar issue is in the bode blot save options,
here there is an "dBm" unit but that is missing in the bode plot view itself -
The CSV export always saves the complete FFT data set. The currently selected FFT view range, e.g. -1.2 MHz to 11 MHz in your case, only limits what is shown on screen. It does not limit the frequency range written to the CSV file.
One way to make it smaller is to only output relevant digits. 0.1dB is about 1% so printing dBs with 2 decimals is more than adequate. The same for the frequency and I'd switch to e notation because the way it is printed now has a lower resolution at low frequencies. -
One way to make it smaller is to only output relevant digits.
my particular problem was not the file size but the huge number of (for me unimportant) entries
and this is solved with the point limit set to 32kpts. -
In the save dialog there is an option to select the FFT unit:
[dBm, dBV, dBmV, dBuV, Vpp, Vrms]
but in the actual FFT config the unit options are:
[dBm, dBV, dBmV, dbuV, Vrms]
why is [Vpp] an option to save but not to display?
For the FFT display, we should be able to add Vpp as an available display unit as well. Vpp is somewhat less common for FFT displays, but since it is already available for CSV export, it makes sense to offer it consistently in the FFT view too. Good point, noted.
a similar issue is in the bode blot save options, here there is an "dBm" unit but that is missing in the bode plot view itself
Regarding the Bode Plot: dBm becomes available for the generator amplitude setting once a load impedance other than High-Z is selected. Without a defined load impedance, the power level in dBm cannot be calculated, so only dBV, dBmV, dBuV, Vpp, and Vrms are available.
BTW: The load setting on the Magnova generator is also not limited to just 50 ohms or High-Z. It can be set anywhere from 10 ohms up to 1 Mohm in 1 mOhm steps, in addition to High-Z.One way to make it smaller is to only output relevant digits. 0.1dB is about 1% so printing dBs with 2 decimals is more than adequate. The same for the frequency and I'd switch to e notation because the way it is printed now has a lower resolution at low frequencies.
Thanks for the suggestion. You're right, the export currently keeps more digits than are really useful in many cases. -
Thanks for the suggestion. You're right, the export currently keeps more digits than are really useful in many cases.
Maybe the "resolution" of the output could also be an option (not only when saving the FFT)
but usually I would say: "give us the RAW data with max resolution and let the user decide how many decimal places he needs at the moment" -
inspired from this post:
https://www.eevblog.com/forum/testgear/generate-arbitrary-waveforms-for-a-signal-generator/
I wrote (or lets better say QWEN3.5 wrote)
two python scripts for the Magnova to convert a 1024x1024 bitmap into a binary file to load into the AWG.
I am not sure if Batronix is happy when I would share these scrips...
depends on how robust the "load" function in the AWG for corrupt data is implemented.
The scripts are checking the input bitmap and the generated AWG values....but I don't want to be the guy that messed anothers person scope.
Anyhow, the structure of the binary is very easy to understand and not decrypted,
so anybody can do this without much effort.
-
Very cool! Thanks for taking the time to look into the format and build the scripts. It is also great that you are being careful about validating the generated data before sharing it - especially when files are loaded directly into an instrument.
And from our side, you can of course share your script. The file format is intentionally not encrypted or meant to be hidden, so experimenting with it and building your own tools around it is absolutely fine.
By the way: The Magnova generator is also quite useful for generating test signals directly with AI. I have used the following prompt below several times in different variations - not only for UART signals, but also for mathematically defined waveforms and other test signals.
Here is the prompt:Code: [Select]Create a binary file for an arbitrary waveform using the following parameters.
Do not make assumptions. Ask for clarification if anything is unclear.
File format:
- Raw binary file
- File header: 0x01 0x00 0x00 0x00 (4 additional bytes before the Float32 data)
- Then exactly 32,768 samples as Float32 values (IEEE 754, little-endian)
- File extension: .bin
Level mapping:
- Bit 1 → +1.0
- Bit 0 → -1.0
- Samples per bit: 16
- Any remaining samples → Idle (High = +1.0)
UART-Signal:
- Parity: None
- Stop bits: 1
- Bit order: LSB first
- Standard 8N1 framing
- 8 data bits per character
Content:
- Output the following sentence via UART: "Hello from the Magnova waveform generator! This message travels byte by byte through the system, testing timing, encoding, decoding, and data integrity. Let the bits flow and the testing begin!"
- Do not transmit an ASCII space (0x20) at all. Instead output +1.0 idle for exactly 128 samples as replacement.
- Set all remaining or unspecified bits to High (+1.0).
Goal:
- Generate the finished .bin file so it can be output by the Magnova Generator and validly decoded by a UART decoder.
The prompt above directly generates a file that is compatible with the Magnova generator and can be output directly. The result can be seen in the screenshot below.
The prompt is also easy to adapt to your own requirements. By changing the parameters and signal description, it can generate many other types of waveforms as well - not just UART signals.
Please note: Since one UART bit uses 16 out of the 32,768 samples, the resulting UART baud rate is 2,048 times higher than the frequency set on the generator.
So for a first test, I would recommend using a relatively low generator frequency, for example 5 kHz or less. The UART decoder should then be set to 10.24 Mbaud (5 kHz × 2,048).
-
here you are:
I added also a batch file and a example bitmap that should run without error
as info: to be generic I splitted the job into two scripts
'bitmap_converter.py' is converting any 1024x1024 bitmap into a textfile with 32768 float values (range -1.0 .. +1.0)
only the first black pixel from the top is used as data and because the filesize has to be 32768 every pixel value is added 32x into the output file.
(I used paint.exe to generate the bmp...must be saved as monochrome 1bit color)
'float_to_binary.py' is reading any textfile with 32768 float values (range -1.0 .. +1.0)
and is generating the actual binary-file that can be then loaded into the AWG module
(with a parameter you can choose the interpolation type)
you can use the batch 'create_bin_from_bmp.bat' without parameter to convert the example bitmap in one go
question @Batronix,
the 'worst-case-scenario' with a self-created file for the AWG is perhaps 32768 alternating entries with -1.0 and +1.0
so the output has to change with max speed and max amplitude....could this cause any type of problem?
(maybe this was tested during developement)
and another info to the scripts:
'use at your own risk'
-
Thanks a lot for sharing this!
I tried it right away and used your script to convert a heartbeat ECG into a binary file and load it into the Magnova generator. I have to say, that looks pretty nice. :-)question @Batronix,
the 'worst-case-scenario' with a self-created file for the AWG is perhaps 32768 alternating entries with -1.0 and +1.0
so the output has to change with max speed and max amplitude....could this cause any type of problem?
(maybe this was tested during developement)
With arbitrary waveform files, an AWG can generate signal components at much higher frequencies than the frequency set as the waveform repetition rate. In your example, with alternating +1.0 / -1.0 samples, the output would contain a frequency component at 16,384 times the selected arbitrary waveform frequency.
There are two practical limits, though. First, the DAC sample rate is limited to 400 MSa/s, which means a maximum theoretical output frequency of 200 MHz. Second, the signal is filtered at several stages in the generator signal path, so the actual amplitude at very high frequencies will be reduced accordingly.
We also tested this during development. Even with such worst-case arbitrary waveforms, the Magnova generator cannot be overloaded or damaged this way.
For demonstration, I used AI to generate an arbitrary waveform containing 10 sine periods (prompt below) and output it with the Magnova set to 20 MHz. As shown in the screenshot, this results in a 200 MHz signal from the Magnova generator. Even though this is far beyond the specified generator bandwidth, the waveform still looks surprisingly good.
Of course, the attenuation from the output filtering is very noticeable at these frequencies. This also works only for frequencies where the DAC sample rate is an integer multiple of the desired output frequency, such as 200 MHz, 100 MHz, 50 MHz, and so on.
The following AI prompt was used to generate the 10-sine-period arbitrary waveform file for the Magnova generator, in case anyone wants to try it:QuoteCreate a binary file for the Magnova arbitrary waveform generator using the following parameters. Do not make assumptions. Ask for clarification if anything is unclear.
File format:
- Raw binary file
- File header: 0x00 0x00 0x00 0x00 (4 additional bytes before the Float32 data)
- Then exactly 32,768 samples as Float32 values (IEEE 754, little-endian)
- File extension: .bin
Signal:
- Ten complete sine periods over the 32,768 samples
- Start phase at 0° / sample 0 = 0.0, rising
- Stored samples must contain exactly +1.0 and -1.0 - normalize the sampled waveform so its discrete extrema reach exactly ±1.0.
Goal:
- Generate the finished .bin file so it can be output by the Magnove Generator and creates 10 sine periods per run.
-
I think a neat feature for the AWG could also be to trigger the sweep and burst mode with an external signal.
e.g. TTL rising-edge from an analog channel, or 0V=disable, 5V=enable....i don't think that the timing here would be that critical.