Issues with LF emulation or original ultra hardware, no issues on clone #175
Comments
|
electrical contact to the LF antenna via the screws has been reported to be problematic on a few devices, maybe you could check. But be cautious, it has also be reported that stuck screws broken when forced... |
|
Yeah, I forgot to mention... I did check that too. The screws was indeed stuck, but no signs of resin residues on connecting surfaces. |
|
The developers of CU's Taobao clone have submitted repair code for some issues with LF, which I think is the reason why Taobao clone LF can work very well. |
|
If this continues, I will consider restoring the code to its original state because too many people are complaining about this issue. |
|
I have DevKit and Lite from the original campaign and both cannot emulate LF ( tried with flipper, proxmark, door acess ... no ). The ultra does emulate and the DevKit can also read LF, so I don't think it's hardware issue in my case, but it is very annoying issue. |
|
FWIW i havent experienced this issue on my devices. Maybe some changes In HW revisions (mine was In the first badges shipped) |
|
I have the same problem. My Chameleon Ultra can't emulate lf cards. I tried using my Chameleon Ultra from a mobile application (even two different mobile applications). In the Iceman`s discord I was given a recommendation to try using CLI. And so, I installed CLI and nothing changed. CU emulates only hf cards. At the same time, it reads EmMarine cards perfectly. What I tried to do:
|
|
On the Devkit and Lite LF emulation works fine, on my Ultra it doesnt. (Tried reading with the pm3 or Flipper zero, nothin) |
I have the opposite problem, on Ultra the LF emulation works fine and on my Lite/Devkit it does not. Devkit is able to read LF just fine though, just cannot emulate them back...and I've tried. |
|
I'm trying to understand differences between v.1.0 (a.k.a. "factory version") and current LF emulation code. There is 20us delay in |
Can you point to that change? |
|
Looks like m_is_send_reboardcast_last_edge is unititialzed in firmware/application/src/rfid/nfctag/lf/lf_tag_em.c, Line 46 (from commit d4e6c03) it probably should be initialzed to false. New file location line is 36 https://github.com/RfidResearchGroup/ChameleonUltra/blob/main/firmware/application/src/rfid/nfctag/lf/lf_tag_em.c |
|
Did some testing, no change. This seems very inconsistent nomatter if i leave it as be, set it to true or false or whatever... |
|
I have the same problem. I conducted experiments with some noname reader that I have, and noticed that the Chameleon Ultra needs to be brought much closer to the reader than the original tag in order for it to be reliably read. If you move it too far, the RFID activity LED begins to flicker and reading does not occur. Perhaps this is a design issue with the LF antenna? P.S. I tried all versions of the firmware, including the "factory default" version, and the problem occurs on all of them. I made sure several times that the contact between the back cover and the nuts on the front cover was good. My “problematic” reader has weak field strength compared to a normally functioning reader (tested using Proxgrind RFID Field Detector). |
Due to the impact of components and PCB layout on RFID radio frequency, ChameleonUltra will inevitably reduce the card reading distance in terms of Tiny size. If excellent RFID performance is required, you should try using ChameleonLite or Chameleon Ultra Dev |
|
Artifacts from lf_test_rollback branch. |
|
Work well on my reader, so i need you help, to test this change. |
|
@xianglin1998 trying to do a before test, it seems to have magically started working for me... my pm3 can read it perfectly and it isnt even very position dependent... |
Let's look forward to testing by other users. |
Well, I have this problem, and it is definitely something floating and really embarrassing. While RF LED lights up even 2-3 cm away, LF requires an extremely short distance of 1-2mm between ultras to actually work, and even in these conditions, being vise-fixed, it sometimes stops working after 1-2 reads (RF flashes) or works inconsistently, getting data once per 2-3 reads. It does not work at all with VIZIT panel (just flashing led once when entering the field). Reading a regular LF tag works from a much higher distance, over several centimeters, up to the same distance as RF LED on emulator catches the request. Absolutely no problem with HF, though. Problem is constantly reproduced on all devices with 2.0 builds I've tried, including this build. Didn't test with 1.0. Feels like it may be a problem with transmitting power or transmitting timing. UPD: Lite with above modification does not have this issue anymore. And after conducting some more tests, I am almost sure the problem is timing. Lite works with the VIZIT reader only when the slot is pre-selected (transmits too late or off-time after activation by entering the field), but Ultra does not work at all (it does emulate, but it seems it's too late for the reader). So I am wondering now, why it does not retransmit, maybe it should while field is present and it will solve the problem? I've also ordered an additional coil antenna to test with Ultra and to confirm that the bug is not about the antenna attenuation. Will give an update here in 2-3 days as I'll receive and test it. UPD2: Lite stopped working by itself the next day. So, it's not about the antenna, but timings. |
How can i install this? I am on v2.0, but i guess this is a new (test) firmware release? |
thnx, it's work, 10/10 |
You can use NRF DFU Application to update this firmware, or try to use ChameleonUltraGui to update(I dont known it is support or no, you need to confirm) |
Good start!!! but we still more people to test it. try to make it work well and well. |
Nothing changed for me. Still doesn`t work LF emulation. |
|
Hi all, just wanted to report, i have similar issue where my CU was unable to read any LF cards. I have followed the troubleshooting steps and i do not found any epoxy residue. I can confirmed that the CU LF reading is working fine when i have tested with basic factory firmware and it was able to read the LF card however when i install the lastest firmware, i'm no longer able to read the LF card again. I have also tried the modified version below : https://github.com/RfidResearchGroup/ChameleonUltra/actions/runs/7554329636#artifacts It is not working either.
|
|
Hi all, FWIW my CU has just arrived, I've updated its firmware to v2 thru Android GUI and tried the LF Read+Emulation (also thru Android GUI) and it worked wonderfully. |
|
Well, after a significant number of different tests, I feel like something is drifting away in time when using CU or Lite with specific readers. You'll be able to emulate the card once or even several times after the firmware reset, but then it stops emulating correctly. I'm not sure about just replacing the LF ID or enabling/disabling the slot: it gives uncertain results. Meanwhile, with other readers, especially handheld Chinese copying devices, it works fine every time. Maybe there is a chance of some data shifting over time in the sequence to be emitted? Kinda, we emit a stop-byte in the middle, but the handheld reader ignores the pause in the middle of the sequence? I am not very familiar with RFID protocols. |
Wanted to try, but it's expired :( |
I'm having issues emulating em4100 using both of my CUs with reader in my residential block.
Unfortunately I don't know the brand of the reader.
The success rate is about 1/3, but most attempts ends with the RF field diode flashing irregularly and the door remain locked.
It happens on any version of firmware I've tried since August, BUT it worked quite reliably with firmware built using lf_tag_em.[hc] from June "factory release".
No problem when trying to read both CUs using flipper zero or some cheap chinese reader.
CU's taobao clone (the one with triangles on antenna pcb) doesn't seem affected at all, works with problematic reader every time on any firmware.
The text was updated successfully, but these errors were encountered: