Akustiska måltavlor

[grahn]

Det där ser väl lovande ut!
Du kanske kan flytta ut "printf" utanför "while(timeout < time_us_64 && measurementcounter)"-loopen ?
Hur fort cyklar dítt program ?
Vad har picon för upplösning på klockan ? 1mhz ?

[grahn]

Jag ska göra ett sista försök att förklara varför jag hävdar och tror att ljudet som träffar mikrofonen först är genererad en bit ut från målet (beroende på avstånd till mikrofon och mach-vinkel)

Så länge kulans hastighet "va" är lägre än oändlig blir tiden för ljudet att färdas via "c" kortare än tiden för kulan och ljudet att färdas via "a" och "b".
Tiden "a"+"b" kan aldrig vara lägre än "c"

Absolut är tiden "b" kortare än tiden "c" MEN man kan inte bortse från tiden "a" som kulan först måste färdas.

Se det länkade excel-arket:
https://docs.google.com/spreadsheets/d/ ... ue&sd=true

[lasse-a]

Jag ska göra ett sista försök att förklara varför jag hävdar och tror att ljudet som träffar mikrofonen först är genererad en bit ut från målet (beroende på avstånd till mikrofon och mach-vinkel)

Om vi postulerar att det är så: På vilket sätt skulle det påverka inmätningen av kulan menar du?

[grahn]

Om du mäter tiden "c" och räknar som om det är tiden på sträcka "b" blir det självklart fel.
Felet i sig är linjärt men när du sedan lägger på den ökande variabeln i tdoa approximationen så har inte den variabeln samma fel.

[lasse-a]

Om du mäter tiden "c" och räknar som om det är tiden på sträcka "b" blir det självklart fel.
Felet i sig är linjärt men när du sedan lägger på den ökande variabeln i tdoa approximationen så har inte den variabeln samma fel.

Håller helt med. Men vi mäter inte tiden "c" och "b". Vi mäter skillnaden mellan tiden när signalen når mikrofonerna.

Så antag att vi har fyra mikrofoner symmetriskt runt tavlan och på samma avstånd från mitten. Om kulan träffar mitt i då blir skillnaden mellan mikrofonerna noll. Oavsett var kulan är i banan när den genererar vågfronten som träffar. Menar du att felet blir större när vi rör oss bort från centrum?

Jag har inte orkat räkna på det, men det är bra att du gör det!

[Fält]

Det där ser väl lovande ut!
Du kanske kan flytta ut "printf" utanför "while(timeout < time_us_64 && measurementcounter)"-loopen ?
Hur fort cyklar dítt program ?
Vad har picon för upplösning på klockan ? 1mhz ?

Jag har inte en aning om hur fort det går, jag får lägga till ett par prestandaräknare. Det finns en del utrymme för optimering då jag främst ville få konceptet klart, att använda 64 bit variabler är tex ganska korkat.

Klockan går på 1MHz, så 125-133 klockcykler är tillgängliga per klocksteg.

Skarpt öga för måsvingarna! Ja, givetvis skall presentationen vara i while(1) slingan. Jag knappade in den det sista jag gjorde och jag hade mindre skarpt öga för måsvingarna. Då det är en ny fil så behöver jag skriva filer för cmake och allt det där innan jag kan komplilera det.

[grahn]

Jag satte min esp32 till 80Mhz på räknaren och den cyklade på ca 104pulser alltså ca ~1.3us.
1mhz är lite grovt om du vill mäta prestandan på koden en direkt men jag tror/gissar inte det kommer att vara ett problem. Jag gillar det du har gjort!
Klocka cykeltiderna kan vara rätt viktigt för att se att inget annat stör den ibland.
Jag fick ner mina tider från 4-5us till 1.3 om jag gjorde som du och körde while(true) istället för att släppa tillbaka till loop()

Det kan ev vara bättre att behålla 64-bitar än att konvertera och hantera det.

[grahn]

Håller helt med. Men vi mäter inte tiden "c" och "b". Vi mäter skillnaden mellan tiden när signalen når mikrofonerna.

Så antag att vi har fyra mikrofoner symmetriskt runt tavlan och på samma avstånd från mitten. Om kulan träffar mitt i då blir skillnaden mellan mikrofonerna noll. Oavsett var kulan är i banan när den genererar vågfronten som träffar. Menar du att felet blir större när vi rör oss bort från centrum?

Jag har inte orkat räkna på det, men det är bra att du gör det!

Helt rätt jag hävdar att vi mäter dT c/c2 osv men felet blir detsamma.

Om om träffar i mitten blir dT c/c2 0, där håller jag med helt.
Ja det är mitt påstående.
Skjuter du mitt på en mikrofon blir felet som störst.

