@MathProf.

The EZ-B can only connect over WiFi, and you cannot connect directly from a PC.

In regards to how many can you connect, each EZ-B has its own IP address. So if you connected via AP mode (computer to EZ-B directly) with each EZ-B having its own dedicated PC running ARC, then the amount you can connect potentially limitless.

If connecting via "Client Mode" (EZ-B to PC via router), again the number would be high but I think it would depend on how many simultaneous connections the router could handle at any one time.

And you can connect up to 255 EZ-B's to a single instance of ARC from one computer.

Hope that helps.

Steve, very, very helpful. Thanks!

Your very welcome.

If your PC's can each have a wired (or wireless) LAN connection (for local network and internet) and a separate wireless connection to talk to its own EZ-B, I think you would be better off than trying to put them all on the same wireless network in client mode. Then you know that each PC is only talking to its own EZ-B and don't need to worry about IP address reservations, the DHCP Bug that the EZ-B currently has, or a host of other potential issues.

Only thing is that the LAN connection can not be in the 192.168.1.x subnet or it won't be able to communicate to both the EZ-B and network at the same time.

Alan

Great information, Alan. I'm sure glad this forum is available for just this sort of teamwork, but also glad that it has a good search facility. In a week or so, I'll come back to your feedback and Steve's as well, and roll it into my business plan.

Awesome!

Ok, Alan, I'm still thinking about this. In the computer lab environment I see my final product placed in, there would be a minimum of 25 (max could be 100 or more) PCs, all hardwired to a LAN, and all running EZ-B, and there would be one humanoid head at each PC work station serving as the primary user interface for a student.

If I understood your post above, each EZ-B should be running in AP mode, is that correct? That would ensure that each EZ-B would be talking to its own PC. But now I'm wondering about having 25 pairs of devices transmitting wireless packets in such a lab environment. Although any particular EZ-B would only respond internally to its partner PC, wouldn't each EZ-B need to read and examine each and every packet transmitted by the other 48 devices in the lab? If so, wouldn't it be possible for all devices to reach a saturation point, maybe not with 25 pairs, but more?

What I'm seeing is that the EZ-B and JD humanoid head combination is great for prototyping. However, if indeed the final product requires an expressive humanoid head in fixed position, then a hardwire connect between the head and PC, for both signal and power would be the best approach. Also, the design of the controller board would not need to be so complex as we are only dealing with a robot from the neck up . . . well, lot's to think about here.

Ron

Also, Alan, I looked at the thread you referenced above on the DHCP bug. I was blown away at your ability to troubleshoot so effectively. Each of your three scenarios nailed it! No router issues for sure.

So, as I understand it, DJ is awaiting a response from the manufacturer of the tcp stack that is licensed for the EZ-B wifi modules. Is that correct?

Ron

Yeah, at some point you are going to start seeing wifi channel interference and signal saturation. I am not sure at what point that would be, but it would be reduced if all the EZ-B s shared a network in client mode, but we really need the dhcp issue fixed for that to be reliable.

Interestingly, the old EZ-B v3 that used Bluetooth was easy ti convert to hardwired USB, but it ran at comm port speeds, so no built in video (although that might not actually be an issue in your environment. You could have videeo in the monitor rather than the JD head).

I don't want to push you away from an EZ-B solution, but have you considered a software avatar rather than a physical robotic interface? (to see what I mean, go to Amtrak.com and use the "Ask Julie" tool).

Alan