From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

UDP Data lost at High Rates using Queues for PDA

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:

http://digital.ni.com/public.nsf/allkb/D5AC7E8AE545322D8625730100604F2D)

 

, 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 ?

 

Regards

 

Muzza

 

0 Kudos
Message 1 of 10
(3,632 Views)

MSDN has information on the setsockopt here:

 

http://msdn.microsoft.com/en-us/library/aa926453.aspx

 

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.

0 Kudos
Message 2 of 10
(3,606 Views)

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 ?

 

Muzza

0 Kudos
Message 3 of 10
(3,590 Views)

Muzza,

 

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:

 

http://digital.ni.com/public.nsf/allkb/517300B49212795986256DDD00623FEE?OpenDocument

 

Hopefully this helps.

0 Kudos
Message 4 of 10
(3,569 Views)
I have included dll and headers in my project, no change. If I make a vi, with nothing but a UDP refnum attached to "UDP Get Raw Net Object.vi" and add it to a blank project I still get the error. Under Windows XP on my PC, no problems. I have a question ? Is "UDP Get Raw Net Object.vi" windows OS specific ? If not not, how do I change it considering that this vi is locked with a password ? Muzza
0 Kudos
Message 5 of 10
(3,554 Views)
The UDP Get Raw Net Object refers to that GetManagerLong function which is OS specific.  What device are you trying to deploy this on?  Maybe I can give it a try and see if I have the same problem, however I have a pretty good feeling that I will.
0 Kudos
Message 6 of 10
(3,536 Views)

David

 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.

 

 

Regards

 

Muzza

0 Kudos
Message 7 of 10
(3,524 Views)
Few questions.  Where are you recieving the data from?  Can you change this source to slow down the transmission speed?  Also have you tried using the UDP Send and recieve examples from example finder?  Does this work for you?  Maybe the answers to these questions can help gain some insight.  Also you may want to try searching around on some Windows Mobile specific forums since this is a more a problem with the windows API than with LabVIEW.
0 Kudos
Message 8 of 10
(3,447 Views)

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 ?

 

Muzza

0 Kudos
Message 9 of 10
(3,418 Views)

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.  

0 Kudos
Message 10 of 10
(3,400 Views)