asked on
tutorial on building a counter for a RFID device
I got advise from an expert as follows;
You can make a 300 MHz counter with a CPLD (a programmable logic device) that costs ~$20.
The counter (18-bits) would run continuously.
The transmitter pings every millisecond.
Each receiver would generate one COUNT reading per ping.
The computer would take all the COUNT readings and crunch them to calculate the transmitter position.
https://www.experts-exchange.com/questions/24190697/measuring-time-delay-between-RFID-wireless-reader-and-tag.html?anchorAnswerId=23776425#a23776425
Does anyone know of any text books or online tutorials that may assist in building this. Also would I be able to use a RS-232 to USB adaptor for this device as my laptop has only USB ports.
thanks
You can make a 300 MHz counter with a CPLD (a programmable logic device) that costs ~$20.
The counter (18-bits) would run continuously.
The transmitter pings every millisecond.
Each receiver would generate one COUNT reading per ping.
The computer would take all the COUNT readings and crunch them to calculate the transmitter position.
https://www.experts-exchange.com/questions/24190697/measuring-time-delay-between-RFID-wireless-reader-and-tag.html?anchorAnswerId=23776425#a23776425
Does anyone know of any text books or online tutorials that may assist in building this. Also would I be able to use a RS-232 to USB adaptor for this device as my laptop has only USB ports.
thanks
Math / Science
Last Comment
d-glitch
ASKER
what does this mean - "crunch"?
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
This is part of my major project that was given to me by my supervisor in college for my final year in college. He advised me to purchase those readers and tags from ebay which I done.
I am trying to do the system based on DTOA using the notes as per attached and I originally thought that the java code running on the computer with the three RFID readers attached via USB to RS-232 would be enough. I did not realise the issue with counters and synchronization etc.
The technology must be RFID but the accuracy or resolution is not important. I just need a working system.
"The hardest part of this (for me) would be the RF TX and RX designs. "
Are you referring to the counter here?
location-algorithm.doc
I am trying to do the system based on DTOA using the notes as per attached and I originally thought that the java code running on the computer with the three RFID readers attached via USB to RS-232 would be enough. I did not realise the issue with counters and synchronization etc.
The technology must be RFID but the accuracy or resolution is not important. I just need a working system.
"The hardest part of this (for me) would be the RF TX and RX designs. "
Are you referring to the counter here?
location-algorithm.doc
"what does this mean - "crunch"?"
-
I do not know. you are the one who used it.
-
I do not know. you are the one who used it.
ASKER
This is in the original question - crunch is quoted
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
by "crunch" it means take the time difference and calculate the hyperbolas, then find their intersection.
d-glitch gives a good outline of a "crunch" procedure and suggests the iterative process which I would not have thought of.
ASKER
thanks aburr,
d-glitch is there anything you'd like to add here? Your advise so far has been excellent! Can you please take a look at my attachment? How well would the computer without the additional clock work? It would even be sufficent for me if the readers could see what quadrant of the room you were in and I could work on improving from there possibly with a clock and using the advise given by you above.
d-glitch is there anything you'd like to add here? Your advise so far has been excellent! Can you please take a look at my attachment? How well would the computer without the additional clock work? It would even be sufficent for me if the readers could see what quadrant of the room you were in and I could work on improving from there possibly with a clock and using the advise given by you above.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
This is great.... ok we have access to oscilloscopes in the lab at college I will do experiments and will open a new case with my results. Thanks so much for your help so far.... I really appreciate it!!
ASKER
thanks again
There is nothing wrong with the location algorithm. But it requires enormous timing precision.
If you experimental setup consist of:
RFID TX1 ==> RFID RX1 ==> RS233 ==> USB ==> PC
I believe the nanosecond DTOA data will be swamped by 100's or even 1000's of microseconds of jitter.
You can run two Serial Ports off one USB port. But you can't guarantee any degree of synchronization
between then. You can run each Serial Port into a its own USB port, but you can guarantee any
synchronization there either.
Even if you connect the hardware as best you can, and code the location algorithm perfectly, 100 us of
jitter correspond to errors of 2700 miles. You can tell for sure the planet you're on, and maybe the continent, but definitely not the state.
Early prototyping is essential.
Take the hardware you've got and get it running.
Don't worry at all about the location algorithm yet.
You need to get raw DTOA data from your hardware ASAP.
A quantitative negative outcome is a perfectly fine result for a senior project.
"This technique does not work because ..."
If you experimental setup consist of:
RFID TX1 ==> RFID RX1 ==> RS233 ==> USB ==> PC
I believe the nanosecond DTOA data will be swamped by 100's or even 1000's of microseconds of jitter.
You can run two Serial Ports off one USB port. But you can't guarantee any degree of synchronization
between then. You can run each Serial Port into a its own USB port, but you can guarantee any
synchronization there either.
Even if you connect the hardware as best you can, and code the location algorithm perfectly, 100 us of
jitter correspond to errors of 2700 miles. You can tell for sure the planet you're on, and maybe the continent, but definitely not the state.
Early prototyping is essential.
Take the hardware you've got and get it running.
Don't worry at all about the location algorithm yet.
You need to get raw DTOA data from your hardware ASAP.
A quantitative negative outcome is a perfectly fine result for a senior project.
"This technique does not work because ..."
ASKER
=> Yes I have the ports working and the java program is communicating with them fine...
I am currently studying the The ARRL Handbook that you advised and it is excellent. It is just the book and information I need and am taking the note of what you advise. I will work on this in the labs and this will def be productive
=> "You can run two Serial Ports off one USB port. But you can't guarantee any degree of synchronization
between then. You can run each Serial Port into a its own USB port, but you can guarantee any
synchronization there either.
This is excellent advise because it was just the assumption I was making
=> believe the nanosecond DTOA data will be swamped by 100's or even 1000's of microseconds of jitter
This is the part I am not sure of... how is this jitter caused? Actually I am going to open a new question on this as it is just that... one sec
I am currently studying the The ARRL Handbook that you advised and it is excellent. It is just the book and information I need and am taking the note of what you advise. I will work on this in the labs and this will def be productive
=> "You can run two Serial Ports off one USB port. But you can't guarantee any degree of synchronization
between then. You can run each Serial Port into a its own USB port, but you can guarantee any
synchronization there either.
This is excellent advise because it was just the assumption I was making
=> believe the nanosecond DTOA data will be swamped by 100's or even 1000's of microseconds of jitter
This is the part I am not sure of... how is this jitter caused? Actually I am going to open a new question on this as it is just that... one sec
>> Even if you connect the hardware as best you can, and code the location algorithm perfectly, 100 us
of jitter correspond to errors of 2700 miles. You can tell for sure the planet you're on, and maybe the
continent, but definitely not the state.
100 ns jitter ==> 18.6 miles error
of jitter correspond to errors of 2700 miles. You can tell for sure the planet you're on, and maybe the
continent, but definitely not the state.
100 ns jitter ==> 18.6 miles error
ASKER
=> 100 ns jitter ==> 18.6 miles error
how is this calculated?
how is this calculated?
=> 100 ns jitter ==> 18.6 miles error
That should be => 100 us jitter ==> 18.6 miles error
==========================
The speed of light is 3 x 10^8 m/s = 186,000 miles/s ~ 1 ft/ns
100 us is 1 x 10^-4 seconds
So you move the decimal point 4 places to the left.
100 us jitter ==> 18.6 miles error
100 ns jitter ==> 100 feet error
That should be => 100 us jitter ==> 18.6 miles error
==========================
The speed of light is 3 x 10^8 m/s = 186,000 miles/s ~ 1 ft/ns
100 us is 1 x 10^-4 seconds
So you move the decimal point 4 places to the left.
100 us jitter ==> 18.6 miles error
100 ns jitter ==> 100 feet error
The devil is in the word "crunch" That is not a command in most computer languages.
The difficulty is not in getting hardware to send and receive signals. It is getting the signal to be sufficently stable to give you readings to the required accuracy.
For books, look in amazon under "programable logic devices".