proxmark3 gerbers and bill of material

gaucho · 2014-03-20 08:39:52

vivat wrote:

gaucho wrote:
OFFTOPIC: i calculated a save of about 18€ reducing the number of components with my pcb design. another saving can be made on pcb reducing the number of layers and another saving can be made on pcb soldering because of the reduced number of solderings. When i'll finish repairing these boards I'll request a quotation. consider the big price is the component's price.
I think it can cost 40€(total production cost). So the commercial price can be 80€, supposing to sell it at the double of the production price.
I would personally pay more money to get more features, like SPA and DPA attacks on most cryptographically "strong" tags like desfire, or having the ability to debug the board with I/O pins on the PCB rather than buying.
To perform such attacks, we need more sensitive ADC, faster micro-controller, probadly external RAM, bigger more powerful FPGA.

the problem in your request is a reengeneering of the software (apart the HW re-styling).
this requests time before to have a working product.
high price + not working functionalities = few users = small comunity = slow open source product growth

gaucho · 2014-03-20 08:47:33

vivat wrote:

gaucho
I think that there is problem in analog TX path. Can you check that both 244's with scope?
Do you use same antenna on all boards?

yes i used same antenna on all the boards.
analog TX?
ummm... How could i check them? what is the expected effect on not working 244?
i suppose that if there was a not working 244 i should see a lower sine waveform on the received signal from the antenna.. correct?
i've still seen that the received signal amplitude is the same..

Last edited by gaucho (2014-03-20 08:48:28)

vivat · 2014-03-20 09:27:39

You can compare the results obtained on working/non-working pm3 with scope. Who knows, maybe that 244 tri-states are fake too...
I found that our TLC5540 samples around 6.7 bits @ 13.56 mhz clock:

Last edited by vivat (2014-03-20 15:47:26)

Enio · 2014-03-20 17:35:17

gaucho wrote:

Enio wrote:
An issue i see is that each ADC clock we get 8 bits at fpga, to send that to arm we only have ssp (1 bit per clock cycle). Im not sure how fast we can clock ssp, but probably not 8x as fast as samples arrive thru ADC. Thats probably why only accumulations are sent to arm.
infact the summary of my considerations ( maybe you can understand me reading again my previous post) , is to send one sample(1Byte) each 9 clock cycles.
So my final previous question was: will it be good to have a sampling frequency of 1,5MHz (13,5MHz/9)?
My answer is YES.
EDIT: one bit of the reply obtained from a mifare 1k tag, has a duration of 5 microseconds. With a sampling frequency of 1,5MHz you can get that HIGH bit sampled 7 times. It's a lot!

I experimented with the verilog code yesterday. I "abused" hf 14b simlisten function to get raw PKD samples (to set fpga modes etc).
But im not exactly sure what i am getting there, with my configuration adc samples with 13.56MHZ and i send average of last 8 samples to arm. This i save in BigBuffer and plot it. Its probably nonsense, i made that just to learn how to gather data from adc and send it into buffer.

Now, what data should i gather to send to arm so we can interpret it?

gaucho · 2014-03-20 18:23:35

Enio wrote:

gaucho wrote:
Enio wrote:
An issue i see is that each ADC clock we get 8 bits at fpga, to send that to arm we only have ssp (1 bit per clock cycle). Im not sure how fast we can clock ssp, but probably not 8x as fast as samples arrive thru ADC. Thats probably why only accumulations are sent to arm.
infact the summary of my considerations ( maybe you can understand me reading again my previous post) , is to send one sample(1Byte) each 9 clock cycles.
So my final previous question was: will it be good to have a sampling frequency of 1,5MHz (13,5MHz/9)?
My answer is YES.
EDIT: one bit of the reply obtained from a mifare 1k tag, has a duration of 5 microseconds. With a sampling frequency of 1,5MHz you can get that HIGH bit sampled 7 times. It's a lot!
I experimented with the verilog code yesterday. I "abused" hf 14b simlisten function to get raw PKD samples (to set fpga modes etc).
But im not exactly sure what i am getting there, with my configuration adc samples with 13.56MHZ and i send average of last 8 samples to arm. This i save in BigBuffer and plot it. Its probably nonsense, i made that just to learn how to gather data from adc and send it into buffer.
Now, what data should i gather to send to arm so we can interpret it?

WOW. you cool.
you don't have a signal generator..may be you could try just enabling the HI RAW PATH?
In this case, without any tag, after a HW TUNE, on TP1 you should always see a sine waveform (i suppose because it stays enabled).
Is it correct?
otherwise if you can send hf 14a read and take the samples but i suppose this is more difficult since the samples are still used by the fpga for the real time processing...

Enio · 2014-03-20 19:14:49

Hm, something must be wrong, i get only noise of pkd, no matter if antenna or not. selecting hiraw i get steady +127 with sime negative spikes to -1.

This is the fpga code

//-----------------------------------------------------------------------------
//
// Jonathan Westhues, April 2006
//-----------------------------------------------------------------------------

module hi_read_rx_xcorr(
    pck0, ck_1356meg, ck_1356megb,
    pwr_lo, pwr_hi, pwr_oe1, pwr_oe2, pwr_oe3, pwr_oe4,
    adc_d, adc_clk,
    ssp_frame, ssp_din, ssp_dout, ssp_clk,
    cross_hi, cross_lo,
    dbg,
    xcorr_is_848, snoop, xcorr_quarter_freq
);
    input pck0, ck_1356meg, ck_1356megb;
    output pwr_lo, pwr_hi, pwr_oe1, pwr_oe2, pwr_oe3, pwr_oe4;
    input [7:0] adc_d;
    output adc_clk;
    input ssp_dout;
    output ssp_frame, ssp_din, ssp_clk;
    input cross_hi, cross_lo;
    output dbg;
    input xcorr_is_848, snoop, xcorr_quarter_freq;

// Carrier is steady on through this, unless we're snooping.
assign pwr_hi = ck_1356megb & (~snoop);
assign pwr_oe1 = 1'b0;
assign pwr_oe2 = 1'b0;
assign pwr_oe3 = 1'b0;
assign pwr_oe4 = 1'b0;

