Protocol

[Charles Yarnold]

Hi all,

I'm starting to thrash out a proposed protocol from the bits I like from the miles tag protocol.

My current musings are on if we have different protocols for ir and i2c (this includes all non ir comms, e.g. bt) or try to use the same. Thoughts?

The main part of the miles tag protocol I dislike is the lack of response to commands, i.e.

Currently ammo can be given, but not checked if it is received, this would mean ammo from a crate could be lost.

I would suggest making a player shoot the ammo box, the ammo box replies with a data packet including the player id, the gun responds with the same packet with parity. This means the ammo box knows that the ammo has been received and can reliably remove a clip from its inventory.

Sol

[Charles Yarnold]

Also, how much data do we want to retain?

Currently miles tag tells you you have been hit by a grenade, I would like to record who it was who activated the grenade prior to it hitting me, it looks like we need to expand from 2 bytes of ir messages to 3 (ooh the extravagance!)

Also I have lost 2 team IDs to allow for 2 NPC team ids, allowing for automated turrets etc.

I'm currently thrashing out an ir protocol at http://wiki.hackspace.org.uk/wiki/User:Solexious/Open_Laser_Tag/Protocol

Sol

[Will Pearson]

On 23 May 2011 00:57, Charles Yarnold <charles...@gmail.com> wrote:
> Also, how much data do we want to retain?
> Currently miles tag tells you you have been hit by a grenade, I would like
> to record who it was who activated the grenade prior to it hitting me, it
> looks like we need to expand from 2 bytes of ir messages to 3 (ooh
> the extravagance!)
> Also I have lost 2 team IDs to allow for 2 NPC team ids, allowing for
> automated turrets etc.
> I'm currently thrashing out an ir protocol
> at http://wiki.hackspace.org.uk/wiki/User:Solexious/Open_Laser_Tag/Protocol

I approve of retaining player data.

A few questions:

How small does the packet need to be? I know the smaller the better.
But what are the error rates? Can we use error correcting codes,
rather than just parity detection to improve things?
Would a gameid be useful, so that multiple games can be run in tight
confines? Or help prevent shenanigans.
Would it be worth it being variable length. if we want to expand (have
an "additional length" count at the start)?
Will we want more than 8 types of gun/damage?

Will

[tomwj]

Given that we can only detect single bit errors do we know how reliable the transmission is? This might be something to leave open or design in flexibility until the final design for the sender and receiver is confirmed and can be tested.

The constraints seem about right to me

• 5 Teams
• 32 Players
• 7 Weapons

I've been thinking about the way to deal with ammo collection and I think triggering it with [ MyID; weapon; parity ] and the response [MyID; Noweapon; ItsID; info] could be quite nice as it saves having to switch to a pickup mode while playing. I have been thinking about the complications of having variable packet sizes and I can't quite see how they would be dealt with other than just having what would amount to a larger packet, unless it is possible to operate on the packet as a bit stream. With this in mind it may be better to fit the protocol into 2bytes. This would take longer but I think the extra-time would be acceptable given that you are picking up ammo or other interaction.

[Charles Yarnold]

I guess error rates is something we need to test, all I can say is that with large games, the milestag protocol works. Not every shot needs to be received correctly as these are counted as "near misses".

I was going to use odd/even parity as part of the protocol, but it doesn't seem needed, this means, as with miles tag, one game could use even, one could use odd.

I agree 8 types of both feels limiting, i'm trying to work out how to fit a good numbr of weapons and damage amounts into one byte.

Sol

[Charles Yarnold]

The only main draw back to how I have it now, is that the last 3 types of weapon would need to be reserved to prevent a packet being made that could also look like a bullet from the player using that weapon when replying to a NPC.

I was thinking along the lines of the "use" button found in most fps' on the gun that would send out a bullet packet using the no weapon ID.

Sol 

[Mark Steward]

On Mon, May 23, 2011 at 12:28 AM, Charles Yarnold <charles...@gmail.com> wrote:

Hi all,

I'm starting to thrash out a proposed protocol from the bits I like from the miles tag protocol.

My current musings are on if we have different protocols for ir and i2c (this includes all non ir comms, e.g. bt) or try to use the same. Thoughts?

Yeah, I think they should be separate.  IR is a different speed and I imagine would have different reliability/retry behaviour to the i2c bus.  Also, in the future you might want to keep the equipment IR-compatible, while upgrading the internal bus to something more sophisticated.

Mark

[tom]

> large games, the milestag protocol works. Not every shot needs to
> be received correctly as these are counted as "near misses".

