Advice on a wireless fencing scoring system?

I'm trying to make a scoring system type of machine.

A simple way to think about it is you have 3 boxes (2 children and 1 parent).

The children boxes have a button. When the button is pressed I gather some data (no more than 32 bytes) from on board sensors and send it over to the parent box.

The parent box decides on a winner between the two child boxes. If the first child box presses the button then the second child box has X milli seconds to press the botton (something like 50ms).

The boxes are in a relatively near each other, no more than 10meters (32feet).

All the boxes will be running on batteries.

This isn't actually the project, but a simplification of it here since it would take too long to explain the entire project.

I'm trying to figure out what type of wireless communication method I should use. I have actually tried using the nRF24L01 chips... but they are way to unreliable as I literally have a pile of dead chips (They sometimes just die after the Arduino resets).

I am looking for something - low on power consumption, - can operate in a noisy environment (i.e. many of these boxes running all at once in different channels/addresses), - preferably can transmit and receive. - and is reliable (i.e. not the nRF24L01). I really don't care about range (since this will be operating in close range).

What are some good wireless communication modules/methods that would be best for this application? I saw the RFM69 433MHz chip, any thoughts?

EDIT (27 Nov 2017): Here is some info that helps explain it a bit.

The actual machine is for Fencing and the buttons are actually physical buttons on each sword. The data is capacitance data collected based on the voltage drop (or rise in the case of foil) to determine if the hit was a target hit or an off target hit (metal or not metal and how big of a metal in the case of foil). Then the parent box will light up telling the referee who scored valid touches. So both can get valid touches then the ref decides what to do (but the ref deciding is beyond this machine haha).

So the speed of transmission is very important. Should I use a single transceiver for both transmitting and receiving, or should I use individual transmitter and receiver chips?

For power consumption I can work around a larger power draw if that means faster communication.Although, ideally I would like not to need a large battery pack.

yoseph1998: . . . I have actually tried using the nRF24L01 chips... but they are way to unreliable as I literally have a pile of dead chips. (They sometimes just die after the Arduino resets). . . .

You are not running these at 5 volts, are you ?

Hi,

The parent box decides on a winner between the two child boxes. If the first child box presses the button then the second child box has X milli seconds to press the botton (something like 50ms).

The winner is the first button pressed?

Can you tell us your electronics, programming, Arduino, hardware experience?

Thanks... Tom.... :)

6v6gt: You are not running these at 5 volts, are you ?

No, I have a voltage divider bringing it down from 5v to 3.4v.

TomGeorge: Hi,

The winner is the first button pressed?

Can you tell us your electronics, programming, Arduino, hardware experience?

Thanks... Tom.... :)

The winner would be the box with the best looking data collected from the sensors. The actual machine is for fencing and the buttons are actually physical buttons on each sword. And the data is capacitance data collected based on the voltage drop (or rise in the case of foil) to determine if the hit was a target hit or an off target hit (metal or not metal and how big of a metal in the case of foil). Then the parent box will light up telling the referee who scored valid touches. So both can get valid touches then the ref decides what to do (but the ref deciding is beyond this machine haha).

-I'm using 5v Arduino Pro Mini's. About to get my hand on a large batch of the 3.3v versions. -Programming is in C. I'm more fluent in Java and C++, so C is not a big issue (I have taken a microprocessors class at university). So I know a fair bit of C to not have programming be an issue. -And my hardware experience... well I've worked with EEPROM chips, some I2C sensor chips, I've built a board using a PIC24 microcontroller (Outdated baby haha), I have only ever worked with SPI in this project (the nRF24's). I've never worked with surface mount chips before... I'm quite used to prototyping boards using arduinos, sensors/other modules using pcb prototyping boards and Knar wire.

Hope that explains what you wanted.

  • Yoseph

Hi, Can I suggest you edit your Subject to this thread and put Fencing in it, there is a forum member who knows a lot about fencing and the electronics involved in scoring.

Tom... :)

No, I have a voltage divider bringing it down from 5v to 3.4v.

Not a good way to do it. As the load changes the voltage on your divider will change and you'll blow out your chip. Put it on a proper power source at 3V3 and they'll stop blowing.

