proxmark3 gerbers and bill of material

vivat · 2014-03-05 14:54:38

My old working pm3:
R9 49.6K
R10 49.7K
R12 99.1K
R30 6.9M
R11 484K
R31 232K
Do you need another measure?
I replaced MUXEL_HIPKD with MUXEL_HIRAW in ./armsrc/iso14443a.c and recompiled:
http://www.sendspace.com/file/ejjzi0
Can anyone flash and retest?

gaucho · 2014-03-05 15:11:16

piwi wrote:

correct. AMPL_HI (and AMPL_LO) are only used to measure the antenna voltage
cross_hi is not used
MUXSEL_HIPKD is used (at least) by all hf 14a and hf mf commands. Both external reader and external tag signals come via this line.
MUXSEL_HIRAW is not used.

ok, so cross_hi is not used.
what about cross_lo?
Could we make everything by means of PKD inputs and AMPL_ inputs? do we need also CROSS_ inputs?
I'm tring to semplify the schematic and see if the board can be cheaper.

EDIT: CROSS_HI circuit can be removed, RAW circuits can be removed, then I suppose also the relay can be removed, and then all the components around the relay coil can be removed..

Last edited by gaucho (2014-03-05 15:18:29)

vivat · 2014-03-05 15:31:06

I'm tring to semplify the schematic and see if the board can be cheaper.

In pm3lcd MUXSEL_HIRAW and MUXSEL_LORAW paths have been removed. But it has some problems with HF.
CROSS_LO is used for 134 khz TI tags. See functions ReadTItag() and WriteTItag() in ./armsrc/lfops.c.

	// Place FPGA in passthrough mode, in this mode the CROSS_LO line
	// connects to SSP_DIN and the SSP_DOUT logic level controls
	// whether we're modulating the antenna (high)
	// or listening to the antenna (low)

I think that this functions can be rewritten.

piwi · 2014-03-05 16:44:30

Enio wrote:

Thank you, that makes perfect sense. Check the screenshot on post #279, i can snoop some parts (reader part with uid) but it looks quite messed up.

