That's great to hear!

Payalneg, I sent you a private message.

Quote for pics

Kjrell, thanks for posting the photos!

Payalneg, here is a description of how to post photos:

http://www.rctech.net/forum/10334159-post102.html

Personal Lap Timer (PLT)!!!
 

The code for the “Personal Lap Timer” (PLT) is now working.

The PLT reads the first valid transponder ID it sees after power-up, stores it to EEPROM, then calculates lap times for that transponder while ignoring all others. The results are sent via RS232 to an external computer.

The RS232 signal is currently logic-level, which doesn’t conform to the true specification (that requires voltages below -3V), but the PC I’m using has no problem reading the logic levels.

While I have saved the transponder ID to EEPROM, and recall the ID and send it via RS232 to make sure it got where it was supposed to go, I’m currently not using the value stored in the EEPROM for anything else. I intend on including a pushbutton to tell the microprocessor when to acquire the transponder ID so there will be no need to re-acquire it every time the decoder is powered-up (which is now a minor inconvenience).

The next (vitally important) step will be to test the system with transponders in moving cars, and modify things depending on the effects of interference from the motor, ESC, radio, etc.

I’ll post the last schematic, showing connections to the microprocessor, shortly.

Here’s the schematic I promised earlier:

The microprocessor receives transponder data (stripped of the first two bytes by the Preamble Detector / Stripper, or PDS), timestamps it, and transmits the result as ASCII hexadecimal characters in asynchronous serial format to an external computer.

(Alternatively, I have also created software that recognizes a single transponder and calculates lap times for it, for use in testing and as a “Personal Lap Timer”.)

Microprocessor U60 runs at 20 MHz, as determined by crystal XTL60 and capacitors C65 and C66. (U60 is shown as a 28 pin PIC16F886; my prototype uses the 40 pin PIC16F887.) One of the internal counters runs at 32.00 KHz, as determined by crystal XTL61 and capacitors C67 and C68. This is used as a timebase for the timestamps.

U61B divides the 20 MHz clock down to 10 MHz for use in the Synchronous Serial Converter (SSC). (Thanks to Brano, “OM2KW”, for pointing out that the PIC oscillator will drive the counter when in HS mode.)

The prototype currently transfers the transponder data into the microprocessor using the components labeled “Parallel Interface”. When the code for the SPI interface is complete, these will be eliminated , and U61A and U41D will serve the purpose.

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

EDIT: For the latest schematics, see post 206:

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

I've been re-investigating bringing the transponder data into the PIC on its SPI port, in an effort to eliminate the two ICs in the Parallel Interface (on the microprocessor schematic sheet). Unfortunately, there is an anomaly where every ninth bit in the data stream is ignored, regardless of whether or not the Slave Select pin is active. (The PIC has an option to either use or ignore the Slave Select). I've contacted Microchip about the problem.

According to my oscilloscope, all of the bits are being clocked in correctly to the PIC, and all setup, hold, and clock times are more than the minimum specifications.

The two ICs in the Parallel Interface don't use up much space or cost much money, so it's not a big deal if the SPI won't work. But it would be nice to understand what's going on!

Keep up the Great work.

I am Waiting for some ATMEL AVR test:nod:
I personally think the AVR will resolve the SPI lost ninth bit problem.
Maybe next week I will start working on the Amplifiers.
PCB's for the Amplifiers would be nice but this project is still in its infancy.
Personally I like ExpressPCB for their Quality work but they are kinda pricey.

I think the entier timing and scoring system could be done on a ATMEGA128 /ATMEGA1280
I have nothing against PIC's I just code AVR's as a hobby.

AMB, be afraid, be very afraid!

As a compromise between for profit and open source, you could try the "John Carmack" model. Sell it, make some money, and then give it away.

And once it's open source, it'll just get better and better.

You geeks are awesome!

Thanks for the encouragement!

It’s quite possible that changing over to the Atmel microprocessor will solve the SPI problem, probably because I won’t repeat the same mistake I’m making with the PIC-- whatever that mistake might be. But the biggest reason to change to the Atmel will be for the larger RAM (giving more space for the transmit FIFO).

The loop amplifier design is likely stable enough to do a PC board. The other schematics will probably need tweaking after doing some real-world testing. There’s the question of AGC on the Phase Detector Input Amplifier, and I’ve got another version of the digital Phase Detector that I want to try.

