jay (support) wrote:
I understand the time critical nature - however, threading the plugin, I believe, will solve a variety of issues. While it's interesting to know multiple times a second that the reader is present, I'm not sure that's interesting to the user. I don't know how much of the sub-second data is passed from the plugin to the server but if data is being updated more than a couple of times a second (which is probably overkill) then I'd suggest a heavy rethink about the plugin's architecture.
That would be my basic recommendation: minimize the amount of communication between the plugin and the server and buffer between the read thread and the main thread in the plugin so that anything that could cause the server to hang up for smallish periods of time doesn't significantly impact the plugin. If a tag is updated to be "in range" a second later than might be the case because the server was busy doing something else, I suspect that 99.9% of your users won't even notice.
I cannot go into too much more detail in a public forum about the protocol, however I can tell you that the buffer in the reader is very small and must be emptied of tag data many times per second in order to make room for any subsequent tag transmissions. The plugin is not simply determining if the reader is present, that is a secondary use of the empty tag packet which is primarily used for emptying the reader's buffer. If the buffer is not emptied, new tag data will overwrite the previous data and the tag data will be lost. This is especially critical when tags are at rest and transmitting at 15s intervals. In this example, if one tag packet is missed, 30 seconds will have elapsed between tag packets.
The design of the hardware (small buffer) is intentional and geared towards real time data collection and forces us as a developer to empty the tag buffer frequently to insure fresh, accurate data.
In our test environment we have had good results with as many as 135 active tags in the range of a reader and that is only possible because of the speed at which we retrieve the tag data from the reader, thus clearing the buffer many times per second.
]]>