twin hub trains - impossible without connection locks ?

[zus2]

I am struggling to work out how to reliably communicate with a 2nd hub. There is no return value or feedback from the observer. It would only take one missed broadcast, to stop() for example, to break any app. Is there some clever logic to back and forth one-way broadcasts that allow commands to be confirmed?

I believe BLE uses advertising to send data - there is no pairing - so it is kind of like smoke signals with no way to be sure both groups have seen the signal.

[dlech]

It works better if you can send "state" rather than "commands". I.e. instead of sending a command to tell it to go faster, just send the desired speed as the state. If you want it to stop, just change the speed to 0 instead of sending a stop command.

If you don't have too much state, you can just send it all at once with a single broadcast(). This way, even if the observer misses a few packets, it will still eventually get the current state.

You can also implement a timeout that if it doesn't receive new data for X amount of time, then maybe we should stop.

[zus2]

Sorry yes I am actually sending raw motor.dc values. Including 0. But the 2nd hub doesn't seem to hub.ble.observe() consistently using wait(10). It seems to miss a lot. There is a built in delay of 100ms is that right?

[BertLindeman]

Paul,

You probably know, but I add this here anyway:
The broadcasting and observing hubs do it a lot worse it they are also connected to another device (as a PC and such).

Tested with a robot Inventor hub to broadcast an incremented counter at 100 msec interval on channel 5.
Used a cityhub to observe at that channel with a 50 msec interval.

• On a non connected run I saw: obs:3000 missed:139 interv:50 4.63%
• On a connected run a bit shorter: obs:300 missed:970 interv:50 323.33%

Quite a difference.
The hubs are close to each other 10 - 20 cm so there is no problem.
Other wifi and bluetooth devices are in the neighborhood and can interfere.

Bert

[zus2]

Hi Bert yes I do forget to disconnect while developing quite frequently! The 5% miss rate is not so bad I just need a way to make the application resilient so that it can absorb these missed broadcasts. One way would be to repeat the broadcasts blindly , alternatively for the observer to confirm receipt before the broadcaster actions. This then becomes the same conundrum in reverse. A central hub would perhaps help coordinate but the essential issue is how to , for example , issue dc=0 to both hubs. There are some dual hub scripts out there I will see if they use any feeeback. Also the blocks example Pybricks code for dual hubs.Cheers PSent from my iPhoneOn 29 Apr 2025, at 23:16, Bert ***@***.***> wrote: Paul, You probably know, but I add this here anyway: The broadcasting and observing hubs do it a lot worse it they are also connected to another device (as a PC and such). Tested with a robot Inventor hub to broadcast an incremented counter at 100 msec interval on channel 5. Used a cityhub to observe at that channel with a 50 msec interval. On a non connected run I saw: obs:3000 missed:139 interv:50 4.63% On a connected run a bit shorter: obs:300 missed:970 interv:50 323.33% Quite a difference. The hubs are close to each other 10 - 20 cm so there is no problem. Other wifi and bluetooth devices are in the neighborhood and can interfere. Bert —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>