#1. Upgrade from Windows 8.1 to Windows 10. Seriously, Windows 8.1 is a pig.

May not solve the problem, but won't hurt and would be the first step I take.

Other issue could be WiFi interference. If you are using Client mode, set your router to a different channel (I am at work without an EZ-B. Not sure if you can change the channel in AP mode).

If you have an Android device, WiFi Analyzer app can tell you what the best channel for your location is. There are probably similar programs available for Windows, I have just never looked for them.

Alan

@guru - The second computer has windows 7, same problem. I don't use a router.

When I get home I'll check if you can change wifi channel in AP mode. Might help.

When doing the benchmark test, do you have a project running that is using sensors, or is it a blank project with just a connection?

Several of us have seen performance problems when an analog sensor was flooding the system because of not enough pause between reads. You indicated you had a 100ms pause, which should be sufficient, but perhaps you have something reading more frequently than you think.

If you want to post your project (or if you put it on the cloud as public, just give the name) I would be happy to review it, and if I have enough or the right parts, see if I can duplicate the issue.

Alan

@guru - I have nothing running, board with no inputs or with inputs doesn't matter. Only thing I have added is the benchmark control window, nothing else. Thanks

I am getting 73+ reads/commands a second using the same ADC test you tried... And this is within one of my projects that is also doing some stuff in the background to boot... FYI I did the test in client mode...

@ Richard, I remember when I first got my V4 board it had about 65 to 70 adc reads per second.

The reads per second will vary based on the network adapter and any network services specific to the adapter. For example, on my computer there is a silly Intel(R) PROSet/Wireless Event Log and a few others with similar name. When they are running, my performance is low.

Hi DJ, Thanks for commenting. I am using this benchmark as a indicator of the problems I am having. I don't know how else to describe the issue. Its like there is a clogged up communication link between the pc and the EZb. For example when I use a graph it keeps randomly pausing every second or so, like the pc is struggling to communicate with the board. Is there another way to test/troubleshoot this? Thanks

Outside of viewing the TCP communication with a sniffer, no.

You can post the project and we can take a look - to see if there's any performance suggestions.

Also, do you have any of those services/tasks running? I stop mine using the TAsk Manager in Windows.

I have nothing running. Only the benchmark control.

Also, on Windows 7 and above, from within task manager you can open resource monitor and look for things like spikes in cpu, disk i/o and network utilization that coorespond with the alowdowns, and from there see what processes are sucking up the resources.

Alan

Thanks Guru, I'll check that tonight.

The things i asked if are running are in the task manager, that alan mentioned. The Intel (R) Wireless XXXXXX and etc wireless services are in the task manager, not ARC.

I looked in task manager and didn't see anything that would lead me to believe that it is using resources. I do not have a project running I only use the Benchmark control as a benchmark, I don't know how else to say that everything is running slow. My system used to get 65 reads per seconds, now I get 5 per second. I have tried different 2 computers, different boards 1 v3 and 2 v4s. What could this be? The symptom is graphs that keep pausing.

Have you loaded yesterday's release of ARC? DJ made a bunch of performance improvements (although I am not sure if any of them effect ADC).

Alan

Yes, I have the latest ARC installed. There was no difference between the older versions and this new one.

I recommend revisiting my previous posts in this thread. Those services will not give a sign of high utilization - they merely slow the network communication.

Also, for highest performance you can limit the EZ-B's cpu by disconnecting the camera and limiting the amount of audio playback.

First, I consider myself a Non-Programmer. I do not have a camera connected and I am not using audio. I have no scripts running. I can see the graph pausing with only one adc graph running, with nothing else connected. I went into task manager and saw ARC running and a couple of other things running at a fraction of a percent. To me I did not see anything that would indicate to me that the computer was slowing things down, but then again I really do not know what I am looking for. I see this issue accross two different computers too. If I go to task manager what do I do? Should I just turn off everything running except ARC?

See my post #12. Run Resource Monitor, not just task manager, and look for spikes in disk I/O or network use that happen at the same time as the graphs freezing, then see what processes are responsible for those spikes. resource manger gives much more detailed information than task manager that just shows cpu and memory, but not disk or network use. (resource manager is a button on the "performance" tab of task manager".

If your graphs as freezing, then something is interfering. If it is happening on multiple devices on multiple computers, probably something on your network.

