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

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?