NI 5124, max points measured with 256MB memory

Question

I want to know if there is a simple calculation that i can do to know
the maximum amount of points that i can measure with the 5124 scope.
With My application i want to measure a burst of 520 mS of signal at
ones, the signal is downconverted from 406MHz  with the 5600. So
the signal is at a minimum frequency of 5MHz. This burst i want t save
completely and still be able to retrieve offline the following features:
- Frequency
- Power
- IQ
- Decode the message.
For this i need a high enough sample rate (minimum niquist). So as
absolute minimum i need 520mS signal, but it would be nice to have at
least 1 second of signal..
is there an ellegant sollution for this?
Regards
Joost van Heijenoort

Answer 1

So I've implemented the change and it seems to work a bit better. I don't know if there's a drastic speed increase, but the intervals between stage motion (the only indication that an acquisition is done in the auto acquire mode) seem more uniform and on the quicker side of where they were last night.
I opted against using the "Fetch Relative To" property node in your example (which is for continuous data acquisition) in favor of the "Fetch Offset" property node used in the 'Fetch in Chunks' NI-SCOPE example (which is more along the lines of a single triggered acquisition like my situation). I also found that fetching relative to the read position wouldn't start the data stream at the normal pretrigger location, even though the position is supposed to be set to zero after each acquisition start. I would presume I would get the same waveform out using 'fetch relative to:read position' as I would using the scope soft panel, but it doesn't.
A similar problem I have now that I've messed with the "Fetch Relative To" property node is that now it seems like I have to make an extra acquisition before anything like trigger delay or number of samples to read is registered. In the manual mode, I used the "Fetch Relative To: Pretrigger" in order to get the section of data to be properly oriented in time. But it still exhibits the updating only after an acquisition has been made. Example: I setup a 1Msample acquisition at 50MS/S w/ a trigger delay of zero. I acquire and see my pretty graph. There's an interesting feature at t=8ms, so I set my trigger delay to 8ms, but I have to acquire twice in order to see my graph update with a waveform that starts near the interesting feature. Any idea why this is happening now?
Also, I've attached a screenshot of the acquisition loop. Let me know if this is approximately what you had in mind for fetching 65000 bytes (or 65000 data points w/ my I8 acquisition) at a time and streaming that to disk. Now that I look at it, it might make more sense to use another queue (like in your example) that passes the waveform ID and the chunk of data to a separate loop that is always waiting on data to write to disk. Also, when I save the files, I'd like to be able to load them and see the original Voltage/timing information on the file and I'm at somewhat of a loss as to how to include information like offset, gain, t0 and dt. Right now, even though I think it creates a weird header at the beginning of the file, I use the waveform attributes to keep this information.  I ended up saving those four items in reasonably related waveform attributes, but if there's a better way you can think of, let me know.
Attachments:
FetchinChunks.jpg ‏181 KB