Proxmark3 community

marshmellow

Contributor

From: US

Registered: 2013-06-10

Posts: 2,302

clean up the data commands structure

as a group if we are worried about the number of commands in the "data" group we could consider moving or removing some of the following:

Possible to remove:

bitsamples  (another data samples just without the argument for how many samples to get - it gets 12288 samples)
bitstream  (looks like another ask/manchester demod attempt)
fskdemod
askdemod
mandemod
threshold (we now have dirthreshold)

Possible to Move (maybe to data adv ?):

dec (decimate samples)
amp (amplify peaks)
hpf (zeros graph mean)
hexsamples
norm (min/max to +/-500) (note: will break new demod functions - should change to +/-128)
zerocrossings

thoughts?

iceman

Administrator

Registered: 2013-04-25

Posts: 9,538

Website

Re: clean up the data commands structure

Maybe add a  "graph" command and move  buffclear, show, hide, scale, ltrim, rtrim, tune

I think "bitsamples" or "bitstream"  (one is sufficient) to get a "raw" signal to 1/0's  could be interesting when looking att unknown tags.
the old fsk,ask,man demod can go away.

Threshold, dirtythreshold,   I'm not sure what is was for.

marshmellow

Contributor

From: US

Registered: 2013-06-10

Posts: 2,302

Re: clean up the data commands structure

The threshold commands helped manual demodulating graphed waves and it sometimes helped the old mandemod command.

iceman

Administrator

Registered: 2013-04-25

Posts: 9,538

Website

Re: clean up the data commands structure

I think we will need to have the commands that helps with manual decoding a tag.

marshmellow

Contributor

From: US

Registered: 2013-06-10

Posts: 2,302

Re: clean up the data commands structure

Yes but my point was we probably don't need both threshold commands, or we can move them (as they are now rarely needed) to a data adv menu

Last edited by marshmellow (2015-01-03 14:11:24)

iceman

Administrator

Registered: 2013-04-25

Posts: 9,538

Website

Re: clean up the data commands structure

Which one to keep?  the newew dirtythreshold?

And wasn't some of these commands added since the old *demod commands worked so bad?

marshmellow

Contributor

From: US

Registered: 2013-06-10

Posts: 2,302

Re: clean up the data commands structure

I would lean towards the new dirthreshold, and yes that one was created because the old ask demods had more problems.  But it may still be useful for manual graph demodulating.  I don't think we need both tho

iceman

Administrator

Registered: 2013-04-25

Posts: 9,538

Website

Re: clean up the data commands structure

Well, by all means, lets agree on mark the old "threshold" as  obsolete in the code and comment it out.

marshmellow

Contributor

From: US

Registered: 2013-06-10

Posts: 2,302

Re: clean up the data commands structure

I'm struggling with what should be under the "data" sub menu.

It is focused around graphing lf waves.

Some demods and decodes have been under data ( now there are more ), but others are in various lf sub menus.

One nice benefit of the data section is the offline capabilities to load up an old or remote trace and do things with it.

And it is nice having the commands that you know can get and use the data loaded into the graphbuffer all in one place.
  I.e. data load - data fskhiddemod

But if we put demod commands in data, do we put Sim commands or clone commands in data as well?

Or should we only put raw binary demods and not specific tag demods under data and move the specific tag demods to their respective lf ... Menus?
  I.e. data load - lf hid graphdemod

Thoughts?

Last edited by marshmellow (2015-01-15 04:12:57)

marshmellow

Contributor

From: US

Registered: 2013-06-10

Posts: 2,302

Re: clean up the data commands structure

Sorry i was fighting the website last night and that last post was incoherent...  I've fixed it now...

Last edited by marshmellow (2015-01-15 04:14:25)

iceman

Administrator

Registered: 2013-04-25

Posts: 9,538

Website

Re: clean up the data commands structure

the question is if it is useful to change the complete commands structure for the client.
Right now it is a mix as you have noticed between "freq/tag-brand/cmds"    and  "freq/analysing"    where the LF side has most mixes..   

Maybe we should have  "FREQ/TAG-BRAND/CMDS"  still?

The DATA would become

/DATA/ANALYSE    (Marshmellows ADV suggestion)
/DATA/SIM
/DATA/MODULATE

I don't know if its worth the effort.  Not so many people seem to be using the PM3 device.

Last edited by iceman (2015-01-15 10:50:51)