reg ssp_clk;
reg ssp_frame;

reg fc_div_2;
always @(posedge ck_1356meg)
    fc_div_2 = ~fc_div_2;

reg fc_div_4;
always @(posedge fc_div_2)
    fc_div_4 = ~fc_div_4;

reg fc_div_8;
always @(posedge fc_div_4)
    fc_div_8 = ~fc_div_8;

reg adc_clk;

always @(xcorr_is_848 or xcorr_quarter_freq or ck_1356meg)
    if(~xcorr_quarter_freq)
    begin
	    if(xcorr_is_848)
	        // The subcarrier frequency is fc/16; we will sample at fc, so that 
	        // means the subcarrier is 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1 ...
	        adc_clk <= ck_1356meg;
	    else
	        // The subcarrier frequency is fc/32; we will sample at fc/2, and
	        // the subcarrier will look identical.
	        adc_clk <= fc_div_2;
    end
    else
    begin
	    if(xcorr_is_848)
	        // The subcarrier frequency is fc/64
	        adc_clk <= fc_div_4;
	    else
	        // The subcarrier frequency is fc/128
	        adc_clk <= fc_div_8;
	end

// Enio
reg [10:0] adc_d_accum;
reg [7:0] adc_d_out;
reg [7:0] enio_cnt;

