Proxmark3 community

Research, development and trades concerning the powerful Proxmark3 device.

Remember; sharing is caring. Bring something back to the community.


"Learn the tools of the trade the hard way." +Fravia

You are not logged in.

Announcement

Time changes and with it the technology
Proxmark3 @ discord

Users of this forum, please be aware that information stored on this site is not private.

#1 2010-02-06 10:49:21

adam@algroup.co.uk
Contributor
From: UK
Registered: 2009-05-01
Posts: 203
Website

Graph offset - difference between LF and HF

We currently have two commands for getting samples into the graph - lfsamples and hfsamples... They are essentially the same, but lfsamples offsets the data by -128, which means it uses the whole graph window and you can see when the sample goes positive/negative... With hfsamples, this does not get applied, so everything sits above zero... I have a patch that replaces both these commands with 'samples', and uses the -128 offset...

Is there any reason not to apply it?

Offline

#2 2010-02-06 13:58:24

iZsh
Contributor
Registered: 2010-01-02
Posts: 95

Re: Graph offset - difference between LF and HF

I don't think so, but you can show the patch for review, I guess, if you want to be sure.

We just need to be careful that one doesn't need to "just know" he has to apply a -128 offset to process the LF samples. So it really depends on your patch and its n00b usability.

Offline

#3 2010-02-06 16:23:11

adam@algroup.co.uk
Contributor
From: UK
Registered: 2009-05-01
Posts: 203
Website

Re: Graph offset - difference between LF and HF

The graph buffer is used for some operations:

$ find . -name *.c -exec grep -l GraphBuffer {} \;
./armsrc/lfops.c
./client/graph.c
./client/cmdhf14b.c
./client/cmdhf15.c
./client/cmdlfem4x.c
./client/cmdlf.c
./client/cmdlfti.c
./client/wingui.c
./client/cmdlfhid.c
./client/cmddata.c

We can discount the lf operations, because they're already using the -128 offset, and the display ones, so that only leaves:

/client/cmdhf14b.c

Looking at CmdHF14BDemod, it looks to me that all operations are relative, so it wouldn't change any functionality but I don't have any 14b tags to test against....

In any case, it should maybe be getting data from the pm3 buffer instead of relying on what's lying around in the graph buffer?

./client/cmdhf15.c

I've tested this against an ISO 15693 part 3 TAG with the current version and my patched version, and both correctly demodulate after 'hf 15 read' 'data samples 5000' (or 'data hfsamples 5000')...

patch:

Index: client/cmddata.h
===================================================================
--- client/cmddata.h    (revision 329)
+++ client/cmddata.h    (working copy)
@@ -14,10 +14,9 @@
int CmdFSKdemod(const char *Cmd);
int CmdGrid(const char *Cmd);
int CmdHexsamples(const char *Cmd);
-int CmdHFSamples(const char *Cmd);
int CmdHide(const char *Cmd);
int CmdHpf(const char *Cmd);
-int CmdLFSamples(const char *Cmd);
+int CmdSamples(const char *Cmd);
int CmdLoad(const char *Cmd);
int CmdLtrim(const char *Cmd);
int CmdManchesterDemod(const char *Cmd);
Index: client/cmddata.c
===================================================================
--- client/cmddata.c    (revision 329)
+++ client/cmddata.c    (working copy)
@@ -429,30 +429,6 @@
   return 0;
}

-int CmdHFSamples(const char *Cmd)
-{
-  int cnt = 0;
-  int n = strtol(Cmd, NULL, 0);
-
-  if(n == 0) {
-    n = 1000;
-  } else {
-    n/= 4;
-  }
-
-  for (int i = 0; i < n; i += 12) {
-    UsbCommand c = {CMD_DOWNLOAD_RAW_ADC_SAMPLES_125K, {i, 0, 0}};
-    SendCommand(&c);
-    WaitForResponse(CMD_DOWNLOADED_RAW_ADC_SAMPLES_125K);
-    for (int j = 0; j < 48; ++j) {
-      GraphBuffer[cnt++] = (int)(sample_buf[j]);
-    }
-  }
-  GraphTraceLen = cnt;
-  RepaintGraphWindow();
-  return 0;
-}
-
int CmdHide(const char *Cmd)
{
   HideGraphWindow();
@@ -474,7 +450,7 @@
   return 0;
}

-int CmdLFSamples(const char *Cmd)
+int CmdSamples(const char *Cmd)
{
   int cnt = 0;
   int n;
@@ -880,10 +856,9 @@
   {"fskdemod",      CmdFSKdemod,        1, "Demodulate graph window as a HID FSK"},
   {"grid",          CmdGrid,            1, "<x> <y> -- overlay grid on graph window, use zero value to turn off either"},
   {"hexsamples",    CmdHexsamples,      0, "<blocks> [<offset>] -- Dump big buffer as hex bytes"}, 
-  {"hfsamples",     CmdHFSamples,       0, "[nb of samples] Get raw samples for HF tag"},
   {"hide",          CmdHide,            1, "Hide graph window"},
   {"hpf",           CmdHpf,             1, "Remove DC offset from trace"},
-  {"lfsamples",     CmdLFSamples,       0, "[128 - 16000] -- Get raw samples for LF tag"},
+  {"samples",       CmdSamples,         0, "[128 - 16000] -- Get raw samples for graph window"},
   {"load",          CmdLoad,            1, "<filename> -- Load trace (to graph window"},
   {"ltrim",         CmdLtrim,           1, "<samples> -- Trim samples from left of trace"},
   {"mandemod",      CmdManchesterDemod, 1, "[ i] [clock rate] -- Manchester demodulate binary stream (option 'i' to invert output)"},

Offline

#4 2010-02-06 17:39:41

iZsh
Contributor
Registered: 2010-01-02
Posts: 95

Re: Graph offset - difference between LF and HF

GraphBuffer is a misleading variable name IMHO, it should be named DataBuffer, but I'm planning to rename it soon smile

If the -128 is arbitrary and without consequences for hf commands then yeah, you can go ahead with your changes. The only remaining difference between the two functions is the default sample size to download. But I have a change in mind which will eliminate to specify any size anyway, so it's probably only a temporary issue.

Offline

Board footer

Powered by FluxBB