Hub to Hub communication

[Glaysche]

I just upgraded to the new Mindstorms app (10.2.0).  It has a new help center but more interestingly, it has an experimental hub to hub communications.  I tried a quick test.  I made two trivial programs:

 

 

I ran them on two hubs with a motor attached to port A on each.  It worked. Moving the motor on one hub caused the other to move.  It was a bit laggy but not really any worse than using the touch screen remote.

It was annoying to do the programming.  I needed to download the first program to one hub then turn that hub off to disconnect.  I then attached to the second hub and downloaded the second program.  Then you can run the program on both hubs and see it work.  It would be very nice to be able to attach to two different hubs simultaneously.  Maybe even if it's just one hub per tab or something.

I have questions about the implementation.  Since you don't specify a destination hub in a signal, I assume this is just a broadcast?  I wonder how this scales to more hubs? If you had a classroom full of Mindstorms stations, would they all interfere with each other?  I also wonder if the protocol is lossy. I assume it is if it's broadcast.  Also, since the "when hub receives signal" and "Received .... value" blocks are separate, if you receive two signals before you read the value from the first one, I assume you lose the first value? That sounds challenging to make reliable.

They say this is an experimental feature.  I wonder how open they are to feedback?  If one wanted to provide feedback to TLG, where would they send it? I have sent multiple questions in the past to the Mindstorms email on the Lego support page and never received any reply at all.

Edited August 25, 2021 by Glaysche

[Jim]

Very interesting!

And an interesting question. I don't think customer service is the right channel.

Maybe @kbalage can chime in. He isn't a Mindstorms expert, but he has done a lot with the different LEGO hubs.

[David Lechner]

I used a Bluetooth sniffer to see what is going on.

 

It uses Bluetooth Low Energy advertising. So your conjecture about classroom could have some merit. There are only 3 channels used for advertising data, so all hubs would be competing for these 3 channels (compared to 37 data channels for connected devices). But if the broadcasts are spaced out enough, this probably won't be noticeable. Interestingly though, all hubs would be listening to all other hubs, so if everyone in the class made the same program with the same broadcast/receive name (e.g. "Motor1"), then everyone would be trying control everyone else's hubs. But I don't think the Robot Inventor is aimed at classroom use anyway.

Using advertising data also means that data is limited to 31 byte, including overhead (so probably something like 28 bytes). Try sending a long string and see what happens.

It also looks like LEGO didn't quite get the format of the advertising data correct (this is why it says "Malformed Packet"). The actual advertising data is the part highlighted in blue in the screenshot. The first byte is supposed to be the size of the advertising data segment that follows. This is missing and the first byte (which should be the 2nd byte) is the data type. 0xFF means manufacturer-specific advertising data. It is followed by 0x0397 which is the LEGO company identifier. The remaining data is defined by LEGO, so we will have to do some reverse engineering to decode it.

The last 3 bytes as an ASCII string are "296", so I'm guessing that is the motor position being sent as text. There are 5 bytes before this. I'm guessing this somehow encodes the "Motor1" name as some sort of hash. I would expect a hash to be an even number of bytes, so there seems to be at least 1 more byte for something else.

Edited August 25, 2021 by David Lechner

[David Lechner]

For the reverse engineering fans, something to keep an eye on: https://github.com/NStrijbosch/RevEng-hub2hub-word-blocks

It looks like the first byte increases by one with each broadcast.

[Glaysche]

1 hour ago, David Lechner said:

I used a Bluetooth sniffer to see what is going on.

This is great! Thanks for investigating this. You suggest they are encoding the channel name as a CRC32.  That's a bit unfortunate.  Collisions are not that rare with that.  Probably not the biggest problem, though.  Doing all communications over BLE advertising broadcasts with limited packet sizes seems pretty limiting.  This reminds me of when Doom multiplayer mode first shipped (I'm sure I'm dating myself here).  It did all communication over broadcasts and took down our entire campus network.  Probably not a big issue here but it's still not necessarily the best architecture.

I wonder what TLG's roadmap is for this feature?

[kbalage]

10 hours ago, Jim said:

And an interesting question. I don't think customer service is the right channel.

Maybe @kbalage can chime in. He isn't a Mindstorms expert, but he has done a lot with the different LEGO hubs.

I would raise the question in the ROBOTMAK3RS Mindstorms community. Some members there certainly have direct channels to the Mindstorms developers and often get access to experimental features so they might know where to look for information or who to ask.

[Vinz1911]

16 hours ago, David Lechner said:

Using advertising data also means that data is limited to 31 byte, including overhead (so probably something like 28 bytes). Try sending a long string and see what happens.

I tried and there is a hard cut. I received 23 Bytes of content and the rest was lost.

[David Lechner]

Looks like I didn't do my math right. There are 8 bytes of overhead, so of course 31 - 8 = 23 bytes.

[Vinz1911]

I discovered something really strange. I wrote a lib to connect to the powered up remote. I have two programs on the hub, one is for connecting and dealing with my remote and the other program was just a test with the hub2hub feature from lego. If I run first the program which connects to my remote, then disconnecting and stopping the program and after that running the other program with the "when hub receives signal" block. the hub is reconnecting to my handset. This is so weird I tried other programs without the "when hub receives signal" block and then it's NOT reconnecting (which I expect). I'm not sure what happens here, it seems that my class for connecting to my remote is still in memory and the lego block seems to trigger the connection process again, very strange. Seems that this is written with the ubluetooth library or something gets strange with the Nimble stack. :D 

[Glaysche]

On 8/25/2021 at 10:30 PM, kbalage said:

I would raise the question in the ROBOTMAK3RS Mindstorms community. Some members there certainly have direct channels to the Mindstorms developers and often get access to experimental features so they might know where to look for information or who to ask.

Huh, I tried to post a few days ago and I am still waiting for the admins to approve my post.  Maybe they don’t want new members in their group?