Lap Timing Decoder
 

Here's some news on the decoder that I mentioned in my Transponder Design thread.

When I use the term "decoder" in this thread, I mean the system which detects the transponders as they pass the start/finish line. It uses the receiving loop for its input, and sends messages to the lap counting computer. We can break the decoder down into subsystems, including some sort of amplifier, probably with Automatic Gain Control (AGC), to increase the signals induced in the receiving loop by the transponders to usable levels; a detector (or demodulator, the fancy term) to extract the data from the signals; and some sort of microprocessor to translate the data into messages for the lap counting computer.

My first try at a phase detector/demodulator for the decoder is running. It turns out that the phase-locked-loop (PLL) that I mentioned in my Transponder Design thread was unnecessary. Only some simple logic gates are required. This is nice, as PLL circuitry is analog, and logic gates are digital. Digital stuff tends to be easier to reproduce and operates with fewer worries than analog stuff (and this comes from an analog guy-- me!).

The transponders send their data via phase modulation of the 5 MHz carrier, at a data rate of one bit per four carrier cycles. Detecting phase inversions in the carrier is simply a matter of sampling the instantaneous level (using digital levels, either high or low), storing it for one (or up to four, in this case) full cycles, and then comparing a new sample level with the stored level. If the new level is opposite the stored level, then a phase inversion has occurred, and this should result in an output pulse from the detector. This is easily accomplished using a 5 MHz clock, some D flip flops, and an exclusive-or gate.

One complication arises from the fact that the transponder carrier and the clock used in the detector are not at the exact same frequency, and even if they were, their phase relationship is unknown. We'll call the difference in frequencies the "beat frequency". This can lead to the generation of spurious output pulses from the detector during those times when the detector samples the carrier waveform when the waveform level is ambiguous, i.e, near its zero-crossings. One way to eliminate these spurious pulses is by using two detectors running in parallel, with their sample clocks offset by 90 degrees (quadrature operation), and then doing a logical AND of their outputs. When one detector samples the carrier waveform near its zero-crossing and generates a spurious output pulse, the other detector is sampling a different point of the carrier waveform that is far from zero, and does not generate a spurious pulse. When a phase inversion occurs in the carrier, then both detectors generate pulses, and this condition is the one that is valid.

Here's a scope shot of the outputs of the two detectors, using an unmodulated carrier input. As described above, each generates spurious pulses, but the pulses never coincide. (In fact, the pulses tend to occur twice as often as the beat frequency since there are two zero crossings-- positive-going and negative-going-- and about 90 degrees apart, due to the quadrature arrangement of the sample clocks.)

http://i1191.photobucket.com/albums/...r/DSC02536.jpg