always @(negedge adc_clk)
begin
  // count to 255
  if(enio_cnt[7:0] == 8'd255)
    enio_cnt[7:0] <= 8'd0;
  else
    enio_cnt <= enio_cnt + 1;

    // Add each sample to accum. reg. each cycle
    adc_d_accum <= adc_d_accum + adc_d;
    

    // change ssp_clk every 4rth adc_clk
    if(enio_cnt[1:0] == 2'b10)
        ssp_clk <= 1'b0;
    if(enio_cnt[1:0] == 2'b00)
      begin
        ssp_clk <= 1'b1;
      end

    
    // load new data just before frame begin. (== 32th adc tick)
    if(enio_cnt[4:0] == 5'b11111) //5'd31
    begin
        adc_d_out[7:0] <= adc_d_accum[10:3]; // Send average of 8 samples (/8 = 3x right shift)
        adc_d_accum[10:0] <= 10'd0; // reset to 0
       // adc_d_out[7:0] <= adc_d; // Sends every 8th sample. 
    end

    // Begin frame AFTER 32 adc tick
    if(enio_cnt[5:2] == 4'b0000 || enio_cnt[5:2] == 4'b1000) // 0000XX / 1000XX
      begin
        ssp_frame = 1'b1;
      end
    else
    begin
      // shift ssp ouput every non-start of frame (at start we just loaded new
      // data, nothing to shift there)
      if(enio_cnt[1:0] == 2'b00) // 2'd0
        adc_d_out[7:1] <= adc_d_out[6:0];
      ssp_frame = 1'b0;
      end
end

assign ssp_din = adc_d_out[7];

// Unused.
assign pwr_lo = 1'b0;

endmodule

I tested it well, it sends the right bytes that are copied in adc_d_out.

However im not sure about my arm code where i set the modes for fpga. And im not sure why the ADC gets signal in snoop mode with no antenna present.

FpgaWriteConfWord(FPGA_MAJOR_MODE_HF_READER_RX_XCORR | FPGA_HF_READER_RX_XCORR_848_KHZ | FPGA_HF_READER_RX_XCORR_SNOOP);

should disable the hf field as seen in fpga code:

// Carrier is steady on through this, unless we're snooping.
assign pwr_hi = ck_1356megb & (~snoop);

With snoop = 1 it should always be 0 on pwr_hi.

Ill see what i can learn about HF signal... Any hints appreciated though!
Edit: I think i send samples slower then i thought. Anyways, why do i get values on adc?..

Last edited by Enio (2014-03-20 19:27:11)

Enio · 2014-03-20 21:26:03

Ooooohhhhh

Snooped some stuff with my phone and a mifare card. Does that look good?

How can this be decoded? Hmm. I should read more papers.

Last edited by Enio (2014-03-20 22:16:38)

gaucho · 2014-03-20 22:35:38

Enio wrote:

Ooooohhhhh
Snooped some stuff with my phone and a mifare card. Does that look good?
http://i.snag.gy/5LRrw.jpg
How can this be decoded? Hmm. I should read more papers.

supercool. i understood that the higher signal are the requests and the lower signal is the reply from the tag. zoom on the first tag reply and you should be able to decode the reply. piwi explained few pages ago how to decode it. did you read it?

i'm also interested to test your compiled fw on my broken boards

Last edited by gaucho (2014-03-20 22:37:57)

Enio · 2014-03-20 22:43:11

gaucho wrote:

Enio wrote:
Ooooohhhhh
Snooped some stuff with my phone and a mifare card. Does that look good?
http://i.snag.gy/5LRrw.jpg
How can this be decoded? Hmm. I should read more papers.
supercool. i understood that the higher signal are the requests and the lower signal is the reply from the tag. zoom on the first tag reply and you should be able to decode the reply. piwi explained few pages ago how to decode it. did you read it?
i'm also interested to test your compiled fw on my broken boards

Ill try find it. I need to make it a lil more stable, right now i start collecting samples when value reaches 255, but if i dont get close with my phone to trigger it pm3 will reset after a few seconds. I might be able to do that tomorrow and send you a fullimage (or a patch if you want, but you need Xilinx ISE/Webpack to compile fpga code)

Btw, i drive ssp with 13.56 MHZ clock, same as the adc sample. Right now i return adc of every 8th sample only. if ssp can go faster we could get better resolution. And we might be able to drive ADC even faster.

Last edited by Enio (2014-03-20 22:47:57)

vivat · 2014-03-21 04:21:42

Enio
Good job!
Can you show us your diff?

Btw, i drive ssp with 13.56 MHZ clock, same as the adc sample. Right now i return adc of every 8th sample only. if ssp can go faster we could get better resolution. And we might be able to drive ADC even faster.

I see in your code that you clock adc with adc_clk/4:

    // change ssp_clk every 4rth adc_clk
    if(enio_cnt[1:0] == 2'b10)
        ssp_clk <= 1'b0;
    if(enio_cnt[1:0] == 2'b00)
      begin
        ssp_clk <= 1'b1;
      end

Or maybe you have changed your code?
gaucho
Have you performed other tests?

Enio · 2014-03-21 05:46:42

vivat wrote:

Or maybe you have changed your code?

Yeah i fixed and simplified it.

However i tried using pck0 (supposedly 24Mhz) clock for ssp, it doesnt work - i dont get any more samples, i dont know why.

Anyways, diff files in here: https://www.dropbox.com/s/02aza5te65q6wxb/hf_snoop.zip
Fullimage.elf: https://www.dropbox.com/s/05h9yfzp2ixhrns/fullimage.elf

launch it with

>hf 14b simli

and read the card with another reader in the next few seconds.

Last edited by Enio (2014-03-21 05:48:33)

gaucho · 2014-03-21 09:03:52

HiEnio,
Vivat yesterday wrote this:

vivat wrote:

Quick googling:
http://wiki.jelectronique.com/at91sam7
ARM's SSC speed is up to 12.5Mb/s
Are you going to implement downsampling in FPGA?
Oh, and also on the client because now it reads 8-bit samples(data in decimal from -128 to 128 that you can see on the plot window).

it it true?
if it's true, you can not feed the line with a clock faster than 12MHz.
Cause may be that the arm is not able to receive it.
Am I clear? can you check documentation?

Enio · 2014-03-21 09:33:10

Could well be the reason why pck0 didnt give more samples but more noise. pity. We could reduce value spectrum and send more.

gaucho · 2014-03-21 09:42:26

read also here. i can't find the information needed, but may be you understand it better than me: http://www.atmel.com/images/doc6175.pdf

could you also check that the number of sent samples is equal to the number of the received samples?

Last edited by gaucho (2014-03-21 09:46:46)

gaucho · 2014-03-21 10:06:11

i repeat my reply to vivat about the clock, could you evaluate it?

-if ARM's SSC speed is up to 12.5Mb/s, this means a max sampling frequency of 1 Mega Samples per second (because i'm considering to transmit at a frequency a little bit under the limit, let's say 12MSps, we transmit 8 bits of data and one start bit and one stop bit or maybe also something else.., so 1MSps seems to be the right choice in my opinion).

- one bit of tag response during the HF 14A READ command is 5microseconds.

- 1MSps= 1 sample each microsecond means that we can sample one bit of tag response for at least 4 times.

Conclusion: we don't need to go faster than 12Mega bit per second.

Is it correct?

if it's correct you can take the PCK0 (24MHz) dividing by 2 that clock and using it as source clock for SSC

EDIT: @vivat: no, i didn't performed more tests, i had a lot of work yesterday and today i will be out of office all day. Next measures on monday.
today I'll take the 2 boards given to my friend and on monday I'll replace the op. amp. also on these boards.

Last edited by gaucho (2014-03-21 10:15:51)

vivat · 2014-03-21 10:43:33

gaucho wrote:

working board:
http://www.magicparker.it/site/img/system/working6.jpg
not working boad :
http://www.magicparker.it/site/img/system/brokennot_reading.jpg
comparing the previous 2 screenshots i can see that on the broken board it is missing the third reply of the tag. moreover there is also higher noise on the broken board.
Next screenshot shows the other broken board where the noise is not present, sometimes there is the third reply, and when there is the reply the tag is read:
http://www.magicparker.it/site/img/system/brokenreading.jpg

Looking at your second screenshot, I don't understand why pm3 have started to transmit before the tag stopped transmitting. Can you check also check that FPGA clocked properly by ARM(take measurements from FPGA_CCLK pin)?
And analog TX, of course.

Last edited by vivat (2014-03-21 10:47:31)

Enio · 2014-03-21 21:46:55

gaucho wrote:

- 1MSps= 1 sample each microsecond means that we can sample one bit of tag response for at least 4 times.

It already runs on 13.56 Mhz clock- we get ~4 samples per tag bit. I dont think we can get any higher, i already tested with 24Mhz and got very noisy results.

I'm having trouble finding ressources on the exact type of modulation & encoding of the reader/tag interaction. If you have a good read, please let me know.

asper · 2014-03-21 22:09:27

Enio, do you have 13.56MHz ISO standard datasheets? If you need them let me know.

vivat · 2014-03-22 05:34:14

Enio
Can you add option to your new code to select ADC path, i.e. HF/LF RAW/PKD and ADC/SSC clock?

Enio · 2014-03-22 12:13:45

vivat wrote:

Enio
Can you add option to your new code to select ADC path, i.e. HF/LF RAW/PKD and ADC/SSC clock?

Yes, this was just a test to see how close we can get these "raw" samples. What i added is basically an fpga passthru to ssc - as long as we dont work on samples on fpga thats our bottleneck.
The highest freq we can sample with arm is ~1.5MHZ (12.5MHZ / 8) as gaucho pointed out and what seems to be true in tests (13.56/8 bytes on ssc, higher gave distortions). Because it seems we cannot send more then 1 bit per 13.56 MHZ cycle. This i want to further test and read up about it though. Maybe theres another way to send data and we can use both. Or we can buffer some samples in fpga triggered by some wave and send later for a closer look.

So my plan is,
1) Make sure we dont miss an opportunity to send faster fpga->arm
2) Put the fpga code to its own module and add a clock divider and a source selection. (We probably could have lf&hf read in one function then. Mux settings are set from arm code so there is flexibility - we could even use the hw setmux for that i guess.)
3) Finally i want to see how fast we can pass the arm input to pc. A passthru mode there could be funny too i.e. for listening radio with pm3.
4) Find out how to put this to svn/git once its done.

But sadly i am low on time till wednesday and cant code till then. Ill do some reading in the meantime while travelling.

Enio · 2014-03-22 13:51:15

asper wrote:

Enio, do you have 13.56MHz ISO standard datasheets? If you need them let me know.

I found some, thanks!

Enio wrote:

gaucho wrote:
- 1MSps= 1 sample each microsecond means that we can sample one bit of tag response for at least 4 times.
It already runs on 13.56 Mhz clock- we get ~4 samples per tag bit. I dont think we can get any higher, i already tested with 24Mhz and got very noisy results.
I'm having trouble finding ressources on the exact type of modulation & encoding of the reader/tag interaction. If you have a good read, please let me know.

I Demodulated some bits now (I got the UID out! ), we get good enough wave to do that manually however i noticed:

Usually i have 8 samples for 1 modulated bit. But not always. Sometimes 1 gets skipped, probably because ssc "records" slower then 13.56mhz, probably just gets 12.5Mbit/sec out of the arriving 13.56.
This is a bit annoying as when you put an 8sample grid on it, sometimes on demodulating you have to shift the grid by a sample to be in sync again.

Any idea how to solve that? As we wont get more samples we could consider rewriting the grid function to support fraction values for distance and to move it by smaller steps. Then we could set it to 8*12.5/13.56 = ~7.34 stepsize and align it on the flanks of a Manchester wave to easily read the bits by watching direction of the closest flank.
(As we can work with samples with higher resolution on fpga - thats just for educational purposes, to better learn about modulations etc. - or to analyze manually.)

Last edited by Enio (2014-03-22 14:03:48)

gaucho · 2014-03-22 14:33:10

Enio,
I'm not sure if i understood your words.

-I understood that you are sampling at 13,56MHz.
-I understood that you are using 13,56MHz as clock on the SSC serial line.
-I understood that sometimes you are loosing one sample.

I ask you the following:

1) do you agree with me that the limit speed on SSC clock is 12MHz (I hope that this speed also contemplates the writing of the data on the arm memory) ?

2) If you agree with me, why you leave 13,56MHz clock? I think you should take the 24MHz clock, divide it by 2 in order to obtain the 12MHZ and then use it on the SSC clock. The same signal (the 12MHz), divided by 12 should be used to sample the signal in order to send on the serial line one sample each 12 clock cycles.

By this way you will have 4 samples for each bit transmitted from the tag. We need at least 1 sample for each bit in order to correctly decode a tag, so, 4 bit it's enough.

About your comment:

enio wrote:

Usually i have 8 samples for 1 modulated bit. But not always. Sometimes 1 gets skipped, probably because ssc "records" slower then 13.56mhz, probably just gets 12.5Mbit/sec out of the arriving 13.56.
This is a bit annoying as when you put an 8sample grid on it, sometimes on demodulating you have to shift the grid by a sample to be in sync again.

(the following answer considers that you implemented the sample frequency as i wrote to you).
In assembler i used to do the following in the far past:
starting from the first sample on the aquired signal, wait for the transition from logic bit 0 to logic bit 1, then count a number of samples equal to the half of the tag bit duration (in this case it's 2,5 samples since one tag bit duration is 5 microseconds(5 samples).
on that point, you can start positioning your grid( the grid space should be 5 samples. You will be sure that you will always decode tag information by reading one sample each 5 samples.

I repeat: here i'm considering that you should sample data at 1MSps.

Note: you don't need to sample the tag exactly in the middle of the bit, so your grid could also be shifted left by half sample, in order to fit the second sample of the tag's bit. Your tag reply will always be decoded thanks to your 5 samples grid.

this is always true if it's a mifare tag.

Did i was clear?

Last edited by gaucho (2014-03-22 14:45:42)

Enio · 2014-03-22 22:02:08

Hm sure, we could send less samples.. but why decrease it? For analyzing i.e. power we want as many samplws per bits as possible.

Edit: im wondering, reqa, wupa sould transfer on 106kbs. I get ~8 samples per bit. That means we get 848kBytes/sec data on clock . That is 6.784 Mbs. Thats only half the speed we should get, no? I am now wondering if due to too fast clock on ssp we only get evry 2nd bit off SSC? But if we really only get samples on every 16th 13.56 mhz tick (instead of 8th) = every 848khz = 1/8 106khz tick - why is it misaligned on grid? Do i miss anything? I will test pck0/2 clock tomorrow (12Mhz)

Last edited by Enio (2014-03-23 00:36:23)

gaucho · 2014-03-23 10:18:27

Enio wrote:

Hm sure, we could send less samples.. but why decrease it? For analyzing i.e. power we want as many samplws per bits as possible.
Edit: im wondering, reqa, wupa sould transfer on 106kbs. I get ~8 samples per bit. That means we get 848kBytes/sec data on clock . That is 6.784 Mbs. Thats only half the speed we should get, no? I am now wondering if due to too fast clock on ssp we only get evry 2nd bit off SSC? But if we really only get samples on every 16th 13.56 mhz tick (instead of 8th) = every 848khz = 1/8 106khz tick - why is it misaligned on grid? Do i miss anything? I will test pck0/2 clock tomorrow (12Mhz)

1) if request signal is sent at 106Kbps, the duration of one bit is 106mS. I see that in the request coming from the reader (my oscilloscope measurements) in case of MIFARE tag (HF 14A READ command) one bit duration is about 5microseconds, not 106milliseconds.

Anyway,i f you can, do the tests with pck/2 and when it works, please, upload the image so i will test it.

2) you wrote "why decrease the sampling rate?": because you can not sample at higher frequency than what the device is able to do. if you can read somewhere that the data can be transfered and saved in to arm memory at speed higher than 1MBps, then i will agree with you.

Enio · 2014-03-23 13:50:26

gaucho wrote:

Enio wrote:
Hm sure, we could send less samples.. but why decrease it? For analyzing i.e. power we want as many samplws per bits as possible.
Edit: im wondering, reqa, wupa sould transfer on 106kbs. I get ~8 samples per bit. That means we get 848kBytes/sec data on clock . That is 6.784 Mbs. Thats only half the speed we should get, no? I am now wondering if due to too fast clock on ssp we only get evry 2nd bit off SSC? But if we really only get samples on every 16th 13.56 mhz tick (instead of 8th) = every 848khz = 1/8 106khz tick - why is it misaligned on grid? Do i miss anything? I will test pck0/2 clock tomorrow (12Mhz)
1) if request signal is sent at 106Kbps, the duration of one bit is 106mS. I see that in the request coming from the reader (my oscilloscope measurements) in case of MIFARE tag (HF 14A READ command) one bit duration is about 5microseconds, not 106milliseconds.
Anyway,i f you can, do the tests with pck/2 and when it works, please, upload the image so i will test it.
2) you wrote "why decrease the sampling rate?": because you can not sample at higher frequency than what the device is able to do. if you can read somewhere that the data can be transfered and saved in to arm memory at speed higher than 1MBps, then i will agree with you.