If you happen to lay out a PC board, please feel free to share it with us!

I’ve used Advanced Circuits for many years. Several times they’ve gone way further than I would have expected with their help and support. It’s hard to find service like that these days.

Thanks for your kind words.

I don't think AMB has much to worry about. From what we've heard, RC is only a small market for them. Also, I believe that the decoders make much less money than the transponders!

I'll probably offer the programmed microprocessors at a nominal cost, just like I did on my transponder design. That might help recover some of my development expenses.

SPI on shift register is better then SPI in AVR. Interrupt, return from interrupt writing data in SRAM is very many cycle of MCU. Detectors on 74hc logic os the best way.
Thanks to Howard for amplifier schematics. My device is working fine. :)

For example this device maked on ATMEGA128 with external 32kb RAM.
Detector if based on ATTINY2313 (this is my big mistake to do detectors on MCU)
Also it have ENC28J60 for Ethernet and Tp-link for WiFi.

I am waiting Howard chips to do compataible Amb chips with my decoder
h_ttp://i1277.photobucket.com/albums/y482/Payalneg/2013-03-10114721_zps9c9e45ba.jpg
h_ttp://i1277.photobucket.com/albums/y482/Payalneg/2013-03-10114729_zps0927950a.jpg

P.S. Can post images because: 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.

This is some really fantastic work! Photos from Payalneg's last post:

http://i1277.photobucket.com/albums/...ps9c9e45ba.jpg

http://i1277.photobucket.com/albums/...ps0927950a.jpg

I dont know how it is in USA, but in Europe, and mainly France (my country) there is many tracks that cant afford an AMB system, transponder is not the problem, but the crazily overpriced decoder is. National/regional federation lend their ones for events, but this means no timing for everyday racers...

About transponders, I've read here on R/C Tech that AMB ones should cost less then 25$ based on components used (bought by one, not hundreds like AMB)

We'll be pleased to support the job you did!

You guys are doing an amazing job :D

http://www.hobbytalk.com/bbs1/archiv...p/t-73738.html
much to sift through though it help me alot with a IR system many years ago.

Patrick

From the Internet because it is true.

When I ran this test, the setup was with one computer, so I ran
Autoscore with USB and the terminal program on RS232. The first
results shows that the AMBrc will send AMB20 data on the RS232 and
AMBrc data on the USB port at the same time. To get the AMBrc to send
the full data on the RS232 port, you need to "enable" the AMBrc mode
via the serial port. Once enabled, it will continue to send data in
AMBrc mode, and the scoring program can be either RS232 or USB. This
means that you don't need a Y cable, but an initialization string from
the communication program (or something else to start the serial data
in AMBrc mode).

OK. Now here is the data in "raw" format from the communication
program. The # records are status, the @ are transponders.

^A@ 237 213 5479698 80.619 130 119 2 x6D70
237 is the decoder ID. 213 is the sequence number, then transponder
number (5479698), time (80.619) in seconds, number of hits (130),
signal strength (119), Loop and battery indicator (2) and then
checksum. The delimiter (character between fields) is a tab.

^A# 237 212 0 x38E0
^A@ 237 213 5479698 80.619 130 119 2 x6D70
^A@ 237 214 2395327 80.792 119 135 2 x2CC1
^A# 237 215 0 xA177
^A@ 237 216 2395327 85.434 34 88 2 x2779
^A@ 237 217 5479698 85.626 172 164 2 x7A44
^A# 237 218 0 xD72B
^A@ 237 219 2395327 90.262 62 75 2 xFC1
^A@ 237 220 5479698 90.48 170 155 2 xE6E6
^A# 237 221 0 x34E3
^A@ 237 222 5479698 94.301 185 138 2 x56C3
^A@ 237 223 2395327 94.408 173 135 2 x9F89
^A# 237 224 0 xCB16
^A@ 237 225 5479698 98.448 131 117 2 xC7F2
^A@ 237 226 2395327 98.46 122 115 2 x4744
^A# 237 227 0 x9E45

After sorting by transponder number and then time...

