Jump to content
Cathodion

Problem with multiple Master bricks

Recommended Posts

Hey fellas,

 

I'm running into trouble connecting multiple master bricks over USB to my PC. I have 3 master bricks installed in different rooms in my attic, and connect those with USB cables to a powered USB Hub, which is connected to my PC. However, if I connect more then 3 master bricks to the HUB brickv can no longer connect to brickd. If I attach 2 master bricks, then connect with brickv, and then connect the 3rd master brick to the USB Hub, I can see the third brick appear in brickv less then a second after plugging it in. But If I then disconnect brickv and try to reconnect it fails, and keeps failing until I disconnect one of the bricks.

 

If i remember correctly I also get problems if I connect 2 master bricks with USB cables to 2 different USB ports on my Macbook.

 

Are there any such problems known to you?

These use-cases are quite important to my setup, so I would be more then happy to give more details on this problem in a Google Hangout or something.

 

Kind regards,

Geert Schuring.

Share this post


Link to post
Share on other sites

However, if I connect more then 3 master bricks to the HUB brickv can no longer connect to brickd.

 

If brickv fails to connect to brickd then this might be a problem in brickd itself. Assuming that you mean that brickv is really complaining about connection problems with a message box. There is known problem like this related to the number of connected Bricks.

 

Are you using the latest version of brickd and the firmwares on the Bricks?

 

What operating system are you using on the PC?

 

Does it matter which of the Bricks you connect as third one that will then trigger the problem? Does this only happen with one of them?

 

What USB cables are you using? Is the problem related to a specific cable?

 

Could you take a look at the brickd log file? On Windows you can use eventlog.exe from the brickd installation directory. eventlog.exe allows to store the log to file. On Linux and Mac the log file is stored in /var/log/brickd.log. Could you attach the log file here on a post, so I can have a look at it?

Share this post


Link to post
Share on other sites

Yes, too long or too low quality USB cables might result in broken/flaky USB communication. That's something to check too.

 

But this should not stop brickd from accepting TCP/IP connection attempts from brickv.

Share this post


Link to post
Share on other sites

Thanks for your replies. I'm trying out several different setups to be able to answer your questions. I have a couple of answers already:

 

- I'm seeing the problem on linux only. If I connect 3 master bricks using long (5m) usb cables and a USB hub to my Macbook Pro I have no problems at all!

- The linux PC that I want to use is an Odroid U3.

- The problem is not related to a particular cable or brick.

- I can connect as much bricks as I want to the Odroid which all works fine... until I disconnect brickv from brickd and try to reconnect. So it looks like there's a problem in the brick/bricklets discovery mechanism on linux when a client connects.

 

I have a Windows 8 laptop in the house (ugh) so I'll test on that one too.

 

I'll have more answers in the coming days.

Share this post


Link to post
Share on other sites

So, if you have brickv connected to brickd before you connect any Bricks then it works. But If you try to connect brickv to brickd while there are already Bricks connected to USB then it doesn't work.

 

Odroid U3 can run XUbuntu 13.10 or Android 4.x according to their website. I assume you're using XUbuntu. Are you running brickv on the Odroid U3 if the problem occurs? If yes you might be affected by this bug in PyQwt. You can check your PyQwt version like this:

 

apt-cache show python-qwt5-qt4

 

If it's older than 5.2.1~cvs20091107+dfsg-6+b3build2.1 you should probably update it.

 

You can also test if the problem doesn't occur if you run brickv on a different computer than the Odroid U3, for example your Macbook, while the Bricks are still connected to the Odroid U3.

 

This all assumes that the problem is related to the PC you run brickv on. If that's not the case and the problem is only related to the PC brickd is running on then I'm following a red herring here :)

Share this post


Link to post
Share on other sites

This is the log of brickd running on the Odroid:

 