Are you using AP or Client mode on the EZ-B v4/computer? Might want to try AP mode to remove anything else on your network as a possible cause. (or when testing with the V3, turn off WiFi completely)

Alan

Thanks Alan, I will try these things tonight.

Did this start happening when you put up your Christmas tree or changed something in your house? I ask because I would guess that it has something to do with network interference. You may try rebooting your wifi access point or router.

I do not use a router or any of that stuff. I just have my computer connecting to the ez boards, trying to keep things simple. I do not have routers or cable for internet, I get to the internet through my cell phone.

I assume that your robot is close to your computer and still having the same issues.

Can you save your project to the cloud and try a app from your phone to run it? This will eliminate the computer as being an issue. If it is still slow, we will have a better idea that it isnt the PC causing the issue. Wifi cards in computers can go bad and they often display really weird issues just prior to failure.

There is no project to put on the cloud.

The thing you are using is a project. It is an ARC project. Publish it to the ez-robot cloud and then open it from your phone and connect to your robot. See if it is still reporting only 5 refreshes per second.

Try without the camera connected and see what you get.

Also, sometimes the benchmark can flood the data channel on that board and disconnect. Is it disconnecting?

@ purple . This is may sound like a dump question, have you power cycled both computer and EZB board.

Also might want to check you wifi properties to make sure the auto power saver is disabled.

First, thank you all for trying to help me. Here is something that I think may help, if I run the Benchmark and read 300 adc values I get 3 to 5 per second. I can change that to 23 to 30 per second if I run the Connection Diagnostic plugin at the same time. Then when I close the Connection diagnostic plugin, I am right back to 3 to 5 per second, max. Then if I open and run the connection diagnostic, at the same time, I get 23 to 30 per second again. I can go back and forth. I do not have anything connected to the ez-b. No cameras, no audio, just a bare board, nothing. I have looked at the resource graphs in task manager and do not see anything that shows resources being used. Nothing looks out of the ordinary. This also does this with different ez-bs and different computers and at different locations. The only thing that I keep thinking is the 'Limited' indication on the wifi connection to the ez-b, but I have been told that that is just there because I am not connected to the internet.

Sounds like you have a fast computer and the benchmark test is flooding the data channel because it's a high priority loop. Looks like the performance concerns are due to overly fast cpu and inconsistent results from the benchmark test. So your cpu is faster than the network capabilities I guess could also be a driver thing

DJ, I think your right. I have one more odd thing that I noticed, when I do the set 300 digital port to true, the ez-b goes crazy. It makes the sound of power up, but ARC shows it still connected. Ok how do I put the brakes on this?

You don't use the benchmark :)

If I have any adc monitors running my computer slows down to a crawl. If I have more than 4 running the robot responds in fits jitters and will freeze up. I have to pause all monitors and restart ARC to get things working smoothly again. The most I can ever run at one time is 1 adc monitor.

Ah, well you can all upgrade to the new comm board next month :). It's a much faster cpu and faster throughput, nearly 100 adc reads per second while playing audio and video.

OK, something is going on here... A few days ago Windows 10 went through a major update to I guess a new version of Windows 10... I have Cortana now... Anyway now I am experiencing what @Purple is experiencing... I am now only getting about 4 adc reads a second.... In fact my whole computer has be relatively "sluggish" in general since the upgrade.... I takes much longer for most programs to open and even ARC now takes a few minutes to install new versions as opposed to 30 seconds as it used to... Anyway this has been over a period of several days since the major upgrade of windows 10... Remember, I already had Windows 10 installed before it upgraded again a few days ago... No amount of rebooting has helped... I still only get about 4 adc reads/second when a week ago (before the update) I was getting 70 plus...

Ok, it doesn't seem have anything to do with Windows as I have tried this on 3 versions of Windows, 2 different versions of ARC and 2 different ezb4s... @Purple, I am seeing exactly what you're seeing... Can anyone else so some benchmark tests and see what you are getting for adc reads per second?

8.78 here for analog reads. 11.21 for digital reads.

I am going to try a much slower computer with the latest version of ARC.

@David... Is that reads per second? I am getting between 4 and 5 reads/second on both digital and adc... A week ago I was getting 70 plus reads adc/second

atom processors on 2 GB RAM wifi connection to the router got 9.67 commands per sec on analog reads 10.32 commands per second on digital reads

