Can you share your project? The latency on the new firmware isn't axtually higher and more reliable. You will experience fewer disconnects. Id like to see what your project looks like to see if it can be optimized.

Thanks DJ, I'm starting to believe it's not the firmware in the controller. I would like you to take a look at my program, it's like something has slowed it down. I'll put something together. Thanks

Certainly! If you can post the project, i'll take a look at it for you

Some things to watch out for are how many scripts or controls that "ask" the controller for information - that takes the longest time in the communication protocol. For example, if you're using Ping sensors - limit yourself to one ping sensor control. Same applies with SHARP IR sensors, limit yourself to one.

@DJ - When you say "limit yourself to one" for the PING and SHARP IR do you mean one at a time or one connected to the EZb, period? What's your opinion on running one radar ping sonar sensor on a panning servo and using another ping sensor for distance in say a hand?

@JustinRatliff I have had 4 pings and 2 Sharp Ir detectors (obviously all on different pins) going all at once in a script loop... It worked without issue and that was before the current controller update...

I think DJ is talking about controls rather than scripts. If you have say 4 ping controls and 2 IR controls open and set to update every 100ms then you are basically checking for data 60 times a second (100ms = 10 checks per second, 6 sensors * 10 times per second = 60 checks per second) which would be a huge demand on the EZ-B comms.

With scripts I worked mine out based on the benchmark results I got (use the benchmark control). Worked out how many sensors I had, how many times the EZ-B could read data in a second and used Sleep commands to limit the amount of data being demanded leaving a 20% buffer available for anything else that may be needed. I've not had an issue doing it this way and the sensors update quickly enough to avoid any major accidents.

@Rich... Yes, I was using scripts... I added a delay at the end of the loop sleep(25)... the pings were arranged in an array across the front of the robot... covering about 150 degrees or so of the frontal area... the 2 IR detectors were down near the wheels (down low) to pick up any low lying objects that the robot would not be unable to drive over... Like a pet food/water bowl... Anyway... It seemed to work and voice control was able to halt the robot as needed... I am still a novice at ARC so I hope to refine as I go... thanks for the input...

DJ, I just put my project up for your review. I just got my second V3 board. It nice having two ez bs, because you can rule out things when trouble shooting. So I don't think my issue lies in the v3 board or the firmware anymore. Please review my program when you have time. Thank you, John