You can't really complain about them being unreliable if you are abusing them like this. Remember that you have to consider the part itself and it's current draw as a third leg of your divider circuit.

The nRF24 modules are very reliable if they are used properly.

I don't think your attempt at simplifying the project description is actually helpful because it may be introducing timing complexities that need not exist. Using wireless to detect who presses a button first is not going to be reliable because if the second wireless starts transmitting before the first one finishes both messages will be garbled.

Is it practical for each of the slave Arduinos to store a record of the "hit" data and pass it to the master when the master requests it? The master can poll each slave in turn several times per second and that will completely eliminate the risk of data collisions. The two slaves will need to have very closely synchronized clocks if you want to know which "hit" comes first. The communications from the master could probably be used to synchronize things.

Have a look at this Simple nRF24L01+ Tutorial. It includes an example with a master and two slaves.

...R

Delta_G: Not a good way to do it. As the load changes the voltage on your divider will change and you'll blow out your chip. Put it on a proper power source at 3V3 and they'll stop blowing.

You can't really complain about them being unreliable if you are abusing them like this. Remember that you have to consider the part itself and it's current draw as a third leg of your divider circuit.

Not sure if we are talking about the same voltage divider. https://learn.sparkfun.com/tutorials/voltage-dividers

From my understanding of how a voltage divider works current draw does not affect the output voltage. The formula is Vout=Vin*(I*R2/(I*(R1+R2))) So it simplifies to Vout=Vin*(R2/(R1+R2)) I am using a 1k resistor for R1 and a 2.2k resistor for R2. Meaning if I have a constant and well regulated 5v power source (the Arduino's internal voltage regulator outputs 5v). Then It should bring it down to 3.4v.

One issue is voltage dividers heating under high loads. However the nRF24L01 has a highest current draw of 13.5mA when receiving at 2Mbps. So since P = I*V the highest possible power draw is 0.0675 Watts. well below the rating of most hobby resistor's (1/8Watt 0.125).

I don't see how I am abusing these chips. I've been very careful not to overpower them since I was told that these will fry if supplied with a voltage higher than 3.6.

I don't see why that would be abusing the chip since I have a constant 3.4v to the chip.

Robin2: The nRF24 modules are very reliable if they are used properly.

I don't think your attempt at simplifying the project description is actually helpful because it may be introducing timing complexities that need not exist. Using wireless to detect who presses a button first is not going to be reliable because if the second wireless starts transmitting before the first one finishes both messages will be garbled.

Is it practical for each of the slave Arduinos to store a record of the "hit" data and pass it to the master when the master requests it? The master can poll each slave in turn several times per second and that will completely eliminate the risk of data collisions. The two slaves will need to have very closely synchronized clocks if you want to know which "hit" comes first. The communications from the master could probably be used to synchronize things.

Have a look at this Simple nRF24L01+ Tutorial. It includes an example with a master and two slaves.

...R

So instead of sending if there is a hit from each slave have the server pull for a hit status and time stamping each pull request would probably help synchronize the two boxes. Although wouldn't mean the current draw would always be high (eating away precious battery life)?

What about this. Using two transceiver chips on the master board that listen to each slave separately. That way it can still be time stamped to help synchronize but also eliminate the constant pulling.

  • Yoseph

The resistor network in post #8 ignores the internal resistance of the load you are adding to it. Just consider a 1K resistor between the power rails. At 5 volts, the current flowing will be 5mA. You have mentioned 13.5mA. Do you see a problem ?

Have a look at this. It is designed for 5 volt operation of nrf24l01 devices.

You're right that the current through a divider doesn't change the voltage. But that isn't the situation you have. Part of your current is only going through one leg of your divider.

Imagine your radio as just another load. Let's model it with a resistor. So now you have one resistor from hot and two resistors from it to ground. Your divider just got more complicated. Now imagine that resistor that models your radio is a variable resistor. As you change it you change the resistance on that half of the divider and thereby changing the voltage. You also have less resistance than you thought you had because of the way resistance adds. So you end up with too much voltage and blow your radio.

This comes up all the time as why can't I power an SD card from a voltage divider. It's all well known stuff. Use a divider to get some reference voltage or to cut a voltage down for an input (high impedance). But don't try to use a voltage divider to power a component cause you'll just blow it up.

Delta_G: You're right that the current through a divider doesn't change the voltage. But that isn't the situation you have. Part of your current is only going through one leg of your divider.

Imagine your radio as just another load. Let's model it with a resistor. So now you have one resistor from hot and two resistors from it to ground. Your divider just got more complicated. Now imagine that resistor that models your radio is a variable resistor. As you change it you change the resistance on that half of the divider and thereby changing the voltage. You also have less resistance than you thought you had because of the way resistance adds. So you end up with too much voltage and blow your radio.

This comes up all the time as why can't I power an SD card from a voltage divider. It's all well known stuff. Use a divider to get some reference voltage or to cut a voltage down for an input (high impedance). But don't try to use a voltage divider to power a component cause you'll just blow it up.

That just blew my mind. That is very good to know.

I have a question. So when using chips that require a certain voltage does that mean that I have to have a voltage regulator for every chip (i.e. using two nRF chips)?

  • Yoseph

yoseph1998: Although wouldn't mean the current draw would always be high (eating away precious battery life)?

How long does a fencing match last? A pair of AA alkaline cells will power an Atmega 328 with an nRF24 for several hours - like maybe 20 hours. Compared to the cost of fencing gear I suspect cheap alkaline cells are a trivial expense.

What about this. Using two transceiver chips on the master board that listen to each slave separately. That way it can still be time stamped to help synchronize but also eliminate the constant pulling.

You would probably need to disable auto acknowledgements to prevent the two "receivers" from interfering with each other and that would likely make the system less reliable as the slaves could not be sure that their message was received.

If the only purpose of this is to reduce the cost of batteries I don't see the point. Keep it simple.

...R

Robin2: How long does a fencing match last? A pair of AA alkaline cells will power an Atmega 328 with an nRF24 for several hours - like maybe 20 hours. Compared to the cost of fencing gear I suspect cheap alkaline cells are a trivial expense. You would probably need to disable auto acknowledgements to prevent the two "receivers" from interfering with each other and that would likely make the system less reliable as the slaves could not be sure that their message was received.

If the only purpose of this is to reduce the cost of batteries I don't see the point. Keep it simple.

...R

You make some very good points. Thank you for the advice. This also fixes another problem. If all active strips have their master board constantly pulling data from the slave boards then any extra strip wanting to pick an empty channel can just walk through the channels till it finds one without traffic. Thank you so much. I appreciate it.

  • Yoseph

yoseph1998: then any extra strip wanting to pick an empty channel can just walk through the channels till it finds one without traffic.

I'm not sure that you mean by "extra strip" but there is no need for every master-slave group to use a different channel. Different addresses will probably be sufficient unless there is a very high update rate.

I built 4 pairs of controllers for a model railway system and they all work quite happily on the same channel using different addresses for each pair. Each pair sends messages about 10 times per second. The system is designed to withstand occasional data collisions.

However, based on my current knowledge of nRF24s if I was building the system now I would just use one master to poll the 4 hand controllers. and that would avoid the collisions.

...R

Robin2:
I’m not sure that you mean by “extra strip” but there is no need for every master-slave group to use a different channel. Different addresses will probably be sufficient unless there is a very high update rate.

I built 4 pairs of controllers for a model railway system and they all work quite happily on the same channel using different addresses for each pair. Each pair sends messages about 10 times per second. The system is designed to withstand occasional data collisions.

However, based on my current knowledge of nRF24s if I was building the system now I would just use one master to poll the 4 hand controllers. and that would avoid the collisions.

…R

So in fencing you’d have a strip that two fencers fence on. So for this project each strip would have a master box (showing the lights and telling the judge who hit who), and two slave boxes attached to each fencer that the master would pull for hit status.

If you have two strips (the line on which a fencer fences on) you’d have two separate master boxes indicating to two separate judges who touches and which ones are valid, all at the same time.
If you look at fencing nationals, you’ll have well over 60 different strips each with different scoring systems. So when you have 60 strips all fencing at the same time (or maybe the boxes don’t get turned off) and suddenly someone decides to turn on the 61st scoring system, then that can just sweep through the channels checking for traffic and picking a traffic free channel.

Or at least I think that is doable.
Actually, is this doable? Would it be too much strain on the nRF chips to constantly change channels and check for traffic?

yoseph1998:
Would it be too much strain on the nRF chips to constantly change channels and check for traffic?

If I understand your requirement correctly there would only be a need to check for a spare channel when a new “strip” is brought into use and it would not be a problem for an nRF24 to listen for a few moments on successive channels until it finds a free channel.

However, what you really need is for all three nRF24’s for a single strip to find the SAME free channel, and that is not so easy.

You mention the possibility of 61 separate fencing matches simultaneously. There are only 128 different channels in an nRF24 and I’m not sure if you can use adjacent channels or if you would need to leave every second one unused. If so you would be running right at the edge of the capacity of the system.

You also need to keep in mind that WiFi and Bluetooth and micro-wave ovens also operate in the 2.4GHz band and a frequency that seems clear now may not be clear in 5 minutes time (and vice versa).

Before thinking further about this you need to provide details of how often data needs to transfer from a slave to the master. If the update rate is low then the options available will be much wider, including, for example, one master dealing with several “strips”

Another relevant question is whether there is already a commercial system that operates like this and if so, how does it work?

…R

Robin2: If I understand your requirement correctly there would only be a need to check for a spare channel when a new "strip" is brought into use and it would not be a problem for an nRF24 to listen for a few moments on successive channels until it finds a free channel.

However, what you really need is for all three nRF24's for a single strip to find the SAME free channel, and that is not so easy.

You mention the possibility of 61 separate fencing matches simultaneously. There are only 128 different channels in an nRF24 and I'm not sure if you can use adjacent channels or if you would need to leave every second one unused. If so you would be running right at the edge of the capacity of the system.

You also need to keep in mind that WiFi and Bluetooth and micro-wave ovens also operate in the 2.4GHz band and a frequency that seems clear now may not be clear in 5 minutes time (and vice versa).

Before thinking further about this you need to provide details of how often data needs to transfer from a slave to the master. If the update rate is low then the options available will be much wider, including, for example, one master dealing with several "strips"

Another relevant question is whether there is already a commercial system that operates like this and if so, how does it work?

...R

For getting the master and the two slaves to sit on the same channel I could have the two slaves be physically connected to the master when you start or else the entire system just refuses to start. That way you can have the master find a channel and tell the two boxes to use that channel.That would also mean the slave boxes can be an identical box with the exact same hardware and software. (Makes production easier and more practical if you lose one box and not the other).

In regards to the troubles with wifi I am thinking about using RFM chips at 433MHz or 915MHz (From my understanding the RFM is very similar to the nRF in a lot of ways, correct me if I am wrong). That would allow me to not worry much about interference. I might just have to make the entire thing search every other channel and have it be a project design that only even channels are allowed to be used.

I would need to get started on making a prototype and figure out what type of speeds I would need to be able to accurately do the lockout and buzzing.

I've talked with a few guys from Leon Paul (they currently have one of the few wireless scoring machines available out there). Although they were a bit secretive about those types of details.

I guess I just need to make a prototype box using something like the RFM then slowly start working out kinks and maybe upgrading parts if some become a limiting factor.

You've been a great deal of help! I really appreciate it.

From the (simplified) project description and the following discussion, I more and more wonder why you want to go wireless, rather than wired, like just about all these fencing scoring devices do.

The timing of wireless signals is indeed a headache. Most if not all wireless protocols are simply not designed to be real time.

To do real time over wireless you’ll have to deeply understand the complete protocol, from the lowest level up to the highest, plus the workings of the hardware. Then you can know the inherent transmission delays, chances of channel interference, packet loss and delay of retransmission, etc. Fencing is after all a game where milliseconds count, so any disturbance in the transmission may mean the difference between win and lose (and the cause of many an argument)