The first attempt was from an I7 with 32 GB ram and raided SSD's through a wired gigabit connection to the router. 8.78 commands per second for analog reads. 11.21 commands per second for digital reads.

Both of these were with version 2015.12.16.00 of ARC

Both of these were to the same EZ-B which was purchased a couple of months ago. The board has only the I2C 4 in 1 sensor attached.

The v4 reports the following version information EZ-WiFi v0.3 I dont know if you track by MAC address or not to identify individual EZ-B's but this is the id for this one - 00078033D45E

I still have a Windows 7 machine, and I think one of my Windows 10 machines hasn't run the update yet (I haven't booted it in a couple of weeks) so I will run some comparisons tonight or tomorrow morning to see if there is a significant difference.

I only have one analog sensor, so I can't duplicate Dave S experience of slowdiwns with multiple analog devices.

Alan

Ok, interesting.... Last week (like @Purple) I was getting 70+ adc reads.... now on 3 different versions of Windows, 2 different versions of ARC and 2 different ezbs I only get 4 or 5 reads/second now...

@alan... I had nothing but the benchmark control and nothing plugged into the ezb when I did the tests now and last week.... Hmmm

Mine is un-populated with no analog or digital sensors attached. Really, you shouldn't need one I wouldn't think. An analog port would just report back the resistance at the board. The digital would just report back 0 or low.

Mine is a new project from the just downloaded and installed ARC on both computers. I had never used this tool before so I have no way of knowing what it was or would have been before. Only thing in the project is the benchmark tool for both computers.

This benchmark test is a tool that I use as a benchmark. It corrolates to other problems that have been ongoing, such as computer lockups at the same instant the connection chime is playing. This has been plaguing my ez b world for quite some time now. It's been getting worse to the point where the ez bs are unusable. I went back to my ezb v3 boards which have the same issue but not quite as bad as the ezb v4. I'm sure ezrobot will have a solution. Thanks

purple, ensure you are running the latest ARC - which has substantial stability improvements.

Additionally, the benchmark will flood the data channel.

If you have a project that crashes and isn't working - share it with me and i will take a look.

I understand the purpose of the tool, just haven't had a need to use it. I have never had an issue with analog or digital read/writes per second to this point. That isn't to say that I won't. I have had issues with serial communications but have found another way around the issue by connecting directly to the computer over USB for these functions. Other devices handle the analog and digital sensors that I am using right now. That isn't to say that the V4 won't eventually be populated with digital and analog sensors at some point by someone, so this is a concern to a certain extent. My hope is that the new board will offer a USB connection to the V4 which would probably eliminate this issue for me. All of my robots have gone to onboard computers, so this fits my purposes well.

The key here is that multiple people seem to be experiencing issues with this tool for some reason. It could be reporting back bad information. It could be a threading issue. It could be that there is something else going on that none of us are qualified to answer. I think that providing EZ-Robot and DJ as much information about our particular situations is probably the best way to help him provide a solution. I think that the best information that can be provided is

What is your network topology? - 1) Wired gigabit to Access point 2) wifi to Access Point Are you seeing the same readings in AP vs Client mode? I haven't tried AP mode yet. When did you purchase your V4? 2 months ago What are the specs on your computer? 1) I7, 32 GB RAM, Raided SSD's 2)atom with 2 GB ram and single SSD What OS are you running? 1)Windows 10 2)Windows 10 What version of ARC are you running?1) 2015.12.16.00 2)2015.12.16 What does your project consist of? 1)just the benchmark tool 2)just the benchmark tool If you know previous readings, what were they? I dont know on either What are your readings now? 1) 8.78 commands per second for analog reads. 11.21 commands per second for digital reads. 2) 9.67 commands per sec on analog reads 10.32 commands per second on digital reads Have there been any environmental changes? Chistmas tree with lights has been put up next to my desk What voltage is the V4 running off of? 5V

What I have seen on the forum is a vague question without enough information to answer the question or diagnose the issue. It is very important (speaking as one who troubleshoots technical issues for a living) to have the information necessary to solve the issue. Most don't have time to dig the information out from the user base and assume that the issue must be something local to that user until others complain.

DJ, this is the entire project with the results that I am seeing.

This is mine....

I can't continue to repeat myself The bench mark utility will flood the communication channel of the EZ-B v4 - it has been stated since we released the v4, this is due to limited processing capabilities on the v4.

