lf antenna power strength changes the amount of time to power the antenna on sim or write

[marshmellow42]

i've noticed this before but it is very apparent with the rdv4.0 hardware. i'm going to try to explain the issue to see if anyone has any ideas how we can adjust for it automatically without different code per antenna hardware...:

take a simple t55xx write command we bitbang the antenna on and off the code says our timings should be as follows: start gap 31 8us (or 31 125khz samples) write gap 20 8us write_0 bit 18 8us write_1 bit 50 8us

when measuring a first generation pm3 with a semi weak antenna the results are as follows: (note measurements are imperfectly taken from another pm3 NOT oscilloscope - my only tool atm.) start gap 32 125khz samples write gap 20-21 125khz samples write_0 bit 18-19 125khz samples write_1 bit 49-50 125khz samples

as we can see we had some time lost during power on that ended up in the gaps (power off) but minimal

when measuring a rdv4.0 pm3 with a 70v antenna the results are as follows: start gap 34 125khz samples write gap 22-24 125khz samples write_0 bit 17 125khz samples write_1 bit 47-48 125khz samples

this is a drop of over 2*8us per power on vs the other hardware version. i've noticed a similar issue (but not to this degree) when changing lf antenna's from weak ones to stronger ones on my old pm3's.

is there a linear time per volt that can be accounted for to adjust the power up delays?

ultimately this issue affects t55xx cards ability to "hear" the commands as they become borderline out of spec. (it will also significantly affect fsk or psk simulation.)

[iceman1001]

Interesting subject.

T5577c datasheet says min-typical-max values are pretty leanient

          min typ max
Start gap 8 15 50
write gap 8 10 20
write_0  16 24 32
write_1   48 56 64

Looks like

• write gap is too large as it is now. 22-24.
• write_0 is too short 17

RDV40 and 2*8us drop, is still within t5577 specifications.

[marshmellow42]

however, for every version of the t55xx chips those timing requirements changed a little. finding a happy medium that works with all antenna's and all chips is a tighter margin that it appears.

but this is just an example that illustrates a problem that will affect every lf transmit command...

i can adjust timings for t55xx but on my hardware it may result in working commands and on someone else's hardware it may not.

[marshmellow42]

a better example would be psk simulation. for psk1 fc/2 rf/32 simulation has to alternate the antenna on and off every 16us except when a bit change happens then it holds the antenna on one extra fc or 8us. this is tight timing... FSK is similar (not as tight but fairly tight)

[tssmcu]

For t55xx Writing, I think you are right ,they become borderline out of spec. Because the sine wave VPP Fall down speed become slower when voltage is higher. When I design it I missed it .
My suggestion is : 1)add an handle switch to low the voltage, just for T55xx writing. or add an transistor
to do it automic. 2)Can we keep the timings in old one, that will make the wave not 100% ASK， We can test. Maybe T55xx can understand. Maybe he is more redundant to ASK than gap timings.

"it will also significantly affect fsk or psk simulation." Actullay, It won't affect simulation. the simulation circle is tatolly changed. Completely separated by optocoupler isolation and modulated by separate transistors. I think the lf simulate are much better than before. Farther distance. Compatible more readers. I have tested ASK(EM TAG) and FSK(HID tag), I don't have PSK readers. Please help me to test simulation. I hope I 'm right :)

[marshmellow42]

I haven't tested the simulation on the rdv4.0 yet. I suppose I assumed a similar timing issue would present itself due to using the same high voltage antenna.
You sound as if you know much more about hardware than I do, so I'll retract my comment about simulation until I've tested it. (On my todo list)

As far as your suggestions, I just want to be sure I understand: for 1, you're saying modify the rdv4.0 lf antenna hardware with a switch (or transistor) to lower the voltage anytime we want to write to a t55xx chip? (Or any lf chip for that matter)

And for 2, are you saying if we keep the existing timing it may work because it is different enough from an ask modulation the chip might recognize it as a cmd anyways? Not sure I followed that right...

[tssmcu]

@marshmellow42 For 1, and for 2. Yes, That's what I want to say. You are very right! chip might recognize it as a cmd. Looking forward to your test results, I'm glad you are very concerned about PM3&RDV4.0. I hope the PM3&RDV4.0 will become better and better.

[marshmellow42]

T55xx writing is very touchy with the rdv4.0. It only works ok on large tags and if the tag is positioned just so. And even then it isn't very reliable, 80% maybe.
On smaller tags like keyfobs you have to remove the antenna cover and place keyfob directly on the antenna and it might work 50% of the time.
This is much less reliable than the older hardware with a custom 40v antenna.

