TCP/Ip and UDP in Matlab

Hi, I'm trying to code for TCPIP n UDP. The case is: Computer is connected to Vector Network Analyzer, I'm running a Matlab application in my computer. BUt now I want to stream data from Network analyzer to computer. I'v written some code using matlab help. but since its live streaming data i'm facing a problem. Plizz help

[Walter Roberson]

Which problem are you facing?

[Rohan]

The Requirement is: VNA has to listen and send the data continuously. If there is an interrupt(data) from user(laptop), the VNA should process that receive data and do necessary action. for eg send "this" much of data to laptop and so on. The problem I'm facing is I'm not able to stop VNA when it enters the loop.

[Walter Roberson]

What you describe sounds like a difficulty on the VNA end, which we do not know anything about.

Alternately you might not be sending the packets in the right format, or your packets might not have the line terminator the VNA expects (if the format is line-oriented).

Have you used a tool such as WireShark to monitor the packets you are sending out from the laptop?

[Rohan]

Thanks Walter. Data acquisition part is not an issue. The main problem is "I want to control VNA from my laptop" that is the VNA has to stop processing or transmitting/receiving when I send the stop signal(that happens to be an integer value).

[Walter Roberson]

My previous comment still stands: that sounds like a difficulty at the VNA end, and we don't know anything about that device. Or you might be sending packets in the wrong format. Have you tried monitoring what you transmit using a tool such as WireShark to monitor what you send?

[Rohan]

Well Walter the only thing missing here is the concept of multi threading. I cannot implement it in Matlab. Is it possible in Matlab?

[Walter Roberson]

I do not immediately see what multiprocessing has to do with the matter.

You wrote that you are not able to stop VNA when it enters the loop (I'm not sure which loop, but anyhow.) Multiprocessing would not appear to change that. Is the VNA listening to you or is it not listening to you?

There is no MATLAB data collection mode that takes the full attention of MATLAB. Data collected from serial objects, digitalio objects, or analogio objects (including winsound), or tcp or udp objects, is buffered automatically, and that is true whether you are using basic MATLAB, or the Instrument Control Toolbox, or the Data Acquisition Toolbox. Your program asks to transfer the data from the buffer and place it in a MATLAB variable. That can happen by you reading whatever is available, or by you checking BytesAvailable to determine if enough data has accumulated to warrant reading, or by you programming a BytesAvailableFcn callback that is called automatically when conditions warrant. Any of the three ways, you always have control in-between and can do other things (processor time permitting), including sending out a command to tell the other end to stop.

The important question in this matter is whether data will continue to accumulate in the input buffers while MATLAB is doing other activities, and the answer for all of those device object types is YES. It matters not whether this is by way of internal interrupt routines or by way of multithreading: it is transparent either way.

[Rohan]

I have some good news... I'm almost there.. I wanted multi threading becoz I was trying to do the same as it is in Unix socket programming.

Thanks for ur time Walter. I'll let u knw when i'm finished

[Walter Roberson]

Unix socket programming does not require multiple threads.

[Rohan]

UNIX requires multiple threads...If u want monitor something ..the same time u want to process a job.

[Walter Roberson]

No UNIX does NOT require multiple threads for that. You use select() with a timeout structure that uses a time of 0 in order to poll to see if something is ready. Or you use the newer poll(), but I would need to cross-check to see if that made it in to POSIX.

If you require non-cooperative multi-processing, then you can fork() off a Unix process to do the work, with the new process either taking over the socket directly, or continuing to use the listener process to handle multiple sockets and forward packets as they become available.

The fundamental Unix process inetd() was written LONG before there was multithreading in Unix.

I own physical copies of the 1989 ANSI C standard, and of the 1990 POSIX.1 standard. Neither one of them has threads. At the time of the 1990 POSIX.1 standard. POSIX threads were not added to POSIX.1 until they became POSIX.1c in 1995.

If, as you claim, Unix "requires" multiple threads for that situation, then how ever did Unix manage to survive between the time it was created in about 1970, until 1995? (And yes, it did definitely have sockets before that. Sockets were merged from BSD into System V Unix as of SVR4, 1988.)

I have personally programmed multitasking network daemons; I never used multiple threads. Multiple processes sometimes, but not multiple threads.