2014-03-17 23:14:41.512984 <I> <network|network.c:94> Added new client (socket: 15, peer: 192.168.1.116)
2014-03-17 23:15:01.129551 <I> <usb|usb.c:144> Added USB device (bus: 1, device: 51) at index 0: Master Brick [6QHQQb]
2014-03-17 23:15:14.699561 <I> <usb|usb.c:144> Added USB device (bus: 1, device: 52) at index 1: Master Brick [6DbrcQ]
2014-03-17 23:15:28.269694 <I> <usb|usb.c:144> Added USB device (bus: 1, device: 53) at index 2: Master Brick [6jEWkb]
2014-03-17 23:15:35.442208 <I> <network|client.c:74> Client (socket: 15, peer: 192.168.1.116) disconnected by peer
2014-03-17 23:15:37.095135 <I> <network|network.c:94> Added new client (socket: 15, peer: 192.168.1.116)
2014-03-17 23:15:37.098579 <E> <network|client.c:255> Could not send response to client (socket: 15, peer: 192.168.1.116), disconnecting it: EAGAIN (11)
2014-03-17 23:15:37.214632 <I> <network|network.c:94> Added new client (socket: 15, peer: 192.168.1.116)
2014-03-17 23:15:37.378739 <E> <network|client.c:255> Could not send response to client (socket: 15, peer: 192.168.1.116), disconnecting it: EAGAIN (11)
2014-03-17 23:15:37.536632 <I> <network|network.c:94> Added new client (socket: 15, peer: 192.168.1.116)
2014-03-17 23:15:37.598215 <E> <network|client.c:255> Could not send response to client (socket: 15, peer: 192.168.1.116), disconnecting it: EAGAIN (11)
2014-03-17 23:15:37.706233 <I> <network|network.c:94> Added new client (socket: 15, peer: 192.168.1.116)
2014-03-17 23:15:37.745932 <E> <network|client.c:255> Could not send response to client (socket: 15, peer: 192.168.1.116), disconnecting it: EAGAIN (11)
2014-03-17 23:15:37.874373 <I> <network|network.c:94> Added new client (socket: 15, peer: 192.168.1.116)
2014-03-17 23:15:38.004635 <E> <network|client.c:255> Could not send response to client (socket: 15, peer: 192.168.1.116), disconnecting it: EAGAIN (11)

 

You can see what I'm doing:

  • Connect brickv running on my Mac to brickd running on Odroid
  • Attach 3 bricks using 5m usb cables
  • Disconnect Brickv and try to reconnect

 

See the attachement for a screenshot of the brickv error message.

 

Now the following is the log output of brickd running on my Mac. I've simply attached the same bricks setup to my mac, which is now running both brickd and brickv:

 

2014-03-17 23:26:08.477154 <I> <network|network.c:94> Added new client (socket: 13, peer: 127.0.0.1)
2014-03-17 23:26:15.523401 <I> <usb|usb.c:144> Added USB device (bus: 26, device: 5) at index 0: Master Brick [6QHQQb]
2014-03-17 23:26:15.845647 <I> <usb|usb.c:144> Added USB device (bus: 26, device: 6) at index 1: Master Brick [6DbrcQ]
2014-03-17 23:26:15.907285 <I> <usb|usb.c:144> Added USB device (bus: 26, device: 7) at index 2: Master Brick [6jEWkb]
2014-03-17 23:26:30.675503 <I> <network|client.c:74> Client (socket: 13, peer: 127.0.0.1) disconnected by peer
2014-03-17 23:26:35.006954 <I> <network|network.c:94> Added new client (socket: 13, peer: 127.0.0.1)

 

No problem whatsoever...

Screen_Shot_2014-03-17_at_23_18_57.png.c20fe99d6204fe926b7c67c546de0c04.png

Share this post


Link to post
Share on other sites

That's interesting:

 

2014-03-17 23:15:37.098579 <E> <network|client.c:255> Could not send response to client (socket: 15, peer: 192.168.1.116), disconnecting it: EAGAIN (11)

 

This means that brickd cannot send data to the socket. This only happens if you reconnect brickv while the the Bricks are connected.

 

Brickv requests an enumerate on connect. If no Bricks are connected then there is no enumerate response. If you connect a Brick it sends enumerate responses for its stack only. But if you reconnect Brickv while all the Bricks are connected then all Bricks send their enumerate response at once resulting in a burst. This could explain the problem you're seeing there.

 

I've added a send queue to brickd to deal with this situation. I attached an .deb package for armhf, assuming that the right things for the Odroid.

 

If you didn't install from a package you can find the source code on GitHub:

https://github.com/Tinkerforge/brickd

 

Could you test this version to see if it fixes your problem?

brickd-2.1.0-dfef064fc11f415b926aa82ba77f6f63a8c7b375_armhf.deb

Share this post


Link to post
Share on other sites

YES that worked! Awesome. ;D

I can now hook a whole bunch of bricks and bricklets to my odroid. GREAT!

 

Thanks a lot for taking the time to look into my problem. Its very much appreciated!

 

RRCH0Ms.png

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...