[tssmcu]

That is too bad. I need to buy some keyfob T55XX to test. And find out the solution.

[marshmellow42]

i just re-tested and even larger tags are worse than 80%. you have to get the card in exactly the right spot to get it to work at all.. and even then it is not consistent. i noticed some comments on the kickstarter complaining about t55xx writing not working as well.

in testing a few different timing settings i was unable to make it better. (there are a lot of possibilities though so i didn't exhaust them all..) so this may NOT be something we can fix with software...

[marshmellow42]

also i verified that all simulating (including psk) works well (against universal readers) with the rdv4.0. I stand corrected!

[pwpiwi]

It might help if someone can publish the RDV4.0 schematics. They should be GPL.

[marshmellow42]

i tend to agree. in the mean time i doubt high res photo's would help would they? ;)

[marshmellow42]

nope, pics won't help at all, as several components have had their markings burned off...

[pwpiwi]

Hmmm, usually this would be an indicator for the opposite of a GPL system...

[marshmellow42]

I tried a custom antenna built for my other pm3s and it doesn't tune at all. There must be major antenna circuit differences.

[tssmcu]

I have bought some small T5577 tags , but I don't find the issues... If it is possble, can you seet me some sample? And from the result , the writing distance of RDV4.0 ,is waker than EASY, but small diffrent. and I have no idea why the second tag has such long distance. I guess the dielectric constant of materials is different.

[TomHarkness]

@tssmcu You are missing a crucial screw on the LF antenna which will be contributing to this!!!! I can read t55 key fobs from very good distance on my v4!!!

[TomHarkness]

Example - the below t55 detect and lf search are with the keyfob about 5cm from antenna.

[tssmcu]

HAHA! no worry, it is a naughty crew. When I take pic it gets lost :)

[iceman1001]

Well, @marshmellow42 claims that its is the T5577 commands and on forum he claims serious writing problems So what needs to be tested is T5577 read/write operations in order to verify his claims.

@tssmcu did you test lf t55xx commands like reading / writing ? @TomHarkness you have a bunch of different custom antennas to test the lf t55xx part and against glass chip..

[tssmcu]

No, I use" lf em em410x write" &" lf hid clone" instead of lf t55xx commands.

[TomHarkness]

@iceman1001 Yes - I have a lot to test with! I only received my v4 yesterday and will have time for testing once I get home tonight! I will update here once I have more details. There is no point with glass chip and stock antenna - we are working on a solution and will have some news soon.

