I sended a message about coding to Howard.

Ok, howardcano, can we get some details about the coding?

Thanks

Payalneg has sent me some information, but he asked that I keep it confidential, which I will do. It will be his decision if he wants to share it.

Hi felows, nice work do you have, learn lots reading your posts.
Has someone test the Cano sistem in boats?
Any chance to adapt for boats, i have a race boat clube and like to build and test a system like yours.
Regards and keep good work.

I haven't tested it for boats. You may run into problems with reception due to the conductivity of the water.

Nice work guys!
 

Hi guys,

I've registered just to post this here - to say the least I'm bloody impressed at how far you guys have come with this and to congratulate you on what you've done so far.

I came across this through doing a bit of research for what I'm still working on - which as it happens is almost the exact same thing, but aimed at cycling.

I won't go in to details for now, but will say just this:

1. I've been involved with electronic timing since 1994 - and have a very good understanding of the protocols and electronics used by MyLaps and a number of their competitors - particularly Dorian, but also TagHeuer and Orion. Knowing the problems those systems had to overcome, and the shady business dealings of ... err... one certain company - bravo to you guys getting this far.
2. It's interesting to see the design decisions you guys have gone with, largely in order to retain compatibility.
3. I too am in the process of designing a system (targeting to cycling), but which uses very different principles to any of the MyLaps systems. It's much closer in function to Dorian DATA-1 or Equitime in how it works.

I'll certainly be keeping an eye on this as you guys progress.

Welcome to the thread!

My designs and ramblings presented here have attracted a good number of very talented people who are creating their own systems, sometimes using bits and pieces of what has been presented, sometimes entirely from scratch. I find it very inspiring to hear of their exploits! Please keep us posted on your progress!

I have tested a few things with decoding old amb protocol from the transponder.

One thing i noticed with my old amb decoder is that the bits after the 8 data byte in the stream are not needed for it to read the transponder number, and it makes sense since the 16bit number have its last most significant bit in it.

What i have tried after that is tested all 32 posible combinations that still gives the same transponder number.
the last 8 bits is this sequence in my test: 01100100 (decoded 110)
and only these 4 worked
00100111
00100100
01100111
01100100
they all are within one bit error of the original and is then error corrected by the decoder. none other sequence worked of the 32 possible combinations.

I then tried to change the transponder number by cutting the last bit from 110 to 100 making the transponder number 3xxxxx2, well within the range between 2097152-9999999

Again if the code to create the message is decoded without knowledge of what is coming after the bit its reading, i could try all 32 possible combinations that make this transponder number and one of them, or 4 with error corrections, should work then. but this was not the case, none worked. This suggest that not all possible transponder numbers are valid even if you get the coding right.

And last a question, have anyone managed to create a trellis diagram that work to recreate a known sequence? or is it some other coding in use here? I have failed to get a 2bit state trellis to work, is it a 3 bit state? reversed order?

ps.
my own made transponder often have a "ghost number" that is not the real number that show up more often than the real number, this is always under the 2097152 that some say is the lowest possible number, yet my decoder picks it up, i have picked up a ghost number of 16000 something from a transponder with a 5000000 number. I thought the error correction must be weak to allow this, of 6 transponder numbers i have programmed and tested in my own made transponder 5 have this ghost numbers .

I ran into a similar situation with my transponders. Here is the transponder thread:

http://www.rctech.net/forum/radio-el...er-design.html

Here is the particular post:

http://www.rctech.net/forum/11978449-post126.html

This post doesn't mention the "ghost numbers", although (if I recall correctly) the remedy described did fix this also.

Great information, but i have not find any status message on my AMBrc DP, how does the status message "preamble" look like, if any? I have a 200MHz recorder but it only record just enough time to get a id message in one frame (without triggers) so i have to try many times before i randomly get a message at the same time it records. And the antenna pickup is not great so the information is bad most of the time.

I posted an answer in the transponder thread, since that is a more appropriate place for it:

http://www.rctech.net/forum/13423620-post183.html

magic box
 

Hi all
been tying to follow this thread on and off for a while.
maybe some one can answer this quick and easy. we run two tracks in our area with the same amb timing gear, with the second track I will like to run it with out the yellow cable ( the one with the magic black box) just coaxial and an amp I guess(home made magic box), would this following link work for what Im trying to achieve ?