1) I calculate different:
1s = 106kb
1s = 106000b | / 106000
1s/106000 = 1b
~ 0.00000944s = 1b
9.44us = 1b

2) I agree with you, i want to sample as fast as arm can handle to receive. We dont send start/stopbits on ssp, we just send a bitstream. So carrier on ssp/8 is the bitEdit:byterate.
If it turns out we can send 12Mbs (= 1.5MBs = 1.5MSample/s):
1s = 1 500 000Sample
0.00000066 = 1Sample
0.66us = 1 Sample

9.44us /0.66us = ~14.3 Samples per bit received.

Do you agree?

I only get ~the half of that i think. Ok im reading the sheet again, to see the maximum clock on SSP. If you were right with 12Mhz we should be able to get more samples and my code is just bad...
Edit: The full data sheet: http://www.atmel.com/Images/doc6175.pdf

Section 32 is about the SSC. It states in 32.6: "The maximum clock speed allowed on
the TK and RK pins is the master clock divided by 2"

I had the impression that pck0 was exactly that ARM master clock/2. I will do a test to see the data rate we get. Ill send 0-255 Bytes from fpga to arm and see if i get a nice saw wave or if something gets lost.
Edit2:
Test Results so far:
13.56Mhz clock on ssp:
I get a nice saw wave but only every second Sample(byte).
24Mhz pck0 on ssp:
Get every 4rth sample only
Making it a RAMFUNC to be executed from RAM i get roughly evry 3rd sample.
Removing the TX sending 0xFF when ready (its 2 comparisons) i get evry 2nd Sample, sometimes 3rd.
Removing the trigger check inside the for loop i get evry 1 sample, sometime one missing!
Removing check on SSC_SR (SSC status register) and further optimizing code after reading up on it i get every sample. Sometimes TWICE. With adding check for SSC_SR i sometimes miss one sample.

