AnsweredAssumed Answered

Translate data trace to dBm

Question asked by Freddy on Mar 27, 2007
Latest reply on Jun 5, 2007 by nizuchi

Like • Show 0 Likes0
Comment • 11

Hi, I'm making an application for get the trace data for a Agilent E4407B.

I need speed and space, and I would like download the trace data in <INT,32> (uncorrected ADC values), or <UINT,16>, my question is how tranform that data to dBm.

Thanks a lot.

Freddy Coal

No one else has this question

Outcomes

11 Replies

bwreed Mar 28, 2007 4:26 PM
Mark Correct
Correct Answer
Greetings Fred,

It is important to know which format you want. If speed is the issue, I would suggest 16 Bit data since it will give you all you need. There are a set of scaling constants that can also be read. I would have to look up the command and may do so if I have time. I have done it before. The query gives you a small set of numbers that are needed to scale the data into its true linear form. I cannot remember if uncorrected data comes back in linear or log form. The user manual should tell you this. I would suppose that raw data is in linear form as it is in nearly all our isntruments. In this case, your final step would be a conversion to dBm.

As I recall, the set of scaling constants comes as a list of floating point numbers which you can get in ASCII form and which you only need once per setup.

If you need more specific help than this, please call post again.

Brent
Like • Show 0 Likes0
Actions
Freddy Apr 3, 2007 3:59 PM
Mark Correct
Correct Answer
Thanks for your reply bwreed; I send an email to Agilent support and he say that rawtrace don't send correct data, and is impossible translate that data to dBm.

I'm very upset, I donÂ´t understand why the manual describe that type of 'garbage' data.

My best regards bwreed.
Like • Show 0 Likes0
Actions
bwreed Apr 3, 2007 4:13 PM
Mark Correct
Correct Answer
In the period of time since my last reply, I did take a significant effort to attempt a favorable answer to the question. You asked. What I am told by people at our factory is that there is no way to convert raw data to meaningful data.

By this they mean that the error correction process is complex and proprietary.

If the format form for the display data is in dBm, the raw data is in dBm. IF the format is linear or some other units, the raw data is in those same units. However, the scaling factors are missing. I suppose you could do a test with a known signal level at a known frequency. Measure its amplitude with a marker and pull the raw data. Develop a scaling factor based upon your measured number. That would give something which may be better than nothing.

I wish I had a better answer for you. I was rather surprised myself to find out that the scaling factors are not available. No doubt the command exists for the use of firmware designers to help them get data to check their firmware based corrections.

That is the best I have been able to determine.
Like • Show 0 Likes0
Actions
Dr_joel Apr 3, 2007 4:58 PM
Mark Correct
Correct Answer
Not to put too fine a point on this, but the 4407 is not really a network analyzer; of course we would never allow a network analyzer to have 'garbage' data.
Like • Show 0 Likes0
Actions
bwreed Apr 4, 2007 7:34 AM
Mark Correct
Correct Answer
Dr. Joel, Dipti asked me to answer this one as a mispost since the SA forum is not one line yet. We know how to correct raw data from our VNA's. But for the SA's it turns out not to be so public a matter as publishing an error model and equations. I wish it were. The customer base ought to have the error model, but then again, who execpt for a rare few even would care. For this customer, the issue is speed alone for data transfer.

Thanks much Brent.....does feel funny to be on the SA side of the fence.
Like • Show 0 Likes0
Actions
Freddy Apr 16, 2007 3:50 PM
Mark Correct
Correct Answer
Hi bwreed, I have other question, I'm sending block of commands separated for ";".

I send the next block of commands:

:SWE:POIN 601;:FORM:TRAC:DATA INT,32;:SWE:TIME:AUTO ON;:SENS:BAND:RES 30000;:SENS:BAND:VID 30000;:DISP:WIND:TRAC:Y:RLEV 0;:DISP:WIND:TRAC:Y:PDIV 10;:POW:ATT 10;:FREQ:CENT 1745000000;:FREQ:SPAN 100000000;:TRAC:DATA? TRACE1;*WAI

Well, when the E4407B are in preset state, the data have 401 points peer trace; In my block I change that for 601 points (first command), but the first trace that return me have 401 points; My questions is, how the analizer process a block of commands?, why the analizer send me a trace with 401 points when my first intruction was change that for 601p?, the commands have priority?.

