Welcome to Synthiam!

Program robots using technologies created from industry experts. ARC is our free-to-use robot programming software that makes features like vision recognition, navigation and artificial intelligence easy.

Get Started
Asked — Edited

So Weird : Ezb V4 Ultra Slow / Even On Ap Mode / And Some Really Weird Stuff : I

Just tried to upgrade one of my robots with EZB V4 hopping to get something much faster and also to overcome some serious issues and limitations due to EZB V3 losing Digital ports one after the other.

1) This expensive piece of hardware does something totally unbelievable : it CHANGES MY NETWORK'S GATEWAY to its own client's address... How is it even POSSIBLE ? *confused*

2) Both the EZBs' I got are EXTREMELY SLOW. If I don't disable most of the sensors connected to it, and this EVEN in AP MODE, digital ports will simply take up to 30 seconds to respond. In AP mode N mode it is a little bit faster, but still at a pace that makes running any script useless. I also varied the milisecs for all of them, even at 2 seconds delays I have some little improvement only and no one can seriously hope to use a 2 seconds delay on an IR sensor, right?

I tried from different routers, without routers (AP modes) and the only thing that will make it work properly is turning off almost all sensors (2 ulstrasounds, 3 IRs', 2 currents meters and a lux sensor).

Has anyone met the same 2 problems ? I will try to change the power source, especially the power regulator that I use and see if it does something in terms of transfer rate. For the first SO WEIRD problem, here, I'm stuck... no idea what could do that the EZB takes over the router's address on my network forcing me to set all my computers on fixed ip addesses... . It should not be possible at all.

Thanks for your help,

Sorry to hear that... all my ezb's move data blisteringly fast... way faster than the ezb3.... How new is you pc? Maybe it has a crappy wifi adapter?...Sorry I can't offer any more help than that...
This happens to me if I have tooany adc monitors open and actively watching the ports. When I pause the controllers everything speeds back up. My point is that this control uses so much of the computers resources that it bogs the computer down not the ezb. You may not be useing these adc monitors but something in your project is hogging all the computer's resources or choking up the comunacation network between it and ezb. The best way I've found to manage resources is to make sure that if you have scripts that loop that they have small sleep commands in them. This helps to clear up resources. Kinda like stop signs at a busy intersection.

I don't think it's possible for the ezb to change your network gateway address. That must have happened some other way. *confused*
Similar to Dave's advice, if you are using analog ports (and most of the sensors you listed appear that they do) and not pausing at all between readings this will happen. Even a 50ms pause in your script is enough to give some cycles back to the CPU and keep it humming along fine.

re: the network issue, there is a bug that the Wifi doesn't turn off its DHCP server when you switch to AP mode, so if your router responds slower to DHCP requests than your EZ-B does, the EZ-B will start handing out addresses. The problem is it will hand out the default router correctly, but will give the router IP as the DNS entry, so if your router is set to hand out DNS entries rather than acting as a local DNS server, it can cause devices which boot after the EZ-B behave strangely (and if you are using "static dhcp" they may not get the addresses you expect).

This also causes EZ-B's that boot after the first one to get addresses assigned but he first EZ-B rather than your router, so they may not be the address you expect either, but they will be the lowest available address on your network. (for instance, if your router is, first EZ-B will get whatever address you have assigned, or lowest available. So, say you assigned to the EZ-B, but everthing between and is free, the second EZ-B to boot will be regardless of whether you assigned an address in the router or not.

Those using newer Dlink routers, or the new Verizon FiOS Gateway don't see this issue because the DHCP server in the router reacts faster than the EZ-B. TP-Link routers seem particularly slow to respond to DHCP requests, so experience this all the time, and other cheap routers seem to have the problem. I don't have an exhaustive list of ones that work well and ones that don't.

You can see all the ugly details, including network traces that show what is going on here: http://www.ez-robot.com/Community/Forum/Thread?threadId=7229

I'll be writing up a tutorial for using multiple EZ-Bs on a network, including a few workarounds to this bug soon. Wanted to get it done this week, but I have been under the weather.

DJ has a ticket opened with the WiFi chip vendor, but they have changed owners recently, so I don't know if he has made any progress.

Thanks a lot everybody, really helpful. Alan, it makes sense indeed if the EZB's DHCP is not stopped under client mode. I hope they'll come up with a firmware correction ASAP because this is not really acceptable to pay so much for less performance, as a result, than what I could do with the V3. I should be able to work around that for now, thanks to your advice.

For the latency I'm not sure to know what to do then, beside using less sensors, which are indispensable to detect obstacles located on different levels or even on the side of the robot so it can run in straight lines at safe distance along walls. This worked so far under V3.

My computer is a 6 core with 16gb memory so I don't think it's a computer's performance issue. Network adapter, maybe, but we're talking about top expensive routers here (I have four routers bridged, one is DD-WRT on netgear AC8350).

The check interval for all my sensors is 500 ms. Is there any other way to have ARC to prioritize digital commands over analog readings?

THanks again,
It sounds as if the project could be optimized for wifi communication - which introduces a minor higher latency over bluetooth, even though wifi is higher bandwidth. The higher bandwidth enables more features, such as streaming audio, video and larger packet size for AutoPosition and multi-servo movements from controls. The very uncommon scenario that you are experiencing can easily be resolved with a code/project audit. Normally, the higher latency of wifi over bluetooth during an upgrade migration is very minor and not noticeable unless rare circumstances. Post your project and I will review it for optimization recommendations.

If the question "prioritize digital ports of adc" is asked, then there may be a misunderstanding of how ARC and/or programming works. I won't be able to cover the entire details of computer programming, but i will introduce these two properties...

#1 programs run linear from top to bottom. Each line of your program is executed in a formally fashion - within exception of snippets which are skipped due to GOTOs, IFs, ELSEs, etc.. If the program was meant to read a digital port and analog port, the priority of which one to read can be determined by having one in front of the other. Keep in mind, a program in ARC is each EZ-Script program, which there may be many due to the multi-threaded control model.

#2 ARC uses a multi-threaded control model. There is a tutorial in the learn section regarding controls and what they are. Each control is a behavior for the robot. A camera control is for vision. An Auto Position is for GAIT movements. There are hundreds of controls and plugins using the ARC open architecture. Each control runs in its own thread or process. The communication between controls is done through a channel referred as the ControlCommand(). The ControlCommand() enables controls the ability to "speak" with each other, exposing available features which can be accessed. If two controls are running, each reading a digital port and/or an analog port - the priority of communication activity can be determined by the timing configured to the controls, which run independently. Multi-threading or multi-process means that each control runs separate from each other as isolated programs. Again, the processes/controls can communicate using ControlCommand(). Choosing port priority is based on what timing speed each control is running while communicating with desired ports.

The short answer to summarize the "does ARC prioritize ports" is: Your program decides by which port is read first, and/or which port is read more often, respectively.

As for the DHCP - the manufacturer of the wifi chip used in the EZ-B v4 had communicated with additional detail about the DHCP, which i had not communicated in Alan's thread. The DHCP on the wifi chip is delayed to "wait and see" if there is another dhcp server on the network. This is a feature used for portable networks where there is no dhcp and only a common access-point. Because this wifi chip is optimized for use in robotics, plc, iot and other portable network applications, it is common for these networks to not have dhcp servers. So the wifi IC delays and responds accordingly. Due to the slow processing speed of some older home routers, their dhcp server may respond slower and therefore trigger the dhcp server of the ez-b v4 wifi chip.

This is why ez-robot has been unable to reproduce the experience which alan had introduced in his thread - in both my home and office network. This instance has only arisen less than a handful of times on the forum, and has been resolved with router upgrades.

The DHCP delayed server does not affect communication performance. DHCP is the protocol used to issue IP addresses to devices and computers on a physical layered network. This means a network not separated by routers, such as your home network.

If the DHCP delayed server is responding due to the delayed response of the home network router, report your router model and version here to me with a description of the experience and i will compile a trouble ticket with the vendor for resolution.

Something to note, the wifi ic on the ez-b is being discontinued by the manufacturer, which may mean no further upgrades. Even though there will be plenty of surplus inventory of the wifi chip, ez-robot does not manufacture hardware with discontinued components - so ez-robot is changing the wifi chip for 2016. Due to the modular design of the ez-b v4, the communication board of the ez-b v4 can be swapped out with the new module when it is available - if the issue with delayed dhcp continues to cause issues.

If you want the DHCP completely disabled - and control over the wifi module code directly, you can re-flash the wifi module. All you need is one of these: http://www.ebay.ca/sch/i.html?_from=R40&_sacat=0&_sop=15&_nkw=pickit+3+clone&rt=nc&LH_BIN=1

If you buy one of those, i can create a quick tutorial and give you a new firmware which entirely disables DHCP on the chip. Alan, this applies to you or anyone as well. Unrelated to Alan's dhcp server experience, ez-robot has been thinking about releasing the webserver firmware open-source for customizing web UI and additional custom features. Perhaps this is a good time to do it. Get one of those pickit 3 programmers (the clone ones work great) and i'll get on pushing the wifi code on this website.

Lastly, if you believe the performance is far too unusable - there may be a defect in the manufacturing, which is unlikely but possible. That being said, feel free to Contact Us and send the ez-b v4 directly to our facility in Calgary, Alberta for review and/or repairs/replacement under warranty.:)
It seems that the problem comes from ARC in fact because if I run diagnostic commands from the web interface while all my ADC ports are on, the EZB receives the commands immediately. Now, I tried to run EZB from four different computers and symptoms are exactly the same : as soon as there are more than 3 ADC ports running, latency can go up to 30 seconds, if not more.