You mean post #245?
All in all your hf 14a sim looks good - not messed up at all (although it seems to be inconsistent - there are some messages about "unknown commands" which don't show up in hf 14a list). Your OpAmp seems to work for reader signals.
Your hf 14a snoop shows meaningful reader commands as well - again an indication that your OpAmp works for reader signals. I am not sure why there are so many "26" (REQA) without any other commands in between them - I suppose that the snoop commands tries to decode tag answers (which doesn't work) and therefore misses some reader commands. At least the timestamps indicate that there should have been some conversation in between.

Enio · 2014-03-05 17:06:20

piwi wrote:

Enio wrote:
Thank you, that makes perfect sense. Check the screenshot on post #279, i can snoop some parts (reader part with uid) but it looks quite messed up.
You mean post #245?
All in all your hf 14a sim looks good - not messed up at all (although it seems to be inconsistent - there are some messages about "unknown commands" which don't show up in hf 14a list). Your OpAmp seems to work for reader signals.
Your hf 14a snoop shows meaningful reader commands as well - again an indication that your OpAmp works for reader signals. I am not sure why there are so many "26" (REQA) without any other commands in between them - I suppose that the snoop commands tries to decode tag answers (which doesn't work) and therefore misses some reader commands. At least the timestamps indicate that there should have been some conversation in between.

Hm yeah. It misses quite alot. Mostly tag. Could wrong R12 add to it? Ill change it this evening.

gaucho · 2014-03-05 17:27:12

Enio wrote:

I dont want to go offtopic, but can someone help me understand how this particulr opamp (lets say in lf path IC6B in scheme) is supposed to work when we apply a square waveform?
I understood that opamp measures difference on + and - input and amplifies this difference to output.
Is this correct:
No signal - Vmid on pin5(+) and pin6(-)
If we add rising edge of square waveform on pin5, we would have delta (Vmid+amplitude pin5 - Vmid pin6) get amplified on output 7.
But then, would Vmid + amplitude quickly rise voltage on pin6 too via R12 and R13 so that pin6 and pin5 after a short period would be on the same level? So difference delta pin5 vs pin6 would fall down to 0 and produce a triangular waveform on pin7. Is this wrong?
I am just not sure how "fast" voltage would adjust in real world. Because if i understand this correct, R12 could have huge impact on signal shape output of opamp.
I'm sorry im new to this, thanks for your help.

you made me come to doubt. I passed at least 2 hours to simulate the circuit on pspice.
Finally i did the test with the same circuit, but using an audio operational amplifier and then of course i had to use a square waveform on the input positive pin with lower frequency (2kHz). The result is the same square waveform, a little bit clipped on the top and on the bottom. no saw waveform.
About the work of an operational amplifier i can't help you since it's passed too much years since i studied them. Use wikipedia, he will explain it very better than us.

Enio · 2014-03-05 19:02:39

gaucho wrote:

Enio wrote:
I dont want to go offtopic, but can someone help me understand how this particulr opamp (lets say in lf path IC6B in scheme) is supposed to work when we apply a square waveform?
I understood that opamp measures difference on + and - input and amplifies this difference to output.
Is this correct:
No signal - Vmid on pin5(+) and pin6(-)
If we add rising edge of square waveform on pin5, we would have delta (Vmid+amplitude pin5 - Vmid pin6) get amplified on output 7.
But then, would Vmid + amplitude quickly rise voltage on pin6 too via R12 and R13 so that pin6 and pin5 after a short period would be on the same level? So difference delta pin5 vs pin6 would fall down to 0 and produce a triangular waveform on pin7. Is this wrong?
I am just not sure how "fast" voltage would adjust in real world. Because if i understand this correct, R12 could have huge impact on signal shape output of opamp.
I'm sorry im new to this, thanks for your help.
you made me come to doubt. I passed at least 2 hours to simulate the circuit on pspice.
Finally i did the test with the same circuit, but using an audio operational amplifier and then of course i had to use a square waveform on the input positive pin with lower frequency (2kHz). The result is the same square waveform, a little bit clipped on the top and on the bottom. no saw waveform.
About the work of an operational amplifier i can't help you since it's passed too much years since i studied them. Use wikipedia, he will explain it very better than us.

Ah i see. I started on spice just before too but couldnt finish - have you tried changing R12 value in simulations? What happens with much higher/lower or without it? Why is R12 needed at all?..

gaucho · 2014-03-05 19:28:22

good question. tomorrow i will try if i will find the time.

Last edited by gaucho (2014-03-05 19:28:35)

vivat · 2014-03-06 04:18:38

gaucho wrote:

Here I am.
I did everything.
Here the results:
-R9 and R10 are 5kohm. ok, no problem, the voltage on op.amp input is Vdd/2.
-the Umid voltage is correct (Vdd/2).
-R30 is correct on my boards. the tester reads about 700Kohm because you are measuring the series of R31 and R11.
-R11 and R31 are also correct. (this case the read values corresponds to expected values cause they have smaller value than R30).
@enio and Benoit: Please measure it with a multimeter without powering the board and let me know the result.
-R12 on my board is 10Kohm like the benoit board. This is a problem. I will replace this resistor on all the boards.
I applied a square waveform (200KHz) to the IC14 pin 5 (AD8052 input) and i verified that the output signal on pin 7 is exactly the same signal but amplified by factor 2 (il i well remember). Anyway i'm sure now that the AD8052 is not fake.
I applied a square waveform (200KHz) to the IC6 pin 5 (MCP6294 input on the LF path) and i verified that the output signal on pin 7 is a triangular waveform. I'm quite sure that this chip is fake. I will also simulate the circuit on a simulation software to be sure that THAT op.amp. circuit have to give a square waveform on the output.
I will start the order of op.amp.

Where from you will order them? Higher price doesn't automatically guarantee that it will be genuine.
MCP6024 in TSSOP-14 package seems to be also compatible replacement. What do you think?

gaucho · 2014-03-06 08:44:48

@vivat,
yes they seems to be compatible,
http://www.microchip.com/wwwproducts/De … ct=MCP6024
http://www.microchip.com/wwwproducts/De … ct=MCP6294
even if the 6294 has higher quality.
I'm ordering NOW the 6294 on mouser or digikey. I'm waiting a reply by mail just to understand which is cheaper between the 2 suppliers.
I'm not sure, but i suppose that the fake component was ordered from
http://item.taobao.com/item.htm?spm=a23 … 8121873147

gaucho · 2014-03-06 08:51:21

Does The fake component affects the LF path?
Assuming that this op.amp. works fine for signals under 10KHz...
Does The signal on the input of the operational amplifier (after the filter) have frequency higher than 10KHz?

vivat · 2014-03-06 11:58:04

gaucho wrote:

Does The fake component affects the LF path?
Assuming that this op.amp. works fine for signals under 10KHz...
Does The signal on the input of the operational amplifier (after the filter) have frequency higher than 10KHz?

To answer that question, you can make another measurements from TP1 with scope and some LF commands. What LF tags do you have?
@everybody

gaucho wrote:

i suppose that the fake component was ordered from
http://item.taobao.com/item.htm?spm=a230r.1.14.21.OPX5ah&id=18121873147

We must warn possible buyers of this fake components by leaving negative feedback.

vivat · 2014-03-06 15:09:15

pm3lcd have an AD8052 or AD8062 opamp. This part parameters different from our MCP6294. Maybe that is the reason why pm3lcd is not working with HF properly.

Enio · 2014-03-06 15:19:28

vivat wrote:

I replaced MUXEL_HIPKD with MUXEL_HIRAW in ./armsrc/iso14443a.c and recompiled:
http://www.sendspace.com/file/ejjzi0
Can anyone flash and retest?

I did, no change in hf 14a reader - couldnt select tag.

I replaced r12 with 100k, still same on r848 - couldnt select tag.
I replaced my r30 with 10M - seems i get good readings out of hw tune for LF now, my antennas are bad though, ill try to build a good one now.

Edit: Got my LF antenna to a functional state i guess. I only got a hitag2 tag to test. When i do a lf hitag reader 2X it receives some tag answer and stops. Its always as following:

#db# Measuring complete, sending report back to host                 
          
# LF antenna: 23,50 V @   125.00 kHz          
# LF antenna: 18,93 V @   134.00 kHz          
# LF optimal: 24,04 V @   126,32 kHz          
# HF antenna: 11,05 V @    13.56 MHz          
proxmark3> 



proxmark3> lf hitag reader 21
#db# Starting Hitag reader family                 
#db# List identifier in password mode                 
#db# Configured for hitag2 reader                 
#db# Uknown frame length: 2                 
#db# frame received: 2                 
#db# All done                 
proxmark3> lf hitag list
recorded activity:          
 ETU     :nbits: who bytes          
---------+-----+----+-----------          
 +      0:    5:     c0             
 +      0:    2: TAG 40             
proxmark3>

Edit2: [Deleted stuff] Nvm. im not sure now which version it partly worked apart of 848 with corrupted results.

Last edited by Enio (2014-03-06 16:20:50)

gaucho · 2014-03-06 17:00:00

just for exercise i modified the board shematic, to see if i can do it cheaper.
You find it here: proxmark3.1.pdf
Here what i did:
-replaced miniusb with the new microusb.
-added jumper to connect a 5V battery
-removed Q2 and R58 on the first sheet (on my boards they are not used since R58 is zero ohms.
-removed all test points
-removed from sheet2 the cross_lo and cross_hi resistors
-removed the FPGA header (never used)
-replaced the big connector SV3 and replaced with a small 5 pin header (i used the same 6 pin header named SV5
-removed all DNP components
-removed C8 (it was only 1nF and it's in parallel with a 4,7uF capacitor C9!!)
-replaced the big button with a smaller one
-removed LO_RAW path and HI_RAW path
-removed CROSS_LO path and CROSS_HI path
-removed the big RELAY (no more used if we don't use RAW paths
-removed the zero ohm resistors and replaced with shorts
-removed IC11 (the mux) and replaced with a 3 pin jumpers. when you want to switch from HI antenna to low antenna you do it manually because it's a different mission, and you don't need to do it automatically
-removed C45 from sheet4 cause it's in parallel with C10 (and i replaced C10 with a 200nF capacitor)
-removed the strange and horrible Hirose connector from the antenna and replaced with 2 headers (2 pin header for each antenna)

-the idea is to do the board a little bit bigger, if needed, with only 2 layers.
-the difference between other experiments is that i maintain the same component's location if possible, and I maintain the same circuit designed by J.Westhues (apart removing components)

Last edited by gaucho (2014-03-06 17:00:44)

0xFFFF · 2014-03-06 21:48:28

You might want to consider:

Placing a Liion charger before the battery header
Placing mounting holes in a reasonable location
Adjust the PCB size for a specific enclosure (perhaps one that fits a battery and antenna?)

gaucho · 2014-03-06 22:35:43

@0xFFFF: thank you for you hints.
I've seen that the board schematic has been updated today on the google code space, even if there is no change log, so it's impossible to know what changed. (without passing 20 minutes on schematics)

p.s.:op.amp. ordered on digikey. i suppose they will arrive within 48 hours.

vivat · 2014-03-07 05:27:20

gaucho
-added jumper to connect a 5V battery
Jumer is a bad choice, you can place battery charger IC instead(see pm3lcd)
-removed all test points
That is bad because it's so hard to take measurements from SMD and QFP parts without good micro-SMD grabbers. Proxmark is open hardware project, so in order to make it more hackable we need to keep TPs.
-removed the FPGA header (never used)
AFAIK this is header is used for FPGA debugging with Xilinx cable. Maybe it can be useful for someone who have this cable, but I prefer oscilloscope and logic analyzer instead of the cable. I would also remove it.
-replaced the big connector SV3 and replaced with a small 5 pin header (i used the same 6 pin header named SV5
That's good.
-removed the big RELAY (no more used if we don't use RAW paths
-removed IC11 (the mux) and replaced with a 3 pin jumpers. when you want to switch from HI antenna to low antenna you do it manually because it's a different mission, and you don't need to do it automatically
That's not very good because the board should switch automatically by FPGA or ARM software. User should only touch the board when he needs to reset it. It's simple usability(TV as an example):

-removed the strange and horrible Hirose connector from the antenna and replaced with 2 headers (2 pin header for each antenna)
Maybe better option will be 50-ohm BNC?
-the idea is to do the board a little bit bigger, if needed, with only 2 layers.
Bigger board=more $.
-the difference between other experiments is that i maintain the same component's location if possible, and I maintain the same circuit designed by J.Westhues (apart removing components)

Have you looked at bizongod's mod, radiowar's changes(his changes just "cosmetic") and pm3lcd?
Also have a look at NSA's hardware/software exploits. I' m interested in JUNI0RMINT implantable hardware with 400 mhz ARM9, Virtex4/5 and 128 megs DDR2:
http://leaksource.info/2013/12/30/nsas-ant-division-catalog-of-exploits-for-nearly-every-major-software-hardware-firmware/
Enio
That's strange. Can you retry with my firmware and new antennas?

0xFFFF · 2014-03-07 05:45:43

vivat wrote:

-removed the strange and horrible Hirose connector from the antenna and replaced with 2 headers (2 pin header for each antenna)
Maybe better option will be 50-ohm BNC?

BNC is enormous. SMA is a better option.

vivat wrote:

Bigger board=more $.

Yes, but 2 layers is MUCH cheaper than 4. I believe the larger PCB size @ 2 layers will be significantly less in this case.
What quantities are we looking at?

gaucho · 2014-03-07 07:41:09

@vivat: i will look at that boards. yesterday i tried but the wiki site is banned inside my workplace.
the purpose is to lower the price and allow more people to buy and use the board. By this way you will have bigger comunity. ok, most of them will be lamers, but within them you will also have contributors.
So all the not needed items should be removed. This is not a version for deep debugging. It is like a "low cost and less functions" version. such product doesn't need test points. May be it's also possible to remove the arm jtag interface, cause i understood that nowadays it's possible, to flash directly with usb, also the bootloader cause it comes preflashed. anyway i was not able to flash the bootloader with the manufacturer tool (may be i misunderstood something).

@0xFFFF: prototyping for 2 layers is really cheap starting from q.ty 10

p.s: you are doing home made antenna with a AWG26 wire without shield, not with a coaxial cable. At these frequencies and at this cable lenght, a SMA or BNC is really too much for this board. the task is:"working board at small price"

p.p.s.:on internet it's easy to find microusb batteries for smartphones ( http://www.amazon.fr/Ramozz-Battery-Eme … sb+battery ). they are really really cheap, even more than this, my friend paid it 3€. may be we could also remove the jumper for battery.
Could we use such batteries? If i uploug the power from the board and then connect the board to the pc, will the board maintain the previously saved data? or it forgots everything? this is a newbye question, i don't know where samples are stored.

EDIT: i found that the arm has a SRAM and a FLASH. the sram is erased when the power is unplugged. is data stored on the flash or on the sram? why we don't use this big space now that we have 512K memory?speed problems?

Last edited by gaucho (2014-03-07 08:34:03)

holiman · 2014-03-07 08:42:20

Great work guys! I haven't been paying much attention to this thread for a while, since I don't feel I can contribute much here, but I really appreciate the work you are doing!

Neuer_User · 2014-03-07 11:17:33

QUOTE: -removed IC11 (the mux) and replaced with a 3 pin jumpers. when you want to switch from HI antenna to low antenna you do it manually because it's a different mission, and you don't need to do it automatically

I disagree. Especially if you want to scan for tags, the software should be able to scan HF and LF tags automatically.

Otherwise, nice development work. :-)

piwi · 2014-03-07 13:12:24

gaucho wrote:

EDIT: i found that the arm has a SRAM and a FLASH. the sram is erased when the power is unplugged. is data stored on the flash or on the sram? why we don't use this big space now that we have 512K memory?speed problems?

I am not sure if I understand what you are looking for. There is the SRAM which is used for temporary data (like the RAM in a PC) and there is the Flash memory which holds the software/firmware including the FPGA configuration (like the BIOS of a PC). If you are looking for some storage resembling a hard disk then the Flash would not be suitable:

You cannot write single bytes but always need to write a whole page. The software would need to take care of that
The Flash is specified for 10.000 write cycles only.
yes, it is slow compared to the SRAM
don't know either how one would fill 512K memory. We currently use approx half of the 256K.

Cex · 2014-03-07 13:49:30

gaucho wrote:

EDIT: i found that the arm has a SRAM and a FLASH. the sram is erased when the power is unplugged. is data stored on the flash or on the sram? why we don't use this big space now that we have 512K memory?speed problems?

To use the 512K of Flash you need to modify the bootloader to handle the two pages the flash is divided into when writing (when reading the memory is flat and there's no need for any other modification).
The only issue is that if you develop code beyond the 256K limit it won't be usable by other users with standard PM3.

gaucho · 2014-03-07 16:05:13

ok, i understood. data obtained from tags are "volatile". you can't unplug the power between a scan and the download of the data.

P.s.: I have one board with different problem from the rest: the fpga seems to don't work. I was tring to understand if fpga is broken or if it's something else:

-"hw tune" command runs but gets zero voltage on antennas.
-LO_PWR is 12MHz (it's the default value on working board, on this board it never changes even if you send the HW tune)
-HI_PWR has no signal (it's the default value on working board, but on this board it never changes even if you send the HW tune)
-"lf read" and "hf 14a read" commands never get answer from proxmark and the client stops.
-the FPGA pin 36(PCK0) is a 12MHz
-the FPGA pin 91 is the correct 13,5MHz oscillator frequency
-the FPGA pin 71(SSP_CLK) is a 12MHz (this is the default value on a working board, but on a working board, after HW TUNE it becomes a zero voltage signal, while on this board it never changes).
-the fpga pin 52(FPGA_INIT) is correct, it's about 3,3 volt
-the fpga pin 22 (TP7) is a correct signal (i compared it with a working board, now i can't remember if it is a 12MHz signal or something else..
-fpga pin 49 (FPGA_DONE) is a 5 volt DC voltage like a working board
-fpga pin 51 (FPGA_NPROGRAM) is a 5 volt DC voltage like a working board

QUESTION: How could i check if the fpga is broken? communication problem with the ARM? do we have some debug feature on the arm?

Last edited by gaucho (2014-03-07 16:08:43)

vivat · 2014-03-07 16:22:50

gaucho wrote:

QUESTION: How could i check if the fpga is broken? communication problem with the ARM? do we have some debug feature on the arm?

First triple-check fpga pins for short circuits. If you can't find them, try to replace the FPGA. I don't know any debug function in FPGA code. I can only send some signal on the FPGA pin which you can see on oscilloscope. In ARM code there is DbpString() debug function in ./bootrom/bootrom.c

benoit37000 · 2014-03-07 17:31:57

gaucho wrote:

ok, i understood. data obtained from tags are "volatile". you can't unplug the power between a scan and the download of the data.
P.s.: I have one board with different problem from the rest: the fpga seems to don't work. I was tring to understand if fpga is broken or if it's something else:
-"hw tune" command runs but gets zero voltage on antennas.
-LO_PWR is 12MHz (it's the default value on working board, on this board it never changes even if you send the HW tune)
-HI_PWR has no signal (it's the default value on working board, but on this board it never changes even if you send the HW tune)
-"lf read" and "hf 14a read" commands never get answer from proxmark and the client stops.
-the FPGA pin 36(PCK0) is a 12MHz
-the FPGA pin 91 is the correct 13,5MHz oscillator frequency
-the FPGA pin 71(SSP_CLK) is a 12MHz (this is the default value on a working board, but on a working board, after HW TUNE it becomes a zero voltage signal, while on this board it never changes).
-the fpga pin 52(FPGA_INIT) is correct, it's about 3,3 volt
-the fpga pin 22 (TP7) is a correct signal (i compared it with a working board, now i can't remember if it is a 12MHz signal or something else..
-fpga pin 49 (FPGA_DONE) is a 5 volt DC voltage like a working board
-fpga pin 51 (FPGA_NPROGRAM) is a 5 volt DC voltage like a working board
QUESTION: How could i check if the fpga is broken? communication problem with the ARM? do we have some debug feature on the arm?

this exactly the problem i have with my board !

HW tune give 0 and no sine wave generated by fpga.

so i tried to burn and burn firmware about 12 times ( between revision 486 672 756 807 834 bootrom os fullimage ...)
still not working.

so Tired i tried starting the proxmark with button pushed ... and guess what now the HW Tune is working ...

-i made a full checking twice of the FGPA an ARM solder OK
-i checked all Capacitors value OK ( the same value as my working proxmark ).
-i checked all resistors value : OK except R12 at 100 KOhm ( R9 and R10 at 10 KOhm also found R57 at 330 Ohm versus 10 Kohm but as R57 is useless because of R58 short )

now i flashed the different firmware with fullimage and bootrom
and the HW tune is still working !!
i am getting crazy i do not undertsand hardware or software problem !!

piwi · 2014-03-07 18:28:14

benoit37000 wrote:

-i checked all resistors value : OK except R12 at 100 KOhm ( R9 and R10 at 10 KOhm also found R57 at 330 Ohm versus 10 Kohm but as R57 is useless because of R58 short )

R58 is not short but non-existent. Nevertheless - the value of R57 shouldn't make a difference - except more current to be provided by the NVDD_ON output of the ARM.
The value of R12 does matter. It determines the cut off frequency of the C12/R12 high pass.

benoit37000 · 2014-03-07 18:44:56

piwi wrote:

benoit37000 wrote:
-i checked all resistors value : OK except R12 at 100 KOhm ( R9 and R10 at 10 KOhm also found R57 at 330 Ohm versus 10 Kohm but as R57 is useless because of R58 short )
R58 is not short but non-existent. Nevertheless - the value of R57 shouldn't make a difference - except more current to be provided by the NVDD_ON output of the ARM.
The value of R12 does matter. It determines the cut off frequency of the C12/R12 high pass.

when i said i check it regard to reality not only schematic check your board you will see a zero Ohm for R58 ...

gaucho · 2014-03-07 19:55:03

R58 is zero ohm on the BOM found on the google code space.
anyway this short is not a problem in my opinion. Infact the Q2 is not mounted (infact it's not present in the BOM) and the FPGA should be powered with delay with the signal FPGA_ON

Last edited by gaucho (2014-03-07 19:56:20)

gaucho · 2014-03-07 20:02:08

benoit37000 wrote:

gaucho wrote:
....I have one board with different problem from the rest: the fpga seems to don't work. ......
this exactly the problem i have with my board !
HW tune give 0 and no sine wave generated by fpga.
so i tried to burn and burn firmware about 12 times ( between revision 486 672 756 807 834 bootrom os fullimage ...)
still not working.
so Tired i tried starting the proxmark with button pushed ... and guess what now the HW Tune is working ...
-i made a full checking twice of the FGPA an ARM solder OK
-i checked all Capacitors value OK ( the same value as my working proxmark ).
-i checked all resistors value : OK except R12 at 100 KOhm ( R9 and R10 at 10 KOhm also found R57 at 330 Ohm versus 10 Kohm but as R57 is useless because of R58 short )
now i flashed the different firmware with fullimage and bootrom
and the HW tune is still working !!
i am getting crazy i do not undertsand hardware or software problem !!

you wrote that you didn't found the HF sine, what about the LF sine. did you checked it before to solve the problem?
I will try your tests, to see if i solve it. ..but i still ordered also an fpga.

did your board "crashed" after sending the commands to read tags? mine yes. it seems that the fpga does nothing.

Last edited by gaucho (2014-03-07 20:04:35)

piwi · 2014-03-07 21:37:27

benoit37000 wrote:

when i said i check it regard to reality not only schematic check your board you will see a zero Ohm for R58 ...

Checked my non-Chinese board and you are right!

vivat · 2014-03-08 08:19:19

benoit37000 wrote:

gaucho wrote:
ok, i understood. data obtained from tags are "volatile". you can't unplug the power between a scan and the download of the data.
P.s.: I have one board with different problem from the rest: the fpga seems to don't work. I was tring to understand if fpga is broken or if it's something else:
-"hw tune" command runs but gets zero voltage on antennas.
-LO_PWR is 12MHz (it's the default value on working board, on this board it never changes even if you send the HW tune)
-HI_PWR has no signal (it's the default value on working board, but on this board it never changes even if you send the HW tune)
-"lf read" and "hf 14a read" commands never get answer from proxmark and the client stops.
-the FPGA pin 36(PCK0) is a 12MHz
-the FPGA pin 91 is the correct 13,5MHz oscillator frequency
-the FPGA pin 71(SSP_CLK) is a 12MHz (this is the default value on a working board, but on a working board, after HW TUNE it becomes a zero voltage signal, while on this board it never changes).
-the fpga pin 52(FPGA_INIT) is correct, it's about 3,3 volt
-the fpga pin 22 (TP7) is a correct signal (i compared it with a working board, now i can't remember if it is a 12MHz signal or something else..
-fpga pin 49 (FPGA_DONE) is a 5 volt DC voltage like a working board
-fpga pin 51 (FPGA_NPROGRAM) is a 5 volt DC voltage like a working board
QUESTION: How could i check if the fpga is broken? communication problem with the ARM? do we have some debug feature on the arm?

this exactly the problem i have with my board !
HW tune give 0 and no sine wave generated by fpga.
so i tried to burn and burn firmware about 12 times ( between revision 486 672 756 807 834 bootrom os fullimage ...)
still not working.
so Tired i tried starting the proxmark with button pushed ... and guess what now the HW Tune is working ...
-i made a full checking twice of the FGPA an ARM solder OK
-i checked all Capacitors value OK ( the same value as my working proxmark ).
-i checked all resistors value : OK except R12 at 100 KOhm ( R9 and R10 at 10 KOhm also found R57 at 330 Ohm versus 10 Kohm but as R57 is useless because of R58 short )
now i flashed the different firmware with fullimage and bootrom
and the HW tune is still working !!
i am getting crazy i do not undertsand hardware or software problem !!

I found this in Xilinx Spartan II datasheet:

CRC Error Checking
During the loading of configuration data, a CRC value embedded in the configuration file is checked against a CRC value calculated within the FPGA. If the CRC values do not match, the FPGA drives INIT Low to indicate that a frame error has occurred and configuration is aborted. To reconfigure the device, the PROGRAM pin should be asserted to reset the configuration logic. Recycling power also resets the FPGA for configuration. See "Clearing Configuration Memory".

According the datasheet, pin 52 is INIT signal(see page 74). Can you guys make measurements from this pin when you plug the pm3 to USB?

Last edited by vivat (2014-03-08 12:28:03)

gaucho · 2014-03-09 19:41:46

Dear Vivat, thank you for your contribute,
Pin 52, as you can see on the schematic, is connected to the arm and it has a pullup resistor to power supply.
when the fpga shorts it to ground internally to the fpga, the arm will read a logic zero, otherwise it's normally setted to logic 1 thanks to the pullup resistor.
I checked it, as you wrote on my previous post, and it was 3,3Volt but I will recheck it with oscilloscope in order to check if this bit moves while i launch the commands.

My fear is that the fpga is not generating signals due to the lack of some signal coming from the arm.
cause next days I will replace the fpga but the source of the problem could also be the arm!!
There are a lot of signals between arm and fpga. which are the needed signals for the fpga to start the generation of the HF TUNE square waveform?

vivat · 2014-03-10 10:36:41

./armsrc/appmain.c:

void MeasureAntennaTuningHf(void)
{
	int vHf = 0;	// in mV

	DbpString("Measuring HF antenna, press button to exit");

	for (;;) {
		// Let the FPGA drive the high-frequency antenna around 13.56 MHz.
		FpgaWriteConfWord(FPGA_MAJOR_MODE_HF_READER_RX_XCORR);
		SpinDelay(20);//wait some time before antenna resonates
		// Vref = 3300mV, and an 10:1 voltage divider on the input
		// can measure voltages up to 33000 mV
		vHf = (33000 * AvgAdc(ADC_CHAN_HF)) >> 10;//Read ARM's internal ADC channel and caluulate the voltage

		Dbprintf("%d mV",vHf);//Send the results to client
		if (BUTTON_PRESS()) break;//Until button pressed
	}
	DbpString("cancelled");
}

./fpga/hi_read_rx_xcorr.v

assign pwr_hi = ck_1356megb & (~snoop);//generates 13.56 mhz signal for hf antenna

How many channels do you have on your oscilloscope?If 4, connect this:
ck_1356meg(FPGA p91)
pwr_hi(FPGA p80)
+3v3(ARM p1)
ampl_hi(ARM p4)
Do you have logic analyzer?

gaucho · 2014-03-10 11:13:25

vivat wrote:

./armsrc/appmain.c:

void MeasureAntennaTuningHf(void)
{
	int vHf = 0;	// in mV

	DbpString("Measuring HF antenna, press button to exit");

	for (;;) {
		// Let the FPGA drive the high-frequency antenna around 13.56 MHz.
		FpgaWriteConfWord(FPGA_MAJOR_MODE_HF_READER_RX_XCORR);
		SpinDelay(20);//wait some time before antenna resonates
		// Vref = 3300mV, and an 10:1 voltage divider on the input
		// can measure voltages up to 33000 mV
		vHf = (33000 * AvgAdc(ADC_CHAN_HF)) >> 10;//Read ARM's internal ADC channel and caluulate the voltage

		Dbprintf("%d mV",vHf);//Send the results to client
		if (BUTTON_PRESS()) break;//Until button pressed
	}
	DbpString("cancelled");
}

./fpga/hi_read_rx_xcorr.v

assign pwr_hi = ck_1356megb & (~snoop);//generates 13.56 mhz signal for hf antenna

How many channels do you have on your oscilloscope?If 4, connect this:
ck_1356meg(FPGA p91)
pwr_hi(FPGA p80)
+3v3(ARM p1)
ampl_hi(ARM p4)
Do you have logic analyzer?

i have everything, but logic analizer is not available on my lab, i have to keep it from another lab.
I'll first measure that 4 signals on scope and i'll post here results.
BUT:
-FPGA pin 91 as you can read on previous post it was still measured by me and the 13,56MHZ is available.
-FPGA pin 80 is never activated by fpga
-it has no sense to measure ARM pin 4 since the FPGA doesn't generate the 13,56MHz

it could be interesting to know what signal activates the function " FpgaWriteConfWord(FPGA_MAJOR_MODE_HF_READER_RX_XCORR); "

see u later.

EDIT:

on armsrc/ fpgaloader.c i found the following:

void FpgaSendCommand(uint16_t cmd, uint16_t v)  {
          SetupSpi(SPI_FPGA_MODE);          
          while ((AT91C_BASE_SPI->SPI_SR & AT91C_SPI_TXEMPTY) == 0);              // wait for the transfer to complete          
          AT91C_BASE_SPI->SPI_TDR = AT91C_SPI_LASTXFER | cmd | v;         // send the data  
}  
//-----------------------------------------------------------------------------  
// Write the FPGA setup word (that determines what mode the logic is in, read  
// vs. clone vs. etc.). This is now a special case of FpgaSendCommand() to  
// avoid changing this function's occurence everywhere in the source code.  
//-----------------------------------------------------------------------------  
void FpgaWriteConfWord(uint8_t v)  {          
    FpgaSendCommand(FPGA_CMD_SET_CONFREG, v);  
}

i suppose that setup function "SetupSpi" controls ARM pins 20,19,9,10.....or pins 28,27,22,21 ?
may be i can check also those signals?

Last edited by gaucho (2014-03-10 11:37:35)

vivat · 2014-03-10 12:16:26

There is two full-duplex interface from ARM to FPGA:

SPI. It's used to setup operating mode, i.e. HF14443a sniffer or LF generic reader transmitter or HF generic receiver. It's like a gearbox in car. You select appropriate gear with it. As you have already posted, it is done by function FpgaWriteConfWord(). In some proxmarks with LCD it is also possible to drive the LCD with SPI. SPI is implemented on ARM pins 28,27,22,21
SSC. It's used to transmit data(batches of logic zeros and logic ones) to/from FPGA. In car terms it delivers the power from engine to the wheels. SSC is on pins 20,19,9,10

Hope you understood me correctly.

gaucho · 2014-03-10 14:45:54

vivat,
it's not clear to me which is the mandatory signals (the first to act) and which is the direction.
I report here the measures that i've done:

FPGA pin 91: it's the 13,56 MHz generated by the oscillator. it's ok.
FPGA pin 80 (PWR_HI) is never generated on the broken board.
ARM pin 1 is a 3,3V, generated by the voltage regulator. it's ok.
FPGA pin 52 (FPGA_INIT) is a DC voltage 3,19Volt.

If I send the command HF TUNE it runs and it reads 0 voltage. In my opinion this is due to the fact that the ARM sets the FPGA but it doesn't request a feedback from the FPGA. For this reason the ARM continues to work, even if the FPGA doesn't generate the square waveform on PWR_HI.

If i send the command HF 14A READ the led D9 powers on and it stay ON for few seconds, then the ARM resets the board, infact also che signal FPGA_ON is controlled to reset the FPGA. also the ARM reboots infact the PC make the sound tipycal of when you unplug and replug the usb cable. In my opinion this happens cause the arm sends the message to fpga but the fpga doesn't give answer. the arm needs the data coming from the fpga, then it waits and then it finally reset the board thinking that the fpga is broken. As you can see on the following measures, i suppose that the request message never arrives to the fpga.. cause the arm pin never sends the required signals.. read following measures now.

Then i analyzed other signals:

PCK0 is a 24MHz signal, 3,2Vpp amplitude. It's ok. This is a screenshot of this signal:

SSP_Dout is a 3,3V when you power the board. When I send the command HF 14A READ, this signal SSP_Dout goes to zero volt on the broken board while on a working board it transmits some pulses. You can see the signal of a working board in the following screenshot:
hf%2014a%20read%20on%20pin%20ssp_dout.jpg

SSP_Din is not present on the broken board, while it is always present on a working board as soon as you hit the command HF READ. this is the screenshot on the working board:

SSP_FRAME is not present on the broken board, while it is always present on a working board as soon as you hit the command HF READ. this is the screenshot on the working board:

SSP_CLK is a 24MHz, 3.4 Vpp amplitude. it's ok.

Who generates the signal SSP_Dout ? i suppose the FPGA...
Who generates the signal SSP_Din and SSP_FRAME? i suppose the ARM...

If I am right, may be broken ARM?

should i watch also NCS, MISO,MOSI,SPCK?

other hypothesis?

Last edited by gaucho (2014-03-10 14:58:20)

vivat · 2014-03-10 16:11:49

It seems that FPGA is fried/damaged/counterfeit. But can you first check +2v5 voltage regulators that feeds the FPGA? Are you sure that FPGA has no short-circuits, bad soldering, dirt? Do you have other issues with this broken board?

FPGA pin 91: it's the 13,56 MHz generated by the oscillator. it's ok.
FPGA pin 80 (PWR_HI) is never generated on the broken board.
ARM pin 1 is a 3,3V, generated by the voltage regulator. it's ok.
FPGA pin 52 (FPGA_INIT) is a DC voltage 3,19Volt.

Can you measure FPGA_INIT on working board?
You didn't understood me correctly. Can you make measurement at the same time, so that all 4 channels of the scope show 4 waveforms from this channels?
ARM seems to work.

Who generates the signal SSP_Dout ? i suppose the FPGA...
Who generates the signal SSP_Din and SSP_FRAME? i suppose the ARM...

In fpga folder there is Verilog modules, you can see that:

    input ssp_dout;//incoming SSP data from ARM
    output ssp_frame, ssp_din, ssp_clk;//outgoing data from us (FPGA) to ARM

should i watch also NCS, MISO,MOSI,SPCK?

Yes, you can watch the data with logic analyzer that supports SPI decoding.

Last edited by vivat (2014-03-10 16:17:35)

gaucho · 2014-03-10 16:50:49

vivat wrote:

It seems that FPGA is fried/damaged/counterfeit. But can you first check +2v5 voltage regulators that feeds the FPGA? Are you sure that FPGA has no short-circuits, bad soldering, dirt? Do you have other issues with this broken board?

i'm quite sure that the board it's ok...
the voltage regulators are also ok.

vivat wrote:

Can you measure FPGA_INIT on working board?
You didn't understood me correctly. Can you make measurement at the same time, so that all 4 channels of the scope show 4 waveforms from this channels?
ARM seems to work.

I compared each measured signal with a working board, this is the reason why at the end of the row i wrote "It's OK".
I can measure that signals together but it has no sense because if you better read what signal I found on each pin you will see that they are static signals. For each pin i tried to send commands and no one of those pins changes its state.

    input ssp_dout;//incoming SSP data from ARM
    output ssp_frame, ssp_din, ssp_clk;//outgoing data from us (FPGA) to ARM

If this is true, the FPGA could be broken.
BUT
who tells the FPGA to start sending data on ssp_frame, ssp_din, ssp_clk ?
on a working board there is no signal on these pins. The data on those pins starts to flow as soon as i send the command HF TUNE.
How the arm tells the fpga to start sending data on this line?

you wrote, on your previous message, that the commands arrive to the FPGA on pins NCS, MISO,MOSI,SPCK.
Could you confirm it?
I will measure those signals tomorrow.

EDIT: if i well understood the serial line NCS,MISO,MOSI,SPCK is this one: http://en.wikipedia.org/wiki/Serial_Per … erface_Bus
Who is master and who is slave? i suppose that the arm is master and the fpga is slave. correct?

Last edited by gaucho (2014-03-10 17:09:34)

Enio · 2014-03-10 19:21:21

Gaucho, have you received the opamps yet? Can you let me know if it works? I will buy them then too, otherwise i wait if i might need more parts, because shipping is so expensive compared to parts price..

vivat · 2014-03-11 04:31:55

if i well understood the serial line NCS,MISO,MOSI,SPCK is this one: http://en.wikipedia.org/wiki/Serial_Per … erface_Bus
Who is master and who is slave? i suppose that the arm is master and the fpga is slave. correct?

Correct:
The FPGA communicates with the ARM through either its SPI port (the ARM
is the master) or its generic synchronous serial port (again, the ARM
is the master).(from ./doc/system.txt)

who tells the FPGA to start sending data on ssp_frame, ssp_din, ssp_clk ?

Nobody. FPGA is final state machine. FPGA isn't a general-purpose CPU. It's architecture different from traditional CPU. For example, FPGA runs all operating modes simultaneously, and input output pins are selected by it's internal logic. It demodulates incoming samples from IC8(ADC) and sends the results to ARM via output pins. Or it modulates signal as fake tag, receiving logic zeros and ones from ARM via input pins. Or it doesn't modulate any signal in sniffer mode, sending the sniffed frames to ARM. Etc, etc.
Which FPGA mode do you want to understand more?

you wrote, on your previous message, that the commands arrive to the FPGA on pins NCS, MISO,MOSI,SPCK.
Could you confirm it?

Yes, you are right. The command to switch/set operating mode from ARM to FPGA arrives via SPI using this pins.
P.S. On Spartan II datasheet I see that FPGA_INIT is inverted. Shouldn't it be zero volt on working board?

piwi · 2014-03-11 12:01:15

More remarks:
The SSP is only controlled by the FPGA. Depending on the mode (sent to the FPGA from the ARM via the SPI port) the FPGA generates ssp_clk and ssp_frame. Data is transferred synchronously to this clock via ssp_in (from FPGA to ARM) and ssp_out (from ARM to FPGA).

When in any of the iso14443a modes the signals on ssp_clk and ssp_frame are
In Sniffer-mode (hf 14a snoop or hf mf sniff): 13,56MHz/8 on ssp_clk.
In any other iso14443a mode: 13,56MHz/16 on ssp_clk.
On ssp_frame there should be a positive pulse every 8 ssp_clk cycles (indicating the start of an 8 Bit transfer).

Didn't have a look at the LF modes yet.

gaucho · 2014-03-11 13:58:33

Enio wrote:

Gaucho, have you received the opamps yet? Can you let me know if it works? I will buy them then too, otherwise i wait if i might need more parts, because shipping is so expensive compared to parts price..

received 10 minutes ago.
give me time to solder

gaucho · 2014-03-11 14:11:56

I feel a little bit stupid in this moment.
I measured the SPCK,MIO,MOSI,NCS signals.
There was the NCS pin unsoldered.
For this reason the FPGA wasn't receiving commands from the arm.
Anyway the good thing is that now we have measures also for those signals.
I report them here for reference.
They are taken from working board:
MISO after HF TUNE
miso%20on%20working%20board%20after%20hf%20tune.jpg
MOSI after HF TUNE (to know the repetition period of this signal, consider the next screenshot with the NCS zoomed out screenshot)
mosi%20on%20working%20board%20after%20hf%20tune.jpg
NCS after HF TUNE (zoomed out, so you can see its repetition period)
ncs%20on%20working%20board%20after%20hf%20tune.jpg
NCS after HF TUNE (zoomed in)

SPCK after HF TUNE (zoomed in, but consider as repetition period the same of NCS)
spck%20on%20working%20board%20after%20hf%20tune3.jpg

Last edited by gaucho (2014-03-11 14:19:23)

vivat · 2014-03-11 16:15:58

I feel a little bit stupid in this moment.
I measured the SPCK,MIO,MOSI,NCS signals.
There was the NCS pin unsoldered.
For this reason the FPGA wasn't receiving commands from the arm.

Good to see that you have found the problem. So, now FPGA is working as it should to do?

Last edited by vivat (2014-03-11 16:16:22)

gaucho · 2014-03-11 20:13:49

yes now it answers to requests and it generates the required square waveform. but i need to check if for performances now.
I replaced the wrong resistor on most of the boards, then i replaced the op-amp. on most of the boards.
tomorrow i'll try to continue but i have also another work to do.

Enio · 2014-03-12 08:10:22

gaucho wrote:

yes now it answers to requests and it generates the required square waveform. but i need to check if for performances now.
I replaced the wrong resistor on most of the boards, then i replaced the op-amp. on most of the boards.
tomorrow i'll try to continue but i have also another work to do.

Cool! A quick test would be just a hf 14a reader on svn rev 839+. Thank you!

gaucho · 2014-03-12 10:41:11

ok, i'm testing the boards.
let's start from the first one:

proxmark3> hw ver
#db# Prox/RFID mark3 RFID instrument                 
#db# bootrom: svn 845 2014-02-19 20:58:33                 
#db# os: svn 845 2014-02-19 20:58:37                 
#db# FPGA image built on 2014/02/19 at 11:41:11                 
uC: AT91SAM7S512 Rev A          
Embedded Processor: ARM7TDMI          
Nonvolatile Program Memory Size: 512K bytes          
Second Nonvolatile Program Memory Size: None          
Internal SRAM Size: 64K bytes          
Architecture Identifier: AT91SAM7Sxx Series          
Nonvolatile Program Memory Type: Embedded Flash Memory          
proxmark3>

HF section:
signal level is ok because, even if the signal is not the best, i read with success a small mifare 1k all the times i do it (i did it 10 times in the next log):

         
proxmark3> # HF antenna:  9.28 V @    13.56 MHz

this is the log while reading the same tag multiple times:

proxmark3> hf 14a read
ATQA : 04 00          
 UID : c4 ea b4 38           
 SAK : 08 [2]          
TYPE : NXP MIFARE CLASSIC 1k | Plus 2k          
proprietary non iso14443a-4 card found, RATS not supported          
proxmark3> 
proxmark3> hf 14a read
ATQA : 04 00          
 UID : c4 ea b4 38           
 SAK : 08 [2]          
TYPE : NXP MIFARE CLASSIC 1k | Plus 2k          
proprietary non iso14443a-4 card found, RATS not supported          
proxmark3> 
proxmark3> hf 14a read
ATQA : 04 00          
 UID : c4 ea b4 38           
 SAK : 08 [2]          
TYPE : NXP MIFARE CLASSIC 1k | Plus 2k          
proprietary non iso14443a-4 card found, RATS not supported          
proxmark3> 
proxmark3> hf 14a read
ATQA : 04 00          
 UID : c4 ea b4 38           
 SAK : 08 [2]          
TYPE : NXP MIFARE CLASSIC 1k | Plus 2k          
proprietary non iso14443a-4 card found, RATS not supported          
proxmark3> 
proxmark3> hf 14a read
ATQA : 04 00          
 UID : c4 ea b4 38           
 SAK : 08 [2]          
TYPE : NXP MIFARE CLASSIC 1k | Plus 2k          
proprietary non iso14443a-4 card found, RATS not supported          
proxmark3> 
proxmark3> hf 14a read
ATQA : 04 00          
 UID : c4 ea b4 38           
 SAK : 08 [2]          
TYPE : NXP MIFARE CLASSIC 1k | Plus 2k          
proprietary non iso14443a-4 card found, RATS not supported          
proxmark3> 
proxmark3> hf 14a read
ATQA : 04 00          
 UID : c4 ea b4 38           
 SAK : 08 [2]          
TYPE : NXP MIFARE CLASSIC 1k | Plus 2k          
proprietary non iso14443a-4 card found, RATS not supported          
proxmark3> 
proxmark3> hf 14a read
ATQA : 04 00          
 UID : c4 ea b4 38           
 SAK : 08 [2]          
TYPE : NXP MIFARE CLASSIC 1k | Plus 2k          
proprietary non iso14443a-4 card found, RATS not supported          
proxmark3> 
proxmark3> hf 14a read
ATQA : 04 00          
 UID : c4 ea b4 38           
 SAK : 08 [2]          
TYPE : NXP MIFARE CLASSIC 1k | Plus 2k          
proprietary non iso14443a-4 card found, RATS not supported          
proxmark3> 
proxmark3> hf 14a read
ATQA : 04 00          
 UID : c4 ea b4 38           
 SAK : 08 [2]          
TYPE : NXP MIFARE CLASSIC 1k | Plus 2k          
proprietary non iso14443a-4 card found, RATS not supported          
proxmark3>

EDIT: using another HF antenna i can get higher voltage:

proxmark3> # HF antenna: 11.76 V @    13.56 MHz

the lf path gives good signal on hw tune, even if my antenna is not the best. see the log:

   
proxmark3> # LF antenna: 25.78 V @   125.00 kHz          
proxmark3> # LF antenna: 25.91 V @   134.00 kHz          
proxmark3> # LF optimal: 25.91 V @   126.32 kHz

i also have a T55X7 125KHz tag with changeable uid, but i never user it, so i don't know how to read it.
Here it is what i did:

proxmark3> lf t55xx readblock 0
Reading block 0          
proxmark3> 
proxmark3> #db# DONE!

I don't know how to better test the LF path.

Here the measures on TP1 after replacing the op.amp, from a zoomed out view, to a zoom on a single bit:
the following tests are only with the command HF 14A READ

bits transmitted by the reader:

bits received from the tag:

single bit:

after hitting a command(i'm not sure if hf or lf command) i also tried to plot the sampled data with the following command, see the result, i'm not able to understand if it is good:

proxmark3> data samples 16000
Reading 16000 samples
Done!
proxmark3> 
proxmark3> data plot
proxmark3>

Last edited by gaucho (2014-03-12 12:04:04)

gaucho · 2014-03-12 11:14:24

NOTE: on the previous post i used the client version 834 .

EDIT: I tried now the client version 845 (like the current uploaded version of the operative system) on the DATA PLOT i get only noise. I can't see the bits. Is it a bug? Is it correct to use different version of client?

EDIT2: i'm going crazy. I tested again the data sample and data plot commands and now i always get noise instead of the expected bits. does this function works fine? why the "hf 14a read" works fine even if the data plot gets noise?

Last edited by gaucho (2014-03-12 12:05:13)

Proxmark3 community

Announcement

#301 2014-03-05 14:54:38

Re: proxmark3 gerbers and bill of material

#302 2014-03-05 15:11:16

Re: proxmark3 gerbers and bill of material

#303 2014-03-05 15:31:06

Re: proxmark3 gerbers and bill of material

#304 2014-03-05 16:44:30

Re: proxmark3 gerbers and bill of material

#305 2014-03-05 17:06:20

Re: proxmark3 gerbers and bill of material

#306 2014-03-05 17:27:12

Re: proxmark3 gerbers and bill of material

#307 2014-03-05 19:02:39

Re: proxmark3 gerbers and bill of material

#308 2014-03-05 19:28:22

Re: proxmark3 gerbers and bill of material

#309 2014-03-06 04:18:38

Re: proxmark3 gerbers and bill of material

#310 2014-03-06 08:44:48

Re: proxmark3 gerbers and bill of material

#311 2014-03-06 08:51:21

Re: proxmark3 gerbers and bill of material

#312 2014-03-06 11:58:04

Re: proxmark3 gerbers and bill of material

#313 2014-03-06 15:09:15

Re: proxmark3 gerbers and bill of material

#314 2014-03-06 15:19:28

Re: proxmark3 gerbers and bill of material

#315 2014-03-06 17:00:00

Re: proxmark3 gerbers and bill of material

#316 2014-03-06 21:48:28

Re: proxmark3 gerbers and bill of material

#317 2014-03-06 22:35:43

Re: proxmark3 gerbers and bill of material

#318 2014-03-07 05:27:20

Re: proxmark3 gerbers and bill of material

#319 2014-03-07 05:45:43

Re: proxmark3 gerbers and bill of material

#320 2014-03-07 07:41:09

Re: proxmark3 gerbers and bill of material

#321 2014-03-07 08:42:20

Re: proxmark3 gerbers and bill of material

#322 2014-03-07 11:17:33

Re: proxmark3 gerbers and bill of material

#323 2014-03-07 13:12:24

Re: proxmark3 gerbers and bill of material

#324 2014-03-07 13:49:30

Re: proxmark3 gerbers and bill of material

#325 2014-03-07 16:05:13

Re: proxmark3 gerbers and bill of material

#326 2014-03-07 16:22:50

Re: proxmark3 gerbers and bill of material

#327 2014-03-07 17:31:57

Re: proxmark3 gerbers and bill of material

#328 2014-03-07 18:28:14

Re: proxmark3 gerbers and bill of material

#329 2014-03-07 18:44:56

Re: proxmark3 gerbers and bill of material

#330 2014-03-07 19:55:03

Re: proxmark3 gerbers and bill of material

#331 2014-03-07 20:02:08

Re: proxmark3 gerbers and bill of material

#332 2014-03-07 21:37:27

Re: proxmark3 gerbers and bill of material

#333 2014-03-08 08:19:19

Re: proxmark3 gerbers and bill of material

#334 2014-03-09 19:41:46

Re: proxmark3 gerbers and bill of material

#335 2014-03-10 10:36:41

Re: proxmark3 gerbers and bill of material

#336 2014-03-10 11:13:25

Re: proxmark3 gerbers and bill of material

#337 2014-03-10 12:16:26

Re: proxmark3 gerbers and bill of material

#338 2014-03-10 14:45:54

Re: proxmark3 gerbers and bill of material

#339 2014-03-10 16:11:49

Re: proxmark3 gerbers and bill of material