Akustiska måltavlor

[lone_wolf]

Börjar undra om ni läser vad jag skriver
Trianguleringsformel finns ovan, både min version och en länk till kanonvarianten.
...

Löste du för z? Det såg ut att bli ganska långa och många substitueringar.

[Bjerker]

Nu ska vi se om det går att förstå hur jag tänker. Blå cirklar = referens där allt går ihop. Skalar vi nu om mätvärdena med plus 50%, typ en temperatursänkning på 100°C, så får vi de röda cirklarna. Nu går det bra att rita in en ny träffpunkt som stämmer med tre mätpunkter, men inte den fjärde.

Min tes är att det ska gå att skala mätvärdena tills alla fyra träffar en båge. Träffpunkten är då i bågens centrum.

Hitta en algoritm för detta med mattekunskaper som somnat in sen 30 år ligger bortom min förmåga.

SnipImage.jpg

Skickat från min Lenovo TB-X606X via Tapatalk

[Ellemam]

Den pdf jag länkade till ovan har ju en noggrannhet på 0,25mm vilket kväver 0,7us.

Frågan är vilken exakthet man tycker är ok? Man kan nog komma undan den extra klock-kretsen om man säkert kravet något.

Sent from my SM-A528B using Tapatalk

[kattafan]

Börjar undra om ni läser vad jag skriver
Trianguleringsformel finns ovan, både min version och en länk till kanonvarianten.
...

Löste du för z? Det såg ut att bli ganska långa och många substitueringar.

Ja, gjorde jag inte det? y och z är kända.
Hypotenusorna är x, x+y, x+z
Vi behöver a och b som båda kan skrivas om som funktioner av x.

Men jag kan som sagt ha missat nåt kapitalt, isåfall vill jag gärna veta.

[kattafan]

Den pdf jag länkade till ovan har ju en noggrannhet på 0,25mm vilket kväver 0,7us.

Frågan är vilken exakthet man tycker är ok? Man kan nog komma undan den extra klock-kretsen om man säkert kravet något.

Sent from my SM-A528B using Tapatalk

Sius och Megalinktavlorna presenterar resultat på milimetern när på 300m. Detta med hjälp av 3 mikrofoner i underkant av måltavlan, en griffeltavla och en coaxialkabel.
ShotMarker är godkänd för tävlingar i Norge och säger själva att 1mm är under perfekta förhållanden men 2-3mm är rimligare i blandade förhållanden

[Fält]

Den pdf jag länkade till ovan har ju en noggrannhet på 0,25mm vilket kväver 0,7us.

Frågan är vilken exakthet man tycker är ok? Man kan nog komma undan den extra klock-kretsen om man säkert kravet något.

Sent from my SM-A528B using Tapatalk

Med en så mycket snabbare processor som en ESP32 så tror jag att man löser det utan problem och jag tror att 1mm duger för en applikation som den vi talar om.

[Ellemam]

Det borde gå att få i arduino uno med utan extern Counter om man får till att det här triggas av mikrofonerna.

http://www.gammon.com.au/timers

[Fält]

Det borde gå att få i arduino uno med utan extern Counter om man får till att det här triggas av mikrofonerna.

http://www.gammon.com.au/timers

Jag tror inte att det går att få till i en UNO då den bara har en input capture. Även om man skulle koppla alla mikrofonerna till samma ingång med lite logik så kan ljudet nå fram till dem samtidigt.

Det finns andra ATMega processorer som har fler input captures, ATMega 640, 1280 och 2560 har fyra input captures och används till Arduino kort.

Jag började titta på hur mycket interrupt latency det är i en ESP32 och det verkar finnas problem som gör att det är väldigt långsamt! De talar om 1.7-2uS, tydligen finns det optimeringar för vissa interrupts, men inte för alla. Så det är lite oklart vad som gäller just nu.

[Ellemam]

Det borde gå att få i arduino uno med utan extern Counter om man får till att det här triggas av mikrofonerna.

http://www.gammon.com.au/timers

