03-25-2009 12:58 PM
Hi guys,
I have currently using E4440A SA. I have used LabVIEW 8.0 with the instrument drivers provided at NI. Currently, I have some problem whereby the acquistion for per trace data was set at 1 sec from the wait for operation complete vi. This pose a problem to me as there is a loss of real time data. Henceforth, i have changed to about 40 msecs where my sweep time was 36.87 msecs. The hardware SA tends to hang after running for about 3 hours continuously.
I sincerely seek help to enquire how can I achieved in getting the real time data, without setting the wait for operation vi as I believed the SA hangs was due to the setting. Thanks a lot.
Rdgs
Chew
03-25-2009 02:03 PM
I worked on and with the E4440A for about three years (but, unfortunately, not with LabVIEW). I think what you need to do is set it to single sweep mode and send the *OPC? command -- with a 1 second timeout. If the instrument times out (and it does, I know the behavior you are referring to), the best thing to do is reset the instrument (*RST) and setup all of the parameters again.
It's a great instrument, but it does have its quirks. I had one that occasionally decided it wanted to be system controller and threw everybody else off the GPIB bus. Took me a while to figure that one out because it was the only instrument I could actually talk to...
03-25-2009 02:54 PM
Hi Matt,
That sounds about right.
Chew,
Can you post your code in case we can see womething that may contribute to the slow acquisition?
R
03-26-2009 01:34 AM
03-26-2009 07:07 AM
Hi Chew,
I have not yet looked at your vi.
I was amused about your comment conerning R&S. I've often worked with both and much prefer working with R&S. They are more costly, but -wow- they are fun to work with.
Depending on the R&S model that you are working with, you do realize that the internal A/D circuitry within the R&S is superior to the E4440A, right? That means better sampling rates, which in turn has an impact on your acquisition. 😉 {not that I'm biased or anything 😄 }
R
03-26-2009 07:21 AM
Hi Chew,
I had a look at your code. Correct me if I'm wrong in my understanding...
The outer loop configures the SA for every group of 9 samples which are then saved if "Peak & Noise" is selected.
Do you actually want to configure the SA at every interval of 9 samples? Are you doing this so that you don't need to stop & restart the application when you want to change your settings? Every time you start a new set of acquisition, it will take extra time just to setup the instrument, which may be un-necessary if you continuously take samples without changing the settings (Spa, VBW, RLev, Log).
If so, there is an architecture to avoid that situation.
Why do you have 99ms delay in the inner loop? There is no reason for such a delay. Since it is reading the trace within the loop, it will take some time to execute each iteration, so no need for extra wait time. You could put a value of 0ms or 1ms to allow the processor to tend to other tasks, but that may not be an issue anyway.
R
03-26-2009 09:43 AM
Hi Ray, I cannot be bias but I cannot not agreeing with you about R&S. Frankly, they do have a faster sampling time and especially, I able to achieve more real time data, with the sampling time. Fantastic!
Regards to my programming, i have tried to place 0 ms as per advice but still achieving a slow acquistion. My suspect may due to the wait for acquistion complete vi, where a 1000 msecs or 1 sec wait time was placed in there. However, if i changed the wait time, i discovered the hardware will 'hang' and hard reset on the instrument have to be done. Perhaps, I have take note about the instrument. The sampling time is quite fast compared to R&S. However, if i try to capture the data at a faster rate (slower than the sweep time), the instrument give the earlier problem. I sincerely wonder if you could advise me in a better architerature. By the way, i do like to keep the outer loop for other purposes. 😉 But only to the inner loop, the acquistion still give me problems and headache.
Thanks a lot. 🙂
Rdgs
Chew
03-26-2009 01:07 PM
I'll be able to work on it tonight.
R
PS: We're saying the same thing about R&S, right? They do have faster sampling 🙂
03-27-2009 02:00 AM
04-03-2009 11:55 AM
Sorry for the delay to post the example...
Have a look at the attached code. I didn't do code cleaning and I could not test it (plus I didn;t have the SA VI's installed at this machine).
It should give you an idea of what I was referring to in my previous post.
R