This scope shot shows the final result. The upper trace is the modulated carrier, and the lower trace shows the logical AND of the two detector outputs. (The carrier is actually the digital drive waveform for the transponder tank-- it's best to start simple!) You can see there is one pulse per carrier phase inversion, with the pulse delayed by the latency inherent in the detector design. The bottom trace is "fuzzy" because the carrier and detector sample clocks are different, and the scope is triggered by the carrier. This makes the bottom trace jitter back and forth a little.

http://i1191.photobucket.com/albums/...r/DSC02549.jpg

Here's a single sweep of the same thing, which eliminates the "shake" and makes things more obvious:

http://i1191.photobucket.com/albums/...r/DSC02551.jpg

Here is the detector output for a larger number of bits:

http://i1191.photobucket.com/albums/...r/DSC02552.jpg

And finally, the ugly solderless breadboard:

http://i1191.photobucket.com/albums/...r/DSC02555.jpg

Is there doco anywhere on how to read data from the decoder? Even the AMB one? I've been considering writing a mac version of some race software for some time now.

I haven't seen any documentation for the AMB (which is likely the brand that you want to use), and don't know the details. It might be that this information is provided to those who want to write PC lap counting software only after they sign a Non-Disclosure Agreement (NDA). But it should be possible to determine the data provided by the decoder with some testing. Unfortunately, I don't have a decoder to test.

If I get far enough along, one possible route for this project would be to contact one of the existing software sources and ask them if they can provide information on any of the decoders that their software supports. I'd guess that the information isn't "protected" for all brands of decoders, especially those that have been discontinued. Given that information, I would make this decoder design "look" like one of those decoders to the PC.

Please share any information you find. It might be quite useful!

In my first post I mentioned that ambiguity of the carrier level around its zero-crossings can cause the phase detector to generate spurious pulses, and that using parallel detectors with their outputs logically ANDed together eliminates the problem. However, when a valid carrier phase inversion occurs, the ambiguity can also cause one detector to generate an output pulse that is offset enough in time to not align with the pulse from the other detector, resulting in a missed bit when their outputs are combined with the AND gate. To correct this, I have incorporated a third parallel detector, with the three detector clocks offset about 60 degrees from each other, and employed a majority logic gate that gives an output pulse whenever two or more of the detectors generate coincident pulses. It's a few more parts, but still fits on the solderless breadboard, as you can see:

http://i1191.photobucket.com/albums/...r/DSC02562.jpg

This scope shot shows the carrier modulation waveform on the top trace, and the combined detector output on the bottom trace. (The modulated carrier is applied to the detector inputs.) The scope persistence is set to "infinite" (one of the nice features of a digital scope!), and this reveals an umeasurable bit error rate (the scope triggers incorrectly every once in a while, but the output remains consistent up until that occurs).

http://i1191.photobucket.com/albums/...r/DSC02571.jpg

You can find many useful info about MYLAPS (AMB) P3 protocol at this project:
https://github.com/skoky/ambmylapsti.../skoky/P3tools

Thanks, Vlad. Unfortunately I had problems accessing that web page. Do you have a text document for the protocol?

Unfortunately I haven't any document for MYLAPS P3 protocol. It's not my project. It's source codes that use MYLAPS P3 protocol.

Righ now I havn't any problems with accessing that web page (IE and Firefox).

Perfect! I'm better at Java than Obj-C anyway :batman:

It's time for an after-the-holidays update.

I'm currently working on an interface to convert the phase detector output to SPI for interface to a microprocessor. The microprocessor can then create whatever information (transponder ID, time stamp, etc.) is necessary to present to the lap counting PC.

It would be nicer to find a microprocessor that can read asynchronous serial input at 1.25 MHz, but I haven't found one so far. SPI ports are faster. Does anyone have any suggestions?

Mr. Williams, if you should happen to determine the information and format necessary for making a decoder "look" like an AMB to the lap counting PC, please let us know!

At first glance, It looks like crossing the loops just makes the decoder kick out a string with data at various offsets following a header and CRC check. This appears to be the code that reads it, after connecting to the decoder. I'll check it out more in the evening when I'm off work.

https://github.com/skoky/ambmylapsti...ta/Record.java

The first try at the SPI converter design is running. The converter stretches the pulse output from the phase detector and reconstructs the clock signal necessary for synchronous data transfer to an SPI port on the yet-to-be-chosen microprocessor. Here's a scope shot of the SPI output. The top trace is the data, the lower trace is the clock. Data is transferred on the negative-going edge of the clock:

http://i1191.photobucket.com/albums/...r/DSC02579.jpg

One interesting thing that I should point out is the slightly different clock pulse width at the beginning of the data stream. This is due to the SPI converter re-synchronizing with the transponder transmission.

Next I'll be fiddling with some ideas I have for the front end (loop) amplifier. That's supposed to be what I'm good at!

hi all!

Howard, i think that ATSAM3X8E is a very good uC. it's damn fast

SAM3X8E is now on Arduino DUE

I wish to get at Howard point, so i need some help to do the clock and the logic.

Howard do you have a draft schematic? or some help to start?

thank you

The Arduino boards seem very cost-effective, and the Due is quite fast. Unfortunately I would need to change the oscillator frequency to make the UART run at 1.25 MHz, and I'm concerned that this might affect operation of other parts of the Due. (EDIT: This conclusion is incorrect!)

The Arduino Uno is what I was aiming at. It's quite a bit cheaper than the Due, and the cost of the SPI converter to get the transponder data into the Uno's SPI port is not nearly as great as the difference in cost between the Uno and Due.

The choice may be decided by how much computational power is necessary to get the data crunched and sent to the lap counting PC. If I had designed the AMB system, I would have made the decoder as simple and dumb as possible; there's no point putting a bunch of "horsepower" in the decoder when there's a PC (with a clock speed perhaps hundreds of times faster) available for the heavy chores. But since I don't know the details of the AMB decoder, I can't say at the moment what will be necessary.

Right now everything is very much in the proof-of-concept stage. I would need to at least get an entire system to some semblance of operation before releasing any schematics.

Also, I don't really know where this is going at the present time. I have manufactured electronics devices before, and sold my designs to other entities for them to manufacture, so it would not be prudent at this stage to release what might be valuable information.

But I must admit that I am tempted to do this as an "open source" project, since I've never been involved with that before, and find the possibility intriguing.

I think code has incomplete protocol implementation. And it has some errors. So it need some further testing.

For example:
GENERAL_SETTINGS:
1) Command has requested options - 0x01, 0x03, 0x07
2) Parsing respond from the decoder (details) -
STATUS_INTERVAL = 0x01;
REAL_TIME_CLOCK = 0x03;
FIRST_CONTACT = 0x01; ???? maybe 0x07