Jag har räknat på det här.....lite mer än vad som är sunt tror jag
Inte med det sagt att jag HAR rätt men för mig stämmer det i huvudet iaf.

[lasse-a]

Helt rätt jag hävdar att vi mäter dT c/c2 osv men felet blir detsamma.

Om om träffar i mitten blir dT c/c2 0, där håller jag med helt.
Ja det är mitt påstående.
Skjuter du mitt på en mikrofon blir felet som störst.

Jag spenderade just lite tid (alldeles för mycket, men jobbet var tråkigt) för att algebraiskt visa att tiden till punkten vinkelrät från kulans bana är samma som tiden vinkelrät mot Mach-konen (som alltså kommer från en tidigare tidpunkt). Men det går inte. För det är ju fel! (Vilket man faktiskt kan visa geometriskt ganska enkelt).

Så du har övertygat mig på den punkten. Jag borde varit mera ödmjuk, men det spelar ingen roll hur gammal man blir, man lär sig ändå inte. Jag faller tillbaka på det gamla talesättet att det ju inte finns något bättre sätt att lära sig rätt på internet än att ha fel...

Jag lät mig luras av att ljudbangen uppkommer av överlagrade ljudvågor från flera tidpunkter. Men det är bara nästan sant. Vid höga Mach-tal så sker helt riktigt en kompression, dvs övertrycket ("ljudet") i en punkt kommer att ha biddrag från en längre sträcka från kulans färd (eller flygplanet för den delen), men det är inte en perfekt överlagring. (Om det vore det så fick man faktiskt ingen kon!) Så pga geometrin så blir skillnaden i väg/tid inte så stor som man skulle kunna tro, men den finns där. Det blir överlagring (därav "ljudbang") men den blir distribuerad över ett tunt band.

Jag är inte övertygad om att det leder till mätfel än. Jag får faktiskt sätta mig ner och göra beräkningarna för de olika situationerna, men nyligen vis av skadan så skall jag inte tvärsäkert säga att du har fel!

Jag har räknat på det här.....lite mer än vad som är sunt tror jag

Omöjligt! Man kan aldrig räkna för mycket!

Inte med det sagt att jag HAR rätt men för mig stämmer det i huvudet iaf.

Ja, den som skall vara svårast att övertyga skall vara en själv som Feynman lärde.

[Fält]

Jag ska göra ett sista försök att förklara varför jag hävdar och tror att ljudet som träffar mikrofonen först är genererad en bit ut från målet (beroende på avstånd till mikrofon och mach-vinkel)

Nu är jag med på vad du menar, för något år sedan var jag inne på samma linje som dig. Men när jag provade att göra ett par överslagsberäkningar så stämde det inte. Men nu har jag räknat igen och kom fram till att det beror vilka värden man väljer.

Jag gjorde fem serier i excel där jag berknade tiden det tar för kulan att nå mikrofonernas linje och för ljudet att nå mikrofonerna från den punkten. Från den så subtraherade jag tiden det tog för ljudet att nå från den ursprungliga punkten till mikrofonen.

Det är en serier per avstånd i meter mellan kulan och mikrofonen. Farten är 680m/s och ljudets hastighet är vald till 340m/s.

På y är felet i millisekunder och på x är avståndet mellan kulan och mikrofonernas plan. När värdet är positivt så finns det ett fel, när det är negativt så finns inget fel. Felet krymper med stigande fart och stiger kraftigt när farten minskar, det är helt tydligt att farten måste mätas.

Tidsfel.png

[Fält]

Jag satte min esp32 till 80Mhz på räknaren och den cyklade på ca 104pulser alltså ca ~1.3us.
1mhz är lite grovt om du vill mäta prestandan på koden en direkt men jag tror/gissar inte det kommer att vara ett problem. Jag gillar det du har gjort!
Klocka cykeltiderna kan vara rätt viktigt för att se att inget annat stör den ibland.
Jag fick ner mina tider från 4-5us till 1.3 om jag gjorde som du och körde while(true) istället för att släppa tillbaka till loop()

Det kan ev vara bättre att behålla 64-bitar än att konvertera och hantera det.

Skumt att det blev skillnad när du körde while(true) istället för att köra hela main(). Men jag såg mycket kommentarer om att ESP har en hel del hyss för sig när jag kollade på den. Som att något ligger och gör saker i bakgrunden hela tiden.

Picon klarar av att hoppa in i en interrupt och ändra en pinne på ca 200ns, men det finns risk för kollisioner och hinner den här snurran gå genom på en us så tycker jag att vi nått målet. Nu när vi andra förstått att vi måste mäta frarten så kommer det väl tillhands då det är mycket lätt att lägga till fler mätningar i den koden. Min tanke är att vi dubblar alla mikrofoner, så ger det även redundans.

