8LikesLap Timing Decoder
02-12-2013 | 02:07 AM
#76
Hi,
I have been trying to follow this discussion with some interest. I am wandering how you plan to determine which of several transponders currenting in the timing loop the analog decoding output is assigned to? It seems to me that the antenna amp is seeing an rf hash of multiple input signals all on the same frequency. Similar to many people trying to use the same (non-2.4g) radio channel to control their cars at the same time. I have seen this situation occur many times with bad results
.
Thanks,
-Rich
I have been trying to follow this discussion with some interest. I am wandering how you plan to determine which of several transponders currenting in the timing loop the analog decoding output is assigned to? It seems to me that the antenna amp is seeing an rf hash of multiple input signals all on the same frequency. Similar to many people trying to use the same (non-2.4g) radio channel to control their cars at the same time. I have seen this situation occur many times with bad results
. Thanks,
-Rich
Occasionally the data will be garbled by simultaneous transmission, and the decoder ignores this. This will happen more often when there are large numbers of transponders passing through the loop, but given sufficient time, all of the transponders will transmit their data successfully.
02-12-2013 | 04:42 AM
#77
Tech Initiate
iTrader: (1)
Joined: Aug 2006
Posts: 34
I also suppose you need a microcontroller (fast one reading your phase detection method) with some sort of TCP stack in order to be able connect to the rf stuff at one side and at the lan port of the router to the other.
I think that the router can be a really nice for pratice/personal use of the lap timing device because you don't have to take a PC to the track.
Otherwise I think that for manage a full race you still need something more than a smartphone or a tablet, so in my opinion it will be useful if the "detection module" can be connected also to a PC.
02-12-2013 | 05:59 AM
#78
Here are the screen shots for Gerrie's previous post:
Hello Howard,
Remember I was using that nice PC Laptimer software called "PCLapcounter" for my initial testing? It is free to use for the first 10 laps. Good enough to study the AMB20 protocol, as there are no restrictions besides the maximum amount of laps that can be counted. I continued some study because I think that software is worth the 50 Euro and this amount can be easily shared amongst my RC friends that I meet in the weekends.
I would like to share some info to the community on the subject you study as well, to make the information that comes from the decoder towards the PC better understandable. The "PCLapcounter" has the option to unmark the tickbox called 'Get lap time from decoder'. It is found under the settings menu were you select the decoder-type. I have unmarked that option and fed my own strings into the COM-port that I emulate the decoder with (COM3 in my case). The strings that I generate are send from COM4, and fed back into the RX-pin of COM3. The strings that I generate from COM4 I have full controll over. In that way I debugged what is minimal needed in AMB20 protocol to have the PCLapcounter react to the incomming strings. One could think by unmark the tickbox called 'Get lap time from decoder', the string from decoder to PC can be minimalistic and only contain Car-ID_crlf, but that was not the case. I've seen you go into the direction the PC is to count the laptime, so you only want to send minimal info from decoder to PC. That is also what I think is a good idea, don't use a real time clock (RTC) in the decoder. get back to some earlier post I did, the string for AMB20 contains "@Car-ID, Time, amount of hits in the loop +crlf". Look above for exact details. During my tests of today, I tried to remove all info for time and amount of hits from the string, because I unmarked that tickbox and had the PC doing the time_measurements. It turned out not to work!
To get the PC to react and do the time-measurement rather than the decoder do the time-measurements, you still need to include all positions in the string from decoder -> PC. However that info can contain all zero's. As an axample for a passing of car with transponder-ID 16, this means: "@160000000000crlf".
I have doen a few screenshots to explain further (and because it looks nicer in a large piece of boring text...):
The above picture shows the defined transponders during my test. The transponder-ID's were set to #12, #14, #16 and #18.
In the below picture you can see the PCLapcounter software actually running. The screen was opened were it shows the incomming transponder-ID's. Clearly the 4 transponders that send their incomming passings are seen. Mind that the time_info received by the individual transponders is "0", because all send info was set to zero's!
Most interresting is the screen in which the incomming data is shown in ASCII format.
This is the last picture I include:
In writing: ASCII received by the PCLapcounter for passing of car that has transponder ID #16, without timestamp:
Send to COM3: @1600000000crlf
Received in PC: 40 31 36 00 00 00 00 00 00 00 00 00 00 0D 0A
This is my contribution so far, I hope it helps. At least the info is not lost now...
Gerrie
Remember I was using that nice PC Laptimer software called "PCLapcounter" for my initial testing? It is free to use for the first 10 laps. Good enough to study the AMB20 protocol, as there are no restrictions besides the maximum amount of laps that can be counted. I continued some study because I think that software is worth the 50 Euro and this amount can be easily shared amongst my RC friends that I meet in the weekends.
I would like to share some info to the community on the subject you study as well, to make the information that comes from the decoder towards the PC better understandable. The "PCLapcounter" has the option to unmark the tickbox called 'Get lap time from decoder'. It is found under the settings menu were you select the decoder-type. I have unmarked that option and fed my own strings into the COM-port that I emulate the decoder with (COM3 in my case). The strings that I generate are send from COM4, and fed back into the RX-pin of COM3. The strings that I generate from COM4 I have full controll over. In that way I debugged what is minimal needed in AMB20 protocol to have the PCLapcounter react to the incomming strings. One could think by unmark the tickbox called 'Get lap time from decoder', the string from decoder to PC can be minimalistic and only contain Car-ID_crlf, but that was not the case. I've seen you go into the direction the PC is to count the laptime, so you only want to send minimal info from decoder to PC. That is also what I think is a good idea, don't use a real time clock (RTC) in the decoder. get back to some earlier post I did, the string for AMB20 contains "@Car-ID, Time, amount of hits in the loop +crlf". Look above for exact details. During my tests of today, I tried to remove all info for time and amount of hits from the string, because I unmarked that tickbox and had the PC doing the time_measurements. It turned out not to work!
To get the PC to react and do the time-measurement rather than the decoder do the time-measurements, you still need to include all positions in the string from decoder -> PC. However that info can contain all zero's. As an axample for a passing of car with transponder-ID 16, this means: "@160000000000crlf".
I have doen a few screenshots to explain further (and because it looks nicer in a large piece of boring text...):
The above picture shows the defined transponders during my test. The transponder-ID's were set to #12, #14, #16 and #18.
In the below picture you can see the PCLapcounter software actually running. The screen was opened were it shows the incomming transponder-ID's. Clearly the 4 transponders that send their incomming passings are seen. Mind that the time_info received by the individual transponders is "0", because all send info was set to zero's!
Most interresting is the screen in which the incomming data is shown in ASCII format.
This is the last picture I include:
In writing: ASCII received by the PCLapcounter for passing of car that has transponder ID #16, without timestamp:
Send to COM3: @1600000000crlf
Received in PC: 40 31 36 00 00 00 00 00 00 00 00 00 00 0D 0A
This is my contribution so far, I hope it helps. At least the info is not lost now...
Gerrie
02-12-2013 | 06:08 AM
#79
Tech Apprentice
Joined: Jan 2013
Posts: 61
From: Schoonebeek
@Howard: I replied to your PM just now. The 3 pictures are in a public Photobucket album.
@OM2KW: Funny, I did the same yesterday evening, without noticing you also did some calculations on the time a car is inside a loop.
My observations were with a 1" wide loop, and a car passing the loop at 20mph, the amount of hits seen by the decoder is about 7 maximum. This is 1 additional at approaching the loop, and 1 just outside the loop. I calculated by using the earlier post from Howard in which he states the random interval between 2 busrst is set to 4mS - 8mS at 16 discreet random steps. I took the average of 6mS repeattime for the bursts.
General: If the decoder missing already missing 1 burst, the accuracy of that lap is influenced already. The middle_of_loop is then calculated from 6 in stead of 7 bursts.
Any comment?
@OM2KW: Funny, I did the same yesterday evening, without noticing you also did some calculations on the time a car is inside a loop.
My observations were with a 1" wide loop, and a car passing the loop at 20mph, the amount of hits seen by the decoder is about 7 maximum. This is 1 additional at approaching the loop, and 1 just outside the loop. I calculated by using the earlier post from Howard in which he states the random interval between 2 busrst is set to 4mS - 8mS at 16 discreet random steps. I took the average of 6mS repeattime for the bursts.
General: If the decoder missing already missing 1 burst, the accuracy of that lap is influenced already. The middle_of_loop is then calculated from 6 in stead of 7 bursts.
Any comment?
02-12-2013 | 06:48 AM
#80
@Howard: I replied to your PM just now. The 3 pictures are in a public Photobucket album.
@OM2KW: Funny, I did the same yesterday evening, without noticing you also did some calculations on the time a car is inside a loop.
My observations were with a 1" wide loop, and a car passing the loop at 20mph, the amount of hits seen by the decoder is about 7 maximum. This is 1 additional at approaching the loop, and 1 just outside the loop. I calculated by using the earlier post from Howard in which he states the random interval between 2 busrst is set to 4mS - 8mS at 16 discreet random steps. I took the average of 6mS repeattime for the bursts.
General: If the decoder missing already missing 1 burst, the accuracy of that lap is influenced already. The middle_of_loop is then calculated from 6 in stead of 7 bursts.
Any comment?
@OM2KW: Funny, I did the same yesterday evening, without noticing you also did some calculations on the time a car is inside a loop.
My observations were with a 1" wide loop, and a car passing the loop at 20mph, the amount of hits seen by the decoder is about 7 maximum. This is 1 additional at approaching the loop, and 1 just outside the loop. I calculated by using the earlier post from Howard in which he states the random interval between 2 busrst is set to 4mS - 8mS at 16 discreet random steps. I took the average of 6mS repeattime for the bursts.
General: If the decoder missing already missing 1 burst, the accuracy of that lap is influenced already. The middle_of_loop is then calculated from 6 in stead of 7 bursts.
Any comment?
If we use only the first and last hits through the loop to calculate lap time, and we miss either the first or the last (but still have the next nearest hit available), then the loop crossing time will be off by 2 ms (assuming a 4 ms repetition rate), plus any quantization error (from sending the time stamp in increments of 1 ms). 3 ms is close enough for me! I don't believe that AMB claims much better than that.
If the first and last hits are missed, then the average of the next nearest hits will give the same number as if none were missed.
Using time stamp increments of 1 ms is somewhat arbitrary. We could easily chop it up (perhaps 8x?) finer to reduce the quantization error.
I'm certainly open to any other ways of calculating the loop crossing time. We won't use AMB's method, but there are probably others that I haven't considered. I just suggested taking the average of the first and last time stamps because it is simple, and can be done very quickly in a small microprocessor (add the time stamps, right shift the result) if it becomes necessary.
02-12-2013 | 07:42 AM
#81
Tech Initiate
iTrader: (1)
Joined: Aug 2006
Posts: 34
The repetition time is 2 to 4 ms. Please forgive me if I stated this incorrectly before.
If we use only the first and last hits through the loop to calculate lap time, and we miss either the first or the last (but still have the next nearest hit available), then the loop crossing time will be off by 2 ms (assuming a 4 ms repetition rate), plus any quantization error (from sending the time stamp in increments of 1 ms). 3 ms is close enough for me! I don't believe that AMB claims much better than that.
If the first and last hits are missed, then the average of the next nearest hits will give the same number as if none were missed.
Using time stamp increments of 1 ms is somewhat arbitrary. We could easily chop it up (perhaps 8x?) finer to reduce the quantization error.
I'm certainly open to any other ways of calculating the loop crossing time. We won't use AMB's method, but there are probably others that I haven't considered. I just suggested taking the average of the first and last time stamps because it is simple, and can be done very quickly in a small microprocessor (add the time stamps, right shift the result) if it becomes necessary.
If we use only the first and last hits through the loop to calculate lap time, and we miss either the first or the last (but still have the next nearest hit available), then the loop crossing time will be off by 2 ms (assuming a 4 ms repetition rate), plus any quantization error (from sending the time stamp in increments of 1 ms). 3 ms is close enough for me! I don't believe that AMB claims much better than that.
If the first and last hits are missed, then the average of the next nearest hits will give the same number as if none were missed.
Using time stamp increments of 1 ms is somewhat arbitrary. We could easily chop it up (perhaps 8x?) finer to reduce the quantization error.
I'm certainly open to any other ways of calculating the loop crossing time. We won't use AMB's method, but there are probably others that I haven't considered. I just suggested taking the average of the first and last time stamps because it is simple, and can be done very quickly in a small microprocessor (add the time stamps, right shift the result) if it becomes necessary.
It seems that they not only measure the hits, but also the strength of the received signal, so probably they can be more accurate.
However personally I don't care about 3, 4 or 50ms of error on my laps, I only want to know the correct final standings
.
02-12-2013 | 07:49 AM
#82
If you go at the end of this document http://www.transponderservices.com/d...epaper_RC4.pdf there are some test results of the amb transponder/decoder.
It seems that they not only measure the hits, but also the strength of the received signal, so probably they can be more accurate.
It seems that they not only measure the hits, but also the strength of the received signal, so probably they can be more accurate.
http://www.rctech.net/forum/11728173-post33.html
Spoken like a true racer!
02-12-2013 | 10:47 AM
#83
Tech Apprentice
iTrader: (3)
Joined: Dec 2012
Posts: 59
That is an excellent question! Each transponder transmits its own unique digital data train, but only for a short time (88 microseconds). It then stays inactive (not transmitting) for a much longer time (about 2 to 4 milliseconds) so that other transponders can send their data. This inactive time is varied, as freexray has pointed out, so that if two transponders send their data at the same time during any given transmission, they will send at a different time in the next attempt.
Occasionally the data will be garbled by simultaneous transmission, and the decoder ignores this. This will happen more often when there are large numbers of transponders passing through the loop, but given sufficient time, all of the transponders will transmit their data successfully.
Occasionally the data will be garbled by simultaneous transmission, and the decoder ignores this. This will happen more often when there are large numbers of transponders passing through the loop, but given sufficient time, all of the transponders will transmit their data successfully.
-Rich
02-12-2013 | 02:30 PM
#84
Tech Initiate
Joined: Feb 2013
Posts: 29
I think that signal strength measurement will not give more precise in timing measurement. SS measurement is in my opinion not fast enough especially in situation when you have more transponders close to loop. I can not imagine how we can measure signal strength for multiple sources with abt 88us bursts very very close each other in time and sometimes also overlapping in time. In my opinion 1ms reading of original system is only marketing number. And i also vote for relative accuracy - final standings
02-12-2013 | 02:36 PM
#86
Tech Initiate
Joined: Feb 2013
Posts: 29
@ema-77
I thing that small hw as router board can handle all race situations. Of course it is not very convient to set it up via smartphone but for race event you can use larger gui e.g. tablet of pc. I just want to have web gui for control iow. at client (pc, smartphone, tablet) you do not need any apps besides of web browser
I thing that small hw as router board can handle all race situations. Of course it is not very convient to set it up via smartphone but for race event you can use larger gui e.g. tablet of pc. I just want to have web gui for control iow. at client (pc, smartphone, tablet) you do not need any apps besides of web browser
02-12-2013 | 03:10 PM
#87
I think that signal strength measurement will not give more precise in timing measurement. SS measurement is in my opinion not fast enough especially in situation when you have more transponders close to loop. I can not imagine how we can measure signal strength for multiple sources with abt 88us bursts very very close each other in time and sometimes also overlapping in time. In my opinion 1ms reading of original system is only marketing number. And i also vote for relative accuracy - final standings
@ema-77
I thing that small hw as router board can handle all race situations. Of course it is not very convient to set it up via smartphone but for race event you can use larger gui e.g. tablet of pc. I just want to have web gui for control iow. at client (pc, smartphone, tablet) you do not need any apps besides of web browser
I thing that small hw as router board can handle all race situations. Of course it is not very convient to set it up via smartphone but for race event you can use larger gui e.g. tablet of pc. I just want to have web gui for control iow. at client (pc, smartphone, tablet) you do not need any apps besides of web browser
02-13-2013 | 11:10 AM
#88
Tech Initiate
Joined: Feb 2013
Posts: 29
I think that we are speaking about same think but different approach. I am quite busy and dont think will have time to seriously work in separate thread, if you do not mind i will try to share ideas about topic here. My idea is that more ideas can give better result in joint effort.
02-13-2013 | 11:47 AM
#90
I think that we are speaking about same think but different approach. I am quite busy and dont think will have time to seriously work in separate thread, if you do not mind i will try to share ideas about topic here. My idea is that more ideas can give better result in joint effort.
That will be determined during testing. Right now the front end will tolerate substantial overdrive without losing phase information. If AGC proves necessary, I can easily add it (probably at the phase detector input amplifier).
