LF Sim Timing issues

[marshmellow42]

I've been testing the LF sim functions to see why they are so erratic as to their functionality.
I believe it comes down to the use of the clock in SimulateTagLowFrequency.
could someone explain what GPIO_SSC_CLK measures?

let me illustrate the issue:
a standard HID FSK2a tag should have waves 10 samples and 8 samples long depending on whether it is bit 1 or bit 0. so digitally it should be 1111100000 and 11110000.

if this is sent through the SimulateTagLowFrequncy the output has 2 errors.

1. the number of samples have lengthened to 11111110000000 and 11111000000
   so our clock is too slow
2. if you compensate for by reducing the bits sent to the function then the second issue becomes obvious: the transition between bit 1s and bit 0s creates extra 0 waves.
   So going from 1111000011110000 to 1111100000 translates 11110000001111100000 (added 2 extra 0 bits)

img1: bad timing:

img2: bad transition:

any thoughts?

I can get ASK clocks of 32 or greater to work fine but the lower the clock the worse this affects things.

[holiman]

I investigated LF Sim a bit in depth a while ago, and my conclusion was the following...
We don't use any on-board clock for timing, instead we rely on the clock from the reader (the carrier signal), which we get from via the GPIO_SSC_CLK (iirc). I believe there's some documentation on the forum somewhere about my investigation on that.

Could you elaborate on what you did to get the images above? Are you using two pm3:s ?
Maybe someone ought to look through the FPGA parts where GPIO_SSC_CLK is generated from the carrier.

[marshmellow42]

my guess is we need to use a different clock calculation. (possibly instead of bit-bang, modulate or demodulate for x clock periods for each wave, where x is 1/2 the given wave length)

unfortunately I'm very new to the clocks and their uses.

[marshmellow42]

i'm using 2 PM3's one to sim one to read.

[marshmellow42]

maybe I should snoop the sim to a real reader... I can look at that.

[holiman]

Here's the forum thread where I looked into it

[marshmellow42]

I just re-read the info, and I do believe we need an internal clock, or I suppose fix the carrier clock detection. can we re-use some of the info used for hitag?

[holiman]

We should use the carrier clock, as that one kind of per definition is correct - it's the clock the reader expects, whether it's correct according to NIST standards or not...

[marshmellow42]

