Question about QR code implementation

[user90435u90]

Hello,

I'm doing a personal audit of the firmware (version v25.10.1), and while trying to reproduce its behavior in Python on my PC, I noticed something that I couldn't fully reconcile.

Here's what I observed:

• I copied the simulator QR code implementation from:
  krux/simulator/kruxsim/mocks/qrcode.py
• Using that script, I was able to generate a QR code that matches the PNG shown in:
  krux/docs/img/maixpy_amigo/about-300.en.png

However, when I compare it with the QR code displayed by my Yahboom device running Krux firmware v25.10.1, they are not identical.

I used the exact same input in both cases, but the QR code generated by the Python script on my PC still differs from the one produced by the firmware on the device.

Because of that, I was wondering if the firmware running on the device uses a different QR code implementation than the simulator mock, or if there is some other difference in the pipeline that I may be missing.

If I misunderstood something, I would really appreciate any clarification.

If the hardware firmware does use a different QR code implementation, could you please send me the script that is actually used on the device? I would like to reproduce the exact same QR code generation in my Python implementation for comparison.

Thank you for your time and for maintaining the project.

[qlrd]

Can you reproduce the same steps on main and develop branhces, building them onto device?

[odudex]

This is a frequent question.
Firmware runs on MicroPython, and QR codes are built using C code that might use a different mask from cPython modules used in a PC, resulting in different QR codes.
Despite different masks create different QR codes, the content is the same.

[user90435u90]

Thanks for the clarification.

I looked into the qrcode.c implementation you mentioned and located the actual firmware QR code generation logic. I was able to replicate it in Python on my PC, and the output matches exactly the QR code generated by the device.

With that, it became clear that the difference I initially observed comes from the simulator mock (krux/simulator/kruxsim/mocks/qrcode.py) using pyqrcode, which produces different QR layouts for the same input data.

I had assumed the simulator output would match the firmware, which led to the discrepancy in my reproduction attempt.

Would it make sense to align the simulator QR generation with the same implementation (or a Python-compatible port of qrcodegen) to improve consistency with the actual device behavior?

[odudex]

It's something that doesn't bother me, but more reproducibility is always welcome.
This question is also raised when people compare with SeedSigner, though.
"Why the same mnemonic resulted in a different Compact SeedQR in Krux vs SeedSigner?"
The answer is the same, SS uses a cPython module that might use a different mask than Krux