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.