interference during the Lego exhibition.

[MeriatoP]

Hello everyone,
Not being good in English, I use Google to translate. I am French.
I use a set of 7 hubs to manage 2 trains on the same track:

• 1 hub (mindstorm) that I would call switch: which manages a switch and gives orders to 2 hubs (city), 1 hub per train that I would call train controller.
• 2 train hub (city) controller: This has a color sensor that checks specific tiles positioned in strategic locations to give specific orders to the hubs in the locomotives.
• 4 hub (city) locomotives: these hubs manage the headlights and the engine under the locomotive.
  The scenario:
  the trains turn in the same direction and wait on a relief track while the other train turns.
  The switch hub manages the switch and gives the tempo to the controller hubs.
  The controller hubs receive instructions from the switching hub and color tiles then give orders to the locomotive hubs assigned to it.
  Although the colored tiles are not always well seen, the alternation of the trains works perfectly.
  This weekend during a Lego exhibition, nothing was working.
  The table in front of me, the exhibitor was using Buwizz blocks and when he used them, that's when everything went wrong in my programming.
  For additional information, my friend had a bluetooth hypoglycemia sensor and it found itself disconnected from the smartphone.
  Have you had this kind of experience? If so, how did you resolve the problem?
  I told myself that in the transmission list to add a complex and long code so if this code is not sent in the list then the hubs do not take into account the signals received.
  Additionally, can you tell me if there is a sensor/tile distance so that the tile is systematically seen?
  Thank you for the time you took to read me

Bonjour à tous,
N'étant pas bon en Anglais, je m'aide de Google pour traduire. Je suis français.
J'utilise un ensemble de 7 hubs pour la gestion de 2 trains sur une même voie :

• 1 hub (mindstorm) que j'appelerais aiguillage : qui gère un aiguillage et donne des ordres à 2 hubs (city), 1 hub par train que j'appelerais controlleur de train.
• 2 hub (city) controller de train : C'est dernier à un capteur de couleur qui vérifie des tiles spécifique positionnés à des endroits stratégiques pour donner des ordres spécifiques aux hubs dans les locomotives.
• 4 hub (city) locomotives : ces hubs gérent les phares et le moteur sous la locomotive.
  Le sénario:
  les trains tournent dans le même sens et attentdent sur une voie de délestage pendant que l'autre train tourne.
  Le hub aiguillage gére l'aiguillage et donne le tempo aux hubs controlleur.
  Les hubs controlleur reçoivent les instructions du hub d'aiguillage et des tiles de couleurs puis donnent des ordres aux hubs locomotives qui lui sont attribuées.
  Bien que les tiles de couleurs ne soient pas toujours bien vu, l'aternance des trains fonctionnent nickel.
  Ce week end pendant une exposition lego, plus rien ne fonctionnait.
  La table en face de moi, l'exposant utilisait les blocs Buwizz et quand il les utilisait, c'est là que tout dérapé dans ma programmation.
  Pour l'information complémentaire, mon pote avait un capteur bluetooth de hypoglycémie et ce dernier se retrouvait déconnecté du smartphone.
  Avez-vous eu ce genre d'expérience? Si oui, comment avez vous fait pour lever le problême?
  Je me disais que dans la liste de transmission de rajouter un code complexe et long ainsi si ce code n'est pas envoyé dans la list alors les hubs ne prennent pas en compte les signaux reçus.
  De plus, pouvez-vous me dire s'il y a une distance capteur/tile pour que la tile soit systématiquement vu?
  Merci du temps que vous avez pris à me lire

[laurensvalk]

The table in front of me, the exhibitor was using Buwizz blocks and when he used them, that's when everything went wrong in my programming.

Have you had this kind of experience? If so, how did you resolve the problem?

That's really interesting. What kind of behaviors did you see? Was it getting "the wrong data", or "less data"?

For example, if you did only this, what would it print in your case?

For additional information, my friend had a bluetooth hypoglycemia sensor and it found itself disconnected from the smartphone.

I'm not really sure what that is. Did you mean that your friends' Bluetooth devices/applications also stopped working when Buwizz was activated, completely independent of Pybricks?

