Basically I remembered that last year someone wanted the ability to be able to drive the low frequency antenna at an arbitrary frequency from say anywhere between 100khz to 200khz. This frequency is currently determined by PCK0 which is driven by the ARM at 24Mhz and divided internally in the FPGA by 12 or 11 and then again by 16 to get one of only two final drive frequencies of 125Khz or 136Khz. Because on the ARM side you can only drive PCK0 at 24/12/6/3/etc MHZ but nothing in between, if you want fine control of the final frequency you're restricted to having to divide that clock down in the FPGA as in the current design.
I noticed that the Synchronous Serial Port can provide clock via SSP_CLK and that this clock frequency is set by the formula SSP_CLK=MCK/2*SSC_CMR where MCK is the Master Clock = 48Mhz and SSC_CMR is a 12 bit ARM register. Due to the high resolution of the divisor (12 bits) one could in principle drive SSP_CLK anywhere from 24Mhz to about 6kHz in 6Khz steps (numbers are slightly rounded but close). Due to the further neccessary division by 16 in the FPGA (and doing away with the divide by 12 or 11) one could drive the low frequency antenna from 1.5Mhz to 366Hz in 366Hz steps (in theory) but of course in practice most of this range is of no use as the physical antenna has only a fairy narrow frequency response so it wouldn't make much sense driving an antenna dimensioned (tuned) for 125Khz at 1Mhz for example. You would nevertheless have fine frequency control in the range of interest from say 100Khz to 150Khz, or of course by having an assortment of physical antennas tuned for different ranges nothing could stop you from using the entire 1.5Mhz range, really.
On closer investigation of my idea there are however two fairly big problems. First, the SSP_CLK is always an output from FPGA to the ARM (ie the FPGA drives this pin). While the ARM can also drive this pin, the FPGA needs to be reconfigured so that pin is an input. There is a danger that through bad programming, one could have the FPGA and the ARM both driving this pin and this would be "A Bad Thing" as damage could occur. Secondly and more importantly, I don't see an easy way to have that FPGA pin act as an input sometimes and an output at others (my FPGA/Verilog skills are fairly rudimentary).
After this long story, I think it would be far far easier to implement a high resolution programmable divisor in the FPGA than proceed with the above SSP_CLK idea.
]]>Hey just a quick caution message regarding 20090301_proxmark_doob.zip
thx, so wait for ur new version is my choice!
]]>This will be fixed when I upload a new version in the next few days if the idea I'm working on pans out otherwise you've been warned
]]>Anyway, that is a long way of saying it shouldn't have made any difference to either the button functionality and certainly not the tune function but it is possible - I'll look at that again. Once I can get ReaderISO1443a equipped with a bigger buffer I'll post updated version - If I can see why either of the above may be happening I'll also let you know.
cheers
]]>I'd flash my pm3 using the newest "20090301_proxmark_doob.zip" version, but when I use "hi14asnoop" to snoop the communications, I can't stop the snooping process via the push-butoon ("SW1" component) as I do with the "20081211" version. and it's very strange that the returned-parameter of "tune" is half lower than the "20081211" version (but the antenna) is the same one.
anyone can help me? thx a ton in advance!
BR.
Ryan