How do you in a situation with one infrared reciever deal with multiple signals for say if you had multiple infrared diodes sending different data at different times and they cross collide with each other is there a technique for dealing with this what is the approach?
is there a technique for dealing with this what is the approach?
You have no hope of separating 2 codes that overlap when using proprietary coding schemes as you have no control over the format and contents of the code.
If you have full control over the devices sending the codes and the format and contents of the codes then it might be possible to extract sensible code from the overlapped version.
Suppose that each data byte from device 1 was preceded by 0xFF and the data never contained 0x00 and that each data byte from device 2 was preceded by 0x00 and the data never contained 0xFF then you might be able to unscramble them, but good luck in doing it.
Shandy:
How do you in a situation with one infrared reciever deal with multiple signals for say if you had multiple infrared diodes sending different data at different times and they cross collide with each other is there a technique for dealing with this what is the approach?
When they 'collide' you will need error-handling code.
You could try multiple receivers for multiple senders if you restrict the view of the detectors so that each one only 'sees' the IR from one sender. Put the detector at the bottom of a tube or ballpoint pen barrel.
GoForSmoke:
You could try multiple receivers for multiple senders if you restrict the view of the detectors so that each one only 'sees' the IR from one sender. Put the detector at the bottom of a tube or ballpoint pen barrel.
That would not simulate a bullet strike very well.
This is where the rubber meets the road in network design. (You didn't realise you were designing a network?) Despite the bandwidth on your proposed system allowing a theoretical maximum of over 4000 messages per minute, if there is a possibility of collisions, then your practical bandwidth could be a tenth of this, just to allow lots of blank time that makes collisions less likely.
If there's two-way communication then the target can ask the gun to send the packet again, but only if the address of the sender wasn't clobbered by the collision. But then how does the second gun know that its transmission wasn't read? Maybe the address is repeated on the end of the packet and you assume that you can never have three messages collide? There's no bottom to this particular rabbit hole.
Or re-think the whole protocol. For a gun that can fire 900rpm, just have it send "start" and "stop" packets. Instantly you've reduced the number of packets to be transmitted by a factor of 10 or more.
aarg:
That would not simulate a bullet strike very well.
If the target game shooters are positioned in certain areas/positions then yes, receivers can be view-restricted to those areas.
If it can be any shot from any place for all the "shooters" then perhaps if the "guns" had wireless connections they could take 10 or 20 ms turns to send 5 ms max messages.
Or possibly the "guns" can only fire once every 100 ms and have an IR detector of their own and not "fire" when another "gun" is "shooting" the target area.
All good answers Ive done some testing and it seems that which ever signal started first gets through and all the shots happen so fast that you can't actually notice that they are not being picked up at the same time however the error rate did increase but in game you really would not notice however I only tested with 2 sending and 1 receiving.