Last edited by Enio (2014-03-23 15:43:54)

Enio · 2014-03-23 18:29:19

Any suggestions?
1) If i read the Recive Hold register (RHR) as fast as possible, without any other checks, then we can get samples at 3MSs. But since i dont check if i the RHR has updated yet (Check on status register SR) we might get a double read of a sample evry now and then.
2) If i check for Status(SR) and read when it has a new sample we do miss evry 6th or 7th Sample. We could lower sampling frequency a bit so there is enough time for both checks in between.

I personally prefer to have the ability to sample with maximum speed. Maybe just implement both modes?

Example:

See the sample count i have for 1 bit. With further optimized sscread function i get a double read on evry 3-4rd sample. So if we could clock pck0 higher we could get even more..

Better idea to sample ADC on 13.56MHz and send bits on SSC with 24MHz - we dont get aliases that way:

To clarify: The samples get in on a 24Mhz clocked SSC line which sends 1 bit each cylce. That means we get Samples in with 3Mega Samples per second. We do not miss any samples, the opposite: As i read the Register where samples come in faster then they arrive, i have a higher samplecount then expected in the plot and they are duplicates of the previous sample(Edit: By calculation with 3MSs we should get 28.6 Samples per bit - on plot i have ~40, so approx evry 4rth sample is a duplicate).. One could tune it by adding some busy-wait cycles between reads to have less duplicates or raise the clock frequency on ssp.
We could also increase bit count per frame on ssc (collect i.e. 4 samples on fpga and send it in frames of 32 bits) - we might have less overhead for checking if something arrived and maybe the 2nd check for status register would be ok then.
And finally we could use interrupts to read the data that came in. Im a complete newbie for that so i might save that for the future.

Edit: And one last snoop with 13.56 on ADC and 13.56 on SSC ( =1.695MSs) and Status Register check enabled. With that speed that check is no issue and we dont miss a sample and we dont get duplicates. You can see very well i have 16 Samples per bit and i dont have any shifts occuring. So the time/sample is not corrupted.

You can easily see now we got the ATQA 0x0400

Flank going down = 1 , going up = 0:

 
1         (Startbit) 
0010 0000 (Byte1 LSB first) That is 0x04
0         (Odd Parity1) 
0000 0000 (Byte 2 LSB first)  That is 0x00
1         (Odd Parity2) 1
EOT       (End of Transmission = no modulation for 1 bit duration)

Beautiful!

fullimage (13.56 on ADC and 13.56 on SSC ( =1.695MSs) and Status Register check enabled): https://www.dropbox.com/s/po8p3zsl950o8 … limage.elf
Triggers after first sample value 255, then skips 10000 Samples, then records to Buffer.

Last edited by Enio (2014-03-23 20:42:20)

gaucho · 2014-03-24 04:39:46

Enio wrote:

1) I calculate different:
1s = 106kb
1s = 106000b | / 106000
1s/106000 = 1b
~ 0.00000944s = 1b
9.44us = 1b

2) I agree with you, i want to sample as fast as arm can handle to receive. We dont send start/stopbits on ssp, we just send a bitstream. So carrier on ssp/8 is the bitEdit:byterate.
If it turns out we can send 12Mbs (= 1.5MBs = 1.5MSample/s):
1s = 1 500 000Sample
0.00000066 = 1Sample
0.66us = 1 Sample
9.44us /0.66us = ~14.3 Samples per bit received.
Do you agree?

yes of course, maybe i was sleeping when i wrote that. I agree entirely.
Very good job.
I'll test the FW ASAP.

Last edited by gaucho (2014-03-24 04:45:45)

Enio · 2014-03-24 21:47:47

