It's good to know my intuition was correct! In any case, the active amplifier will cost much less than a proper balun transformer.

As promised, here are some pictures of the loop amplifier.

The first picture shows the timing loop. It is 1' x 8', and uses Radio Shack #278-1301, 24 AWG stranded "zip" speaker wire, with a 3' lead-in section that is still joined as a pair, and the loop formed by separating the wires and soldering them together at the “far” end of the loop (which is actually closest to the camera in this pic). The loop resonates in conjunction with a capacitor at the amplifier input. Different loop dimensions require a different capacitor (more capacitance for a smaller loop), but the value is not critical because the Q is relatively low. I taped the loop to some corrugated cardboard to hold the proper dimensions, and it folds up in the center to get it out of the way when I’m not using it.

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

Here is an AMB transponder running from a battery, and located about 8" above the center of the timing loop.

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

Here’s the loop amplifier driving 25’ of 75 ohm coaxial cable. The red alligator clip is the +5V supply, which feeds the center conductor through a 75 ohm termination resistor. The scope probe is monitoring the signal output on the center conductor. As you can see, there’s not much required for the amplifier (it uses six transistors).

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

Finally, here is the output of the loop amplifier. It follows the carrier phase inversions very well.

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

For AMB systems, the loop is suppose to have a resistor in the middle of the loop. It was in the RC2 Decoder instructions, so if you wanted to make your own loops. The resistor was a 470 Ohm. The loop is 1ft apart.

True about the loop resistor,... But he is building the transformer. That according to AMB/MyLaps should read 100K ohms at both the loop leads and the BNC connector. Back when I got my rc decoder (as there never was an rc2) I noticed it said 1' apart.... The system20 said 2'... so I emailed AMB about it.. They replied with that was a misprint and it should be 20" - 24" apart... still have this email.


There have been a handful of threads on here about the transformer.

http://www.rctech.net/forum/electric...need-help.html

Ok, Thanks for clearing that up. They told me with the new RC4 it should be 2ft apart, but when I called, they said 1ft is ok. So I guess we are all in the clear!!! :lol:

Thanks for the info, gentlemen. I prefer to keep all of the electronic components on the amplifier board so they are better protected. The loop will be just wire, nothing else.

My preamplifier design does not need a transformer. All of the common-mode rejection and impedance matching is done electronically, and for less money than what just the transformer would cost.

But since we are talking of loop sizes, it sounds like it would be a good idea to include a couple of jumper blocks at the preamplifier to match it to a range of loop sizes. That way there's no need to attach additional components to different size loops-- just select the appropriate jumper setting. I can envision the 1' x 8' size for "normal" use, and maybe a 1' x 6' size for narrow 1/12 scale tracks, and perhaps a 6" x 4' size for micro cars like Mini-Z's. Do you have any requests or suggestions?

As long as loop sizes (length) are flexible, and with any type of readily available wire, it should be fine. Ive used as small as 22 gauge speaker wire, and as big as 14awg copper house wire (an experiment in durability). It all works well.

Can this be a personal lap timing device?

It could certainly be used for that, but setting up your own loop, decoder, and computer would be inconvenient.

My local track is interested in a mylaps compatible timing system to replace their current "non-standard" system, but the mylaps system exceeds their budget. Do you have any idea what this system will cost? Thanks