But as usual, we have advancements. Next month we start shipping the EZ-B v4.1/2 Comm replacement board that runs at twice the processing speed and twice the DMA memory for handing much higher bandwidth.

Here's the test i just did for you on the EZ-B v4.1/2 to demonstrate. Keep in mind that these results from the video are through my router, and not direct ad-hoc. Expect more consistent and increased throughput with ad-hoc. They're still very impressive numbers...

@DJ... we understand what you are saying, .... but the fact remains is that last week (post #6) I was getting 70+ adc reads a second and now a week later I am getting 4 or 5.... I am trying to figure out why the drop...

To continue Richard R's thought, the basis of this thread is not that benchmark isn't working, but that graphs using ADC are freezing in @Purple's project. Which of course, leads back to two previous suggestions, 1) Purple, post the project where the graphs are having issues so we can look at it (and tell us what analog devices you are reading from), and 2) look at Resource manager while hte project is running to see if there are other activities occurring at the time you see freeze ups.

Saying not to use hte benchmark tool, while valuable advice if the tool is not useful, does nothing towards helping Purple solve the initial complaint.

Alan

To clarify my statement. I experience the slowdown when I have more than one of adc monitors installed and activity monitoring ports. This would support what DJ is saying about flooding the comm chanel.

I guess the solution is to remove the benchmark control or lower the default sample set from 300 to a smaller number. At least until the EZ-B v4.1/2 is shipping. The latest ARC release has incredible performance increases in the communication layer which runs the benchmark utility at around 500% faster - this was noted in the release notes.

The performance increases of the benchmark utility, which seems to be popular screenshot posts in this thread, are flooding the data channel on the ez-b v4. As you are all aware, flooding the wifi channel of any device will result in disconnects or unstable behavior.

To be clear. The benchmark utility was updated to increase performance for pushing the ez-b v4.1/2 next month. The new benchmark utility now floods the data channel on the ez-b v4 using the default value of 300 samples.

If tests state that you experienced higher number of reads on the old benchmark utility, that is because there was a slower delay between commands - which didn't flood the data channel on previous releases of ARC in benchmark utility, specifically.

To be more specific, and explain the inner workings of communication might help. There are many layers of communication between the EZ-B chip itself, and your computer, from high level to low level...

1. the benchmark utility was rewritten with the new threading model which has a huge increase in performance and stability. this same threading model is used in the scripting engine, camera, audio, and auto position. All the controls, except benchmark, have threading delays between commands, for obvious reasons related to their operation. For example, an Auto Position does not transmit all of the servo position frames in milliseconds at once, because your robot servos wouldn't respond that quickly - that would be silly. Therefore, all controls using the new threading model still have inherit delays in their communication that reflects the operation. The fact is, the new threading model increases accuracy, increases performance and increases stability. However, on the new benchmark utility, that's where the control literally sends as many commands as possible to the ez-b, which floods the communication channel more than the ez-b v4 can keep up, as I have repeated throughout this thread.

2. there's the application layer within ARC, that was rewritten with dramatic increased performance. The application layer is where the controls pass their commands to be relayed to the ez-b over wifi. It uses sockets and stuff to buffer and prioritize the commands, etc.. Well, that was rewritten for increased performance of the new ez-b v4.1/2 comm board.

3. the wifi communication part is handled by the operating system, router, etc.. not ez-robot's domain.

4. the Comm board on the EZ-B v4 is the top pcb. It has the microchip pic which runs at 80mhz and the tcp stack. It has enough memory to handle a certain number of commands and requests in it's buffer. How this works is quite complicated, so i will try to explain. There are numerous DMA features on the processor. The communication to each peripheral has a DMA with a ring buffer. The wifi module itself is connected by the SPI and the EZ-B v4 bottom board is connected by UART with RTS/CTS flow control. This module can only buffer so many commands before it overflows. Unlike the ez-b v3, which uses bluetooth and the OS handles large buffers, the v4 has suffered from communication channel flooding since day one. Inefficient programming that results in flooding the communication channel will be more evident with performance improvements of recent ARC releases.

5. finally, there's the EZ-B v4 itself, which is the bottom board, as referenced in the previous point. This board has a massive DMA buffer because it's a more powerful chip. In fact, the new EZB v4.1/2 Comm board uses a similar CPU as the bottom board. Which is why it the new EZ-B v4.1/2 has dramatic performance and stability improvements over it's little brother.

QED: the only way you can expose the communication performance limitations of the ez-b v4 is by...

1. looping get* commands without delays in scripts

2. layering too many ADC read commands erroneously. There are only 8 ADC ports, which means efficient programming should only be calling 8 getadc commands.

3. using the benchmark utility with high numbers (i.e. 300). Try with a reasonable number of 20 or 30 in the benchmark

To be clear - none of the performance increases outside of the Benchmark Utility will flood communication channel unless incorrect programming structure is used - which is nothing knew to the ez-b or any wifi device.

Thanks DJ. I understand now why there was a change and how the change impacted us. Just to be clear, we were just trying to identify the issue, which you clearly have done. It isn't an issue so much as an effect caused by improving technology.

I wonder if a possible solution to the software would be to have a benchmark tool for the V4 and another one for the future 4 1/2. It might help to clear some of the confusion. Obviously it is your call. I just am offering a suggestion.

I did run wireshark to see what was happening. If you would like the export from that, I can provide, but it looks like you're already aware of what is going on.

I look forward to the 4 1/2 for sure and will be picking one up as soon as it shows up in the store. Thanks for the explanation.

David

Once again, The problem is NOT the benchmark test. It is just a way that I can show the problem of slow performance in acquiring analog data. Limiting the benchmark test will not fix this.

Something else to note... years ago when ARC was young, there was a caching model built into the communication layer. The caching model would throttle commands to prevent the ez-b v3 bluetooth from being saturated. After some time, people had noticed the cached responses. Meaning, if you queried the adc 5 times within the cache timeout, you would always get the same response until the cache timed out.

While this did provide some stability on the old ARC, which was not nearly as awesome in communication as it is now, had down falls of inaccurate responses.

The census was to remove the caching model and provide real-time data queries. This wasn't a difficult solution, because after all, the whole point to ez-robot is to teach you how to program. If ARC was to allow for inefficient programming, it would be doing a better job of band-aiding than being a learning tool.

As technology does improve and become accessible to us, we can keep up with it. Such as the new EZ-B v4.1/2 Comm upgrade, which turns your ez-b v4 into a power house of stability and performance and will most likely provide the communication needs for your project.

Purple, i am unable to help you if the bench mark is continued to be discussed. Please provide a project demonstrating the issues that you are experiencing so we can help identify what is happening, or if it's even possible to be resolved with your hardware, software configuration and program.

@purple,

So basically, the benchmark tool is not a good way to measure performance right now. If you are seeing issues with performance, upload your project that you are seeing issues with so that someone can then review the project or test the project in their environment. This will allow someone to offer some suggestions on what can be done to increase performance on this project or help to identify a possible issue by allowing others to see what you are seeing.

It is now a good way to measure performance with the latest release. The default value has been lowered to a more realistic value from 300 to 30, which should not flood the data channel - unless there are a bunch of other controls running in the background. Release notes here: https://synthiam.com/Community/Questions/8758

Now, let's get back on topic and identify what purple's project is doing that is causing his computer to lock up and freeze due to apparent communication issues.

I agree totally DJ. The project has been requested multiple times from multiple people. Without it, there is nothing more that can be done.

@DJ.... thanks for the clarification, I also get what's going on now.... To be honest, I was also focused on the benchmark control. Like David, I actually haven't seen any degradation in performance in my projects... And my Windows 10 upgrade build (with sluggish computer) was just a coincidence.... I think we are all looking forward to the release of the ezb4 1/2 ....

Any time :). I never saw the danger of leaving a high number in the default sample field of the benchmark utility. It's funny because since the release of the ez-b v4 last year, we internally use the benchmark utility with a default count of 300 to see how long it takes before it crashes, because it mostly does. I've only seen less than a handful of ez-b v4's not crash with the default 300 benchmark sample test.

