I'll go take a look! Be right back!

Nothing is theory when it comes to logic. The data channel is indeed flooding, which is causing something interesting to happen. On my slower PC, the data is slower with connection debugging running, with different experience on my faster PC.

It appears the faster PC's are shoveling data too quickly at the ez-b v4 and she's having trouble keeping up, by flooding the data channel. It seems that the slight delay of the connection diagnostic tool is giving the ez-b v4 a chance to catch up.

Perhaps the solution is if i add a tweak-able delay parameter. Let me debug a bit more this evening and see what i come up with.

Stay tuned!

@DJ, remember I'm not down. Everything works fine. Happy holidays

Give this build a shot: https://synthiam.com/Community/Questions/8766

I'm not fully sure how to handle this scenario with the new Comm being released next month... Because this setting dramatically decreased performance capabilities of the ez-b v4.1/2, when people start to get it.

I'll think of something in the meantime - let me know how this works for you. What ever you do, don't run the Connection Diagnostic plugin with this setting - or the performance will be severely affected. Start with a value of 1 and run the benchmark. On my fastest PC, the value of 1 seems to great.

On my main PC the value 8 works the best.... At an 8 micro second delay the Benchmark for analog reads shoots way up from 5 reads/second (0 microsecond delay) to 70 reads/second at 8 mirco second delay

I wonder if anyone looks at the graphs. I mean really look at the graphs. Because if you take a minute and look at them you could see that they, run then pause, run then pause, run then pause. You could say, well that's because of this or that etc. etc. etc. But I'm not buying it, I won't even rent it. Because I never had any analog input read issues with the v3 board over bluetooth. I still have a v3 board but that has the issues too, I say it's a problem in the code. I wish I would have saved older versions of ARC. Then I could go back to a working version. I would like to say it is usable but annoying to have graphs pausing, but I am starting to think that maybe the ez software has become too complex to be fixed.

The graphs will pause while waiting for network communication if there are wifi issues. I experience no pausing, except for the 100ms delay between requests.

Perhaps you can benefit from changing the ezb v4 wifi channel? Run a wifi scan to see what channels are free in your area?

Also, how is the ezb connected in the robot? Is it shielded by any metals? How far are you from the router or laptop? Are you connecting adhoc or client mode?

There are plenty of wifi related questions - because that is how wifi works and it does have its own inherit delays which are out of ezrobot's domain.

The ezb v4 now has the option to throttle delays to prevent flooding to increase throughput. Can you verify the benchmark utility has increased throughout?

@DJ - explain how the same problem appears on my v3 bluetooth connection.