There is definitely something at the level of EZB that seems to not be able to exploit network capabilities properly.

I also configured a test project with only ADC ports and one digital D8 button and here it goes : 5 ADC ports on, very long latency time, as of 3 ADC ports running and below, almost no delay. In all cases, again, commands sent from the web interface are always ok.

Has anyone any idea what could cause that in ARC / windows settings maybe? I run under windows 7 ultimate.

There are tens of thousands of ez-b v4's out there:) These experiences are entirely unique and therefore can be resolved. Let's work together to solve the latency issue which you are experiencing. To begin, please submit a diagnostic report: http://www.ez-robot.com/Tutorials/Help.aspx?id=220

Also, please acknowledge that you have read and understand my previous response.
DJ, Great information on the delay function on the WiFi chip. Totally explains the symptoms I have seen (except that it is not a problem with just old or cheap routers. I experience it with a TP-Link Archer C5 and C8, which are very high end modern routers, and the C5 has one dozens of best by awards). However, I will report the issue to TP-Link to see if they can speed up the processing of DHCP requests in their firmware.

I'll probably also take you up on instructions for flashing the chip on my EZ-B's and buy one of those devices since I will probably always be using a router.

Elfege, Post your project to the thread so DJ and a few of us can review to see if there is anything that could be causing your issues with analog port performance. Many of us use all 7 analog ports without issue as long as we are careful not to have no-rest loops.