If we put a default number in there, it's a recommended value - something i should not have over looked. The latest release lowers the number to a realistic value.

We'll get purple's project posted up here shortly and give it a good overhaul and get him back on his feet :)

I have always used the benchmark as a Benchmark! It has never crashed and has always been a good indicator of system speed. This used to run at 65 to 70 adc executions per second. On both v3 and v4 boards. Something has changed. I will put together a project to show you, but it will take some time. And I am sure that it will be met with the same hostility that every issue I have pointed out has been met with, even after it was discovered that there really was a problem. Every time someone on this forum points out a issue , it is always responded to with 'Lets figure out what You are doing wrong'. Everytime.

@Purple, Something has changed as DJ has stated. Others dont see the issue that you are seeing from an actual project perspective. DJ has stated that the Benchmark tool, with the changes to ARC for the new products that are coming out doesn't pause between attempts to access the Analog ports (or really any others) anymore. This is because the new product can handle faster speeds. This will flood your connection and cause issues with the current product. Because of this, what you used to do to gage performance won't work well with this board at this time. The benchmark tool is not a normal function, and thus is irrelevant to your project. If your project is showing slowness, and nobody else is having an issue with slowness, then logically speaking, your project probably has an issue. If you post it and everything looks good with it, then someone will be able to say "yea, I am having the same issue here" or "Nope, no issue here". That will help to determine where the issue is.