i guess its at which point the near misses start becoming frequent
enough to not be fun.

Would 3bytes take much longer than 2 to transmit?

[Charles Yarnold]

Sadly I agree, would have been nice to just flip a bit to have the message broadcast over ir!

[Sam Cook]

I was thinking along the lines of the "use" button found in most fps' on the gun that would send out a bullet packet using the no weapon ID.

I think this will have to be the solution; it also means that you don't accidentally pick up ammo etc when in fact you're trying to shoot someone. 

Is there anyway we can set up a Rx/Tx stress test to find out what the error rate is? I think I have a USB IR port somewhere that we can use if need be. 

Also are you planning on keeping the miletag 'header'? 

S

[tom wyatt]

I've got ir transmitter receiver pairs in my box

[Sam Cook]

Excellent, if we can leave them running for an hour just doing Tx/Rx over a reasonable distance (20m?) and do an error count it should give us an idea of how much error checking/correct we need. 

S

[Charles Yarnold]

Sounds like a good idea to me. could use an arduino as a test receiver.

I had planned to keep the headers but halved the timing used in miles tag.

Sol

Sent from my Android, please excuse typos and spelling errors.

On May 23, 2011 3:07 PM, "Sam Cook" <sam.lind...@gmail.com> wrote:

> I was thinking along the lines of the "use" button found in most fps' on the gun that would send o...

[tom wyatt]

Are we using 38khz?

[Sam Cook]

I would suggest keeping the full length leading tag as it is a unique signal so means you won't accidentally try receiving from the middle of a message.

S

[Charles Yarnold]

Pretty sure that's what I have,

Sent from my Android, please excuse typos and spelling errors.

On May 23, 2011 3:30 PM, "tom wyatt" <bollo...@gmail.com> wrote:

Are we using 38khz?

On 23 May 2011 15:22, "Charles Yarnold" <charles...@gmail.com> wrote: > Sounds like a good ide...

[tom wyatt]

Awesome i have 4 of those.

[Charles Yarnold]

I was thinking of 1/2ing all of the timing used, so this should keep the header unique, but it will need testing!  

[Charles Yarnold]

Cool, I have a bread boarded sender and receiver, will get em shooting each other to stress test tomorrow moring!

[Nigel Worsley]

> Cool, I have a bread boarded sender and receiver, will get em shooting
> each other to stress test tomorrow moring!

At some point it needs to be tested in high ambient light environments
(outdoors in the sun) and with haze in the air. Immunity to strobe
lights etc. would be good too.

I suspect that in good conditions the error rate will be negligible,
with a rapid increase to very high levels as the range hits the limit.

It may be possible for the decoding algorithm to incorporate a signal
quality detector that rejects signals with too much timing distorsion.

Nigle

[Sam Cook]

We should do some side by side comparison tests to see how much halving the signal times affects the error rate (if it does at all)

high ambient lighting sounds like a good check as well

S

[Charles Yarnold]

I tested it today, with both low light, and under (an quite close to) the strip lighting in the main room.

Had a few ghost near miss packets under strip lighting while not sending bullets to the receiver, but not more than a couple over 5 mins, and no packet loss or degradation for 10m range in both conditions (the range of unfocused single ir led packet sending is 12m). Testing was for 20 mins each time and with a 30ms gap between bullets.

So from my point of view it works.

Sol

[Mark Steward]

On Tue, May 24, 2011 at 11:59 PM, Charles Yarnold <charles...@gmail.com> wrote:

I tested it today, with both low light, and under (an quite close to) the strip lighting in the main room.

Had a few ghost near miss packets under strip lighting while not sending bullets to the receiver, but not more than a couple over 5 mins, and no packet loss or degradation for 10m range in both conditions (the range of unfocused single ir led packet sending is 12m). Testing was for 20 mins each time and with a 30ms gap between bullets.

This is the problem with having such a small signal to correlate. From a quick looking at the MilesTag page, if you're sampling every 600uS, you'll get a spurious header pulse roughly every (rate of noise)^4 symbols.  In other words, a random noise level of 5.7% will give you a fake packet every minute.  And that's assuming noise is random - any bursty noise could easily look like a header pulse, and there's no way to check for errors in the payload.

Honestly, MilesTag was designed by an idiot.

 

So from my point of view it works.

As long as it's easy to change to another protocol at some point in the future, I'm fine with that.

Mark

[tom wyatt]

Why not test one of the tv remote protocols? Theres libraries for nec and rc5 protocols