134kHz TI tags on the PM3

edo512 · 2009-07-01 21:57:10

Hi all,

The PM3 host-side client still references commands to read TI tags: unfortunately, this is just a remainder from the Proxmark2, there is no support in the PM3 for this. I exchanged emails with Jonathan Westhues on the subject, and it seems putting support for those tags back in place would not be too difficult, except that the FPGA code needs to be slightly updated.

Unfortunately I do not have any skills around FPGAs and not enough time to get an education on the subject... Would someone be willing to help ?

Below is the feedback of Jonathan on the subject:

That is indeed a vestige of the proxmarkii. I never got around to implementing that for the proxmark3, though the hardware is certainly capable of it.
Some FPGA tweaks would be necessary; basically, you'd have to add a new major mode where you wired the CROSS_LO comparator straight to the processor's synchronous serial port input, and short-circuited the antenna circuit.
To read the tag, you first excite it with a burst of 125 kHz unmodulated carrier, as you would any other tag. But unlike a normal tag, the TI tag does not answer while you're exciting it. Then you kill power, and listen for the response using the CROSS_LO comparator. You can think of that comparator as a 1-bit A/D, sampling at 2 Mbit/s, not synchronized to anything in particular.
The TI tag responds with a frequency-modulated ID, which there is code to demod.
The proxmarkii code follows; you would basically use that, plus the new FPGA mode.
      case CMD_ACQUIRE_RAW_BITS_TI_TYPE:
          OUT_125K_ON();
          OSC_125K_ON(TRUE);
          SpinDelay(50);
          OSC_125K_OFF();
          AcquireTiType();
          DbpString("acquire done (ti)");
          break;


//-----------------------------------------------------------------------------
// Read a TI-type tag. We assume that the tag has already been illuminated,
// and that the exciting signal has been turned off. That means that we just
// acquire the `one-bit DAC' bits from the comparator.
//-----------------------------------------------------------------------------
void AcquireTiType(void)
{
  int i;

  // Set up the synchronous serial port
  PIO_DISABLE = (1<<GPIO_FROM_TIDET);
  PIO_PERIPHERAL_A_SEL = (1<<GPIO_FROM_TIDET);

  SSC_CONTROL = SSC_CONTROL_RESET;
  SSC_CONTROL = SSC_CONTROL_RX_ENABLE | SSC_CONTROL_TX_ENABLE;

  // Sample at 2 Mbit/s, so TI tags are 16.2 vs. 14.9 clocks long
  // 48/2 = 24 MHz clock must be divided by 12
  SSC_CLOCK_DIVISOR = 12;

  SSC_RECEIVE_CLOCK_MODE = SSC_CLOCK_MODE_SELECT(0);
  SSC_RECEIVE_FRAME_MODE = SSC_FRAME_MODE_BITS_IN_WORD(32) |
      SSC_FRAME_MODE_MSB_FIRST;
  SSC_TRANSMIT_CLOCK_MODE = 0;
  SSC_TRANSMIT_FRAME_MODE = 0;

  i = 0;
  for(;;) {
      if(SSC_STATUS & SSC_STATUS_RX_READY) {
          AcquireBuf[i] = SSC_RECEIVE_HOLDING;
          i++; if(i >= 1536) return;
      }
      WDT_HIT();
  }
}

d18c7db · 2009-07-02 00:08:01

I'm all set up to compile FPGA code as I've done changes to it in the past. From what JW said above sounds pretty easy..

Does anyone have any TI tags to actually test this?

Last edited by d18c7db (2009-07-02 00:09:22)

edo512 · 2009-07-02 22:43:25

I have a tag - I was told it's a TI tag - but I was also told I'll have to send it back to its owner at some point, so I can't forward it to you for testing :-(

duran97 · 2009-07-05 04:17:17

I've got a couple of TI tags being sent to me. Once they arrive I can send one down to you.

d18c7db · 2009-07-19 05:50:31

I got a TI tag off duran97 and I've made an initial attempt at the relevant code. The FPGA now has a new passthrough mode where the CROSS_LO is connected to SSP_DIN and the antenna isn't driven by the drivers. The antenna is "shorted" as per JW's comments above in the same way it's shorted when the FPGA is in lo_simulate mode.