Interesting project, will definitely watch with interest.

Just some comments from my experience with AVR.
Any AVR that supports a 20MHz clock (most modern ones) will support a 1.25MBaud uart. However at that rate you would have 160 clock cycles between uart transfers, so it may be very tight if you plan to program in c.
EDIT: that is to say the AVR will need to run at 20(or 10 with high speed UART enabled)MHz.

If you have SPI working, you could use an FTDI ft2232 to directly connect to a pc (and let FTDI deal with driver support, with drivers being supported on just about everything imaginable atm).

The ft2232/ ft232r /ft230x should also handle UART at 1.25MBaud (you will need to check, they go 300Baud to 3+MBaud).

Alternatively the "u" coded AVR have USB phy built in (eg atmega32U4) however you will need to write your own drivers (or use the open source drivers like LUFA or ATMEL's libs)

<my interest in FPGA>
Not knowing your background this may be a bad suggestion, and would be overkill in the extreme, but have you considered an FPGA? All logic could be implemented on the FPGA, serialisation ect. only thing not possible would be analogue stages (and even then you have DSP....). Downside would be the cost.
</my interest in FPGA>

Many thanks for your input. I misread the datasheet; yes, it looks like the UART will run at 1.25 MHz with the 20 MHz clock. It's nice having others check up on me to catch my mistakes!

I was thinking about using the UART to read the demodulated signal from the transponder, but then realized that the format isn't compatible-- the transponder doesn't send start and stop bits. This might not be a big deal; even a garbled result from the transponder would still be useful as long as the result is unique to that transponder. But at the moment I think I should keep all of the information intact, just in case.

Also, it is unclear to me whether or not the UART in the ATmega devices re-synchronizes to the incoming data on each bit or each start bit, or simply times everything from the first detected start bit. The transponders send a pulse train having 98 total bit "slots", and their bit rate isn't very accurate, so errors can occur if the UART doesn't re-synchronize at least a few times during reception of the transponder data. My SPI design re-synchronizes on each received phase inversion (which I have been calling a logic 1).

The FPGA would be the logical route to take for production runs. It would also be nice to have for prototyping, but I don't have the programming tools laying around here. I do have a bunch of 74HC logic laying around, so that's what I'm using. Do you have any suggestions for a very inexpensive FPGA family and the associated tools?

There is another benefit using standard 74HC logic: If we make this design open-source, then the decoder could be constructed by others with minimal effort and expense.

Do you have a diagram of the packet makeup? or picture? Attempting to get an idea of what the protocol is. 98bits is alot of data to send a ID that would be less that 40bits and a checksum (8/16 bits?). guessing the remaining data if for the new telemetry

AFAIK, all basic UART implementations only look for start bit (done by sampling at 8 or 16x baud rate, hence the need for a system clock 8 or 16x faster than baud). although wiki leads me to believe that there are implementations that resync on bit inversions, however i can see the downside to this if the line is subject to impulse noise.
Either way you are right, uart would not work because of the start/stop bits not being considered data.

Sounds like your method is the best. Makes me wonder if you could do the same with a spi receiver and a timer/counter on a micro controller, where you generate the "spi" clock in the timer (pwm mode). when you detect a phase inversion you do a calculation to see if you and too fast/slow and update the counter threshold value (or reset the counter, or something else). basically brute forcing spi to act as a asynchronous receiver. Although at 1.25MHz, don't know of any device capable.

Funny enough an FPGA would be perfect to implement a custom receiver. It is just unfortunate that the words "reasonably priced" and FPGA are seldom used in the same sentence. While the price is falling quite quickly, i think you will still be in the $100 mark (although some boards based on older devices ~$50).
Also worth keeping in mind that there is a significant learning curve as the design process is quite different to software.
This website has a good list HERE, generally you want a spartan 3e or 6 to learn (only considering xilinx as that is what i use, there are other brands with their own merits). the avnet LX9 MicroBoard is a good example as the board has usb programming and comes with "upgraded" versions of the free tools.

i'm trying to understand how demodulator works.
demodulator is a BPSK or a QPSK?

I really have no idea of the information in the data stream. Here are a few things I have observed, based on a sample size of 26 different transponder numbers (from 4 AMBs, 2 custom MRT numbers, and the 20 alternate MRT numbers). I am calling a carrier phase inversion a logic 1:

The number of ones transmitted is always even.

Maximum run of zeroes = 13
Maximum run of ones = 10

The first 16 bit slots always contain the same pattern: 1111100100010110. I'll call this the "preamble". It might be a type identifier, or number of bytes in the packet, or ???

The following bit slots are always either 11 or 00:
17 and 18
83 and 84
85 and 86
87 and 88
89 and 90
91 and 92
93 and 94
95 and 96

I don't see any patterns in the rest of the data stream. I would expect that some of the commonalities will disappear if the sample size is increased.

Of course, for my current purposes it's not necessary to understand the information in the data stream. As long as the stream is unique for any given transponder, it's useful. In fact, I intend on doing as little manipulation of the data as possible in the decoder; I'll simply send what is received to the PC, and it can do what it likes with the data. It might be a good idea for the PC to strip off at least the first 16 bits before reporting the rest as the transponder ID, which still leaves about 1.2 million million million million possible numbers-- most of which would not be recognized by an AMB decoder if it uses a checksum.

Now THAT is a cool idea! I love using things in ways that their creators didn't foresee!

The data is transmitted via BPSK on a 5 MHz carrier, with a bit rate of 1.25 MHz (one possible phase inversion every four carrier cycles).

Decent data set. when you say maximum number of ones/zeros, do you mean sequentially? That first 16 bits definitely sounds like a header. played with it but never got out any anything that looked like a payload length (inverted, word/byte/nibbles), maybe the last nibble if inverted (=9), but you need to do some creative math to make it fit (header(16bits) + footer(8bits) + nibble(9)*8bits).

Out of interest, have you tried any hybrid rc4/ rc4 transponders? just guessing, but if the hybrid transponders can communicate with the older equipment, they should be using the same protocol. BUT they will be unique because they should have a packet that changes (dependent on supplied voltage and temperature is it?) allowing the design of the packet to be picked apart a little. does not explain why the rc4 transponders are not backwards compatible however, as the hybrid transponders have the same telemetry, but work on the older system.

Of course not useful for the hardware design, but an interesting problem. Even just cloning existing transponders would be infinitely preferable to having knowledge of the protocol and nothing to use it with.

Yes, maximum sequential run of ones or zeros. The maximum run of zeros was a concern because the SPI converter uses ones to re-synchronize to the transponder data stream, and too many zeros in a row combined with too large a variation of the bit rate from nominal (1.25 MHz) can lead to bit slip. I'm considering using the carrier edges for synchronization, which would eliminate this problem, but haven't come up with anything so far.

I was under the impression that the new RC4 system uses a higher carrier frequency, and the hybrid transponders transmit on both the old frequency and the new. If this is the case, the old and new data formats might be entirely different, thereby not offering any clues toward understanding either.

If someone has a hybrid transponder they could loan to me, I'd be interested in "sniffing" the output with my scope. But I don't think I would spend my own money just to do that.

This brings up an interesting point, though it is tangential to the above information. My experiments so far have treated the transponder as a "black box". All of the information I have gleaned so far was gained using a single loop of wire to receive the signal from the transponder, and examining it with a relatively inexpensive digital sampling oscilloscope. There was no need to open up the transponders to look inside. Indeed, that would have ruined their resale value, which is entirely at odds with one of my original reasons for starting this project: save money! I hope to pay for the parts and PC boards I have purchased by selling the original transponders when I'm done testing them.

I talked with the guy that wrote that Android program linked to earlier in the thread. He's under NDA and can't really share the protocol info or doco. All we could really do is work backwards from his code, since it's open source.

That's not surprising. If I were AMB I would also require an NDA. As we mentioned previously, there are other routes available, such as making the decoder appear as something other than an AMB (but still supported by typical lap counting software).

Thanks for checking!

I know that the carrier wave is used in smarter GPS receivers to improve accuracy and update rate. I know someone who is currently working on GPS processing (RTK GPS) so i can ask if there are any tricks.

Huh, had no idea that was the case. I guess that is one way to prevent people hacking the old decoders to work with the new transponders.

Just thinking out loud:
Am i right in my assumption that the amb transponders are nothing more than active RFID? in that case, would it make any sense to look at making the decoder system compatible with the 13.56MHz(ISM) (or the one around 3MHz) RFID tags? I guess you would have to duplicate the analogue stage due to difference in frequency. Advantage is you could use sub $1 tags...

The AMB and MRT transponders are actually simpler than an active RFID, because they don't receive any kind of signal from the timing loop; they just transmit repetitively, as long as power is applied. The AMB timing loop doesn't radiate; it only receives the signals from the transponders.

One of the design requirements I have for this project is that it must be usable with the existing AMB and MRT transponders. I think this requirement best serves the average RC racer, as no new equipment would need to be purchased.

Others have attempted to use low-cost, passive RFID tags for lap counting, but in general the reader is too expensive, and the system response too slow.

Oh I agree totally.

Active RFID can be single direction (Passive Reader Active Tag "PRAT"), but I have nothing to do with RFID so have no idea about the specifics.

Well other then I use a passive card several time a day and always hate how slow they are. Some times you would think someone was sitting at a computer with yes/no box and a list of allowed people.

I didn't know that. Thanks for the correction!

Now THAT'S funny!

Our local library uses the passive tags in the books and other items that can be borrowed. Sometimes it will take 10 seconds to read an item. (I know that's not typical, but it seems like I'm always the one subjected to the atypical situations.)

Its system based on RFID 125khz. Transmiter working at 125khz amplitude modulation. Transmit protocol based on Manchester code. ATTINY25 based.

Receiver is ATMEGA16 with schematics looks loke h_ttp://serg22.sibgtu.ru/radio/rfid-proteus02.jpg without 125khz transmitter, receiver only.

Receiver h_ttp://cs323523.userapi.com/v323523346/44f8/4YQLyLlZrg0.jpg
h_ttp://cs323523.userapi.com/v323523346/44ee/jVc5rwMd1_8.jpg

At this moment I am testing this system and waiting LCD for this project.
Sorry for my English.

That looks awesome! I think you should start a thread to document your work. I would definitely read it!

Here's how to post your photos, after you have uploaded them to Photobucket (it's free!) :
http://www.rctech.net/forum/10334159-post102.html