Jag tror inte att det går att få till i en UNO då den bara har en input capture. Även om man skulle koppla alla mikrofonerna till samma ingång med lite logik så kan ljudet nå fram till dem samtidigt.

Det finns andra ATMega processorer som har fler input captures, ATMega 640, 1280 och 2560 har fyra input captures och används till Arduino kort.

Jag började titta på hur mycket interrupt latency det är i en ESP32 och det verkar finnas problem som gör att det är väldigt långsamt! De talar om 1.7-2uS, tydligen finns det optimeringar för vissa interrupts, men inte för alla. Så det är lite oklart vad som gäller just nu.

Arduino Due verkar vara en vettig kandidat.

Sent from my SM-A528B using Tapatalk

[Fält]

Arduino Due verkar vara en vettig kandidat.

Sent from my SM-A528B using Tapatalk

Jag tittade på den för en stund sedan men blev distraherad, jag hittade inte hur många input captures den har.

Den hade däremot ganska usel interrupt latency, men det gör inget alls om den har tillräckligt många input captures.

[kattafan]

får hem en micro pro på fredag. Den har fem interrupt.
.Har provat med 2 mikrofoner nu och är på väg att slänga ut skiten genom fönstret. Först fick jag det till att uppföra sig konsekvent, när jag knäppte nära ettan visade den värden först, när jag knäppte nära tvåan reagerade den först. Men.. dessa jävla studsar.. Blev typ 1.1.1.1.2.2.1.2 sen 2.2.2.2.1.1.1 osv.

Så, jag testade olika sätt och har lyckats få bort studsar men nu blir värdena helt åt helvete istället. Vill ju inte lägga in några millisekunders väntan som man gör annars så var tvungen att vara kreativ.

Får fundera lite över natten.

Edit: Medan jag kyler ner hjärnan. Hur skulle ni skriva koden för att mäta tiden för reaktion i mick 1 och 2? Digital insignal

[Fält]

Jupp, studsandet måste hanteras. Om man inte har snabba interrupts (som ju inte tycks finnas på någon plattform ) så behöver det hanteras innan signalen når microprocessorn. En SR vippa är det enkaste första steget, då blir det bara en signal. Sedan måste man nollställa den. Om det räcker för den färdiga applikationen vet jag inte.

Arduino Micro Pro använder en ATMega 32u4, den har två input captures. Så det går att få maximal precision på två mikrofoner. Det är en början, skulle det visa sig fungera bra för två men inte med fler, så finns Mega2560 kortet med fyra input captures.

För att vara lite övertydlig, en input capture och en interrupt är två helt olika saker.

* En input capture skriver först upp tiden som något hände, sedan kan man välja om den även skall skapa en interrupt.

* En interrupt får processorn att spara allt som behövs för att kunna fortsätta på samma ställe (det är det som gör att det blir långsamt) och sedan börja köra den nya koden. Det senare innebär att det tar ganska lång tid innan vi själva kan spara tiden då något hände.

Om man kör en busy loop för en av mikrofonerna och låter input captures hantera de andra två så är inga interrupts inblandade. Att hela tiden "fråga" en pinne om status och sedan spara tiden när något händer är snabbt. Men man får inte göra något annat som använder interrupter under tiden.

[Fält]

Edit: Medan jag kyler ner hjärnan. Hur skulle ni skriva koden för att mäta tiden för reaktion i mick 1 och 2? Digital insignal

Jag skulle börja med att försöka hitta någon annan som skrivit koden då det är ett väldigt bläddrande i databladen på processorn för att använda en timer riktigt:
Video: https://www.youtube.com/watch?v=N5VQZTDNcj0
Kod: https://akuzechie.blogspot.com/2020/11/ ... duino.html

