ricmoo / QRCode

QR code generation library in C, optimized for low-power devices, such as Arduino.
Other
638 stars 202 forks source link

QR Text being padded with 'ec 11' which doesn't allow for smaller versions. #10

Open rlightner opened 4 years ago

rlightner commented 4 years ago

Encoded Text: WIFI:S:*MyWifi-B0B5;T:nopass;P:;;

Encoded Bytes: 42 15 74 94 64 93 a5 33 a2 a4 d7 95 76 96 66 92 d4 23 04 23 53 b5 43 a6 e6 f7 06 17 37 33 b5 03 a3 b3 b0 ec 11 ec 11 ec 11 ec 11 ec 11 ec 11 ec 11 ec 11 ec 11 ec 11

For some reason it's padding with ec 11, which is now allowing me to use a smaller version

ricmoo commented 4 years ago

I don't quite understand what the encoded bytes are. How did you get them? The encoded bytes for your string should be:

57 49 46 49 3a 53 3a 2a 4d 79 57 69 66 69 2d 42 30 42 35 3b 54 3a 6e 6f 70 61 73 73 3b 50 3a 3b 3b

which would need at least a version 3 QR code with L or M EC, or version 4 at any level.

rlightner commented 4 years ago

exactly. That's the exact string being passed in, with the latest code from this repo, so I'm a bit at a loss.

ricmoo commented 4 years ago

But how are you converting the string into those bytes? How are you printing them to the console? It may be an issue with either of those...

rlightner commented 4 years ago

char ssid[13]; uint64_t chipid = ESP.getEfuseMac(); snprintf(ssid, 13, "*MyWifi-%04X", (uint32_t)chipid);

Which calls a method with this signature: void Draw_QRCode(const char *string)

And that in turn calls: qrcode_initText(&qrcode, qrcodeData, 3, 0, string);

nayuki commented 4 years ago

WIFI:S:*MyWifi-B0B5;T:nopass;P:;; The encoded bytes for your string should be [...] which would need at least a version 3 QR code with L or M EC

To my surprise, that string can be encoded at v2 L, if you segment the characters such that the first 9 are in alphanumeric mode and the remaining 24 chars are in byte mode. The bit stream (before padding) is 267 bits for optimal segmentation, or 276 bits for encoding the whole text in byte mode.

You can confirm this on my demo page (only statistics, no rendering): https://www.nayuki.io/page/optimal-text-segmentation-for-qr-codes

nk9 commented 4 years ago

For anyone wondering the answer to the original question: the amount of data which a QR code can store is a function of both the version (the size and subdivision pattern of the grid) and also the level of error correction. If you're seeing "ec 11" padding on the end of your decoded QR code, the library has had to level up to a larger version to store the provided data with the given error amount.

You may be able to avoid this by tweaking the error parameter to be less forgiving.