Originally Posted by howardcano (Post 11712592)

That's almost correct!

The method is called Binary Phase Shift Keying (BPSK). There are many descriptions of it on the internet, but here's a quick description particular to the example you gave:

A logic 1 is indicated by ANY reversal in the carrier phase. (This is just a convention I am using. We could just as easily say that the carrier reversal indicates a logic 0.) The initial carrier phase, before data is sent, is unimportant.

First, the data stream must be preceded for a short time with the carrier turned on to give the tank circuit time to "ring up" to full amplitude, and time for the phase detector in the decoder to generate a first valid output. Then a start bit (an initial logic "1") is sent to indicate the beginning of the data stream.

So the sequence is:

1. pin 5 = low, pin 6 = low, tank circuit is not not driven and does not radiate.

2. pin 5 = high, pin 6 = low, initial ring up for tank circuit

3. pin 5 = low, pin 6 = high for one machine cycle (4 carrier periods) sends the start bit

4. No changes for 3 more machine cycles (12 carrier periods) sends "000"

5. pin 5 = high, pin 6 = low for one machine cycle (4 carrier periods) sends a logic "1"

6. No changes for 3 more machine cycles (12 carrier periods) sends "000"

Originally Posted by mos-leung (Post 11714460)

Thanks.
How about the data steam of "0" and "1", if i want to send out the transponder number "3901248" ?

Originally Posted by howardcano (Post 11714558)

I haven't the slightest idea. The data format is unknown to me. I've already posted the few things I've observed so far about the data train.

Originally Posted by freexray (Post 11716082)

Hi Howard,

Not sure how the pic programming (memory division, write protect) is done (AVR person) but have you considered putting the transponder "strings" into eeprom? on power up the program would load a string out out eeprom.
You could lock the program space but leave the eeprom space read/write allowing end users to update the "string table" (or populate it from blank).
Combined with some form of decoder, it would allow people to clone existing transponders, avoiding totally issues of clashes.

Any idea of the power required to run the transponder?

Originally Posted by Ema-77 (Post 11713549)

Really a great job, thanks for sharing and for the detailed description.
Now, the only thing we miss is a "valid" sequence of 0 and 1 that the AMB decoder is able to recognise, then we can start playing at home with our 2 cents electronic equipment :D .

Originally Posted by mos-leung (Post 11715977)

In your tested sample, is it possible to let us know one of the data stream and the corresponded transponder number ? e.g. "2034566" is logic of "000101010100010"

Originally Posted by howardcano (Post 11716540)

I will not provide this information; please re-read post #67. You can determine it on your own with an existing transponder and an oscilloscope. The details are left up to you.

Originally Posted by howardcano (Post 11716527)

The average current consumption is about 11mA from a 6V supply. That will increase if I include a Zener for shunt regulation, to permit operation from higher voltages (like a LiFe receiver pack, for those individuals still using them).

Originally Posted by freexray (Post 11720251)

I took your comment that generating the carrier on the processor was not feasible as a challenge lol. Got some parts on order to give it a try.
Back of the envelope calculations tell me it is possible (16 instruction per data bit. 8 consumed generating the carrier wave, 8 remain to calculate whether to pin toggle). would be ~1600 instructions of pure sequential code (not a single compare or branch).

Originally Posted by howardcano (Post 11720399)

Oh, it's definitely do-able, but not on the little PIC. That would take a 40 MHz clock (giving 10 MIPS), which I don't think is available on the smaller PICs, and straight-line code (as you said) where each instruction just twiddles the pins high or low. For a PIC, that's about 800 lines of code (one instruction per carrier edge, or a NOP for no edge).

Unfortunately, the output current of the PIC is still insufficient to drive the tank directly, so we would need to parallel up the output pins, requiring a larger package size. I'd rather just use separate logic gates for their higher drive current, and then the microprocessor can generate just the modulation, which makes the code 1/8 as long and lets the processor run at 1/8 the speed. That's a pretty substantial improvement for an investment of two cheap gates.

But that's only my preference. I'll definitely want to see your experiments!

Originally Posted by howardcano (Post 11653119)

The first, as I understand it, is currently available, has a yellow case, and uses ID numbers that are unique to the club transponders, so if it should disappear and show up again later, it would be easily recognizable.

Originally Posted by Ed Anderson (Post 11724177)

Other then the phsical shape,. I dont believe there is anything "unique" to the house TP numbers.... I've looked at over 100 of them locally... and the numbers are all over the place.

Originally Posted by PiccoRacing (Post 11724023)

Have you physically inspected any of the genuine AMB transponder internals? They do it with a single PIC microcontroller. The FCC docs have internal pics. I'd have provided direct links, but the forums want some undisclosed post count achieved before I can post URLS.

For clarification, AMB transponder IDs range from 2097152(2^21) to 9999999.