Isit working for you?

vivat · 2014-03-25 07:55:36

gaucho
Have you tested your non-working boards?

Enio · 2014-03-25 16:39:15

I checked some datasheets again.

ARM runs at 48 MHz Main clock. SSC max. clock is 24MHz = 3MByte/s data rate.
However, we could raise it up to 55MHz. SSC max. clock would be 27.5 MHz ~3,4375MByte/s datarate.

I would go for it if i had a JTAG device to revive my board when i mess it up, so this has to wait.
If anyone of you wants to play with that and owns a JTAG, let me know, im in for ideas. We would need to find the sections that stop working with different clock speed and modify it, but im positive we could get it to run.

For now i will finish the HF snoop code in the next week and add some configuration for the section in fpga & arm. Im not sure how many options i can put in, but i aim for:
- Set ADC Sample Frequency divider and clock source.
- Set SSC Frequency divider and clock source
- Set ADC input channel (basically muxes in arm)
- Set SSC input source (ADC or test samples)
- Set SSC Data Frame length
- Set SSC read mode (Syncronized with Status Register and "fast as possible" (prone to double samples))

I will design it so that adding functionality to fpga is easy (prepare room for additional configuration values)
i.e. one might want to implement a more sophisticated function that scales the wave down so we get less values per sample while keeping all the peak/low-information. Might be able to send more then double the sample rate then with 4bit samples.

Im debating what to do with the ADC clock, if SSC & ADC clocks are the same, right now we push every 8th ADC sample on the line to ARM. This works fine with PKD mode on HF. Might just sample ADC with SSC_CLK/8 then. But maybe It would be better to send the mean PEAKS? Or mean LOWS? Im not sure how fast the PKD dampens the wave, maybe even a normal MEAN would be more stable then just every 8th sample?

Please, if you have anything to add, ideas or critics for the initial design of this snoop function and client commands - let me know!

gaucho · 2014-03-25 17:04:23

here i am. i was out of office since last 5 days. i was without boards at home.
now i will download and test the fw. which is the implemented command? hf read? hf snop?

my suggestion for the hf snoop command:
-add all the optional parameters that you desire but by default, without parameters, choose the safest way to sample data (the one that you are teorically and practically sure that it is better)
during the study of new tag we need to process data on the pc, so we need also to download data in a file on the pc.

about the mean calculatd on last 8 samples, this is my first impression: don't do it. Because: let's suppose that your signal is changing, in example 4 samples have 128 value and 4 samples have -128 value, the mean is 0 but this is not true, to read the mean is wrong.
The first assumption that we are doing is that we are sampling data at a frequency of at least 10 times the frequency of the signal to be sampled, so no fear about noise or wrong samples. We will have many samples, at least 5, for each sampled bit of the aquired signal. the reconstruction of the signal is a digital filtering and processing problem that we can perform offline.

Enio · 2014-03-25 17:13:03

gaucho wrote:

here i am. i was out of office since last 5 days. i was without boards at home.
now i will download and test the fw. which is the implemented command? hf read? hf snop?

"hf 14b simlisten"

gaucho wrote:

my suggestion for the hf snoop command:
-add all the optional parameters that you desire but by default, without parameters, choose the safest way to sample data (the one that you are teorically and practically sure that it is better)
during the study of new tag we need to process data on the pc, so we need also to download data in a file on the pc.

For now i will keep it in the BigBiffer which we get with data samples. However an option to dump this buffer to a file could be handy, true.

gaucho wrote:

about the mean calculatd on last 8 samples, this is my first impression: don't do it. Because: let's suppose that your signal is changing, in example 4 samples have 128 value and 4 samples have -128 value, the mean is 0 but this is not true, to read the mean is wrong.
The first assumption that we are doing is that we are sampling data at a frequency of at least 10 times the frequency of the signal to be sampled, so no fear about noise or wrong samples. We will have many samples, at least 5, for each sampled bit of the aquired signal. the reconstruction of the signal is a digital filtering and processing problem that we can perform offline.

Note: If ill add any sample selection options, they will be for sure optional.

I dont worry about not detecting bits, but maybe one might want to see the shape of the bits. For some sidechannel attacks a closer look might be cool.

Taking every plain 8th sample might be less accurate (harder to get repeatable results) then for example
1) taking the mean of the peak (or low) of first 4 ADC samples and last 4 ADC samples.
2) Just taking the peak (or low) of 8 ADC samples
3) Analyze 8 samples and start sending samples from the peak of those, and then every next 8th sample

The use of that might heavily depend on the waves you are analyzing, underlying carrier frequency and combination of ADC & SSC clk rates, however it might be cool to have at least the option to set these in the future.

Edit: I forgot to add: I will also add an option for triggering the saampling, and for skipping an amount of samples before they get written into the buffer. As right now, with sampling trigger on maximum sample value, i had to skip 10000 samples to get the samples of the Reader/Tag communication. (Its hardcoded right now..).

Last edited by Enio (2014-03-25 17:52:36)

gaucho · 2014-03-25 18:50:24

yes, it is good to have trigger level and offset from the trigger event. trigger level should be in the same scale of the plotted data (from -127 to 128) in order to be user friendly.

as you said it is also useful (as second step of the development) to allow to sample less bits in order to increase the sampling frequency. Now i don't know which is the best way to do it. I don't know if to select the 4 Most Important Bits or some other method. I will tell you when I'll see it on the tournel.

I made measurements with your new FW.
input signal amplitude: the same of my previous measure (max digitizable amplitude)
input signal shape: sine
point of ijection: TP1
command hitted for hf sampling: Enio's HF 14b simlisten
command hitted for lf sampling: lf read

first tests are with working board, then i did it with the not working boards. the result is the same. there is no problem in the sampling part:

working board with 1KHz sine (command LF READ)

same signal zoomed in

working board with 1KHz sine (command HF 14B SIMLISTEN)

same signal zoomed in

working board with 100KHz sine (command HF 14B SIMLISTEN)

same signal zoomed in

working board with 200KHz sine (command HF 14B SIMLISTEN)

NOT working board with 1KHz sine (command LF READ)