Please see above with up[dated pics of stock antenna read distance - for me this is better than the "easy" model or my rdv2 even!

[TomHarkness]

Ok so.

@marshmellow42 - I just tried all of my custom LF ones and they work fine when connected between the two screw terminals for the LF antenna. Are you connecting directly to the GND & LF RAW? You do see that there is a need for a tuning cap and connection to PWR yes? On the rvd2 the tuning components were on the mainboard - not antenna. There is your problem.

Edit: fine with the exception that they are not tuned properly for the set of components on the stock antennas. They work, but could be better..

@iceman1001 see above for antenna explanation. I'll do some testing with t55 but I have not experienced any issues so far and have already been doing a lot of writing to glass key fobs LF & HF - cards and glass tags (with previous custom antennas) etc.. The trick is to not have them to close to the antenna haha - lots of power guys!

@tssmcu - I'll get you samples some tags and cards that I have :)

Did notice while helping a friend set up pm3 client on Mac that the cards that came with his rdv4 were not coming up for lf search or lf t55 detect. Once programmed with an ID though this was resolved.

Also guys there is a major client software issue if people are on OS X AND... ONLY and if they are using XQuarts xwindow system for the plot gui. Uninstalling Xcode will resolve a lot of issues for many many users.. Issues can present like:

First few commands are fine. And then you may see:

Lag, long time for pm3 to respond No response unless enter pressed multiple times Tags not reading correctly both HF and LF - i.e. M1 S50 shows a blank 15a tag with 00000.. uid and all values.

More probably. I tried this with all pm3 forks.

~TH

[marshmellow42]

cool, i wish i had your guy's pm3 rdv4.0. none of my antenna's will make a t55xx or em4x05 cmd work consistently without the tag being a large tag (clamshell or cr80) and being directly on the antenna (cover off)
and there were 2 people on the kickstarter comments that appeared to have very similar problems. with no confirmations that it was working for anyone i may have jumped to the wrong conclusion that ALL the devices are affected, when it certainly appears they are not all affected.

[marshmellow42]

(and yes my antenna(s) are plugged in):

Measuring antenna characteristics, please wait.........
# LF antenna: 66.82 V @   125.00 kHz
# LF antenna: 36.99 V @   134.00 kHz
# LF optimal: 66.82 V @   125.00 kHz
# HF antenna: 36.26 V @    13.56 MHz
Displaying LF tuning graph. Divisor 89 is 134khz, 95 is 125khz.

proxmark3> hw ver
Prox/RFID mark3 RFID instrument
bootrom: master/v2.2.0-887-g913a54a-suspect 2018-07-30 16:16:51
os: master/v2.2.0-903-gd62f7ba-dirty-suspect 2018-08-23 15:01:31
fpga_lf.bit built for 2s30vq100 on 2015/03/06 at 07:38:04
fpga_hf.bit built for 2s30vq100 on 2018/08/13 at 21:22:51
uC: AT91SAM7S512 Rev B
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 512K bytes. Used: 196260 bytes (37%). Free: 328028 bytes (63%).
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory
proxmark3>

[marshmellow42]

works: doesn't work:

[marshmellow42]

yet simulation, and all (raw) lf reading functions work fine... and i can snoop the write command with a second pm3 and see it fine. (which i why i originally thought it was just a command timing issue...)

[iceman1001]

All lot of testing went into RDV40 so we are very keen on sorting out potential flaws if our design is the cause of it. We are aware of glass-chips and card sized tags doesn't fit the LF smaller sized antenna on our dual antenna and that would make a bad coupling between tag and antenna.

The signal also needs to be centralized (data shiftgraph 0) for tags.
Not to forget that the Wait / GETTICKS was recently fixed to be very accurate which also influence the lfops.c We welcome change and fixes to the firmware

We expect that ppl will make even better LF antennas, since the HF antennas is really good. We welcome that.

Yes, there is bad pcb-boards,
2 fo 989 units has a bad oven baking. 1 of 989 has a high pitch whining sound in a certain spectrum. We wecome ppl who got a bad RDV40 to RMA it and we will replace them.

In order to sort out a bad RDV40 experience we welcome feedback.

Issues that we figured out whats wrong:

• Many MacOS users seem to suffer the XQuarts xwindows
• MacOS users has problem with HomeBrew repo or the other system (I forgot name) (its fixed now)
• Unmount antenna and mount it back the wrong way. Yes its possible.
• Bad flashing experience, since the user was new and doesn't understand when swapping repos.
• Linux users forgot the modemmanager. ( sudo make udev if you are on iceman or RRG)
• Smart card module too short timeout, needs a firmware update
• High voltage - high temperatures, firmware related since some command doesn't shut down antenna when done.

Things that has been improved by new users since the release of RDV40.

• huge distance increase in Legic prime
• fpga fixes that enhances iso15, 14b.
• clock fixes which sorts out LF operations
• enhanced standalone modes which benefits from the new flashmem
• enhancements to flashmem driver. (that read speed!)

We are aware that not all will benefit from these since they don't have the right hardware but most will actually.

We are so proud and happy that the community got these improvments.

Screaming out your frustration on twitter or bad mouthing on forum is not the most fruitful way to get in touch with us.

If you have a issue, let us know and we will try to sort it out. That is our promise to you.

[marshmellow42]

First, I'm not on twitter, so... not me... And I did no bad mouthing of anyone.

I potentially overstated the problem in one post on the pm3 forum, which I have corrected, and for which I apologised.

My original assumption ( and the reason we are here on github) was the lf antenna's strength was working against it so is there a way to compensate in software..

From there some hardware guy says yes that is a problem for which I needed to add some hardware hack to fix it...

And after testing out that no timing change helped the issue, I concluded that hw guy must be right, and it somehow was not part of the tests performed during design, which I found hard to believe, but that is where we were...

4 days later we finally get some reports of working rdv4.0, which didn't exist prior.

I'M NOT AGAINST THE RDV4.0'S EXISTANCE.

There are no indications that the hw I have is somehow faulty as everything checks out and works (And even shows great power). It just won't couple with lf r/w tags hardly at all. So I had no reason to ask for a replacement device until today... though I still find it hard to believe it is a hw failure...

[pwpiwi]

See www.proxmark.org/forum/viewtopic.php?id=4593. This confirms your observation and assumption that a strong antenna is slower.

[iceman1001]

After discussions @tssmcu can up with idea of letting circut to discharge faster with keeping PWR_LO = HIGH. A proof of concept has been commited to RRG repo, which makes better T55XX communications.

[iceman1001]

Just added a command lf t55xx deviceconfig over at the RRG repo which enables custom setting of t55xx timings. On a RDV40 it also persists it on flashmemory. It will be easy to find a custom setting for your custom antennas and easy sharing of which setting works best.

next step would be similar but for EM4305, EM4350 etc.

The PoC idea of PWR_LO didn't do very much difference, since the tag activly dampens field it just comes down to timings.

[drandreas]

I'm currently following a more hands-on approach and hoping for suggestions.

What I got so far: The antenna is a RLC Circuit. According to my little knowledge about antennas the Q factor of my LF antenna seems to be too high - After the driver was switched off, the power requires a long time to dissipate. The LF antenna of my Proxmark3 Rdv1 has total resistance of 25 Ohm and my Rdv3 Proxmark3 LF antenna 14 Ohm (6 Ohm coil + 8 Ohm resistor).

I'm now considering changing the dampening resistor from 8 to 20 Ohm to get back to around 25 Ohm: This will reduce the Q factor by approximately 2. I will definitely lose power. But the remaining energy should dissipate in the half of the time. What do you think of this idea?

[marshmellow42]

what specific issue are we trying to fix? communication with t55xx chips?

i thought we came to the conclusion that only my pm3 rdv4.0 had the issue and that others worked fine?

or are we trying to talk to em4x05 chips now that require a q factor of 35 (per forum post) and does the rdv4.0 have trouble with that?

[drandreas]

I don't have any particular issue with my unit. I’m just following a hunch that a faster antenna might yield a higher range after all.

I’m aware that this is against the suggestion of the em4x05 datasheet. However, this thread started off with a discussion on how to correct the timings for different antenna powers. Since I am too lazy to adjust all timings for a stronger antenna I thought I just tune the new antenna to obtain the old characteristics.

I do not suggest that any one else should do that to his brand new gadget.

[TomHarkness]

Interesting. I think that one of the issues at play here is that if the t55 is in em mode, something is happening with modulation difference and t55 commands dong work or return anything. However commands like hid clone still work if it’s a quality card / keyfob. If the t55 is in HID mode then t55 commands work fine, even 2-3cm away for me with an rdv4.

[marshmellow42]

@TomHarkness the issue you are experiencing with t55xx chips emulating em 410x chips is likely related to the ask modulation's de-modulation routines, not anything related to the t55xx commands specifically.

with heavily clipped ask modulation (strong antennas) the auto detection routines can struggle (as this was an uncommon problem 3+ years ago). (usually the auto clock detection routine)

pulling the card farther away may allow lf search to work, but then the t55xx tag is too far to hear the read block command used by the t55xx detect routine.

if you would like i could look into the specific reason the auto detect fails for your environment if you send me a trace after issuing a t55xx readblock of block 0. but i think that would be best to do in a new github issue as i don't believe it is related to this one.

[TomHarkness]

@marshmellow42 interesting. I will try again with this repo and get you some data - I think my issue here actually related to iceman / rrg as I've just tested with this fork on an rdv4 and both HID and EM detect fine. Might have to do some testing with my custom antennas on this fork as I think one of the issues I am facing is likely software not hardware. Kinda good news lol ;)

See here for the issue in RRG:

https://github.com/RfidResearchGroup/proxmark3/issues/3

This same issue presents in iceman - haven't tested that fork fork since all the latest commits hough.

Really appreciate the offer for help and might actually take you up on that over the coming weeks! Do you use any kind of IM? signal, Keybase etc.. ?

Edit:

Here is a trace of me trying to detect a glass implant with rdv4 hardware and a custom antenna tuned perfectly and getting returns from "lf search" from over 3cm easily. Some clues would be helpful! If you need antenna inductance, geometry and tuning circuit details let me know.

https://www.dropbox.com/s/hizvldlru40t84b/t5_rdbl0?dl=0

[marshmellow42]

the results of your trace are pretty weak (expected with glass tag), but the tag didn't properly hear or respond to the read blk command. (it is still replaying it's configured output memory)... i'd be interested to learn more about your custom antenna's. (have you tried an elongated winding such as around a pen but without overlapping any windings, ends up being around an inch long down the pen?)

but again we probably should continue this elsewhere.

you can reach me @ marshmellow + rf + @ + gmail dot com

[TomHarkness]

Thanks @marshmellow42 useful info!

I've since managed to work through this issue and have t5 detection working perfectly. Returning t5 detected on lf search command even! :) Trace is much much much stronger!

I can't share the designs right now as they are going to be released as an RDV4 add-on pretty soon. I will shoot you an email shortly.