Reconnection issues

[turnn]

Hey guys, two developers here working on a little project, we're more than happy to spend a bit of time to get the library working and make a pull request but it'd be great if you could perhaps point us in the right direction cause we've already spent a few hours debugging this.
Significant issues with the dropout happening, I've printed out the responses from the DAC attached
The issue is the constant disconnection on Invalid response, which I'm sure you were once aware of as it is commented in the code as a known issue.
The reconnection forced by EtherConn.js sendPoints() function upon receiving an invalid response isn't reliable, as it just drops out again
You'll notice the invalid response to the data stream, I can't really see any fault in the data stream itself, it is interesting it is always proceeded by a ping request? I'll probably try remove the ping request next...
ResponseLog.txt

[SpaceK33z]

Hey, we actually had the exact same issue and unfortunately we also didn't find a fix yet. I've not been working on it for a long time so at the moment I don't have any more info unfortunately. If you do get a workaround we'll gladly merge a PR.

[sebleedelisle]

Hi there, I hope you don't mind me jumping in but I have some experience coding the Etherdream protocol (see github.com/sebleedelisle/ofxLaser ) so perhaps I can help?

The reason the Etherdream returned the invalid 'I' response is because it ran out of points and switched off output (the playback flags underflow bit is set). This is likely due to intermittent latency in the network (or dropped packets etc), and is expected behaviour (and actually probably desirable for safety reasons).

The way to get around it is to :

• check that the playback_state is PLAY_BACK_IDLE and the light_engine_state is LIGHT_ENGINE_READY (if the light_engine_state is in ESTOP you'll also need to send the clear command)
• resend the "prepare" command ('p');
• start sending points again
• send the "begin" command ('b')

You shouldn't need to reconnect the TCP connection at all.

I hope this helps, you can see my c++ code for doing this in the ofxLaser codebase. I've rewritten the etherdream c library from scratch so I feel like I know it quite well now.

Let me know if I can help any other way.

Seb

[SpaceK33z]

@sebleedelisle thanks so much, that is really insightful! When we were making Modulaser we were debugging this issue for weeks. I don't have time myself to fix & test this soon (we're very busy on a sprint to launch a new app).

If either of you want to fix this & send a PR I can offer a free Modulaser license in return as a thanks.

[turnn]

Awesome! Thanks for the detailed reply @sebleedelisle , @SpaceK33z we'll give the recommendations a try but it might be a couple weeks as this is just a side project for us

[turnn]

Hey guys, I spent a couple days on it and it's still not stable, I believe the problem is that the library only sends enough points to fill the DAC's buffer. I may be incorrect but I think @sebleedelisle 's library works by sending points at the point rate, instead of trying to fill the buffer. I tried to do this and it was significantly better but still quite unstable i.e. 10 underflows a minute instead of an underflow every second. We'll probably try ofxlaser next, but may be back as we did want a JS library.

[sebleedelisle]

Ah a few things to unpick here... if you're constantly getting buffer under-runs either your code isn't getting updated enough or your network isn't fast enough to accommodate the traffic.

A few things to check...

• I assume you're not running over wifi?
• Have you tried reducing the point rate? I find a sweet spot is around 30000 pps
• Have you checked how often the comms code is running? In my library I'm running it on a different thread which makes it somewhat easier. I'm constantly pinging the etherdream so I always have an up to date report on the buffer fullness. I'm not sure how much control you have over the timing of this kind of thing in node.js.

If I was you I would try filling up the buffer every time you send points, the timing should be more forgiving that way. I don't really understand why you're getting more errors when you try filling up the buffer, unless you're over-filling it? Have you checked the buffer size? You should get that back from the etherdream in the broadcast packets. (Note that etherdream 1 and 2 have different buffer sizes).

So a few things for you to check, good luck!

Seb

[dinther]

Hey guys, You're all miles ahead of me with the knowledge you have build up around the lasercube network protocol. I only just received my lasercube pro but immediately I noticed its pretty heavy handed on my network. I had converted some simple video animations into an svg sequence and via wifi things didn't run too smoothly.

Am I correct in my understanding that the app is constantly resending the same points over and over for a static image?
I had assumed communication at application level would have been higher level with the cube capable to keep state.