Counter voor time difference of arrival

Hallo,

Ik ben bezig met een positiesysteem op basis van ultrasound en RF. Voor RF gebruik ik een 433MHz setje van Conrad.

Zie het plaatje hieronder voor een overview:
http://bredend.com/images/ups-problem4.gif

De communicatie zal als volgt verlopen:
http://bredend.com/images/ups-problem3.gif

En dit is wat in de 3 verschillende onderdelen moet gebeuren:
http://bredend.com/images/ups-problem2.gif

Momenteel zitten we nog in de design fase, en is er nog niets gemaakt.
Het probleem zit in de controller, om precies te zijn de counter. De controller krijgt van elke beacon een puls binnen. De tijd tussen het onvangen van de radio ping, en per beacon de ultrasound ping moet gemeten worden.

Het probleem is dat in de groep wel iemand zit die met BASIC Stamp kan werken, en daarmee zou het wel mogelijk moeten zijn, maar dan zitten we op het randje van wat dat ding kan, en is het waarschijnlijk niet accuraat genoeg.

Daarom ben ik op zoek naar een counter IC die 4 aparte inputs heeft en bij een pulse van een beacon de tijd opslaat en vervolgens doorgaat met tellen om ook bij de tweede, derde en vierde puls de tijd op te slaan. In theorie zou dat exact tegerlijk kunnen gebeuren.
De counter moet een resolutie hebben van minimaal 0,3ms, maar 0,03 zou nog beter zijn. een 32kHz teller word het dan.

Wie kan mij vertellen welke IC hiervoor geschikt is? Eventueel meerdere, maar het moet niet al te ingewikkeld worden, aangezien ik nog nooit met IC's gewerkt heb.

Hmm, dit kan je op 2 manieren doen.

1. Je zend bursts uit, en je meet dan pulsjes die terug komen.

2. Je zend een continu signaal uit, en je meet faseverschillen. Dan moet je het ding eerst 'ijken' door hem op een gekende positie te houden. Daarna geld dat iedere keer dat je 1 golflengte verder van een sensor verwijderd bent, dat dan de fase 360 graden gedraaid is.

Bij methode 2 is het lastiger te timen, maar waarschijnlijk wil je methode 1 gebruiken.

Er zijn verschillende counter-IC's op de markt.
De 4060 is een 14-bit counter. Neem 4 van deze IC's, voor ieder kanaal ééntje. Daarnaast heb je één 4044 IC nodig met 4 flipflops. En als laatste een 4011, 4 AND poorten.

Hoe meet je?
Je hebt een oscillator, die een goede meetfrequentie opwekt, met kristal ofzo.
Dit bied je aan op de ene ingang van de AND poort. Op als de andere ingang dan 1 is, dan komt het clock-signaal eruit. Die andere ingang sluit je dus aan op een S/R flipflop.
Die flipflop wordt bij iedere ontvangen radiopuls geset, de uitgang wordt 1, en je hebt dan een clocksignaal. Als de puls van US ontvanger binnen is, dan reset je de flipflop, en het clocksignaal op de uitgang van de AND houd op.
De clock 4060 sluit je aan op de uitgang van de AND poort. Deze gaat dan dus tellen zodra de radiopuls ontvangen, en hij stopt zodra de US-puls ontvangen is.
Je laat het ding resetten wanneer de radiopuls ontvangen wordt.

en dan heb je zo dus 4 counters, die de tijd aangeven. het zijn 14bits, da's meer dan dat je nodig hebt, neem ik aan.

Eigenlijk is het RF gedeelte niet eens nodig.

Als 4 US ontvangers reageren op de US ping, dan heb je meteen 3 tijdverschillen.
Je object zit dan op de kruising van 3 bijbehorende hyperbolen; aangezien 2 al genoeg zouden zijn (3 ontvangers) heb je nog een check ook.

klopt, maarja, dan is t te moeilijk voor de jeugd van tegenwoordig. Dan moet je gaan nadenken met wiskunde enzo, en da's eng.

Hyperbolen kruisen is toch niet moeilijker (in software of op papier) dan cirkels kruisen?
Voor jouw tellerbeschrijving maakt het ook niet uit; dat stuk van de oplossing blijft gelukkig hetzelfde. ;-)
Alleen moet je nu gewoon de eerste US puls afwachten, en dan tellen tot de andere ontvangen zijn.

[Bericht gewijzigd door Frederick E. Terman op ]

Dat valt tegen, want je weet namelijk niet wanneer de puls uitgezonden wordt. Je weet alleen het tijdsverschil tussen de pulsen, en dus wat het afstandsverschil van zender naar A, en van zender naar B is.
Maar dat zou als het goed is met 4 dingen wel gewoon moeten kunnen.

hmm.. bij nader inzien is het idd toch eigenlijk wel erg makkelijk ja.

[Bericht gewijzigd door (Z)weetvoetje op ]

