[Project]huis-tuin-keuken sonar

[Verwijderd]

Na goedkeuring door de mods ben ik nu terug met een aangepast project. Aan de mensen die er op zaten te wachten: sorry dat deze nieuwe topicstart zo lang duurde, maar ik wou meteen een mooie lay-out vinden voor dit project. Er zit nog een foutje in de lay-out maar die haal ik er later wel uit. Als iemand mij trouwens zou kunnen zeggen of/hoe je kleur gebruikt zou dat heel handig zijn.

Waarover gaat dit project?

Zoals de titel het al zegt, dit gaat over sonar . Sonar staat voor Sound Navigation And Ranging. In andere woorden: door geluid te gebruiken navigeer je en bepaal je afstanden tot andere voorwerpen. Sonar doet hetzelfde als radar, maar maakt gebruik van geluidsgolven in plaats van radiogolven, waardoor het niet illegaal is. Voor de mensen die niet op de hoogte zijn van de werking van sonars hierbij een korte samenvatting van de theorie: Bij een sonar stuurt de sonar zelf een geluidsgolf uit. Eens de golf vertrokken is meet de sonar de tijd die verstrijkt vooraleer de sonar een echo opvangt. Op basis van de tijd en de snelheid van het geluid (afhankelijk van temperatuur etc.) bereken je daaruit de afstand tot het voorwerp. Bovendien kan je met metingen van originele frequentie en echo-frequentie bepalen in welke richting en met welke snelheid een voorwerp beweegt. Dit is gebaseerd op het Doppler-effect. Dit Doppler-effect kan geimplementeerd worden om zo mogelijkheid te bieden enkel bewegende voorwerpen te volgen. Uiteraard worden sonars al langer dan vandaag gemaakt. Waarom dan dit project? Zoals waarschijnlijk heel velen onder jullie kreeg ik in mijn vorige levensjaren het vak Fysica / Natuurkunde. In dat vak werd mij meerdere keren het principe achter radar / sonar / lidar uitgelegd...maar daar bleef het ook bij. Ik wil nu graag met dit project eindelijk eens overstappen van de theorie naar de praktijk. Dit project gaat dus over het zelf realiseren van een kleine sonar. Hiervoor wordt enkel gebruik gemaakt van basis-onderdelen en liefst zoveel mogelijk zelf gemaakt. Bovendien moet de totale kostprijs binnen de perken blijven. Zoals ook met de mods afgesproken: deze sonar moet legaal blijven en geen schade of storingen toebrengen aan anderen.

Wat voor sonar exact

De exacte specificaties ken ik uiteraard nog niet, anders zou dit project overbodig zijn. De ruwe richtlijnen zijn wel Sonar die gebruik maakt van ultrasoon geluid Opgebouwd uit basisonderdelen Bereik liefst boven de 5 meter Niet schadelijk / hinderlijk voor mensen / dieren / andere aparatuur Betaalbaar Verdere eisen zullen ongetwijfeld voortvloeien uit discussies in dit topic.

Waarom net een sonar

Omdat een sonar het enige is dat aan alle voorwaarden kan voldoen. Een radar maken is illegaal heb ik ondertussen geleerd. Dus dat valt af, want GoT doet uiteraard (en gelukkig) niet mee aan illegale praktijken. Een lidar is niet illegaal, maar is wel hinderlijk. Ik denk niet dat mijn kat er mee zou kunnen lachen om elke minuut eens verblind te worden door een laserstraal. Bovendien denk ik dat sonar minder vatbaar is voor storingen (mist kan een lidar nogal eens in de war brengen denk ik) en makkelijker een groot bereik kan halen.

Wie mag hieraan meedoen

Iedereen is welkom! Uiteraard is het handig als je wat voorkennis hebt over hoe een sonar werkt of je goed op de hoogte bent van elektronica. Het is echter zeker geen vereiste. Zelf ben ik wel goed op de hoogte van de theorie, maar qua praktijk zal ik zelf ook veel moeten bijscholen denk ik. Echter als je bereid bent om te leren wat je niet weet, dan ben je hier van harte welkom.

Handige links

Theorie: http://electronics.howstuffworks.com/radar.htm: Hoe werkt radar (principe sonar is gelijklopend) http://hyperphysics.phy-astr.gsu.edu/hbase/sound/dopp.html: Niet zo duidelijk voor het principe van Doppler-effect maar bevat wel alle nodige formules. http://home.planet.nl/~heuve345/nl/electronics/course/course.html: Elektronica-cursus uit de FAQ, ziet er verstaanbaar en uitgebreid uit. Doppler-effect: Afleiding van de formule om snelheid van een voorwerp te bepalen. Praktijk: http://www.robot-electronics.co.uk/htm/srf04tech.htm: bevat een schema van een sonar, kan een hulp zijn. Conrad: Ultrasone receiver en transmitter. Circuits Online: handige basis-tutorial over PIC's, zeker de moeite om te lezen. http://samples.microchip.com/: Gratis samples van PIC's. http://www.maxim-ic.com/: Gratis samples van o.a. MAX232, MAX232A, MAX233 Boondog: Nog een tutorial over PIC's, behandelt ook communicatie tussen PIC en PC. Codeworks: Info over communicatie met de seriele poort in VB.NET Momenteel zijn dit de enige links, deze vul ik zeker nog aan later.

Slotwoorden

Eerst en vooral wil ik nu al iedereen van harte bedanken die meehelpt aan dit project. Ok hoop dat we samen ooit zullen mogen zeggen dat het ons gelukt is. Uiteraard zal ik zelf proberen om de sonar volledig te maken. Als hij eenmaal af is hebben we misschien wel de eerste GoT-sonar gemaakt Uiteraard zal ik dit topic, eens de in de ontwikkelfase komen, voorzien van vele foto's van het verloop. Ik wens jullie allemaal heel veel plezier in dit topic. offtopic: Alle opmerkingen over hoe de startpost kan verbeterd worden zijn uiteraard welkom.

[ Voor 26% gewijzigd door Verwijderd op 18-07-2004 15:26 . Reden: Lay-out aangepast. ]

[Verwijderd]

Laat ik meteen maar beginnen ook met een paar ideeën.

Om een goeie sonar te kunnen maken moet je gericht geluid kunnen uitzenden. Hiervoor stel ik het volgende voor. We maken een stuk van een paraboloïde en plaatsen microfoon en luidspreker van de sonar in het brandpunt. Zo heb je meteen gericht geluid opgewekt en het weerkaatst geluid wordt door de paraboloide ook terug wat versterkt in het brandpunt waardoor de gevoeligheid van de microfoon minder hoog moet zijn.
Praktisch maken van de paraboloide is natuurlijk iets anders. We moeten een materiaal vinden dat zoveel mogelijk geluid weerkaatst zonder te absorberen. Zelf had ik gedacht aan een metalen frame (gelast) met daarop plexi-glas. Dit omdat het volgens mij wel mooi is. Of het functioneel is weet ik echter niet. Bovendien weet ik ook niet hoe je plexiglas in de vorm van een paraboloide kunt krijgen.

Kwestie van motor (de sonar moet kunnen ronddraaien toch) dacht ik aan een steppermotor (of steppenmotor ?). Als de constructie niet te zwaar is kan zelf een licht motortje uit een oude diskdrive dienst doen, dit in de gedachte het zo goedkoop mogelijk te houden.

[sebastius]

Electronica en Microcontroller persoon meld zich. Ik heb een aantal gedachten:

• Afstand is afhankelijk van hoe snel jij je rondje wil maken, en hoe goed je geluid gefocust is. Vooraf 5 meter eisen is wat drastisch.
• Er zijn kant en klare ultrasoon setjes (dus zender/ontvanger in één), hoef je alleen nog maar rond te laten draaien en uitlezen.
• Printplaatjes kan ik eventueel ontwerpen en bestellen.

[Brazza]

Ik zat hier laatst ook aan te denken toen me zus naar Prenetal ging voor een 3d echo (waarbij ze de hersens van het kind konden zien) maakten van haar kindje.

Wat zou je dan in kaart willen brengen? Je kamer-meubilair?

[Verwijderd]

sebastius schreef op 10 juli 2004 @ 18:27:
Electronica en Microcontroller persoon meld zich. Ik heb een aantal gedachten:

• Afstand is afhankelijk van hoe snel jij je rondje wil maken, en hoe goed je geluid gefocust is. Vooraf 5 meter eisen is wat drastisch.
• Er zijn kant en klare ultrasoon setjes (dus zender/ontvanger in één), hoef je alleen nog maar rond te laten draaien en uitlezen.
• Printplaatjes kan ik eventueel ontwerpen en bestellen.

• Rondje uiteraard zo traag als het moet...ik denk vooral aan de draagwijdte van het signaal zelf, als ik spreek over die 5 meter. Ik veronderstel dat een heel zwak signaal na 5 meter veel te zwak is om nog teruggekaatst te worden en opgevangen te worden door de microfoon.
• Dat die setjes bestaan, dat weet ik, maar dan blijft er heel weinig over van de uitdaging eigenlijk vind ik. Ik zou het dus liefst volledig zelf maken met standaard-componenten (weerstanden, luidsprekers, microfoons,...).
• Ontwerpen van printplaat zijn inderdaad wel heel belangrijk. Dat mag je zeker en vast doen en hier posten hoor . Ik zal dan eens kunnen testen hoe mijn begrip is van printplaten "lezen", kan ik op je steun rekenen als ik het niet goed begrijp

Trouwens, ik veronderstel dat je nogal wat ervaring hebt met printplaten. Hoe zit het "echt" met het zelf maken van printplaten? Ik zag hier in de FAQ een paar links over hoe je zelf etsen e.d. moet maken. Zijn die veel minder in kwaliteit dan als je ze besteld, of veel moeilijker te maken?

[Verwijderd]

Brazza schreef op 10 juli 2004 @ 18:33:
Ik zat hier laatst ook aan te denken toen me zus naar Prenetal ging voor een 3d echo (waarbij ze de hersens van het kind konden zien) maakten van haar kindje.

Wat zou je dan in kaart willen brengen? Je kamer-meubilair?

Om het even eigenlijk, het gaat vooral om het kunnen maken ervan, wat ermee gedaan kan worden is eigenlijk bijzaak. Ik veronderstel dat doordat we uiteraard legaal moeten blijven en betaalbaar, het praktische nut sowieso al minimaal zal zijn.
Het is dus eerder een project om later te kunnen zeggen dat je het gemaakt hebt, dan om er iets praktisch mee aan te vangen.

[MissingDog]

Ik denk dat je met een Piezo element meer succes hebt qua geluidsbron, omdat je daarbij minder bijgeluiden hebt dan met reguliere geluidsbrengers en exacter getimede pulsen kunt geven. Tevens is zo'n elementje relatief klein en dus uitermate geschikt om te verwerken in je setup.

De plaatsing van de geluidsbron hoeft niet noodzakelijk direct naast de microfoon te zijn, zolang je maar de exacte afstand+hoek tussen de twee weet kan je dit compenseren in je berekeningen van het teruggekeerde signaal.

Verder is het ontvangen van teruggekaatst geluid erg leuk, maar heb je al enig idee wat voor schakeling of software je erachter moet hangen om het signaal te bewerken tot een bruikbare response?

[ Voor 30% gewijzigd door MissingDog op 10-07-2004 18:51 ]

[sebastius]

Verwijderd schreef op 10 juli 2004 @ 18:36:
[...]

• Ontwerpen van printplaat zijn inderdaad wel heel belangrijk. Dat mag je zeker en vast doen en hier posten hoor . Ik zal dan eens kunnen testen hoe mijn begrip is van printplaten "lezen", kan ik op je steun rekenen als ik het niet goed begrijp

Trouwens, ik veronderstel dat je nogal wat ervaring hebt met printplaten. Hoe zit het "echt" met het zelf maken van printplaten? Ik zag hier in de FAQ een paar links over hoe je zelf etsen e.d. moet maken. Zijn die veel minder in kwaliteit dan als je ze besteld, of veel moeilijker te maken?

Uiteraard kan ik wel wat helpen hier en daar, mits je zelf ook een beetje initiatief toont en gewoon zelf dingen opzoekt. Ik ben geen vraagbaak.

Printplaten uit de fabriek kosten meer, maar zijn ook veel beter van kwaliteit. Je kan er ook meer mee, dus smallere baantjes, meer eilandjes, dubbelzijdig enzovoort. Het kan vanaf 2 stuks.

[Verwijderd]

het beste zou zijn om de "aansturing", berekeningen etc te laten doen door een uc (avr of pic ofzo) en die dan weer laten praten met een pc (via seriele poort)?

[Brothar]

In ieder geval "modulair" lijkt me.
Hiermee bedoel ik:
- op Seriële poort - of USB ? (lijkt me beter) - een zender (module) en 1 of meerdere ontvangers (modules)
- het reken- en plot- werk (=plaatje: 3D mogelijk ?) doet de PC

Zo zou het dan mogelijk moeten zijn om, met een groter aantal ontvangermodules, een grotere nauwkeurigheid te bereiken.
De ontvangermodules zouden dan, evenals de zendermodule (wellicht dat 2 zendermodules, waarvan de stralen elkaar kruisen onder een hoek van 90 graden, ook mogelijk is) stationair kunnen zijn. Stationair omdat, als ik het "robotics"-schema goed lees, 1 puls/ontvangst-cyclus 20 milliseconde duurt. Per seconde betekent dat 50 cycli, en dat zou voor een "radar"-opstelling een draaisnelheid van 50 omwentelingen per seconde (= 3000 per minuut) moeten betekenen.
(Kan een zender die draaisnelheid aan ?).
Met een geluidsnelheid van 300km/s betekent dat, dat de ontvangst bijna direct is (bij een gemiddelde woonkamer). Dit stelt dus een redelijk grote "reactiesnelheid"van de electronica (bijeen bereik van meer dan 5 meter).
Bovendien moet dan rekening gehouden kunnen worden met de weerkaatsing door de muren.

@Damoke:
- inderdaad, geluidssnelheid is 340 m/s (temperatuur + druk correctie is leuk, maar dat vind ik iets voor fine-tuning in een later stadium);
- 20 ms - ik zei niet voor niets: "als ik het goed lees" - leidde ik af uit de periode van 18 ms maximum duur voor echo pulse (100us - 18 ms).Maar de note inzake 36 ms "if no object detected" gaat dus meer richting 25 cycli per seconde (en dat moet met een stappen motor te doen zijn).

[ Voor 25% gewijzigd door Brothar op 10-07-2004 22:18 ]

[Verwijderd]

Mooie topicstart

Misschien wel handige naslag:
http://www.thunting.com/c...rum=sonar&startThread=121
http://www.portup.com/~dfount/sidescan.htm

[Verwijderd]

Even een algemene reply op de voorgaande posts.

Naar mijn idee zou zowel aansturing als berekening door computer plaatsvinden.
Ik dacht zelf om gebruik te maken van de parallelle poort omdat ik uit de FAQ etc opmaakte dat die redelijk rap aan te sturen en uit te lezen was. Echter USB is wel een mooiere oplossing naar mijn mening, als dat realiseerbaar is zou ik daar dan ook de voorkeur aan geven.

Hoe ik het hele systeem zie:

- Simpelst:
De sonar doet op zich niets. Het is de pc waarmee hij verbonden is die hem opdrachten geeft. Zo stuurt de pc eerst een signaal uit dat de sonar opdracht geeft een geluidsgolf uit te sturen. Op dat ogenblik begint de sonar ook met het terugsturen van een signaal naar de pc. Zodra de sonar zijn echo ontvangt stopt hij met terugsturen naar de pc. De pc kan de tijd bepalen tussen verzenden en echo en zo dus de afstand. Nadien geeft de pc een ander signaal om de motor een beetje te draaien. Vanaf dan begint alles terug vanaf nul.
In dit systeem wordt alles dus gedaan door computer.

- Mooist:
Op een of andere manier wordt het grooste deel al door de sonar zelf gedaan. De sonar zendt uiteindelijk continu afstand/snelheid/positie sonar door over de USB/Printer kabel. Dit zou uiteraard mooier zijn omdat de sonar dan volledig autonoom werkt. Ik weet echter niet of dergelijk systeem doenbaar is.

