Thanks for the encouragement, guys! Anything I use could well outlast me!

Your progress is exciting!

Simulation is an excellent tool. The real challenge comes with actual, asynchronous inputs. That will present the circuitry with inputs that sometimes can't be simulated, or simply haven't been tried during simulation.

in reality i am doing non coherent decoding so i am not reconstructing clock. I am just detecting pulses and as they are in correct length with some tolerance (can be tuned for performance let say in 5ns steps) i am assigning value. I implemented several timeouts and also several checks e.g.there must be at least 2 short pulses between 2 long pulses etc. And also what is important sending to host is done in separate process so there can be 2 packets one just after another, no need to pause between them. I already can receive signal from generator at cmos level, unfortunately i am still waiting for pcb for frontend. As this will be working in real life, i will start to do sw for host (for measuring and user interface)

The first proof-of-concept is finally working! The system is now reading the transponder data, stripping off the first two bytes, and transmitting the remaining 10.25 bytes as ASCII hexadecimal numbers, via the UART at 115200 baud, to an old desktop computer. (Both the PIC and ATmega processors are capable of much higher baud rates, but the desktop computer is limited to 115200. I don’t know if this is a limitation of the computer or the Hyperterminal program, nor do I care.)

I’ll use this as a simpler method of “grabbing” data trains from transponders. It sure beats looking at all those pulses on an oscilloscope!

I had problems with getting the PIC processor to read the SPI interface, so I added an octal D flip-flop as an external SPI to allow the PIC to grab the data in parallel bytes. I later found the likely problem with the SPI, as I was coding for the parallel input (20 decimal is different than 20 hexadecimal… D’OH!), so I’ll probably go back and try the SPI again. For the moment, the parallel interface will suffice.

The software FIFO (circular buffer) is also working. It is used as an interface between the two main tasks the processor is doing: reading the transponder data stream in real time, and sending the processed data via the UART at a relatively leisurely rate. (This is essentially what OM2KW mentioned in his last post.)

The next task is to add add a timestamp to the data.

The next milestone will probably be to add code to recognize and store one transponder ID to EEPROM, calculate lap times for just that transponder (ignoring all others), and send the result to an external computer. That will be the “personal lap timing system” that we’ve mentioned before in this thread.

Of course, it will be extremely important to test the system with transponders in moving cars! That’s when the real troubleshooting begins. I can do that either with the system as it presently exists, or with the “personal lap timing system”.

I’ll also start transferring the schematics to TinyCAD and posting them in sections as they are completed.

Hi Howard, it is great progress, just few remarks. AVR is much faster at same clock than pic (i mean normal pic, not those dsp32 etc). SPI at avr can run max at fcpu/4 (slave mode). I do not know what is bps from your hw, but if it is 5mhz you are on the edge with avr spi rx. Other think is that in this case (5mbps and fcpu 20mhz) you have max 32cpu cycles to store data from hw to mcu. This is also very on the edge (int jump, inc counter, store data, int return + normal program run).

Regards,

Brano

Hi Brano,

The hardware SPI runs at the bit rate of the transponder, 1.25 MHz. It's just within the specifications for the PIC at a 20 MHz clock, and easy for for the AVR (ATmega328). With the PIC, there's just enough time to grab the data, convert to ASCII, and shove it in the FIFO as it is received (using less than 32 machine cycles, as you said). Again, the AVR will have no problems due to its 4x faster machine cycle at the same clock rate.

I only started with the PIC because I'm familiar with it. Once the software is working, then if I want I can translate it for the AVR, using that as an opportunity to learn the nuances of the AVR.

Thanks, Howard. You loop amplifier works fine:
h_ttp://cs407731.userapi.com/v407731346/6bdf/LPhbObG0NN0.jpg
h_ttp://cs407731.userapi.com/v407731346/6be8/uTJXKwOIjWs.jpg

How about this phase detector on 74hc4046?

P.S. Forum says me: You are only allowed to post URLs to other sites after you have made a certain number of posts. You have not reached that limit yet.

I'm happy to hear the amplifier is working for you! I'll keep the schematics updated on their original posts. So far I've changed a resistor to reduce the gain.

I tried the 74HC4046 for phase detection, but never got it working very well. My latest, all digital phase detector is working okay, but still is prone to errors, apparently caused by bit rates that are significantly different (1/2%) from 1.25M. I need to check this out.

Here are the pics for your last post:

my transponders working at 500khz carier
74hc4046 working on Proteus 7.1
h_ttp://cs407731.userapi.com/v407731346/6bfa/SshaZczfCDg.jpg
h_ttp://cs407731.userapi.com/v407731346/6c02/BuMb8oGuRj4.jpg
attiny25 is transponder working at 20Mhz.

this calculator can help you with 74hc4046
h t tp://w ww.ch angp uak.ch/elec tronics/ca lc_03.p hp (with out spaces)
Tommorow I wll try R1=110k, R2=3k, C1= 750p

I mentioned previously that my all-digital phase detector was still experiencing some problems, so I have been using an analog phase detector until I get the digital detector sorted out. It is a standard design using an XOR gate as a phase comparator, and a tank circuit as a “flywheel” to add time delay to any phase changes of the input waveform. (Thanks to Payalneg for reminding me of this circuit!)

The circuit is simple enough and performs well, but has the normal problems one expects from an analog circuit in that it must be tuned and tweaked for proper operation. (That’s something I prefer to eliminate in most of my designs.) In this case, several parts must be selected to compensate for various component variations.

C20 must be selected depending on the particular part chosen for L20, as different inductors will have different inherent inter-winding capacitance (as reflected in the self-resonant frequency). The tank is tuned nominally to 5 MHz, so that it rings in phase with the transponder carrier. I have made no provisions for tuning drift with temperature, although the tank runs at a fairly low Q, which reduces problems due to the drift.

