+1

Great news!

Howard up to his normall level of Fun!!! :lol:

The software for separating transponder ID messages from status messages, and sending only the ID messages to the PC, is operational. Despite being quite complex, the software functioned on the first try. (This only partially compensates for me spending days to fix ridiculously trivial items on other parts of the software!)

The first photo shows 10 transponders (5 Cano, 4 AMB, and 1 MRT) gathered around a small testing loop. This is a worst-case scenario, and in fact I wasn’t counting on the software being able to determine which messages are for ID and save them to the list in RAM in this situation (since a message must be received twice in a row to be saved as an ID message). While it does take a few seconds for all the IDs to be determined and saved, it eventually happens. This is a pleasant surprise, but has no bearing on operation on the track, where each ID would be determined as each car passes individually through the loop during the race warmup.

At the moment the newest 11 verified ID messages are saved in RAM, so the decoder has a limit of 10 cars on the track at the same time if we reserve one ID for a safety margin. This number is a bit arbitrary; there is more RAM available, but each verified ID adds to the microprocessor workload.

The second photo shows the decoder output sent to the PC. All 10 transponder IDs are present (represented by the first 6 characters on each line), with no bogus messages, and none of the 70 different status messages (7 for each transponder).

Eliminating the status messages actually mitigates one of the bottlenecks in the system by reducing the data sent to the PC (by 25%, since each transponder sends a status message every fourth transmission). The tradeoff is that the microprocessor workload is increased.

The next step will be for the decoder to determine the crossing time for each transponder, and only send that information to the PC. This will virtually eliminate the bottleneck of sending data to the PC, since the data would need to be sent only once per car per lap. It remains to be seen if the little PIC can be coaxed into doing this much work!

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

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

Option for Decoder
 

Howard,

I know you will laugh when reading this, but you know how I like to over analize things like data ...... hummmmmmm just like you ......


Is there a way to have more than one loop to transmit the data? Think F-1 and have times in each segment and then a total.

Lastly, option to just track ONE transponder. Think of this as your own track timing, but what a wonderful tool. You could time the sweeper and straight, plus one or two spots in the infield. Make some changes, like a gear change for the nitro car and see what it does in each section, what your giving up to get something else.

Just a thought

Mark

Yes, although each loop would require its own decoder. But the cost of this decoder will be low enough to permit that.

The scoring software would need the ability to monitor more than one decoder and combine the results. I believe Alycat already has this capability. Of course, the scoring software must also accept input from my decoder! I still need to deal with that in some manner.

The Personal Lap Timing software I have already completed for this decoder will do that over a full lap. Setting up your own timing loop will not affect the track's usual timing loop, and your results will show up on both systems.

It shouldn't be difficult to combine the outputs of two loop amplifiers to permit splits with a single decoder. But there would be no way for the decoder to know which signal was coming from where, so you would need to use split times that were obviously different from each other so you could see which was which.

In both of these cases, there is of course the inconvenience of setting up one or more of your own timing loops.

When something doesn’t work properly, it’s an indication of a problem. But sometimes when something works too well, it’s also a sign of a problem. (“If it sounds too good to be true, it usually is.”)

My initial belief that having 10 transponders in the loop at the same time would prevent determination of ID messages was, in fact, correct. I found a glitch in the software that made it possible, but only rarely would also recognize a status message as an ID message (which would have alerted me to the problem). Now that this glitch has been corrected, IDs can be determined for only about 5 transponders in the loop at the same time.

Again, this has no effect on normal operation, where each transponder ID is recognized as each car individually passes through the loop (we call this “checking in”). When all of the IDs have been recognized, then all 10 transponders can be in the loop simultaneously with no ill effects.

The Digital Phase Detector (DPD) is now operational.

This thread started with an account of the first iteration of the DPD, and my main concern then was eliminating spurious pulses in the detector output created when the transponder carrier edges would occur in a different sample period than expected due to mismatched clock frequencies between the DPD and the transponder. My original approach was to use three individual phase detectors that would sample at different times, then combine the outputs with a majority logic gate so that a spurious pulse from any single detector would be suppressed. I wasn’t entirely successful!

The new approach is to use a single detector, but suppress spurious pulses by requiring that there be pulses in at least two out of three successive sample times to result in a final output from the DPD.

Here’s the schematic, followed by a short description:

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

U20B and associated components create a 40 MHz clock signal for the DPD. (This can also be divided down to 20 MHz for use as the microprocessor clock, shown on a different schematic sheet.)