Misschien is dit iets waar de inbreng van mensen die goed op de hoogte zijn van elektronica belangrijk is. Wat vinden jullie er van?

[Verwijderd]

sebastius schreef op 10 juli 2004 @ 20:25:
[...]
Uiteraard kan ik wel wat helpen hier en daar, mits je zelf ook een beetje initiatief toont en gewoon zelf dingen opzoekt. Ik ben geen vraagbaak.

Printplaten uit de fabriek kosten meer, maar zijn ook veel beter van kwaliteit. Je kan er ook meer mee, dus smallere baantjes, meer eilandjes, dubbelzijdig enzovoort. Het kan vanaf 2 stuks.

Ik begrijp heel goed wat je bedoelt Ik was ook helemaal niet van plan om je als vraagbak te gebruiken hoor. Enkel de dingen die ik echt niet vind of versta zou ik aan juo kunnen vragen dan.

Bedankt ook voor je inbreng over de printplaten. Als de kwaliteit inderdaad veel beter is en de mogelijkheden uitgebreider dan hoeft er niet veel getwijfeld te worden (ik verondstel dat de kostprijs deftig blijft voor kleine oplagen).

[Verwijderd]

MissingDog schreef op 10 juli 2004 @ 18:48:
Ik denk dat je met een Piezo element meer succes hebt qua geluidsbron, omdat je daarbij minder bijgeluiden hebt dan met reguliere geluidsbrengers en exacter getimede pulsen kunt geven. Tevens is zo'n elementje relatief klein en dus uitermate geschikt om te verwerken in je setup.

De plaatsing van de geluidsbron hoeft niet noodzakelijk direct naast de microfoon te zijn, zolang je maar de exacte afstand+hoek tussen de twee weet kan je dit compenseren in je berekeningen van het teruggekeerde signaal.

Verder is het ontvangen van teruggekaatst geluid erg leuk, maar heb je al enig idee wat voor schakeling of software je erachter moet hangen om het signaal te bewerken tot een bruikbare response?

Piezo elementen ken ik enkel uit aanstekers maar ik veronderstel dat de werking gelijkaardig zal zijn. Als dat inderdaad minder bijgeluiden oplevert is dat zeker het overwegen waard natuurlijk.

Je opmerking over de plaatsing van microfoon en luidspreker is correct, alleen volgens mij niet echt van toepassing of verstandig als we met een paraboloide werken. Als je luidspreker dan niet in het brandpunt staat krijg je geen goed gericht geluid. Anderzijds als je microfoon niet in het brandpunt staat krijg je een veel zwakker signaal terug waardoor je veel gevoeligere microfoons moet hebben.

[Verwijderd]

Brothar schreef op 10 juli 2004 @ 20:48:
In ieder geval "modulair" lijkt me.
Hiermee bedoel ik:
- op Seriële poort - of USB ? (lijkt me beter) - een zender (module) en 1 of meerdere ontvangers (modules)
- het reken- en plot- werk (=plaatje: 3D mogelijk ?) doet de PC

Zo zou het dan mogelijk moeten zijn om, met een groter aantal ontvangermodules, een grotere nauwkeurigheid te bereiken.
De ontvangermodules zouden dan, evenals de zendermodule (wellicht dat 2 zendermodules, waarvan de stralen elkaar kruisen onder een hoek van 90 graden, ook mogelijk is) stationair kunnen zijn. Stationair omdat, als ik het "robotics"-schema goed lees, 1 puls/ontvangst-cyclus 20 milliseconde duurt. Per seconde betekent dat 50 cycli, en dat zou voor een "radar"-opstelling een draaisnelheid van 50 omwentelingen per seconde (= 3000 per minuut) moeten betekenen.
(Kan een zender die draaisnelheid aan ?).
Met een geluidsnelheid van 300km/s betekent dat, dat de ontvangst bijna direct is (bij een gemiddelde woonkamer). Dit stelt dus een redelijk grote "reactiesnelheid"van de electronica (bijeen bereik van meer dan 5 meter).
Bovendien moet dan rekening gehouden kunnen worden met de weerkaatsing door de muren.

Ik snap je berekeningen met het robotics-schema niet echt. Als ik versta wat je bedoelt zou jij een signaal laten uitsturen en dan eerst een rondje draaien voor je de echo opvangt. Dat lijkt me nogal gek. Volgens mij is de bedoeling signaal sturen, wachten op echo, dan pas draaien. Dan draai je zo snel of zo traag als je wil. Ik snap ook niet waar je aan die cyclus van 20 miliseconden komt, die hangt toch af van de afstand tot het voorwerp?

Als laatste wil ik, om verwarring te verhinderen, nog even opmerken dat de snelheid heel wat lager ligt dan 300km/s. We werken hier met geluid en niet licht dus een snelheid van "maar" 340m/s.

Hier omtrent: de 340 m/s is maar een benadering. De exacte snelheid van geluid in lucht is ook afhankelijk van temperatuur en druk. Wie is er voorstaander van de sonar van een temperatuursensor te voorzien, om op basis daarvan de correcte(re) snelheid te bepalen? Als we dat doen moet er wel rekening gehouden worden emt het feit dat dat een extra berekening betekend.
Als we voor de "makkelijkste" manier gaan [zie hierboven] is dat op zich niet zo erg moeilijk. Als de "mooiste" manier mogelijk is brengt dat misschien wel problemen met zich mee...

[-DarkShadow-]

Verwijderd schreef op 10 juli 2004 @ 12:52:
...

Ik vind het een heel goed initiatief, maar wat is je eigen kennis? Uit je verhaal maak ik min of meer op dat je weinig ervaring hebt met elektronica. De theorie achter een sonar snappen is iets heel anders dan zelf een sonar in een uC te programmeren. Als ik jou was zou ik met een minder 'drastisch' project beginnen. Maak eens een looplichtje, een batterijlader en een schaakcomputer (mogen best andere dingen zijn hoor) met een uC. Dan heb je de basiskennis uC te pakken en dan kun je verder kijken. En dan heb ik het niet eens over het analoge verhaal, maar daar kun je in deze schakeling aardig omheenwerken omdat het een kwestie is van sensors uitlezen en gegevens verwerken (klinkt lekker simpel zo).

Edit: Sorry, praktijkervaring ontbreekt het je ook al aan je PCB-verhaal te zien. Praktijkervaring is héél belangrijk heb ik gemerkt. Ik heb de afgelopen jaren relatief weinig theorie bijgeleerd, maar ik heb wel veel projecten ter hand genomen. En geloof mij maar dat het 10e project beter ging dan het eerste terwijl het 'niveau' hetzelfde was.

[ Voor 35% gewijzigd door -DarkShadow- op 10-07-2004 22:08 ]

[Verwijderd]

-DarkShadow- schreef op 10 juli 2004 @ 22:03:
[...]

Ik vind het een heel goed initiatief, maar wat is je eigen kennis? Uit je verhaal maak ik min of meer op dat je weinig ervaring hebt met elektronica. De theorie achter een sonar snappen is iets heel anders dan zelf een sonar in een uC te programmeren. Als ik jou was zou ik met een minder 'drastisch' project beginnen. Maak eens een looplichtje, een batterijlader en een schaakcomputer (mogen best andere dingen zijn hoor) met een uC. Dan heb je de basiskennis uC te pakken en dan kun je verder kijken. En dan heb ik het niet eens over het analoge verhaal, maar daar kun je in deze schakeling aardig omheenwerken omdat het een kwestie is van sensors uitlezen en gegevens verwerken (klinkt lekker simpel zo).

Edit: Sorry, praktijkervaring ontbreekt het je ook al aan je PCB-verhaal te zien. Praktijkervaring is héél belangrijk heb ik gemerkt. Ik heb de afgelopen jaren relatief weinig theorie bijgeleerd, maar ik heb wel veel projecten ter hand genomen. En geloof mij maar dat het 10e project beter ging dan het eerste terwijl het 'niveau' hetzelfde was.

Praktijkervaring heb ik inderdaad niet...maar het is net daarom dat ik dit project tot een goed eind wil brengen. Ik ben het beu van altijd theorie te krijgen en nooit tot de praktijk te komen.

Ik weet dat ik tijdens dit project veel over elektronica zal moeten leren, maar dat heb ik er voor over. Ik heb het liever dat ik heel veel op korte periode moet leren en nadien een indrukwekkend eindresultaat heb, dan geleidelijk aan leren en maar "kleine" dingen maken als een looplicht.

Ik geloof heel goed dat praktijkervaring belangrijk is: oefening baart kunst zeggen ze. Het is echter niet mijn bedoeling om met dit project plots de perfecte elektronica-specialist te worden. Als ik met dit project tot een werkend systeem kan komen waarvan ik de werking snap ben ik al zeer tevreden. Zoals ik al meermaals zei is het voor mij vooral de bedoeling om de overstap van theorie naar praktijk eens te maken.

Ik hoop dat mensen die hieraan willen meewerken dit nog steeds willen, ook al is mijn elektronica-kennis ver van optimaal. Ik ben er van overtuigd : waar een wil is, is een weg...en de wil is er heel zeker. Een paar kenners die richtingaanwijzer willen spelen (en er zelf ook wat van willen opsteken uiteraard) maken de weg echter wel wat duidelijker.

[Vermicellisoep]

Veel verstand heb ik er niet van, maar ik weet dat er aardig complexe berekeningen aan te pas komen om een mooie paraboloïde 'schotel' te maken. Plexiglas lijkt mij niet direct de meest eenvoudige oplossing, ik heb zelf al gemerkt dat dat heel moeilijk te buigen is, laat staan uitrekken enz..
Met een CNC-frees moet het mogelijk zijn om de parabool uit een massief blok aluminium (?) te halen, maar daar hangt ook weer een prijskaartje aan. Ook moet je dan rekening houden met resonantie etc..

Mijn idee is daarom ook om een klant en klare schotelantenne te gebruiken. Een perfect paraboloïde vorm tegen een realistischere prijs. (Schotelantennes zijn nog redelijk betaalbaar als je ze zonder ontvangunit koopt, die heb je toch niet nodig
Bijvoorbeeld artikelnummer 940586 - 8B bij Conrad; een 60cm schotel voor 19,95euro.)

Mijn inziens moet dit werken maar ik kan het ook helemaal fout hebben, gelieve dit dan (onderbouwd) te zeggen.

Over de USB interface; dit gaat erg moeilijk worden. Het is erg lastig om software compatible met het USB protocol te schrijven, helemaal 'from the scratch'

[ Voor 4% gewijzigd door Vermicellisoep op 10-07-2004 23:03 ]

[Verwijderd]

Vermicellisoep schreef op 10 juli 2004 @ 23:00:
Veel verstand heb ik er niet van, maar ik weet dat er aardig complexe berekeningen aan te pas komen om een mooie paraboloïde 'schotel' te maken. Plexiglas lijkt mij niet direct de meest eenvoudige oplossing, ik heb zelf al gemerkt dat dat heel moeilijk te buigen is, laat staan uitrekken enz..
Met een CNC-frees moet het mogelijk zijn om de parabool uit een massief blok aluminium (?) te halen, maar daar hangt ook weer een prijskaartje aan. Ook moet je dan rekening houden met resonantie etc..

Mijn idee is daarom ook om een klant en klare schotelantenne te gebruiken. Een perfect paraboloïde vorm tegen een realistischere prijs. (Schotelantennes zijn nog redelijk betaalbaar als je ze zonder ontvangunit koopt, die heb je toch niet nodig
Bijvoorbeeld artikelnummer 940586 - 8B bij Conrad; een 60cm schotel voor 19,95euro.)

Mijn inziens moet dit werken maar ik kan het ook helemaal fout hebben, gelieve dit dan (onderbouwd) te zeggen.

Over de USB interface; dit gaat erg moeilijk worden. Het is erg lastig om software compatible met het USB protocol te schrijven, helemaal 'from the scratch'

Ik weet niet wat je net bedoelt met de berekeningen maar dat mag normaal niet zo een probleem zijn. De twee vakken (Meetkunde en Analyse II) die handelen over paraboloïden bij ons ben ik alletwee voor geslaagd in 1e zit...meeste berekeningen kan ik daar omtrent dus wel doen.

Je hebt wel gelijk dat het misschien gewoon beter is om een pre-made parabool te kopen. Waarschijnlijk zal de kwaliteit daarvan die van een zelfgemaakte ver overschrijden. Het maakt het dan natuurlijk wel weer net dat beetje minder self-made, maar dat is muggenziften ntl

Over de USB-interface, dat dacht ik er ook van in eerste instantie, maar ik kreeg geleidelijk aan mijn twijfels. Weer in de FAQ las ik een pin-out van de USB-kabel. Hieruit maak ik op dat je de USB-kabel op dezelfde manier kan gebruiken als een printerkabel. Alleen het aanspreken in een programmeertaal is wat anders natuurlijk. Uiteraard leg ik mij er zonder veel discussie bij neer als een printerkabel veel makkelijker is als een USB-kabel.

[Verwijderd]

Verwijderd schreef op 10 juli 2004 @ 21:46:
[...]

Ik snap je berekeningen met het robotics-schema niet echt. Als ik versta wat je bedoelt zou jij een signaal laten uitsturen en dan eerst een rondje draaien voor je de echo opvangt. Dat lijkt me nogal gek. Volgens mij is de bedoeling signaal sturen, wachten op echo, dan pas draaien. Dan draai je zo snel of zo traag als je wil. Ik snap ook niet waar je aan die cyclus van 20 miliseconden komt, die hangt toch af van de afstand tot het voorwerp?

Als laatste wil ik, om verwarring te verhinderen, nog even opmerken dat de snelheid heel wat lager ligt dan 300km/s. We werken hier met geluid en niet licht dus een snelheid van "maar" 340m/s.

Hier omtrent: de 340 m/s is maar een benadering. De exacte snelheid van geluid in lucht is ook afhankelijk van temperatuur en druk. Wie is er voorstaander van de sonar van een temperatuursensor te voorzien, om op basis daarvan de correcte(re) snelheid te bepalen? Als we dat doen moet er wel rekening gehouden worden emt het feit dat dat een extra berekening betekend.
Als we voor de "makkelijkste" manier gaan [zie hierboven] is dat op zich niet zo erg moeilijk. Als de "mooiste" manier mogelijk is brengt dat misschien wel problemen met zich mee...

jij zegt signaal uitsturen, ontvangen en dan verder draaien. je weet toch niet van te voren hoe lang het gaat duren voordat je de echo terug krijgt (als je em terug krijgt..).
nog iets dat ik me zomaar even afvroeg, je krijgt op deze manier dus een "plat" beeld (alleen alle objecten ter hoogte van de zender/ontvanger) ?

[DiLDoG]

misschien dat dit handy is?

Ben zelf van plan ze te gebruiken voor een ultrasoon snelheidsmeter (dopplereffect)

[tafkaw]

Je kunt ook proberen een paraboloide (k*twoord ) zelf te gieten. door eerst een mal te maken in bv zand of beton ofzo...

[Verwijderd]

Verwijderd schreef op 10 juli 2004 @ 23:26:
[...]


jij zegt signaal uitsturen, ontvangen en dan verder draaien. je weet toch niet van te voren hoe lang het gaat duren voordat je de echo terug krijgt (als je em terug krijgt..).
nog iets dat ik me zomaar even afvroeg, je krijgt op deze manier dus een "plat" beeld (alleen alle objecten ter hoogte van de zender/ontvanger) ?

Inderdaad, je weet niet hoe lang het duurt, maar daarvoor werk je met een limiet-periode waarin de echo moet ontvangen worden. In het begin test je gewoon uit tot hoe ver je signaal maximaal draagt en op basis daarvan bepaal je dan hoe lang de sonar moet wachten op echo. Is er binnen die periode geen echo ontvangen, dan is er geen voorwerp gevonden en draai je verder.

Je krijgt inderdaad een plat beeld, maar zo werken de meeste radars / sonars ook. Je kan in principe nog naar 3d evolueren door de sonar ook in de hoogte rond te draaien, maar ik denk dat de tijd per omwenteling dan heel lang wordt en bovendien de software voor visualisatie een pak ingewikkelder.