http://www.jaycar.co.nz/productView....UBCATID=965#11

Iknow Howard has put up a drawing but I not sure if I can get all the bits.

Thanks for any help I may get.

The link you provided is for an audio amplifier. There are many reasons it will not work for what you want to do. The first is that its frequency response is at least a factor of 100 less than what is needed.

Okay.

thanks very much for the quick Answer Howard..

cheers

While I feel like it's gravedigging this post, I wanted to comment on this and give some details on how we handle this in other systems, including AMB (MyLaps) TranX, Orion Ceres, TagHeuer RCS, DATA-1 and Mk42. Also I'm bored, to jotting this out helps me think.

TranX is somewhat susceptible to mounting height and metallic objects being placed fore or aft of the transmitter. The reason for this is, as you say, averaging. Given the radiation pattern of the antenna used, at a raised height, the actual hits received may only be from the mid-point (or leading/trailing edge) as the transmitter crosses the loop.

The algorithm is more like avg(strength*time) - ie, the leading edge signals are slightly weaker, they induce a lower voltage, so they're not considered as relevant - but still somewhat relevant - to the overall signal.
This is important as you might only get, say... packets 1, 3, 7, 22, 24 if you have a lot of noise (and don't want to type a long list ;)
I can prove as much as about 50ms variance in TranX crossings.

TranX Pro can control a few loops, but most other AMB systems are single loop - and single timebase per decoder.

Ceres is a bit more... catastrophic in this regard. You see, Ceres uses the very last frame only for calculating time. We only discovered this recently. The result is that when you get lots of transponders through its active field simultaneously, all bets are off as to when you might get that timestamp due to collisions etc. TagHeuer RCS is a bit the same.
Ceres also doesn't use a loop for detection at all - the loop is an activation loop only. Detection is actually via an antennae connected to the decoder. I'm not going to explain right now how this leads to almost zero accuracy.

Then there's DATA-1 - designed in 1986(?), still the gold standard for accuracy. The new Formula 1 transmitters use a similar principle - but they're still not quite as accurate.
In DATA-1, you're looking for a certain squelch level.

In a DATA-1 frame, imagine you're looking for 6 bytes. It's very small - and yes, they're very limited in their available number range. It uses an antenna very similar to a ham radio - it's a ferrite core loopstick antenna - highly directional. As the transmitter gets closer to the leading edge of the loop, it induces a + voltage. It's going to get closer and closer, each time each bit being a little bit stronger voltage. Then eventually it's going to pass that leading edge loop, and start giving less voltage. Then it's going to reach the trailing edge of the loop, and start inducing the other way - until it peaks - then it trails off.

Mk42 puts a frame-counter within the frames. This does two things: 1: The Two CRCs completely change with every frame. and 2: If you're missing a frame due to noise etc, you also know *which* frame.

Since both systems don't pause between frames, they just loop straight back to where they started, you know very precisely how much time was missing between each frame.

The time that gets used is the exact centre point (in 10,000ths of a second) between four signal points - the squelch level you set on the rise, then as it came back down, then the negative of this on the trailing loop edge, then the fall.

It's rated to operate at 400km/h - though we've been able to get a few frames at 432km/h, down to only a single frame at 460km/h.


Unfortunately the result of the use of a loopstick antenna like this is your maximum range is about 40 centimeters at 3V, but that's fine. Mk42 is using exactly the same method. Differences: It can act as an active transponder, or a passive transmitter, and it uses a much smaller antennae - it only has to operate at speeds of 70km/h, not 400km/h. The transponder version has a coil in it, and whereas in MyLaps systems the active field transmits data, which in effect is used to tell a Flex transponder whether or not to turn on, all we use it for is to generate enough of a electrical charge to turn on the attiny85 it runs on. After it gets that high bit, battery power takes over until it goes low again, and the transponder turns off.



Another core difference is how AMB RCx, AMB TranX, TagHeuer RCS and Orion Ceres handle collisions.
As you might imagine, when you only have a single reception antennae, a lot of things happen when you pass multiple devices over a loop simultaneously. One of these is noise. It's extremely difficult to decode multiple electrical signals on a single line when they're both trying to talk over each other - so you could miss effectively most of your frames.

DATA-1 gets around this in two ways: One, because of the very low transmission range I spoke about because of the loopstick antenna.
The second is by using multiple smaller loops. By making your loops as wide as your narrowest vehicle, you can gaurantee only one device at a time ever crosses a single loop at a time. Result: No noise on loops from multiple simultaneous transmitter passes, as they're isolated.

So how is this managed?

Well, DATA-1 in general allows use of four loops per card, and up to 7 cards per Track-Side Receiver - 28 addresses, with 4 reserved for other hardware addresses. Each card has its own clock, so you need to sync them periodically (we would generally do it before the start of each race to be safe).
Mk42 does it a bit differently - using a set of common pins which provide a constant 10-bit clock sync. But essentially it's designed as an expandable system. For almost everyone, one card (4 loops) will be sufficient.

These loops on cards - they might not all be for the same line. Say you have 7 cards in a TSR, you might have 12 of those loops as the main finish line, another 4 being a speed trap 10m after the finish line, and 5x2 in pit lane giving you 4 pit lane speed traps. Why 5x2? Because if a car stops in a pit bay directly on that loop, it's flooding that loop, so you put one on the garage side, one on the lane side.

So what about when you want more loops? Well, then you add another TSR, and you have a super-node that connects to TSRs. The result? Well, right now I'm looking at the track.cfg for Texas Speedway that has 8 TSRs with 4 cards in them, and another 3 TSRs with 2 cards in each. Yep, 152 loops total. I've also got the Indianapolis one here which is 15 TSRs each with 4 cards in them - 240 loops. The ones for Australian and NZ tracks are really pretty boring - couple of lines, few speedtraps, nothing special.
Then there's manual cards that control things like lights.


Anyway, that's gone a bit off track, but the point of typing this out is to hopefully help you get some thinking caps on with respect to how you would go about determining an accurate event time given what signals you can pick up - and how you can consider a 'better' system to be more accurate if it doesn't have to deal with collisions, or omni-directional antennae.

I guess what I'm saying is:
If you get away from the thinking that one loop across a track is used, just because AMB/MyLaps do it that way - you may find yourself able to get much more accurate times, particularly when dealing with multiple simultaneous crossings.

Anyway, enjoy ;D

To howardcano:
I was made decoder based on you schematic. And find some problems.
1. Some time it received wrong bits at end of data packet (last 3 bytes). First 8 bytes is all time right. Think need make synchronization with transponder signals like DPLL.
2. The signal after U1C (To phase detector) looks not good.

Wow, that's a lot of information to digest! If my goal is to learn something new each day, then this should take me through the end of the year. Thanks!

Yes, bit errors do occasionally happen, and not just in the last three bytes. That's virtually impossible to prevent, and is why almost all systems have some software-based method of detecting and correcting them. In my case, the software looks for three identical data packets in a row before accepting the packet as valid.

We'll need more information to help with this.

In my case errors is only at end of packet. Think it is result of desynchronisation between Chip quartz and Detector quartz. Maybe have reason reset some timer every time when received bit. It will be synchronize both for every next bit timing.

I not have permission to place directly links on this forum. Delete spaces in link.
w w w.d r o p b o x.com/s/3vcy1ubcw0i9w2p/notgood.png

You need to use all of the circuits presented before drawing conclusions; the SSC re-synchronizes to the incoming data whenever a phase inversion (interpreted as a logical 1) occurs:
http://www.rctech.net/forum/11880840-post118.html
The operating frequency of the transponder may differ from the decoder without generating errors, but the tolerable difference depends on the maximal run of zeroes in the data. This is 13 zeroes from the transponders I have tested, which translates to a frequency difference of about 1%. None of the transponders I tested had a combination of frequency deviation and maximum run of zeroes that would generate a bit error.

It doesn't look good; it should have very sharp rise and fall times. Make sure you are using a 74HC device (not 74C) for U1, and check for any miswiring creating excess capacitance on the node.

Hmm. Thanks for explanation. My problem is - i put all your schematic in CPLD and can't test it by oscilloscope for find problem. In any case thanks.

I see your use resistor for hysteresis but i not see resistor before U1B...

That would be R9 and R10.

I don't know if this will help - probably not, because of the way RC4 seems to be encoded - but this is how I got around this problem in an AM carrier wave:

Except the sync-byte, every bit is manchester encoded.

Every bit gets sampled 8 times. The result is you can re-sync your timing on every single bit when you get a little bit of drift. By spreading sampling 8 times within a bit, you can find the point in, say, a high bit at which a low goes high, or on a low bit, when a high goes low. If it drifts by more than 1/8th of a sample for two bits in a row (allowing for a bit of noise), I resync.
If you're using a 5MHz crystal, then you're not going to have much luck here. To achieve this in the same way you'd want to be using a at least a 40MHz TCXO.

In an active system you can use your active field for synchronization. For example, say you have a 125kHz active field, you can use that either embed a sync (eg, every 12th wave has three times the power, something like that).

Food for thought maybe?

If I knew a bit more about the RC4 protocol/carrier specifically I could probably be of more help, sorry, otherwise I can only give general/abstract ideas :(

Hi,
based on algorithm which is used for encoding number to bytestream you can use sw error correction. You can find the algorithm with source code in transponder design thread. It is based on convolution with long constrain length so viterbi can not be used but you can use some other algs. If you need further explanation i can help you with this as i worked a lot with finding this alg.
regards
Brano

I mean - Must be resistor before 74HC04 if your use it as Schmitt trigger.
This is typycal schematic: h t t p://upload.wikimedia.org/wikipedia/commons/thumb/6/64/Op-Amp_Schmitt_Trigger.svg/300px-Op-Amp_Schmitt_Trigger.svg.png

R9 and R10 serve this function. Their Thevenin equivalent is the input resistor; that's 1K, in this case.

http://en.wikipedia.org/wiki/Th%C3%A9venin%27s_theorem

If i right understand - 11 bytes = 88 bits/ 2 = 44 bits. It is 5 bytes + 1 nibble.
So... Why your decoder and encoder use only 3 bytes?

the are some bits which meaning is unknown and number is still the same, we tested that. What we tested is that decoder does not care about these bits. They just needs to be encoded correctly. Maybe in newer version of decoder these bits has some meanings. First 2bits in each received byte after preamble does not have meaning at least we do not know. Or maybe this alg is wrong ;0)
Anyhow you can calculate which bit you should receive and till some extent you can correct wrongly received bits.

Somewhere in this unknown bits hided secret of detecting where is ID packet and where is Status packet.

That might be jumping to an incorrect conclusion. The terms "ID" and "status" for describing the packets are totally arbitrary, created by me. I needed to call them something, and I named the packet that was transmitted most often by the transponder "ID" because that's what I ended up using it for in my decoder software. At the time I created these arbitrary names, I had no idea what was contained in the data.

I think you right with terms "ID" and "status".
Without Status packets AMBrc decoder stop accept chip after 1-2 laps.
Also Status packets is unique for every single chip. So i think it based on ID number.
100% somewhere must be identificator of packet type.
All chips what i read (not too much, just 4 chips) have data like xxxxxxxxxxxxxxxxxxxxx0 - last nibble all time = 0. I think it's not a data. It is part of packet footer (like zeros before preamble data) . And it have reason - 5 bytes = 40 bits length.

i do not think so, at least not in this case, this works with dp (older) transponders and i think those do not have status message. From my observation those sends all the time the same message.

I believe you are correct. Three of the twenty "bonus numbers" contained in the MRT PTX-20 do not have status messages, and all of these were "cloned" by MRT from AMB devices.

Hi Howard,

i do not have access to decoder now, can you or anybody test to generate the same number with different 'ghost bits' and check which of them works ?

DP chip have ID and 7 status messages.

I only have access to MyLaps and AMB decoders about once weekly, and then all of my time is spent racing (usually four or more classes!).

Hi,
if anybody is interested in this project, I have a few PCB's here.
When I ordered them I got a few more delivered.
It's Cano's Layout as you can see in the pictures.

Just PM me and we talk about the price and shipment (I live in Germany).

Mike

Hi Snoopy,

i had the same thought as you to shield the concrete, i am in the process of building my decoder now since i did not get aoround to it all summer. So once its built i will test on a concrete floor.

As for this equipment being too expensive your absolutly correct considering how cheap components are! There should be a low cost alternative and this one is the way especially considering that Howard has designed an inexpensive transponder, we can just build our own systems and transponders.

Hi Walsmi,

I also have extra decoder boards, but no transponder boards. I would be interested in buying some of your trasnponder boards! PM me.

thanks

Hello Howard,

I am in the process of building my board finally!

A question for you, concerning the Crystal that goes in XTL61, there are 3 holes. Which holes do we use?

thanks