DAQ Counter for FSK Tx

[Tom_Q]

I want to produce an FSK digital output on USB-6363 with frequencies of 150kHz and 200kHz, I was thinking that the counter would provide the highest resolution by dynamically switching the frequency with a property mode. Is it possible to simultaneously specify the duration (finite samples) with each symbol. The modulation scheme uses 4 cycles @ 200khz for a high and 2 cycles @ 150khz for a low. The patterns that need to be generated are too large for the FIFO so if I use a Digital Waveform the DO Sample Clock frequency is limited to 1 MHz and can be impacted by the system and bus activity. So I'm thinking the counter would be a better choice if the samples and frequency could be synchronized, if so what would be the sample frequency? Is there a way to generate this output with a resolution of 10 MHz or higher?

[Kevin_Price]

FSK isn't something I've done, so I first want to be sure I clearly understand what this pulse pattern needs to look like and what's supposed to control the frequency changes.

For example, you could just generate a continuous free-running pattern of 4 cycles @ 200 kHz, followed by 2 @ 150 kHz, then back to 4 @ 200k, etc. with a simple-ish buffered counter output task.

But my quick skimming about FSK seems to suggest that the freq changes are done in response to an external signal.  However, in that case I don't know why you'd be specifying a # of pulses at each frequency.  It seems like it'd be unknown and in a lot of cases unknowable.

Are those minimum #'s of pulses such that you won't consider responding to an external signal until you've gotten through that amount?   Or are you looking to issue exactly 4 @ 200 kHz in response to a signal and then go idle until you get the signal to change and issue exactly 2 @ 150 kHz and then go idle again?

The knowledgebase article I found here lists several specialty RF instruments but no DAQmx devices.  Your 6363 is a very capable piece of DAQmx hardware with a lot of versatility though, so if there's any way to do it in DAQmx, you've probably got the right device for the job.  (Caveat: there are some times when the USB version of a device has some performance limitations when compared to a desktop card.   In fairness though, there were also certain M-series USB devices that had improved on their desktop counterparts, specifically the boosted counter FIFO size.  They were able to support higher sustained rates of frequency measurement as a result.)

-Kevin P

[Tom_Q]

Thanks for your response, there is no idle time between the 150kHz and the 200kHz. Typically, the output is a sinewave with the frequency switching at the zero-crossing, I’m driving a coil with the digital signal so in the end it looks like a sinewave. Since the data-stream could be quite large I won’t be able to use the DAQ's buffer. Each high bit in the pulse train needs 4 cycles @ 200 kHz and each low bit needs 2 cycles @ 150 kHz the frequency stream needs to be continuous until the end of the data-stream.

[Kevin_Price]

Now I'm actually more confused.

---

there is no idle time between the 150kHz and the 200kHz. Typically, the output is a sinewave with the frequency switching at the zero-crossing

---

But your original post talked about an FSK *digital* output, preferably with a counter.   Now you bring up sine waves and zero-crossings?  Which is it?

---

Since the data-stream could be quite large I won’t be able to use the DAQ's buffer. 

---

Good news for you here.  This is a fairly common misunderstanding.  You are *NOT* limited by the device's onboard hardware buffer size.  DAQmx tasks *also* use buffer space in PC system memory by default.  You could make a buffer size of 10's or even 100's of MB.  You'd have to go out of your way to instruct DAQmx to use *only* the device's onboard hardware buffer (aka "FIFO").

    The DAQmx driver is quite good at delivering data from application PC memory down to the hardware device.  However, this is one area where a USB device will suffer compared to a PCIe device.  DAQmx can't deliver more data at a time than the size of your PC-side buffer.  Thus, the amount of *time* represented by that PC-side buffer tells you the minimum *frequency* at which DAQmx must deliver data down to the device.

    In your case, your 38+2 cycles in the 100's of kHz represent a total of about 0.2 millisec.  If you write a single cycle of your pattern into the PC-side buffer, DAQmx must keep delivering all of it at a 5 kHz rate down to the device.   While I expect that'd be no problem for a PCIe device using DMA memory access, it's probably not gonna work for USB.

    The workaround is fairly simple though.  Offhand I'd target a buffer size to be about 10 millisec worth of data.  So for your situation, just take your 0.2 millisec pattern, and generate an array that repeats that pattern 50 times.  Write *that* much larger amount of data to your PC-side task buffer.  *Then*, your USB device is probably going to be able to handle it.

Each high bit in the pulse train needs 4 cycles @ 200 kHz and each low bit needs 2 cycles @ 150 kHz the frequency stream needs to be continuous until the end of the data-stream.

---

Not *entirely* clear what you're describing here.  Here is my best effort at guessing:

    The 38+2 FSK pattern describes what you need a counter output task to do.   That same counter output signal will be used by an AO task for sine wave generation.   So when the counter frequency changes, so does the sine wave frequency change proportionally.   The AO sinewave frequency will (of course) then depend on the # samples per cycle.

-Kevin P

[Kevin_Price]

I'm curious whether you've got your app working.  If so, could you share your end result?  It could be helpful to someone down the road.

-Kevin P

[Tom_Q]

I got it working perfectly.

[JensG69]

Even if you got it already working, how about a digital output with a base frequency of 600 kHz. Pattern for your 200 kHz section would be 3 ticks low, 3 ticks high, pattern for your 150 kHz section 4 ticks low, 4 ticks high. Total lenght of that "pulse train" would be 40 ticks.

Regards, Jens