[Verwijderd]

DiLDoG schreef op 11 juli 2004 @ 00:46:
misschien dat dit handy is?

Ben zelf van plan ze te gebruiken voor een ultrasoon snelheidsmeter (dopplereffect)

Die is inderdaad wel erg handig. Alleen kom ik er niet zo goed uit wat conrad nu net verkoopt. In de pdf vind ik informatie over zowel receiver als transmitter, maar op de site zelf (Conrad) kom het type nummer niet overeen met die in de pdf-file...Verkoopt conrad nu transmitter, receiver of beide
Never mind, ben er uit geraakt. Heel handig, voor ongeveer 10 euro heb je dus receiver en transmitter.

[ Voor 8% gewijzigd door Verwijderd op 11-07-2004 10:49 ]

[frickY]

Ben hier onlangs n VB-programmatje voor tegen gekomen die ik tegen kwam tijdens het zoeken naar een mogelijkheid om frequenties te meten.

Je meost dan gewoon je speaker en microfoon naast elkaar leggen (dezelfde kant op gericht) en hij genereerde dan een pieptoon, meette de tijd tot hij hiervan de echo opving, en gaf de afstand tot het voorwerp op het scherm aan.
Heb dit getest, en het werkte nog met de kast 2 meter naast me.

dit was een in Visual basic geschreven programmatje welke gebruik maakt van DirectSound. Zowel het werkende voorbeeld als de volledige source waren te downloaden. Kan het helaas niet terug vinden

[ Voor 47% gewijzigd door frickY op 11-07-2004 12:36 ]

[Verwijderd]

frickY schreef op 11 juli 2004 @ 12:23:
Ben hier onlangs n VB-programmatje voor tegen gekomen die ik tegen kwam tijdens het zoeken naar een mogelijkheid om frequenties te meten.

Je meost dan gewoon je speaker en microfoon naast elkaar leggen (dezelfde kant op gericht) en hij genereerde dan een pieptoon, meette de tijd tot hij hiervan de echo opving, en gaf de afstand tot het voorwerp op het scherm aan.
Heb dit getest, en het werkte nog met de kast 2 meter naast me.

dit was een in Visual basic geschreven programmatje welke gebruik maakt van DirectSound. Zowel het werkende voorbeeld als de volledige source waren te downloaden. Kan het helaas niet terug vinden

Zo een programma zou natuurlijk wel eens handig als referentie kunnen zijn. Kan je wat meer info geven over hoe je er op gekomen bent (mogelijke trefwoorden, Google of GoT of andere,...) dan zoek ik wat mee

[frickY]

Ik was opzoek naar n manier om een VisualBasic programmatje te schrijven waarmee ik de frequentie van een geluid kon meten.
Uit eindelijk kwam ik op een niet-opgemaakte pagina terrecht van iemand die een aantal programmatjes in VB in elkaar had geplakt met behulp van Directsound.

Voorbeelden van programams zijn een tonengenerator (tik n frequentie in en de toon komt uit je speakerS), een equalizer, dat sonar-ding dus, en nog wat andere grappige geluids-aanverwantte dingetjes.

Ik ben via google op die pagina terrecht gekomen na n aardig poosje gezocht te hebben. Kan me voorstellen dat mn zoektermen iets van "vb measure sound frequency" zijn geweest...
Op mn werk heb ik dat geluidgeneratortje nog.. pest nog steeds dagelijk mn collega's met 17000hz

edit:
w00t! Gevind; http://www.techmind.org/audio/
Ik zie alleen de download voor zn 'Acoustic Radar' niet meer staan
alleen dr staat wel iets erg interressant bij zn stukje text hierover! Vooral even lezen.
Google geeft ook wat kinky htis op 'Acoustic radar'

[ Voor 25% gewijzigd door frickY op 11-07-2004 15:55 ]

[Vermicellisoep]

Verwijderd schreef op 10 juli 2004 @ 23:16:
[...]

Ik weet niet wat je net bedoelt met de berekeningen maar dat mag normaal niet zo een probleem zijn. De twee vakken (Meetkunde en Analyse II) die handelen over paraboloïden bij ons ben ik alletwee voor geslaagd in 1e zit...meeste berekeningen kan ik daar omtrent dus wel doen.

Je hebt wel gelijk dat het misschien gewoon beter is om een pre-made parabool te kopen. Waarschijnlijk zal de kwaliteit daarvan die van een zelfgemaakte ver overschrijden. Het maakt het dan natuurlijk wel weer net dat beetje minder self-made, maar dat is muggenziften ntl

Over de USB-interface, dat dacht ik er ook van in eerste instantie, maar ik kreeg geleidelijk aan mijn twijfels. Weer in de FAQ las ik een pin-out van de USB-kabel. Hieruit maak ik op dat je de USB-kabel op dezelfde manier kan gebruiken als een printerkabel. Alleen het aanspreken in een programmeertaal is wat anders natuurlijk. Uiteraard leg ik mij er zonder veel discussie bij neer als een printerkabel veel makkelijker is als een USB-kabel.