The output from the Phase Detector Input Amplifier feeds two series-connected D flip-flops in U21 (1D/1Q/2D/2Q) that sample the transponder’s 5 MHz carrier eight times per carrier cycle. The series connection reduces timing inaccuracy due to metastability.

The sampled, synchronized signal feeds one input of XOR gate U20A (the “heart” of the detector) and shift register U22. U22 delays the signal by eight sample clock periods (one full transponder carrier cycle). U20A then compares the original signal with the delayed signal, and its output goes high if they do not match. The XOR gate output is then re-synchronized to the sample clock by U21 flip flop 3D/3Q.

Two more sections of U21, 4D/4Q and 5D/5Q, delay the 3Q output by an additional one and two sample clock periods, respectively.

NAND gates U23A and U23B will generate valid (low) outputs if the XOR output was high for either two successive sample clock periods, or high for a first and third sample clock period, respectively. The outputs are again re-synchronized to the sample clock by U21 flip flops 6D/6Q and 7D/7Q. U23C then ORs the gate outputs together to create the “DIFF” signal. “DIFF” goes high only when the transponder carrier has swapped phases (phase modulation). Single, spurious pulses from U20A never appear at “DIFF”.

Counter U24 and associated gates form a pulse stretcher to transform one or several closely-spaced DIFF pulses into a single, longer pulse at “PHASE_DETECTOR_OUT”. Any positive pulse at “DIFF” resets U24’s Q4 output. U20C inverts this to give “PHASE_DETECTOR_OUT”. U23D gates the 40 MHz clock to enable counting by U24 whenever “PHASE_DETECTOR_OUT” is high. After eight sample clock periods, Q4 goes high, “PHASE_DETECTOR_OUT” goes low, and counting ceases. If more than one pulse appears at “DIFF” before Q4 goes high, the counter will reset and the pulse length at “PHASE_DETECTOR_OUT” will be extended.

EDIT: For the latest schematics, see post 206:

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

Time to test new schematics. I am finished software part. My decoder is amb20 for RCM
http://cs306401.vk.me/v306401346/5c0c/jGAs7ekoJEw.jpg
http://cs306401.vk.me/v306401346/5c03/3v5cQir4OQg.jpg

As usual, you are way ahead of me on software. It shows what a truly talented engineer can do!

Our readers might be interested in seeing what's happening on the other side of the world:

http://vk.com/club17646479

wow you can use this hardware with zround sofware?

Compatibility will be determined by software, which I have not yet completed.

Maybe Payalneg can let us know if he will be doing software for other scoring programs.

no. This software doesn't support amb systems. Only GiroZ

BBKrc may be will work.
Pc lap counter works.
Free laps works with problems.
Only RCM Begginers works without problems.

Some new photos.
Howards loop amlifier:
http://cs323616.vk.me/v323616346/8ccd/8ZKb2CfVmoQ.jpg
And very big and ugly transponder :flaming::
http://cs323616.vk.me/v323616346/8cc4/xwjEJ-OBrxE.jpg

And I think its time to share software for emulation of amb20:
https://www.dropbox.com/s/pkyigvfnohbzqel/amb20.rar
password - "payalneg"
This is very simple programm writen on Codevision v2.0. For programmers no trouble to recreate schematics. Mcu works on external crystal 7.3728Mhz. Also thera 32.768kHz crystal on TOSC.

Howard, You are god of 74hc logic.
http://cs407629.vk.me/v407629346/5487/kcSi2moL9jY.jpg

I’m about the right age for that, too. When 74HC logic was brand new… I wasn’t.

Others have already pointed out that most of this design could go into an FPGA, but 74HC logic still has the advantages of being both very cheap and still made by multiple manufacturers. (There’s nothing worse than designing with a single-sourced part, then having that part be discontinued by the manufacturer.) And, of course, it doesn’t need to be programmed!

I should give a word of warning: there are a few high-speed portions in this design (particularly the Digital Phase Detector) that may not function properly on a solderless breadboard. The layout should be kept as small as possible, and could use a ground plane, even for prototyping.

I have encountered this problem. Instead 74ac4040 (140mhz) I put cd404be (10mhz). Started working with altera epm3064 (about $ 10). I think all of your schemes to place there. Tomorrow I will gather byteblaster

but zround software support more systems : giro-z , slot, ambrc , i-lap ,d-nano, robitronic and u-sec rc timmer
and manual with f buttons in keyboard

