Next release v2.0.0 : Clarify protocol.

[0xDRRB]

Hi.

I'm currently writing a little C tool to read and configure the device, just for fun (and maybe make it into something usable with Flipper Zero later). And I'm not sure if this is really a bug or just some sort of protocol inconsistency.

Using the DATA_CMD_GET_APP_VERSION command the hardware response is "11 ef 03 e8 00 00 00 02 13 00 01 ff". The two data bytes are "00 01", so 0x1 in big endian, or 0x100 in little endian.

chameleon_cli_main.py and ChameleonUltraGUI both show version 1.0, but everything else in the protocol (command, length and status code) is big endian.

My question is: Is the answer to DATA_CMD_GET_APP_VERSION little endian and the version is 1.0, or the answer is big endian and the version is actually 0.1?

Also note that protocol.md specifies that LRC3 is calculated on DATA, but that make_data_frame_bytes (in chameleon_com.py) adds LRC3 with frame.append(self.lrc_calc(frame)) and therefore calculates LRC3 on the whole packet.

Regards.

[doegox]

Hi Denis,

As we speak now, the protocol is not very well documented. IMHO all the protocol should be defined in Network order (so Big Endian), and the code should use the appropriate htonl, htons,... functions to make things explicit (and some unpack('!H', x) in Python) and models for contributors willing to add new commands. Also you'll see some data sizes are currently derived from some enum, whom size solely depend on their highest value, so pretty fragile definitions too.

Still in the TODO list... These planned changes should not affect the existing protocol definition... except if some commands are currently breaking this convention, and it seems you found one :) Apparently another one is DATA_CMD_GET_MF1_DETECTION_COUNT which is also using little endian.

So to answer your question, right now DATA_CMD_GET_APP_VERSION is using little endian but we should change that to be more consistent.

Actually LRC2 and LRC3 can be considered as covering either everything since the start of the frame or since the data after the previous LRC... because previous LRC nullifies previous bytes LRC computation. I added a note to remember it.

PS: if later you plan to write some article for Diamond Editions on the matter, I can help you reviewing it, as I occasionally do for MISC.

[0xDRRB]

Hi Philippe,

Thank you for all the answers. I will keep an eye on the evolution of the firmware and adapt my code accordingly.

PS: Yes, I am preparing an article to present the Chamelon Ultra, I am currently in the experimentation phase. I'll get back to you as soon as I have finalized something readable.

[doegox]

I started a PR https://github.com/RfidResearchGroup/ChameleonUltra/pull/147 which gives an idea of the changes to come and the logic behind.

[xianglin1998]

At present, great progress has been made in solving this problem, and the main branch has not been updated for almost a week. This is a huge blow for users who are not familiar with Github to see an inactive project(Actually, it's very active.). Therefore, I have placed this issue at the top to inform new users of our current progress.

[doegox]

As this issue is pinned, I changed the title to highlight the situation. PR #147 is ready, we're just waiting for the GUI devs to make it compatible with this v2.0.0 release. Meanwhile, you'll get a preview at https://github.com/doegox/ChameleonUltra/releases/tag/v2.0.0