Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

RF Tags collision emulation

  1. Jun 8, 2007 #1
    We are developing a system of RF tags for open space storage place. This are mostly containers. I need to make simulation of collisions in simultaneous Tag's transmission. Let's say I need 10 Tags to send update to base stations at exactly the same time. The idea to connect tags with wires is not good as we will have to use kilometers of wire and it can not be placed everywhere. So far I have found some GPS based solution http://www.xdimax.com/interX/interX.html" [Broken]
    They have GPS and unit can be programmed to output signal at predefined times . Some on---off----on---of sequence. If I take 10 units they will do the same and with good precision.
    I wounder if there is any other solution? Any chance for instance to program all tags to make synchronous transmits and lay on Tag's crystal synchronization?
    In other words if I take a number of 4MHz Cristals what can be a drift between them let's say in one hour period?
    Last edited by a moderator: May 2, 2017
  2. jcsd
  3. Jun 8, 2007 #2


    User Avatar

    Staff: Mentor

    Are these tags capable of 2-way communication, or are they transmit only? If they are transmit only, then you will either need to do something with synchronized times, or they will need to use Unacknowledged Repeat service to increase the probability of getting their messages through.

    If they are capable of 2-way communication, then just have the master device poll them periodically.
  4. Jun 9, 2007 #3
    Sure if it were two way communication there would be no problem. Tags must be cheap and they have only TX function. We have developed algorithms to prevent collisions and so far it works. But we want to understand how this algorithm is good and how good were our assumptions about TX strength and interference. Also it depends very much on Base Stations positioning. Shortly we want to emulate worst cases and to do it we have to synchronize tags.
    I looked once again at interX http://www.xdimax.com/interX/interX.html and contacted Dimax. interX can be programmed to provide pulse Ton---Toff---Ton---Toff .....
    Ton - on time
    Toff - off time
    And synchronizations between interX devices can be less then 100uS. This is what we need.
    So everything looks nice except this test for 10 units will cost us $2500.
    But looks like we are going to order it next week as time costs much more.
  5. Jun 12, 2007 #4


    User Avatar

    You're inquiring about some fairly complex issues and
    without better specification of what the questions are and
    what the variables and configuration options are, it's hard
    to come up with suggestions.

    Crystal timing drift between sets of crystals is usually
    difficult to estimate without having measurements of
    the individual units. This is because the oscillator circuit's
    engineering has some effect on the crystal oscillation
    frequency, and because there's intrinsic variability in the
    stability and frequency of timing of the crystal oscillators
    themselves. Generally one will buy crystals or
    crystal controlled oscillators with an accuracy specification
    of so many parts per million maximum frequency error
    over a specified range of operating conditions
    (age, temperature, humidity). Often the PPM error of
    the nominal oscillation frequency is somewhere
    between 100PPM and 25PPM over age and temperature
    for many inexpensive commercial units. Individual samples
    of these oscillators are deemed working if the frequency
    they generate is anywhere within this specified error band.

    However any individual unit will likely have some base error
    that is its 'normal' error relative to the nominal frequency,
    and it will tend to repeatably oscillate near that repeatable
    offset frequency. It will then drift in frequency relative to
    temperature variances, and also the drift and random
    short term error will increase as the unit is subjected to
    instability due to being newly powered on before it
    stabilizes, due to abrupt vibrations, abrupt changes in
    temperature, etc. Over a longer time once a stable
    environment is created after minutes or hours of time,
    the frequency will become more stable and then tend to
    stay at its current value showing only very slow (months,
    years) drifts if the operating conditions / environment do
    not change.

    Hence you can pretty much accurately predict the
    accumulated time error of a set of crystal controlled timing
    devices because unique to their particular oscillators the
    error will be mostly stable and predictable, and the error
    will not usually vary much once you know the value for
    the units. Hence you can say that "unit #3 has a clock
    drift of -28 seconds per week", or "unit #7 has a clock
    drift of +52 seconds per week" etc. and program in
    compensations relative to the mostly fixed individual errors.

    If the units are GPS connected, however, it seems sensible
    that they will reset their real-time clocks frequently
    based on the GPS time broadcast which will maintain
    all units' clocks in near perpetual perfect accuracy
    so long as they can frequently correctly receive the
    GPS signal.

    As for modeling the transmit / receive error situations
    related to signal attenuation, noise,
    multiple active transmitters, et. al. I'm afraid you'll either
    have to deal with a very simplified "educated estimate"
    of reliability, or be prepared to create a detailed analytical
    model of the various variables (signal power, antenna
    pattern, receiver sensitivity, RF noise in the bandwidth,
    interference from multiple units, signal modulation type,
    packet structure, packet length, bit rate, presence of any
    type of integrity parity/checksum/CRC, presence of
    any forward error correction encoding in the data,
    probability of how many transmissions will overlap based
    upon transmission timing / frequency / length, possibility
    of signal obstruction by intermittent material movements,
    possibility of battery depletion, possibility of units failing
    to receive GPS temporarily, possibility of
    software/hardware error causing units to reset or lose
    some of their timing / time data, etc. etc.).

    It's not all that complex to model the system fairly
    accurately if you know the details, but if you're so short
    on time / expertise to invest, and may not be privy to all
    the technical data required to model the system, it's
    a difficult prospect to get more accuracy than a rough
    initial guesstimate.

    In a unidirectional communication,
    redundancy of transmission, and presence of forward
    error correction information will help reliability greatly.
    If you can devise to schedule the transmissions to occur
    as far apart from each other in time as possible, that'll
    help eliminate the opportunity for errors due to multiple
    simultaneous transmissions.

    The best situation would be to ensure GPS based time
    clock resynchronization of all tag units at least every couple
    of days, and allow each node a unique real time clock
    interval of a certain hour, minute, and ten second window
    in which to transmit. Then ten nodes could transmit
    in sequence each over its own 10 second period and the
    whole set would be received withon 100 seconds. I'm
    guessing that 10 seconds is long enough for each node
    to transmit all its data at least two or three times for
    redundancy in case unrelated receiver noise or fault
    causes a reception error for one of the transmissions.
    If node battery life is suitable to allow such retransmissions
    then they'll add a good amount of extra reliability to the

    If a 10 second window is too long for your aplication you
    could shorten it to something like 1 or 2 seconds, though
    of course you'd have to make sure the units synchronized
    their real time clocks often enough that they're each
    always within 1 second of the precisely correct time,
    which probably means taking a GPS time fix at least once
    or twice a day if their clocks are quite prone to drift as
    many are.

    Ensuring the whole set of nodes transmits their data
    redundantly perhaps 10 minutes apart from the primary
    scheduled time will help improve reliability in the case
    that the main receiver or its computer has a fault and
    needs to be quickly rebooted / replaced or whatever.
  6. Jun 13, 2007 #5
    Thanks for reply. Yes all your notes are right. We mae theoretical calculations of different crystals with 10 to 30 PPM and found out that this will not suite our needs. And I do agree that emulation of collision is not something real as there so many additional factors that can not be estimated. Even wether conditions can make a big difference in results. But not everything is under engineer control. There are some political issued that force us to conduct this emulation.
    Anyway we decided to go for GPS solution mentioned above. So far it looks quite good for our needs. We are preparing physical and mechanical connection between interX units and our tags. The GPS solution will give us below 10ms synchronization ( actually it can be less then 1ms but will require more battery power ) 10ms is quite good for us.
    We are going to check both collisions and collisions preventing algorithm.
    I alsways ask my boss why we could not do it in simulator but...
  7. Jun 18, 2007 #6
    Check www.ekahau.fi . They make RFID tags based on 802.11 wireless technology. Having multiple WiFi Access Points around, this technology can also determine the position of the tags.
  8. Sep 21, 2007 #7
    We have finally made emulations with interX (http://www.xdimax.com/interX/interX.html)
    and got required information about system our system stability and ranges. They made a number of vital modifications in interX and all after all we are quite satisfied with testing system and especially testing results.
Share this great discussion with others via Reddit, Google+, Twitter, or Facebook

Similar Threads for Tags collision emulation
How RFID tags work