Hi, I just finished receiver with mcu (STM32). I am directly sampling square wave from limiter. After decoding sending via USB to PC (for now) So far works ok, sampling is done at 20MHz. Have to check how to calculate crc to make sure message is correct. I made rf - ttl converter with ad8309 and work very good. Still have to play a bit with antenna matching. Even with not properly match dynamic range is abt 40db.

regards

Brano

Hi Payalneg,
nice to hear about progress. I did decoder in cpld (VHDL in lattice machx02) but as far as i can tell it is overkill. I had bpsk to spi converter in cpld but i still needed mcu for pc interfacing. I choose to override need for cpld by using faster mcu.

regards

Brano

I just did today programmer for epm3064. Today, digital phase detector will be finished by Howard. Calculate crc via cpld probably not a problem Wait and see.
I posted a couple of posts above MCU computer

you have more option in cpld. I used different approach. I measured pulse widht in cpld and ignored too short and too long pulses. So you can take in to account only pulses let say between 90-110ns for normal and 170-220 for phase change pulses. In this case you can align perfectly to pulse edge and can have tolerance for freq deviation.

You'll probably want to change your criteria for detecting a phase change. Some transponders (particularly MRT PTX) will generate two short pulses rather than one long pulse during a phase change, due to the tuning and relatively high Q of the tank circuit. If the detector ignores the short pulses, it will miss the phase change.

Howard, if you need Digital Phase Detector in CLPD, please PM me.
http://cs319029.vk.me/v319029346/9afb/V0XOZwtyE5k.jpg

This is exciting! Can you fit all of the digital circuitry into the PLD?

I think yes. I will start this work after test my device

really very interesting these posts!
I'm french, I'll try to make the phase detector ? Do you think it's possible to connect the phase detector after the original AMB loop (wire with 470ohm resisitor and balun) ?
to reduce the parasitic noises, why not put a 5MHz filter before the amplifier loop?

thanks

You'll still need amplification and a comparator with some hysteresis to create the digital input levels necessary for the phase detector. The tank circuit formed by the timing loop and its parallel capacitance filters at 5 MHz, so it would be best to not use the 470R resistor and balun transformer. It might be possible to use more filtering, but if you use too much then the system won't follow the modulation very well. It's certainly worth trying if there are noise problems.

OK,

What is the unit used to make your loop? foot, inch ?
I think is foot.
For an outdoor application on our circuit I need a 1' x 13' minimum loop.
What is the minimal input level for the pase detector circuit ?

I think I'll start with your installation with your loop decoding to understand and see the analog levels.

thanks.

I'm using a 1x8 foot loop. You can use a larger or smaller loop by changing C1 in the loop amplifier to make the loop resonate at 5 MHz. (The tuning is not very critical.) For experimentation, it's easiest to just use a trim capacitor for C1.

The phase detector requires 5V CMOS logic levels: <0.6V low, > 4.4V high.

Here are the schematics for the loop amp and phase detector input amp, which should be used together:

http://www.rctech.net/forum/11802000-post68.html

I have done the loop amplifier. I have only 140mV peak to peak AMB transponder, the signal level is it correct before I build the phase detector input amp ? On the 42 post you have 200mV peak to peak.


Thanks.

That will work fine. The phase detector input amplifier provides the rest of the gain needed.

I have a problem with the phase detector input amplifier.
When I connect Q4 output to the 74HC04 input, the signal is disturbs. Before the 74HC04 input, signal is perfect centered to 2,5 V.
Have you met this problem before ?
thanks

That isn't a problem. What you have observed is normal.

what is the function of the R11 resistor ?

It adds hysteresis.

I take some pictures tomorow.
When I connected signal to the 74HC04 pin 1, the signal is disturb, waveform is deformed.

my problem :
1st picture
h_ttp://hostingpics.net/viewer.php?id=887040scope1.png

yellow : between R9 & R10 of the phasqe detector input amplifier
green : pin 4 of the 74HC04

first picture, the 74HC04 is not powered.

2nd picture, the 74HC04 is powered with filtrage capacitor (100nF)

2nd picture
h_ttp://hostingpics.net/viewer.php?id=953389scope4.png

thanks.

Your scope shots show normal circuit operation. There is no problem.

The second scope shot shows the analog signal converted to CMOS digital levels. This is what the Phase Detector Input Amplifier does.