I dont think that anyone is saying "Lets figure out what you are doing wrong". I think that people are saying, "Unless I see what you are doing, I cant really help out". Everyone here has tried to be as helpful as possible, but until we can see what you are seeing, it is really hard to help. As stated, the Benchmark tool isnt a good method of determining what is happening because with the improvements in performance on the ARC software that have been put in place (this is a good thing), the bottleneck is now somewhere else in the chain of things that happen to make the robot work. You can see the bottleneck with the Benchmark tool, but that doesn't mean that in a real world scenario this should exist.

If you have seen this issue in the past (which nobody is doubting) then you should have an existing project that demonstrated this issue in a real world scenario. I think everyone wants to see that so that it can be determined where the issue is.

Not at all @purple - there are 263 ARC software releases with fixes inspired from user experience. Your experience has inspired an update today, as well.

The process to identify an issue starts with reviewing the project. Without a project to review, there is no information for me to see what scenario is causing the experience. Once you provide a project that crashes or locks up, it will be easy for me to fix :)

In this thread, we have identified that the performance enhancements of the benchmark utility flood the communication channel at a high sample count. This has resulted in an ARC update.

Take your time with an Example Project that demonstrates the software lockup - when you come across it, let me know, i'm always here to help.

I have just put up a project to the cloud. It is called 20151219 pausing test. Just notice the changes with and without the Connection Diagnostics running. This is on a bare board.

awesome, thanks!

First, that project has the debug control added, which is incredibly resource hungry and debugs every command sent to and from the ez-b in the gui thread. The plugin should not be used for testing - as it's a connection plugin only, hence the title. The title and description of that plugin in no way leads itself to be used for performance testing. Please do not use the connection plugin when not being used to debug connection failures. Due to this incorrect use of the connection debug plugin, i will update the description so others do not confuse the name of the plugin with a reason to use it for any other purpose.

Here you go - here's the fix for your example project. I added educational notes in the project. Hopefully this will contribute to your programming learning experience :)

Your new file: PurpleFixed.EZB

Let me know if you have additional questions.

Updated the connection diagnostic plugin with a description that includes the warning about why not to use it. Even though it's name and description does imply what it is - let me know if there are other plugins which may cause confusion and be used incorrectly as well. Thanks! :)

Here's a video demonstrating to avoid confusion of how the Pause On and Pause Off work... Let me know if you have any questions!

@DJ You are the one that is confused.

What else can i do for you? Let me know and we'll get you up and running! :)

Go back and run my project. Take note of the update speed of the graphs. Then remove the Connection Diagnostic, now note the speed of the graphs again. Now put the Connection Diagnostics back in and look at the update speed of the graphs. I am using the Connection Diagnostics to show that with it added to the project the update speed increases by 5 times. This corrolates to the read 300 adcs. This also contradicts your flooding the communication link theory.

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.

Bluetooth is also a wireless signal. Both communication methods use rf (radio frequency) to communicate.

If the issue that you are experiencing is a short occasional pause while reading data, then consider checking for wifi interference as mentioned and how the controller is mounted in the robot.

Also consider applications running on the PC which may affect performance.

Only one command can be sent at a time over a single connection - which is how the ezb works. It's faster that way, than opening a new connection for each request. Sharing the connection requires less back and forth conversation and resources in the form of sockets on each endpoint.

As all controls and commands are sharing the connection, they stand in line waiting for the next response. So, you can imagine what happens when one request is delayed, the rest in the queue have to wait their turn.

Anything else I can help you with?

No I'm all set.

Excellent!