Restart the VI so that new Tx params are set?

[cynop]

Hi,
I'm new to using USRPs and have very little experience with Labview overall. I am trying to implement frequency hopping using the example of the USRP packet transmitter. I converted most of the transmitter options to constants, since I'm mainly interested in the frequency changing aspect, and included a knob to change the frequency. The problem is that I have to stop and restart the VI for the USRP to start the frequency. I figured that there must be a way to reset the VI everytime the frequency changes without having to stop/run it manually, but so far I haven't managed to find it. Is there such a way?

[ErikL]

There is a property node that allows you to change the frequency on the fly within the loop. I believe there is a shipping example in the examples folder that excercises this functionality.

[cynop]

ErikL, thanks for taking the time to reply. I haven't found an example that allows me to simply change the value of the frequency carrier  on the fly. I know that with the 1.20 version of the driver that is possible, so I guess I'm missing something. I tried using the property node, but obviously I am doing something wrong. Any advice or hint would be greatly appreciated.

[Sarah_Y · Accepted solution]

Hey cynop,

Thanks for attaching your VI.  The first property node that you inserted you do not need.  You can wire the frequency from your case structure directly to the Carrier Frequency input of the niUSRP Configure Signal.vi.  The property node that is inside the loop is what you need to change the frequency on the fly.  When you update the carrier frequency control on your front panel, the carrier frequency of your USRP will also be updated.  One thing you should note is that the coerced carrier frequency indicator on the front panel will not update.  You would need to pull the coerced carrier frequency inside the loop for that indicator to update.  I would not recommend doing that though.  The amount of time it takes the driver to query the device for the frequency can be enough time to cause a buffer underflow error.

[cynop]

Thanks Sarah_Y. It turns out that the property node was working correctly, I was just waiting (futily)for the coerced value to change. Lesson learned 🙂