RfidResearchGroup / proxmark3

Iceman Fork - Proxmark3
http://www.icedev.se
GNU General Public License v3.0
3.81k stars 1.01k forks source link

Real-time LF sampling #2167

Closed wh201906 closed 10 months ago

wh201906 commented 10 months ago

(moved to #2173)

  1. The client side doesn't handle these samples. To get the samples, you need to run socat with -x option to log the data, then plot it somewhere.
  2. When starting bulk tranfer, \~3 samples will lost due to the time cost. Some of the USB transfer payload can be distributed into every sample. (Done in 523fde21a4ce0e62ed299cce3ed2cb6814f67ffa)
  3. I use the verbose option as a flag for real-time sampling (-r for real-time sampling)
github-actions[bot] commented 10 months ago

You are welcome to add an entry to the CHANGELOG.md as well

wh201906 commented 10 months ago

2. When starting bulk tranfer, ~3 samples will lost due to the time cost

Maybe this is caused by the -x option in socat Test hw status:

socat -dd /dev/ttyACM0,raw,echo=0,b115200 udp-listen:18888,fork,reuseaddr
Transfer Speed PM3 -> Client... 732160 bytes/s

socat -dd -x /dev/ttyACM0,raw,echo=0,b115200 udp-listen:18888,fork,reuseaddr
Transfer Speed PM3 -> Client... 325354 bytes/s

stdbuf -oL socat -dd -x /dev/ttyACM0,raw,echo=0,b115200 udp-listen:18888,fork,reuseaddr &> lfread3.txt
Transfer Speed PM3 -> Client... 304956 bytes/s

# Can be optimized by this
stdbuf -oL socat -dd -x /dev/ttyACM0,raw,echo=0,b115200 udp-listen:18888,fork,reuseaddr &> /mnt/ramdisk/lfread3.txt
Transfer Speed PM3 -> Client... 675840 bytes/s
iceman1001 commented 10 months ago

Interesting However, all those USB stuff doesn't belong in the lfsampling... you need to refactor it

wh201906 commented 10 months ago

Yes I will. The commits there are only for test now. I'll clean up the code and squash the commits once everything is done.

iceman1001 commented 10 months ago

I am happy to see your great efforts of making the proxmark3 run better with new functions.

wh201906 commented 10 months ago

In cast that I miss the review advices you provided, I'll apply all of them first and rewrite the commit history as need.

wh201906 commented 10 months ago

@iceman1001 Do you consider using the unlikely() GCC extension? The arm code is always compiled with gcc-arm-none-eabi on all platforms. If you don't like it I will revert the changes about them.

wh201906 commented 10 months ago

Well it looks like the unlikely() is undefined. I tested it with Compile Explorer and it shows it's undefined, just like the CI output. However, the __builtin_expect() does work, so we need to add an extra #define for it if we need unlikely()

iceman1001 commented 10 months ago

I seriously doubt that the ___builtinexpect() call will improve the loop much.

and since we compile it on decently recent versions on the gcc-arm-none-eabi compilers (2018-2022 ish) across the OS platforms, we can add it.

I would love to see if there is actually some gains, otherwise these hints adds more confusing when trying to read the code.

wh201906 commented 10 months ago

I see

wh201906 commented 10 months ago

@iceman1001 The samples can be fetched to the client now. https://github.com/RfidResearchGroup/proxmark3/blob/e44161bb602fe9b5c37daf052eff281f7732521f/client/src/cmdlf.c#L716-L718 The real-time sampling process can be stopped by pressing Enter on the client or pressing the button on PM3. It can also be stopped if it reaches the number of -s option. How can I store them into a file compatible with the .pm3 format? Is there any existing function for this?

wh201906 commented 10 months ago

@iceman1001 The real-time lf read is working now. However, I added some of the code from cmddata.c to cmdlf.c to make it work. Plus, the graph buffer is not resizable, so it's hard to plot and save all of the samples. I think we need to refactor the code.

iceman1001 commented 10 months ago

Nice!

data save -f is the function all. it save the length of what has been loaded onto the graphbuffer.

wh201906 commented 10 months ago

Here are some bugs when bit_per_sample is not 8

  1. async_usb_write_requestWrite() always returns false
  2. the client crashes after receiving the data should be fixed now
wh201906 commented 10 months ago

I've cleaned up the commit history and made a new PR #2173.