Page 4 of 8
Re: LTAR TRRS Protocol
Posted: Mon Sep 18, 2017 10:10 pm
by 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!
Re: LTAR TRRS Protocol
Posted: Tue Sep 19, 2017 5:33 pm
by 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.
Re: LTAR TRRS Protocol
Posted: Tue Sep 19, 2017 6:34 pm
by 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
Re: LTAR TRRS Protocol
Posted: Tue Sep 19, 2017 7:23 pm
by 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
Re: LTAR TRRS Protocol
Posted: Tue Sep 19, 2017 8:17 pm
by 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.
Re: LTAR TRRS Protocol
Posted: Tue Sep 19, 2017 9:41 pm
by 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!
Re: LTAR TRRS Protocol
Posted: Tue Sep 19, 2017 10:10 pm
by izzy84075
The timestamp is irrelevant.
Re: LTAR TRRS Protocol
Posted: Tue Sep 19, 2017 10:20 pm
by izzy84075
And the second date byte of the 0x20 blocks is not a second checksum.
Re: LTAR TRRS Protocol
Posted: Tue Sep 19, 2017 10:25 pm
by 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.
Re: LTAR TRRS Protocol
Posted: Tue Sep 19, 2017 10:34 pm
by izzy84075
Ah, sorry. Sometimes a bit hard to follow other people's thought processes. But no, it's not related to time at all.