same signal zoomed in

NOT working board with 1KHz sine (command HF 14B SIMLISTEN)

same signal zoomed in

NOT working board with 100KHz sine (command HF 14B SIMLISTEN)

same signal zoomed in

NOT working board with 200KHz sine (command HF 14B SIMLISTEN)

same signal zoomed in

gaucho · 2014-03-25 19:03:06

I've seen that after 15 seconds the board reboots if it didn't find any trigger event.
This should not happen otherwise i have to run to the turnstile and this will cost me a training for 100 meters speed races, in order to increase my legs muscles and may be i also need to start with anabolic medicines and i don't want to do it. ..if not needed for educational purposes.

Last edited by gaucho (2014-03-25 19:05:23)

gaucho · 2014-03-25 19:47:32

update: Asper successful changed the uid for the mifare ultralight with changeable uid.
I write here its results for who purchased this item (me, asper and vivat) with the board.

asper wrote:

i successful wrote uid for mifare ultralight sending RAW commands:
hf 14a raw -c -p -a A20001020304
hf 14a raw -c -p -a A20105060708
hf 14a raw -c -p -a A20200000000
the first command writes bytes 01 02 03 04 in block0
the second command writes bytes 05060708 in block1
the third command writes bytes 00000000 in block2
In factory default, blocks 0 and 1 are readonly.
In factory default, block2 is "partially" read-only
Thanks to a patch that i requested, now we can modify blocks from 0 to 2 for chinese mifare ultralight with a simple write command directly with the function to write the ultralight without the raw commands

Last edited by gaucho (2014-03-25 19:48:13)

Enio · 2014-03-25 19:52:16

gaucho wrote:

I've seen that after 15 seconds the board reboots if it didn't find any trigger event.
This should not happen otherwise i have to run to the turnstile and this will cost me a training for 100 meters speed races, in order to increase my legs muscles and may be i also need to start with anabolic medicines and i don't want to do it. ..if not needed for educational purposes.

Hahaha yes i know, im not exactly sure why that happens though, nothing to spot easy. Its on the plan to investigate for the release version, dont worry!

i wonder why the sines on hf snoop dont have the same Sample shifts as in the lf snoops. Thats odd.
Edit: Gaucho, if you ever happen to have issues with these shifts on the lf snoop, remind me that we could sample on the LF path with higher frequency and send normalized data with lf frequency over the ssc to get rid of these shifts. It seems these chinese ADC have issues with sampling at slow rates.

Last edited by Enio (2014-03-25 19:57:48)

asper · 2014-03-25 19:54:35

Using the pentura's patch we can also use direct mifare ultralight write command using the -w option (already implemented in the new windows gui settings). Those tags are fussy, you must put them 0.5cm from the antenna otherwise strange behaviour occurs (ex. You are able to read but write gives error even if succesful or strange read values).

Enio · 2014-03-25 20:16:59

gaucho wrote:

as you said it is also useful (as second step of the development) to allow to sample less bits in order to increase the sampling frequency. Now i don't know which is the best way to do it. I don't know if to select the 4 Most Important Bits or some other method. I will tell you when I'll see it on the tournel.

I saw our FPGA has 4096 RAM cells - i is it used right now (?) - we could buffer up to 512 samples in there with the highest ADC frequency we can generate (40 MHz max for adc i think). My board already runs on pck0 with 48Mhz (Tested if we can get higher Frequency then Arm Main Clock / 2 on SSC. i had to change any pck0 use to use pck0/2 to keep functionality for the other commands).

It would be as easy to make that 96Mhz and divide at least to 32Mhz. So in theory, we could read 512 8bit samples on 32MS/s (Capture 512 samples in 16ns) and stream it back to ARM later. If thats not cool

gaucho · 2014-03-26 01:12:41

Enio wrote:

i wonder why the sines on hf snoop dont have the same Sample shifts as in the lf snoops. Thats odd.

I've seen it.
I can't explain it.

gaucho · 2014-03-26 13:51:24

i tried to read a mifare with my SL500 and to sniff data with the proxmark.
The SL500, in order to read the tag, powers off the antenna, then it powers it on, and then sends data to the tag.
The proxmark triggers and saves data but the resulting data is a sine waveform with low frequency.
I suppose that powering on and off the antenna, the the proxmark triggers on the powering of the antenna and not on the transmission of the data.

To solve this, the following is required:
-be able to sample data with lower frequency, in order to watch more signal in time domain, and then understand where to zoom.
-be able to set delay from the trigger event (but this will be not sufficient if the delay is not fixed like it is in my case)
-be able to set the number of trigger events to jump before to start aquisition (1=start on first event, 2=start on second event, and so on)

Enio · 2014-03-26 14:01:27

gaucho wrote:

-be able to set the number of trigger events to jump before to start aquisition (1=start on first event, 2=start on second event, and so on)

Good idea.

Might allow diffeent kind and count of triggers. Samples/time/special modulations and count of these.
Especially when we somtime in the future - we can sample 512 with 32MS/s, we need reliable trigger definitions.

gaucho · 2014-03-26 14:14:18

i tried to read a mifare with a working proxmark and to sniff data with another proxmark.
The proxmark triggers and saves data but the resulting data is a sine waveform with low frequency.
I suppose that we're triggering in the wrong point... is it possible? how did you selected the delay? which is the expected delay on hf14a read ?

Enio · 2014-03-26 16:01:49

Darn, yes its hardcoded in aüpmain.c

I skip 10000 samples after trigger..

gaucho · 2014-03-26 16:14:29

i rechecked on microscope the 4 not working boards (also the 2 boards returned from my colleague are not working).
I found some false solderings and may be that now one board is working, but, before to functionally recheck them, i asked to a specialized lab to wash for me the boards because they have a washing machine that washes the boards for 1,5 hours with a solvent. Tomorrow they will give me back the boards more lucent than ever. We will see if there is a problem with the dirty.

Last edited by gaucho (2014-03-26 16:15:15)

gaucho · 2014-03-26 19:54:51

UPDATE: the manufacturer of the mifare ultralight cards suggested alternative method to change the uid: use the acr122u
He wrote me this:

