Closed X-Ryl669 closed 3 years ago
Also, I get exactly the same value for any setting:
setting=1
100:OK
uid?
101:OK WITH TEXT
72F47648387034
setting=2
100:OK
uid?
101:OK WITH TEXT
NO UID.
config=MF_CLASSIC_1K_7B
100:OK
uid?
101:OK WITH TEXT
72F47648387034
setting=3
100:OK
config=MF_CLASSIC_1K_7B
100:OK
uid?
101:OK WITH TEXT
72F47648387034
setting=4
100:OK
uid?
101:OK WITH TEXT
NO UID.
config=MF_CLASSIC_1K_7B
100:OK
uid?
101:OK WITH TEXT
72F47648387034
setting=5
100:OK
config=MF_CLASSIC_1K_7B
100:OK
uid?
101:OK WITH TEXT
72F47648387034
setting=6
100:OK
config=MF_CLASSIC_1K_7B
100:OK
uid?
101:OK WITH TEXT
72F47648387034
setting=7
100:OK
uid?
101:OK WITH TEXT
NO UID.
config=MF_CLASSIC_1K_7B
100:OK
uid?
101:OK WITH TEXT
72F47648387034
setting=8
100:OK
uid?
101:OK WITH TEXT
NO UID.
config=MF_CLASSIC_1K_7B
100:OK
uid?
101:OK WITH TEXT
72F47648387034
setting=9
202:INVALID PARAMETER
Totally wild guess and most likely won't help, but have you tried disabling some configs at compile time? It's very unlikely this is related, but still...
So far, I've gave up with the "flash" storage and patched the code to use EEPROM instead. I don't know if I have a version with MRAM (not FRAM) and since I recently started to store my keys with a magnet on them...
I only needed to emulate a TiTag +. I've fixed everything and both the original tag and the emulation returns the same thing now (UID + Memory content) when scanned with NXP TagInfo (and NFC Tool), but the original reader rejects the chameleon.
Up to last week, it worked flawlessly with firmware from august 2020, but it suddenly failed (the original reader started to emit error tones) and I've tried to update the firmware to a more recent version. If I remember correctly, when I've initially programmed it (in august or september), I had to reverse the UID byte order in order to work and the chameleon wasn't correctly detected by my phone but what perfectly detected by the reader.
Now, while I can't see any difference with my Android's NFC scan tools, the original reader does not even bip when the chameleon is presented, like if the emulation wasn't working. The field led is blinking. I don't have to revert the UID anymore.
I'm 99% sure the tag memory content is not required (in my case), only the UID, yet it does not work.
Is there some work done on the TiTag standard (or plus) version that could have reduced the compatibility ?
I'm afraid the system is damaged somehow (and it's too expensive to buy another one just to try).
Did you ever get this fixed? It sounds like an FRAM issue, because the current config should be buffered in FRAM afaik.
Also, which version of the Chameleon are you using? Just the normal KAOS RevG?
Honestly, I've wasted too much time on this. So to sum up, I used the EEPROM instead of the MRAM (really, it's a MRAM I have, and I'm 99% sure it's dead) to store the TagPlus UID I needed (and the content of the tag, which happened to be all zero). With my android phone, when I'm detecting the tag, it's a 1:1 of the other (genuine) tag in both NXP TagInfo and NFC Tool, yet, the chameleon tiny does not work with the original reader.
What's strange is that:
At this point, I'm not able to make progress anymore. I don't have the tools required to understand/sniff the difference between the original tag's answer and the chameleon's answer.
BTW, I also had a Chameleon Rev E but never got it to work.
To me it seems that you have purchased some other products manufactured by a third party ( I read ChameleonTiny etc.) that are not supported in this git. ChameleonMini RevG definitely has an FRAM. This git is only for the original ChameleonMini RevG as invented, open-sourced and manufactured by us (Kasper & Oswald GmbH / KAOS). We are aware of various other profit-oriented / commercialized variants of our ChameleonMini project - unfortunately they are often not even open-source but have some commercial license! on top of our open-source license.... - and since we don't know what these third party manufacturers have been doing to create malfunctioning devices, we cannot help solving the problems with their products. I recommend to contact the manufacturer directly.
Right, it's confusing (for us, customers). I had purchased a Rev E (95% sure it was by KAOS) but since I wanted to emulate a TiTag+ and the support wasn't coming, I bought the ChameleonTiny (because the form factor was perfect as a key chain, the original format is too big to be useful). At the time, I did not realize it wasn't the same company producing both product. If I were you, I won't be ashamed to copy their product (the ChameleonTiny is very convenient and practical) since they weren't ashamed to copy yours.
Anyway, I'm not blaming you for the MRAM issue (which, as you said is not your responsibility). I'm not blaming you for the code I wrote either (to use the EEPROM instead of the MRAM). I'm almost sure my code is working since the emulation is read by my phone correctly on both application.
The original issue is probably invalid, but the later issue is, IMHO, still valid: the TiTag+ emulation is not working with the original reader I had, yet the smartphone does not see any issue.
Their hardware is open source: https://github.com/RfidResearchGroup/ChameleonMini
the ChameleonTiny is very convenient and practical so why the above description of malfunctioning? The original RevG doesn't have these problems.
Their hardware is open source: https://github.com/RfidResearchGroup/ChameleonMini aha, this is some clone of our git; it contains the schematics of (our) original RevG 5 years ago or have I missed s.th. ... ?
Also, on some other page you will find in a hidden way, that the license of the Tiny is NOT open source.
This seems recent to me. It looks like Altium's schematic and is dated 2019. There's no Gerber or PCB layout.
So to clarify the situation is as follows:
the ChameleonTiny / RRG repo is forked from this repo, and there are some changes on the code. It appears to be under the same license as this one here, at least they didn't change the license file. There used to be this condition on the ProxGrind RevG "IMPORTANT The ChameleonMini RevG by Proxgrind implements patented technology from Info Wise Limited. Licence for use of the device for non-commercial purposes is included with device purchase. All commercial use of the ChameleonMini RevG by Proxgrind is subject to licence from Info Wise Limited." - I cannot find this for the Tiny though.
there are schematics (in some viewer) of the ChameleonTiny here https://chameleontiny.com/downloads/, but no board layout
there is no source code for the BLE chip that is on the Tiny, but there is a rar with the Android API or something
So in summary, contrary to the original Chameleon, you cannot really build a Tiny on your own.
There are 2 version of the tiny, one with the BLE chip (I think it's called the Tiny Pro) and the other without. I have the latter version. It's not hard to see that the BLE chip is used as a serial link proxy/pass through (AVR_TX and RX are the only pins going from the NRF to the AVR), so even without the firmware, it shouldn't be required to update it to get it to work.
If I understand correctly, there is no software difference between the tiny and the mini, and I've built this repository's firmware and run on the their board without any issue. The pinout is the same for major components, the FRAM part number is also the same, and the AVR seems to be the same too. They have more pins used for leds (they have 8 leds while yours only has 2). They have a USB-C input but they only use the USB's D+D- lines so (the schematic is so simple) I doubt it would make any difference to the behavior.
There is zero guarantee that they actually routed this schematic (and the broken MRAM shouldn't happen with a FRAM, proves that they've probably swapped the flash for a cheaper MRAM version, unlike what's written on the schematic).
All in all, as a consumer, I'd say that both Chameleon (Rev E and Tiny) are hard to grasp (they are not dumb user friendly). Without a minimum knowledge to NFC standards, it's almost impossible to use. The software is powerful but made as a engineer tool, not as a consumer tool.
I guess the main use of these products is to merge all NFC tags we usually wear with us into a single device. As a dumb user, I would have loved if the product was working this way:
IMHO, a user shouldn't have to know the technology of the tag she's using (Mifare, NTAG, TiTag+, etc...), nor how does it work. Using the Android App should be reserved for power user and even then, the app should be more intuitive than having to enter commands by hand.
Regarding the BLE chip, you're mostly right but I think there is some framing going on and also the BLE chip actually appears to control the Xmega power line and sample the antenna field, so it's not fully trivial.
Regarding the modes you outline, of course we'd be happy to see that as a contribution. However, at least for us the Chameleon is not targeted at "dumb" users but rather people who have (some) understanding of RFID technology.
Done this:
UID never update and it's fixed to a wrong value.
When programming the device with avrdude, the verification is ok for both flash and eeprom, yet, I can't get the flash to program from the application itself. I've tried to also build the firmware with disabled DMA (in Memory.c, commented
#define UseDMA
) but no change whatsoever.Programming with avrdude works, since if I change the number of codec in the Makefile, it appears in the
config=?
queryAlso, the device is not in readonly mode (readonly? returns 0)
Any idea ?