diff --git a/README.md b/README.md index 972dfa9f9..27e64810a 100644 --- a/README.md +++ b/README.md @@ -16,19 +16,24 @@ alt="Yuotube" width="100%" height="auto" border="10" /> | FAQ's & Updates | Installation | Use of the Proxmark | | ------------- |:-------------:| -----:| -|[Whats changed?](#whats-changed) | [Setup and build for ArchLinux](/Installation_Instructions/Arch-Linux-Installation-Instructions.md) | [Validating proxmark client functionality](/Use_of_Proxmark/1_Validation.md)| -|[Development](#development) | [Setup and build for UBUNTU](/Installation_Instructions/Ubuntu-Installation-Instructions.md) | [First Use and Verification](/Use_of_Proxmark/2_Configuration-and-Verification.md) | -| [Why don't you add this or that functionality?](#why-dont-you-add-this-or-that-functionality) | [Homebrew (Mac OS X) & Upgrading HomeBrew Tap Forumula](/Installation_Instructions/Mac-OS-X-Homebrew-Installation-Instructions.md) | [Commands & Features](/Use_of_Proxmark/3_Commands-and-Features.md)| -|[Why didn't you based it on offical PM3 Master?](#why-didnt-you-based-it-on-offical-pm3-master) |[ParrotOS Installation ](/Installation_Instructions/Parrot-OS-Proxmark3-RDV4-installation.md)|[PM3 GUI](#pm3-gui) -|[Notices](#notices)|[Setup and build for Windows](/Installation_Instructions/Windows-Installation-Instructions.md)|| -|[Issues](#issues)|[Coverity Scan Config & Run](/Installation_Instructions/Coverity-Scan-Config-%26-Run.md)|| -||[Kali Linux Installation Instructions](/Installation_Instructions/Kali-Installation-Instructions.md)| +|[Whats changed?](#whats-changed) | [Setup and build for ArchLinux](/doc/md/Installation_Instructions/Arch-Linux-Installation-Instructions.md) | [Validating proxmark client functionality](/doc/md/Use_of_Proxmark/1_Validation.md)| +|[Development](#development) | [Setup and build for UBUNTU](/doc/md/Installation_Instructions/Ubuntu-Installation-Instructions.md) | [First Use and Verification](/doc/md/Use_of_Proxmark/2_Configuration-and-Verification.md) | +| [Why don't you add this or that functionality?](#why-dont-you-add-this-or-that-functionality) | [Homebrew (Mac OS X) & Upgrading HomeBrew Tap Forumula](/doc/md/Installation_Instructions/Mac-OS-X-Homebrew-Installation-Instructions.md) | [Commands & Features](/doc/md/Use_of_Proxmark/3_Commands-and-Features.md)| +|[Why didn't you based it on offical PM3 Master?](#why-didnt-you-based-it-on-offical-pm3-master) |[ParrotOS Installation ](/doc/md/Installation_Instructions/Parrot-OS-Proxmark3-RDV4-installation.md)|[PM3 GUI](#pm3-gui) +|[Notices](#notices)|[Setup and build for Windows](/doc/md/Installation_Instructions/Windows-Installation-Instructions.md)|| +|[Issues](#issues)|[Coverity Scan Config & Run](/doc/md/Installation_Instructions/Coverity-Scan-Config-%26-Run.md)|| +||[Kali Linux Installation Instructions](/doc/md/Installation_Instructions/Kali-Installation-Instructions.md)| --- ## Whats changed? - * added flash memory 256kb. - * added smart card module - * added FPC connector + +On the hardware side: + + * added flash memory 256kb. + * added smart card module + * added FPC connector + +On the software side: quite a lot, see the [Changelog file](CHANGELOG.md). ## Development This fork now compiles just fine on diff --git a/Installation_Instructions/Arch-Linux-Installation-Instructions.md b/doc/md/Installation_Instructions/Arch-Linux-Installation-Instructions.md similarity index 100% rename from Installation_Instructions/Arch-Linux-Installation-Instructions.md rename to doc/md/Installation_Instructions/Arch-Linux-Installation-Instructions.md diff --git a/Installation_Instructions/Coverity-Scan-Config-&-Run.md b/doc/md/Installation_Instructions/Coverity-Scan-Config-&-Run.md similarity index 100% rename from Installation_Instructions/Coverity-Scan-Config-&-Run.md rename to doc/md/Installation_Instructions/Coverity-Scan-Config-&-Run.md diff --git a/Installation_Instructions/Kali-Installation-Instructions.md b/doc/md/Installation_Instructions/Kali-Installation-Instructions.md similarity index 100% rename from Installation_Instructions/Kali-Installation-Instructions.md rename to doc/md/Installation_Instructions/Kali-Installation-Instructions.md diff --git a/Installation_Instructions/Mac-OS-X-Homebrew-Installation-Instructions.md b/doc/md/Installation_Instructions/Mac-OS-X-Homebrew-Installation-Instructions.md similarity index 100% rename from Installation_Instructions/Mac-OS-X-Homebrew-Installation-Instructions.md rename to doc/md/Installation_Instructions/Mac-OS-X-Homebrew-Installation-Instructions.md diff --git a/Installation_Instructions/Parrot-OS-Proxmark3-RDV4-installation.md b/doc/md/Installation_Instructions/Parrot-OS-Proxmark3-RDV4-installation.md similarity index 100% rename from Installation_Instructions/Parrot-OS-Proxmark3-RDV4-installation.md rename to doc/md/Installation_Instructions/Parrot-OS-Proxmark3-RDV4-installation.md diff --git a/Installation_Instructions/Ubuntu-Installation-Instructions.md b/doc/md/Installation_Instructions/Ubuntu-Installation-Instructions.md similarity index 100% rename from Installation_Instructions/Ubuntu-Installation-Instructions.md rename to doc/md/Installation_Instructions/Ubuntu-Installation-Instructions.md diff --git a/Installation_Instructions/Windows-Installation-Instructions.md b/doc/md/Installation_Instructions/Windows-Installation-Instructions.md similarity index 100% rename from Installation_Instructions/Windows-Installation-Instructions.md rename to doc/md/Installation_Instructions/Windows-Installation-Instructions.md diff --git a/Use_of_Proxmark/1_Validation.md b/doc/md/Use_of_Proxmark/1_Validation.md similarity index 100% rename from Use_of_Proxmark/1_Validation.md rename to doc/md/Use_of_Proxmark/1_Validation.md diff --git a/Use_of_Proxmark/2_Configuration-and-Verification.md b/doc/md/Use_of_Proxmark/2_Configuration-and-Verification.md similarity index 100% rename from Use_of_Proxmark/2_Configuration-and-Verification.md rename to doc/md/Use_of_Proxmark/2_Configuration-and-Verification.md diff --git a/Use_of_Proxmark/3_Commands-and-Features.md b/doc/md/Use_of_Proxmark/3_Commands-and-Features.md similarity index 100% rename from Use_of_Proxmark/3_Commands-and-Features.md rename to doc/md/Use_of_Proxmark/3_Commands-and-Features.md diff --git a/doc/Compiling Proxmark source and firmware upgrading v1.pdf b/doc/original_proxmark3/Compiling Proxmark source and firmware upgrading v1.pdf similarity index 100% rename from doc/Compiling Proxmark source and firmware upgrading v1.pdf rename to doc/original_proxmark3/Compiling Proxmark source and firmware upgrading v1.pdf diff --git a/doc/Proxmark III - Ubuntu GSG v1.pdf b/doc/original_proxmark3/Proxmark III - Ubuntu GSG v1.pdf similarity index 100% rename from doc/Proxmark III - Ubuntu GSG v1.pdf rename to doc/original_proxmark3/Proxmark III - Ubuntu GSG v1.pdf diff --git a/doc/Proxmark III - Windows 7 GSG v1.pdf b/doc/original_proxmark3/Proxmark III - Windows 7 GSG v1.pdf similarity index 100% rename from doc/Proxmark III - Windows 7 GSG v1.pdf rename to doc/original_proxmark3/Proxmark III - Windows 7 GSG v1.pdf diff --git a/doc/Proxmark III - Windows XP SP3 GSG v1.pdf b/doc/original_proxmark3/Proxmark III - Windows XP SP3 GSG v1.pdf similarity index 100% rename from doc/Proxmark III - Windows XP SP3 GSG v1.pdf rename to doc/original_proxmark3/Proxmark III - Windows XP SP3 GSG v1.pdf diff --git a/doc/RFID_Antenna-Basic-Form.stl b/doc/original_proxmark3/RFID_Antenna-Basic-Form.stl similarity index 100% rename from doc/RFID_Antenna-Basic-Form.stl rename to doc/original_proxmark3/RFID_Antenna-Basic-Form.stl diff --git a/doc/RFID_Antenna-With-Lanyard-Hook.stl b/doc/original_proxmark3/RFID_Antenna-With-Lanyard-Hook.stl similarity index 100% rename from doc/RFID_Antenna-With-Lanyard-Hook.stl rename to doc/original_proxmark3/RFID_Antenna-With-Lanyard-Hook.stl diff --git a/doc/proxmark3.brd b/doc/original_proxmark3/proxmark3.brd similarity index 100% rename from doc/proxmark3.brd rename to doc/original_proxmark3/proxmark3.brd diff --git a/doc/proxmark3.pdf b/doc/original_proxmark3/proxmark3.pdf similarity index 100% rename from doc/proxmark3.pdf rename to doc/original_proxmark3/proxmark3.pdf diff --git a/doc/proxmark3.sch b/doc/original_proxmark3/proxmark3.sch similarity index 100% rename from doc/proxmark3.sch rename to doc/original_proxmark3/proxmark3.sch diff --git a/doc/proxmark3.xls b/doc/original_proxmark3/proxmark3.xls similarity index 100% rename from doc/proxmark3.xls rename to doc/original_proxmark3/proxmark3.xls diff --git a/doc/proxmark3_schema.pdf b/doc/original_proxmark3/proxmark3_schema.pdf similarity index 100% rename from doc/proxmark3_schema.pdf rename to doc/original_proxmark3/proxmark3_schema.pdf diff --git a/doc/system.txt b/doc/original_proxmark3/system.txt similarity index 98% rename from doc/system.txt rename to doc/original_proxmark3/system.txt index a3ae86055..b0d47f1a5 100644 --- a/doc/system.txt +++ b/doc/original_proxmark3/system.txt @@ -1,276 +1,276 @@ - -This is outdated. - ---- - -INTRODUCTION TO THE proxmark3 -============================= - -The proxmark3 device is designed to manipulate RFID tags in a number of -different ways. For example, a proxmark3 can: - - * read a low-frequency (~100 kHz) or high-frequency (13.56 MHz) tag, - including the ISO-standard tags; standards that require - bidirectional communication between the reader and the tag are - not a problem - - * emulate a low- or high-frequency tag, in a way very similar to the - way that a real tag behaves (e.g., it derives its timing from the - incident carrier) - - * eavesdrop on the signals exchanged between another reader and tag - - * measure the resonant frequency of an antenna, to a certain extent - (this is a convenience when building a test setup for the previous - three functions) - -The proxmark3 may be thought of as a direct-sampling software radio. -There is some complication, though, because of the usual dynamic range -issue in dealing with signals in RFID systems (large signal due to -the reader, small signal due to the tag). Some analog processing is -therefore used to fix this before the signal is digitized. (Although, -it is possible to digitize the signal from the antenna directly, with -appropriate population options. It is just not usually a good idea.) - -SYSTEM ARCHITECTURE -=================== - -The ANTENNA sends and receives signals over the air. It is external to -the board; it connects through SV2. Separate pins on the connector are -used for the low- and high-frequency antennas, and the analog receive -paths are separate. The antennas are inductive loops, which are resonated -by on-board capacitors. - -On the transmit side, the antennas are excited by large numbers of -paralleled bus driver buffers. By tri-stating some of the buffers, it -is possible to vary the transmit strength. This may be used to generate -a modulated carrier. The buffers are driven by signals from the FPGA, -as are the output enables. The antennas are excited as series circuits, -which permits a large input power for a relatively small input voltage. - -By driving all of the buffers low, it is possible to make the antenna -look to the receive path like a parallel LC circuit; this provides a -high-voltage output signal. This is typically what will be done when we -are not actively transmitting a carrier (i.e., behaving as a reader). - -On the receive side, there are two possibilities, which are selected by -RLY1. A mechanical relay is used, because the signal from the antenna is -likely to be more positive or negative than the highest or lowest supply -voltages on-board. In the usual case (PEAK-DETECTED mode), the received -signal is peak-detected by an analog circuit, then filtered slightly, -and then digitized by the ADC. This is the case for both the low- and -high-frequency paths, although the details of the circuits for the -two cases are somewhat different. This receive path would typically -be selected when the device is behaving as a reader, or when it is -eavesdropping at close range. - -It is also possible to digitize the signal from the antenna directly (RAW -mode), after passing it through a gain stage. This is more likely to be -useful in reading signals at long range, but the available dynamic range -will be poor, since it is limited by the 8-bit A/D. These modes would be -very appropriate, for example, for the heavily-discussed attacks in which -a tag's ID is learned from the data broadcast by a reader performing an -anticollision loop, because there is no dynamic range problem there. It -would also be possible to program the proxmark3 to receive broadcast AM -radio, with certain changes in component values. - -In either case, an analog signal is digitized by the ADC (IC8), and -from there goes in to the FPGA (IC1). The FPGA is big enough that it -can perform DSP operations itself. For some high-frequency standards, -the subcarriers are fast enough that it would be inconvenient to do all -the math on a general-purpose CPU. The FPGA can therefore correlate for -the desired signal itself, and simply report the total to the ARM. For -low-frequency tags, it probably makes sense just to pass data straight -through to the ARM. - -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). The ARM connects to the outside world over USB. - -DETAILS: POWER DISTRIBUTION -=========================== - -I make a half-hearted attempt to meet the USB power specs; this adds a -bit of complexity. I have not made measurements to determine how close -I come to succeeding, but I think that the suspend current might turn -out to be a pain. - -The +3V3 rail is always powered, whenever we are plugged in to USB. This -is generated by an LDO, which burns a quiescent current of 150 uA -(typical) already. The only thing powered from the +3V3 rail is the ARM, -which can presumably do smart power control when we are in suspend. - -The ARM generates two signals to switch power to the rest of the board: -FPGA_ON, and NVDD_ON. When NVDD_ON goes low, the Vdd rail comes up to -about five volts (the filtered-but-unregulated USB voltage). This powers -most of the analog circuitry, including the ADC and all of the opamps -and comparators in the receive path, and the coil drivers as well. Vdd -also feeds the +3V3-FPGA and +2v5 regulators, which power only the -FPGA. These regulators are enabled by FPGA_ON, so the FPGA is powered -only when NVDD_ON is asserted low, and FPGA_ON is asserted high. - -DETAILS: FPGA -============= - -The FPGA is a Spartan-II. This is a little bit old, but it is widely -available, inexpensive, and five-volt tolerant. For development, the FPGA -is configured over JTAG (SV5). In operation, the FPGA is configured in -slave serial mode by the ARM, from a bitstream stored in the ARM's flash. - -Power to the FPGA is managed by regulators IC13 and IC12, both of which -have shutdown. These generate the FPGA's VCCO (+3v3) and VCCINT (+2v5) -supplies. I am a little bit worried about the power-on surge, since we -run off USB. At the very minimum, the FPGA should not get power until -we have enumerated and requested the full 500 mA available from USB. The -large electrolytic capacitors C37 and C38 will presumably help with this. - -The logic is written in Verilog, of course for webpack. I have structured -the FPGA in terms of `major modes:' the FPGA's `major mode' determines -which of several modules is connected to the FPGA's I/O pins. A separate -module is used for each of the FPGA's function; for example, there is -now a module to read a 125 kHz tag, simulate a 125 kHz tag, transmit to -an ISO 15693 tag, and receive from an ISO 15693 tag. - -DETAILS: ANALOG RECEIVE PATH -============================ - -For `slow' signals, I use an MCP6294 opamp. This has a GBW of 10 MHz, -which is more than enough for the low-frequency stuff, and enough for -all of the subcarrier frequencies that I know of at high frequency. In -practice, the `slow' signals are all the signals following the peak -detector. These signals are usually centred around the generated -voltage Vmid. - -For `fast' signals, I use an AD8052. This is a very fast voltage-feedback -amplifier (~100 MHz GBW). I use it immediately after the antenna for -both the low- and high-frequency cases, as a sort of an ugly LNA. It is -not optimal, but it certainly made the design easy. - -An ordinary CD4066 is used to multiplex the four possible signals -(low/high frequency paths, RAW/PEAK-DETECTED). There is a potential -problem at startup, when the ARM is in reset; there are pull-ups on the -lines that control the mux, so all of the switches turn on. This shorts -the four opamp outputs together through the on-resistance of the switch. -All four outputs float to the same DC voltage with no signal, however, -and the on-resistance of the switches is fairly large, so I don't think -that will be a problem in practice. - -Comparators are used to generate clock signals when the device is -emulating a tag. These clock signals are generated from the signal on the -antenna, and therefore from the signal transmitted by the reader. This -allows us to clock ourselves off the reader, just like a real tag would. -These signals go in to the FPGA. There is a potential problem when the -FPGA is powered down; these outputs might go high and try to power the -FPGA through the protection diodes. My present solution to this is a -couple of resistors, which is not very elegeant. - -The high-frequency peak-detected receive path contains population options -for many features that I do not currently use. A lot of these are just -me guessing that if I provide options for different series and shunt -passives, perhaps it will come in handy in some way. The Zener diodes D10 -and D11 are optional, but may protect the front end from an overvoltage -(which will fry the peak detector diodes) when the `simulated tag' -is read by a powerful reader. - -DETAILS: ANALOG TRANSMIT PATH -============================= - -The coil drivers are just ACT244 bus buffers. I parallel eight of them -for each antenna (eight for the high-frequency antenna, eight for the -low-frequency antenna). This should easily provide a hundred milliamps -coil drive or so, which is more than enough for anything that I imagine -doing with the device. The drivers hit the coil with a square wave -voltage, however, which means that it is only the bandpass filter effect -of a resonant antenna that suppresses the odd harmonics. In practice it -would probably take heroic efforts (high antenna Q) to meet the FCC/CE -harmonic specs; and in practice no one cares. - -The tx strength, given good antenna tuning, is determined by the series -resistors. Choose the ratios to stay within the rated current of the -buffers, and to achieve the desired power ratios by enabling or disabling -nOEs for the desired modulation index. It is useful to populate one of the -resistors as a high value (~10k) for the simulated tag modes; this allows -us to look at the incident carrier without loading the reader very much. - -DETAILS: ARM -============ - -Atmel makes a number of pin-compatible ARMs, with slightly different -peripherals, and different amounts of flash and RAM. It is necessary -to choose a device with enough flash not just for the ARM's program, -but also for the FPGA image (which is loaded by the ARM). - -The ARM is responsible for programming the FPGA. It also supplies a -clock to the FPGA (although the FPGA clock can also run off the 13.56 -MHz clock not used for anything else, which is obviously asynchronous -to anything in the ARM). - -It is necessary to use JTAG to bring the ARM for the first time; at -that point you can load a bootrom, and subsequently load new software -over USB. It might be possible to use the ARM's pre-loaded bootloader -(see datasheet) instead of JTAG, but I wanted the JTAG anyways for -debugging, so I did not bother. I used a Wiggler clone, with Macraigor's -OCD Commander. More expensive tools would work as well. - -USB SOFTWARE -============ - -At present I enumerate as an HID device. This saves me writing a driver, -but it forces me to do interrupt transfers for everything. This limits -speed and is not very elegant. A real USB driver would be nice, maybe -even one that could do stuff like going isochronous to stream samples -from the A/D for processing on the PC. - -PRETENDING TO BE A TAG -====================== - -It is not possible, with the given topology, to open-circuit the antenna -entirely and still look at the signal received on it. The simulated tag -modes must therefore switch between slight loading and heavy loading, -not open- and short-circuts across the antenna, evening though they do -not depend upon the incident carrier for power (just timing information). - -RECEIVING SIGNAL STRAIGHT FROM THE ANTENNAS -=========================================== - -There is a path straight from the antenna to the A/D, bypassing the peak -detector assembly. This goes through a gain stage (just a fast voltage -feedback opamp), and from there straight in to the mux. - -It is necessary to energize the relay to connect these paths. If the -coil is driven (as if to excite and read a tag) while these paths are -connected, then damage will probably result. Most likely the opamp -will fry. - -READING A TAG -============= - -The tag is excited by a carrier transmitted by the reader. This is -generated by IC9 and IC10, using some combination of buffers. The transmit -power is determined by selecting the right combination of PWR_OEx pins; -drive more of them low for more power. This can be used to modulate the -transmitted signal, and thus send information to the tag. - -The received signal from the antenna is first peak-detected, and then -high-pass filtered to reject the unmodulated carrier. The signal is -amplified a bit, and goes in to the A/D mux from there. The A/D is -controlled by the FPGA. For 13.56 MHz tags, it is easiest to do everything -synchronous to the 13.56 MHz carrier. - -INTERFACE FROM THE ARM TO THE FPGA -================================== - -The FPGA and the ARM can communicate in two main ways: using the ARM's -general-purpose synchronous serial port (the SSP), or using the ARM's -SPI port. The SPI port is used to configure the FPGA. The ARM writes a -configuration word to the FPGA, which determines what operation will -be performed (e.g. read 13.56 MHz vs. read 125 kHz vs. read 134 kHz -vs...). The SPI is used exclusively for configuration. - -The SSP is used for actual data sent over the air. The ARM's SSP can -work in slave mode, which means that we can send the data using clocks -generated by the FPGA (either from the PCK0 clock, which the ARM itself -supplies, or from the 13.56 MHz clock, which is certainly not going to -be synchronous to anything in the ARM), which saves synchronizing logic -in the FPGA. The SSP is bi-directional and full-duplex. - + +This is outdated. + +--- + +INTRODUCTION TO THE proxmark3 +============================= + +The proxmark3 device is designed to manipulate RFID tags in a number of +different ways. For example, a proxmark3 can: + + * read a low-frequency (~100 kHz) or high-frequency (13.56 MHz) tag, + including the ISO-standard tags; standards that require + bidirectional communication between the reader and the tag are + not a problem + + * emulate a low- or high-frequency tag, in a way very similar to the + way that a real tag behaves (e.g., it derives its timing from the + incident carrier) + + * eavesdrop on the signals exchanged between another reader and tag + + * measure the resonant frequency of an antenna, to a certain extent + (this is a convenience when building a test setup for the previous + three functions) + +The proxmark3 may be thought of as a direct-sampling software radio. +There is some complication, though, because of the usual dynamic range +issue in dealing with signals in RFID systems (large signal due to +the reader, small signal due to the tag). Some analog processing is +therefore used to fix this before the signal is digitized. (Although, +it is possible to digitize the signal from the antenna directly, with +appropriate population options. It is just not usually a good idea.) + +SYSTEM ARCHITECTURE +=================== + +The ANTENNA sends and receives signals over the air. It is external to +the board; it connects through SV2. Separate pins on the connector are +used for the low- and high-frequency antennas, and the analog receive +paths are separate. The antennas are inductive loops, which are resonated +by on-board capacitors. + +On the transmit side, the antennas are excited by large numbers of +paralleled bus driver buffers. By tri-stating some of the buffers, it +is possible to vary the transmit strength. This may be used to generate +a modulated carrier. The buffers are driven by signals from the FPGA, +as are the output enables. The antennas are excited as series circuits, +which permits a large input power for a relatively small input voltage. + +By driving all of the buffers low, it is possible to make the antenna +look to the receive path like a parallel LC circuit; this provides a +high-voltage output signal. This is typically what will be done when we +are not actively transmitting a carrier (i.e., behaving as a reader). + +On the receive side, there are two possibilities, which are selected by +RLY1. A mechanical relay is used, because the signal from the antenna is +likely to be more positive or negative than the highest or lowest supply +voltages on-board. In the usual case (PEAK-DETECTED mode), the received +signal is peak-detected by an analog circuit, then filtered slightly, +and then digitized by the ADC. This is the case for both the low- and +high-frequency paths, although the details of the circuits for the +two cases are somewhat different. This receive path would typically +be selected when the device is behaving as a reader, or when it is +eavesdropping at close range. + +It is also possible to digitize the signal from the antenna directly (RAW +mode), after passing it through a gain stage. This is more likely to be +useful in reading signals at long range, but the available dynamic range +will be poor, since it is limited by the 8-bit A/D. These modes would be +very appropriate, for example, for the heavily-discussed attacks in which +a tag's ID is learned from the data broadcast by a reader performing an +anticollision loop, because there is no dynamic range problem there. It +would also be possible to program the proxmark3 to receive broadcast AM +radio, with certain changes in component values. + +In either case, an analog signal is digitized by the ADC (IC8), and +from there goes in to the FPGA (IC1). The FPGA is big enough that it +can perform DSP operations itself. For some high-frequency standards, +the subcarriers are fast enough that it would be inconvenient to do all +the math on a general-purpose CPU. The FPGA can therefore correlate for +the desired signal itself, and simply report the total to the ARM. For +low-frequency tags, it probably makes sense just to pass data straight +through to the ARM. + +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). The ARM connects to the outside world over USB. + +DETAILS: POWER DISTRIBUTION +=========================== + +I make a half-hearted attempt to meet the USB power specs; this adds a +bit of complexity. I have not made measurements to determine how close +I come to succeeding, but I think that the suspend current might turn +out to be a pain. + +The +3V3 rail is always powered, whenever we are plugged in to USB. This +is generated by an LDO, which burns a quiescent current of 150 uA +(typical) already. The only thing powered from the +3V3 rail is the ARM, +which can presumably do smart power control when we are in suspend. + +The ARM generates two signals to switch power to the rest of the board: +FPGA_ON, and NVDD_ON. When NVDD_ON goes low, the Vdd rail comes up to +about five volts (the filtered-but-unregulated USB voltage). This powers +most of the analog circuitry, including the ADC and all of the opamps +and comparators in the receive path, and the coil drivers as well. Vdd +also feeds the +3V3-FPGA and +2v5 regulators, which power only the +FPGA. These regulators are enabled by FPGA_ON, so the FPGA is powered +only when NVDD_ON is asserted low, and FPGA_ON is asserted high. + +DETAILS: FPGA +============= + +The FPGA is a Spartan-II. This is a little bit old, but it is widely +available, inexpensive, and five-volt tolerant. For development, the FPGA +is configured over JTAG (SV5). In operation, the FPGA is configured in +slave serial mode by the ARM, from a bitstream stored in the ARM's flash. + +Power to the FPGA is managed by regulators IC13 and IC12, both of which +have shutdown. These generate the FPGA's VCCO (+3v3) and VCCINT (+2v5) +supplies. I am a little bit worried about the power-on surge, since we +run off USB. At the very minimum, the FPGA should not get power until +we have enumerated and requested the full 500 mA available from USB. The +large electrolytic capacitors C37 and C38 will presumably help with this. + +The logic is written in Verilog, of course for webpack. I have structured +the FPGA in terms of `major modes:' the FPGA's `major mode' determines +which of several modules is connected to the FPGA's I/O pins. A separate +module is used for each of the FPGA's function; for example, there is +now a module to read a 125 kHz tag, simulate a 125 kHz tag, transmit to +an ISO 15693 tag, and receive from an ISO 15693 tag. + +DETAILS: ANALOG RECEIVE PATH +============================ + +For `slow' signals, I use an MCP6294 opamp. This has a GBW of 10 MHz, +which is more than enough for the low-frequency stuff, and enough for +all of the subcarrier frequencies that I know of at high frequency. In +practice, the `slow' signals are all the signals following the peak +detector. These signals are usually centred around the generated +voltage Vmid. + +For `fast' signals, I use an AD8052. This is a very fast voltage-feedback +amplifier (~100 MHz GBW). I use it immediately after the antenna for +both the low- and high-frequency cases, as a sort of an ugly LNA. It is +not optimal, but it certainly made the design easy. + +An ordinary CD4066 is used to multiplex the four possible signals +(low/high frequency paths, RAW/PEAK-DETECTED). There is a potential +problem at startup, when the ARM is in reset; there are pull-ups on the +lines that control the mux, so all of the switches turn on. This shorts +the four opamp outputs together through the on-resistance of the switch. +All four outputs float to the same DC voltage with no signal, however, +and the on-resistance of the switches is fairly large, so I don't think +that will be a problem in practice. + +Comparators are used to generate clock signals when the device is +emulating a tag. These clock signals are generated from the signal on the +antenna, and therefore from the signal transmitted by the reader. This +allows us to clock ourselves off the reader, just like a real tag would. +These signals go in to the FPGA. There is a potential problem when the +FPGA is powered down; these outputs might go high and try to power the +FPGA through the protection diodes. My present solution to this is a +couple of resistors, which is not very elegeant. + +The high-frequency peak-detected receive path contains population options +for many features that I do not currently use. A lot of these are just +me guessing that if I provide options for different series and shunt +passives, perhaps it will come in handy in some way. The Zener diodes D10 +and D11 are optional, but may protect the front end from an overvoltage +(which will fry the peak detector diodes) when the `simulated tag' +is read by a powerful reader. + +DETAILS: ANALOG TRANSMIT PATH +============================= + +The coil drivers are just ACT244 bus buffers. I parallel eight of them +for each antenna (eight for the high-frequency antenna, eight for the +low-frequency antenna). This should easily provide a hundred milliamps +coil drive or so, which is more than enough for anything that I imagine +doing with the device. The drivers hit the coil with a square wave +voltage, however, which means that it is only the bandpass filter effect +of a resonant antenna that suppresses the odd harmonics. In practice it +would probably take heroic efforts (high antenna Q) to meet the FCC/CE +harmonic specs; and in practice no one cares. + +The tx strength, given good antenna tuning, is determined by the series +resistors. Choose the ratios to stay within the rated current of the +buffers, and to achieve the desired power ratios by enabling or disabling +nOEs for the desired modulation index. It is useful to populate one of the +resistors as a high value (~10k) for the simulated tag modes; this allows +us to look at the incident carrier without loading the reader very much. + +DETAILS: ARM +============ + +Atmel makes a number of pin-compatible ARMs, with slightly different +peripherals, and different amounts of flash and RAM. It is necessary +to choose a device with enough flash not just for the ARM's program, +but also for the FPGA image (which is loaded by the ARM). + +The ARM is responsible for programming the FPGA. It also supplies a +clock to the FPGA (although the FPGA clock can also run off the 13.56 +MHz clock not used for anything else, which is obviously asynchronous +to anything in the ARM). + +It is necessary to use JTAG to bring the ARM for the first time; at +that point you can load a bootrom, and subsequently load new software +over USB. It might be possible to use the ARM's pre-loaded bootloader +(see datasheet) instead of JTAG, but I wanted the JTAG anyways for +debugging, so I did not bother. I used a Wiggler clone, with Macraigor's +OCD Commander. More expensive tools would work as well. + +USB SOFTWARE +============ + +At present I enumerate as an HID device. This saves me writing a driver, +but it forces me to do interrupt transfers for everything. This limits +speed and is not very elegant. A real USB driver would be nice, maybe +even one that could do stuff like going isochronous to stream samples +from the A/D for processing on the PC. + +PRETENDING TO BE A TAG +====================== + +It is not possible, with the given topology, to open-circuit the antenna +entirely and still look at the signal received on it. The simulated tag +modes must therefore switch between slight loading and heavy loading, +not open- and short-circuts across the antenna, evening though they do +not depend upon the incident carrier for power (just timing information). + +RECEIVING SIGNAL STRAIGHT FROM THE ANTENNAS +=========================================== + +There is a path straight from the antenna to the A/D, bypassing the peak +detector assembly. This goes through a gain stage (just a fast voltage +feedback opamp), and from there straight in to the mux. + +It is necessary to energize the relay to connect these paths. If the +coil is driven (as if to excite and read a tag) while these paths are +connected, then damage will probably result. Most likely the opamp +will fry. + +READING A TAG +============= + +The tag is excited by a carrier transmitted by the reader. This is +generated by IC9 and IC10, using some combination of buffers. The transmit +power is determined by selecting the right combination of PWR_OEx pins; +drive more of them low for more power. This can be used to modulate the +transmitted signal, and thus send information to the tag. + +The received signal from the antenna is first peak-detected, and then +high-pass filtered to reject the unmodulated carrier. The signal is +amplified a bit, and goes in to the A/D mux from there. The A/D is +controlled by the FPGA. For 13.56 MHz tags, it is easiest to do everything +synchronous to the 13.56 MHz carrier. + +INTERFACE FROM THE ARM TO THE FPGA +================================== + +The FPGA and the ARM can communicate in two main ways: using the ARM's +general-purpose synchronous serial port (the SSP), or using the ARM's +SPI port. The SPI port is used to configure the FPGA. The ARM writes a +configuration word to the FPGA, which determines what operation will +be performed (e.g. read 13.56 MHz vs. read 125 kHz vs. read 134 kHz +vs...). The SPI is used exclusively for configuration. + +The SSP is used for actual data sent over the air. The ARM's SSP can +work in slave mode, which means that we can send the data using clocks +generated by the FPGA (either from the PCK0 clock, which the ARM itself +supplies, or from the 13.56 MHz clock, which is certainly not going to +be synchronous to anything in the ARM), which saves synchronizing logic +in the FPGA. The SSP is bi-directional and full-duplex. +