The usage is: plot, tiread, tibits and tidemod. At the moment something seems to be happening, the demodulator looks happy but the decoded value doesn't look right. Nevertheless I've commited the code in case someone wants to build upon what I've already started. Remember to flash the FPGA as well as the ARM

A test trace of the TI tag I have can be found under traces/titest.txt

Those interested can get the tag datasheet and the programming guide for R/W tags.

Last edited by d18c7db (2009-07-19 06:02:03)

d18c7db · 2009-07-20 11:59:23

OMG I cracked it

After staring at that capture I was getting of the TI tag, I noticed it looked remarkably like the last 40 bits or so of the expected 128 bit datastream. This means that without any intentional overhead I was losing far too much time switching from one FPGA mode to another.

I went back and changed the passthrough FPGA mode so that now, while staying in that mode, you can switch from modulating the antenna to listening simply by toggling a pin. This new mode allowed me to capture the complete TI tag response, which according to my oscilloscope trace starts transmitting pretty much immediately after the antenna field is switched off (no appreciable delay). The bitstream now matches the expected one from the datasheet.

Adam, you might be keen on this new FPGA passthrough mode too as you wanted a very fast way to switch the modulation on and off? If not, then an alternative mode to do what you want is to do what we do in simulation mode: create a buffer consisting of the on/off field pattern you want and "simulate" this like we do in losimulate.

To use the passthrough mode, use FPGA_CMD_SET_DIVISOR to set the frequency you want to modulate at, then enter FPGA_MAJOR_MODE_LF_PASSTHRU and use the pin GPIO_SSC_DOUT to modulate the antenna (when high) or to listen (when low) to the CROSS_LO via GPIO_SSC_DIN.

I've updated the trace file TITEST.TXT with the new, complete waveform so those without a TI tag can use "load ..\trace\TITEST.TXT" followed by "tidemod" to see the output in the plot window.

What needs to be done next is write code to send commands to the writeable TI tags. Shouldn't be hard at all

XEROEFFECT · 2009-07-20 13:28:04

What makes you people so smart??? is it the food you guys eat... i mean.... i have no idea about this jargon. What do i have to do to get up to speed with you guys??

samy · 2009-07-20 19:49:19

Most of these guys are just really, really, extremely good looking, which always helps.

duran97 · 2009-07-21 00:51:26