^A# 237 221 0 x34E3
^A# 237 212 0 x38E0
^A# 237 227 0 x9E45
^A# 237 215 0 xA177
^A# 237 224 0 xCB16
^A# 237 218 0 xD72B
^A@ 237 214 2395327 80.792 119 135 2 x2CC1
^A@ 237 216 2395327 85.434 34 88 2 x2779
^A@ 237 219 2395327 90.262 62 75 2 xFC1
^A@ 237 223 2395327 94.408 173 135 2 x9F89
^A@ 237 226 2395327 98.46 122 115 2 x4744
^A@ 237 213 5479698 80.619 130 119 2 x6D70
^A@ 237 217 5479698 85.626 172 164 2 x7A44
^A@ 237 220 5479698 90.48 170 155 2 xE6E6
^A@ 237 222 5479698 94.301 185 138 2 x56C3
^A@ 237 225 5479698 98.448 131 117 2 xC7F2

After an excel computation (and less columns)...
0 x34E3
0 x38E0
0 x9E45
0 xA177
0 xCB16
0 xD72B
2395327 80.792 119 135 2 x2CC1
2395327 85.434 34 88 2 x2779 4.642
2395327 90.262 62 75 2 xFC1 4.828
2395327 94.408 173 135 2 x9F89 4.146
2395327 98.46 122 115 2 x4744 4.052
5479698 80.619 130 119 2 x6D70
5479698 85.626 172 164 2 x7A44 5.007
5479698 90.48 170 155 2 xE6E6 4.854
5479698 94.301 185 138 2 x56C3 3.821
5479698 98.448 131 117 2 xC7F2 4.147

You can easily count the laps and check split times.

WoW , i´m very impresed , Howard and Payalneg are my idols
very very good work,
i´m spanish and i have a rc club in my country but for lap count used zround and manual push in keyboard f1 f2 f3 f4 f5 f6 f7 f8 f9 f10 .... for car 1 , 2 ,3 etc
amb decoder is very expensive
im very interested in this Project

thanks

We have a similar situation here in the USA. There’s a good market for used AMB decoders, since the new ones are very expensive.

The parts cost for my transponder design is about $5 in small quantities, without the PC board. I paid $10 per raw PC board in quantities of 10. That would be much lower for larger quantities.

As I have pointed out in my transponder thread, the price of the transponders has little to do with their manufacturing cost. All the myriad expenses of running a business--salaries, rent, utilities, government approvals, and product support, to name a few-- contribute much more to the cost than the parts and assembly labor do.

Many thanks for this information!

I remember making tick marks on paper, with columns for each car! Getting a computer, a program, and using the function keys was a godsend!

Thanks to both of you for the encouragement. We are fortunate to have many talented people reading and contributing to this thread. I am constantly amazed at the abilities of Payalneg and others. They seem capable of doing in their sleep what would take me weeks of labor!

We have reached several important milestones, but there is much work yet to be done to reach the final goal of a “generic” lap timing system.

Payalneg's setup seems to be working pretty good, what problems (explained for non-electric skilled persons) are there?

Oh and before I forget... :lol:

http://www.scubaboard.com/forums/att...my-money11.jpg

edit:What about a donation? Would that help with the development? I'm super excited about this...

Hi,

I'm software programmer, I'm very interested on this thread and maybe make a simple/free lap timing software.

Please let me know the comm properties to read data from RS232 or USB Comm port (BaudRate,DataBits,Parity,StopBits,FlowControl)

Thanks

9600,8,N,1,hardware flow control

I will post the spec's tonight 7pm PST and a raw HEX dump of the serial port of my IR system that works with the free programs including RCScoringPro (not free)

There are lots of free programs out on the web.
I will post the ones I have and use for Family racing.

Perhaps Payalneg can let us know more details on his system, and how far along he is on development.

Money is always welcome, but I'll feel better when I can send you something in return! When the design is stable, I'll probably be offering programmed microprocessors, and maybe bare circuit boards (or assembled and tested, depending on how they are affected by FCC regulations).

If you want to create software to work with the decoder we are presenting, here are the details:

The data string is currently sent from the decoder via RS232 at 115200 baud, 8 data bits, no parity, 1 stop bit, no flow control. The first 6 hex ASCII characters are the first 24 bits of each transponder transmission after the preamble. (I am assuming that these 24 bits are unique enough to use as an ID, as they are different for each of the 30 or so transponders I have examined so far. We can always include more bits if we start to find different transponders with the same first 24 bits.) The next 8 hex ASCII characters are the timestamp, MSB first, in increments of 1/4 millisecond. (This is different than shown in post #116, where the LSB was first.) The string is terminated with a carriage return and line feed.

To keep the decoder hardware expense as small as possible, it will not do any calculations, but will simply receive all of the transponder transmissions, timestamp them, and send them to the scoring PC. The PC must sort them, determine when each transponder passed over the center of the timing loop (we'll call this the "crossing time"), calculate the lap time for each transponder, and pass the result off to the scoring program. These tasks could also be integral to the scoring program.

The transponder sends its ID at least three times consecutively, then sends some type of status message on the next transmission. This means that the PC needs to determine whether the message is for ID or status. Since we have no way of knowing what the message means, the PC can determine if the message is for ID by keeping a list in memory of, say, the newest 20 messages that have been received at least 3 times consecutively. If the message matches one in this list, then it is for ID. If there is no match, then the message should be ignored.

The PC must determine the loop crossing time for each transponder by averaging the timestamps of the first and last ID messages for a given transponder within a certain time window (for instance, after no messages have been received from the transponder for, let's say, 0.1 second).

Then the PC must then calculate the lap time for each transponder by subtracting the previous crossing time from the latest crossing time.

I think the decoder should determine the loop crossing it is not to hard to do and gives the pc more time to run other task.
to determin the crossing time my IR decoder counts the passing HIT's (up to 255 max) then uses the center 2 hits and adds thenthen devide by 2 giving center of the loop. It is not perfect but it is within .01 sec.

having more then 5 cars pass within one half second under the loop causes problems (lost hits)

on average my 20mph real speed test shows 30 to 40 hits per car
at mod speeds fo 43mph I get 15 to 20 hits
if 5 cars go under the loop at the same time then expect only 4 to 7 hits per car at 43mph.

if a car sits under the loop then it counts up to 255 hits and waits for the car to exit the loop for a minimum of 1sec before starting a new hit count. otherwise all you have to do is sit under the loop to win the race:lol:

time stamps in HEX from My IR Decoder
it is not quite 100% amb compatable but it works with
Free programs already out there

theses programs simply ignore the Csum at the end
Iridium ( the maker of the IR system I use)
alycat/lapsFree/jlaps/

it does not work with B&B's autoscore (Autoscore needs csums to be correct) and I am lousy at figuring out 16bit csums

Can any body help me with the 16bit csum's ?


this HEX does not include the ^A at the begining instead it uses the older (SOH) Ox01 and (CR,LF)
sh = start of heading
@ = transponder
# = unit status (sent every 4 seconds)
09 = tab used as a delimeter
device id = 202 for my unit
frame = 0 to ~ prolly used to keep track of lap times after a race
transponder number 7 digit cannot use 3000000 to 3999999 <-house transponder numbers only that i know of
time in seconds . hundreths seconds <-- could use of hit counts and average time to get thousands calculated
hun = Hundreths of a second
thousands of a second possible or even tenths of thousands but not used on my decoder unit
hits = how many times the transponder war counted under the loop per pass <--Max 255 and must leave the loop for one second before restarting hit count
Dummy = normaly used for rf signal strenth <- not used so for compatibility set to 111db
0 = loop and battery indicator <-- I have not played with this one yet
x = end of data field or start of Csum or both
checksum displayed in ascii format <-- I have not figured out how to compute for other programs to work with (autoscore/RCtimer/ect)
checksum is not used by most Timing Software

sh_@_|_devicID___|__frame #_|__transponder number_|__time____.__hun___|__hits__|_dummy__|__0_ |__x checksum in ascii (cr,lf)
01 40 09 32 30 32 09 31 35 39 09 31 30 30 33 30 39 34 09 33 32 37 2E 36 35 09 31 39 09 31 31 31 09 30 09 78 35 37 32 34 0D 0A
01 40 09 32 30 32 09 31 36 30 09 31 30 30 33 30 39 34 09 33 32 37 2E 39 35 09 33 30 09 31 31 31 09 30 09 78 35 37 32 34 0D 0A
01 40 09 32 30 32 09 31 36 31 09 31 30 30 33 30 39 34 09 33 32 38 2E 32 36 09 33 31 09 31 31 31 09 30 09 78 35 37 32 34 0D 0A
01 40 09 32 30 32 09 31 36 32 09 31 30 30 33 30 39 34 09 33 32 38 2E 38 35 09 35 37 09 31 31 31 09 30 09 78 35 37 32 34 0D 0A
01 40 09 32 30 32 09 31 36 33 09 31 30 30 33 30 39 34 09 33 32 39 2E 31 33 09 31 36 09 31 31 31 09 30 09 78 35 37 32 34 0D 0A
01 40 09 32 30 32 09 31 36 34 09 31 30 30 33 30 39 34 09 33 32 39 2E 34 32 09 31 33 09 31 31 31 09 30 09 78 35 37 32 34 0D 0A
01 40 09 32 30 32 09 31 36 35 09 31 30 30 33 30 39 34 09 33 32 39 2E 37 36 09 32 36 09 31 31 31 09 30 09 78 35 37 32 34 0D 0A

These strings sent once every 4 seconds indicating the decoder is alive ,kinda like a watch dog timer
lets the pc know it is connected and working properly
01 23 09 32 30 32 09 31 36 36 09 30 09 78 43 32 34 39 0D 0A

01 23 09 32 30 32 09 32 34 30 09 30 09 78 43 32 34 39 0D 0A

I am working at this project since december 2012.
Transponder very simple:
h_ttp://cs407731.vk.me/v407731346/726b/-Wo4gFwpM_E.jpg
Its ATTINY25 (in future will be ATTINY85) clocking by an external crystal 20Mhz.
5Mhz carrier is making by internal Timer with PWM.
100p capacitor and 15 turns of of copper wire as transmiting antenna.

thanks Howard for loop amplifiers.
Decoder based on Attiny2313 on 20Mhz. This mcu transmit decoded ID to ATMEGA128 via SPI.

Main unit (ATMEGA128) have 2 functions: counting laps and web server.
In external SRAM 32kb storing pilots results. In internal eeprom storing information ID-Name.
Ethernet is maked by microchip ENC28J60. Its simple MCU with very large errata.
Main unit now have one setup button to store client MAC as Admin MAC

Lcd is hd44780 20x2.

h_ttp://cs419517.vk.me/v419517346/3f30/FDJe9Cjpo1I.jpg

My ten little frends:
h_ttp://cs407816.vk.me/v407816346/9905/v23CFrNzcd4.jpg

Payalneg, it looks like you have been quite busy!

Is the software to run races complete?

Photos from the last post:

http://cs407731.vk.me/v407731346/726b/-Wo4gFwpM_E.jpg

http://cs419517.vk.me/v419517346/3f30/FDJe9Cjpo1I.jpg

http://cs407816.vk.me/v407816346/9905/v23CFrNzcd4.jpg

The Mark of Microchip!

Here is an example of the data from the decoder, with a single transponder sitting in the loop:

B96CB700FFB6CE
CDFD4C00FFB6DA
CDFD4C00FFB6EA
CDFD4C00FFB6F9
CD8E2A00FFB706
CDFD4C00FFB70F
CDFD4C00FFB71A
CDFD4C00FFB728
749AA700FFB733
CDFD4C00FFB741
CDFD4C00FFB74D
CDFD4C00FFB75C
CABFB600FFB768
CDFD4C00FFB771
CDFD4C00FFB77B
CDFD4C00FFB785
73D37900FFB792
CDFD4C00FFB79A
CDFD4C00FFB7A4
CDFD4C00FFB7AE
0073D800FFB7BC
CDFD4C00FFB7C6
CDFD4C00FFB7D1
CDFD4C00FFB7E0
73D89700FFB7EF
CDFD4C00FFB7FA
CDFD4C00FFB80A
CDFD4C00FFB818
B96CB700FFB824
CDFD4C00FFB833
CDFD4C00FFB841
CDFD4C00FFB84C
CD8E2A00FFB85A

My rc4 transponder also have codes looks like yours, but spi converter works not stable. I will wait yours chip to continue with amb transponders compatable.

p.s. We only have two transponder amb in our city.

well , the zround software with manual keys f1 f2 ...... is simple
you can implement this system with 12 transponders in a dismantalate keyboarb for that when passing transponder 1 automatic press f1 key , transponder 2 f2 key ........ to transponder 12 f12 key.

By the way, instead of r8 and r9 in the first scheme is better to put a variable resistor.

Today I tested my system. Its works fine, but there is some problems. Some times transponders are not detected. I think the problem is RESET pin not connected of ATTINY25. MCU just reseting all the time. I will add to protocol times of Poweed On to watch this. Some times i could conect to device by WiFi. But its works very fine.
Some photos
http://cs407816.vk.me/v407816346/9ad5/DIC6IhtOhC4.jpg
http://cs407816.vk.me/v407816346/9ade/k2IslSZuLjQ.jpg
http://cs407816.vk.me/v407816346/9ae7/aT_7CEG4mVY.jpg
http://cs407816.vk.me/v407816346/9af0/wrV1PqdVkcA.jpg
http://cs407816.vk.me/v407816346/9af9/RVa2fsizUk8.jpg

great work payalneg i´m very interestec in this Project, but can conector in a pc for use with zrounz software in amb mode

The voltage indicated at this point on the Loop Amplifier schematic is an approximate value; if it's off by 0.1V, it's no big deal. More substantial errors indicate that the input transistors, Q1 and Q2, are mismatched. You can use the diode function (or one of the resistance ranges) on a DVM to match their Vbe’s (within 2mV should be fine). Alternatively, an input offset voltage adjust pot can be added. I’ll include this option on the schematic when I get a chance. I don’t recommend changing R8 and R9.

The Loop Amplifier and Phase Detector Input Amplifier have quite a bit of gain. If it needs to be decreased, it should be done by increasing R2 on the Phase Detector Input Amplifier. Doubling its value will cut the gain by about a factor of 2. If I need to add AGC to the system, this is where I will add the circuitry.

This is awesome!

I’ve been taking some time to get my cars ready for a couple of big races I’ll be attending, but now it’s time for an update on the decoder:

I went to Home Depot yesterday and bought some 1x2’s to make a timing loop “bridge” that I can use at the local track. (The track owner has kindly given me permission to set up the loop on a non-points day.) It will break down so the longest piece is 5’, so I can transport all of the pieces along with all of my cars and gear in my Miata. (The guys at the track find it amusing that the largest amount of RC stuff arrives in the smallest vehicle!) I’ll post photos when it is done.

Parts for my next try at the digital phase detector are on order. While the analog phase detector works nicely, I’d still like to use a digital arrangement that won’t need any tuning or “tweaking” for proper operation, since not everyone that will want to construct a decoder will have access to an oscilloscope.

I’ve also started software to move the first task that I had intended for the PC into the decoder: sorting the transponder messages, and only transmitting those that represent an ID to the PC. (This is the first step in calculating lap times inside the decoder, rather than in the PC.) This task would be much simpler if I knew the format of the transponder data and message! But since I don’t, I’ll use the method I previously mentioned: keeping a list of messages that have been received at least twice in a row, and sending only those messages.

Currently, there are two big “bottlenecks” in the decoder: the time it takes to send all transponder messages to the PC, and the large size of the transmit FIFO required to store all those messages while they are waiting to be sent. Calculating lap times for each car inside the decoder would be difficult, but it does have the advantage of eliminating the transmission time bottleneck, since only a single message would need to be sent per car per lap. I’m hoping that the RAM requirements for calculating lap times will be no larger than that for the FIFO.

The Personal Lap Timer in Action!
 

Here are some photos from testing the decoder. I was using the Personal Lap Timer software.

I had to re-tune the loop amplifier to match the new timing loop, since I eliminated the 3’ lead-in length of zip cord used on the original loop. There is now virtually no lead-in length since the loop amplifier is placed directly at the loop.

The photo of the lap times shows 10 laps in a row (at the bottom of the screen) where I drove my 1/10 scale, 13.5T 1s pan car under the loop under full acceleration from a standing start about 3’ away, then turned around and did the same in the other direction. These conditions create a large amount of electrical noise from the motor and ESC, as the current draw is highest. There were no problems with the pan car.

I then tried my 17.5T, 2s TC, using the original AMB transponder, and missed about half of the laps. This seemed to be regardless of whether I was on throttle through the loop, or coasting through it. The problem turned out to be insufficient pulse stretching time in the analog phase detector, which I have now corrected.

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

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

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

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

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

Awesome! Keep up the fantastic work!