GithubHelp home page GithubHelp logo

Comments (13)

gotthardp avatar gotthardp commented on May 30, 2024

That is weird indeed. Could you please try one more thing: first start both A+B, but then after some cycles stop B and keep only A running. Does the random alternation stop, or not?

from python-mercuryapi.

clickworkorange avatar clickworkorange commented on May 30, 2024

Thanks Petr! I changed the detectA() function to stop readerB after ten reads, and this also stops any calls to detectB():

300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 B1
300ED89F3350004001821268 B1
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 B1
300ED89F3350004001821268 A1
300ED89F3350004001821268 B1
300ED89F3350004001821268 A1
300ED89F3350004001821268 B1
Stopping readerB
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1
300ED89F3350004001821268 A1

Note that antenna "B1" is some four metres away from antenna "A1", and antennas "A2-4" are in between, so it cannot be simply that "the wrong antenna" sometimes reads the tag.

from python-mercuryapi.

gotthardp avatar gotthardp commented on May 30, 2024

But-- if both readers can see the tag, when you start both A+B, each will CONCURRENTLY use its antenna and read the tag, i.e. the prints from detectA (called by A) and detectB (called by B) will be mixed up. Could you please explain again what is wrong with this behaviour,

from python-mercuryapi.

clickworkorange avatar clickworkorange commented on May 30, 2024

if both readers can see the tag

They cannot, and should not - each tag can only be read once in my application, and it is critical that I know where (i.e. which reader and antenna) it was first seen. This is beside the point though; the issue here is not that the tag sometimes is being read by readerA and sometimes by readerB - it is always read only by one of the readers, but the callback for the other one sometimes gets erroneously called.

from python-mercuryapi.

gotthardp avatar gotthardp commented on May 30, 2024

So you say that the tag is so far from one of the readers that only one of the readers can "see" it (from the radio perspective). If both readers are on one table the tag can be easily seen by both readers. This is obvious, right?

from python-mercuryapi.

clickworkorange avatar clickworkorange commented on May 30, 2024

So you say that the tag is so far from one of the readers that only one of the readers can "see" it

Absolutely. And not only that:

  1. I never get an unexpected read by any of the other antennas on the same reader, even though they are much closer (indeed A1 and A2 are less than a metre away from each other, while A1/A2 are four metres away from B1/B2).
  2. The erroneous callback always triggers with the same antenna number; if the tag is on A2 I get B2 triggers, if it's on A1 I get B1 triggers, if it's on B4 I get A4 triggers.
  3. If I put the tag on B4, I get erroneous triggers of A4's callback - but after ten such errors I stop_reading() on readerB and the A4 callbacks also stop at at that time. How could this be if the callbacks are not linked?

This is obvious, right?

Very.

from python-mercuryapi.

clickworkorange avatar clickworkorange commented on May 30, 2024

Hang on a minute - the plot thickens! In the interest of eliminating all possibilities I disconnected the antenna from A4, and guess what; the A4 callbacks stopped coming! Instead I see some (much less frequent) A3 triggers. Hmmmm.

from python-mercuryapi.

gotthardp avatar gotthardp commented on May 30, 2024

I cannot find any possible root-cause in the code. Could you please print tag.rssi as well? Perhaps the difference of RSSI from different antennas could shed some more light onto this.

from python-mercuryapi.

clickworkorange avatar clickworkorange commented on May 30, 2024

Thanks Petr, it's certainly starting to look like I'm barking up the wrong tree here - my apologies! There must be some unexpected (to me) RF interoperation between the two readers; the prototype I built using a single reader (4 antennas) worked flawlessly and never misread even with antennas within centimetres of each other - but now with two readers I get some kind of synchronous interference at several metres... Furthermore, if I introduce a delay of 200ms between readerA.start_reading() and readerB.start_reading() the problem magically goes away!

from python-mercuryapi.

gotthardp avatar gotthardp commented on May 30, 2024

I am happy it's not a bug :) Readers transmit energy and then receive the backscattered signal. I am not an RF expert, but I see no reason why reader B couldn't receive the backscattered signal triggered by the reader A. Or, if two readers supply energy there can be more of the backscattered signal, which could explain what you experienced.

from python-mercuryapi.

clickworkorange avatar clickworkorange commented on May 30, 2024

Yes, it all makes sense; each reader will iterate between its four antennas (I think the default dwell time is 250ms), and any tags present are energised by one antenna at a time; the problem is not the antenna pulse itself, but that the same # antenna on the second reader is listening to the response from the tag at the same time. Had it been an eight channel reader I assume this wouldn't be a problem, but now I have to find a way to sequence the antennas between the two readers. Currently running a test of 1000 reads from all four readerB antennas, with increasing delay before starting readerA, and logging the number of errors for each delay (50ms to 1s in 10ms increments). Perhaps this simple approach will be sufficient. Will report back with my findings.

from python-mercuryapi.

clickworkorange avatar clickworkorange commented on May 30, 2024

In the end I opted not to use streaming mode, instead triggering manual reads of readerA followed by readerB in a loop, with a 200ms dwell time. This slows down the detection noticeably, since you may have to wait 1.6 seconds before "your" antenna is activated, but it completely solves the duplicate read issue and the delay is not that bad; in most cases the reads still feel instantaneous. Thanks to Petr for checking the code and pushing me in the right direction - sorry for wasting your time!

I guess the main take-home lesson here is that while the energising pulse from the antenna is directional and local enough that tags placed on another antenna won't activate erroneously, an activated tag's response signal is omnidirectional and will easily be picked up by another antenna 4-5 metres away, even if it's pointing in a different direction - if that antenna also happens to be listening at the same time. Caveat emptor!

from python-mercuryapi.

gotthardp avatar gotthardp commented on May 30, 2024

No problem :)

from python-mercuryapi.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.