LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

can we process 2k*33 data in 20ms??

we have a PCI AD card to sample the signal at 200MHz. First we need to transfer the data 2k*33 to RAM via PCI bus . every 20ms, we get 2K*33 data to construct a image and display it in real time.

we need to do LOG compression and color table conversion at least. Is it possbile for labview? is there any code i can download?

We are doing ultrasound imaging. Thanks
0 Kudos
Message 1 of 3
(2,221 Views)
Assuming 4 Bytes per value transmitted, that's 2,000 values x 4 Bytes x 33 Channels = 264kb per 20 ms. Multiplying by 50 to give the data rate per second gives 264,000 x 50 = 13,200,000. So there are around 13 Megabytes per second which you want to process and display in real-time. Seeing as the PCI bus can handle 133 MB/sec, the PCI bus is definitely not a problem.

The problem is most likely going to lie with the displaying of the processed values, and to an extent the processing itself. 13.2 MB is quite a lot of data to ship around per second. If you don't have a display to actually show 2000 pixels wide (or high, depending on how the image is generated), then you can scale the data down to a smaller size which will still look good on the monitor, but will significantly speed up the display. I'm assuming that each value read corresponds in some way to a unique pixel of the final image.

My feeling (having no experience in processing ultrasound signals) is that it's probably do-able, but it's probably better to go the LabVIEW real-time route to make sure the processing isn't interrupted too much by OS activity. A 10 second interruption by the OS results in a whopping 130 MB backlog in memory.

Hope this helps.

Shane.
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)
0 Kudos
Message 2 of 3
(2,216 Views)
Hi,

You could also skip every other frame. 25 Hz is still enough to see smooth animation. Some sort of interlacing is also possible (alternate between updating even lines and uneven lines).

Perhaps the LOG compression and color table conversion can be combined in one LUT, so each measured value can be indexed from one table. That should be really fast.

Regards,

Wiebe.


"shoneill" <x@no.email> wrote in message news:179498@exchange.ni.com...
Assuming 4 Bytes per value transmitted, that's 2,000 values x 4 Bytes x 33 Channels = 264kb per 20 ms. Multiplying by 50 to give the data rate per second gives 264,000 x 50 = 13,200,000. So there are around 13 Megabytes per second which you want to process and display in real-time. Seeing as the PCI bus can handle 133 MB/sec, the PCI bus is definitely not a problem<br><br>The problem is most likely going to lie with the displaying of the processed values, and to an extent the processing itself. 13.2 MB is quite a lot of data to ship around per second. If you don't have a display to actually show 2000 pixels wide (or high, depending on how the image is generated), then you can scale the data down to a smaller size which will still look good on the monitor, but will significantly speed up the display. I'm assuming that each value read corresponds in some way to a unique pixel of the final image.<br><br>My feeling (having no experience in processing ultrasound signals) is that it's probably do-able, but it's probably better to go the LabVIEW real-time route to make sure the processing isn't interrupted too much by OS activity. A 10 second interruption by the OS results in a whopping 130 MB backlog in memory.<br><br>Hope this helps.<br><br>Shane.
0 Kudos
Message 3 of 3
(2,173 Views)