On the PNA-X N5242A, I am trying to use receiver leveling with point triggering a power sweep .
Is there a SCPI method to tell when the RX Leveling loop is complete and ready to sweep? Ie Waiting at the 1st points power level?
Good question. I don't know. It might be we switch out of point triggering for the background sweeps, but I haven't ever tested that condition. I'll try it let you know. Or...I might just ask the guy that wrote the code what he's doing in the code.
Thanks for looking into it Dr.Joel.
Strange had another 2 parts to the question one I answered myself.
Is there a SCPI command to read back the sweep indicator, or the position on the sweep during a point trigger sweep? (Besides counting triggers and hoping each trigger completes the intended action. I have ran into issues with initial and re-sweeps being quirky on the number of triggers it needs on previous Network analyzers. Though my intended 2nd question helps with this that the opc now works with point trigger completions and dosen't just wait till the sweep is completed like on previous network analyzers.)
Ok got a additional question is there a scpi command to set a external pmar device as a reference receiver?
I am using a external power sensor as my reference, that i have configured as a PMAR Device0 and enable for the GUI. But when i send the scpi command
"source:power:alc:mode:receiver:reference 'Device0,1'" or
I got a error a "invalid parameter", which i am assuming the command doesn't like using a external device since it works with "R1" instead, though i can manually set it in the GUI and read back the reference value and read back "Device0,1"
I have a work around of saving the device0 as a reference receiver in a cal state and with scpi recalling it that seems to work.
Is Device0 activated and enabled in the channel before you send that command?
Yes I do before sending the command I have a trace using device 0 as it receiver.
I've already noted it seems to get external receiver leveling to Function with the GUI, a trace using device0 was required. You could select external leveling receiver as device0 but the sweep wouldn't start till a trace was using device0 .
I have taken the same setup where I manually configured device0 and have a trace using device 0 as a receiver, and get the invalid parameter when I send the
sorry for the late reply; I've been on the road. Can you please provide the firmware version of your PNA-X and if possible a state file (.csa) of your setup right before you send the sour:pow:alc commands?
The PNA-X is running firmware 10.49.10.
Unfortunately can't send you the csa state from that machine.
I'll try to recreate your setup from the description you have provided and will get back to you.
I finally had a chance to be at my desk long enough to test this out and it appears that we have a bug. the remote interface is validating the receiver name only against the internal receiver names and as a result your PMAR is getting kicked back as an invalid receiver name. I am entering this into our defect database and it will be addressed on the next release on that branch (which will be a A.10.60.xx)
Thanks for verification.
Haven't heard anything back on the first question of is there a scpi method of determining the leveling loop is complete?
there is a new command: TRIGger:STATus:READy? that will return true when the specified external trigger line is ready. All RxLeveling pre-sweeps are done prior to trigger-ready, so this will work if you are a) in external trigger mode and b) you have RxLeveling turned on. you can read more about this command here.
To get this command, you'll have to have the latest A.10.60.07 firmware running on your PNA, which you can download from here. Note that this command will only work on PNAs that have DSP version 5 hardware installed (basically any PNA that has shipped in the last 2-3 years). you can see the DSP version of your PNA by using the Help->About dialog.
Well have a few questions on that.
a. I am not using external hardware triggering, I am using scpi "Init" to trigger a Point sweep of power.
The documentation is all referencing external hardware triggering. So will this work with internal manual triggering?
so for example my test flow would be :
setup receiver leveling and point /manual triggering
Check if status is ready? Loop till ready (Leveling loop complete, 1st point power is outputted)
Initiate loop for number of Points in sweep
Take measurement query of DUT Detector (expected PNA power is outputted)
Read opc and 1 is received
Go to next iteration until point sweep loop completes
Finish measurement sweep function/ iterate next sweep. (Leveling Loop runs in Back Ground)
b. if a part of the test setup that between the receiver and the source changes loss/gain , changing frequency's will restart the Power leveling loop?
a - So right now, this does only work for external triggering scenarios. I have brought your use case to the attention of the firmware team and they are looking at the feasibility of extending the functionality to manual triggering as well. In most instances, customers who use point trigger (with or without RxLeveling) do so using external hardware triggering. Manual software triggering in point mode would be significantly slower and therefore not often used by customers and that is why it wasn't included in the scope of the "TRIG:STAT:READ?" command initially.
b- I am not sure exactly what you are asking here, but if you have a channel in power sweep mode and you send a command to change the channel's CW frequency, that will trigger an abort of the current sweep (if you are in continuous mode) and RxLeveling will start again when the next sweep is initiated.
Retrieving data ...