01-05-2011 08:09 AM
Personally, I can't really say if UDP is the best choice for you. It really depends on your application, architecture and perhaps even your time-frame and budget, etc.
UDP probably has a higher bandwidth than RS232, but there are some inherent (and potentially serious) disadvangtes also, such as dropped packets.
Here is some info about UDP: Using LabVIEW with TCP/IP and UDP
01-05-2011 01:17 PM
And there are a series of UDP examples in the Example Finder (Help menu » Find Examples... » Search tab » Search "UDP") if you decide to go in that direction.
01-05-2011 08:10 PM
Thank for your thought I think I will go with RS 232 b/c i already built code based on it but according some ppl I should have done UDP interface anyway that I will look later on. Now I am confuse I can receive something but how to write statement machine for data to get recogonised which data is CO2 or which one is SpO2 then seperate and display each. How can I build code on that part. I had attached monitor menu before you can check if you needed. Please help with part. Thank you so much.
01-24-2011 06:55 AM
I want to make wireless connection b/w Intellivue Patient Monitor and Laptop. Does anyone have any opinion or thoughts on it please share to give me start.
01-24-2011 09:18 AM
You could try using a wireless RS232 system. This is a common solution used in many industrial settings where it is not practical or safe to put a laptop. Look at this one or this one. Then you simply install MECIFView on the laptop in order to retrieve data from the patient monitor.
A couple things to keep in mind:
- Make sure your patient monitor can output serial data in the MECIF format. Check mecifview.com for a list of compatible models.
- Make sure the wireless RS232 system can support the same baud rates that are used by MECIFView.
- Make sure your hospital does not mind having wireless signals being transmitted around your patients. Some don't like this because they claim it interferes with other instruments.
- You may need to "play around" with the cabling to get it right. The MECIF format requires a special serial pinout. I don't think it'll be a problem, but there is a slight risk that the unusual pinout will cause problems. Not exactly sure. To minimize this risk, choose a wireless RS232 system that transmits all the pins in the cable.
01-24-2011 10:18 PM
Thank you for your reply.
Now my question is if I use wireless RS232 link kit and how MECIFView software will be compatible with kit since this software is done for system when I have to download data by using USB serial converter. OR I have to write software adding into it to make it communicate to laptop.
Another question of mine I am trying to down ECG wave from philips monitor by using labview. I am also using serial usb converter as you mentioned to connect monitor and laptop. I am attaching a block diagram of my design please I would like you to check it and give me your opinion on it.
01-25-2011 09:00 PM
If you use a wireless serial link as josborne suggests, you'll simply replace the USB to Serial cable in your setup with the wireless link.
The resulting setup will be:
| Instrument » serial to wireless ~~~~ wireless to serial » laptop |
Depending how you implement the wireless, the data should appear to LabVIEW as from a serial device.
The program architecture diagram you've attached looks like a good start.
01-26-2011 06:18 PM
Thank you for your reply,
I am struggling with TCP protocol anyone can help me to give a good start. I want to know how can I multi or demultiplex signal in Labview.
01-27-2011 12:20 PM
There are a few great resources for TCP communication. The first is, of course, the Example Finder (Help menu » Find Examples... » Browse tab » Networking » TCP & UDP).
However, depending on your application, the you may also want to look at Network Streams for sending data between different LabVIEW capable machines.
If you're sending command type information via TCP, you may also want to look at the Simple Messaging Reference Library (STM).
Both of the above solutions neatly abstract much of the TCP layer away.
Hope this helps,