Edit:
I koden så har han ställt prescalern på 1024, det ger den lägsta precisionen man kan ha och är kanske inte rätt för det du provar. Jag skrev några varianter på den intressanta raden och tog fram lite tider och även hur lång väg ljudet når vid 340m/s vid den tiden.
TCCR1B |= 0b11000101; //set 1024 prescaler, rising edge, noise canceler - 64us. . Max tid 4.19s, 21.76mm precision
TCCR1B |= 0b11000100; //set 256 prescaler, rising edge, noise canceler - 16us
TCCR1B |= 0b11000011; //set 64 prescaler, rising edge, noise canceler - 4us. Max tid 0.26s, 1.36mm precision
TCCR1B |= 0b11000010; //set 8 prescaler, rising edge, noise canceler - 0,5us. Max tid 0.0327s
TCCR1B |= 0b11000001; //set 1 prescaler, rising edge, noise canceler - 0,0625us. Max tid 0.0041s
Edit, fixade ett fel.

[lone_wolf]

Om den ursprungliga designen är gjord för något 10-tal år sen så är den troligen baserad på analog filtrering av inkommande signal. Eventuellt en analog integrering som säkerställer att ljudbangen är tillrägligt hög för att klassas som en triggning. Ekon är svagare och faller bort.

Man kan ju också bygga logik i mätalgoritmen som bara godkänner triggningar inom det maximala tidsfönster som storleken på tavlan kan ge upphov till.

[lasse-a]

För att vara lite övertydlig, en input capture och en interrupt är två helt olika saker.

* En input capture skriver först upp tiden som något hände, sedan kan man välja om den även skall skapa en interrupt.

* En interrupt får processorn att spara allt som behövs för att kunna fortsätta på samma ställe (det är det som gör att det blir långsamt) och sedan börja köra den nya koden. Det senare innebär att det tar ganska lång tid innan vi själva kan spara tiden då något hände.

Just. Och att få interupt-baserad tidmätning att fungera är i stort sett omöjligt. Latensen är variabel och relativt stor.

[lasse-a]

får hem en micro pro på fredag. Den har fem interrupt.
.Har provat med 2 mikrofoner nu och är på väg att slänga ut skiten genom fönstret. Först fick jag det till att uppföra sig konsekvent, när jag knäppte nära ettan visade den värden först, när jag knäppte nära tvåan reagerade den först. Men.. dessa jävla studsar.. Blev typ 1.1.1.1.2.2.1.2 sen 2.2.2.2.1.1.1 osv.

Så, jag testade olika sätt och har lyckats få bort studsar men nu blir värdena helt åt helvete istället. Vill ju inte lägga in några millisekunders väntan som man gör annars så var tvungen att vara kreativ.

Får fundera lite över natten.

Edit: Medan jag kyler ner hjärnan. Hur skulle ni skriva koden för att mäta tiden för reaktion i mick 1 och 2? Digital insignal

Jag är inte säker på att jag förstår vad problemet med studsar (eko antar jag) kommer bli i den riktiga applikationen. Fördelen med bogvågsknallen är att den är det första som kommer komma fram till mikrofonen. Så har en mikrofon triggat en gång så låser man in det värdet och så är det klart.

Man undviker falsktriggningar genom att ställa sin förstärkning lågt och bara trigga över en viss nivå. Bogvågsknallen är +100 dB så det fungerar väl.

[kattafan]

Med studs menar jag inte eko. Jag menar på samma sätt som med en mekanisk tryckknapp, att det blir flera tryck istället för ett. Samma med ljudet, det är längre än vad mätcykeln är så det triggar flera värden efter varandra

Jag får läsa på vad input captures är, det lät intressant.

[lasse-a]

Med studs menar jag inte eko. Jag menar på samma sätt som med en mekanisk tryckknapp, att det blir flera tryck istället för ett. Samma med ljudet, det är längre än vad mätcykeln är så det triggar flera värden efter varandra

Ah. Då behöver du "avstudsa". Det gör man traditionellt med extern krets (ngn form av vippa som Fält säger), men sedan länge så gör man det i mjukvara istället. När man triggat så blockerar man ut triggningen så lång tid att ev. studsar hunnit dö ut. Sedan så öppnar man den igen.

