Datasheets and other information about debugging with the ChameleonMini

[maxieds]

Can someone point me to a detailed datasheet documenting the features of the ChameleonMini RevG RF hardware? The only ones I can find online are single pages. I remember that one of the really innovative features of this hardware was memory mapping the RF chip. I want to do some experiments tweaking the features of the codec code. I think there might be some nice features to add with different subcarriers.

Also, what software are you all using to generate the outputs in this thread and this thread?

[ceres-c]

I don't think there are comprehensive datasheets for the whole platform. Mostly because the analog frontend is rather simple and clean and implemented with passive components only. The signal is then fed directly into the MCU pins.

Currently trying (failing) to focus on completely different stuff, but I am not sure I get what you mean by "memory mapping". There is basically no RF chip here. We're probing a pin and using either the ADC or the DAC to compare values or loadmodulate the field.

Regarding the pics, those were obtained with my cheapo Siglent SDS1104X oscilloscope attaching micro probes to the MCU pins. The setup is described here #316

[maxieds]

I wanted to see if the Chameleon hardware would let me isolate multiple signals in the input - at least one of which is encoded as binary data. I had the idea looking at this explanation and this shorter one. The code @ceres-c wrote for the ISO15693 had two definitions for the subcarrier frequency. This is probably another project that I need separate hardware to work on. That and the AI deployment discussions in talk programs recently hit home with some very nasty covert operations.

Some issue thread about debugging the DESFire emulation over the last couple of years had some unresolved questions about why an external USB reader interfaced with libnfc versus libfreefare would (would not) recognize the Chameleon when scanning the configuration where nfc-anticol would run correctly. I think the explanation was something about timings with the libraries. There is this enum for NFC baud rates that could be used to detect some of the different speeds of the tags.

[ceres-c]

The chameleon is in sync with the carrier because it is clocked at 2*carrier speed (27 or so MHz, see makefile). The demodulation is done by the analog frontend that does carrier subtraction IIRC. Because of this, there are simply not enough clock cycles to work with faster signals, so we only deal with the subcarrier which contains actual data, and being slower can be analyzed.

Two subcarriers can be emulated with no issue because as long as we're generating the subcarrier we have the precision to do so. I was not able to achieve sufficient precision to detect the 2 subcarriers while I was getting the sniff code to work. The problem there was with finding a reliable, real time peak detection algorithm that ignored noise and was sensitive enough to detect everything. I gave up at real time and used a dynamic threshold that more often than not missed the first few subcarrier pulses

Regarding the lib question, yes the oscilloscope would definitely help you with debugging that behavior. You don't even need a 500€ one if you don't want to look at the NFC signal itself but just at timings on the chameleon, just get the cheapest OWON VDS. I wouldn't recommend it, but it is feasible and I have done it in the past