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]

I was not aware that the default behaviour of ble.broadcast() is repeated (100ms?) advertisements until sent None ( or also sleeps at 1 second I read ? ). I was trying to set up my own series of repeated broadcasts every t ms.

I have stripped out all BT calls from various tasks and coroutines and made a single new multitasked task which broadcasts the current state of 2 vars ( using globals .. :/ ) - I gave up on trying to broadcast only if the vars had changed etc. , or even broadcasting for just 500ms say as mentioned above - too many latency issues. The flood approach seems better. I use rechargeable batteries.

So it is essentially a multitasked "watcher" object, which sends everything down to the observer every 50ms. I am still getting regular resource busy errors on ble.broadcast() ( and also remote.light ) but not as many - I have added try/catch to all hardware calls within repeat loops. I suspect the cause of these OSErrors is simply bad coding somewhere in my nested loops or buried function calls causing a jam.

But at least it is working 100% resiliently and the train is not pulling itself apart! So that's a v1.0 maybe ?

I just wish AI could take my code and make it a lot more elegant ..

[BertLindeman]

In my test I changed the broadcast interval to 250 and that got us (NOT connected to pc):
obs:1500 missed:0 interv:100 0.00%
So:

• broadcast interval 250 msec
• observe interval 100 msec

[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: ***@***.***>

[zus2]

Could you try broadcast 100 observe 50 ? I am thinking observe really needs to be as fast as possible. PSent from my iPhoneOn 30 Apr 2025, at 21:05, Bert ***@***.***> wrote: In my test I changed the broadcast interval to 250 and that got us (NOT connected to pc): obs:1500 missed:0 interv:100 0.00% So: broadcast interval 250 msec observe interval 100 msec —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[zus2]

How did you get the log ? Sent from my iPhoneOn 30 Apr 2025, at 21:05, Bert ***@***.***> wrote: In my test I changed the broadcast interval to 250 and that got us (NOT connected to pc): obs:1500 missed:0 interv:100 0.00% So: broadcast interval 250 msec observe interval 100 msec —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[BertLindeman]

wrote the log to memory and re-read in the REPL with hub.system.storage(0,128)

Could you try broadcast 100 observe 50 ? I am thinking observe really needs to be as fast as possible.

That was the data a few posts back:

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%

Bert

[zus2]

Bert - doesn’t hub.ble.broadcast() automatically run a separate thread/task every 100ms for 1 second ?I thought I stumbled across that in Pybricks api Sent from my iPhoneOn 30 Apr 2025, at 21:42, Bert ***@***.***> wrote: wrote the log to memory and re-read in the REPL with hub.system.storage(0,128) Could you try broadcast 100 observe 50 ? I am thinking observe really needs to be as fast as possible. That was the data a few posts back: 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% Bert —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[dlech]

doesn’t hub.ble.broadcast() automatically run a separate thread/task every 100ms for 1 second ?

No, that is entirely handled by the Bluetooth chip. We just set the broadcast interval to 100ms and the advertising data and it infinity broadcasts until we tell it to stop (no 1s timer, no threads/tasks running in the background).

Technically, you only need to call broadcast() when the values actually change. If they are changing faster than every 100ms, then then you could rate-limit calls to broadcast().

You should be able to call observer() as often as you want because it doesn't do any I/O. But if the broadcast interval is only 100ms then calling it any faster is just going to return the same result every time.

[zus2]

You would think polling as fast as possible would reduce latency but may well introduce errors if broadcasts are granular - but they can be excepted no ? However does memory become an issue for rapid polling on the observer ? Or even battery drain ? PSent from my iPhoneOn 30 Apr 2025, at 21:42, Bert ***@***.***> wrote: wrote the log to memory and re-read in the REPL with hub.system.storage(0,128) Could you try broadcast 100 observe 50 ? I am thinking observe really needs to be as fast as possible. That was the data a few posts back: 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% Bert —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[dlech]

However does memory become an issue for rapid polling on the observer ?

No, it shouldn't as long as you aren't doing something like appending every value read to a list.

Or even battery drain ?

No, CPU and Bluetooth usage are negligible compared to the amount of power that motors and lights use.

[zus2]

That’s all very useful thanks - always seems like waiting 1000ms or 100ms or 10ms seems kind - to allow something to breathe - but in fact wait(0) costs nothing really. n 30 Apr 2025, at 22:29, David Lechner ***@***.***> wrote:

…

However does memory become an issue for rapid polling on the observer ? No, it shouldn't as long as you aren't doing something like appending every value read to a list. Or even battery drain ? No, CPU and Bluetooth usage are negligible compared to the amount of power that motors and lights use. — Reply to this email directly, view it on GitHub <#2172 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKHCFE6NGLIXUEYMMYLLSFD24EXBBAVCNFSM6AAAAAB4DWOATKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEOJZHA2DGNI>. You are receiving this because you authored the thread.

[dlech]

always seems like waiting 1000ms or 100ms or 10ms seems kind - to allow something to breathe

On ev3dev that runs Linux, this is true! But not needed on the Powered Up hubs.

[zus2]

Nice to know ! 🚀

…

On 30 Apr 2025, at 22:43, David Lechner ***@***.***> wrote: always seems like waiting 1000ms or 100ms or 10ms seems kind - to allow something to breathe On ev3dev that runs Linux, this is true! But not needed on the Powered Up hubs. — Reply to this email directly, view it on GitHub <#2172 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKHCFEYXRHSWOGGQM3G4ERT24EYXJAVCNFSM6AAAAAB4DWOATKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEOJZHA2TAOI>. You are receiving this because you authored the thread.