What is/was your plan for the software on the RPI & Mac? Presumably you were not looking at using a terminal emulator software long term? If you are going to write your own software to process the data it might be worth writing just the part to read the UDP packets and display something to see if the delay is present or not.
At least you know where the problem appears to be so you can get back to your main project rather than spend too much more time on side issues.
countrypaul:
What is/was your plan for the software on the RPI & Mac? Presumably you were not looking at using a terminal emulator software long term? If you are going to write your own software to process the data it might be worth writing just the part to read the UDP packets and display something to see if the delay is present or not.At least you know where the problem appears to be so you can get back to your main project rather than spend too much more time on side issues.
Well, no. You are right. I'm mapping in real-time a video on moving surfaces (operated by computer-controlled winches). That's when I discovered this lag. The image was trailing behind the moving surfaces. It was quite strange, because when planes slow down the image eventually caught up. As if something is buffered or wasn't providing data fast enough.
So I spent 2 months investegating this. I blamed this on serial USB dongles (which I used first). Then on Arduino. Now it looks like the problem is elsewhere.
Instead I started to write an algorithm to anticipate the lag and position the frames ahead of time. It's tricky and it's not perfect. I would rather have real-time system, but looks like it's just not possible or really-complicated.
I believe, as I have not done this, that it is easy to control an LED on the RPi (I mean turn on/off in software). It shoud be easy to write a small program to read the UDP packets from the Arduino and turn on the LED as soon as one is received. This would give you an idea of how long it actually takes to process UDP on the RPI. I suspect - but have little evidence that the delay will be the terminal server running on the RPi communicating with the actual terminal display software than is the delay - afterall if you ping an RPi it does no take 40ms to respond (assuming you have a suitable network), nor does ARP take that long.
countrypaul:
I believe, as I have not done this, that it is easy to control an LED on the RPi (I mean turn on/off in software). It shoud be easy to write a small program to read the UDP packets from the Arduino and turn on the LED as soon as one is received. This would give you an idea of how long it actually takes to process UDP on the RPI. I suspect - but have little evidence that the delay will be the terminal server running on the RPi communicating with the actual terminal display software than is the delay - afterall if you ping an RPi it does no take 40ms to respond (assuming you have a suitable network), nor does ARP take that long.
actually I did this test and I know that it takes 3ms for UDP to arrive to RPi.... what takes other 37ms I don't know.... 
I see your point regarding terminal server, but I don't think it should take that long. I also have a app running on Mac (openframeworks/c++) that renders very simple graphics based on UDP value. And this is delayed as well. Go figure...
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.