Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invalid data embedded in the QR code #7

Closed
zepplock opened this issue Nov 24, 2015 · 13 comments
Closed

Invalid data embedded in the QR code #7

zepplock opened this issue Nov 24, 2015 · 13 comments
Labels

Comments

@zepplock
Copy link

Hello,

I'm encoding the following string into the QR: http://localhost:4000/v1/sessions/9a454d3bb5d14369842f21a8f9683a87 which results in this image:
qrcode

The problem is that the actual data embedded in the QR is: http://localhost:4000/v1/sessions/9a454d3bb5d14369842f21a8f9683a8'. Notice the 7 at the end turned into '. I also saw similar errors which had 1 character wrong but not at the end of the string.

Here's my erl -v

erl -v
Erlang/OTP 18 [erts-7.1] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] [dtrace]

One thing to note is that when using Q or L error correction modes it is working fine, at least for the given input string.

@zepplock
Copy link
Author

Hello Steve, any update on this issue?

@komone
Copy link
Owner

komone commented Dec 19, 2015

Looks like it's not the data but the error correction at the root of this. I am thinking currently that the ECC bytes are overriding the data and flipping a bit in the value. Note that $7 = 0x37 and $' = 0x27

@komone
Copy link
Owner

komone commented Dec 20, 2015

This doesn't look trivial to get to the root of, but I have a quiet period coming up that may help me focus :)

@zepplock
Copy link
Author

Steve, after verifying changes for #8 I found that L Qand H modes are working but now M mode is the only one that fails for a given string (referenced in the original post). Same problem, last character 7 is turned into '

@komone
Copy link
Owner

komone commented Dec 22, 2015

Yep the issue in #6 and #8 is different to this issue. There's an error correction issue that's causing a bit to flip in the data (overriding the embedded value). Further examples if you find them could perhaps be helpful.

@zepplock
Copy link
Author

Ok, let me see if I can get more strings. Going to be all URL-like strings. I get them 1 in 10 (on average).

@komone
Copy link
Owner

komone commented Dec 22, 2015

My current hypothesis is that the ec code is causing a bit flip, so will be interesting to see if other examples could be explained by a single bit flip. I do not yet understand root cause.

@zepplock
Copy link
Author

Sent you some more string over email.

@komone
Copy link
Owner

komone commented Dec 22, 2015

That's useful test data - thank you, Vlad. I should be able to isolate the issue and resolve it with this test data.

@komone
Copy link
Owner

komone commented Dec 23, 2015

Doing a few "syndrome" checks on the ECC shows that there's an error correction code generation problem... close to a solution

komone added a commit that referenced this issue Dec 23, 2015
Fault in gf256 multiply function.
Atom removed a bunch of trailing spaces, so these are in here too.
@komone
Copy link
Owner

komone commented Dec 23, 2015

Vlad, this latest update passes my testing - can you confirm with yours?

@komone
Copy link
Owner

komone commented Dec 23, 2015

Example production using the latest update and the original issue string (have also validated various others):
qr-issue7

@zepplock
Copy link
Author

Steve, I tried it with M error correction level and it's working great! Can be closed.

@komone komone added Resolved and removed Testing labels Dec 24, 2015
@komone komone closed this as completed Dec 24, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants