Open doegox opened 4 years ago
iso15: seems ok but 15b seems to short to record properly durations (or duration computation is wrong)
[usb] pm3 --> hw dbg 3
#db# Debug level: 3
[usb] pm3 --> hf 15 reader
#db# [!] error, uneven octet! (extra bits!) mask 02
#db# Error in LogTrace: duration too long for 15 bits encoding: 0x002a97e0 start:0x00003680 end:0x002ace60
#db# Forcing duration = 0
[+] UID: E0 07 C0 13 55 29 08 7E
[+] TYPE: Texas Instrument; Tag-it HF-I Standard; 8x32bit
[usb] pm3 --> trace list
[=] downloading tracelog from device
[+] Recorded activity (trace len = 36 bytes)
[=] Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer
[=] ISO14443A - All times are in carrier periods (1/13.56MHz)
Start | End | Src | Data (! denotes parity error) | CRC | Annotation
------------+------------+-----+-------------------------------------------------------------------------+-----+--------------------
0 | 3408 | Rdr |26 01 00! f6! 0a! | !crc| REQA
3424 | 3424 | Tag |00! 00! 7e! 08 29 55! 13 c0! 07 e0 35! b0 | !crc|
Amazing bugs, and documentation of these timings. I struggled all years in getting someone to explain it all.
log trace, timestamp end vs duration. Could be a semantic error
operation execution time.
reader EOF - tag SOF
tag EOF - reader SOF
or
reader SOF - tag SOF
tag SOF - reader SOF
Kind of curious, 15bits = 16383. Kind of many systems will go past 16383 of (1/13.56MHz) before getting an answer. 16383 * 8us = 131064 us, 1310ms, 1.31 Sec...
Its almost like we should increase this to 31bits ? Or is there no major advantage with that?
#db# Error in LogTrace: duration too long for 15 bits encoding: 0x002a97e0 start:0x00003680 end:0x002ace60
duration should be the duration of the answer: tag SOF-EOF but they don't do it all, iso15693 duration is like 300ms, I don't understand it. Yes if we're sure we need more bits for duration we can increase its size (and break compatibility with recorded traces) but it's not clear to me at all is it's needed, a frame itself shouldn't be that long
or the duration from request eof to tag sof.. Depends on what you wanna measure. For the time critical parts, we need to keep it precise. Known that the answer took 56us isn't as usefull if we didn't know the whole chain.
I guess here is where the umbiquos tracelog / duration / timestamp end, started.
the duration from request eof to tag sof
You have already that information by comparing timestamp_start of req, duration of req, timestamp_start of resp. If duration becomes the time to respond, you're losing the information about the frame duration.
So right now, for e.g. iso14443A which is one of the decent traces so far, we have:
It would probably be nice also to display explicitly the time between req and resp, but that doesn't need to be added to the trace format, it's just matter of computing it from the available info.
there is an option for frame-delay, which does print the delay between EOF and SOF
hooooo :)
You learn new things about proxmark3 everyday
In the branch FPGA, the timings has been improved for iCLASS; ISO15, and 14b.
I fixed some usages where duration was wrongly used as timestamp_end. Still, some usages seem weird...
client/src/cmdtrace.c:
ARM:
(GetCountSspClk() + 8) & 0xfffffff8
then*16 or <<4
and with corrective offsetsGetCountSspClk()) & 0xfffffff8)
then<< 4
, duration = felica_lasttime_prox2air_start + felica_lasttime_prox2air_start ??