-
-
Notifications
You must be signed in to change notification settings - Fork 73
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
osdp_FMT might be parsed incorrectly #206
Comments
Unfortunately no, this is the first I am hearing about this problem. Does the RSFID reader actually send those two bytes over OSDP? If not, I don't see how they can expect the CP to know about it. Also, by that logic, shouldn't it be 3 more than the actual length? (START + END + CKSUM) |
That's what I am trying to tell them, but they are not very cooperative... Do you have any idea what START, END and CKSUM are supposed to be? They are not mentioned anywhere. I tried to look for any reference implementation, but not even SIA seems to know what they meant or care about it. Their conformance test implementation does not support
|
I have no idea what START, END and CKSUM means nor have I encountered them. Perhaps @IDmachines or @rsgmodelworks knows something? RSFID guys seems to be the only ones privy to this knowledge and you should press them to explain their decisions -- which they should as you've paid for their product. |
osdp_FMT is not to be used, it was scheduled for removal years ago. There are no known implementations of this in the wild. Any implementation using this would be considered non-interoperable. |
Describe the bug
I am currently having a discussion with an RFID reader manufacturer who claims that the "Character Count" specified in the osdp_FMT reply should be 2 more than the actual length, because it says "Number of characters, including START, END, CKSUM" in the spec.
I would disagree, but I wanted to know if you have any experience with other OSDP readers and how they handle this?
In my opinion the osdp_FMT reply is extremely underspecified. In B.4 it says readers can either send card data as an "array of bits" or an "array of BCD characters". Whatever that means... 🤦
The text was updated successfully, but these errors were encountered: