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.
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.
Well I seem to have done it. I have a new version of code that allows you to specify the low frequency modulation. The FPGA logic for low_read.v and fpga.v has changed so the FPGA needs to be reflashed.
What I've done is implement a way to send specific command/data pairs to the FPGA, so whereas in the original version the ARM could only send an 8 bit configuration byte over the SSP (sync serial port), I've changed it to send a 16 bit word which the FPGA interprets as a 4 bit command followed by 12 bits of data.
Out of the 16 possible commands, only two are impemented. The other 14 FPGA command values can be used in the future for setting internal FPGA parameters should the need arise.
Command 1 is the old fpga config byte (only the low 8 bits of the data is used)
Command 2 sets an internal 8 bit FPGA divisor register used to set the low frequency according to the formula 12Mhz/(divisor+1).
Some example values:
Divisor Frequency
255 46.88Khz
119 100.0Khz
95 125.0Khz
87 136.6Khz
59 200.0Khz
19 600.0Khz
I've simulated the logic with ModelSim and it works for divisor values of 19-255 inclusive (600Khz to 46.9Khz). Divisor values less than 19 can be programmed and they will drive the antenna at the specified frequency, but the logic won't have enough clock cycles to read the ADC and send it back to the ARM, so stick to 19 and over for divisor.
I've also done practical tests by flashing my board and measuring the frequency at the antenna as well as running hidfskdemod and hi14areader to ensure that the old functionality didn't break. Anybody else care to test drive it ?
Example usage:
> setlfdivisor 70
Divisor set, expected freq=169014Hz
#db# Divisor set
> tune
# LF antenna @ 4 mA / 5371 mV [1273 ohms] 125Khz
# LF antenna @ 4 mA / 5505 mV [1187 ohms] 134Khz
# HF antenna @ 47 mA / 11247 mV [235 ohms] 13.56Mhz
> setlfdivisor 80
Divisor set, expected freq=148148Hz
#db# Divisor set
> tune
# LF antenna @ 8 mA / 10742 mV [1273 ohms] 125Khz
# LF antenna @ 8 mA / 10473 mV [1187 ohms] 134Khz
# HF antenna @ 47 mA / 11247 mV [235 ohms] 13.56Mhz
> setlfdivisor 90
Divisor set, expected freq=131868Hz
#db# Divisor set
> tune
# LF antenna @ 32 mA / 41491 mV [1273 ohms] 125Khz
# LF antenna @ 34 mA / 41491 mV [1187 ohms] 134Khz
# HF antenna @ 47 mA / 11214 mV [235 ohms] 13.56Mhz
It should go without saying that if you muck around with the divisor, set it back to 95 if you plan to read some 125Khz tags or else the LF reader functions won't read too well
Offline
I'd be very interested to test this!
Can you update the firmware distribution package using my latest version (still in the upload section on the site, I believe, 20090328_ela.zip ) and put the fpga image in s19 format in the zipfile ? - if this is not too much to ask for of course ;-)
Ed
Offline
Then I will do my best to re-order the uploads
There are 2 more files there, they are from bizongod right?
Offline
Then I will do my best to re-order the uploads
There are 2 more files there, they are from bizongod right?
Yes, I think so.
Maybe we should consider a SVN for source code management?
Offline
That would be perfect. I see the files section more as a dump for useful files.
We could store there "stable" releases, but for real development I vote for svn.
Do you mind to set up a google-code project?
To be honest, we started a project months ago, but it never came from the ground.
(http://code.google.com/p/proxmark/).
Since I'm not the administrator, we can maybe better start a new one.
Let's call this proxmark3 or something. I'll make sure the other one will be migrated to the new one.
Let me know what you think.
Offline
I'd be super keen on SVN too otherwise we trip across each other as we make changes. For now I've uploaded vlf_090409_prox.zip (S19 files only) for those super keen to test this new version.
For a little surprise try:
sweeplf
losamples
hpf
plot
It should be obvious what that is but if anyone needs it explained, just ask
Source code will follow but we need to sort out some issues. For example this new version is based on 20081211 as I had some problems with doob's version and I didn't even see 20090328_ela as it's in a different directory from the others.
At this point we have a fork in the code and I don't want that, we need to merge the version and test everything to arrive at a new stable release.
Roel the files in the upload dir currently are:
20090328_proxmark_ela.zip edo512's new version code with Generic ASK & Manchester decoding for LF tags
pm3.1b.1.rar BizonGod's new hardware revision of PM3
vlf_090409_prox.zip binary only of the variable frequency code in this post (leave it in uploads for a week or so then delete it).
proxmark3-eagle-batchpcb.zip This is the zip I uploaded to BatchPcb after having had to move some vias to fix their DRC bot's whining. Turns out that after all that, from what I was reading in their forums, they do not offer 4 layer PCB service as there is no demand for it so the PM3 may not be orderable through BatchPcb.
Last edited by d18c7db (2009-04-09 00:52:41)
Offline
Ok, I've moved edo's version to the sources dir. Your batchpcb files to a PCB dir, your test binairies to the binairy dir and bizongod's files to "hardware revision".
Let's make the file section for "stable" releases and keep the SVN for test releases.
It is very sweet to see quite a few active members are working on this. I will try to find time soon to redesign the whole USB framework.
Offline
I'd be super keen on SVN too otherwise we trip across each other as we make changes. For now I've uploaded vlf_090409_prox.zip (S19 files only) for those super keen to test this new version.
For a little surprise try:
sweeplf
losamples
hpf
plotIt should be obvious what that is but if anyone needs it explained, just ask
Hmm... Actually, we'd need the updated host client too
Offline
Oh, see 20090409_prox.zip in the uploads. This is my new changes merged into 20090328_proxmark_ela so it hopefully works OK. Consider this code as non stable until proven otherwise through testing.
I still need to tidy up some things, add some comments etc
Offline
Hi!
Just tested your code, looks good at first sight, the sweeplf command is nice to check whether the LF antenna actually resonates at 125kHz or not
I added the code to SVN since it does not seem to break anything else as far as I can tell...
Offline
Hi,
I noticed that your source code currently resets the FPGA frequency divisor each time when calling 'loread', as well as when calling 'tune': ideally, we'd need to update the loread & tune commands to remove the "h" option, or maybe better, introduce a "c" (for "custom"?) option for free setting of the LF divisor ? What do you think ?
Ed
Offline
RIP sweeplf.
I've removed the sweeplf command but don't cry, it's now integrated into tune. Also removed some of the tune displayed values (current/impedance) as they can be easily calc'd and not really relevant. The voltage across the coil is the only measure we seem to use for tuning.
Tune now shows this:
> tune
#db# Measuring antenna characteristics, please wait.
# LF antenna: 25.38 V @ 125.00Khz
# LF antenna: 37.73 V @ 134.00Khz
# LF optimal: 40.95 V @ 129.03KHz
# HF antenna: 10.22 V @ 13.56Mhz
The idea is that there are enough commands already on the PM3, we don't need an extra one if the functionality can be integrated into an existing command. The tune command leaves the good stuff in the buffer so you can still use losamples and plot for the eye candy after a tune command. Tune takes about 8 secs to complete now due to the sweep. The output of tune should be obvious, "LF optimal" shows where the antenna really resonates during the sweep. Should have really called it "LF resonant" but optimal makes the text line up better.
Offline
Heh! You beat me to it... I was planning to do something similar!
Nice work!
Oh, and speaking of lining up text, I've prettified the output slightly...
Offline
LOL %9.2f kHz? Are you expecting that big a value ever? I think %3.2f is plenty. That goes for the 5.2f voltage readings which are now in Volts not mV, remeber the zenners cut off voltage above 47V so at most you'll measure %2.2f voltage readings and %3.2f frequency (which is already in Khz).
Last edited by d18c7db (2009-07-13 14:49:48)
Offline
proxmark3> tune
> tune
#db# Measuring antenna characteristics, please wait.
proxmark3> proxmark3>
# LF antenna: 0.00 V @ 125.00 kHz
# LF antenna: 0.00 V @ 134.00 kHz
# LF optimal: 0.00 V @ 12000.00 kHz
# HF antenna: 9.99 V @ 13.56 MHz
# Your LF antenna is unusable.
proxmark3>
Offline
It seems like this function doesn't work with the latest firmwares.
Changed the divisor for a frequency around 66kHz but I could read an EM4102-tag with this setting, so I think the "lf read" command ignores this setting and still runs it on 125kHz.
Edit: Noticed this in armsrc/lfops.c which forces the reading command to use only 125 or 134.8kHz.
void AcquireRawAdcSamples125k(int at134khz)
{
if (at134khz)
FpgaSendCommand(FPGA_CMD_SET_DIVISOR, 88); //134.8Khz
else
FpgaSendCommand(FPGA_CMD_SET_DIVISOR, 95); //125Khz
My suggestion is to have an option on the "lf read" command to read with the desired divisor directly if it's possible!
Last edited by urkis (2013-09-15 16:13:43)
Offline
sorry for the Offtopic, please delete this message if it hurts.
I'm tring to get answer from roel (rule) about a group buy for the PM3. read this post http://www.proxmark.org/forum/viewtopic.php?id=1599&p=3
does someone knows how to contact him?
thank you. sorry. bye.
Offline