Thanks a lot.

Freddy Coal
Like • Show 0 Likes0
Actions
bwreed Apr 16, 2007 4:13 PM
Mark Correct
Correct Answer
Greetings Freddy,

I don't know that there is a hard rule about how things like setting the number of points works in strings of concatenated points. At first look I would expect your command to work as you suggest. On a closer look, I think that it may be a mistake to pack so many together, the more so with commands that take time, depending on the state of the instrument.

For example, you set the sweep time to auto. This should be the default, but I personally would expect that commands of that type might take a little bit of time. Also it acts directly on the sweep subsystem. I know you have a *WAI at the end, but not every command in the book implements the use of the status register. Some are assumed to take zero or negligable time.

If I were faced with your problem, I would start hacking out the long string to find out what command is causing you the problem. Also, I believe I would put the instrument in hold mode while I was changing things such as video and res bandwidth. Commands that cause the major changes like that could dramatically change a sweep period in which case when you finish your setup, the new number of points has not changed. What I am saying is that if the instrument is sweeping, you should not expect the change in the number of points to take place until the current sweep is finished. You would think that the WAI would assure that this would happen.

I would just experiment until I figured out how things worked and mark it down to the oddities of a specific product. I assure you that you will not find two instruments that implement *OPC and *WAI exactly alike. It is rather common that only commands that start time consuming processes even implement them.

I hope this helps.

Brent
Like • Show 0 Likes0
Actions
Dr_joel Apr 16, 2007 4:33 PM
Mark Correct
Correct Answer
Caveat: Don't know the 4407 at all...

But, with SCPI, I think the convention is *wai says "don't process any commands after *wai until all the commands before are complete".

Thus, you have said "change the points, change the start/stop, and output the trace as fast as you can...then wait until everything is complete before doing anything else"

If the output trace command is very fast, and the change points is not, then it is emminently reasonable to output 401 points, as that is what you asked for.

Brent is exactly right that best practice is to first hold the instruement; change the number of points, start, stop, then *wai, then trigger, then *wai, then read the trace data.
Like • Show 0 Likes0
Actions
Freddy Apr 17, 2007 9:24 AM
Mark Correct
Correct Answer
Thanks for your answers, in the moment I know the problem, please give me the better solution.

I would like change center frequency, wait a sweep to complete the refresh, and take the trace (maybe 100 traces in this way). My question is how know that the E4407B is in process, for not send more commands until finish the work, how know the busy state?.

Thanks in advance.

Freddy Coal
Like • Show 0 Likes0
Actions
Dr_joel Apr 17, 2007 5:03 PM
Mark Correct
Correct Answer
Hi, I don't think you can -know- it's in process...you must send commands and wait for it to return.

The classic way is to send the setup commands, and after the last command send *wai. then send the init command to take a sweep, (also with a *wai, I think), and then send the trace read command. The analyzer should (-should doesn't mean always will, but we can hope) hold off processing the init and trace command until it has processed all the commands before the *wai. Sometimes, things slip through and commands don't hold off for the *wai, so I usually find a command I like that I know waits, and then use that to sink up...in the VNA it's the single sweep command, with an OPC, which I know doesn't return 'til it's done. As for the 4407, I don't know the specific commands, but do as brent said, and parse out bits of your original string with *wai at the end of each. Don't forget the trigger command (usually init:imm).
Like • Show 0 Likes0
Actions
nizuchi Jun 5, 2007 1:08 AM
Mark Correct
Correct Answer
Hello Freddy,

First, if you put "*WAI" before "TRAC:DATA? TRACE" query, you should be able to get 601 points of data as expected. (I tried it myself and it worked.)

And, FORM INT,32 returns value in mdBm. If you devide return value by 1000, you'll get numbers in dBm.

This format is a bit tricky to handle. Firts it returns #, followed by number of bytes of header, then actual data size in byte. For example, if you read 601 data in FORM INT,32, first header data is "#42404", meaning, 2404 bytes data is to follow. As a matter of fact, the number of data is 601 x 32bit of integer.

So, to process this, you skip first header "#42404" then, store the following every 4 byte data to 32bit integer array. Then devide them by 1000 to get value in dBm.

Hope this helps!
Naoya
Like • Show 0 Likes0
Actions

Translate data trace to dBm

Outcomes

Related Content

Recommended Content