I am reading UDP packets which are coming at a rate of 1000/sec into a PDA. I am writing the packets into a queue, then reading them out as required. My problem is that Labview keeps up with it for about 40 samples, then it looses packets.
According to the NI Knowledge Database (Reference:
, Lost UDP Packets at Fast Transfer Rates may occur because Labview can't keep up with the UDP buffer and the solution is to increase the size of the OS socket buffer size by making a call to setsockopt function in the wsock32.dll.
Question, This works for Windows XP, which has wsock32.dll, but it does not work with Windows Mobile 5.0. I assume because Windows Mobile does not have wsock32.dll. So what does Windows Mobile use in it's place so I can increase the buffer size ?
MSDN has information on the setsockopt here:
It explains what you can do in Windows Mobile and mentions the library and header toward the bottom. Might be a good place to start.
Thanks David for your help.
I have located a copy of the ws2.dll (winsocket32 equivalent for Windows Mobile) and modified the example
vi, to reflect the change. However, when I build the UDP_buffer_example.vi under a Labview PDA Module project, I get a build error "GetManagerLong is a missing VI or C file". I narrowed the cause of the error to the UDP Get Raw Net Object.vi, which comes from the c:\Program Files\National Instruments\Labview 8.5\vi.lib\Utility\tcp.lib.
Any ideas why this happens ?
Have you made sure to include the dll and header files in your project? Also check out the following KB about calling external code in LabVIEW PDA:
Hopefully this helps.
I am using a Dell Axim X51 PDA with Windows Mobile 5.0 (ie. Pocket PC ).
I had no problems with it reading UDP packets, except loosing packets because of small OS buffer size, hence why I am trying
to set the buffer size with a call to setsockopt.
The UDP packets are sourced from an embedded data acquisition system using a FPGA. I can slow the rate down, but it would take longer for the PDA to gather all points required->in my case to built power spectrum density.
The UDP receive and Transmit examples work on the PDA but the receive is unable to keep up, which is why I am using a queue to try to buffer the packets quickly and then read out of queue at a slower rate. However, I find unless I slow the UDP packet rate right down I will lose packets.
I have an example of increasing the size of the windows winsock buffer in Labview, and I am confident I can adapt it to Windows Mobile. However, I can not do that unless I can convert the UDP refnum from the Open UDP socket vi and convert it to a DLL socket reference. The "UDP Get Raw Net Object.vi" provided under Labview that I have talked about is password protected, and will not work under Windows Mobile (Getmangerlong error). If I can at least understand how it works or somehow unlock it, then I can modify it to work under Windows Mobile.
I have looked at the Windows Mobile forums they are not much help.
So can you eithwer give me a version of "UDP Get Raw Net Object.vi" that is not locked so I can modify it or explain how it converts UDP refum to a DLL socket reference ?
Unfortunately, not even we have access to the locked VIs and I do not personally know what goes on inside of that VI. It would be my guess that the GetManagerLong is a function in another dll on the PDA side, but it is not found at compile process on the windows side. One possible option is to create a stub dll. This will be a "fake" dll that will make the compiler think the dll is there, but once it gets deployed to the PDA, the code will access the real dll on pda. Instructions can be found here.
My only other suggestions would be to either slow down your UDP sender to send data at a speed that the PDA can handle inherantly. This would not really cause a slow down of your data collectio. The PDA can only handle the speed that it's getting now and by increasing the buffer, you are only giving more room to put the faster data temporarily while it is being processed slower on the other side of the buffer. In the end if you increase the buffer and process the data, or if you slow down the original data, the final processing of the data will be the same speed.