Hello Howard,
I was started myself to design a Lap_times system and while searching background info, I stumbled accross your nice work! At the moment I trigger my transponders by crossing a magnetic 'line' that is picked u by a sensitive HALL device. This starts a burst of RF at 2.4GHz and continues until a ACK is receiced. The magnetic line is used because this in my opinion gives a more defined moment of triggering.
My question to you: In case the RX-loop in the AMB-like systems is 40cm or so in width, and more than 1 car is at the same time in the loop, how does the system determines which car is really 'first'? I mean the decoder will be open to any BPSK coded signal in reach. As soon as the decoder reads a correct CRC (not neccesarily the car that is in the lead) it will send the ID of that car to the PC isn't it? But because all cars inside the loop TX at 5MHz in bursts how can the AMB system (or alike systems) claim 1/1000 second accuray? Any idea?.

it picks up the strongest signal 1st the 2nd as 2.. If ur trans was on ur front bumper and a guy has his on his back bumper and the both entered loop at same time and the guy with it on rear has a stronger signal Thats the 1st place car..so this .0001 accuracy is a lie.that's why lap counting software has signal strength reading..and thats why I use a 9v battery to power my personal...do u think this guys trans will work.. I'm beating $1000 it will not EVER..
Lets see a video of his trans and a setup calling out his name..oh leave the lid off...

