LTAR TRRS Protocol

[izzy84075]

I'm thinking maybe that third data frame in the 0x20 block is a salt or a nonce for the DRM.

No. 0x20 is unrelated to authentication.

It looks like the 0x20 blocks are in response to 0xC0 and 0xA0. Since it happens every 10 seconds it might be the idevice polling to see if the LTAR is still connected?

Warmer.

[izzy84075]

I just pushed another update to my sigrok-decoders repo. There's now a ltar_smartdevice_decode PD, which decodes the "known" BTypes(Currently only 0x02 TAGGER-STATUS) and checks the checksums of blocks.

EDIT: Just pushed another that breaks down what's known of the TAGGER-STATUS block.

[riley]

I got an iPhone and hacked up a cable so my PC can listen in on the communications.

I've filled in a bit more information about the TAGGER-STATUS block on the wiki:

https://wiki.lazerswarm.com/wiki/Tagger_Status_Block

I think I've got the basics of BType 0x01 figured out. It's a more basic status block. BData0 has flags for reloading (0x08) firing (0x20) and tag received (0x40) and BData1 is the same as BData1 in TAGGER-STATUS.

[riley]

I'm thinking BType 0x50 is a negative acknowledgement. BData0 is the BType of the block that had an error and BData1 is the error flags. 0x01 is something like invalid argument and 0x04 is something like unexpected block. I get a lot of 0x04 errors when using the Left->Mic loopback to record the tagger without an iPhone attached. I think it's NAKing some of its own blocks because it doesn't expect to hear tagger blocks coming from a device. Then it NAKs the 0x50 blocks too. Luckily it's smart enough not to get stuck in a loop doing that.

[izzy84075]

I've filled in a bit more information about the TAGGER-STATUS block on the wiki:

https://wiki.lazerswarm.com/wiki/Tagger_Status_Block

BData1 bit 5 is a bit more complicated than hunting/being hunted. Who's hunting who is a function of current game time and how many teams are in the game and which team you're on. I forget the exact sequence, but this bit changes every so often and changes which teams are hunting which other team.

I think I've got the basics of BType 0x01 figured out. It's a more basic status block. BData0 has flags for reloading (0x08) firing (0x20) and tag received (0x40) and BData1 is the same as BData1 in TAGGER-STATUS.

Pretty much everything there is correct, yeah. Nitpick-y differences, but for most purposes correct. BType 0x01 is PRIORITY-UPDATE.

I'm thinking BType 0x50 is a negative acknowledgement. BData0 is the BType of the block that had an error and BData1 is the error flags. 0x01 is something like invalid argument and 0x04 is something like unexpected block. I get a lot of 0x04 errors when using the Left->Mic loopback to record the tagger without an iPhone attached. I think it's NAKing some of its own blocks because it doesn't expect to hear tagger blocks coming from a device. Then it NAKs the 0x50 blocks too. Luckily it's smart enough not to get stuck in a loop doing that.

Halfway. It's a generic acknowledgement, positive or negative depending on BData1. I had never actually noticed that it would generate these in response to it's own blocks, haha. Keep poking at this one, though.

[izzy84075]

Yeah, it's similar to what's on the LTAR display.

The circuit is something similar to this one, though I'm pretty sure this one is better than what I had figured out back then.

The input from the iPod/LTAR goes in where the 40Hz source is in that, and the output from the op-amp is your input to whatever you're capturing with. Puts out nice clean square waves, as you can see on the left trace on the bottom.

I just tested this circuit, by the way. Works great! My cheap logic analyzer should be here anytime, and then I'll get some nice clean captures for you guys.

EDIT: Man, captures are much smaller when they're digital data instead of analog. Still putting new captures at https://drive.google.com/drive/folders/ ... sp=sharing, the latest being the "loopback" one. I've got two of those op-amp circuits, one on each TX and RX, and am capturing the outputs with the cheap LA set to 50KHz. In this case, though, I've got the TX and RX lines bridged together, so both outputs are pretty much the same(Though I just noticed that I grabbed the wrong resistor for one part, which explains the difference between the two outputs. D1 is the correct channel.). There's a /ton/ of the 0x50 blocks in there, which I had never noticed existing before, haha.

EDIT 2: Pushed another decoder update. Had a couple typos in the code that were causing it to error. Also added a few more block names.

EDIT 3: Hrm. Having the iPod connected is making capturing more problematic, still. It works fine with just the LTAR with a loopback, but once I connect the iPod, the LTAR TX gets... muddled.

[izzy84075]

Oh, duh. It would help to actually follow the schematic... All of the resistors I had grabbed were off by a power of 10(Brown black /yellow/, not brown black orange...). Now it takes a bit to stabilize(Mostly because of voltage spikes as things power up), but it does work. There's a new capture in there that is ltar-ipod-SoloMultiplayerGame-fire-endgame.sr, and it decodes with both sides. Still missing the beginning of the conversation between the iPod/LTAR, but it's way closer than it was before!

EDIT: Oh, and the input capacitor needs to be changed to a 47uF one. Forgot about that.

[riley]

I'm making a lot of progress now. I'm filling in stuff on the wiki as I go.

https://wiki.lazerswarm.com/wiki/Smart_Device_Protocol

I've also found the authentication method. It's a 16-bit challenge/response. I haven't figured out how to generate the correct responses yet.

[riley]

I've figured out how to generate the correct responses for the authentication method!

https://wiki.lazerswarm.com/wiki/Challe ... onse_Block

[neuron]

RIght on Riley! You've done a great job! The wiki layout of the data blocks is much easier to understand than on the forum. Nice work