Op 17 november 2006 12:40:34 schreef (Z)weetvoetje:
klopt, maarja, dan is t te moeilijk voor de jeugd van tegenwoordig. Dan moet je gaan nadenken met wiskunde enzo, en da's eng.

Ik heb het eerst proberen te ontwerpen zonder RF ping, maar dat werkt niet goed als het object in het midden zit: dan heb je drie zeer korte tijden, en gaat de nauwkeurigheid omlaag.
Voor enge dingen ben ik niet bang hoor ;)

http://bredend.com/images/ups-problem0.gif
http://bredend.com/images/ups-problem1.gif

De oplossing van (Z)weetvoetje is mij toch wat te pittig. Ik ben momenteel ook aan het kijken of je het tellen misschien op een PC kan laten doen dmv een seriele poort.

[Bericht gewijzigd door bredend op ]

Op 17 november 2006 12:52:19 schreef bredend:
Voor enge dingen ben ik niet bang hoor ;)

definitie van eng is dat je er bang voor bent...

Wat is er zo lastig aan die oplossing van mij? Simpeler kan het haast niet zou ik zo zeggen. Dat zijn 6 goedkope IC'tjes, en verder (bijna) niets. De PC laten tellen is grote overkill. De enige moeilijkheid zou nog kunnen zijn om de 4 uitgangen na elkaar uit te lezen, maar dat moet ook nog wel lukken.

Houd je er trouwens wel rekening mee dat het ontvangertje ook omhoog en omlaag kan? want het is natuurlijk niet allemaal in het platte vlak...

Op 17 november 2006 12:48:52 schreef Frederick E. Terman:
Hyperbolen kruisen is toch niet moeilijker (in software of op papier) dan cirkels kruisen?

schrijft da eens rap in 8 bit assembler .... en dan praten we verder ( en je mag gene float libraries gebruiken. code moet self contained zijn )

picjes kun je ook prima in C programmeren hoor.

Op 17 november 2006 16:41:28 schreef free_electron:
[...]

schrijft da eens rap in 8 bit assembler .... en dan praten we verder ( en je mag gene float libraries gebruiken. code moet self contained zijn )

Wat is er tegen libraries ? Jij programmeert je 8051 toch ook niet met een hex keypad of een aantal schakelaartjes ?
Maar on-topic: Ik zou toch een micro gebruiken om die 4 signalen te timen, zelfs met een software counter moet je makkelijk een nauwkeurigheid van 10 microseconden kunnen halen. Bovendien heb je het getal dan in een makkelijk te hanteren vorm. Voor die hardware counter van (Z)weetvoetje moet je 4 * 14 datalijnen uitlezen. Dat kan je multiplexen maar kost meer hardware. Is dus een keuze tussen een software of hardware oplossing.

Toen de huidige GPS zo'n beetje begon, in de jaren tachtig, MOEST het wel in 8-bit. Het is rekenkundig hetzelfde probleem, alleen in drie dimensies.

Eén oplossing was het iteratief te doen. Uitgaande van een gegokte positie (de vorige positie, bijvoorbeeld) de verwachte tijdsverschillen uitrekenen, vergelijken, en dan de gok aanpassen in de juiste richting tot het klopt.

Op 17 november 2006 16:46:26 schreef the waiter:
picjes kun je ook prima in C programmeren hoor.

Zeker, net zoals avr's en ander spul. Het probleem is, dat enkele float-bewerkingen vaak meer plaats innemen dan de rest van je programma. En naar de tijd die ze in beslag nemen durf ik zelfs niet raden...
Ik probeer dat te omzeilen door 32-bit integers te gebruiken, en zonodig variabelen eerst 8 of 16 bits naar links op te schuiven. Dat neemt heel wat minder code in beslag, het gaat sneller vooruit, en de nauwkeurigheid is meestal bevredigend.

maar dit hoeft toch niet iteratief te gebeuren? je kan dit met een beetje wiskunde ook best exact oplossen.

Stel je hebt 4 microfoons, A,B,C,D, met posities:
A: (0,0,0)
B: (1,0,0)
C: (0,1,0)
D: (0,0,1)
(in gewone XYZ coordinaten)

de tijd die het duurt om het signaal door te sturen van de zender naar A noem ik a, idem voor B,C,D. De coordinaten van de zender zijn x, y, z.
dan geldt:
(aangenomen voortplantingssnelheid v=1, anders factor v erbij)
a=x2+y2+z2
b=(x-1)2+y2+z2
c=x2+(y-1)2+z2
d=x2+y2+(z-1)2

Het tijdsverschil tussen a en b is a-b dus:
a-b=x2+y2+z2-(x-1)2+y2+z2=x2-x2+2x-1=2x-1.
x=(a-b+1)/2
y=(a-c+1)/2
z=(a-d+1)/2
DIT IS FOUT, FET DEED HET WEL GOED