The decoder monitors each transponder's multiple transmissions ("hits") as it passes over the loop, and tags each hit with an amplitude and time. Then it compares all of the amplitudes for that transponder's hits, and interpolates where the maximum would have occurred in time if the transmissions were continuous. (Imagine creating a graph of the signal level of each transponder as it goes over the loop, drawing a smooth curve through the data points to find the peak.) This is the time it reports to the lap counting PC. The overall amplitude of the signal is unimportant, as long as it is strong enough to give multiple hits.

It is this interpolation that permits an accuracy that exceeds the repetition time of the transponder transmissions. That's pretty slick!

The signal strength is unimportant as long as multiple hits are recorded. Even if it were, the transponders are regulated internally, so the strength is the same with 6V supply as with 9V supply.

Hello Howard,
Thank you for your kind reply. That makes sense to me! The issue kept me awake the last couple of days, never realised it was solved this way. That also answers the question whether it is important were at the car the transponder is located. I think I undersood: In the first lap, the car crossed the loop. The timing software registrates the Peak_signal_time and the first lap starts for that car. Not important were the transponder is located, it is at the same location the next lap. The car will cross the loop a second time and again the Peak_signal_time is registred for that car. The time_difference in Peak_signal_time is the lap_time.
For spectators at the side it is thus difficult to judge if two cars in the end of the race have done the same amount of laps and cross the loop visually at exact the same time (by eye...); It depends were the car's transponder was (more to the front or rear), but the electronic timing will show the difference in time of both cars. The car that had the transponder a bit more to the front started the lap earlier as well, it is the lap_time that counts. I think I all understand now.