Oke, volgens mij gaat het met de berekeningen omtrent de paraboloïde wel lukken zo te horen
De kwaliteit van een zelfgemaakte schotel op ons niveau (huiskamer en 't schuurtje achter als werkplaats) kan gewoon niet tippen aan een pre-made ding, al is dat wel jammer. Gewoon het ding helemaal inpakken in ducktape en iedereen zal zeggen dat je het zelf gemaakt hebt

Op het gebied van programmeren en poortaansturing heb ik heel weinig ervaring maar ik kan wel opmaken uit veel toppics hier op GoT dat het een stuk moeilijker is dan de paralelle of seriële poort.
Als iemand denkt: "Onzin, ik kan dat wel!" meld je maar

[Viva Vince]

In mijn eerste jaar van Technische Natuurkunde op de TU/e is er een OGO project geweest wat als doel had objecten te kunnen detecteren op een tafel van 3 bij 3(als ik het me goed herinner). Volgens mij was dit wel een succes geworden. Hun resolutie was ook nog redelijk ( paar cm onzekerheid op een meter).

Hun princiepe was echter om gebruik te maken van meerdere microphoons en door het tijdsverschil te meten de positie te bepalen(net zoals GPS maar dan met geluid ). Verder maakten ze gebruik van de doppler shift van het geluid om de snelheid van het voorwerp te bepalen.

Als data aquisitie systeem is gebruik gemaakt van een PhyDas crate, met een zooi ADC's en DAC's, die aangestuurd werd door wat c++ programmatuur. Uiteraard is dat de mooiste situatie, echter ik denk dat je wel een redelijk nauwkeurige ADC moet hebben om er iets mee te kunnen. Ik denk dus dat de ADC van je paralelle/serieele poort niet snel genoeg is, en ook niet nauwkeurig genoeg. Dus het word waarschijnlijk zelf een ADC knutselen ipv die je pc al heeft.

Ik weet niet of je/jullie het interessant vinden om het verslag van dit project in handen te krijgen? Ik heb toen zelf een ander project gedaan maar als er interesse naar is kan ik wel ff rondvragen of iemand het verslag nog heeft.

Geluidskaart gaat idd ook niet lukken voor ultra-soon, maar in princiepe hoeft het ook niet ultra-soon te zijn. De enige rede dat je hoge frequenties wilt is de korte golflengte dat je een hogere resolutie haalt lijkt mij zo.

[ Voor 23% gewijzigd door Viva Vince op 11-07-2004 17:53 ]

[Verwijderd]

Over de paraboloïde:
Hoe wou je dat precies gaan doen? Ontvanger en zender in 1 grote paraboloïde? Of allebei apart?
In het eerste geval zit je met het probleem dat hij de echo die vanaf de paraboloïde zelf terugkomt zal zien als een obstakel, en in het tweede geval zal hij zeer kleine afstanden niet kunnen detecteren omdat de ontvangerparaboloïde het signaal van de zenderparaboloïde niet kan ontvangen omdat deze naast elkaar staan.
Je zult dan dus in ieder geval de eerste manier moeten gebruiken, en om dat te doen moet je de firmware van je sonar aanpassen zodat hij de eerste paar ms of ns (heb geen flauw idee van de orde van grootte van zo'n meting) alle echo's negeert.

Over USB: Ik weet er niet al teveel vanaf, maar volgens mij moet je voor een usb apparaat in ieder geval een usb client IC inbouwen in je apparaat, en zelf een driver schrijven (die hebben usb apparaten nou eenmaal nodig). Er zijn natuurlijk ook dingetjes verkrijgbaar van conrad bijv, waarbij je een soort printerpoort aan een usb snoertje krijgt. In dat geval is de driver dus al voor je geschreven en zit je ook niet meer te kloten met usb client ICs, maar ik heb het idee dat dat klauwen vol geld gaat kosten. Als ik jullie was zou ik voor het I2C protocol via de com-poort gaan. Lekker makkelijk (2 i/o lijntjes nodig) en vrijwel 100% betrouwbaar omdat je niet vast zit aan een bepaalde timing. Enige probleem is dat je niet de volle bandbreedte van de lijn kunt gebruiken, maar zoveel data hoeft die sonar nou ook weer niet over te pompen.

-edit-
@post hierboven:
Geluidskaart lijkt me geen goed plan, maximale samplerate van een geluidskaart is 48khz, dus je zult maximaal een 24khz signaal kunnen detecteren (wat volgens mij minder is dan ultrasoon geluid, maar zelfs dat kan ie niet 100% betrouwbaar), en doppler shift kun je wel helemaal op je buik schrijven

[ Voor 11% gewijzigd door Verwijderd op 11-07-2004 17:44 ]

[Verwijderd]

Mijn idee is een sonar bouwen naar het ontwerp van een radar. Dus 1 parabool waarop zowel microfoon als luidspreker zitten.

In de bovenstaande post klopt het inderdaad dat er dan ook echo optreedt van de parabool zelf. Dit valt op te lossen door de microfoon af te zetten zolang de enige mogelijke echo die van de parabool zelf is. Des noods doe je dat niet fysisch maar zeg je gewoon programmatisch dat de eerste signalen genegeerd moeten worden. Hiervoor zou ik ook graag de mening weten van sebastius als hij nog mee wilt doen nu hij weet dat mijn elektronica-kennis minimaal is .

Misschien is dit nu wel een geschikt moment om een paar vragen te beantwoorden en een stap verder te gaan:
• Proberen we toch zelf een parabool te produceren, of kopen we een pre-made?
• Gebruiken we printerpoort of com-poort voor aansturing? Dat USB niet makkelijk is en nodeloos veel inspanning zal kosten is duidelijk
• Is het mogelijk om de sonar op een "mooie" manier te maken? Dus de berekeningen worden door de sonar zelf gedaan en enkel de resultaten worden naar pc doorgestuurd. Of doen we het op de "simpele" manier?

Deze laatste vraag is een vraag waar volgens mij vooral de elektronica-specialisten op kunnen antwoorden daar zij wat meer weten wat kan en niet kan. Ik vraag hen zeker niet om het uit te werken of zo, enkel een "het is mogelijk" of "het is quasi onmogelijk" is momenteel voldoende denk ik

Nog even over de link die hier iets boven staat. Die programma's zijn inderdaad interessant, vooral als we voor de "simpele" manier zouden gaan kan dat van pas komen. Anderzijds zijn zijn bemerkingen over sonar ook handig. Ik denk echter dat bij ons heel wat van zijn problemen wegvallen. Van wat ik versta heeft hij vooral problemen met resonantie van luidspreker en microfoon en omgevingsgeluid. Hij gebruikt echter in zijn project een normale pc met speaker en microfoon.
Ik zou zelf voorstellen om de ultrasone transmitter en receiver van op Conrad te gebruiken. De resonantie die daar in optreedt zal waarschijnlijk veel minder zijn. Bovendien reageert (denk ik toch) de receiver enkel op signalen in de buurt van het ultrasone geluid. Dat is volgens mij geen "standaard" omgevingsgeluid, dus het terugvinden van je eigen signaal zal ook niet zo'n probleem vormen denk ik. Dit is echter wat ik er van denk, bemerkingen zijn uiteraard altijd welkom.

Ten slotte: voor bovenstaande vragen is een poll misschien interessant. Ik zag in diverse topics poll's , kan iemand me zeggen hoe je dat doet? Dan maak ik een poll aan voor de vragen en kunnen we zo zien wat we uiteindelijk doen.

[ Voor 3% gewijzigd door Verwijderd op 11-07-2004 18:41 ]

[Verwijderd]

Hierbij dus de polls. Iedereen is uiteraard vrij om te stemmen, maar stem wel serieus aub. Ik laat deze polls een tijdje open en nadien sluit ik ze af zodat we een stap verder staan in het proces.

Poll: Hoe maken we de parabool?
• Zelf proberen maken
• Kopen

^{Ook een poll maken? Klik hier}

Poll: Welke verbinding tussen sonar en PC?
• Printerpoort
• COM-poort
• Toch USB proberen

^{Ook een poll maken? Klik hier}

Poll: Hoe maken we de sonar zelf?
• De simpele manier. PC doet alles.
• De mooie manier. Sonar doet alles.

^{Ook een poll maken? Klik hier}

[ Voor 10% gewijzigd door Verwijderd op 11-07-2004 18:42 ]

[Vermicellisoep]

Vergeet niet dat als je voldoende rijkwijdte hebt de kleine afstanden juist moeilijk gaan worden, daarom zou ik ervoor kiezen om de pc het rekenwerk te laten doen. Anders moet je ook weer aan de slag met snelle pics enzo en daar hangt ook een prijskaartje aan.

Iemand al enig idee over hou zelf een zuivere paraboloïde te maken?
_{m.i. is het geen optie maar we wachten wel af}

[Verwijderd]

Ik zou zeker voor de mooie manier gaan, het is enorm makkelijk om met een programmeerbaar ICtje (20mhz moet genoeg zijn) véél preciezer het signaal te meten dat van de sonar module afkomt te meten dan wat ooit mogelijk zal zijn met een computer die staat te multitasken, en de lengte van het signaal dan 'op zn gemak' als een waarde doorstuurt naar de computer. Zo voorkom je ook dat het programma 100% cpu tijd staat te gebruiken omdat hij wacht op het begin/einde van het signaal.

[ExploWare]

Plexiglas is weldegelijk te buigen
Je moet een harde mal hebben, van staal bijv.
Daarover kan je het vacuum zuigen, moet het wel warm zijn
Ik heb het zelf nog nooit gedaan, maar een vriend van mij is 3D vormgever, en op zn school doet die dat soort dingen

[Verwijderd]

Vermicellisoep schreef op 11 juli 2004 @ 19:47:
Vergeet niet dat als je voldoende rijkwijdte hebt de kleine afstanden juist moeilijk gaan worden, daarom zou ik ervoor kiezen om de pc het rekenwerk te laten doen. Anders moet je ook weer aan de slag met snelle pics enzo en daar hangt ook een prijskaartje aan.

Iemand al enig idee over hou zelf een zuivere paraboloïde te maken?
_{m.i. is het geen optie maar we wachten wel af}

Hier snap ik het verband tussen de afstanden en berekening niet. De berekening blijft toch dezelfde, om het even over welke afstand het gaat?

Voor de paraboloide zelf heb ik ook nog geen idee hoe dat zou kunnen. Ik bedenk net wel iets dat misschien handig kan zijn.
Met elektriciteit is een raster in metaal voldoende om de elektriciteit tegen te houden om door het raster te gaan. Misschien bestaat een gelijkaardig fenomeen met geluidsgolven (dat eens het raster klein genoeg is, geluidsgolven overwegend weerkaatst worden en niet door gaan). Dan is het genoeg om een raster te maken in de vorm van een paraboloide. Dat is op zich wat makkelijker te maken, je moet dan enkel een paar parameter-krommen te vormen om een parabool te hebben.

[Verwijderd]

Verwijderd schreef op 11 juli 2004 @ 19:47:
Ik zou zeker voor de mooie manier gaan, het is enorm makkelijk om met een programmeerbaar ICtje (20mhz moet genoeg zijn) véél preciezer het signaal te meten dat van de sonar module afkomt te meten dan wat ooit mogelijk zal zijn met een computer die staat te multitasken, en de lengte van het signaal dan 'op zn gemak' als een waarde doorstuurt naar de computer. Zo voorkom je ook dat het programma 100% cpu tijd staat te gebruiken omdat hij wacht op het begin/einde van het signaal.

Ik zou ook heel graag voor de mooie manier gaan. Kan je me een idee geven wat zo een programmeerbaar IC kost? Ik zocht net op Conrad rond maar vond niet echt veel. Kan je ook wat info geven (links of zo) over hoe je net programmeert?

[Verwijderd]

Nog even een poll, de vraag stond ook in een van de eerste posts maar werd niet beantwoord:
Hoe bepalen we de geluidssnelheid? Zijn we tevreden met 340 m/s of bepalen we de snelheid exact(er) door de temperatuur te meten?

Poll: Hoe bepalen we de snelheid van het geluid?
• 340 m/s gewoon
• Afhankelijk van de temperatuur

^{Ook een poll maken? Klik hier}

[Verwijderd]

Verwijderd schreef op 11 juli 2004 @ 21:47:
[...]

Ik zou ook heel graag voor de mooie manier gaan. Kan je me een idee geven wat zo een programmeerbaar IC kost? Ik zocht net op Conrad rond maar vond niet echt veel. Kan je ook wat info geven (links of zo) over hoe je net programmeert?

Van een programmeerbare IC zoals de 16F84A van microchip kun je gewoon samples bestellen, dus dat kost niks (ook geen verzendkosten). Het ding draait op 20mhz (1 instructie per 4 cycles, dus effectief heb je 5mhz), en programmeren moet je eigenlijk wel in assembly doen zodat je weet hoe lang een stuk van je programma precies duurt om uitgevoerd te worden. Een goeie tutorial vind je hier, en als je die doorgenomen hebt kun je alles wel snappen wat er in de datasheet staat.

Nog een tip voor als je samples gaat bestellen: Je hebt de PDIP versie nodig (tenzij je smd wilt solderen) van 20mhz. Je kunt er maar 3 tegelijk van 1 type bestellen, dus een goeie keus is als je 3x een PIC16F84A-20/P bestelt en 3x een PIC16F84A-20I/P. Het enige verschil tussen deze twee is dat de een van 0 tot +70°C werkt en de ander van -40 tot +80°C.

Verder zul je ook nog iets met een MAX232 moeten doen om het signaal van de compoort in een TTL-signaal om te zetten, maar daar heb ik verder weinig verstand van.


=edit=

Als je een temperatuursensor wilt inbouwen zou ik dat met bijvoorbeeld deze sensor doen, of in ieder geval een soortgelijke (met I²C interface), aangezien I²C enorm makkelijk aan te sturen is met een PIC. Mocht je nog code willen om via dat protocol te communiceren, heb ik nog wel een stukje code voor je liggen.

[ Voor 13% gewijzigd door Verwijderd op 11-07-2004 22:18 ]

[Vermicellisoep]

Verwijderd schreef op 11 juli 2004 @ 21:44:
[...]

Hier snap ik het verband tussen de afstanden en berekening niet. De berekening blijft toch dezelfde, om het even over welke afstand het gaat?

[..verhaaltje..]

Tegen de tijd dat die pic het signaal naar het piezoelement (oid) heeft verzonden krijgt hij onderhand al een signaal van de microfoon terug als de afstand te klein is. Het hangt van de snelheid van de pic af of hij alles kan verwerken of niet.
Uitgaande van een object op 2 meter afstand heeft de pic 0,00588 seconde tussen de 2 signalen, ik weet niet of dat genoeg is...
_{Correct me als ik loop te blaten}

[Verwijderd]

Je berekening klopt niet vermicellisoep, bedenk wel dat het signaal heen én terug moet. 0,00588sec is dus voor 1 meter de interval.

1 instructie van een PIC die op 20mhz draait duurt 0,0000002 sec. Stel dat je voor de gemiddelde time-en-check-loop 15 instructies nodig hebt (wat al aan de hoge kant is), dan heb je een resolutie van 0,000003 sec. 340*0,000003 = 0,00102 meter, gedeeld door 2 omdat het signaal heen en terug moet, is een resolutie (en minimale afstand) van 0,00051 meter, oftewel 0,51mm. De PIC is dus zéker niet de limiterende factor voor bereik/precisie.
<sub>Correct me als ik nog harder loop te blaten

Nee, ik heb niks te doen</sub>

[ Voor 10% gewijzigd door Verwijderd op 11-07-2004 22:49 ]

[Verwijderd]

Verwijderd schreef op 11 juli 2004 @ 22:08:
[...]


Van een programmeerbare IC zoals de 16F84A van microchip kun je gewoon samples bestellen, dus dat kost niks (ook geen verzendkosten). Het ding draait op 20mhz (1 instructie per 4 cycles, dus effectief heb je 5mhz), en programmeren moet je eigenlijk wel in assembly doen zodat je weet hoe lang een stuk van je programma precies duurt om uitgevoerd te worden. Een goeie tutorial vind je hier, en als je die doorgenomen hebt kun je alles wel snappen wat er in de datasheet staat.

Nog een tip voor als je samples gaat bestellen: Je hebt de PDIP versie nodig (tenzij je smd wilt solderen) van 20mhz. Je kunt er maar 3 tegelijk van 1 type bestellen, dus een goeie keus is als je 3x een PIC16F84A-20/P bestelt en 3x een PIC16F84A-20I/P. Het enige verschil tussen deze twee is dat de een van 0 tot +70°C werkt en de ander van -40 tot +80°C.

Verder zul je ook nog iets met een MAX232 moeten doen om het signaal van de compoort in een TTL-signaal om te zetten, maar daar heb ik verder weinig verstand van.


=edit=

Als je een temperatuursensor wilt inbouwen zou ik dat met bijvoorbeeld deze sensor doen, of in ieder geval een soortgelijke (met I²C interface), aangezien I²C enorm makkelijk aan te sturen is met een PIC. Mocht je nog code willen om via dat protocol te communiceren, heb ik nog wel een stukje code voor je liggen.

Héhé, net gedaan met de tutorial door te lezen, lekker boeiend , die zet ik meteen in de topicstart bij de links. Er zijn nog een paar dingen die niet volledig duidelijk zijn, maar dat komt nog wel. Zeker handig om weten dat dit bestaat, geeft me een beter zicht op de haalbaarheid van het "mooie" systeem.

Morgen kijk ik verder naar die I²C en dat van dat TTL signaal, want dat begrijp ik niet 100%.

[Rey Nemaattori]

Verwijderd schreef op 11 juli 2004 @ 21:50:
Nog even een poll, de vraag stond ook in een van de eerste posts maar werd niet beantwoord:
Hoe bepalen we de geluidssnelheid? Zijn we tevreden met 340 m/s of bepalen we de snelheid exact(er) door de temperatuur te meten?

Poll: Hoe bepalen we de snelheid van het geluid?
• 340 m/s gewoon
• Afhankelijk van de temperatuur
[afbeelding]
^{Ook een poll maken? Klik hier}

Geluidsnelheid hangt eigenlijk af van de dichtheid van de stof waar het doorheen reist, aangezien deze bij gassen in een atmosfeer afhangt van de luchtemperatuur(luchtdrukschommelingen door het weer zijn minimaal en kun je buiten beschouwing laten) en dat kan toch echt wel enkele meters tot tientallen meters schelen op grote afstanden.

Houd er wel rekening mee dat drieren zoals bijvoorbeeld honden en katten een VEEL hoger beriek hebben dan mensen, nog maar niet te spreken over vleermuizen tot tot 200khz kunnen horen... voor hen is je apparaat net alsof een of andere mongool een 800w bouwlamp in je face zet @ night....


BTw waarom is een radar illegaal? iedereen mag toch een apparaat maken dat radiogolven uitzendt of opvangt zolang je er niemand mee stoort...(niet dat waneer jij je device aanzet alle radioapparatuur in een straal van 1km alleen nog maar ruis hebben )

Of je die radio golven nu gebruikt om een bericht de lucht in te zenden of hoopt dat de golven terugkaatsen op een betonnen of metalen plaat... dat maakt tog geen hol uit...(je moet natuulijk geen gigantisch oplichtend punt op de radar worden van defensie )

Verwijderd schreef op 10 juli 2004 @ 23:26:
[...]


jij zegt signaal uitsturen, ontvangen en dan verder draaien. je weet toch niet van te voren hoe lang het gaat duren voordat je de echo terug krijgt (als je em terug krijgt..).
nog iets dat ik me zomaar even afvroeg, je krijgt op deze manier dus een "plat" beeld (alleen alle objecten ter hoogte van de zender/ontvanger) ?

Je zult sowieso een plat beeld krijge, zo'n beetje wat je krijgt als je met 1 gesloten oog en een zaklamp in een grto rondraait. Ervaring zal je diepte laten zien, zelfde met 1 oog, maar eigenlijk zie je alleen een mooi 2-d plaatje

Wil je 'diepte' zien zul je 2 sondar op 1 punt moeten richten en met driehoeksverhoudingen moeten meten, maar dit zijn al vele tientallen stappen geavanceerder dan de TS initieel bedoelde: het afatand bepalen tot objecten omzich heen. Er is nog helemaal geensprake van het maken van beelden of zelfde maar 3d vision...

Verwijderd schreef op 11 juli 2004 @ 09:42:
Inderdaad, je weet niet hoe lang het duurt, maar daarvoor werk je met een limiet-periode waarin de echo moet ontvangen worden. In het begin test je gewoon uit tot hoe ver je signaal maximaal draagt en op basis daarvan bepaal je dan hoe lang de sonar moet wachten op echo. Is er binnen die periode geen echo ontvangen, dan is er geen voorwerp gevonden en draai je verder.

Je krijgt inderdaad een plat beeld, maar zo werken de meeste radars / sonars ook. Je kan in principe nog naar 3d evolueren door de sonar ook in de hoogte rond te draaien, maar ik denk dat de tijd per omwenteling dan heel lang wordt en bovendien de software voor visualisatie een pak ingewikkelder.

Wil je wel visualiseren dan? Of wil je aleen de afstand meten? Visualiseren is sowieso een flink stuk moeilijker( wel interesanter though ) en aan een 3d beeld zou ik niet eens beginnen als ik jou was, da's veels te ingewikkeld.

Vermicellisoep schreef op 11 juli 2004 @ 19:47:
Vergeet niet dat als je voldoende rijkwijdte hebt de kleine afstanden juist moeilijk gaan worden, daarom zou ik ervoor kiezen om de pc het rekenwerk te laten doen. Anders moet je ook weer aan de slag met snelle pics enzo en daar hangt ook een prijskaartje aan.

Iemand al enig idee over hou zelf een zuivere paraboloïde te maken?
_{m.i. is het geen optie maar we wachten wel af}

Neem een grote tupperwarebak, vul deze met warme lucht en span er een stuk keukenfolie overheen zodat het zaakje luchtdicht afgesloten word. Als de lucht afkoelt zal deze minder ruimte in nemen en de luchtdruk het plastic in een mooie paraboolvorm drukken. Nu alleen nog een manier vinden hier iets moois van te maken(lees een hard iets).

[ Voor 44% gewijzigd door Rey Nemaattori op 12-07-2004 01:36 ]

[Verwijderd]

Verwijderd schreef op 12 juli 2004 @ 00:53:
[...]

Héhé, net gedaan met de tutorial door te lezen, lekker boeiend , die zet ik meteen in de topicstart bij de links. Er zijn nog een paar dingen die niet volledig duidelijk zijn, maar dat komt nog wel. Zeker handig om weten dat dit bestaat, geeft me een beter zicht op de haalbaarheid van het "mooie" systeem.

Morgen kijk ik verder naar die I²C en dat van dat TTL signaal, want dat begrijp ik niet 100%.

TTL verhaal is heel simpel eigenlijk:
PIC gebruikt TTL signalen, dwz dat: binaire '1' is 5v, binaire '0' is 0v
Je compoort echter gebruikt RS232 signalen: binaire '1' is +10v, binaire '0' is -10v (voltage kan geloof ik ergens tussen 3 en 10v liggen, weet ik niet precies).
Als je dat dus direct aan je PIC hangt blaas je het ding op, vandaar dat er iets tussen moet. Chipje dat vaak gebruikt wordt om dat te doen is de MAX232 van Maxim

[Verwijderd]

Rey Nemaattori schreef op 12 juli 2004 @ 01:20:
[...]


Geluidsnelheid hangt eigenlijk af van de dichtheid van de stof waar het doorheen reist, aangezien deze bij gassen in een atmosfeer afhangt van de luchtemperatuur(luchtdrukschommelingen door het weer zijn minimaal en kun je buiten beschouwing laten) en dat kan toch echt wel enkele meters tot tientallen meters schelen op grote afstanden.

Ik denk dat de poll overtuigend genoeg zal zijn om uiteindelijk voor een extra temperatuurssensor te kiezen. Hou er wel rekening mee dat het effect niet zo "indrukwekkend" zal zijn. Zoals je zelf zegt kan het enkele meters tot tientallen meters shelen, maar dan wel op grote afstanden, en die gaan we (waarschijnlijk) niet kunnen bereiken. Het is echter wel wat wetenschappelijk interessanter uiteraard.

Houd er wel rekening mee dat drieren zoals bijvoorbeeld honden en katten een VEEL hoger beriek hebben dan mensen, nog maar niet te spreken over vleermuizen tot tot 200khz kunnen horen... voor hen is je apparaat net alsof een of andere mongool een 800w bouwlamp in je face zet @ night....

Daar heb je wel volledig gelijk natuurlijk. Ik ga vandaag eens op zoek gaan naar het gemiddeld gehoor van katten en honden, hopelijk zit het ultrasoon signaal (dat van de Conrad-componenten) hier boven en hebben die beesten er geen last van. Vleermuizen zijn een andere zaak, maar de sonar heeft niet echt een praktisch nut en zal dus niet continu aan staan. Die vleermuizen zullen dus niet te veel last ondervinden denk ik.

BTw waarom is een radar illegaal? iedereen mag toch een apparaat maken dat radiogolven uitzendt of opvangt zolang je er niemand mee stoort...(niet dat waneer jij je device aanzet alle radioapparatuur in een straal van 1km alleen nog maar ruis hebben )

Of je die radio golven nu gebruikt om een bericht de lucht in te zenden of hoopt dat de golven terugkaatsen op een betonnen of metalen plaat... dat maakt tog geen hol uit...(je moet natuulijk geen gigantisch oplichtend punt op de radar worden van defensie )

Waarom het exact illegaal is weet ik niet, maar het komt er op neer dat je niet zomaar je eigen radio-uitzending mag beginnen. Daar bovenop mag je vanaf een declinatie van 10 graden of zo, zeker geen radio meer uitzenden. Je zou maar eens van slechte wil zijn en je radar gebruiken om elke commerciele vlucht uit de lucht te halen...

[...]


Je zult sowieso een plat beeld krijge, zo'n beetje wat je krijgt als je met 1 gesloten oog en een zaklamp in een grto rondraait. Ervaring zal je diepte laten zien, zelfde met 1 oog, maar eigenlijk zie je alleen een mooi 2-d plaatje

Wil je 'diepte' zien zul je 2 sondar op 1 punt moeten richten en met driehoeksverhoudingen moeten meten, maar dit zijn al vele tientallen stappen geavanceerder dan de TS initieel bedoelde: het afatand bepalen tot objecten omzich heen. Er is nog helemaal geensprake van het maken van beelden of zelfde maar 3d vision...


[...]


Wil je wel visualiseren dan? Of wil je aleen de afstand meten? Visualiseren is sowieso een flink stuk moeilijker( wel interesanter though ) en aan een 3d beeld zou ik niet eens beginnen als ik jou was, da's veels te ingewikkeld.

3D visualiseren zou ik zeker niet aan beginnen. Zoals ik al vermelde maakt dat de sonar heel wat trager. Bovendien zal je vaak een nutteloos beeld krijgen, tenzij je heel ver gaat. Als je elk voorwerp groen zou kleuren op je scherm, dan krijg je in een normale kamer gewoon een groen scherm. Je zou dan al op basis van afstand de kleur moeten bepalen etc. Hoe dan ook 3D gaat wat boven de bedoeling.
2D visualiseren is volgens mij echter helemaal niet zo moeilijk. Zoals ik al zei toen het over het "mooie" of "simpele" systeem ging zal je op elk moment ook de orientatie van de parabool kennen. Als je de afstand kent tot het voorwerp en de orientatie van de parabool dan is visualisatie meteen gedaan. Gewoon gebruik maken van poolcoördinaten (wat aangepast wel, maar dat is niet zo moeilijk) en je krijgt een standaard (tv-)radar-beeld.
De bedoeling is dus afstand en snelheid van voorwerpen bepalen en op basis daarvan door computer visualisatie laten doen.

[...]


Neem een grote tupperwarebak, vul deze met warme lucht en span er een stuk keukenfolie overheen zodat het zaakje luchtdicht afgesloten word. Als de lucht afkoelt zal deze minder ruimte in nemen en de luchtdruk het plastic in een mooie paraboolvorm drukken. Nu alleen nog een manier vinden hier iets moois van te maken(lees een hard iets).

Dat wist ik niet maar is uiteraard wel interessant. Misschien is er een mogelijkheid om hetzelfde te doen met heel heet metaal?

[frickY]

Volgens mij heeft niemand de informatie gelezen die ik in deze post heb gegeven; http://gathering.tweakers...message/21192746#21192746 Onderin staat een linkje.

Daaruit kan je leren dat er veel meer bij komt kijken dan een geluid genereren, en naar de echo luisteren, zoals het wegfilteren van ruis.

[Verwijderd]

frickY schreef op 12 juli 2004 @ 11:53:
Volgens mij heeft niemand de informatie gelezen die ik in deze post heb gegeven; http://gathering.tweakers...message/21192746#21192746 Onderin staat een linkje.

Daaruit kan je leren dat er veel meer bij komt kijken dan een geluid genereren, en naar de echo luisteren, zoals het wegfilteren van ruis.

Wel degelijk gelezen en zelf op gereplyd _{(toegegeven, in een algemene reply, sorry)}.
Ik heb gezien dat in die link de maker nogal problemen ondervindt met het terugvinden van zijn eigen signaal. Dat is een normaal probleem...als je met gewoon geluid werkt. Met gewoon geluid heb je inderdaad het probleem dat je moeilijk kan onderscheiden wat de echo is en wat omgevingsgeluid is.

Echter, in een van de voorgaande reply's stond een link naar Conrad waar een ultrasone receiver en transmitter te koop zijn. Als ik een beetje goed snap wat er daar gebeurt gaat het daar als volgt:

- Stuur stroom door de transmitter en de transmitter begint ultrasoon geluid uit te zenden.
- Zend ultrasoon geluid uit en de receiver begint stroom uit te zenden.

Als dat het geval is trek ik daar 2 besluiten uit:
1. De receiver reageert enkel op ultrasoon geluid
2. Problemen met het wegfilteren van ruis verdwijnen omdat omgevingsgeluid nooit (zeg nooit nooit, maar toch) ultrasoon is. Het enige geluid dat de receiver kan ontvangen is de echo.

Als dit allemaal klopt ontlopen we dus de problemen die je hebt bij gebruik van normaal geluid.

[pienk]

Al jullie een makkelijke USB oplossing zoeken kun je een chip van dit bedrijf gebruiken:
http://www.ftdichip.com/
Hier hebben ze USB chips inclusief complete drivers.
Succes met het porject.

[mozinator]

ik heb een verzamel pagina gemaakt, met wat linkjes

http://mozilla.falconey.net/gotsonar.htm

[ Voor 125% gewijzigd door mozinator op 12-07-2004 14:47 ]

[Verwijderd]

Uit voorgaande post kreeg ik het gevoel dat er toch wat meer vraag is naar het Doppler-effect dan wat er in de startpost staat (toegegeven, daar staat amper iets in ). Ik heb me even bezig gehouden met het afleiden van de correcte formules voor de sonar. Tekst en uitleg staat hier.

[ Voor 1% gewijzigd door Verwijderd op 12-07-2004 15:31 . Reden: Foutje in link ]

[Vermicellisoep]

Rey Nemaattori schreef op 12 juli 2004 @ 01:20:

[bladiebla]

[...]

Neem een grote tupperwarebak, vul deze met warme lucht en span er een stuk keukenfolie overheen zodat het zaakje luchtdicht afgesloten word. Als de lucht afkoelt zal deze minder ruimte in nemen en de luchtdruk het plastic in een mooie paraboolvorm drukken. Nu alleen nog een manier vinden hier iets moois van te maken(lees een hard iets).

Volgens mij moet dat ook te doen zijn met een gat in de onderkant en een stofzuiger op een lage stand met een stuk schuimrubber erop ofzo.


^{Het schuimrubber zorgt ervoor dat je zo min mogelijk flow krijgt en een zo gelijkmatig mogelijke daling van de luchtdruk}
Om deze manier is ook de waarde van x in y=x² te regelen.

[Verwijderd]

Vermicellisoep schreef op 12 juli 2004 @ 15:14:
[...]


Volgens mij moet dat ook te doen zijn met een gat in de onderkant en een stofzuiger op een lage stand met een stuk schuimrubber erop ofzo.

[afbeelding]
^{Het schuimrubber zorgt ervoor dat je zo min mogelijk flow krijgt en een zo gelijkmatig mogelijke daling van de luchtdruk}
Om deze manier is ook de waarde van x in y=x² te regelen.

Ja het principe lijkt me te kloppen...probleem blijft dat zoiets enkel realistisch doenbaar is met vicieuze stoffen. Voor de parabool denk ik echter dat dit niet (meteen) tot de oplossing zal leiden.

Een andere mogelijkheid waar ik op kwam is het volgende:
zoals reeds voorgesteld kopen we gewoon een paraboloide. Dan zijn we zeker dat hij perfect is. Nadien "modden" we hem tot een GoT-parabool. Ik dacht zelf aan gewoon zwart spuiten en op binnenkant het logo van GoT spuiten over het hele oppervlak. Het is maar een idee natuurlijk.

Kan iemand trouwens wat normale prijzen voor printplaten posten? Ik heb wat gezocht op bedrijven hier in België die dat doen, maar de prijs voor 1 printplaat ligt nogal hoog, 35 euro vind ik schandalig veel voor een print van 2x2 cm. Uiteraard daalt deze prijs wel naarmate je er meer besteld.
Hoe veel mensen zijn er eigenlijk van plan om zelf ook de sonar te (proberen) maken? Als er meerdere zijn die de sonar voor zichzelf willen maken stel ik namelijk een groepsaankoop van de onderdelen voor, dat maakt alles toch net wat goedkoper. Wil iedereen die er zelf een wil maken mij mailen (adres in profile), dan heb ik een idee van prijzen?

Nog even vermelden, bovenstaande reply verscheen ongeveer gelijktijdig met mijn reply op pagina 2. Mensen die de laatste reply daar dus niet zagen, ga ff kijken, er staat info over het doppler-effect en de formule voor de sonar hier.

[Yoeri]

een paraboolvorm wordt volgens mij eenvoudigst gemaakt door bvb een hars-oplossing in een centrifuge te gieten en te laten stollen terwijl de centrifuge draait

niet zo moeilijk als je over een centrifuge kunt beschikken en een geschikt product vindt om je parabool van te maken

[mozinator]

printplaten ets ik op school, alleen dubbelzijdig en busjes gaat niet

[Verwijderd]

L@aF schreef op 12 juli 2004 @ 18:14:
printplaten ets ik op school, alleen dubbelzijdig en busjes gaat niet

Wel praktisch dat je dat kan (als je dat wil doen ntl)...maar is het nu niet zoiets dat men "vakantie" noemt? Dan ga je toch niet echt naar school, of doe je avondschool?

[mozinator]

Verwijderd schreef op 12 juli 2004 @ 18:19:
[...]

Wel praktisch dat je dat kan (als je dat wil doen ntl)...maar is het nu niet zoiets dat men "vakantie" noemt? Dan ga je toch niet echt naar school, of doe je avondschool?

pas in september begint de school weer, dus etsen kan dan

[Brothar]

Over 't meenemen v/h Doppler-effect bij gebruik v/h Conrad-bouwsetje: als je de gebruiksaanwijzing leest, zie je dat dit werkt bij (ongeveer) 40 kHz; m.a.w.: de ontvangst staat "ingeregeld" op dezelfde golflengte.
Het lijkt me dat bewegende voorwerpen vanaf een bepaalde snelheid niet opgemerkt worden (omdat de frequentie door het Doppler-effect buiten de mogelijk te ontvangen frequenties valt).

Overigens, een project als het bedoelde staat in een engels-talig hobby-blad. Een paar jaar terug was ik daar in geïnteresseerd, en heb het dus aangeschaft, ebenals het Conrad-setje.
Het Conrad-setje heb ik nooit werkend gekregen (waarschijnlijk iets te sterk verhit bij het solderen). Het project uit Electronics Now was me te kostbaar.

De paar jaar terug blijkt 11 jaar te zijn: het gaat om Electronics Now, September 1993, blz. 31. Project: "Build an Ultrasonic Radar Station", ondertitel "and keep tabs on your surroundings!", door ene Ronald M. Jackson.


Onderdelen: zender en ontvanger van een polaroid camera, een stapper motor, en een eerder door het blad geplaatste interface-board. Uitlezing gebeurde door een QBasic programma, zeer waarschijnlijk op een 486-PC (486-er wordt genoemd in de inleiding van het artikale).
In het bouwschema worden 2 IC's gebruikt, met als opschrift "SN28784 PID614908, resp. TL851 PID614904".

[ Voor 37% gewijzigd door Brothar op 12-07-2004 19:03 . Reden: opnemen verwijzing juste tijdschrift-artikel ]

[mozinator]

Brothar schreef op 12 juli 2004 @ 18:50:
Over 't meenemen v/h Doppler-effect bij gebruik v/h Conrad-bouwsetje: als je de gebruiksaanwijzing leest, zie je dat dit werkt bij (ongeveer) 40 kHz; m.a.w.: de ontvangst staat "ingeregeld" op dezelfde golflengte.
Het lijkt me dat bewegende voorwerpen vanaf een bepaalde snelheid niet opgemerkt worden (omdat de frequentie door het Doppler-effect buiten de mogelijk te ontvangen frequenties valt).

Overigens, een project als het bedoelde staat in een engels-talig hobby-blad. Een paar jaar terug was ik daar in geïnteresseerd, en heb het dus aangeschaft, ebenals het Conrad-setje.
Het Conrad-setje heb ik nooit werkend gekregen (waarschijnlijk iets te sterk verhit bij het solderen). Het project uit Electronics Now was me te kostbaar.

De paar jaar terug blijkt 11 jaar te zijn: het gaat om Electronics Now, September 1993. Project: "Build an Ultrasonic Radar Station", ondertitel "and keep tabs on your surroundings!"

Is dat dit artikel toevallig ?

[Verwijderd]

Brothar schreef op 12 juli 2004 @ 18:50:
Over 't meenemen v/h Doppler-effect bij gebruik v/h Conrad-bouwsetje: als je de gebruiksaanwijzing leest, zie je dat dit werkt bij (ongeveer) 40 kHz; m.a.w.: de ontvangst staat "ingeregeld" op dezelfde golflengte.
Het lijkt me dat bewegende voorwerpen vanaf een bepaalde snelheid niet opgemerkt worden (omdat de frequentie door het Doppler-effect buiten de mogelijk te ontvangen frequenties valt).

Overigens, een project als het bedoelde staat in een engels-talig hobby-blad. Een paar jaar terug was ik daar in geïnteresseerd, en heb het dus aangeschaft, ebenals het Conrad-setje.
Het Conrad-setje heb ik nooit werkend gekregen (waarschijnlijk iets te sterk verhit bij het solderen). Het project uit Electronics Now was me te kostbaar.

De paar jaar terug blijkt 11 jaar te zijn: het gaat om Electronics Now, September 1993, blz. 31. Project: "Build an Ultrasonic Radar Station", ondertitel "and keep tabs on your surroundings!", door ene Ronald M. Jackson.


Onderdelen: zender en ontvanger van een polaroid camera, een stapper motor, en een eerder door het blad geplaatste interface-board. Uitlezing gebeurde door een QBasic programma, zeer waarschijnlijk op een 486-PC (486-er wordt genoemd in de inleiding van het artikale).
In het bouwschema worden 2 IC's gebruikt, met als opschrift "SN28784 PID614908, resp. TL851 PID614904".

Over dat Doppler-effect heb je inderdaad een heel goed punt. Daar moeten we waarschijnlijk toch eens goed naar kijken. Op basis van de formules die ik bekomen heb heb ik nu wat zitten rekenen. Als ik in de datasheet van de receiver kijk "gok" ik dat tussen 38000 en 41000 Hz nog net voldoende signaal opgevangen wordt door de receiver. Op basis daarvan heb ik berekend dat de maximale snelheid naar de sonar toe 15 km/h bedraagt, en weg van de sonar 31 km/h. Dat zijn nog redelijke snelheden eigenlijk, maar natuurlijk niet optimaal...iemand goeie ideeën hoe dit verholpen kan worden?

Trouwens zit ik nog met een "begrijp" probleem. In vorige posts ging ik er van uit dat de receiver stroom doorstuurt als het signaal krijgt. Dan zit ik wel met het probleem hoe je frequenties moet uitlezen (nogal belangrijk om berekeningen te doen hé ). Ik heb ook het probleem met de verbinding tussen pc en sonar. Ik snap dat de pc de stroom op een lijn kan uitlezen...maar sinds dat dat digitaal gebeurt is dat enkel 1 of 0, hoe gaat het normaal in zijn werk om waarden (zoals afstanden etc) door te sturen? Is dat een opeenvolgende reeks 0'en en 1'en dan? En hoe kan je dan het begin van een signaal vinden en het einde?

[Verwijderd]

Verwijderd schreef op 12 juli 2004 @ 19:29:
[...]

Over dat Doppler-effect heb je inderdaad een heel goed punt. Daar moeten we waarschijnlijk toch eens goed naar kijken. Op basis van de formules die ik bekomen heb heb ik nu wat zitten rekenen. Als ik in de datasheet van de receiver kijk "gok" ik dat tussen 38000 en 41000 Hz nog net voldoende signaal opgevangen wordt door de receiver. Op basis daarvan heb ik berekend dat de maximale snelheid naar de sonar toe 15 km/h bedraagt, en weg van de sonar 31 km/h. Dat zijn nog redelijke snelheden eigenlijk, maar natuurlijk niet optimaal...iemand goeie ideeën hoe dit verholpen kan worden?

Trouwens zit ik nog met een "begrijp" probleem. In vorige posts ging ik er van uit dat de receiver stroom doorstuurt als het signaal krijgt. Dan zit ik wel met het probleem hoe je frequenties moet uitlezen (nogal belangrijk om berekeningen te doen hé ). Ik heb ook het probleem met de verbinding tussen pc en sonar. Ik snap dat de pc de stroom op een lijn kan uitlezen...maar sinds dat dat digitaal gebeurt is dat enkel 1 of 0, hoe gaat het normaal in zijn werk om waarden (zoals afstanden etc) door te sturen? Is dat een opeenvolgende reeks 0'en en 1'en dan? En hoe kan je dan het begin van een signaal vinden en het einde?

over die frequenties weet ik ook niet helemaal..
maar je hebt dus ongeveer dit (als ik het goed heb):

zender/ontvanger --> uc <-> pc
de communicatie tussen de pc kan grofweg op 2 manieren gebeuren, serieel of parallel. voor beide methoden geldt dat de uc en de pc een "hoog" en een "laag" kennen, dat is 1 bit (0 of 1), waarbij 2 voltages horen.
het verschil tussen parallel en serieel is de manier waarop een byte wordt verstuurd, bij serieel worden de bits achter elkaar verstuurd (dus maar weinig draadjes nodig) en bij parallel worden ze parallel aan elkaar verstuurd (dus bijvoorbeeld 8 draadjes , kun je elke keer een byte versturen)
dan is er bij de pc nog een verschil in die voltage-niveau's. bij parallel is dat 0v(voor laag) en +5v(voor hoog) (zogenaamde TTL). bij de seriele poort is dat +10v en -10v.
zoals gezegd gebruiken de uc's ook TTL. daarom heb je een max232 (www.maxim-ic.com) nodig omze op de seriele poort aan te sluiten (die max232 is als het ware een "vertaler")
begin en einde zijn "afgesproken" (baud-rate etc..)

[ Voor 4% gewijzigd door Verwijderd op 12-07-2004 19:51 ]

[Verwijderd]

Verwijderd schreef op 12 juli 2004 @ 19:49:
[...]


over die frequenties weet ik ook niet helemaal..
maar je hebt dus ongeveer dit (als ik het goed heb):

zender/ontvanger --> uc <-> pc
de communicatie tussen de pc kan grofweg op 2 manieren gebeuren, serieel of parallel. voor beide methoden geldt dat de uc en de pc een "hoog" en een "laag" kennen, dat is 1 bit (0 of 1), waarbij 2 voltages horen.
het verschil tussen parallel en serieel is de manier waarop een byte wordt verstuurd, bij serieel worden de bits achter elkaar verstuurd (dus maar weinig draadjes nodig) en bij parallel worden ze parallel aan elkaar verstuurd (dus bijvoorbeeld 8 draadjes , kun je elke keer een byte versturen)
dan is er bij de pc nog een verschil in die voltage-niveau's. bij parallel is dat 0v(voor laag) en +5v(voor hoog) (zogenaamde TTL). bij de seriele poort is dat +10v en -10v.
zoals gezegd gebruiken de uc's ook TTL. daarom heb je een max232 (www.maxim-ic.com) nodig omze op de seriele poort aan te sluiten (die max232 is als het ware een "vertaler")
begin en einde zijn "afgesproken" (baud-rate etc..)

Ok dus zoals ik dacht, je stuurt elke bit na elkaar door...blijft enkel nog wat onduidelijk hoe je de PIC net bit per bit laat doorsturen, maar ik veronderstel dat dat zorgen zijn voor later. Volgens mij zal het programmeren van de PIC en PC software wel door een paar mensen gedaan worden, dus de dingen die ik niet weet zal ik ongetwijfeld dan wel van iemand anders bijleren.

Nu zit ik eigenlijk met een misschien domme vraag. In de poll wordt overwegend voor serieel gekozen. Dit betekend dat er dan zo een max232 tussen moet om de verbinding mogelijk te maken. Bovendien kon ik maar weinig vinden over programmeren voor de COM-poort.
Daarintegen is er een hoop info te vinden over de printerpoort. Programmeren op PC is daarvoor makkelijker denk ik en bovendien is er geen nood aan max232. Verder heeft de PIC die voorgesteld werd 8 pins op poort B, die kan dus makkelijk gebruikt worden om parallel elke byte uit te sturen.
Waarom wordt er dan zo massaal voor COM-poort gekozen en niet voor de printerpoort

[Verwijderd]

Verwijderd schreef op 12 juli 2004 @ 19:58:
[...]

Ok dus zoals ik dacht, je stuurt elke bit na elkaar door...blijft enkel nog wat onduidelijk hoe je de PIC net bit per bit laat doorsturen, maar ik veronderstel dat dat zorgen zijn voor later. Volgens mij zal het programmeren van de PIC en PC software wel door een paar mensen gedaan worden, dus de dingen die ik niet weet zal ik ongetwijfeld dan wel van iemand anders bijleren.

Nu zit ik eigenlijk met een misschien domme vraag. In de poll wordt overwegend voor serieel gekozen. Dit betekend dat er dan zo een max232 tussen moet om de verbinding mogelijk te maken. Bovendien kon ik maar weinig vinden over programmeren voor de COM-poort.
Daarintegen is er een hoop info te vinden over de printerpoort. Programmeren op PC is daarvoor makkelijker denk ik en bovendien is er geen nood aan max232. Verder heeft de PIC die voorgesteld werd 8 pins op poort B, die kan dus makkelijk gebruikt worden om parallel elke byte uit te sturen.
Waarom wordt er dan zo massaal voor COM-poort gekozen en niet voor de printerpoort

belangrijkste argument voor mij is dat je dan minder pinnetjes op de uc in gebruik zijn. maar ik ben zelf ook pas sinds kort bezig met uc's.
(ik ben begonnen met de avr. als je heel simpel wil beginnen dan kun je hier lezen hoe je een programmer kan maken. en kun je programmas schrijven in dit Basic-taaltje (gelimiteerde gratis versie) waar hier ook nog een nederlandse tutorial/handleiding voor is. volgensmij zou je hier al een heel eind mee komen )

[Verwijderd]

Verwijderd schreef op 12 juli 2004 @ 20:06:
[...]


belangrijkste argument voor mij is dat je dan minder pinnetjes op de uc in gebruik zijn. maar ik ben zelf ook pas sinds kort bezig met uc's.
(ik ben begonnen met de avr. als je heel simpel wil beginnen dan kun je hier lezen hoe je een programmer kan maken. en kun je programmas schrijven in dit Basic-taaltje (gelimiteerde gratis versie) waar hier ook nog een nederlandse tutorial/handleiding voor is. volgensmij zou je hier al een heel eind mee komen )

Hmm, wat meer verwarring nu...Een paar reply's terug (de laatste van gisterenavond) stonden er links naar tutorials en zo in een volledig andere taal en zo...Ach ja, makes sense, als er op pc zo veel talen bestaan moet dat voor pic's etc ook wel zo zijn. Ik ben wel geneigd om deze links bewust niet te lezen. De PIC die gisteren werd voorgesteld kan namelijk gratis besteld worden, wat toch wel een belangrijk argument is.

Langs een kant snap ik dat er dan minder pinnetjes in gebruik zijn, maar maakt dat dan zo veel verschil uit? Ik veronderstel dat uiteindelijk aan de sonar-kant er weinig extra moeilijkheid is als je serieel werkt. Maar zoals ik al zei, vind ik amper iets over COM-programmeren in Windows, wat toch een belangrijk aspect blijft als je iets wil gaan doen met de sonar (visualisatie en weergave van metingen)

[Verwijderd]

Verwijderd schreef op 12 juli 2004 @ 20:53:
[...]

Hmm, wat meer verwarring nu...Een paar reply's terug (de laatste van gisterenavond) stonden er links naar tutorials en zo in een volledig andere taal en zo...Ach ja, makes sense, als er op pc zo veel talen bestaan moet dat voor pic's etc ook wel zo zijn. Ik ben wel geneigd om deze links bewust niet te lezen. De PIC die gisteren werd voorgesteld kan namelijk gratis besteld worden, wat toch wel een belangrijk argument is.

Langs een kant snap ik dat er dan minder pinnetjes in gebruik zijn, maar maakt dat dan zo veel verschil uit? Ik veronderstel dat uiteindelijk aan de sonar-kant er weinig extra moeilijkheid is als je serieel werkt. Maar zoals ik al zei, vind ik amper iets over COM-programmeren in Windows, wat toch een belangrijk aspect blijft als je iets wil gaan doen met de sonar (visualisatie en weergave van metingen)

avr =! pic
je kunt beide in assembly programmeren, en ook van de avr kun je een sample aanvragen . ik gaf alleen wat links die handig zijn om simpel te beginnen met programmeren van avr's (programmeren in assembly lijkt mij redelijk lastig om meteen mee te beginnen)

[Verwijderd]

Verwijderd schreef op 12 juli 2004 @ 20:58:
[...]


avr =! pic
je kunt beide in assembly programmeren, en ook van de avr kun je een sample aanvragen . ik gaf alleen wat links die handig zijn om simpel te beginnen met programmeren van avr's (programmeren in assembly lijkt mij redelijk lastig om meteen mee te beginnen)

Allright! Assembly lijkt inderdaad wat "primitief" om alles te kunnen doen maar van anderen bleek dit toch mogelijk. Anyway, ik wil even duidelijk maken dat ik zeker je links apprecieer, ik hoop dat je je niet aangevallen voelde of dergelijke door mijn misschien wat botte reactie hiervoor.

Verder heb ik net nog een zeer interessante link gevonden (wel over de PIC) waarin een voorbeeld zou staan over interface tussen PC en PIC via COM-poort:
http://www.boondog.com/tutorials/pic16F84/pic16f84.html

[Brothar]

En daar staat dus - hoe handig! - al een timer tussen.
Want de proceduregang die ik me voorstel is:
- uit-signaal op com-poort zetten
waardoor:
- de zend-module een "burst" geeft, en
- elke (PIC)ontvanger-module vanaf dat moment gaat "klokken" hoelang het duurt voor een weerkaatst signaal wordt ontvangen.
Vervolgens moet de com-poort de geregistreerde tijden uit elke module uitlezen, en
Tenslotte beginnen we weer van voor af aan.

De PC ontvangt de tijden via de com poort, weet de stand van de stepper-motor, en plot vervolgens.
Dit zou binnen de tijdsduur van 1 "burst" moeten kunnen.

En nu ik dit zou vaststel, denk ik dat het handigste is, conform het project uit Electronics Now, te werken met 1 zend- en 1 ontvangstmodule, die op de as van de stappermotor boven elkaar zijn geplaatst.
NB. Elk üit"-signaal op de com-poort, dat 1 burst laat starten, kan dan ook dienen om de stappermotor 1 stap verder te zetten (en dan pas de procedure te laten starten).

[ Voor 38% gewijzigd door Brothar op 12-07-2004 21:31 ]

[Verwijderd]

N.a.v de oplossing met de tupperware bak:
Ik denk dat je er beter juist druk op kunt zetten, dan is de binnenkant (de ontvangstkant) van de schotel mooi strak. Vervolgens kun je dan de bovenkant van de plastic 'bel' mooi met epoxy en glasvezelmatjes bedekken.
De binnenkant moet tenslotte mooi strak zijn.
My 2 cents.

[Verwijderd]

Verwijderd schreef op 10 juli 2004 @ 12:52:
Laat ik meteen maar beginnen ook met een paar ideeën.


Kwestie van motor (de sonar moet kunnen ronddraaien toch) dacht ik aan een steppermotor (of steppenmotor ?). Als de constructie niet te zwaar is kan zelf een licht motortje uit een oude diskdrive dienst doen, dit in de gedachte het zo goedkoop mogelijk te houden.

Niet als je met bundels gaat werken. Door middel van staven kun je dan bundels
vormen (attack) of rondom kijken (omni).
Beter is dan om piezo electrische elementen te gebruiken die je in een cirkel opsteld met behulp van een electronische schakelaar kun je dan een bundel kiezen.
Als je er ook mee onder water wilt kijken die je heel goed rekening te houden met de zogenaamde background reverberation.

[Verwijderd]

Verwijderd schreef op 12 juli 2004 @ 19:29:
[...]

Over dat Doppler-effect heb je inderdaad een heel goed punt. Daar moeten we waarschijnlijk toch eens goed naar kijken. Op basis van de formules die ik bekomen heb heb ik nu wat zitten rekenen. Als ik in de datasheet van de receiver kijk "gok" ik dat tussen 38000 en 41000 Hz nog net voldoende signaal opgevangen wordt door de receiver. Op basis daarvan heb ik berekend dat de maximale snelheid naar de sonar toe 15 km/h bedraagt, en weg van de sonar 31 km/h. Dat zijn nog redelijke snelheden eigenlijk, maar natuurlijk niet optimaal...iemand goeie ideeën hoe dit verholpen kan worden?

Waarom niet gewoon een pulsvormend netwerk met daarin een MF welke veranderd kan worden, het een en ander afhankelijk van de maximale doppler verschuiving die je wilt meten (hoge of lage doppler).

Wil je weten hoe een echte sonar werkt google dan maar eens naar:

CWE-610, SQS-506 of PHS-36.

[Verwijderd]

Brothar schreef op 12 juli 2004 @ 21:21:
En daar staat dus - hoe handig! - al een timer tussen.
Want de proceduregang die ik me voorstel is:
- uit-signaal op com-poort zetten
waardoor:
- de zend-module een "burst" geeft, en
- elke (PIC)ontvanger-module vanaf dat moment gaat "klokken" hoelang het duurt voor een weerkaatst signaal wordt ontvangen.
Vervolgens moet de com-poort de geregistreerde tijden uit elke module uitlezen, en
Tenslotte beginnen we weer van voor af aan.

De PC ontvangt de tijden via de com poort, weet de stand van de stepper-motor, en plot vervolgens.
Dit zou binnen de tijdsduur van 1 "burst" moeten kunnen.

En nu ik dit zou vaststel, denk ik dat het handigste is, conform het project uit Electronics Now, te werken met 1 zend- en 1 ontvangstmodule, die op de as van de stappermotor boven elkaar zijn geplaatst.
NB. Elk üit"-signaal op de com-poort, dat 1 burst laat starten, kan dan ook dienen om de stappermotor 1 stap verder te zetten (en dan pas de procedure te laten starten).

Zo zie ik het ook ongeveer, enkel ben ik zelf nog steeds fervent voorstaander van de mooie manier, dus de PIC doet ook de berekeningen.

Jammer genoeg was de link wat bedriegelijk. Er staat enkel in hoe je je PIC zodanig programmeert om signaal door te sturen naar de PC. Al hun programma's voeren ze op PC uit door Hyperterminal. Er is geen sprake van rechtstreeks aanspreken van de COM-poort vanuit om het even welke programmeertaal, jammergenoeg. Dat blijft dus nog zoeken.

De pagina gaf wel interessante informatie over het bestaan van CCS C. Dit is blijkbaar een compiler die C kan omzetten naar hex. Dat zorgt dat er wat meer functionaliteiten mogelijk zijn dan met assembler...denk ik. (op het eerste zicht kan je bv perfect * gebruiken voor vermenigvuldiging, in assembler vond ik daar geen functie voor [maar toegegeven, gisterenavond was de eerste keer dat ik over assembler las]. Enige probleem: weer te betalen. Als iemand een gratis alternatief kent dat hetzelfde kan, zou dat heel handig zijn, anders denk ik dat het toch assembler zal blijven (indien mogelijk).

[3lmowww]

Beste iedereen.

Ik denk dat het maken van de parabool van latere zorg is. Het moeilijkste zit em waarschijnlijk in de "echte" metingen. (electronica dus)

Als er nog mensen nodig zijn voor het schrijven van PIC software bied ik me aan.
Moeilijke onderdelen is voor mij ook no prob.

Serieele communicatie met een pic kan een stuk goedkoper zonder max232 oid. 4 weerstandjes, 1 diode en 2 bc547`s (ik tel nog geen 15 cent ). Dat is niet zo moeilijk.

Seriele poort lijkt mij mooiere oplossing omdater geen hoge datarate nodig is, en het opzich de mooiste poort van de computer is ( toch even mijn vooroordeel uitspreken).

[ExploWare]

maar, dan moet je wel overstappen naar een server PCtje, en niet op de achtergrond van je gamePC uitlaten voeren...
Dat is weer het voordeel van de 'mooie' optie, dus met een pic...
of zie ik verkeerd dat een zware belasting de hele berekening in de war kan schoppen?
En daarbij: WINDOWS KAN NIET MET TIJD OMGAAN!
Als je goed de seconde wijzer van de windows klok bekijkt, zie je m al lelijk bewegen, maar als je nog een teller erbij hebt die 1/100 wil laten zien, wordt t echt lelijk, dan moet je toch echt naar een Linux/Unix OS, die 1/100 honderd% zuiver kan laten zien...

[frickY]

Nu ik dit zo lees ga ik me toch zorgen maken.
Mijn excuses TS.. maar het lijkt net of jijzelf het minste weet over dergelijke zaken. Vind het dus vrij knap dat juist jij dan een dergelijk project wilt uitvoeren met 'hulp' van anderen..

[Verwijderd]

frickY schreef op 13 juli 2004 @ 09:19:
Nu ik dit zo lees ga ik me toch zorgen maken.
Mijn excuses TS.. maar het lijkt net of jijzelf het minste weet over dergelijke zaken. Vind het dus vrij knap dat juist jij dan een dergelijk project wilt uitvoeren met 'hulp' van anderen..

Ik heb er ook nooit een geheim van gemaakt...op gebied van elektronica is mijn kennis minimaal (praktische kennis dan, theoretisch weet ik wel wat de meeste onderdelen doen). Op gebied van theorie rond sonar/radar denk ik dat mijn kennis wel voldoende moet zijn. De grootste reden van dit project is daar voor mij trouwens ook op gebaseerd: eindelijk eens wat praktijk-kennis opdoen en de problemen ontdekken die bij de theorie niet behandelt worden.
Ik ben van nature niet iemand die snel opgeeft, ik ben een doorbijter. De laatste dagen heb ik al een hoop nieuwe dingen bijgeleerd en ben er gerust in dat (als jullie willen blijven helpen uiteraard) we tot een tof eindproduct komen waar ikzelf ook wat dingen ingebracht hebben.

Ik wil ook een beetje het patroon doorbreken. Wie niets van elektronica kent moet de toffe projecten aan z'n neus voorbij zien gaan en zit gebonden aan het maken van een looplichtje...niet zo uitdagend. Ik heb ergens de (naieve?) overtuiging dat als je dit project echt tot een goed eind wil brengen, je beginkennis geen bepalende factor is. Het is je inzet die telt, en geloof me die is er zeker. Ik hoop dat mensen mij blijven steunen en helpen in dit project. Ik heb al enorm veel gehad aan jullie inbreng (van iedereen, ook gewoon mensen die enthousiast waren en wouden meedoen, ook al hadden ze geen echte inbreng). Ik weet dat het makkelijker zou liggen moest ik wat meer ervaring hebben...maar toen je nog een baby'tje was hebben je ouders je ook niet in de steek gelaten voor een andere baby die wel al kon lopen, toch? [Ok Ok, wat ik wil doen is eerder direct de 100m spurt winnen dan gewoon lopen, maar you get the point hé]

Laat me van deze post meteen nog snel gebruik maken om een interessante link te geven die ik gisteren nog vond. Het gaat over het aansturen van de seriele poort in VB.NET. Ik heb het zelf nog niet kunnen lezen maar ga er vandaag eens naar kijken of het doet wat het belooft. Als ik mij niet vergis heb ik ook ergens in mijn hoop bookmarks een link naar hoe je kan plotten in VB.NET , een combinatie van die twee brengt ons dan al heel ver in het programmeren van software voor Windows XP. De link: http://www.codeworks.it/net/VBNetRs232.htm.

[ Voor 14% gewijzigd door Verwijderd op 13-07-2004 10:24 . Reden: Stuk over VB.NET toegevoegd ]

[Verwijderd]

3lmowww schreef op 13 juli 2004 @ 00:07:
Beste iedereen.

Ik denk dat het maken van de parabool van latere zorg is. Het moeilijkste zit em waarschijnlijk in de "echte" metingen. (electronica dus)

Als er nog mensen nodig zijn voor het schrijven van PIC software bied ik me aan.
Moeilijke onderdelen is voor mij ook no prob.

Serieele communicatie met een pic kan een stuk goedkoper zonder max232 oid. 4 weerstandjes, 1 diode en 2 bc547`s (ik tel nog geen 15 cent ). Dat is niet zo moeilijk.

Seriele poort lijkt mij mooiere oplossing omdater geen hoge datarate nodig is, en het opzich de mooiste poort van de computer is ( toch even mijn vooroordeel uitspreken).

Momenteel is er nog niet echt een groep "geselecteerd" om het PIC te programmeren. Ik hou je nick zeker bij. Uiteraard werk ik zelf ook mee aan het programmeren er van (anders zou ik nogal een luie TS zijn hé). Als er nog mensen zijn die zich nu al voor iets willen beschikbaar stellen, laat maar weten hé.

Ik heb ook gekeken op de site van maxim en je kan gratis samples krijgen (hier in België tenminste volledig gratis). Je kan telkens 2 samples ontvangen. Uit wat ik gelezen heb zouden zowel de MAX232, MAX232A en MAX233 voldoen aan de eisen voor de sonar...dat maakt dus 6 gratis samples, dan mag daar al wel eens iets mee mislopen hé , we kunnen dus proberen om eerst de gratis MAX's te gebruiken.

Ik wil ook niet te hard van stapel lopen met dit project. Daarom komt het misschien wel over alsof er geen schot in de zaak komt. Wie vindt er dat we over moeten gaan van het theoretisch keuvelen over verschillende problemen naar praktisch werken? Ik veronderstel dat de eerste taak wel het ontwikkelen van de elektronica zelf is, correct me if i'm wrong...

[Cassettebandje]

Brothar schreef op 12 juli 2004 @ 21:21:
- elke (PIC)ontvanger-module vanaf dat moment gaat "klokken" hoelang het duurt voor een weerkaatst signaal wordt ontvangen.

ga jij ff met een pic meten hoe snel geluid terugkomt, ik denk dat ie daar niet snel genoeg voor is (correct me if i'm wrong)

ik heb op school ook eens met een radar gespeeld en toen hebben ze uitgelegd dat het apparaat een signaal uitzendt met een frequentie die oploopt. Door het verschil in uitgezonden en ontvangen frequentie te meten kun je de afstand bepalen. Het verschil in frequentie kun je bepalen door de signalen op te tellen en de frequentie van de eerste harmonische te bepalen, dat is het verschil in frequentie. Dat zal dan wel laag genoeg zijn om met een pic te kunnen meten.

Dat is meer analoog werk, maar ik denk dat je hier meer success mee behaalt dan met alleen een pic.

[Verwijderd]

Cassettebandje schreef op 13 juli 2004 @ 11:46:
[...]

ga jij ff met een pic meten hoe snel geluid terugkomt, ik denk dat ie daar niet snel genoeg voor is (correct me if i'm wrong)

ik heb op school ook eens met een radar gespeeld en toen hebben ze uitgelegd dat het apparaat een signaal uitzendt met een frequentie die oploopt. Door het verschil in uitgezonden en ontvangen frequentie te meten kun je de afstand bepalen. Het verschil in frequentie kun je bepalen door de signalen op te tellen en de frequentie van de eerste harmonische te bepalen, dat is het verschil in frequentie. Dat zal dan wel laag genoeg zijn om met een pic te kunnen meten.

Dat is meer analoog werk, maar ik denk dat je hier meer success mee behaalt dan met alleen een pic.

Niet slecht bedoelt maar ik denk dat je het hier een beetje door elkaar slaagt.

Op basis van verschil tussen uitgezonden en ontvangen frequentie kan je de snelheid van een voorwerp meten, niet zijn afstand. De afstand bepaal je uit de tijd die verstrijkt tussen versturen en ontvangen, en een paar posts hiervoor is redelijk goed aangetoond dat een PIC hiervoor geen bottleneck is, hij is tot ongeveer een halve milimeter exact en zeker snel genoeg.

Volgens mij is het bepalen van de zwevingsfrequentie (de frequentie van de 1e harmonische van het samengestelde signaal) heel wat moeilijker om te realiseren, dan gewoon meten van ontvangen en verstuurde frequentie, waaruit je dan ook de zwevingsfrequentie kan berekenen.

Welk systeem je ook gebruikt blijft er een "probleem" dat niet behandelt is: dat de receiver stroom doorstuurt als er signaal binnenkomt, daar zijn we het blijkbaar akkoord over (heb nog niemand gehad die zei dat dit verkeerd was). Zo kunnen we al timen hoe lang het duurt tussen verzenden en ontvangen. Maar hoe kom je de ontvangen frequentie te weten van de receiver

[Verwijderd]

Even een vraag aan mensen die op de hoogte zijn van PIC-progammeren. Ik ben een tutorial aan het lezen, en ik heb een vermoeden dat er een zeer foute code gebruikt wordt.

De code is nogal moeilijk te kopieren naar hier dus een linkje is makkelijker: *Klik*.
Het gaat mij om de Delay routine. Volgens mij loopt die nooit zoals het zou moeten. De eerste keer denk ik dat hij niet doet wat hij moet doen omdat die COUNT1 na 1 keer doorlopen al op nul staat. Van zodra je de Delay een tweede keer oproept staat COUNT1 en COUNT2 al op nul van de vorige keer en doet de Delay dus amper iets...Klopt mijn denkwijze? Of is de code correct en snap ik de functie 'decfsz' niet goed?

[Verwijderd]

Wat betreft de communicatie tussen PC en PIC (/AVR): Serieel is mooier, omdat de microcontroller in de meeste gevallen een ingebouwde UART heeft, zodat je zelf niet veel meer hoeft doen om data te versturen (gewoon registertje schrijven en het wordt verstuurd).

Daarnaast kun je met serieel gebruik maken van de 'officiële' manier van poorten benaderen in Windows. Dit kan in Windows namelijk gewoon met fileopen. Dit in tegenstelling tot parallel, waarbij je de poortmachtigingen moet omzeilen met een programma zoals dlportio.

Ik kan trouwens ook meehelpen met het programmeren van het een en ander. (Ik heb zelf vooral ervaring met een AVR)

[DiLDoG]

Ik denk zelf dat een AVR ook een leuk alternatief is. Veel mogenlijkheden en erg veel software (ik gebruik nu C51) erg makkelijk om lcd en andere dingen aan te sturen en goed verkrijgbaar

[Cassettebandje]

Verwijderd schreef op 13 juli 2004 @ 11:52:
[...]

Niet slecht bedoelt maar ik denk dat je het hier een beetje door elkaar slaagt.

Op basis van verschil tussen uitgezonden en ontvangen frequentie kan je de snelheid van een voorwerp meten, niet zijn afstand. De afstand bepaal je uit de tijd die verstrijkt tussen versturen en ontvangen, en een paar posts hiervoor is redelijk goed aangetoond dat een PIC hiervoor geen bottleneck is, hij is tot ongeveer een halve milimeter exact en zeker snel genoeg.

ik heb het niet over het doppler effect maar iets anders: per dF laat je te frequentie van het signaal met dF toenemen. Als je het signaal ontvangt dan bepaal je het verschil tussen de uitgezonden en ontvangen frequentie en omdat dF/dT constant is kun je met het verschil in frequentie het verschil in tijd bepalen.
En die post over dat de pic snel genoeg is moet je me eens aanwijzen

Volgens mij is het bepalen van de zwevingsfrequentie (de frequentie van de 1e harmonische van het samengestelde signaal) heel wat moeilijker om te realiseren, dan gewoon meten van ontvangen en verstuurde frequentie, waaruit je dan ook de zwevingsfrequentie kan berekenen.

Dat zou je kunnen doen met een am-demodulator, signaal erin, 1e harmonische eruit

Welk systeem je ook gebruikt blijft er een "probleem" dat niet behandelt is: dat de receiver stroom doorstuurt als er signaal binnenkomt, daar zijn we het blijkbaar akkoord over (heb nog niemand gehad die zei dat dit verkeerd was). Zo kunnen we al timen hoe lang het duurt tussen verzenden en ontvangen. Maar hoe kom je de ontvangen frequentie te weten van de receiver

na de am-demodulator een schmitt trigger die het niveau van het signaal op een logisch niveau brengt en dan een op primaire logica gebaseerde counter. Primaire logica is veel sneller dan een pic/avr. De coutner laat je bijv 1 sec tellen en wat ie aangeeft dat is de frequentie

[12_0_13]

Leuk project! Het lijkt een beetje op een eerstejaars projectje dat ik gedaan heb tijden smijn studie informatica. Daarbij maten mbh ultasound de hoogte van golven in een waterbak als simulatie voor een stormvloedjkering.

We maakten daar gebruik van reeds bestaande electronica, de bestond uit een zender en een ontvanger. De zender verstuurde een pulstrein aan geluid. Door nu de tijd te meten tussen de verzending en het onvagnen van die pulstrein konden we de hoogte aflezen.

Maar natuulijk kan je ook gebruikmaken van de lengte van de pulstrein om de frequentie te achterhalen

De logica programmeerden we op een FPGA mbv AHDL. Die mat de tijd in units (geen idee meer wat de scaal was), en stuurde die door naar de PC. Mbv java (ja Java ) lazen we de com poort uit en konden we het signaal decoderen naar afstand.

[ Voor 17% gewijzigd door 12_0_13 op 13-07-2004 17:31 ]

[Verwijderd]

DiLDoG schreef op 13 juli 2004 @ 15:36:
Ik denk zelf dat een AVR ook een leuk alternatief is. Veel mogenlijkheden en erg veel software (ik gebruik nu C51) erg makkelijk om lcd en andere dingen aan te sturen en goed verkrijgbaar

Ik heb een hele tijd bezig gezeten om alle tutorials die ik vond over de PIC te lezen. Nu heb ik ook een groot deel van de nederlandse tutorial gelezen over de AVR.

Toegegeven, qua programmeertaal is een AVR makkelijker te programmeren met die Basic-taal. (ik denk bijvoorbeeld aan het bestaan van *, wat ik echt nergens terug vind in assembler).
Anderzijds is de informatie over de PIC naar mijn mening wat uitgebreider en duidelijker. Bovendien denk ik dat er voor de sonar amper verschil is tussen programmeren in Basic of Assembler. (uiteindelijk moet enkel getimed worden en indien mogelijk de frequentie van de receiver gemeten worden)

Ikzelf zou dus liever voor de PIC gaan, ik heb er al wat meer over gelezen etc en ik denk dat de moeilijkheidsgraad voor het programmeren niet veel hoger ligt (uiteraard enkel het vermenigvuldigen blijft voor mij nog een probleem).

Is iedereen akkoord om toch met de PIC te werken en niet met de AVR of zijn er fervente voorstaanders van de AVR?

Poll: Welk type IC gebruiken we?
• PIC
• AVR

^{Ook een poll maken? Klik hier}

[Verwijderd]

Verwijderd schreef op 13 juli 2004 @ 13:36:
Wat betreft de communicatie tussen PC en PIC (/AVR): Serieel is mooier, omdat de microcontroller in de meeste gevallen een ingebouwde UART heeft, zodat je zelf niet veel meer hoeft doen om data te versturen (gewoon registertje schrijven en het wordt verstuurd).

Daarnaast kun je met serieel gebruik maken van de 'officiële' manier van poorten benaderen in Windows. Dit kan in Windows namelijk gewoon met fileopen. Dit in tegenstelling tot parallel, waarbij je de poortmachtigingen moet omzeilen met een programma zoals dlportio.

Ik kan trouwens ook meehelpen met het programmeren van het een en ander. (Ik heb zelf vooral ervaring met een AVR)

Ik hou je nick bij voor het programmeren. Bedankt ook voor jou mening over waarom de seriele poort gebruikt moet worden.

[Verwijderd]

Cassettebandje schreef op 13 juli 2004 @ 16:47:
[...]

na de am-demodulator een schmitt trigger die het niveau van het signaal op een logisch niveau brengt en dan een op primaire logica gebaseerde counter. Primaire logica is veel sneller dan een pic/avr. De coutner laat je bijv 1 sec tellen en wat ie aangeeft dat is de frequentie

Heel hard geprobeert dit te begrijpen...maar schmitt trigger en zo
Blijkbaar heb jij wel een idee / vermoeden over hoe de receiver zijn frequentie doorstuurt. Kan je dat wat toelichten? (bv. de receiver stuurt een stroom door waarvan de stroomsterkte overeenstemt met de frequentie of iets dergelijks...)

[Sprite_tm]

Ok, ik heb dit topic ook maar es ff zo ongeveer doorgelezen, en hier even een braindump van mijn gedachten:

Als je die piezo-onderdelen van de Conrad gaat gebruiken hoef je verder niet meer te filteren ofzo, die dingen zijn namelijk strak getuned op (bijvoorbeeld) 30KHz en daarmee pik je eigenlijk alleen nog maar het signaal wat je zelf uitgezonden hebt op.

Die smalle bandbreedte heeft ook een nadeel: hetgene wat je eruitkrijgt is niet zozeer hetgene wat je in je transmitter gestopt hebt met een delay, maar een langzaam in amplitude aanzwellende en afnemende 30KHz sinus. Je zult dus op een bepaalde manier moeten kiezen wanneer je inderdaad wat gedetecteerd hebt. Dit kan in principe met een simpele comparator, maar je moet er wel even aan denken.

Wat het microcontroller-gedeelte betreft: Ik ben zelf een groot fan van de AVR- series en ik zou hiervoor de AT90S2313 pakken. Ingebouwde uart (seriele communicatie is dus programmeer-technisch een eitje), 16-bit teller (betekent dat je het bijhouden hoe lang het duurt voordat je de puls binnenkrijgt aan de hardware kan overlaten; ergo <1mm resolutie), ingebouwde comparator (scheelt je weer een extern onderdeel) en imho een droom om te programmeren.

Wat je dan aan onderdelen nodig zou hebben om een simpel afstands-detecterend ultrasoon-unitje te hebben is: een AT90S2313, een kristal, een max232 of vervangende tor+condo+diode-schakeling, 2 piezo-elementjes (Of je gebruikt er maar 1 die meteen zowel kan zenden als ontvangen) en misschien nog een opampje om het ontvangende signaal te versterken.


Edit: Damoke: Wat bedoeld wordt met AM-demodulatie is dat je een schakeling aan de ontvanger knoopt die de binnenkomende aanzwellende en afnemende sinus omzet in een evenredig aanzwellende en afnemende spanning. De schmitt-trigger (uitleg bijvoorbeeld hier) maakt daar dan weer een digitaal signaal van.

Edit2: Ter verduidelijking van hoe zo'n piezo-elementje werkt: Zo gaan je rauwe signalen er dus uitzien als je een pulstreintje naar je ultrasoon-transmitter stuurt en je meteen aan de receiver meet:

[ Voor 24% gewijzigd door Sprite_tm op 13-07-2004 18:20 ]

[Cassettebandje]

over zwevingen, am demodulatie en de schmitt trigger

[Verwijderd]

Cassettebandje schreef op 13 juli 2004 @ 18:27:
over zwevingen, am demodulatie en de schmitt trigger
[afbeelding]

Ok, die tekening maakt veel duidelijk. De schmitt trigger maakt dus van een "zwevingssignaal" een digitaal signaal als ik het goed begrijp? Dus in principe sluit je best zo een Schmitt trigger aan achter je receiver vooraleer je het signaal op de PIC laat binnen komen. Dan maakt het timen van het signaal dan eenvoudig en redelijk exact nog steeds.
Maar hoe gebruik je die trigger om de frequentie te bepalen? Ik zit momenteel te denken aan het volgende:
Over het uitgezonden signaal weet je alles wat je wil weten. Van je teruggezonden signaal weet je dat het nog steeds geluid is, dus even snel gaat en ken je de tijd, misschien is dat voldoende om de golflengte van het ontvangen signaal te berekenen en zo de frequentie...Ik ga hier zeker op verder zoeken, maar als iemand denkt dat ik het te ver zoek of verkeerd zoek, zeg het me dan wel aub

[virus.elektro]

waarom gebruiken we geen basic stamp ic, deze zijn standaard uitgerust met rs323 poort en werken op 5 volt en moet je programeren in basic. je kan dus ook gewoon 5 volt gebruiken voor de rest van de logica.

vorig jaar heb ik met dit ic afstanden gemeten tot een centimeter of 40 met ir licht. gaat vrij goed. volgens mij beruste dit op het uitdovings-versterkings principe, maar zeker weten doe ik dit niet. progje heb ik misschien nog wel ergens maar in het ergste geval ligt het op school in een doos

[Verwijderd]

Even nog een handige link voor mensen zoals ik die net beginnen met PIC's programmeren.
http://www.talkingelectronics.com/Projects/PIC_LAB-1/extra_10.html. Deze link heeft mij bevestigd dat er geen standaard manier is om te vermenigvuldigen en te delen maar er staat een mooie oplossing voor vermenigvuldigen en delen. (omdat we in de formule enkel door 2 gaat het goed) Toevallig handelt het ook heel eventjes over hoe je het probleem van te grote getallen aanpakt (zoals wij heel waarschijnlijk zullen hebben)

[Sprite_tm]

Damoke: Is het niet makkelijker om het vermenigvuldigen/delen aan de PC over te laten? De PC krijgt dan gewoon een temperatuur (mits dat doorgaat) en een tijdswaarde en mag dan zelf de afstand berekenen. Scheelt je iig veel moeilijk doen.

[Verwijderd]

Sprite_tm schreef op 13 juli 2004 @ 21:44:
Damoke: Is het niet makkelijker om het vermenigvuldigen/delen aan de PC over te laten? De PC krijgt dan gewoon een temperatuur (mits dat doorgaat) en een tijdswaarde en mag dan zelf de afstand berekenen. Scheelt je iig veel moeilijk doen.

Ik was zelf tot vijf seconden geleden nog altijd voorstaander om alles door de sonar te laten doen, ook al wijst de poll volledig anders uit. Maar door jou punt besefte ik plots iets.
De formule om de snelheid van het geluid te bepalen op basis van de temperatuur bevat ... een vierkantswortel. Dat geeft 2 problemen.
1. Met een PIC is die ver niet te doen denk ik. Ik ken alleszins geen manier om een vierkantswortel te bepalen door gebruiken te maken van som en verschil (en product). Met een AVR gaat dat wel omdat machten daar bestaan en hopelijk dus ook tot de macht 1/2 lukt.
2. Door die vierkantswortel zullen de meeste geluidsnelheden komma-getallen zijn en geen integers. Dus zelf al zou je een vierkantswortel kunnen berekenen, de snelheid zal afgerond moeten worden. Als je afrond kan je dan even goed gewoon 340 m/s gebruiken.

Hierdoor ben ik nu ook voorstaander van alles door pc te laten doen. Behalve het timen en meten van frequentie zou ik door de PIC laten doen. Dat timen zie ik goed zitten, dat meten van frequentie nog steeds niet, maar dat komt misschien nog wel.

[Verwijderd]

Vierkantswortel en kwadraat etc. *moeten* wel te doen zijn met standaard op- en aftel werk, aangezien dat ook het enige is wat de cpu in mn rekenmachine (een TI-83) kan. Dus dat is het probleem niet. Maar als die AVR die Sprite_tm daar noemt een ingebouwde comparator, teller en UART aansluiting heeft wordt het best interessant...

Damoke:
Ik zou niet al te enthousiast worden over het machtsverheffen van een AVR, waarschijnlijk kent het ding niet eens floating point getallen (correct me if i'm wrong)

[ Voor 22% gewijzigd door Verwijderd op 13-07-2004 23:19 ]

[Verwijderd]

Verwijderd schreef op 13 juli 2004 @ 23:18:
Vierkantswortel en kwadraat etc. *moeten* wel te doen zijn met standaard op- en aftel werk, aangezien dat ook het enige is wat de cpu in mn rekenmachine (een TI-83) kan. Dus dat is het probleem niet. Maar als die AVR die Sprite_tm daar noemt een ingebouwde comparator, teller en UART aansluiting heeft wordt het best interessant...

Damoke:
Ik zou niet al te enthousiast worden over het machtsverheffen van een AVR, waarschijnlijk kent het ding niet eens floating point getallen (correct me if i'm wrong)

Ja inderdaad, het moet wel mogelijk zijn. Maar ik ken de methode niet om zoiets door de 4 basisbewerkingen te bereiken en ik denk ook niet dat ze zo voor de hand liggend is. Bovendien blijft ook, zoals je zelf zegt, het "probleem" dat de meeste PIC's en AVR's geen floating point kennen.
Ik blijf nog steeds liefhebber van de mooie manier maar ik begin stilaan meer en meer te denken dat de "simpele" manier toch beter is. Uiteraard zou ik nog een groot stuk van het programma in de sonar zelf willen houden (verzenden en timen van signaal, verder draaien van sonar), enkel de resultaten die hij doorstuurt hebben achteraf nog wat berekening nodig op pc voor ze bruikbaar zijn (frequenties ipv snelheid, tijd ipv afstand). Ik denk dat die combinatie tot een mooi systeem zal leiden dat zo exact mogelijk blijft (als je die berekeningen op de PIC laat doen zit je aan integers gebonden en zal je resultaat niet even exact zijn als op pc)

[3lmowww]

http://www.eje-electronics.nl/tweakers/radar.png

Neem aan:

V_geluid = 330 m/S
(delta)T = 0,1 S

D = V_geluid * 0,5 * (delta)T
D = 330 * 0,5 * 0,1
D = 16,5 m

En als een PIC op 20Mhz werkt (dus met 5Mhz code uitvoerd), doet hij 5000000 instructies per seconde, +- 5 instructies om 1 tijdlus door te lopen (softwarematig, zonder timer gebruikt dus (die hij on board heeft)), kan hij 1/1000000 sec precies werken.

D = 330 * 0,5 * 0,000001
D = 0,000165 m
D = 0,165 mm nauwkeurig.

Een PIC lijkt mij wel degelijk snel genoeg

En seriele communicatie is een MAX232 overbodig voor dit doeleinde: we hebben nog geen 9600 baud nodig...

[Sprite_tm]

Een vierkantswortel is ook best wel in een pic of avr uit te voeren, voor een idee van code zou je bijvoorbeeld wat ouwe z80-boeken moeten doorkijken, daar is elk algoritme wel voor geschreven. Het enige wat het kost is wat denkwerk en code'en.

En op zich is je temperatuurbereik niet eens heel groot, dus wat je zou kunnen doen is voor een aantal temperaturen de geluidssnelheden in een grote table opslaan (wat weer voor een avr pleit, die kan efficienter tables maken)

Komma-getallen zijn niet eens zo heel lastig te implementeren, zoek es op 'fixed point' en je snapt (hoop ik) wel wat ik bedoel.

Anyway, wat ik wil zeggen is: het is best mogelijk om alle berekeningen in een avr/pic te doen, de beestjes zijn er krahtig genoeg voor hoewel je dat niet zou denken, maar als het apparaat toch altijd aan een compu hangt kun je beter die rekenkracht gebruiken.

[Verwijderd]

Als de berekeningen te lastig worden om in assembly te implementeren (of als je daar gewoon geen zin in hebt), kun je eens kijken naar AVRGCC, dit is een gratis C compiler voor de AVR. Dan heb je helemaal nergens meer last van, en kun je gewoon doubles declareren en sqrt() uitvoeren.

Met AVRGCC is het ook mogelijk om ASM in te voegen, zodat je een combinatie kunt maken met ASM voor het timings-gedeelte en C voor het berekeningsgedeelte.

edit:

Een ingebouwde UART neemt je heel wat werk uit handen. Hij zorgt zelf voor het verzenden van de data. Je hoeft dus niet zelf een stukje programma te schrijven dat de pin laag/hoog maakt, even wacht, het volgende bit pakt, de pin weer laag/hoog maakt etc.

De ingebouwde UART van de AVR (en van de PIC ook) werkt met TTL signalen (0 en 5 volt dus). Je bent dus nog wel een MAX232 nodig.

Let er wel op dat wanneer je seriëel wilt communiceren je vast zit aan bepaalde kristalfrequenties. Wanneer je een AT90S2313 zou gebruiken zou je het beste een 7.3728 of 9.216 MHz. kristal kunnen nemen, zodat je bijna alle baudrates kunt gebruiken. (Denk niet dat die AVR trager loopt dan een PIC. Een AVR loopt namelijk altijd op de echte klokfrequentie, en niet gedeelt door 4 zoals bij de PIC)

Wat ik trouwens ook een voordeel vind aan de AVR is dat hij te flashen is met een zeer simpel schakelingtje. Met deze schakeling zijn alle AVRs te programmeren, dit in tegenstelling tot de meeste PIC16F84 programmers (waar je alleen maar een 16F84 mee kan programmeren).

Een AVR programmer bij circuitsonline:
http://www.circuitsonline.net/circuits/view/112

De ponyprog programmer voor de AVR:
http://www.lancos.com/prog.html

Een 16F84 programmer:
http://www.circuitsonline.net/circuits/view/111

[ Voor 67% gewijzigd door Verwijderd op 14-07-2004 11:36 ]

[Verwijderd]

Verwijderd schreef op 14 juli 2004 @ 10:01:
Als de berekeningen te lastig worden om in assembly te implementeren (of als je daar gewoon geen zin in hebt), kun je eens kijken naar AVRGCC, dit is een gratis C compiler voor de AVR. Dan heb je helemaal nergens meer last van, en kun je gewoon doubles declareren en sqrt() uitvoeren.

Met AVRGCC is het ook mogelijk om ASM in te voegen, zodat je een combinatie kunt maken met ASM voor het timings-gedeelte en C voor het berekeningsgedeelte.

Hmm, nu wordt het wel heel aanlokkelijk (naar mijn mening) om een AVR te gebruiken ipv een PIC...ook al zegt de poll volledig anders. Wat die ingebouwde UART ondersteuning betreft, dat zegt me niets, maar het blijkt toch ook een sterk argument te zijn. Klopt het dat zelf met die ondersteuning er nog steeds nood is aan een MAX232 of zelfgemaakt alternatief?
Als iemand trouwens links heeft over de functie van een comparator is dat ook welkom, dan lees ik dat ook eens door en zie ik waarom dat in ons voordeel zou zijn.

Twee links over AVRGCC:
http://www.avrfreaks.net/AVRGCC/
http://gcc.gnu.org/

[ Voor 7% gewijzigd door Verwijderd op 14-07-2004 10:13 . Reden: Links ]

[3lmowww]

Het schakelingetje wat ik gepost heb, vervangt de max232 volledig, is getest op veel laptops en computers, maar is nog wel nodig, omdat een RS232 poort ndere voltages gebruikt.

Als je bv in JAL de standaard functies van serieele communicatie gebruikt (icm PIC is dat idd), ben je ook niet afhankelijk van kloksnelheden, dat wordt berekent bij het compileren. Serieele communicatie is ook niet erg veel nodig, enkel antwoord geven op een paar vragen vd computer.

Kijk even wat het goedkoopste is. Als er veel vraag is naar geprogrammeerde pic`s, kan ik er een hoop bestellen en erg goedkoop programmeren en leveren via mn bedrijf. avr`s zijn AFAIK duurder en moeilijker te krijgen.

[Verwijderd]

Omdat ik het gevoel heb dat heel wat mensen stilaan beginnen af te haken omdat er geen schot in de zaak komt heb ik de eerste 4 polls afgesloten.

De resultaten:


Duidelijk dus: we proberen eerst zelf onze parabool te maken en pas als het faalt kopen we er een.



Ook dit is duidelijk, de communicatie verloopt via de COM-poort. Hierover staat in de startpost al wat informatie over hoe dit behandelt moet worden in de PIC en hoe op PC.



Iets meer aan elkaar gewaagd dan de poll over de parabool. Ik veronderstel dat heel wat mensen voor de simpele manier gestemd hebben voor volgende redenen:
• PC rekent makkelijker dan PIC/AVR
• De PC zorgt voor weergave en kan dus even goed de berekeningen doen
In dit opzicht ga ik akkoord, maar moet ik zeggen dat door de laatste posts ik toch meer overtuigd ben van de realiseerbaarheid van het mooie systeem. Vandaar stel ik voor eerst te proberen de mooie manier te programmeren, die volgende dingen naar de pc doorstuurt:
• Positie van de radar (positie motor)
• Snelheid voorwerp
• Afstand voorwerp
De andere taken (uitzenden signaal, timen, draaien van sonar) doet de sonar zelfstandig in elk geval.
Als dit niet lukt, laten we volgend doorsturen naar de pc:
• Temperatuur
• Ontvangen frequentie
• timing
en bepalen alles met pc op basis daarvan.



Overtuigende poll, op basis van temperatuur it is. De formule:
v = sqrt( (gamma*R*T) / M )
waarbij v de snelheid is in m/s, gamma = 1,4 , R = universele gasconstante = 8,3143 , M = massa van lucht = (0,2 x 32 + 0,8 x 28)10^-3


De poll tussen PIC/AVR laat ik nog open voor een tijdje, ook al is het wel ongeveer duidelijk dat het een PIC zal worden. Ik heb vandaag weer wat zitten lezen en ook in de C compiler zit niet echt een methode voor een exacte vierkantswortel. Ik vond wel 2 primitieve benaderingsmethoden, maar mits wat zoeken moeten die wel aan te passen zijn of moeten er wel alternatieve methodes te vinden zijn.