Man använder en liknande funktion för att öka störkänsligheten hos knappar. Om man får en triggpuls så väntar man en viss (ganska lång tid) och kollar om man fortfarande triggat. Om man har det (dvs knappen fortfarande är nere) så går man vidare. Annars så ignorerar man och återställer. Väntetiden när det rör sig om en knapp är ofta "människo-stor" dvs en eller flera tiondels sekunder.

Hos en viss hisstillverkare (kommer inte ihåg vilken nu) så kunde man se det här fenomenet. Om man tryckte på knappen fort så hann lysdioden blinka till, men knapptryckningen "tog inte". Detta för att man väntade flera tiondels sekunder innan man kollade knappen igen och då hade man redan hunnit att släppa den.

[kattafan]

Med studs menar jag inte eko. Jag menar på samma sätt som med en mekanisk tryckknapp, att det blir flera tryck istället för ett. Samma med ljudet, det är längre än vad mätcykeln är så det triggar flera värden efter varandra

Ah. Då behöver du "avstudsa". Det gör man traditionellt med extern krets (ngn form av vippa som Fält säger), men sedan länge så gör man det i mjukvara istället. När man triggat så blockerar man ut triggningen så lång tid att ev. studsar hunnit dö ut. Sedan så öppnar man den igen.

Man använder en liknande funktion för att öka störkänsligheten hos knappar. Om man får en triggpuls så väntar man en viss (ganska lång tid) och kollar om man fortfarande triggat. Om man har det (dvs knappen fortfarande är nere) så går man vidare. Annars så ignorerar man och återställer. Väntetiden när det rör sig om en knapp är ofta "människo-stor" dvs en eller flera tiondels sekunder.

Hos en viss hisstillverkare (kommer inte ihåg vilken nu) så kunde man se det här fenomenet. Om man tryckte på knappen fort så hann lysdioden blinka till, men knapptryckningen "tog inte". Detta för att man väntade flera tiondels sekunder innan man kollade knappen igen och då hade man redan hunnit att släppa den.

Jo, jag vet hur man avstudsar, men det påverkar input från det andra interruptet verkar det som. Ska kolla över utifrån inte idéer jag fick innan om det går att fixa.

Edit: Jag provade att helt sonika stänga av interruptet när det triggade första gången, det gav fina värden men är lite skeptisk till att det är en bra idé

[lasse-a]

Jo, jag vet hur man avstudsar, men det påverkar input från det andra interruptet verkar det som. Ska kolla över utifrån inte idéer jag fick innan om det går att fixa.

Edit: Jag provade att helt sonika stänga av interruptet när det triggade första gången, det gav fina värden men är lite skeptisk till att det är en bra idé

Ja ursäkta, jag har en tendens att förklara allt som för en tvååring (yrkesskada), så jag får be om ursäkt för det.

Då är jag inte säker på att jag förstår riktigt hur det är gjort. Du har två interrupts till två olika ingångar som triggar en interrupt-rutin? Och i din rutin så lagrar du bara värdet på en global timer i en variabel? Det enda du behöver göra då är att sätta variabeln/variablerna (glöm inte att deklarare dem "volatile") till noll när du börjar. I din ISR så kollar du om den är noll, och sätter den då till timervärdet (micros()). Om den är skild från noll så gör du ingenting eftersom vi då redan har triggat på ett värde. Detta blir din mjukvaru-avstuds.

I din huvudrutin så gör du dina beräkningar och sätter sedan räknarvariablerna till noll igen när du är klar. Ev så slutar du med en fördröjning för att inte trigga på en "studs" för tidigt.

Att stänga av interrupt kan man göra på två sätt. Dels så kan man stänga av dem (cli, sti), och det är generellt en dålig idé. Timers och annat slutar fungera om man har interrupt avstängda någon längre tid. Så det skall man egentligen bara använda i kritiska sektioner (och då egentligen kolla vad de är innan och återställa). Om du menar avregistrera avbrottet så kan det nog göras utan större problem om man gör det på HW-nära nivå (se exv. här: http://gammon.com.au/interrupts, men det tar antagligen längre tid än att bara göra en jämförelse pss som ovan.

Tillförde det något?