Feasibiility of protocols for hot-swappable 100+ unit system

Projects General Guidance
1

I have a particular project where I am wishing to be able to hotswap connect up to (or maybe more than) 100 devices.

They are all square and communicate off of each side with each other and a master device.

I have had some success with pogo pins and pads on each side and using EasyTransferI2C to get data through to the master.

I am now at being able to connect 5 tiles. Which sometimes doesn't quite work if I don't connect the intterupt and data pins in close-enough time. I see that this could be corrected with a message confirmation routine.

BUT. I'm also starting to wonder about whether parasitic capacitance is going to creep into this system.

Currently all four sides are connected to A4/A5.

I am pondering whether I should try to use other pins for separate softwareI2C data (read somewhere that the clock can be common).

I see that the ESP8266 WiFi can have 20 devices connected together at a time. So would have to create the ability in my devices to jump networks to get to 100+ devices.

So I've come to infrared and passing data through as an option.

And, on noticing that exists this project guidance forum, I am curious what those with experience in these matters thinks might be the better physical layer to use?

Summary of layers considered:

  • ESP8266 WiFi - read up. 20 devices can mesh at once
  • I2C - using pogo pins and seeing that sometimes it doesn't fully connect. Worried about parasitic capacitance in the future
  • IR - This, while a bit slow and heavy on power, seems like the right answer. But no current IrDA protocol baked into IRLib nor IRRemote

What do you think?

Cheers,
/A

2

Define a usecase and a protocol, post it, then discuss it. You have neither.

3

Allister_McRae:
I have a particular project where I am wishing to be able to hotswap connect up to (or maybe more than) 100 devices.

Please tell us what the project is. It is much easier to give useful advice when we understand the context.

I can think of a dozen questions to ask most of which will be superfluous if you describe the project.

...R

4

You want to build something like a transputer matrix?

Without nested master-slave levels the only viable approach is a network, maybe wireless.
I2C hardware does not support many clients, IR remote is not directed nor synchronized.

5

You need to do a little more research on protocols and how to implement them You want to look for Carrier Sense, Multiple access, Non Destructive Arbitration type of protocol, there are many around. You will then have to assign an address to each tile. The address could be assigned at build or dynamically when installed. This communication could actually be done as a single wire such as in several different brands of automobiles. Speed is everything and you gave us no speed limit. Capacitance will definitely become a problem, this will cause you do do some design work on the physical layer. This response is to help you get started in solving your problem, not solve it for you.
Good Luck & Have Fun!
Gil

6

Hello,

Thank you for your responses.

This project might most easily be described as "light up scrabble." This is a project which I can spend some money on and am really curious to see if people would be interested in this game and technology.

The IR is only operating with one sender and one receiver (though there are multiple receivers for visualization). The sender is behind the receiver on each tile so that it only gets data from the opposing TX. And I've managed to get two way comms going (wahoo).

You will see six pins. 2 are i2c, one is interrupt, 3 are ground. ( was debating on trying serial. But muxing that situation looked super hairy. And more grounds!)

@gilshultz: I take your points well and to heart.

On my look into Carrier Sense and Multiple access, I'm hoping (maybe?) that I can avoid that overhead. To these points, I2C with its handling of high/low on the bus, sort of takes care of the need for whos in charge.

I have built the code for the backend and do have a functional version with I2C, basically doing address calls to see who is present and then tx/rx data between a master and the "common" tiles, figuring out where they are based on their neighbour, etc.

So... I've come back full circle to my original document that knew I'd have to build tiles that might avoid electrical issues - realizing that dynamic allocation of addresses will be the way to go. You've given me some great terminology to move forward with in my research.

It is currently interrupt driven on each side. (ie. 4 separate iterrupt pins).

I think things can happen within a second or two of each other. The real challenge that I'll work out based on protocol will be synchronizing the tiles to light up in order, or in a pattern or whatnot. Thats the huge challenge if running through IR (which I'd have to capture and retransmit through each tile. So power issues may be a thing, etc.)

@DrDiettrich: I also see your points. Directionality I would address as I can use a single pin transmit on the tx line and have multiple (4) rx devices. IR is very much not synchronized. But maybe if I passed the right data..?(I don't know - and its beyond my current expertise, hence I'm reaching out.)

@zwieblum: Points taken - Hope this helps.

Thanks everyone for your points and taking the time to leave a message.

7

So in summary, every node needs to send a list of up to 4 neighbouring node IDs to some kind of 'backend' system which you haven't described?

How are the nodes powered? If it's via pogo pins to adjacent tiles why is there a need for IR communication, why not use additional pogo pins for data.

What is the maximum number of nodes connected at any one time?
What is the maximum allowable amount of time (milliseconds or seconds) for the 'backend' system to communicate with every node?

If you don't want to use a bus for technical reasons, are you looking for a mesh protocol where there is some kind of routing table that allows nodes in the middle to move their data to an edge node connected to the backend?

8

@mikb55

Max nodes planned is 100.

Pogo Pins - I am not confident that I'm heading down a good path here. Some tiles are bound to be 5 Tiles Up, and over, and mayb connecting through multiple routes if a set of words forms a block. Ex. Say we allow two letter words and we have things in positions 0,0 : 1,0 : 1,1 : 0,1. (or way off 5 tiles over and 5 tiles up they connect with words that started on the top and right of the master tile.

Ex: (M)aster tile, Common (T)iles, (*) is the Tile where two sides are connected, offset x to y.

T T T T *
T T
T T
T T
M T T T T

Power is currently designed as battery within the tiles themselves. Though it would be neat if they could be charging from a larger power source at the Master tile while in play. But then I hit that "more energy probably means more potential electrical issues.)

My lack of knowledge on what will actually happen with electrical is why I'm asking for advice from others.

You are making an excellent point about Edge nodes.

I have two relevant thoughts:

  1. Perhaps I can move the i2c to digital pins so as to isolate them from all being connected to A4/A5 - I have not experimented with that yet as I was kinda comfy with EasyTransfer and "it works for now." This would also help with what @gilshultz was suggesting earlier I read more about (Carrier-sense multiple access et al.)

  2. In thinking about an IR protocol, I was thinking that the tiles would only hold on to their four neighbours and I'd build the address system so they tiles sort of know where they are. (ie. the address is broken up into two parts for a square grid and numbered with uint8_t to match the grid from its origin (plus offsets to start in the middle etc) - This could be implemented as per number 1 as well.

Timing, in my mind, could take up to a second or more to communicate the data from the newly placed Tile, processed at the Master, and information sent from the master to each of the relevant tiles that needs an instruction.

9

Allister_McRae:
This project might most easily be described as "light up scrabble."

That's not a lot of help.

Do you mean that (like scrabble) each piece has a specific character or value and that the user needs to assemble the pieces in a specific order to create "words".

And (like scrabble) is there a list of acceptable combinations?

If it's not really like scrabble why not just tell us what it actually is. If it is a commercial secret then get paid professional advice rather than trying boost your profits at our expense.

To my mind there are still a lot of critically important unknowns.
You have told us almost nothing about the qualities or competence of the individual pieces - what makes them different from each other? - why would a user choose one or another?

How quickly does a new piece need to become part of the system?

It occurs to me that if the connection simply provides power to a board it could then become part of a wireless system.

...R

10

You only need to solve a fairly simple problem: can a new/unconfigured node be configured automaticly by at least one neighbour? And you do not need to invent somthing new, search for "mesh" and you will find a lot of decentralized protocols ready to use. For node2node communication: pogo pins might work, but better go for something not so error prone. IR (as you mentioned) would work nicely, you just need sender+receiver inside a tube ~ the size of your magnets.