@hpikllr: I think after reading the explanation by Howard, we better not bet the $1000...

Thanks Howard!

Your comments are perfectly timed (HA!)-- I had my closest finish ever in a race on last Sunday: 0.005 seconds! The win was decided by the transponder location! (I mentioned it in my thread on Breakout racing.)

This weekend been looking for BPSK decoders in the www, but as said earler by others, there is little available that can be used without any changes. I mostly stumble into PSK decoders used by HAM radio-amateurs (as also I am one). Because of bad weather, I quickly did a try to generate a BPSK signal by using whatever IC I had on hand, but that turned out not to work for an HEF4030. This IC cannot do 5MHz carrier, so I try again with a fast TTL device another day.

Somewere else I found for the older data_stream from the AMB decoder to PC this info that might be usefull for integrating your decoder to existing PC software:

the transmissiom= 9600 8N1
the string = AMB20 Output @010204382050
This string is containg this information: Car1;hours2;min4;Sec38;20Mil Sec;50Hits inside the loop

The date and time is obviously the RTC inside the decoder that is transmitted towards the PC as timestamp.

I don't know if this of any help,I thought it does not matter to share it here.

Gerrie

Hi Gyus,

I need to correct my last post a small bit.
It took me a few days, but now I completely figured it out.

Transmission is 9600 baud, 8 databits, 2 stopbits, no parity.

