And yeah, as you figured, the data is sent LSB-first. Which I had actually forgotten when I got to this page and was comparing with my documentation, heh. Keep up the good work!LTAR TRRS Protocol
Re: LTAR TRRS Protocol
Looking good. And yeah, as you figured, the data is sent LSB-first. Which I had actually forgotten when I got to this page and was comparing with my documentation, heh. Keep up the good work!
And yeah, as you figured, the data is sent LSB-first. Which I had actually forgotten when I got to this page and was comparing with my documentation, heh. Keep up the good work!Re: LTAR TRRS Protocol
I'm always glad to hear when Izzy says things are on the right track 
Thanks for chiming in!
Thanks for chiming in!Re: LTAR TRRS Protocol
Here's something that should help, since I know some of the people here don't do the Facebook thing.
Screenshot: https://drive.google.com/file/d/0B5VkyA ... sp=sharing
I bring to you an LTAR datastream protocol decoder for Sigrok! This is as far as I'll be taking it currently, until you guys get farther in figuring out how things work, but this should at least save you guys from having to decode stuff by hand.
As you might see in that screenshot, this is originally an audio capture that I imported, and used Pulseview's convenient Conversion option to get "logic" level output from it. I feed that into an AFSK decoder to get the bits, and then stack an LTAR datastream decoder after that to pick out the data frames and data blocks.
The decoders are available at https://github.com/izzy84075/sigrok-decoders. Download that repository somewhere, and create an environment variable called SIGROKDECODE_DIR pointed at wherever you downloaded it to(The sigrok-decoders folder, not one of the subdirectories). Then go download Pulseview from https://sigrok.org/wiki/Downloads, and start it up.
You can import a WAV file(Though you might need to convert them first, as sigrok only currently does 8-, 16-, and 32- bit PCM WAVs) in the "Open" menu. Once imported, left-click the CH1 tag on the left, and select "to logic via threshold" under Conversion, and set the conversion threshold to 0.0V. After that, add an AFSK decoder by click the button that has a yellow and a green thing on it. Click the AFSK tag on the left, and pick CH1 from the afsk dropdown. You should see it start to process through the samples and get 0 and 1 bits. If you see a lot of errors(One or two here and there is expected, depending on when the recording started), get me a copy of the recording and I'll see what's up. Next, you can click the AFSK tag on the left and choose "Stack Decoder", and pick "LTAR SmartDevice" out of the list. It should then run through and pick out frames and blocks! Scroll through the data, and start poking!
Screenshot: https://drive.google.com/file/d/0B5VkyA ... sp=sharing
I bring to you an LTAR datastream protocol decoder for Sigrok! This is as far as I'll be taking it currently, until you guys get farther in figuring out how things work, but this should at least save you guys from having to decode stuff by hand.
As you might see in that screenshot, this is originally an audio capture that I imported, and used Pulseview's convenient Conversion option to get "logic" level output from it. I feed that into an AFSK decoder to get the bits, and then stack an LTAR datastream decoder after that to pick out the data frames and data blocks.
The decoders are available at https://github.com/izzy84075/sigrok-decoders. Download that repository somewhere, and create an environment variable called SIGROKDECODE_DIR pointed at wherever you downloaded it to(The sigrok-decoders folder, not one of the subdirectories). Then go download Pulseview from https://sigrok.org/wiki/Downloads, and start it up.
You can import a WAV file(Though you might need to convert them first, as sigrok only currently does 8-, 16-, and 32- bit PCM WAVs) in the "Open" menu. Once imported, left-click the CH1 tag on the left, and select "to logic via threshold" under Conversion, and set the conversion threshold to 0.0V. After that, add an AFSK decoder by click the button that has a yellow and a green thing on it. Click the AFSK tag on the left, and pick CH1 from the afsk dropdown. You should see it start to process through the samples and get 0 and 1 bits. If you see a lot of errors(One or two here and there is expected, depending on when the recording started), get me a copy of the recording and I'll see what's up. Next, you can click the AFSK tag on the left and choose "Stack Decoder", and pick "LTAR SmartDevice" out of the list. It should then run through and pick out frames and blocks! Scroll through the data, and start poking!
Re: LTAR TRRS Protocol
Awesome! Thanks Izzy, this will save a heap of decoding time. And thanks for the detailed instructions for use here too. (This is Bryan Larson, by the way).
Re: LTAR TRRS Protocol
Hey this is awesome. Thanks for posting this Ryan!
Re: LTAR TRRS Protocol
You're welcome! I actually had a lot of fun writing those decoders(Thursday was the first day I actually looked at the Sigrok decoder documentation), so I'm glad people think they'll be useful.
There's a couple other decoders in that repo for the LTTO/LTX/LTAR IR stuff, and a work-in-progress one for what I've figured out about the Recoil protocol, too. There's a README in there that says what each can do.
If you guys find any bugs in them, let me know on the github page with a copy of whatever capture you're seeing the error with, and I'll see what I can do about fixing it.
I'll be keeping an eye on your guys' progress, and I'll try to keep up and add things to the LTAR decoder as you guys figure things out.
There's a couple other decoders in that repo for the LTTO/LTX/LTAR IR stuff, and a work-in-progress one for what I've figured out about the Recoil protocol, too. There's a README in there that says what each can do.
If you guys find any bugs in them, let me know on the github page with a copy of whatever capture you're seeing the error with, and I'll see what I can do about fixing it.
I'll be keeping an eye on your guys' progress, and I'll try to keep up and add things to the LTAR decoder as you guys figure things out.
Re: LTAR TRRS Protocol
Also, I'm ordering a cheap USB logic analyzer/oscilloscope from eBay today, and I'll let you guys know how that turns out. Specifically, a https://sigrok.org/wiki/Noname_LHT00SU1. It's supported by sigrok, and should let you capture one direction of the LTAR data stream directly into sigrok, instead of having to use Audacity. Doesn't let you get both sides, sadly, but a multichannel USB oscilloscope thing is more expensive.
Re: LTAR TRRS Protocol
I have confirmed some more stuff when the LTAR is connected to an iDevice.
The minutes and seconds frames, and they count up.
In Ryan's decoder the Block that has 11 frames (Block, 11 frames) is information that is broadcast approx. every second. (This is also the same when not connected to an iDevice)
"I think" the first frame is a command type.
Also the checksum. Sum all the frames (except the CRC frame) and XOR with 0xFF. The last byte should match the checksum.
0x02 + 0x80 + 0x4B + 0x0A + 0xFF + 0xFF + 0x1E + 0x02 = 0x2F5
0x2F5 XOR 0xFF = 0x20A
You only need the lower byte, so 0x0A.
NOTE: Proper way to compute checksum is listed in the post below this one!
The minutes and seconds frames, and they count up.
In Ryan's decoder the Block that has 11 frames (Block, 11 frames) is information that is broadcast approx. every second. (This is also the same when not connected to an iDevice)
"I think" the first frame is a command type.
Also the checksum. Sum all the frames (except the CRC frame) and XOR with 0xFF. The last byte should match the checksum.
0x02 + 0x80 + 0x4B + 0x0A + 0xFF + 0xFF + 0x1E + 0x02 = 0x2F5
0x2F5 XOR 0xFF = 0x20A
You only need the lower byte, so 0x0A.
NOTE: Proper way to compute checksum is listed in the post below this one!
Code: Select all
cmd Health Shield Minutes Seconds Checksum
110 xxxxxxxx 110 xxxxxxxx 110 xxxxxxxx 110 xxxxxxxx 110 xxxxxxxx 110 xxxxxxxx 110 xxxxxxxx 110 xxxxxxxx 110 xxxxxxxx 110 xxxxxxxx 110 xxxxxxxx
45.65 - 110 01000000 110 00000000 110 00000001 110 11010010 110 01010000 110 11111111 110 11111111 110 01111000 110 00000000 110 01000000 110 01010000 11
0x02 0x00 0x80 0x4B 0x0A 0xFF 0xFF 0x1E 0x00 0x02 0x0A
Last edited by neuron on Mon Sep 18, 2017 10:19 pm, edited 2 times in total.
Re: LTAR TRRS Protocol
First frame is block type, yes. That formula for the checksum works, but the way it's actually implemented in the devices is: initialize temp as a uint8 to 0xFF, subtract every frame of the block from temp(including the checksum byte), if temp is 0, checksum passes, otherwise fails.
Also, I've pushed a couple more changes over the course of today. Nothing huge, but I did fix a couple things here and there.
Also, I've pushed a couple more changes over the course of today. Nothing huge, but I did fix a couple things here and there.
Re: LTAR TRRS Protocol
Was this tagger on team 2? If so, the 0x02 would match the Grab & Go - Team 2 special player number.
Are 0x00 and 0x80 maybe flags similar to the BData1 flags in the Extended Status Block of the LTX rail accessory protocol? Do either of them change if the shield is up or when the tagger gets tagged? What if you change the firing mode to full-automatic?
Is 0x0A the remaining mega-tags? Can you even use mega-tags with the app? If so does this number go down when you use them?
Is 0xFF, 0xFF possibly unlimited ammo? I haven't used the app in a long time, can you configure the ammo?
Are 0x00 and 0x80 maybe flags similar to the BData1 flags in the Extended Status Block of the LTX rail accessory protocol? Do either of them change if the shield is up or when the tagger gets tagged? What if you change the firing mode to full-automatic?
Is 0x0A the remaining mega-tags? Can you even use mega-tags with the app? If so does this number go down when you use them?
Is 0xFF, 0xFF possibly unlimited ammo? I haven't used the app in a long time, can you configure the ammo?