And some of us were born on the right side of the Tasman ;-) (Not that I'm claiming to be smart)

TomBu · 2009-07-21 09:44:34

I personally think they all must be hung like a horse because, as every good feminist will tell you, a man's brain hides in his pants.

d18c7db · 2009-07-21 10:00:04

Well I was always a cute baby but now that I've matured, I'm a real lady killah }8-{

adam@algroup.co.uk · 2009-07-22 02:18:38

d18c7db, not only are you one of the cutest little beans I've ever seen, but your FPGA passthrough looks like exactly what I need.... Sweet!

d18c7db · 2009-07-25 12:42:02

I've just commited the tiwrite command. Example usage as follows, used on a real r/w TI tag courtesy of duran97:

>> Started prox, built Jul 25 2009 23:24:34
>> Connected to device
> tireadraw
> tibits
> tidemod
actual data bits start at sample 5831
length 260/238
Info: raw tag bits = 1....1111.1111.11..1111.1.1.11..1...1111..11.1.1...1.11...1..1...1.1..1.1...111.1.1111111....1111.1111.1
Info: Rewriteable TI tag detected.
Info: Tag data = 123456789ABCDEF0
Info: CRC B8A5 is good
> tiwrite 0xfeedbeef 0xdeadfade
#db# Writing the following data to tag:
#db# feedbeef, deadfade, 00004bc8

#db# Now use tibits and tidemod
> tibits
> tidemod
actual data bits start at sample 5851
length 260/238
Info: raw tag bits = 1.1111.11.1.111111.11.1.1.1111.111111.111.11111.11.11.111.1111111...1..1111.1..1..1111111.1111.11.1.1111
Info: Rewriteable TI tag detected.
Info: Tag data = FEEDBEEFDEADFADE
Info: CRC 4BC8 is good

In the near future, the actual demodulation of the tag should (will) be ported to the PM3 so that it can read/write tags without needing the PC.

edo512 · 2009-07-27 16:53:24

I should go on vacation more often, tons of cool improvements while I was away!!

-> I just tried the new TI functions, reading seems to work, though the tags I have contain only this:

proxmark3> tireadraw
> tireadraw
proxmark3> tibits
> tibits
proxmark3> tidemod
> tidemod
actual data bits start at sample 5728
length 260/238
Info: raw tag bits = 11.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1...11.1..1.1....1.11111111.1.1.1.1.1.1.1
Info: Rewriteable TI tag detected.
Info: Tag data = 5555555555555555
Info: CRC 852C is good

But the tiwrite command fails: the red and green LEDs remain on and the proxmark's watchdog kicks in after a while. Any idea?

Ed

d18c7db · 2009-07-28 03:22:40

Yep that's what the tag from duran97 had when I got it. The tiwrite code as commited to the SVN works as I tested it on my PM3 but as I said in another post there seems to be an issue now that the FLASH code size has reached a certain size where I get that weird behaviour.
Your's seems to hang and watchdog resets, mine seemed to not even boot to the point where it's recognized by the USB bus, but then adding a chunk of code (see the DummyDummyDummy() function which is just used as a filler, not actually called from anywhere) then made it work again. I need to track down what's going on there.

edo512 · 2009-07-28 08:54:26

d18c7db wrote:

Yep that's what the tag from duran97 had when I got it. The tiwrite code as commited to the SVN works as I tested it on my PM3 but as I said in another post there seems to be an issue now that the FLASH code size has reached a certain size where I get that weird behaviour.

My osimage.s19 on the latest SVN is 153882 bytes long, what do you have? Related to this, I have not worked out the maximum flash size that is possible on the at91sam7s256, have you ?

d18c7db · 2009-07-28 13:27:17

Should be the full 256Kb as per the datasheet. I don't think we're near the limit at all, the highest address in osimage reaches 0x19497 (or 103575), so not even half full.

PS: My osimage.s19 is only 111kb but I image you're compiling yours under linux where they've turned off thumb mode for some of the code (looking at the Makefile.linux), hence the larger size.

Last edited by d18c7db (2009-07-28 13:33:34)

henryk · 2009-07-28 19:25:41

Note that the size of the S19 file is completely unrelated to the actual code size since the S19 contents are ASCII Hex characters, so it's at least double the size of the payload contents plus some overhead. If you want to see the real size use something like this:

$ arm-elf-size -B obj/osimage.elf 
   text     data      bss      dec      hex  filename
  51260        0    64512   115772    1c43c  obj/osimage.elf

(or use option -A for a more complete but also slightly more confusing report)

This shows that the osimage currently uses 51260 bytes of flash.

In order to get a more complete breakdown, patch the Makefile as follows:

Index: Makefile.linux
===================================================================
--- Makefile.linux  (revision 144)
+++ Makefile.linux  (working copy)
@@ -54,7 +58,7 @@
 
 osimage.s19: $(OBJ) $(OBJFAST) $(OBJCOMMON)
   @echo osimage.s19
-  $(LD) -g -Tldscript -o $(OBJDIR)/osimage.elf $^ $(ARMLIB)/libgcc.a
+  $(LD) -g -Tldscript -o $(OBJDIR)/osimage.elf -Map=osimage.map $^ $(ARMLIB)/libgcc.a
   $(OBJCOPY) -Osrec --srec-forceS3 $(OBJDIR)/osimage.elf osimage.s19
 
 fullimage.s19: $(OBJ) $(OBJFAST) $(OBJCOMMON) $(OBJFAST) $(OBJFPGA)
@@ -94,6 +98,6 @@
   ../../OpenOCD/openocd -c "halt; flash write_image osimage.s19 0x00100000; halt; reset; resume; poll; exit"
 
 clean:
-  rm -f $(OBJDIR)/*.o $(OBJDIR)/*.elf *.s19
+  rm -f $(OBJDIR)/*.o $(OBJDIR)/*.elf *.s19 osimage.map
 
 .PHONY: all clean

(we're using that in OpenPICC)

You can then look into osimage.map and get a detailed report about which functions and non-static variables ended up where and which object file is occupying how much flash.

d18c7db · 2009-07-29 02:20:49

Thans a very good suggestion henry, this sort of information is very useful for an embedded system.

duran97 · 2009-07-29 04:27:52

What situations are TI tags typically used for? While I have a bunch of TI tages, I've not seen TI tags in the wild before.

edo512 · 2009-07-30 13:11:37

duran97 wrote:

What situations are TI tags typically used for? While I have a bunch of TI tages, I've not seen TI tags in the wild before.

Building access control... The tags I have are credit card sized, but thicker - though not as thick as the HID clamshell tacks -

Ed

edo512 · 2009-07-30 16:54:29

... and by the way, the tiwrite command works perfectly in the latest SVN version I compiled this afternoon (r148). There is something fishy in the ARM source (or compile environment?) since there were no changes in the ti-related functions...

Ed

d18c7db · 2009-07-30 22:30:58

Maybe also reducing the size of BugBuf in r145 might have helped. It used to take 64000 bytes (16K DWORDS) leaving about 1.5 Kb for stack and vars. I reduced it to 10K DWORDS leaving now about 25Kb for stack/vars.

I also double checked the flashing process by dumping the FLASH through JTAG and comaring with the .s19 files. It checks out perfectly so I agree, I'll need to perhaps run the code produced by the compiler through a debugger and find out what's going on. Or use a different cross compile environment.

d18c7db · 2009-08-06 09:13:36

Well, I ported the code for demodulating the TI tag on the PM3 itself and it works but it's pig slow, takes 20 seconds to demodulate one tag, mainly because the demodulation function runs about 20 million itterations of some math functions.

I'm not happy with that so I'll have to come up with a super fast algorithm to demod the tag, maybe counting zero crossings or something like the HID code that does it in the blink of an eye... shame really because the simple act of porting the code from windows to the ARM was a real headache since it run fine in windows but failed to produce results on the ARM. 100 reflashes later, turned out to be a data type issue. An int or a char on the windows compiler is by default signed, an int or a char on the ARM compiler is <gasp> unsigned, which was throwing all the math off...

d18c7db · 2009-08-06 14:02:04

OK it's done, I scrapped the old code and rewrote it from scratch using a hugely faster method or counting zero crossings to detect the frequency. This code now detects tags realtime, testers of course needed. Works fine with duran97's r/w tag, someone (Ed?) should test on the readonly tag.

There are only two commands of significance: tiread and tiwrite. These run on the PM3. For clientside demodulation you can still use tidemod but tibits is gone, use hisampless 40000 to pull the buffer across as signed samples. It's slower as the buffer is unpacked and takes 32 times as much space but since tiread does the job on the PM3 fast now, tidemod is only left as a reference/test command.

duran97, do you want the tag back or shall I add it to my collection?

duran97 · 2009-08-06 18:52:34

You can keep the tag. Do you want a read-only one to try?

app_o1 · 2014-03-21 10:58:21

I am working on some old TI tags.
Reading and writing commands are working perfectly well.

However, I am not able to get a waveform to demodulate.
The following commands seem to have been removed :
"tireadraw"
"tibits"

And replaced by
"hisampless" or "hisamples"
"tidemod"

...which I also cannot find.

Last edited by app_o1 (2014-03-21 11:00:00)

Enio · 2014-03-21 11:56:17

Lf read h
Data samples

Wiki is outdated

Last edited by Enio (2014-03-21 11:57:14)

app_o1 · 2014-03-21 12:12:35

I did try that actually. But data plot looks like there is no tag near the antenna. (and it looks nothing like ...\traces\TITEST.TXT that is included in old releases).

I am able to use the ti read command so I don't think there is anything wrong with my antenna.

Last edited by app_o1 (2014-03-21 12:13:22)

app_o1 · 2014-03-21 12:18:42

I am having better result with lf ti read first and then data samples !

Thank you Enio

Last edited by app_o1 (2014-03-21 12:18:55)

app_o1 · 2014-03-21 12:47:30

Now the problem is that it doesn't work on door...

The original tag is read only. The copy is read/write.
Read only tags send a marker code of $7E to the reader while read/write tags send $FE.

Could the reason that it doesn't work on door be that the system is checking for this marker code ?

Last edited by app_o1 (2014-03-21 12:53:58)

asper · 2014-03-21 12:52:49

If the only difference is this one I think you got it.

app_o1 · 2014-03-22 10:10:37

The only TIRIS tag with 0x7E as start byte are the read only or the rw multipage.
Would that work ? As anyone "tried" a copy in the "real world" ?

app_o1 · 2014-04-04 09:31:42

proxmark3> #db# Info: No valid tag detected.

I got some Multipage Read/Write Transponders but they do not seem to be supported by the proxmark and the read command.

Also it looks like the write command is broken.

proxmark3> lf ti write 0xfeedbeef 0xdeadfade
Please specify the data as two hex strings, optionally the CRC as a third

Cex · 2014-04-04 09:52:15

I think you need to specify the hex strings without the 0x

app_o1 · 2014-04-04 11:34:14

It is also giving me the same result

proxmark3> lf ti write 12345678 12345678
Please specify the data as two hex strings, optionally the CRC as a third

Should I go back to an old version (maybe before CDC) ?

Last edited by app_o1 (2014-04-04 11:34:31)

app_o1 · 2014-04-05 07:51:32

I went back the old interface and it works (r500). I did not flash the bootroom. I just flashed fullimage.elf and fpgaimage.elf

proxmark3> lf ti write 0xfeedbeef 0xdeadfade
#db# Writing to tag: feedbeefdeadfade, crc=4bc8
#db# Now use tiread to check

Although it works only for the r/w 64 bit tags. It doesn't work with the Multipage 1360 bit tags.

I have not enough knowledge in coding to implement new options for Multipage tags writing with proxmark...

Last edited by app_o1 (2014-04-05 07:52:40)

app_o1 · 2014-07-24 05:36:39

a TI 134 kHz tag

http://oi57.tinypic.com/1470j8.jpg

iceman · 2015-02-05 23:48:45

@app_o1

There is a fix for the "LF TI WRITE"

https://github.com/Proxmark/proxmark3/c … e4c3788df7

If you could verify that its now working, that would be appreciated. The syntax is without 0x in string, but the values are in HEX.

proxmark3> lf ti write feedbeef decaaffe

app_o1 · 2015-03-31 11:40:34

It works. Thanks.

proxmark3> lf ti read
#db# Info: TI tag is rewriteable
#db# Info: TI tag ident is valid
#db# Info: Tag data: 1234567887654321, crc=796e
#db# Info: CRC is good
proxmark3> lf ti write feedbeef decaaffe
#db# Writing to tag: feedbeefdecaaffe, crc=e434
#db# Now use tiread to check
proxmark3> lf ti read
#db# Info: TI tag is rewriteable
#db# Info: TI tag ident is valid
#db# Info: Tag data: feedbeefdecaaffe, crc=e434
#db# Info: CRC is good
proxmark3>

/armsrc/lfops.c, line 382, needs to be changed to

DbpString("Now use lf ti read to check");

Also, it doesn't say if the "TI tag is rewritable" anymore.

Last edited by app_o1 (2015-03-31 11:55:26)

iceman · 2015-03-31 11:50:05

Where doesn't it say "TI tag is rewriteable"? In your output, I see two lines "TI is rewriteable", both direct after "lf ti read".

Or do you mean it should say that when you issue the "lf ti write" ?

app_o1 · 2015-03-31 11:54:43

I must be blind... Or I need to sleep. Or both.

copper · 2020-05-13 06:01:46

Hi, i have a problem reading theese ti tags too, i hope someone of you reads this and can help me out.
what i need to do is read and write ti lf tags. it states the one i got is r/w, multipage and 17 pages * (8+2) byte/page * 8 bit/byte = 1360 bit in size. The tag looks like a glas tube, 4 mm in diameter and 32 mm in length. i've received my proxmark3 last week and needed to flash the bootrom (there was no bootrom out of the box) and the fullimage as well (there was also no os version plot in the hw version command's output). Having that done i am able to read both of the rfid cards whch are included in the packet. One the lf one it states "T5577" and the hf is a "gen1a 1k s50 uid changeable". my problem is no metter how i orient the ti tag relativ to the lf antenna the "lf ti read" command allways states it coud not find a valid tag. when i use the "lf ti write 11223344 55667788" command, it tells me it wrote something one the tag and i should use "lf ti read" to validate, but this, as i wrote, does not work. i've noticed that there are two switches on the backside of the hf antenna (on the front of the hf antenna there is the lf antenna) with which i can select Q to be 7 or 14, with the second switch one can choose f0 to be 125 kHz or 134 kHz. No matter wich switch position i use, i'm still not able to read this tag. One thing i have though about is the fact that maybe the lf antenna doesnt exite the tag enough, so i have seen in the code that the proxmark exites a tag for 50 ms @ 134,8 kHz, maybe changing the exiting time might fix the problem, but i havn't changed the armsrc yet.

So why one earth am i unable to read this tag, can you please help me finding out the root cause!?

app_o1 · 2020-05-28 08:36:37

Hi,
Sounds like you are working in the dark
Use command "data plot" and you will see the light.
You can load the test trace to see how it is supposed to look like: https://github.com/Proxmark/proxmark3/blob/master/traces/TITEST.TXT
TIRIS

iceman · 2020-05-28 09:20:13

.... well... lf ti is in desperate need for some love. Long time ago when Marshmellow and I where fiddling and refactoring LF*, the TI commands never got attention. Since we didn't have any tags, readers, and the trace collected wasn't a raw signal.

With that said, if you have tags, reader, first of all we would need some fresh samples.

-- normal 125 Khz, 
lf read
data save

-- configure for 134Khz
lf config H
lf read
data save

I pushed a fix for the failing crc calc.

But no, Low Freq TI is not cloneable with a High Freq S50 magic card...

I am curious to see if a TI tag is cloneable to a T55X7 tag. But then we would need the raw signals.

Proxmark3 community

Announcement

#1 2009-07-01 21:57:10

134kHz TI tags on the PM3

#2 2009-07-02 00:08:01

Re: 134kHz TI tags on the PM3

#3 2009-07-02 22:43:25

Re: 134kHz TI tags on the PM3

#4 2009-07-05 04:17:17

Re: 134kHz TI tags on the PM3

#5 2009-07-19 05:50:31

Re: 134kHz TI tags on the PM3

#6 2009-07-20 11:59:23

Re: 134kHz TI tags on the PM3

#7 2009-07-20 13:28:04

Re: 134kHz TI tags on the PM3

#8 2009-07-20 19:49:19

Re: 134kHz TI tags on the PM3

#9 2009-07-21 00:51:26

Re: 134kHz TI tags on the PM3

#10 2009-07-21 09:44:34

Re: 134kHz TI tags on the PM3

#11 2009-07-21 10:00:04

Re: 134kHz TI tags on the PM3

#12 2009-07-22 02:18:38

Re: 134kHz TI tags on the PM3

#13 2009-07-25 12:42:02

Re: 134kHz TI tags on the PM3

#14 2009-07-27 16:53:24

Re: 134kHz TI tags on the PM3

#15 2009-07-28 03:22:40

Re: 134kHz TI tags on the PM3

#16 2009-07-28 08:54:26

Re: 134kHz TI tags on the PM3

#17 2009-07-28 13:27:17

Re: 134kHz TI tags on the PM3

#18 2009-07-28 19:25:41

Re: 134kHz TI tags on the PM3

#19 2009-07-29 02:20:49

Re: 134kHz TI tags on the PM3

#20 2009-07-29 04:27:52

Re: 134kHz TI tags on the PM3

#21 2009-07-30 13:11:37

Re: 134kHz TI tags on the PM3

#22 2009-07-30 16:54:29

Re: 134kHz TI tags on the PM3

#23 2009-07-30 22:30:58

Re: 134kHz TI tags on the PM3

#24 2009-08-06 09:13:36

Re: 134kHz TI tags on the PM3

#25 2009-08-06 14:02:04

Re: 134kHz TI tags on the PM3

#26 2009-08-06 18:52:34

Re: 134kHz TI tags on the PM3

#27 2014-03-21 10:58:21

Re: 134kHz TI tags on the PM3

#28 2014-03-21 11:56:17

Re: 134kHz TI tags on the PM3

#29 2014-03-21 12:12:35

Re: 134kHz TI tags on the PM3

#30 2014-03-21 12:18:42

Re: 134kHz TI tags on the PM3

#31 2014-03-21 12:47:30

Re: 134kHz TI tags on the PM3

#32 2014-03-21 12:52:49

Re: 134kHz TI tags on the PM3

#33 2014-03-22 10:10:37

Re: 134kHz TI tags on the PM3

#34 2014-04-04 09:31:42

Re: 134kHz TI tags on the PM3

#35 2014-04-04 09:52:15

Re: 134kHz TI tags on the PM3

#36 2014-04-04 11:34:14

Re: 134kHz TI tags on the PM3

#37 2014-04-05 07:51:32

Re: 134kHz TI tags on the PM3

#38 2014-07-24 05:36:39

Re: 134kHz TI tags on the PM3

#39 2015-02-05 23:48:45

Re: 134kHz TI tags on the PM3