In the past I have maxed out an ezb4... with multiple analog, digital reads, servos, sabretooth, etc... The only issues I have ever had was tripping the poly fuse from trying to draw too much current from the ezb... I also use a cheap $45 dlink router and still all my ezb4 projects are lightning fast with no connection issues whatsoever.... and my PC pales in comparison to your "Deep Blue 2"....:P
Is your ezb mounted near any metal? My unit was mounted in the head of my all alimony robot. Key word was. I had experienced everything you mentioned including many many disconnects at the most in opportune times. I moved the controller to a plastic plexiglass mount that is mounted to the head now leaving the controller mostly exposed. I still have issues but have just accepted them at this point. Hope this helps.
You are using a lot of ADC ports. I use all of mine and have no slow down. Like I said earlier; Only when I run the ADC monitor will my system slow down to a crawl. You don't need to run the ADC monitor window to use the ports. If you are using an ADC monitor window to view the reading of the ADC port try pausing all of them to see if our problem goes away. there is a little check box at the bottom of the window that says Pauds. Pausing the window does not pause the ADC port or them working.
Sorry Dj i saw your very detailed answer only after I had posted my last message so it may have looked like I was not reading!:) for now I'm busy with other things but I should be able to get back to it this afternoon and send you the report you asked for as well as the project's file. Thanks a lot for he great support! I'll finish reading all the posts as soon as I'm freed form current work (tons of philosophy papers to grade and comment! - my other hobby:) )

Damn ! I don't need to have all the ARC monitors to run to use the command get(adc) ? Is that right? That would indeed solve the prob!
United Kingdom
Not really, no. For example, I only really use the actual ADC control monitors to get values when setting up scripts for sensors. After that, I delete the ADC controls.
@Dj you asked earlier in this thread to communicate the router model(s) I'm unsing, regarding the DHCP bug of EZBV4.