Zo heb je de coördinaten van het object vrij makkelijk gevonden. pies of cake.

Ik probeer het (zo uit m'n hoofd) enigszins te volgen, maar het lukt me niet direct. Waar staat in je voorbeeld de 'zender' tov de microfoons ?

die staat op positie (x,y,z) t.o.v. microfoon A, want microfoon A staat op 0,0,0.

het klopt ook perfect, 4 microfoons, voor 4 onbekenden: de 3 ruimtedimensies, en de tijd. (de tijd valt hier dan natuurlijk ook mee te berekenen.

Ik ga dinsdag op me werk het excelsheetje weer eens opzoeken waarin ik met soort gelijke uitdaging heb zitten spelen. Daarin zitten alle formules al in, in visual basic vorm.

Ik denk ook dat het RF gedeelte weg kan blijven. Moet de controller de positie weten of het object ?

Object.

Als je zonder RF werkt, zou je met echo moeten werken, dus dat de bakens antwoorden dmv een US puls.

Tijdens research heb ik systemen als Bat, smartLOCUS, Cricket, Fre3space etc bestudeerd, en dan kan je niet om IR of US heen...

Zonder zou het ook moeten kunnen, maar foutgevoeliger, en met een lagere frequentie.

Ik heb inmiddels iemand gevonden die hier meer van weet, en daarom zal het een timer, 4 8-bit-counters en 4 memorycellen worden.
Ik ben nu bezig het ontwerp aan te passen. Het systeem begrijp ik volledig, waar ik het niet meer weet is als er zonodig een condensator aan pin 14 gehangen moet worden :?

Morgen weer een mooi plaatje!

misschien dat je iets op basis van GEE kan doen. :)
http://en.wikipedia.org/wiki/GEE_%28navigation%29

of op basis van loran. http://en.wikipedia.org/wiki/LORAN

Op 18 november 2006 00:56:09 schreef bredend:
Object.

Als je zonder RF werkt, zou je met echo moeten werken, dus dat de bakens antwoorden dmv een US puls.

Dat is niet zo, maar je moet ook niet met de tijden werken, maar met de tijdverschillen.
Dus nogmaals: de eerste puls is je referentie, de volgende drie geven je drie tijdverschillen. In het platte vlak zou twee al genoeg zijn (dus 3 microfoons).

Je research is onvolledig: Loran, Decca, Syledis, GPS, etc. werken allemaal via tijdverschillen (hoewel Decca via faseverschil). Bij al deze systemen zijn er vaste (althans bekende, bij GPS) zenders en is het mobiele platform een ontvanger, die niets terugzendt. Er is dus geen echo nodig.
In jouw systeem is het omgekeerd; er is een mobiele zender, en de vier vaste stations zijn ontvangers, maar ook hier is geen echo nodig.

@Zweetvoetje: kun je je afleiding aanpassen aan tijdverschillen ipv. absolute tijden?

Ik heb het toch al in tijdsverschillen?
a-b is het tijdsverschil tussen a, en b. a-c is verschil tussen a en c, en enz.

Ah, okee, ik keek niet goed.
Je hebt wel het kwadraat vergeten; het is:
a2=x2+y2+z2 enzovoorts.
De uitwerking wordt dan heel lang. Ik heb die hier uitgewerkt (met behulp van 'Derive')
Afleiding positie uit afstandsverschillen

Iteratie lijkt dan geen gekke tweede optie :-)

ochja, natuurlijk, die wortel... |:(
Ik vond het al zo verdacht eenvoudig, die oplossing.

Troost je, ik zie het ook alleen omdat ik er zelf al eens ingestonken was. :(

Voor het platte vlak, en drie microfoons (0,0), (0,1) en (1,0) wordt het altijd nog dit (waarbij ik de letter V even voor het wortelteken heb gebruikt):

                 2    2        2            2           2              2      
       p·V((1 - q )·(p  - 1)·(p  - 2·p·q + q  - 2)) + (p  - p·q - 1)·(q  - 1) 
x = - -----------------------------------------------------------------------
                                       2    2                                 
                                   2·(p  + q  - 1)

                 2    2        2            2          3      2   2               2     
       q·V((1 - q )·(p  - 1)·(p  - 2·p·q + q  - 2)) - p ·q + p ·(q  - 1) + p·q - q  + 1 
y = - ---------------------------------------------------------------------------------
                                            2    2                                      
                                        2·(p  + q  - 1)

Nog een hele mond vol, maar onmogelijk is het niet.
Natuurlijk moeten die coordinaten geschaald worden, en microfoon 'a' is niet altijd de eerste, zodat je ook met vervroegingen moet rekening houden. Maar: het kan.

Dit is in principe toch een algemene oplossing? Dan maakt het niet uit of a als eerste is of niet, je hebt anders gewoon een negatieve tijd. Volgens mij zou het dan alsnog wel uit moeten komen met de min-tekens.