2
\$\begingroup\$

I'm making my own laser tag and I was checking out existing open source solutions.

The MilesTag protocol uses 600us as the basic pulse length. This however limits the maximum rounds per minute to under 2000 RPM while miniguns reach 6000 RPM (100 rounds per second). Are there any reasons I'm not aware of for the 600us pulse?

Will my own solution be less reliable if I go with, say, 300us pulses? Any lower won't work with the IR reciever I'm working with, because it needs at least 10 cycles in a burst with a 40kHz modulation frequency, but a 300us pulse would let me double my RPM.

\$\endgroup\$
  • \$\begingroup\$ @Tut I edited the question to clarify and include my latest findings \$\endgroup\$ – K.L. Apr 16 '14 at 19:57
  • \$\begingroup\$ Hardware restrictions probably apply but without circuits this is impossible to say. \$\endgroup\$ – Andy aka Apr 16 '14 at 20:29
  • 1
    \$\begingroup\$ I can longer find my source so I won't enter this as an answer, but I remember reading that the longer pulse width makes the system more reliable in scenarios where a high amount of reflection is an issue (such as indoors hallways with reflective walls.) When an object is always moving (both blaster and sensor), a sensor can receive reflections from many sources but these reflections can be seen more as quick echos bouncing from all direftions. the longer pulse width requires a more direct and sustained burst. \$\endgroup\$ – JSON Sep 30 '14 at 1:06
  • \$\begingroup\$ Note that in such a sitation (multiple people shooting in a sustained fasion in a hall) it can in effect create a virtually endless lowlevel readings of reflection. In such a situation the sensor needs be less sensative, which in part means requiring longer bursts. \$\endgroup\$ – JSON Sep 30 '14 at 1:15
1
\$\begingroup\$

The following is mentioned on the MilesTag Data Protocol page (the original version of the protocol) that also uses the same timing:

The MilesTag data packet consists of a header pulse followed by 16 data bits (two 8-bit data bytes) and 1 parity bit. The header pulse and data bits are encoded onto a 40kHz infrared carrier signal using pulse-length modulation. This modulation is identical to the format used in Sony IR remotes and others.

So I suspect the original design decision was to pick a low-level encoding method known to be compatible with a wide range of IR receivers. You seem to have determined that the receiver you're using can demodulate a signal in ten cycles, so I don't see a reason in principle the higher data rate won't work but the following might apply:

  • It may be less reliable in one regard because you're giving the receiver less time to demodulate the signal.
  • In another regard it might be more reliable because the shorter packet length will allow less time for player movements and obstructions to interfere with the packet.

It may just be one of those things you have to try and see what difference it makes in practice. If it were me for a start I'd write code so the transmitter pulse duration could be easily changed using a few buttons and LCD, and on the receiver end do the same. Then you could also use the LCD to display the numbers of packets received over a known period of time to determine the packet loss percentage at various data rates and under different conditions.

Another idea somewhat "outside the box" is that if you're coding your own protocol then you could add a rolling sequence number to the packet. If you received two packets with consecutive sequence numbers you could assume when in "minigun" mode that it represented say three hits. Of course depending on the length of the sequence number you'd have a certain probability that you'd hit the next sequence number by chance at a later point rather than it being a consecutive hit.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Great answer and good ideas to solve the problem. Accepted answer candidate. Thanks! \$\endgroup\$ – K.L. Apr 17 '14 at 11:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.