If that is the case, maybe Buwizz isn't using Bluetooth correctly, or "nicely". I wonder if it is also constantly broadcasting and observing.

I told myself that in the transmission list to add a complex and long code so if this code is not sent in the list then the hubs do not take into account the signals received.

This might be a good idea. Maybe this is something we should build in. It doesn't have to be very long; perhaps a 2 or 4 byte checksum will do. This will reduce the available data that the user can send, though.

Although the colored tiles are not always well seen, the alternation of the trains works perfectly.

Good to hear that this was working. You could also calibrate the colors for increased performance.

[MeriatoP]

Have you had this kind of experience? If so, how did you resolve the problem?

The behavior is quite sporadic. The most frequent case was that one of the locomotives received the order from the master hub but not the other or reacted against the instructions issued by the master hub of the train while respecting specific parts of the programs.
The train, even if it was well underway in its program, could have one of the locomotives shut down at any time.
The more I think about it, the more the idea of ​​the confirmation code seems the most relevant to use. Indeed, the list for a locomotive to stop is 0,0,0,0. the simplest list ever. All it takes is for a transmission from a neighboring hub to match this list and the locomotive stops.

For example, if you did only this, what would it print in your case?

I wondered how to know but didn't think to write it like that.
I focused more on how to counter the other signals... but doing your program would have helped me know.
Too bad, it will be for a future exhibition.

I'm not really sure what that is. Did you mean that your friends' Bluetooth devices/applications also stopped working when Buwizz was activated, completely independent of Pybricks?

The sensor worked, but the dialogue between the sensor and the smartphone was not happening.

Yes I think that the Buwizz are transmitting and listening constantly. In my opinion, it is above all the transmission power that is important. because even two hubs 10cm (4 inch) apart were parasitized.

This might be a good idea. Maybe this is something we should build in. It doesn't have to be very long; perhaps a 2 or 4 byte checksum will do. This will reduce the available data that the user can send, though.

How much of a figure does this represent?
My list is like this:
a,b,c,d
a = 0 to 9 (dialogue with the switch HUB)
b = 0 to 100 (dialogue with controller hub and locomotive hub for set speed)
c = 0 to 99 (dialogue with controller hub and locomotive hub for acceleration time in seconds)
d = 0 to 1 (dialogue with controller hub and locomotive hub for switching on the headlights)

Just in case, I will integrate this confirmation code into my program. I would put my date of birth (so you have an idea of ​​the length of the code)
I guess the longer the list, the longer the dialogue will be?

Good to hear that this was working. You could also calibrate the colors for increased performance.

I did the color calibration but it didn't work consistently. it brought a random side and therefore less monotonous to the whole but I would have liked the idea to come from me. lol.
I wonder if the quality of analysis of the sensor is very subject to the battery charge level?

Thank you for reading and responding to me

[biasedlogic]

The thing is, there are some (cough) devices made by some (cough) companies, who do not observe the rules of the 2.4GHz band, in which Bluetooth operates. One of the rules is not to hog the bandwidth. There's no free lunch: the frequencies available to BT are shared by all BT devices and the idea is that not all devices send data at the same time and none of them sends data all the time, so they will be able to share the bandwidth. Think a classroom discussion: each kid takes turns talking, so they can all say something, but none can talk all the time.

Since in crowded environments this does not work very well - think school cafeteria where every kid tries to talk at the same time and they scream over each another, which means almost no data can be transmitted, things like bluetooth LE were introduced, where the communication power is much smaller, so that the distance of the connection is smaller, so that device pairs that are say, few meters apart, can each communicate on the same frequency without disturbing each other. Think school library, where everyone whispers, so many conversations could happen at the same time, but only kids close to each other hear each other.

Now, you can't at the same time have good range of communication and a lot of devices communicating. What one could try is having a shielding around the installation, since most LEGO will be at table level, a boundary fence of conductive material shielding at least the direct line-of-sight contact from other tables might be enough to establish communication again. However, for big events I'd still think about working with train orders, like they did it on real railways in the past. Either make trains stop close to a building where the commanding brick is, so at close range they can communicate reliably and make the commanding brick send encoded instructions to the train so that it can autonomously complete a circuit, or even use color signaling, like semaphores, only embedded into the track, so that no radio communication is necessary.