i'm attempting to learn. ;) as I said above I can hack it and get ASK to work above RF/16 clocks.
(so for EM410x tags i'm good.) but I don't like the hack and it isn't good for the repo. and PSK and FSK are still hit or miss, usually miss.
I'll keep digging.

[holiman]

I can try to capture some traces, with a rfidler generating a 125khz wave, and measuring the ssp_clk from the FPGA debug output, with the pm3 in LF simulation-mode (but not modulating). If I use a DSO to measure the carrier wave and the FPGA output, it would be possible to see if the FPGA somehow misses a step in the carrier sometimes or if the error is somewhere else.

[marshmellow42]

I cannot prove it yet, but it appears to mainly happen during a modulation transition. When it switches high to low or low to high. So I'm not sure you will see something. But it is a very good test to verify it is working as it should when not modulating so we can rule that out.

[marshmellow42]

ok so here is something. using 2 antennas - the one from proxmark3.com who's hw tune is:

LF antenna: 14.16 V @ 125.00 kHz

LF antenna: 27.91 V @ 134.00 kHz

LF optimal: 30.11 V @ 131.87 kHz

and another I built who's hw tune is:

LF antenna: 45.79 V @ 125.00 kHz

LF antenna: 25.02 V @ 134.00 kHz

LF optimal: 45.79 V @ 125.00 kHz

if I run my new sim commands (from my fork) with the weaker antenna I get this result:

or 111100000 and 1110000 instead of 1111100000 and 11110000.

if I run the same command with the stronger antenna I get this result:

or 1111100000 and 111100000 instead of 1111100000 and 11110000.

I've attempted to adjust the input data to get a steady 1111100000 11110000 but have failed so far.
sometimes different distances between the antennas will affect the output but it then becomes erratic. with the antennas very close the results are repeatable.
NOTE the above images were obtained with a second PM3 in snoop mode listening to the first PM3 attempting to sim to a reader. though they actually look the same if I were just to read with the second PM3. the second PM3 is using an antenna I made registering at the 45.79V same as the stronger above

[marshmellow42]

I think I may have fixed the bit transition issue noted in my first post. it appears a true tags wave begins low 00001111 and 0000011111, so I flipped them (in my fork).
This and adding a small wave every 4 0 bits (to fix the clock shift when the clock is 50 and fc is 8) seems to make the wave more like a cards wave.

but we still have the timing issues.

now maybe a 25V antenna works perfectly... ??? but too strong or too weak and your stuck?

[marshmellow42]

just thought I'd explain what I experimented with to get ask simulation working somewhat:

to simulate EM41xx ask/man tags I built a new function SimulateTagLowFrequencyMM. the only change that really made a difference was to test if we just transitioned from a high to low or from low to high and then skip the "wait for reader carrier to go low" loop.

it appears to me when we are transitioning, either the modulating of the coil takes too long and we miss the carrier low, or it interferes with reading the carrier low. (or it has nothing to do with that and it just effectively removes 2 samples per wave that we somehow picked up by mistake)
(note very small waves (rf/16 and below) pick up more extra samples)

this gets lf simask working above rf/16 clock rates. but this is a band-aide and does not really address the clock issue.

[marshmellow42]

http:https://www.proxmark.org/forum/viewtopic.php?pid=2670#p2670 does this still apply to our clock?

[marshmellow42]

based on this: http:https://www.proxmark.org/forum/viewtopic.php?pid=6021#p6021
I flashed my proxmark back to R582 and the HID sim functions great as the poster mentions. antenna doesn't matter.
i'm going to attempt to try additional versions to see if a more recent version works so as to isolate when it was destroyed. I have a feeling it was either when we went to lo_edge_detect.v instead of lo_simulate.v or when the izsh added the wave cleaning.
BTW, on github how do I get a download of the code at a moment in time? (googlecode had versions)
EDIT: I found how to get code from a moment in time on github:
git checkout 'master@{1979-02-26 18:30:00}'
or
git checkout @{14.days.ago}

[marshmellow42]

NOTE: wave from R582 (FSK Sim works well):

(read from second PM3)

[marshmellow42]

it appears the issues where there prior to the break out of LF and HF fpga code, (and the wave cleaning). I loaded code from 6/17/2014 before the FPGA split,(fpga from 2/25/2014) and the "extra" samples per wave were there.
how hard would it be to implement a "new" mode that uses lf_simulate.v and not lo_edge_detect.v?

[holiman]

It would be very simple now that we have unused modes... Address wise...

[holiman]

Regarding my last comment, see here.

[holiman]

I looked at the code now, the lo_simulate is still there. You can try to just use that mode instead, and see if it works better. lo_simulate was very similar to lf_edge_detect back then, the change just added support for both doing reader modulations OR lf sims, whereas earleir it was just lf sim.

One other notable thing changed, as far as I can see. Before:

// Toggle the output with hysteresis
//  Set to high if the ADC value is above 200
//  Set to low if the ADC value is below 64
reg is_high;
reg is_low;
reg output_state;

always @(posedge pck0)
begin
    if((pck_divider == 8'd7) && !clk_state) begin
        is_high = (adc_d >= 8'd200);
        is_low = (adc_d <= 8'd64);
    end
end

always @(posedge is_high or posedge is_low)
begin
    if(is_high)
        output_state <= 1'd1;
    else if(is_low)
        output_state <= 1'd0;
end

assign ssp_frame = output_state;

After:

// Toggle the output with hysteresis
//  Set to high if the ADC value is above 200
//  Set to low if the ADC value is below 64
reg is_high;
reg is_low;
reg output_state;

always @(posedge pck0)
begin
    if((pck_divider == 8'd7) && !clk_state) begin
        is_high = (adc_d >= 8'd190);
        is_low = (adc_d <= 8'd70);
    end
end

See what happened there? The thresholds for determining the carrier state changed, from 64,200 into 70,190. I don't know the reasoning behind that.

The current code, in lo_edge_detect is more complicated, based on izsh's algorithms.

Anyway, just switching mode to use lo_simulate looks very simple, no fpga coding needed.

[holiman]

Just looking at the code, I don't believe the problem is on the "output"-side, that is, our intended signals being corrupted. The ARM-signals go pretty much directly to the coils:

wire tag_modulation = ssp_dout & !lf_field;
wire reader_modulation = !ssp_dout & lf_field & pck_divclk;

// No logic, straight through.
assign pwr_oe1 = 1'b0; // not used in LF mode
assign pwr_oe2 = tag_modulation;
assign pwr_oe3 = tag_modulation;
assign pwr_oe4 = tag_modulation;

As you can see ssp_dout feeds directly to a wire, tag_modulation, which goes directly to the coils. The lf field is off.

The ssp_dout is what we're sending from ARM.

Therefore, I'm leaning towards some problem in the carrier detection.

[holiman]

Ah, I may be totally off. When we're doing sims, we're not looking at ssp_frame, we're looking at GPIO_SSC_CLK which afaik is ssp_clk, which is directly coupled to cross_lo. And this has been looking identical since the stone age.

[marshmellow42]

How do I try the lo_simulate mode? It doesn't seem to have a mode?

[marshmellow42]

Could it just be the time it takes to power up the coil? Would a larger antenna coil take longer to power up? Longer than a 1/2 a clock cycle?

[marshmellow42]

To answer myself, No, it should not be waiting for the coil to fully modulate when you call high or low. I don't think...

[iceman1001]

The coil powering up could be the reason... But it is just the transition that will trigger 1 / 0 ?

[marshmellow42]

If there is a delay of some sort during modulation it would be during a transition from open to shorted or visa versa. And this would explain why my code now works with waves that have fewer transitions (ask RF/32 and above) but why would the code wait for the coil and not just set the bit to on or off and continue?

[iceman1001]

Depends on how the lf_detect &pr lf_simulate modes works I guess.
If there is logic between transitions which takes time to process. Or maybe it is trying to sync transitions with a clock?

The file lo_simulate.v needs to be in the makefile for the fpga.. and hooked in with the FPGA_LF_SIMULATE (1<<2) in armsrc/apps.h
I have no idea at all how to do that.

[holiman]

Yeah, sorry, code is there but not addressable... And afaict, no delay, no logic, no clock...

[marshmellow42]

Sounds like it should be fairly easy to reuse lo_simulate. I'd like to try it and see if it functions any differently. Holiman do you have a FPGA build environment? Is that something we could test?

[holiman]

Yes, I can enable it. May take a few days

[marshmellow42]

Understood, and thanks. It might not fix it but it will rule it out. I don't like not being able to see a problem in the code. :( in the mean time I will continue testing antennas to see their affects on this.

[marshmellow42]

Darn phone... Wrong button

[marshmellow42]

the assignments for pwr_oeX are a bit different between the lo_simulate.v and lo_edge_detect.

pwr_oe3 = 1'b0           vs  pwr_oe3 = tag_modulation; (or ssp_dout)
pwr_oe1 = ssp_dout;      vs  pwr_oe1 = 1'b0;
pwr_lo  = 1'b0           vs  pwr_lo = reader_modulation;
dbg     = output_state;  vs  lf_ed_toggle_mode ? edge_toggle : edge_state; <-- this was a later change 

unfortunately I do not yet understand what each of these do or why pwr_oe3 and pwr_oe1 were flipped.

[pwpiwi]

dbg is only a debug output.

During simulation the reader_modulation is low, therefore there is no difference for pwr_lo.

pwr_oe1 isn't relevant for the LF antenna. However, it might not have been a good idea to modulate with all available LF antenna drivers (pwr_oe2, pwr_oe3 and pwr_oe4). This results in the antenna being completely disconnected when ssp_dout is high. I wonder what we would then get as a clock via cross_lo...

If someone would try this in lo_edge_detect - unfortunately I can't test LF:

assign pwr_oe1 = 1'b0; // not used in LF mode 
assign pwr_oe3 = 1'b0; // base antenna load = 33 Ohms
// when modulating, add another 33 Ohms and 10k Ohms in parallel:
assign pwr_oe2 = tag_modulation;
assign pwr_oe4 = tag_modulation; 

[iceman1001]

I would love to help out, but I don't have a working fpga development environment.

[holiman]

@pwpiwi, great analysis, probably spot on. I can make a new fpga and send to marshmellow for testing

[holiman]

And yes, we have a winner, marshmellow just confirmed. Well done!

[marshmellow42]

the waves look beautiful! I've confirmed good FSK (HID) simulating against 5 different valid readers. it is consistent and reliable.
I've also tested my new sim commands (lf simfsk, lf simask) and they work well.
the lf em em410xsim appears to still have something wrong, but my lf simask can sim these, so it must be a client side issue.
I will do some simPSK testing tomorrow.
I do not have a hitag reader so I do not know how this fpga change will affect hitag.

[marshmellow42]

Great job @pwpiwi for the fix and @holiman for the assist!

[marshmellow42]

while we are on the subject of powering the lf antenna, I was looking at the NRZ/Direct modulation. it appears to normally stay half modulated and modulate full or off to indicate a bit. is there anyway we can support this?

[iceman1001]

Where is all this information of the inner workings of the fpga and its use with the pm3? Can someone make a write-up? With technical details or system documentation? I don't read verilog, so this would help my understanding a lot.

[pwpiwi]

@iceman: depends what you mean with "inner workings". Its a programmable device and Its function is determined by the verilog sources. Together with the PM3 schematic this is the only documentation available. However, if you are interested in the FPGA inner structure then google for the datasheet (Xilinx DS001 Spartan II).
Regarding Verilog: The operators and control structures are very similar to programming languages. But you need to keep in mind that Verilog describes Hardware. In hardware everything happens in parallel and "at once" (give or take a few nanoseconds). If you need something to happen sequentially you need to explicitely specify a "storage" (registers, flip flops) and a corresponding clock signal. And of course you need to know the basics about logic gates, registers, latches, adders with/without carry, RAMs, etc.

@marshmellow42: Do you have a reference (link) to the NRZ/direct modulation you are looking for?

[holiman]

@iceman ; I didn't have a clue about how Verilog functions a few months back. But it's fairly simple to read some tutorials and pick it up. The main concepts could be explained in a page or two, so it's pretty easy to reach the level of being able to comprehend written code - a bit more to write it yourself.

But coming from a software background, I also have difficulties understanding the hardware portions, and the boundaries between hardware and software. I've not looked at the pm3 schematic. @pwpiwi - what free/opensource tools would you recommend to view and make sense of the schematics?

[holiman]

oh, and perhaps you haven't notived. But after I fixed iclass full simulation, I tagged a version 2.0.0-rc1. With this fix in place, I tagged it as 2.0.0-rc2. Anything else we want included in 2.0.0-final?

[iceman1001]

@holiman For me, the hardware connections into the software is just "automagic". I'm totally lost there. My idea was to start understanding it but it seems like I need dev environment for Verilog too..

regarding the rc2, I suggest you get the new stuff from @marshmellow42 into it.

@pwpiwi Your extended knowledge over the software borders to the hardware side, gives you a more complete picture than I ever can get from just looking at the software side.

[pwpiwi]

I meant the schematics in doc/proxmark3_schema.pdf. I am recommending Adobe Reader to view and make sense of the schematics 😀.

[holiman]

For verilog compilation, yes you need a dev env. I use an old win xp virtual machine setup for the purpose, but all I do withini it is copy the code from linux to windows, run go.bat, copy back (via shared folders). For experimentation with verilog, you can use some open source tools. Or just do it the hard way, modify via editors, generate an FPGA-image, flash, test. Works well for small things, like this one here.

[marshmellow42]

@holiman for tagging I'd like to finish my Sim commands and see if I can finish the patch to em410x Sim. I will test psk Sim later today. And might be ready for a pull after that.

@piwi, for NRZ/Direct the best I have is the traces in the traces folder and my experimenting with the ata5577 chip. I know how to demod it, and have built a demod function for it. I've only ever seen one tag from an unknown system use it.

[marshmellow42]

I've finished the sim commands i can build (missing NRZ/Direct), as well as a few fixes - including for the em410xsim and lf sim. (as well as other fixes i've had in my fork for a while.)
i've created the pull request. i hope this doesn't step too much on your graphing changes that are coming @holiman :(

[pwpiwi]

Anything else we want included in 2.0.0-final?

I have another FPGA bugfix in hi_iso14443.v in testing and will commit on Monday morning. Together with @marshmellow42's last fixes this should go into 2.0.0-final. And I might commit the fix for issue #73 on Monday evening...

[pwpiwi]

Couldn't continue with testing yesterday. @holiman: up to you to decide when you want to do the "final" tagging. I personally don't care if these fixes go to 2.0.0.-final or the next release. I am quite sure that these won't be the last fixes anyway...

[pwpiwi]

Pushed two commits.