The AMB20 system decoder (20 cars maximum in one race) gives the below info string for a passing:@010204382050cr/lf
The string content was fine in my last post, see that for details (above here).
Until today, I though the string was preceeded by "AMB20 Output ", but that turns out not to be the case! It is only the part followed the "@".

Besides this passing string, the AMB20 decoder sends every 1 or 2 secons a timestamp.
This timestamp is like this:
@00HHMMSScr/lf
To explain; 00 is a double zero, HH=RTC decoder hours, MM is minutes and SS is Seconds.

I tested today by sending only passing strings to my preferred time_lap firmware (PCLapcounter), and after a 10 minutes simulation in which I fed 4 car_ID's at random time intervals (between 30 and 50 seconds) to the configured COM_port, it was still fine.

This information is made available with the great help of Carl Arrowsmith from rctiming.com. To be able to emulate other than AMB20 systems is more complicated, that information is currently not open to public.

Thanks for the information!

Now that the transponder design is at a usable point, it’s time for an update on the decoder:

I designed an amplifier/line driver for the receiving loop, and it’s working quite nicely. I had originally considered just using a TV-style 300-to-75-ohm transformer to interface the loop to a length of RG6 cable, but the ones I found had a low frequency cutoff of 5 MHz, which is a bit too close to the transponder carrier frequency, and of course the voltage from the loop is reduced by the transformer, which didn’t appeal to me.

The obvious solution was to make an active amplifier. The requirements were:
balanced (differential) input, to reject any common-mode noise on the loop;
present a controlled impedance to the loop, thereby setting a reasonable Q and bandwidth;
present a 75 ohm output impedance to match the coaxial cable connecting the amplifier with the rest of the system;
derive power from the coaxial cable, so no separate power supply is needed;
and add some gain.

The design uses discrete bipolar transistors, 2N3904 and 2N3906, as they are cheap, easily available, and rugged enough to withstand the numerous ESD (ElectroStatic Discharge) events that will probably occur. These have a transition frequency of about 250 to 300 MHz, which is plenty, but not so high that any special care must be taken in the circuit layout. The gain is about 16 dB, and the bandwidth is sufficient to reproduce the signal from the loop with minimal distortion (I sold my RF generator a while back, so I can’t make any direct measurement of the bandwidth). Current drain is about 10.5 mA, drawn from the center conductor of the coax, which is terminated at the far end with 75 ohms to +5V, giving a supply voltage at the amplifier of about 4.17V.

Right now there is no automatic gain control, but it could easily be added if necessary. Initial experiments indicate that it might not be needed, since overloading the amplifier still seemed to preserve the zero-crossings of the signal.

The output level is a few tenths of a volt, which will require translation to digital levels before it is fed to the phase detector. A bit of hysteresis will help eliminate random noise.

I’ll post some pictures and scope shots when I get a chance.

I've tried these TV transfomers with AMB systems... They don't work at all... had better results just tying the loop to the COAX.... which gave piss poor results.... Many missed laps or a lenghty delay.