RMP response message packet delay
RMP response message packet delay
After writing a script(based off the python demo program), the script we developed has issues with dropped packets. In order to ensure all of the commands are executed, the script would wait until a packet is received back. Sometimes this wait is short, and sometimes it can be quite long. Is there a way to clear out the buffer from the RMP and send it a new command if it is having trouble sending the packet back?
-
sdnalloh
Re: RMP response message packet delay
What method are you using to connect to the RMP?
USB is notorious for dropping packets.
USB is notorious for dropping packets.
-
Phillip.Wong
- Posts: 5
- Joined: Fri Oct 04, 2013 2:11 pm
Re: RMP response message packet delay
We connected to the RMP through Ethernet, but also wireless with a router. Do you have any advice for our current setup?
Re: RMP response message packet delay
Here are a few notes and tips based on your question:
1. The RMP uses UDP for the ethernet protocol, meaning that there is no guarantee of delivery. That means that you will have to handle verification of receipt by checking the response.
2. Wireless is notorious for dropped packets due to channel conflicts and poor signal.
3. The python OCU demo uses a non-blocking socket which requires a user to write a blocking loop to wait for incoming messages or a background thread. It also uses pygame which is not particularly well suited for critical timing applications.
My suggestions:
1. Personally if timing is critical I would use a C++ socket and run a TX/RX background thread that implements buffered communication, with message handlers to the application. Alternatively python does have threading modules which you could do the same thing in.
2. Check you channel setting on your wireless router, try changing the channel to ensure there is no conflict with other devices in the vicinity.
3. If timing and bandwidth are critical, create your own network. I have had the best luck by setting up my own network with 2 routers that support AP and Client. AP connected (wired) to your computer and Client on the platform side. I have used both the Linksys WRT54GL DD-WRT and the new TP-LINK TL-WR702N with great success and prefer the TP-LINK TL-WR702N due to the small size and easy setup.
Hope this helps!
1. The RMP uses UDP for the ethernet protocol, meaning that there is no guarantee of delivery. That means that you will have to handle verification of receipt by checking the response.
2. Wireless is notorious for dropped packets due to channel conflicts and poor signal.
3. The python OCU demo uses a non-blocking socket which requires a user to write a blocking loop to wait for incoming messages or a background thread. It also uses pygame which is not particularly well suited for critical timing applications.
My suggestions:
1. Personally if timing is critical I would use a C++ socket and run a TX/RX background thread that implements buffered communication, with message handlers to the application. Alternatively python does have threading modules which you could do the same thing in.
2. Check you channel setting on your wireless router, try changing the channel to ensure there is no conflict with other devices in the vicinity.
3. If timing and bandwidth are critical, create your own network. I have had the best luck by setting up my own network with 2 routers that support AP and Client. AP connected (wired) to your computer and Client on the platform side. I have used both the Linksys WRT54GL DD-WRT and the new TP-LINK TL-WR702N with great success and prefer the TP-LINK TL-WR702N due to the small size and easy setup.
Hope this helps!
Who is online
Users browsing this forum: No registered users and 3 guests