LTAR TRRS Protocol

[neuron]

No the Block I listed above was taken from an LTAR connected to an iDevice playing using the Nerf/Shoot the Moon software. It was just me connected. I haven't seen the 2nd or 3rd frame change when connected to the iDevice and playing the Nerf game, but I haven't experimented much either. The 2nd and 3rd frames are used in the grab and go games or when the LTAR's are networked though.

This was posted back in March:
Looking at the link you posted the ??? might actually be related to the "Hostile Zone." That's just a guess though. I haven't actually checked.

Code: Select all

                Player /                   Tags                    n = total ammo                         Minutes      Seconds       Check
                 Team                     Health        Magazine   nnnnnnnn     nn            Shield        Left         Left         Sum
0 xxxxxxxx 110 xxxxxxxx 110 xxxxxxxx 110 xxxxxxxx 110 xxxxxxxx 110 xxxxxxxx 110 xxxxxxxx 110 xxxxxxxx 110 xxxxxxxx 110 xxxxxxxx 110 xxxxxxxx 11
0 01000000 110 00010000 110 10000001 110 01010000 110 01010000 110 11111111 110 11111111 110 11110000 110 00000000 110 10000000 110 01001010
               aaabb???     ggss h
aaa - Player number when networked, 000 - 111 is 8 Players
bb   - Team number
??? - Not sure yet ... maybe Game Type
gg - When changing the gun to auto these bits change
ss - Shield bits.  Once shield is used bits change to 01, then eventually bits change to 11 and the shield can no longer be used.
h - LTTO Hunt when the team being hunted changes this bit also changes. Only confirmed as Team 2 Player 1

Magazine - The number of shots, or ammo you have before you need to reload
n - This is the total amount of shots or ammo you have for the whole game.  These bits are set when Reload is limited in network mode.

Thanks for the confirmation and correct way to calculate the checksum!

[neuron]

I can confirm the Team Number is the same bits when using the Nerf Playstore Software.
BlockID: 0x02, Frame 2: bits 4 and 5.
This was expected and is the same when the LTAR is networked with an LTTO or when it's just LTARS's playing in teams.

[neuron]

Game Configuration when connected to an idevice and starting a game.

A 19 Frame block is sent with BlockID = 0x22.

Frame1 = BlockID = 0x22
Frame4 = Initial Health
Frame7 = Initial Shields
Frame14 = Team(Bits 4 & 5) - Possibly same format as Frame2 of BlockID 0x02


Possibly the Initial handshake:
Between 13 - 19 blocks are sent, depending on which device is started first.
The blocks are usually the same values (not the same order), except for 2 or 3.
They are 4 frame blocks
Frame 1 = BlockID = 0x20
Frame2 = 0x00
Frame3 = This is the value that changes each time the gun and idevice connect.
Frame4 = Checksum

Once the handshake is established, these 2 blocks of 4 frames are sent approx. every 10 seconds.
The 0x?? is the data that is different on each connect.

Code: Select all

  0x20      0x22     0x00    Checksum
BlockID    Frame2   Frame3   Frame4

  0x20      0x00     0x??    Checksum
BlockID    Frame2   Frame3   Frame4

[neuron]

LTAR Trigger event Blocks
The Blocks are made up of 4 frames, and there are 2 blocks; I think this might be for press/depress?
These are from the game play, and from the menu selections. I can also confirm these commands are sent in regular play when the gun is not connected to an idevice.


Menu Navigation.

Shield Button on LTAR - Navigate Forward
Reload Button on LTAR - Navigate Reverse
Trigger Button on LTAR - Select

Code: Select all

Reload Press
  0x08      0x20     0x02    Checksum
BlockID    Frame2   Frame3   Frame4

Reload Release
  0x08      0x02     0x00    Checksum
BlockID    Frame2   Frame3   Frame4

Shield Press
  0x08      0x40     0x04    Checksum
BlockID    Frame2   Frame3   Frame4

Shield Release
  0x08      0x04     0x00    Checksum
BlockID    Frame2   Frame3   Frame4

Trigger Press
  0x08      0x80     0x08    Checksum
BlockID    Frame2   Frame3   Frame4

Trigger Release
  0x08      0x08     0x00    Checksum
BlockID    Frame2   Frame3   Frame4

[izzy84075]

Haha, glad to see the burst of enthusiasm. Is the decoder helping?

Also, I just pushed another bugfix. Darn Python doesn't throw errors until I manage to run over all the possible code paths...

Also, I've got a nice long capture in https://drive.google.com/drive/folders/ ... sp=sharing. The .sr files have the data already imported and compressed, so those'll probably be easiest. The .txt file describes most of what I did during the capture, and notes that the AFSK margin needs to be set to 50% for this particular capture.

[neuron]

Yeah, the decoder is great. Some of this I've had sitting around for a while and I just needed to post it. I have an HP 16700 Logic Analyzer. It's a beast, so whenever I wanted to work on this I had to go sit in my hobby room, but at least I didn't have to decode by hand! This decoder makes it so I can do this on my laptop! Today I've mainly been looking at the handshake / preamble.

I think the LTAR announces itself with BlockID: 0x19
0x19 0x20 0x00 0xC6

0x20 0x00 0x?? 0x.. Is the block that's sent approx every 10 seconds and it looks like it's in response to the 0x20 0x22 0x00 0xBD request.

0x20 0x22 0x00 0xBD just happens to be sent multiple times when the iDevice Software and LTAR first start.
It looks like the 0x?? is calculated in a similar way as the checksum is calculated?

I.E.
0x20 0x00 0x95 0x4A
So if I look at the timestamp of the LTAR announcement packet, 0x19 0x20 0x00 0xC6, lets say it's 17500ms.
17500ms - 0x95 = 17351ms (which is nothing)
but if I continue back...
17351ms - 0xFF = 17096ms
Which happens to be right around the end of the second 0x20 0x22 0x00 0xBD block initially sent (The first had errors).

I guess my question is, am I way off here? Things don't seem to be exact but I'm also looking at the ms in pulseview and maybe its not very accurate.
I'll pull your new stuff down. I noticed some random phase errors when the data looked fine, but it didn't mess anything up.

Thanks again!

[izzy84075]

The timestamp is irrelevant.

[izzy84075]

And the second date byte of the 0x20 blocks is not a second checksum.

[neuron]

I wasn't saying it was a checksum, I was trying to figure out if it was calculated in a similar way as the checksum. I.E. counting milliseconds from some point when a packet was sent or confirmed. Good to know I was looking at it from the wrong angle! Thank you.

[izzy84075]

Ah, sorry. Sometimes a bit hard to follow other people's thought processes. But no, it's not related to time at all.