for the last year I tried coming up with a wireless scoring machine particularly for epee fencing (as it is the easiest to do).
The "dumbed down" scheme is as follows:
2 standalone Xbees sending to one master xbee/arduino that does the scoring. Sounds easy when you have one sending and one receiving. But how are two sending and one receiving handled? I had a look at the tutorial over at Digi and saw that there are tutorials like Examples & Guides | Digi International. I saw that I had to set ID of the sending XBEE into the config of the receiving one... but how can I handle then two sending to one?? If someone can help... please.
The advanced scheme:
The previous scheme just detects a hit. In an epee there is just a momentary switch in the tip that connects and sends a "hit" signal. simple. But what happens when you hit the weapon of the opponent? Luckily in the cabled version this is solved by detecting a second contact... there is a third connection to the weapon that makes closes the circuit when one weapon touches the other. Simple done when you have wire, but how can you achieve this wireless? I know it has been done because there is a company that sells devices that can do that (but they're in the range of 250$ approx.)
I'm aiming at the dumbed down scheme right now, but if anybody has an idea for the advanced version let me know.
The previous scheme just detects a hit. In an epee there is just a momentary switch in the tip that connects and sends a "hit" signal. simple. But what happens when you hit the weapon of the opponent? Luckily in the cabled version this is solved by detecting a second contact... there is a third connection to the weapon that makes closes the circuit when one weapon touches the other. Simple done when you have wire, but how can you achieve this wireless?
Seems to me that you want to send data only when the wired version of the switches says that there is a hit.
If not, then there is no easy way to accomplish what you want to do.
You could have each XBee send a single byte. If there are collisions on the receiver, the byte(s) won't be acknowledged, so each XBee will send again. The problem, though, is you won't be able to determine anything about the order of the hits, since the retry interval is random, and the retry data may not arrive in the same order as the original data.
Time stamping the hit data requires sending 5 bytes, which increases the odds of collision, but would enable you to determine the correct order of hits.
I mean, is there a possibility that I can just send a HIGH via the two Xbees (without an Arduino) that can be received by an XBEE/Arduino combination that can tell apart the two signals?
why two sending xbees? because there are two fencers, of course. And I need one receiving base station
I mean, is there a possibility that I can just send a HIGH via the two Xbees (without an Arduino) that can be received by an XBEE/Arduino combination that can tell apart the two signals?
The receiving XBee can tell which sender sent the data, but not WHEN. Since the order of hits is important, you'll need to perform the lockout on the swords, so that the only one device is sending data.
It seems I have to elaborate a little more. Sword is the wrong term, by the way, as classic fencing is devided into saber, foil and epee. I'm dealing with the last one here. Sword fighting is technically not considered fencing.
If both fencers hit the other at the same time (in a 25 ms frame, I think, have to check FIE regulations for that) they both score a point. Any longer than that and only one of them gets the point.
Sooo... if the receiving Xbee knows the source of a signal, then I can time the signals with the arduino in my mind. Just has to start a counter and if there's a second hit within this time frame, it will show 1:1 as hits, otherwise it ignores all signals for... say 2 seconds. Or am I wrong?
My problem is that I don't know how I have to do that i.e. how do I have to configure the Xbees. And ideally I don't want arduinos in the sending devices and just have the Xbee send a signal when the line goes HIGH. I don't have to send other data than essentially a "1".
You have several things to consider here.
Opponent 1 scores when his tip is closed for at least 2 mS and the tip is not closed against opponents tip, or a grounded strip.
Opponent 2 can score if his tip also closes within 40mS (1/25th of a second) of opponent 1.
The way I solved this is by sending a series of pulses down one tip wire and looking for Hi-Lo-Hi-Lo coming back on the 2nd tip wire.
If only Hi came back, that indicated open tip. If only Lo came back, that indicated grounded tip. If Hi-Lo-Hi-Lo for 2mS, good touch.
Hitmate.com solves the opponent bellguard grounded issue by treating the bellguard like a big capacitor, uses the body cord against the body as a ground plane.
I don't know how they addressed that for the Olympics. I am figuring the two fencers body units are in sync somehow so that a tip against a bellguard is read back as some kind of valid signal and does not indicate a touch. The master unit that runs the lights for the spectators maybe just listens in on the comm's and displays accordingly.
Well, I'm not going for FIE rules compatibility here. I knew the 40 ms rules, but not the 2 ms one. That means, in my mind, that I do have to add Arduinos to the two senders to check for that delay, right? If the arduinos can resolve that kind of timeframe. If not, I will simply drop that as well and make even the <2 ms connections a (possible) hit. Also, I'm not going to add support for a grounded strip. We don't have metal lanes, we have to roll out black gummi mats.
Yes, I was talking about Hitmate. Seems too complicated to achieve or me. And somehow now i makes sense that it's not always relieable when the fencers start sweating heavily (acording to some product reviews). I am a chemist and have a basic elecronics course under my belt, but I fear it's not enough for the bell guard. It will be a challenge getting the rest to work, as it is.
No.I had not looked into wireless at all.
Perhaps have weak high frequency pulse on A wire that B wire picks up, with different frequency on C wire.
If B senses open, no touch.
If B senses A frequency, touch.
If B senses messed up A frequency, bellguard.
Send message via Xbee or some other small transmitter for master light box to pick up.
Look at nrf24L01+ modules for transceivers.
As you can see in the title of the thread, I am investigating the possibility of communication via Xbee. I tried simple wireless modules, but somehow I only got a range of 30 cm. And you can't change frequencies with them.
I was hoping somebody from the forum might have some experience with Xbee-communication.
30cm? You were not doing something correct.
I use simple 433 MHz Rx/Tx module with the remote for my machine. 17cm wirewrap wire for antenna. Good 40 feet away (farthest I have tried).
Well, my 433 MHz module was a cheap Chinese knock-off, so maybe that was the reason.
I don't think I need different frequencies. The Xbees normally send their identification, don't they? And aren't they supposed to handle packet collision? And is that really a danger here? How short are the data packages/signals anyway?
I don't get you comment, though..?
You need the uC to provide the timing smarts
uC as in Microcoulomb? Of what and why do they have anything to do with timing?
The Xbees will send whatever you program them to send, and the master will address collisions however you program it to address them.
How short the data is depends on what you tell it to send.
You could have each transmitter send its ID, timestamp, and fencing action that occurred. Send it 3 times, master receiver with lights for each strip could ignore any IDs not associated with its strip, and incomplete messages, and just process good, complete messages, ignoring duplicates if all 3 came in.
Not sure what you'd do on a double touch - maybe set up so that each end is sort of scheduled about sending. One side sends immediatetely on a touch, the other side sends 2mS after a touch all the time or something similar.
I've not used Xbees, so maybe the libraries for controlling them can do smarter stuff.
The Xbees normally send their identification, don't they?
Yes, but that is not passed on to the serial port, unless you are using API mode.
Can you elaborate on that? What is required for API mode? Do I need an Arduino/Xbee Combination there for the sending units?
And aren't they supposed to handle packet collision?
Yes. But, when a packet successfully gets through is not the same time as the initial attempt to send the packet, which is what you seem to need.
What's the time difference between initial sending and repeat?
To Robert CrossRoads : may I ask you some precision about this :
"The way I solved this is by sending a series of pulses down one tip wire and looking for Hi-Lo-Hi-Lo coming back on the 2nd tip wire.
If only Hi came back, that indicated open tip. If only Lo came back, that indicated grounded tip. If Hi-Lo-Hi-Lo for 2mS, good touch.".
I combine to weak points : I don't know English very well, and I don't know electronics (almost) at all, so please allow me to ask very specific things to you :
Sending "pulses" down one tip wire = sending Hi-Lo-Hi-Lo ? Or do you use another method like PWM ?
When you expect to read Hi-Lo-Hi-Lo for 2 ms on the other wire, you mean one state per loop, am I right ?
Does the alternance Hi-Lo-Hi-Lo has to be absolutely pefect during 2ms to register a touch ? Would a Hi-Hi or a Low-Low lost in a perfect sequence of Hi-Lo-Hi-Lo reset the 2ms second timing ? If yhe answer is yes, then how do you clean the signal on such long wires ? Do you use capacitors ? If so, where and what specification, please ?
Are you emitting/reading analog or digital signal from your Arduino ?
Would you send me you code if I asked politely ? I'm not planning to copy, as I'm trying to make a saber box, which no one seems to have done on Arduino until now.
Thanks for your attention, Quentin from Belgium
I'm not planning to copy, as I'm trying to make a saber box, which no one seems to have done on Arduino until now.