[MeriatoP]

I thought about all this.
I didn't specify it but even hubs placed 10cm (4 inches) away were disrupted.
I tell myself that it is either a question of transmission power and/or my list is too simple and that it interprets any external transmission as a signal coming from one of my hubs

Thank you for reading and responding to me

[biasedlogic]

Okay, so you have a few issues here, some of them are home-made.

1. You treat radio transmission as if the delivery was guaranteed. It isn't. Here really reading up on how real railways operate will give you a lot of ideas on what would be good strategies to control a multi-vehicle display. You especially cannot assume that you can send a message to two vehicles and both will get it. If you really need motion coordinated between two vehicles, then they have to talk to each other, like Controller [C] -> Vehicle [A]: go coordinated with Vehicle [B]. Vehicle [A] -> Vehicle [B]: Comm check. Vehicle [B]=> Vehicle [A]: Comm OK. Vehicle [A]->Vehicle [B]: start moving, confirm. Vehicle [B]->Vehicle [A]: I'm moving. etc. At the same time you need contingency procedure if the last confirmation is not received, as Vehicle [B] might be on the move but just as well may not. For railway displays it would be, however, safest to make the vehicles fully autonomous and rely on own sensors only. BTW: you can do a lot of data with only one color sensor looking on the tracks, google up AMTRAK optical codes for the general idea.
2. You assume received data is good. This is risky, as both, interference may damage your data and foreign transmissions may match your patterns. Depending on the underlying transmission protocols there may or may not be error checking. I don't know, how secure BTLE transmissions are and if foreign data may be received and not get rejected, but I wouldn't assume anything. If you need e.g. four fields of numbers, then add a fifth one that has the value of all the others added together. You will know if the incoming data is yours if a+b+c+d=e. Or do a XOR over all the bits and send as fifth value.

[MeriatoP]

1. Yes, some problems are due to my program and my lack of knowledge. I thought a lot (no joke lol) about making my trains and how to program them. I absolutely wanted each locomotive (front and back) to be lighting. a) to give more life to my diorama (the headlights come on before starting, turn off when the train stops to make room for our train and when it stops temporarily at the station, the headlights remain on ) and b) to provide me with a battery level indicator when the train is in the storage area. The headlights flash so that you are informed of the battery level of the HUB.
   Yes, now that I've experienced it, "just go" without confirmation of an "OK, I'll do this" in a noisy room doesn't work.
   Without irony, my first programs did it but seeing the latest program on Patreon or youtube. I said to myself “OK it works without confirming everything”.
   I find it good that my new program works in private operation but not in exhibition operation. it makes me learn.
   Yes, now I'm thinking about a confirmation system with a timer. in fact it has happened many times that one of the wagons receives the order to move forward (never to stop) well before the other. We can talk about several seconds.
   The idea of ​​the timer is to know when the hubs received the order and when it should start depending on when they received it.

Just to provide information, the HUB which manages the switch is waiting for confirmation from the train concerned to stop giving the order to go there to this same train. I wanted to avoid the risk of the second train leaving while the first train enters the interval where it arrives in the storage area and finally gives the order that it has arrived, it also receives an order to go there. it could have caused a collision

2. Yes, I think I understand what you mean. That's why I thought I would add a fifth value with a fixed code to confirm that it was indeed a package of information coming from the master hub. I find the idea of ​​the addition interesting. I may be stubborn or I don't have enough experience but I like the idea of ​​my code and I would do a good mix of the two. For example X-(a+b+c+d) =e. X being my code that doesn't need to be passed. From what I have been able to see if the frame is 0,0,0,0,0 I have more chance that the HUBs perceive this information from the outside.

Thanks, it gives me lots of ideas.

On the other hand, how many lines of code can we put in a simple HUB City? I'm not sure that all my ambitions can fit into this type of HUB