För att mäta exekveringstid på enstaka instruktioner så finns andra klockor tillgängliga.

Istället för att använda 64 bitars värden som flaggor tänkte jag använda lättviktigare variabler som jag sätter samtidigt som 64 bitars värdet. Eller bara använda pekare och bara titta på den lägre delen av 64 bitars värdet.

[Fält]

https://docs.google.com/spreadsheets/d/ ... sp=sharing

[Fält]

Det där ser väl lovande ut!
Du kanske kan flytta ut "printf" utanför "while(timeout < time_us_64 && measurementcounter)"-loopen ?
Hur fort cyklar dítt program ?
Vad har picon för upplösning på klockan ? 1mhz ?

Nu har jag lagat oändligt med fel, c tycks vara lite tjurigare med villkor nu än när jag lärde mig på amigan. Eller så har jag glömt hur man gör.

64 bit jämförelser kombinerade med andra vilkor i en while loop tycks dra lite mer än jag trodde. När jag provade så gick snurran på 1.4us. När jag tog bort timeout < time_us_64 så gick den ner till 0,52us. Då är timeout < time_us_64 tillagd i en if inne i slingan för att skriva ut värdet på performance counter var femte sekund. Så något oförutsett sker i kompileringen som gör att det tar lång tid.

Men då koden gör en del onödigt nu som bara finns nu när det provas, så tror jag att det här ger tillräcklig prestanda för att garantera att man får alla tider inom en 1us och jag hoppas att det skall gå att putsa till det lite mer.

[grahn]

Jag låg med en stöddig förkylning i helgen så jag passade på att roa mig med lite kodning...
Eftersom ni jobbar på med hårdvarunära gick jag det andra spåret och kikade på HMI.
Eftersom jag hoppas och tror att jag ska kunna hålla webservern så nätt som möjlig hårdvarumässigt testade jag att göra en HMI med minimalt med dataöverföring men med rätt hyffsat med funktioner.
Gjord för både touch och mus.

Det här kan ni prova lägga på en webserver vilken som:
https://github.com/johangrahn81/MiniShotServer
Det som behövs utöver det ovan är en "/img/" mapp med 2st bilder. "1.svg" och "2.svg" (ifall ni vill byta "tavla"....1px=1mm)

Tänk på att det bara är ett snabbt utkast....mer ett proof of concept mer än något annat.
"data.json" innehåller träff-data för varje skott.

Jag har kört det på en Esp32 och den löser det med en klackspark
https://github.com/johangrahn81/EspShotServer

[Fält]

Jag låg med en stöddig förkylning i helgen så jag passade på att roa mig med lite kodning...
Eftersom ni jobbar på med hårdvarunära gick jag det andra spåret och kikade på HMI.
Eftersom jag hoppas och tror att jag ska kunna hålla webservern så nätt som möjlig hårdvarumässigt testade jag att göra en HMI med minimalt med dataöverföring men med rätt hyffsat med funktioner.
Gjord för både touch och mus.

Det här kan ni prova lägga på en webserver vilken som:
https://github.com/johangrahn81/MiniShotServer
Det som behövs utöver det ovan är en "/img/" mapp med 2st bilder. "1.svg" och "2.svg" (ifall ni vill byta "tavla"....1px=1mm)

Tänk på att det bara är ett snabbt utkast....mer ett proof of concept mer än något annat.
"data.json" innehåller träff-data för varje skott.

Jag har kört det på en Esp32 och den löser det med en klackspark
https://github.com/johangrahn81/EspShotServer

Toppen, det är en av sakerna som jag var mest orolig för att kunde bli lite krånglig. Kul att det fungerar på en ESP redan. Jag satte upp en lighttpd, men jag får nog läsa manualen på den då det tycks finnas något problem med rättigheterna.

Har du möjlighet att posta en bild på hur interfacet ser ut, så kan jag kolla på att få igång det här i lugn och ro senare?

[grahn]

Japp det kan jag men det blir imorgon.

[grahn]

Jag gjorde en skärminspelning idag.
Sidan körs här på en Esp32 som agerar webserver och accesspunkt.
https://drive.google.com/file/d/1RO1MWe ... sp=sharing

[Fält]

Det där ser väldigt bra ut!

Jag fick några vanliga mikrofoner idag så att jag kan prova med luftgevär och papperstavla här hemma.

[Fält]

Tråkigt när annat kommer mellan och stör ens hobbyprojekt!

Jag har haft tid att tänka lite på det här igen och tänker försöka få tid att bygga en liten måltavla med kammare. Det ger möjlighet att prova elektroniken utan att behöva brottas med kulans hastighet och de problem som kommer med det.

Har någon tittat på hur vi kan kompensera för kulans hastighet för mätningen med tryckvåg?