Hello Howard,
Nice to see you are doing some RF stuff...As I am already over 30 years active in HAM radio (licenced radio amateur), I offer my help if you need any. After I posted my last reaction, I continued at my end a bit as well. I tried the transmitter you shared with us and found exactly what you wrote; The second harmonic is perfectly cancelled out, only if the TX-loop is steered by a perfectly balanced signal (duty cucly exactly 100%). Already the slightest unbalance raises the 2nd harmonic by tens (10's) of dB's. I found out because I coupled a signalgenerator (square-wave output) to the 74AC86 rather than a quarz (not on hand at that time). I could vary the DC-offset as well as the input-level. I needed very carefull adjustments to cancel out the 2nd harmonic. Probably a divide by 2 would be better and starting from 10MHz. This would result in a always 100% duty-cycle with 5MHz. I was not able to give BPSK modulation, for this I need to controll the 2 pins at the XOR were you have the PIC...
For the receiver were you work on now, you can look at 40m receiver designs which radio-amateurs build all the time for poratble use. These operate at 7MHz and can easily be modified to 5MHz, The designs often have AGC +signal meter, which signal you can use for the max_loop_level you need to determine the middle loop passage for exact timing. The only thing is it needs to be very fast as cars can move over the loop at high speeds.
My lab at home has all needed test_equipment to perform RF-measurements like sensitivity, spectrum_measurement, IM-test. If you need assistance, don't hesitate to ask and we can test a certain design on performance.

Keep up the good work,

Gerrie

I estimate that it could be below $500. But that is only a rough guess, and here's why:

Most people only consider the cost of the components and labor that goes into a product when estimating what a proper retail price should be. But this is only a small fraction of the cost of making a product, especially one made in small quantities, like a decoder or even a transponder. Far greater costs are incurred from research and development, testing for compliance with government regulations, customer support, and all the other things that it takes to run a business (like rent, phones, etc.).

After all these costs are spread across a production run, then a price can be established to generate a profit for the company. Sometimes this is done on a "cost plus" basis, but if a company has a unique product with little or no competition, then it is usually best to charge "what the market will bear". That's how things that cost $5 to make end up selling for $100.

I'm still considering releasing this design as an "open-source" project, so that any individual or company would be free to use it. But first it would make financial sense to try to sell the design. This is jumping the gun a bit, as the design is not complete! I'd still love it if a competitive company would release a decoder, thus removing any need to complete the design. But that hasn't happened... yet.

My apologies for a long-winded response for such a concise question.

Hi Gerrie,

Thanks for the encouragement and offer of help.

I also have a ham license, but I have only used it for RC cars. When I was racing competitively many decades ago, I figured that if I used 6 meters, then I would have at least a few channels available exclusively to me, rather than have to wait for a frequency clip. When I showed up at a ROAR 1/8 onroad gas nationals, I had not just a few frequencies to myself, I had two entire BANDS (50 and 53 MHz) all to myself!

You are correct, in order to get perfect cancellation of the second harmonic requires exactly 50% duty cycle for the drive signal. This is by no means necessary for the transponder, though, and the AMB transponder output waveform has quite a substantial second harmonic component which is obvious just by looking at the waveform. Running an FFT confirms this.

I'm no expert, but I am reasonably proficient in many aspects of RF circuitry, and have designed both superheterodyne and super-regenerative receivers (which only people of our age will remember!). I don't tend to copy designs, as I enjoy the challenge of coming up with something different. I mentioned in my transponder thread that I have never seen the inside of an AMB transponder, and that is also true for the decoder. I have no need and no desire to do that.

You mentioned the technique of using the AGC signal strength to determine the middle loop passage, which we discussed previously. I believe AMB has a patent on this, so I will be using a different method.

I would still like to keep the intelligence inside the decoder to a minimum, and place more of a workload on the lap counting computer. This means I could use help from someone fluent in PC software to create a driver program to take the raw data from the decoder and convert it to an appropriate format to present to the lap counting program. Tasks like determining the crossing time for each car and parsing extraneous hits really belong in the lap counting computer. (There is no point of putting anything in the decoder that can be done for free in the computer!) I have had one individual express interest, but I have not pursued anything to this point, as the design is not yet to that stage. I think it will be in a few weeks.

Also, if you have the equipment necessary to test the decoder or transponder for FCC compliance, let me know!

I have daily access to an RF anerchoic chamber, we normally use it for verification were we test Bluetooth designs that we work on. Our chamber uses antenna's from 200Mhz upwards to 10GHz. For 5MHz the dimensions of 6m x 6m is also a bit too small I think. However if using a pick_up coil can easily unviel the harmonics as you already showed.
To pass FCC more easy, the working frequency would be better to shift up to 13.56MHz. Have you concidered that? Needless to say the AMB original transponders will not work to your decoder...but may be the advantage to overcome FCC compensates for that.

I discussed the decoder-plans you published so-far with our DSP experts. They asked me why not use over-sampling inside the decoder to retrieve the clock-signal for the BPSK decoding back from the carrier? I could not answer, can you?

My plan at this time is to use an available PC-timing program that has already a nice UI (user interface) called PClapcounter. That is also why I tried to get hold on the AMB20 protocol as discussed earlier. This puts some demand on the decoder, it should at least send "@<car_ID>". I don't think the timestamp is needed because the PCsoftware has this tickbox "retrieve time from decoder". I did not test this yet, but if unmarked, I think the PC software already uses it's internal clock to do the calculations for laptime. The decoder only needs to report the <car_ID> were it thinks it was in the middle of the loop. That is still to solve.

Afterburner: The 470 Ohm resistor is to make the loop wideband. The environment were the loop is placed (tarmac, sand) is in this way of much less influence on the receiver. The loop is connected to the coax by means of a toroid to matches the impedance of the loop to 50 Ohm.

Gerrie

I want to stay at 5 MHz. One goal of this design is to make it work with the thousands of AMB and MRT transponders already in use, so that racers are not forced to buy something they don't want or need just to satisfy the whims of a particular company.

That sounds like a very good plan for someone who is familiar with DSP. I am not. In any case, the phase detector is already working nicely, can be easily constructed by the average hobbyist using widely available 74HC logic circuits, and requires no microprocessor or code. It's not high tech, but it will do.

I'd like to relieve the decoder of the burden of determining when each transponder is in the middle of the loop. If the decoder just sends each hit with a timestamp to the PC, then the PC can do that. (The timestamp will simply be an up-counter inside the decoder, started on power-up.) For the moment I'll just have the PC add the timestamps of the first and the last hit for each transponder and divide the result by two. That will be close enough for testing, and probably close enough for the final design.

Understood. I'm using a parallel resistor at the amplifier input to reduce the loop Q, and have eliminated the transformer. Impedance matching and common-mode rejection that would have been provided by the transformer are done by the amplifier.

Once the RF stuff is done you can also consider to add a small micro and a display to build a personal laptimer.
You put your transponder in the loop, you press one button and the micro acquire the right sequence of your transponder, then it will only count your laps and display them on the LCD after your stop driving.

The final device may be something like this one ...
http://i50.tinypic.com/73e05z.jpg

The first proof-of-concept unit will probably be like this. It will recognize one transponder, reject all others, and interface to an old stopwatch I have laying around. (The stopwatch has the switch contacts brought out on a 1/8" phone jack. I used it with a pushbutton switch mounted on the steering wheel of my shifter kart to make a "poor man's" personal lap timer.)

Sorry for interrupting the the technical issue talk but I've been following this thread from the start and Im wondering where this is going?

I get it that you want to develop a alternative to the current AMB Decoder because its highly overpriced - right?
And and of course your new designed decoder has to work with current AMB transponders - right? (Also with the new RC4?)

So if you succeed your design and are really able to build a decoder thats working - whats the next step?
Will you provide the schematics and everything to public so that everyone could build their own decoder or are you planning to sell them yourself without sharing the "knowledge" on how to build an run one?

I'm asking because I am highly interested in an alternative to the AMB system and providing a cheaper system for clubs that don't have the money to purchase a 3000 $ timing system. (Because my club is not able to...)
Also the current AMB system is very limited with its capabilities. We live in 2013 an almost everybody owns a smartphone which provides so much possibilities for racers.

If your decoder design would be open source this could mean a big step into the future of timing system - hopefully. So, what are your plans?

The biggest reason for my attempting this project (and my transponder project) is simply for the challenge and entertainment. All of the other reasons you mentioned are icing on the cake.

This decoder will NOT be compatible with the AMB RC4 transponders. That is an unnecessary complication.

My plan right now is to make the decoder available at a reasonable price, but I have not decided the best way to do that.

Making the project open-source is a good possibility. Toward that end, one of my design restrictions is that only cheap, widely available components are used, so that the design could be easily constructed by a knowledgeable electronics hobbyist. (Bipolar transistors and 74HC logic are the electronic equivalent of duct tape and baling wire.)

I've been considering various ways of at least recouping my development costs in the open-source scenario. Offering the loop amplifier and phase detector as components that could then be mated to a single-board computer like the Arduino Uno might be one way to do that. It would be convenient for the end-user to purchase unpopulated PC boards, or assembled and tested boards, rather than build from scratch. I’ve done that with some of my other designs. (An advantage of this approach is that these boards would not need to be tested to FCC emissions regulations, as they would only be a small portion of the entire system.)

One huge advantage to the open-source route would be to leverage the talents of other individuals to make contributions in their areas of expertise. The smart phone app you mentioned is but one example.

It’s time for another update on the decoder!

I have designed and tested what I am calling the “phase detector amplifier” (for want of a better term) that translates the low signal levels coming down the coaxial cable from the loop amplifier to digital levels for presentation to the phase detector. The design is very similar to the loop amplifier, but without the line driver, and with some hysteresis added using a couple of logic inverters.

If it proves necessary to add AGC to the system, it would probably make more sense to add it here in the phase detector amplifier (rather than the loop amplifier) since it has few constraints on the allowable current drain.

In an effort to reduce the workload of the microprocessor, I added some circuitry after the SPI converter that “strips” off the first two bytes of the transponder transmission (since they are the same on all transponders), and suppresses the remainder of the transponder transmission if the first two bytes are incorrect or garbled. Less garbage into the microprocessor is always appreciated by the software guys (who are presently me, myself, and I).

I have ordered a couple of flavors of microprocessors, and we’ll see which is best for the task at hand. One is a mid-level PIC, with which I’m familiar, and the other is an Atmel, residing on an Arduino Uno single-board computer, which has the advantage that the hardware is already done for me at a very reasonable price. Both will require assembly-language routines to keep up with the transponders’ data rates, but I’m comfortable with that.

The idea for the first proof of concept has transmogrified somewhat: Instead of timing laps, the decoder will simply dump the transponder data packet to my PC, making “cloning” of existing transponder IDs much easier than my current method (of using my oscilloscope to capture the waveform, and determining the phase inversions visually). Once that is working, then I’ll add time stamps to each data packet.

For anyone who would like to participate in creating code for the project, here is what I envision the data packet to look like:

6 ASCII hex bytes, representing 24 bits of transponder ID, followed by
8 ASCII hex bytes, representing 32 bits of time stamp, in increments of 1 millisecond, followed by
ASCII carriage return and line feed

The lap counting PC will require a program to examine all of the incoming data, determine the loop crossing time for each transponder, and format the result to send to the lap counting program. Is anyone interested in doing this?

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.

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.

That's a great idea !!

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.

Here are the screen shots for Gerrie's previous post:

@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?

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.