U20A, the phase comparator, has no specification for matching of the input thresholds, although in practice they are quite close since the transistors are located near each other on the same substrate.

The tank tuning and phase comparator inaccuracies, in addition to the fact that the input to the circuit may not have a 50% duty cycle, results in “runt” pulses at the output of U20A. U20B and its associated components eliminate these pulses, and only significant changes in the carrier phase will generate pulses at the output of U20B. The value of C22 might need to be changed depending on the length of the runt pulses.

U21B, U20C, and associated components form a pulse-stretcher so that several narrow, adjacent pulses from the output of U20B result in a single pulse output from U21B. Again, C23 must be selected, to give pulses of about 150 to 250 ns duration, as the input threshold variations inherent in U21B and U20C are quite large (and not very stable over temperature).

The reference designators are in the range of 20 to 39 so that the schematic may be included in the complete decoder design with no conflicts with the other schematic blocks. The range should be sufficient to substitute the digital detector schematic for the analog.

I have now added timestamps to the received transponder data. Each increment is worth 0.25 milliseconds, which is more than a factor of 10 smaller than the average transponder repetition time, so the timing errors from quantization are minimal.

The first six ASCII hexadecimal characters are the first three bytes of the transponder data string (minus the two-byte preamble), and the next eight ASCII hexadecimal characters are the time stamp, presented with the low nibble first.

Here is a shot of the data received on Hyperterminal. I timed the capture to show the highest byte rolling over from 0 to 1 (to show that all bytes of the counter, both hardware and software, are active):

Its great idea to use d-trigger. Thanks for schematics, i will try to connect this to my decoder:
h_ttp://cs417623.userapi.com/v417623346/43ba/Btc3g8ckWJY.jpg

I have re-christened the SPI Converter as the Synchronous Serial Converter (SSC). I think it’s a more descriptive name, and avoids the problem that there are so many different standards for SPI, there’s really none at all! Here she is:



The SSC creates two signals, Synchronous Serial DATA (SSDATA) and Synchronous Serial CLocK (SSCLK), that are used to shift the transponder data (from the Phase Detector) into the Preamble Detector and microprocessor.

U40A, U40B, and U41A synchronize the output pulses from the phase detector to the 10 MHz system clock, and generate a negative-going output pulse from U41A of 100 ns duration on any input pulse from the phase detector. The pulse from U41A sets flip-flop U42B, and SSDATA goes high. The pulse also resets counter U43 via inverter U41B.

U43 counts upward by one on each negative-going edge of the 10 MHz clock. As it counts, the outputs of U44 successively go low, each corresponding to the count state of U43.

In state 2, U42A is set, generating the positive-going, active edge of SSCLK. This is used by the Preamble Detector and microprocessor to clock in the data bit from SSDATA. (The opposite polarity of SSCLK is also available from U42A).

In state 4, U42B is reset, preparing the SSDATA output for the next possible data pulse from the phase detector.

In state 5, U42A is reset and SSCLK goes low, preparing it for the next data bit transfer.

If no data pulses are received from the phase detector (meaning no transponder carrier phase inversions have occurred), then U43 and U44 cycle continuously through all eight possible states, generating SSCLK at the nominal transponder bit rate of 1.25 MHz (10 MHZ / 8), transferring zeroes on SSDATA.

The 1.25 MHz transponder bit rate and the 1.25 MHz SSCLK are not phase-locked, so if no data pulses are received from the phase detector, SSCLK will drift away from the bit clock implied in the transponder data train. However, the phase relationship is re-established whenever a phase inversion occurs in the transponder carrier, since this resets counter U43.

EDIT: For the latest schematics, see post 206:

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

Here is the schematic for the Preamble Detector / Stripper (PDS):



The PDS monitors the incoming data from the transponder, looking for a pattern match for the first two bytes. (The first two bytes of transponder data are always the same, regardless of the transponder ID number. We will call these bytes the “preamble”). The leading bit is treated as a start bit to synchronize the SSC to the transponder, and is ignored for the pattern match.

U50 and U51 form a 16 bit shift register. SSDATA, the data from the SSC, is shifted in on the positive-going edge of SSCLK.

The output of NAND gate U52 goes low only when all of the data bits at its inputs are high. The output of NOR gate U53B goes high only when the output of U52 is low, and all of the data bits at its other inputs are low. Similarly, the output of U53A goes high only when all of the data bits at its inputs are low.

NAND gate U54C then combines these signals to create /VALID, which goes low when all of 15 the data bits match the values in the preamble. (D0, the 16th bit, is not used.) Inverter U54B provides the logic-high version, VALID.

/VALID (or signals derived from it) inform the microprocessor that it must read the remaining transponder data. The microprocessor does not read the preamble, and any garbled preamble is ignored, reducing the microprocessor workload.

U50 and U51 could be any of several different parts. The schematic shows 74HC574 octal D flip-flops, but 74HC374 octal D flip-flops or 74HC4015 dual 4-bit shift registers will work equally well. (I used 74HC4015 on the prototype.)

EDIT: For the latest schematics, see post 206:

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

hm, its working )
h_ttp://cs407731.vk.me/v407731346/6e5a/2Dr8s_OBlPc.jpg
h_ttp://cs407731.vk.me/v407731346/6e48/mjuyw0fT4a0.jpg
h_ttp://cs407731.vk.me/v407731346/6e36/eD9fLr4n-Ck.jpg
h_ttp://cs407731.vk.me/v407731346/6e51/OHR2QcaAolU.jpg
but I changed some schematics for better detecting of preambula:
h_ttp://cs407731.vk.me/v407731346/6e6c/p4QXO_U31kc.jpg
and getting data signal from D0 of U51