mifare ultralight manufacturer wrote:

please read the api interface of the acr122u
and use direct command the operate
ACR122U Read Page
< FF B0 00 00 04
ACR122U APDU Command
< FF CA 00 00 00

asper · 2014-03-26 21:15:42

About new proxmark group buy i think that a kickstarter.com project/campaign will be far better!

The commands for ACR122U are for the chip inside the reader: after receiving those commands the unit modulate correct raw commands identical to the one showed in previuos post (A2... ecc.) so you cannot use those commands with pm3.

0xFFFF · 2014-03-27 01:05:55

asper wrote:

About new proxmark group buy i think that a kickstarter.com project/campaign will be far better!.

I love the idea.
Personally I wouldn't back the campaign if the only 'reward tier' was for a cut down Proxmark 3.
I would back a project if there was a 'Proxmark 3.5' or 'Proxmark 4'.

gaucho · 2014-03-27 10:35:27

0xFFFF wrote:

asper wrote:
About new proxmark group buy i think that a kickstarter.com project/campaign will be far better!.
I love the idea.
Personally I wouldn't back the campaign if the only 'reward tier' was for a cut down Proxmark 3.
I would back a project if there was a 'Proxmark 3.5' or 'Proxmark 4'.

I think that if i found a proxmark for 50€ 4 years ago, i started developing the firmware 4 years ago, and today the PM3 firmware would have been much better.

Now you have a digitizer and real time transmitter/processing unit, but the real added value is in the firmware.
This community is almost dead, if compared to other communities because of the price of the device.
This is just an opinion.

p.s.: i never used kickstarter, i don't know how it works, there is nothing of really innovative in my proposal.

Last edited by gaucho (2014-03-27 10:38:11)

vivat · 2014-03-27 11:41:38

Hey gaucho
We can get the board even cheaper with parts that cost less. We can change the AT91SAM7S with Cortex M0+, FPGA with cheaper one, 15-20 MSPS ADC.
You said that you have 4 non-working boards, but you had only 2. Have you found other problems or have I missed anything?

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

i told you that my colleague helped me to resolder the boards. He had 2 boards, i wrote it.
Now he returned me that 2 boards.
On one i found a unsoldered pin and i washed it: now it works really fine.
I still have 3 not working boards (washing them doesn't solved the problem):

-board1: it stops on communication with the fpga (i will check the communication line) but the HW tune works fine.
-board2: LF tune not ok(low voltage) and HF 14A READ not ok (i will start checking LF receiving path)
-board3: HF 14A READ works 3 times yes and 1 time no (more or less) but the remaining parts of the board are ok.

Proxmark3 community

Announcement

#451 2014-03-20 08:39:52

Re: proxmark3 gerbers and bill of material

#452 2014-03-20 08:47:33

Re: proxmark3 gerbers and bill of material

#453 2014-03-20 09:27:39

Re: proxmark3 gerbers and bill of material

#454 2014-03-20 17:35:17

Re: proxmark3 gerbers and bill of material

#455 2014-03-20 18:23:35

Re: proxmark3 gerbers and bill of material

#456 2014-03-20 19:14:49

Re: proxmark3 gerbers and bill of material

#457 2014-03-20 21:26:03

Re: proxmark3 gerbers and bill of material

#458 2014-03-20 22:35:38

Re: proxmark3 gerbers and bill of material

#459 2014-03-20 22:43:11

Re: proxmark3 gerbers and bill of material

#460 2014-03-21 04:21:42

Re: proxmark3 gerbers and bill of material

#461 2014-03-21 05:46:42

Re: proxmark3 gerbers and bill of material

#462 2014-03-21 09:03:52

Re: proxmark3 gerbers and bill of material

#463 2014-03-21 09:33:10

Re: proxmark3 gerbers and bill of material

#464 2014-03-21 09:42:26

Re: proxmark3 gerbers and bill of material

#465 2014-03-21 10:06:11

Re: proxmark3 gerbers and bill of material

#466 2014-03-21 10:43:33

Re: proxmark3 gerbers and bill of material

#467 2014-03-21 21:46:55

Re: proxmark3 gerbers and bill of material

#468 2014-03-21 22:09:27

Re: proxmark3 gerbers and bill of material

#469 2014-03-22 05:34:14

Re: proxmark3 gerbers and bill of material

#470 2014-03-22 12:13:45

Re: proxmark3 gerbers and bill of material

#471 2014-03-22 13:51:15

Re: proxmark3 gerbers and bill of material

#472 2014-03-22 14:33:10

Re: proxmark3 gerbers and bill of material

#473 2014-03-22 22:02:08

Re: proxmark3 gerbers and bill of material

#474 2014-03-23 10:18:27

Re: proxmark3 gerbers and bill of material

#475 2014-03-23 13:50:26

Re: proxmark3 gerbers and bill of material

#476 2014-03-23 18:29:19

Re: proxmark3 gerbers and bill of material

#477 2014-03-24 04:39:46

Re: proxmark3 gerbers and bill of material

#478 2014-03-24 21:47:47

Re: proxmark3 gerbers and bill of material

#479 2014-03-25 07:55:36

Re: proxmark3 gerbers and bill of material

#480 2014-03-25 16:39:15

Re: proxmark3 gerbers and bill of material

#481 2014-03-25 17:04:23

Re: proxmark3 gerbers and bill of material

#482 2014-03-25 17:13:03

Re: proxmark3 gerbers and bill of material

#483 2014-03-25 18:50:24

Re: proxmark3 gerbers and bill of material

#484 2014-03-25 19:03:06

Re: proxmark3 gerbers and bill of material

#485 2014-03-25 19:47:32

Re: proxmark3 gerbers and bill of material

#486 2014-03-25 19:52:16

Re: proxmark3 gerbers and bill of material

#487 2014-03-25 19:54:35

Re: proxmark3 gerbers and bill of material

#488 2014-03-25 20:16:59

Re: proxmark3 gerbers and bill of material

#489 2014-03-26 01:12:41

Re: proxmark3 gerbers and bill of material