The router which has DHCP server on my network used to be a Linksys E8350 (not really the kind of "cheap router" or "old router" that you and Alan referred to in your posts.

Now I have a brand new Netgear Nighthawk X6 R8000 and STILL THE SAME problem.

Lately, after creating a robotics class, I wanted to order 10 units of EZBV4 but I was asked not to by my School's IT director due to the fact that this issue ALSO HAPPENS ON OUR NETWORKS at school.

EZB is a great product but on that one your manufacturer messed up pretty well. It is not acceptable that such a device takes over our routers the way it does.

Here are the facts :

IF and ONLY IF my DHCP server is on the same subnet and same IP address base (192.168.1.x) THEN no problem. BUT AS SOON AS it is logged on a wifi network that uses a different subnet and/or simply a different address (like 192.168.5.x at work or 192.168.10.x at home) EZB ASSUMES that there's no DHCP server on the network.

Please, try using it on a different subnet, you'll see, the bug is systematic. This is annoying, not counting my wife yelling when she can't get Internet access on her macbook (@Alan knows that I know how to resolve that issue, it's simpler than this dhcp server issue...:):) )

Sorry for the lashing out here... but I've been trying everything for days until I found out today that this is purely due to subnet or address format difference and therefore that there's nothing I can do. I can change my infrastructure at home, but not at work... it's simply and purelly going to be a loss for you. And we are in the center of Manhattan, and a famous school and a lot of people are looking at what we do. You want me to continue using your hardware... really. Sorry to use this stick and carrot here, but this is truly unbelievable that there's still no fix for this.

Thank you for your understanding.
Thank you. I was waiting all this time for this promised tutorial (previously mentioned in this discussion). Didn't know it was out already. Since it uses a hex file it should be doable from arduino. If I figure it out I can post about it. Thanks again and again sorry for the frustration... currently my smartthings is crashed again because of bad dns. which means that it impacts my entire house... lights, heaters, all sorts of smart outlets and power meters.
There is no dns server on the ezb.

The dhcp on the current v4 has an issue with some hardware. The upgraded firmware from the tutorial will fix that: http://synthiam.com/Products/ARC
And of course new ones are shipping with the new firmware and don't have the issue so ordering new ones for the school is not an issue.



I wanted to order 10 units of EZBV4
We are in the center of Manhattan, and a famous school
I have a sufficient budget

EDIT: I just deleted what I wrote. I struggle with people who do business like this. The American educational system and a lot of the pompous people who work in it are an embarrassment to the American taxpayer. *blush*
You're right Dave, that sucked a lot... but be sure that this does not represent the American educational system... I can't give details online but if you look into my fb profile you should find out that this ill frustrated talking was not representative of any US institution.

Since when the new ones don't have this issue any longer ? Because I received two more not so long ago, like a month or two ago and they still have that issue.

@DJ thanks for you kind answer and again, sorry for expressing my frustration this way.
@elfege, Sorry if I came across harsh. Sometimes we say things when we get upset and frustrated. I understand and I'm guilty of the same things many times over. Probably even in this thread. I guess we'er all just human no matter what our ideology is. *blush*

Happy robot building and hope you get your issue resolved. :)
Did you get them direct from EZ, or a reseller who might have had old stock. I think they have been shipping with the new firmware for at least 6 months. The AdventureBot I got in November had the new firmware.

The PIK tool is cheap and the flashing is pretty simple. You can also give them recognizable default SSID's which is useful. Just be sure to give each a unique MAC address and don't just flash the default firmware from the download.

hi all

i just wanted to say ,you are all great and annest people.
and this forum can take the abuse we do sometimes.
one thing i now for sure.i trust people who gets verbal sometimes.
and show there frustrations.ive seen amazing stuff here on forum.
talking about helping people aldo it looks like waisting your time.
when am here on the forum,it feels like comming home.

Have you eventually made this tuto to connect multiple EZBs together? I tried to make one client to a second one without success.

I didn't yet. Work got super busy and I hardly have any free time that I want to spend in front of a computer.

All of my EZ-B'S have now been flashed with the latest WiFi firmware, so even if it works for me it is no guarantee it will work on the old firmware, although really the bug you were seeing was the second EZ-B being a client of the first instead of a client of your router. If just using 2 EZ-B, that should work putting one in ap mode and the other as a client to the first. Adding a 3rd in client mode without flashing the WiFi chip could see the same issue.

I have been off these projects for a while so please excuse. Basically what is said here is that we must upgrade the firmware by buying the kit, not directly like V3. I tried on network and access point and both there is too much lag time. Different PC also. No good on the speed.
Depends what version of the ez-b v4 you have.
Tried using interface says unable I guess this early version. I am really have a lag between pc and V4. Run same program on V3 works great. same equipment. Could the problem be the Hbridge?
1) The problem is generally 99% user code - meaning, what are you doing with it? Share the project for someone to take a look at

2) Also, how are connecting to the wifi? Is it direct adhoc or client mode through router

3) lastly, you can check what version of wifi you have. There's a the robot program episode that shows or you can READ the ez-b v4 upgrade page here: http://www.ez-robot.com/Shop/AccessoriesDetails.aspx?prevCat=101&productNumber=51
My code is up on your site called Vetrobot. Tries connecting both modes. Using Win 10 on 2 different machines. latest version of your software. Lag time is between 2- 10 seconds. My laptop which runs nothing else and was ok with V3. I do not believe it is the code. Tried with and without script also. Tried with and without joystick either.