Leaderboard

And going beyond 1500 bytes MTU is only an option if you are on a controlled network where you do know about all routers involved between the two parties. Once you go outside of that, such as an internet connection, the maximum MTU is entirely out of your hands and going beyond the default of 1500 bytes is really playing chances that the communication will actually work, unless you do a lot extra work in reassembling the incoming packages into the right order on the receiving end. And that is something that is even on embedded devices usually handled much more efficiently by the TCP protocol level, so why go to the hassle of UDP in that case? As to data transfer of LabVIEW TCP, it has some overhead in its internal buffer handling but I have in the past reached half the bandwidth of the network without to much trouble, as long as you don't do a two way handshake for every packet send. There used to be some challenges in older LabVIEW versions, with LabVIEW simply loosing data or even crashing on heavy network load (supposedly some rare race conditions in its socket handling), but I haven't seen such things in newer LabVIEW versions.

There's a TFTP example on the NI website: https://decibel.ni.com/content/docs/DOC-8301 No need to reinvent the wheel.

Yes. This is a similar VI that it used in the "OPP Push File" in the LAVA CR. It opens a file and reads "chunks" that it then sends (in this case) via bluetooth. You need to do the same except with UDP rather than bluetooth..

Just read 65k bytes (or 1500 bytes is better for the reasons Rolf outlined) from the file at a time and write it using the UDP write. However. As GregR stated. It is not guaranteed to be recieved in the correct order, or indeed a chunk to be received at all! So that's not a lot of good for files, but usually acceptable for audio or video where a lost frame or two doesn't matter too much. The easy solution, as others are saying, is to use TCPIP where all the ordering and receiving reassembly is handled for you (as well as other things UDP doesn't do out-of-the-box such as congestion control, re-transmission of lost packets etc). If you really must use UDP then you will have to code all that yourself (unless missing or incorrectly ordered file chunks is acceptable-for TDMS it wouldn't be). There are a few examples of reliable UDP (RDP). Noteably UDT and NORM. I am not aware of anyone doing this in Labview however, since it is just easier to use TCPIP.

You can increase the udp buffer size under windows by accessing the socket. See my post from the NI forums... http://forums.ni.com/t5/LabVIEW/Change-UDP-Socket-ReceiveBufferSize-under-Windows/td-p/483098

No. I'm saying the payload cannot exceed 65k. If you can send 1 payload (of 65k) every 10ms then that would be 6.5 MB/sec

Under windows, the default udp datagram size is 1500 bytes (i.e the default MTU). The maximum it can be is 65535 bytes (you can set it to more than this, but it will still be limited to 65k ). This is because the UDP header field is a U16 and cannot represent more than 65k. UDP, User Datagram Protocol

It's incorrect to say that UDP is a "faster" protocol. It is more lightweight than TCP, but that doesn't inherently make it faster - especially in the use case you have, where you'll basically need to handle everything that TCP does automatically (and at a lower level). Speeds far in excess of 2Mbps are feasible using TCP, so you probably need to take a look at your implementation and maybe talk to your teacher about what you can do to optimize it.

In most languages the Booleans are stored as bytes. Memory is cheap. Also, to store a single Boolean on any modern computer, it will always use a byte. It is the smallest addressable piece of data on any computer. Even for arrays it would not pay to pack the Booleans into bits. As I said, memory is cheap, and having to do arithmetic to read a single Boolean value is a bigger waste of resource than memory space is... In the end, you usually want it simple and fast. Br, Mike

UDP does not guarantee ordering, non-duplication or even delivery of "chunks", so you would need to make sure each write contains enough information to completely identify which part of which file it is. That way you could reassemble them on the other side. Even then you may not get them all, so probably want a way to ask for some part of the file to be resent. These are things that TCP would take care of for you. Do you really need to use UDP?

Can you send your data in chunks? You really don't want to set your datagram size to megabytes.

Your IT guy was wrong. If Windows Device Manager sees a serial port, its because there is a serial port. This may not be a normal serial port that is exposed to the outside world via a DB-9 but an internal one for diagnostic support. I've seen several PCs have internal serial ports that allows for for intimate access to the PC, or it is possibly a serial port that is only accessible through a dock that the laptop is connected to. In any case it is not going to be a serial port that is going to be available for communicating with other hardware and investing in a USB-to-RS-232 is going to be a good idea. I've heard some cheap ones don't work with all hardware, but I haven't found any hardware my no name cheapo couldn't talk to yet.