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...):


(Not allowed to post pictures because I did not yet post enough...Hmmm...)


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!


(Not allowed to post pictures because I did not yet post enough...Hmmm...)


Most interresting is the screen in which the incomming data is shown in ASCII format.
This is the last picture I include:

(Not allowed to post pictures because I did not yet post enough...Hmmm...)


I hope the pictures are visible, if not I try again.
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...
Does the counts you refer to match the received ASCII I see in the PCLapCounter programm?

Gerrie

@Howard: Can I send the pictures per PM or e-mail to you, so you can make the visible?
See my website for my e-mail adress to get into contact to me:
w w w.pa3exv.nl under 'contact me'.

Hi Gerrie,

Thank you for your observations!

The latency involved in the transmission and reception of data might preclude having the lap-counting PC create a time stamp for each transponder crossing. You mentioned in an earlier post that the AMB20 was running at 9600 baud. Then sending ten characters of 10 bits each would take over 10 milliseconds. It's anyone's guess how long the PC would take to service the interrupt for data reception, look up the time, and save the results. If the total is 20 or 30 milliseconds, then lap time accuracy could suffer if more than one car crossed the line simultaneously, due to the "bottleneck" in data transmission. If the baud rate were much higher, then it might be okay.

I still intend to have the decoder send a time stamp for each packet, but it will send ALL valid received packets. The PC can then sort though these to determine the crossing time for each transponder. I still think it will be much easier to do this task on the PC, since it will have several orders of magnitude more computational capability and memory than the decoder. Since the decoder has already included the time stamp with each packet, the PC can take its time doing all these chores. A one second delay in calculating the result would be acceptable, since the result would still reflect an accurate transponder loop-crossing time, and therefore, lap time.

If it turns out that the PC will actually be fast enough to provide the time stamp, then that makes the decoder software even simpler! The data transmission between the decoder and PC will probably be via USB, so that delay will be minimal.

Gerrie, I sent you a PM.

Our readers REALLY need to check out Gerrie's work at:

http://www.pa3exv.nl/

This is awesome stuff!

very nice work.

For the decoder -> PC -> lap counting software, there is no need for the decoder to directly communicate with the lap counting software (especially if the lap counting software can communicate using sockets).
This means that the decoder can communicate with some software (be it python, c, java, ect, ect) that translates from the decoder to whatever is needed for the lap counting software. Also gives a place to do the calculations ect.

USB, especially if used as CDC has higher latency than you might think. from memory, up to 16ms latency (pure usb, not os and related). There will be a strong trade off between latency and throughput (although there will be little data, so throughput is irrelevant).

I would not even try for real time operations on Windows (or linux without patches for that matter) as there are too many ways for a process not to run on time.

Thanks for the information! It sounds like it is best to stick to the original plan of having the decoder time-stamp each data packet.

Do you know of anyone who has the ability, time, and desire to write the PC software? My wife has suggested that I just bite the bullet and do it, using it as an opportunity to learn C. But that might take longer than I want to wait!

Hi, very interested thread, i just want to add some my observations.
I am also trying to construct receiver for reading 5mhz transponders. I found that usually you can get several tens of reading transponder during single loop pass. I wanted to calculate exact time of loop passing by mid value between first packet detected and last packet detected. By this approach you do not need measure signal strength which analog value and measurement can make additional delay. You need just to memorize time stamp of first and last detected packet during single loop pass.

regards, Brano

Thanks for your interest! That's exactly what I'm going to do, as stated in post #55.

How are you doing the phase detection?

Here are schematics for the prototype loop amplifier and phase detector input amplifier. I drew them using TinyCAD, which I just started playing with. The result is much prettier than my chicken-scratchings you've probably seen in my transponder thread!

Loop Amplifier: C1 tunes the loop to 5MHz. The value shown is for the 1'x8' loop described in post #42. The amplifier is powered from the center conductor of the coax cable.

http://i1191.photobucket.com/albums/...ps0e52c604.jpg

Phase Detector Input Amplifier: This translates the loop amplifier output to logic levels. The loop amplifier is powered via R1.

http://i1191.photobucket.com/albums/...psa8026fb6.jpg

EDIT: For the latest schematics, see post 206:

http://www.rctech.net/forum/12118142-post206.html

regarding phase detection simple method will be to measure pulse length(PL) by mcu and decide if PL>1/2PERIOD and PL=<PERIOD then phase change occurs. This does not need clock recovery. Other possibility is use adc and fpga but that is much more complicated.

sorry, i missed your #55. I just want to send to PC only results it means 1 packet (ID, timestam,p ...) per loop pass. As there is an OS on PC ant those are not real time, i think this is a problem because all transfer will delayed. I tried to calculate worst case.
5 cars on loop @30kmph, loop width .5m it means 0.06sec on loop with 20 packets for each car it is 100 packet total with in 0.06 sec. With all usb delay etc i think that data could be delayed and mainly mcu will have to cache all data. I think that is is easier to process data in mcu and send to pc only results.

I also wanted not to use pc as main system but use low cost router with linux system (eg tplink wr1043 and openwrt firmware) and present results via web server via wifi. In this case you just need small hw and can use any web client e.g. on smartphone.

Where will the software to run the race reside?

in router (eg wr1043 for $60). I have already done similar solution. I do have similar router with openwrt firmware running my app for our antenna rotor controller with gui via web browser

Multi-transponder differentiation
 

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

This is correct, that is why the transponders transmit with a pseudo-random delay between bursts. also a reason the decoder needs to interpolate the valid packets to find the crossing point.

The code on the pc would be trivial if the lap counting software can use network attached decoders (code would use sockets to communicate).
If it needs to use a com port, the software becomes "difficult" as you will require a driver to create a virtual com port (vcp) (not impossible, i know roughly the right way to approach this, but drives are outside my experience).

That being said i have seen some free software that converts from sockets to vcp, which would allow the processing to be done anywhere (including on the same pc), passed over the network (you don't actually need to be connected to a network to pass data to yourself) to the socket-vcp driver.

EDIT:
I often think c gets a reputation of being hard, simply because people look at code made by people who are attempting to minimize the amount of typing they need to do. code that has been commented and typed to be clearly defined is as easy to read as any language.
If you can code asm, the jump to c is not that great.