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 :D

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

DJ, Now looking like I have a wiring issue. confused

Wiring issues are frustrating but fixable. You need trace each wire out to see if it's connected as expected. Try to remember what you changes sense the last time it worked correctly. You may need to bet a multi meter with a continuity tester built in and make all wires are intact. This tester will also help with tracing wires and finding shorts. You may have two wires connected together that should not be or one connected to a ground. Also make sure all your connections are tight and true. Most problems come from bad connections or wires connected to the wrong place. Take it slow and start at the beginning (usefully where the power comes in). Good luck and keep us posted.

Thanks Dave, I went through all wiring. I solder all connections and make schematics as I go. My motors (dc motors) are on the digital outputs, and are driving the gates of transistors (igbt). What happens is at power up, before I get the ezb connected, some motors will just start on their own. This is very random and I think the problem might be that I do not have any pull down resistors on the gate of the transistors. I believe they are self turning on.