RF Transmissions

Hi folks. I'm using several Nordic RF modules to communicate with one another. I have one of them setup as a transmitter and several that act as receivers. The transmitter simply cycles through all the receiver addresses and sends a command to them. Coded like that, the transmitter doesn't care nor knows whether what was transmitted was actually received on the other end. I'm wondering if there is a simple or elegant way of actually creating a two-way handshake, and yet keep the transmissions to a very small window.

So, I have 14 "receivers" that control lights, and 1 "transmitter". The goal here is to have the transmitter send out a command out every 30 to 60 seconds and all of the receivers need to react to that command. And it needs to happen rather fast (we're talking maybe no more than a second or two.) So I can tell the transmitter to cycle through the receivers when sending commands, and I can easily tell the receivers to send a ping back to the transmitter when they receive something. But what happens if the transmitter does not receive that ping back? It will stay "stuck" on that particular receiver till it hears back. Now what?

So I'm wondering if you guys have an idea of how I can tackle this.

The biggest issue here is that if one of the receivers doesn't receive the command, it won't change the lights to whatever they need to be and that's a problem.

15 in 30 seconds is two seconds each, seems like plenty of time to go:

Hey1! Light up! nominally, will send back "Okay, 1 lit" If not, try again, maybe twice, if no answer in the 2 second window allotted, then declare error and move on to next.

Not quite ... I need all of them to react in the 2 second window, not 2 seconds each. Much tighter and faster control/reaction.

It's still fast enough.

But what happens if the transmitter does not receive that ping back? It will stay "stuck" on that particular receiver till it hears back. Now what?

So this is where your protocol design kicks in, there are choices and as you are designing it you get to choose. The most common one is to try again after a certain time out period. This could be a very short period and not affect your timing criteria. However what happens if there is a fault or a interference causing a unit never to respond, after a number of failed resendes you have to think what happens then. You have the choice of ignoring the failure or taking some sort of abort action. As you have not descried much about your application it is hard to advise on these.

Grumpy_Mike: It's still fast enough.

As you have not descried much about your application it is hard to advise on these.

Fair 'nuff.

So there will be 15 RF modules together (they're attached to kids in a parade.) Each RF module is paired with a micro controller which controls two LED strings. One of the RF modules is designated the master and sends out commands, while the remaining 14 are all listeners. So let's say the master sends out the command '1' out. All the receivers will react accordingly ... say they will all cause the LED strings to start blinking each led randomly. Then the master sends out the command '0' indicating that everyone should turn off. If one of the modules doesn't get that command, it will happily continue to blink when all the others who did get the message will shut off. This can be detrimental to the overall effect.

The way the receivers work is they will simply enter whichever loop they're supposed to (that controls the LEDs) and stay in that loop till they're told otherwise (by the RF module).

I thought maybe have the master RF module keep an array of each receiver and whether they responded or not, maybe also keep whatever the last command sent out was. Have it just cycle through the array trying to contact all the receivers ... those that don't, flag them. Then come back and try again.

At the same time, maybe have a timeout on the receivers. If after a certain amount of time, it doesn't hear from the master, have it try to contact the master and get whatever the last command sent out was. And maybe if that also fails, then turn off entirely, or do something else.

It just seems to get a bit complicated the more I keep thinking about it. But then, one has to stop at some point. One failure, two failure, call it quits, as opposed to continuously trying over and over and over again.

This bit sounds like a lot more trouble:-

If after a certain amount of time, it doesn't hear from the master, have it try to contact the master and get whatever the last command sent out was.

The point is that in theses system slaves never initiate communications they only respond to it. Otherwise you have problems with the slave interfering with the master transmissions. Being radio if there is a failure it is likely to be a two way failure anyway.

You have to consider what you want your failure mode to be, because there will be one. How about a system where by if a slave has not received anything in 2 seconds it stops what it is doing? In other words it needs constantly refreshing to carry on doing something so in a failure mode it will default to off.

Or try a simpler protocol. Send out the message, have the 15 units all ack it at preassigned time slots. You've said 2000mS - I bet it could be done quicker. Message goes out - do pattern X next. 50mS later unit 1 acks receiving it, then 2 at 100mS, then 3 at 150mS, etc, up to 15 at 750mS. Each listens to see if everyone else responded, and if everyone got all 14 acks back from neighbors, they all start the next pattern at 1000mS.

Or, message goes out do pattern X next. 50mS later unit 1 acks receiving it, then 2 at 100mS, then 3 at 150mS, etc, up to 15 at 750mS. At 800mS, master decides that all 15 are responding and sends the "change now" message and they change together.

Am sure lots of protocols can be worked up. I would think RF at fairly short range would be pretty reliable.

CrossRoads: Or try a simpler protocol. Send out the message, have the 15 units all ack it at preassigned time slots. You've said 2000mS - I bet it could be done quicker. Message goes out - do pattern X next. 50mS later unit 1 acks receiving it, then 2 at 100mS, then 3 at 150mS, etc, up to 15 at 750mS. Each listens to see if everyone else responded, and if everyone got all 14 acks back from neighbors, they all start the next pattern at 1000mS.

This is doable, however if one (or more) don't ACK in time (or at all), then we have a problem. Possible solution is to continue that cycle over and over again, extending the change time each time, until everyone has responded. The other issue I foresee is that by having them all listening to one another, one can receive all 14 ACKs, while another received 13 only. So it now cycles through and tries again, and it the rest who did get all the ACKs are now waiting. That gets too complicated.

CrossRoads: Or, message goes out do pattern X next. 50mS later unit 1 acks receiving it, then 2 at 100mS, then 3 at 150mS, etc, up to 15 at 750mS. At 800mS, master decides that all 15 are responding and sends the "change now" message and they change together.

Who's to say that second message will be received by everyone? :)

CrossRoads: Am sure lots of protocols can be worked up. I would think RF at fairly short range would be pretty reliable.

And that's the thing. The testing I've done, in-house, was to have the transmitting module in my office, and I walked down the hallway, around two corners, and into the bathroom with two receiving modules, about 20 feet away. 80% of the time, they received the signal. The other 20% I can clearly see that one module would react and the other never got the signal.

Now, the final product will be used outdoors, as I mentioned, in a parade. Where the wearers will be, probably no more than about 5 feet apart from each other. The transmitting module can potentially end up being 50-60 feet away from the last one in the row (unless I place that person in the middle of the rows.) I have to think about the fact that the modules will be on their backs (around their collars) and so they're not facing each other. I also have to consider what happens when they turn a corner and there are a few hundred spectators standing there. One module being out of sync with the rest will definitely stand out.

I'm thinking maybe Grumpy_Mike's idea might be better. If a receiver doesn't hear anything after a preset amount of time, it simply turns off the LED string and waits. This gives me one advantage: I can tell the transmitter to send out commands every X seconds. Have the timeouts on the receivers be X-5 seconds. This way, technically, they will all shut off for 5 seconds before receiving the next command. Then, if one of them doesn't come back on for the next cycle, so be it. At least they were all off at the same time before the next cycle. I think that might be less obvious than instantly switching from one pattern to the next and suddenly have one of them shut off.

I may also still try to have whichever receiver failed to receive its command, send out a request after that 5 second timeout period, and have the transmitter respond. Then again, maybe not ... too much trouble for a 60 minute parade, or 90 minute show afterwards.

Or screw the transmitter, have them all do a preprogrammed sequence.

CrossRoads:
Or screw the transmitter, have them all do a preprogrammed sequence.

If I can get all 15 modules to work in sync and remain in sync, sure. But, when was the last time you found two (or more) identical oscillators, down to the decimals? They’re not, so over time, the modules will get out of sync. At least with a master module, they can somewhat stay in sync.

Put an RTC on each one, set them all to the same time. RF to all to set the Go time of the pattern sequence in controlled space in case parade kicks off early or later. Define the time after Go time that the next pattern will start. DS3231 or DS3234 for example. http://www.maxim-ic.com/products/timers/ds3234.cfm

DS1307 probably good enough too. http://www.dipmicro.com/store/DS1307.SO8

Thanks for the suggestions, but adding an RTC will be an exercise best left for another time. As it is, I'm out of time with this one. PCB production is going to be my demise if I don't quit now. I'll more than likely get some of the PDIP RTCs and do some testing on the side and leave this specific design where it is ... deal with issues through software.