Three gadgeteers speaking serial with each other?

Hey hey, I’m back with more questions!

Alright, I have three gadgeteers (each with its own screen, hence why I can’t do it with just one mainboard), each has a rotary encoder which allows for scrolling of content on the screen its connected to. However, I need each mainboard to also know how many steps each of the other two rotary encoders have made, so I need to make them communicate between each other.

I’m fairly used to speaking serial between Ardunios, but I’ve never done that with more than two boards speaking with each other. Is it even possible to do with gadgeteer? I’d want to avoid the hassle (and cost) of setting up bluetooth modules and such, or for them to connect to a common point outside my build, as I don’t want it to be dependent on having internet access.

I’m thinking there must be a way of simply hooking up two gadgeteers, with their sockets (just disconnect whichever connections I don’t need) and connecting the TX and RX pins on each socket, or am I barking up the wrong tree here? What would I do programmatically to make that work though?

So, any ideas how I would go by this? I would greatly appreciate any help :slight_smile:

@ MrP - I would use this module if range permits:

The TX pin of a serial port can drive multiple RX pins, but two TX pins can drive one RX pin. The serial ports can not connect/disconnect.

Most Gadgeteer mainboards have at least three serial ports.

Let’s name the boards A, B and C, and on each board define serial ports SA, SB and SC.

From the A board, connect the TX pin of SA to the RX pins of the SA ports on B and C.
From the B board, connect the TX pin of SB to the RX pins of the SB ports on A and C.
From the C board, connect the TX pin of SC to the RX pins of the SC ports on A and B.

Each board can then transmit/broadcast to the other two boards via its named serial port. The other nodes know where the message came from since the receiving port is associated with one board.

Does this help?

No, but should work with low traffic rate and small messages.

RS485 is a bus communication so you could do this… the synchronisation of message transfer isn’t trivial, you may well find you use (maybe even need to generate?) a CSMA/CD like protocol (Carrier-sense multiple access with collision detection - Wikipedia) and back-off when collisions occur.

Of course, you could always push data over multiple standard serial connections too, depending on what boards you’re using it might mean you need to go to a central master device?

What kind of latency can you deal with?

I would use this:

And the rf24l01 can be had for $5

And since you aee an arduino guy, you might even be able to port this to netmf


For robustness sake I’d prefer not to deal with the whole infrastructure that is wireless communication (not to mention added cost, regardless if it’s RF, bluetooth or wifi).

Mike, that does help immensely. I will have to do some tests to see if I can set something like that up. I do not need to send massive amounts of data by any stretch of the imagination, just a three digit number at most twice a second or so.

Let’s see if theory meets reality, thanks a lot!

As for the question of latency, that’s not a big issue, I’m more concerned with data loss, though that could partly be fixed through the code as well to compensate.


Use a checksum and ack if there is an error. It just means the transmitter must retain a copy of the sent message for a set time, that’s if you don’t ack each message.