---

Hej Alle

Jeg leder efter en nifty måde at detektere subj. på. Situationen er den at
jeg måler på et signal der kan antage 7 niveauer svarende til 7 tilstande.
For at undgå støj og deslige, skal jeg måle 3 ens målinger i streg før jeg
med sikkerhed kan sige at der er skiftet tilstand. Det jeg så leder efter er
en smart måde at gøre dette på. Man kan selvfølgelig gøre det ved hjælp af
en række medlemsvariabler, hvilket jeg ikke synes er særlig smart eller
økonomisk (Det er til et embedded system, så pladsforbrug er et seriøst
emne)
Jeg har pt. gjort det på følgende måde:

//Jeg har et medlems array med 3 pladser - Position er en enum der består af
de 7 mulige tilstande.

Position m_lastPositions[3;]

//Når jeg så foretager en måling gør jeg følgende for at se om der har været
3 ens målinger.
m_lastPositions[0] = m_lastPositions[1];

m_lastPositions[1] = m_lastPositions[2];

m_lastPositions[2] = measuredPosition;


if(m_currentPosition != m_lastPositions[2])

{

if(m_lastPositions[0] == m_lastPositions[1] && m_lastPositions[1] ==
m_lastPositions[2])

{

m_currentPosition = m_lastPositions[2];

}

}

Medlemsvariablen m_currentPosition indeholder så hele tiden den tilstand som
er den sidst gældende.

Findes der en smartere/hurtigere/mere pladsbesparende måde at det her på?

Mvh
Søren

---

Hansen wrote:
> Hej Alle
>
> Jeg leder efter en nifty måde at detektere subj. på. Situationen er den at
> jeg måler på et signal der kan antage 7 niveauer svarende til 7 tilstande.
> For at undgå støj og deslige, skal jeg måle 3 ens målinger i streg før jeg
> med sikkerhed kan sige at der er skiftet tilstand. Det jeg så leder efter er
> en smart måde at gøre dette på. Man kan selvfølgelig gøre det ved hjælp af
> en række medlemsvariabler, hvilket jeg ikke synes er særlig smart eller
> økonomisk (Det er til et embedded system, så pladsforbrug er et seriøst
> emne)
> Jeg har pt. gjort det på følgende måde:
>
> //Jeg har et medlems array med 3 pladser - Position er en enum der består af
> de 7 mulige tilstande.
[snip]
> Findes der en smartere/hurtigere/mere pladsbesparende måde at det her på?

Du har ikke brug for at gemme tre målinger, hvis ikke de er ens så
er de ligegyldige.
Det burde være nok at gemme den seneste måling og have en tæller
der tæller hvor mange ens målinger du har.
Når du får en ny måling skal du så checke om det er den samme værdi
som den gemte, hvis den er, tæller du tælleren op, og checker om
du har tre ens, hvis ikke de er ens gemmes denne måling og tælleren
sætttes til 0.
Variablen der husker sidste måling bør initialiseres til en invalid
måleværdi når du starter op.

--
Absolutely not the best homepage on the net:
http://home20.inet.tele.dk/midgaard
But it's mine - Bertel

---

Den Mon, 25 Jul 2005 12:07:58 +0200 skrev Bertel Brander:
> Hansen wrote:
>> Hej Alle
>>
>> Jeg leder efter en nifty måde at detektere subj. på. Situationen er den at
>> jeg måler på et signal der kan antage 7 niveauer svarende til 7 tilstande.
>> For at undgå støj og deslige, skal jeg måle 3 ens målinger i streg før jeg
>> med sikkerhed kan sige at der er skiftet tilstand. Det jeg så leder efter er
>> en smart måde at gøre dette på. Man kan selvfølgelig gøre det ved hjælp af
>> en række medlemsvariabler, hvilket jeg ikke synes er særlig smart eller
>> økonomisk (Det er til et embedded system, så pladsforbrug er et seriøst
>> emne)
>> Jeg har pt. gjort det på følgende måde:
>>
>> //Jeg har et medlems array med 3 pladser - Position er en enum der består af
>> de 7 mulige tilstande.
> [snip]
>> Findes der en smartere/hurtigere/mere pladsbesparende måde at det her på?
>
> Du har ikke brug for at gemme tre målinger, hvis ikke de er ens så
> er de ligegyldige.
> Det burde være nok at gemme den seneste måling og have en tæller
> der tæller hvor mange ens målinger du har.
> Når du får en ny måling skal du så checke om det er den samme værdi
> som den gemte, hvis den er, tæller du tælleren op, og checker om
> du har tre ens, hvis ikke de er ens gemmes denne måling og tælleren
> sætttes til 0.
> Variablen der husker sidste måling bør initialiseres til en invalid
> måleværdi når du starter op.

Hvis man initialiserer tælleren til 0, og ellers tæller fra 1, burde
det ikke betyde noget hvad sidste måling initialiseres til. Det er måske
bare mig, men jeg bryder mig generelt ikke om initalisering til ugyldige
værdier - de ender altid med at blive gyldige når man mindst venter det.

(Var der ikke noget med at det var populært at bruge 9/9-99 som ugyldig
dato i cobol-programmer?)

Mvh
Kent
--
Hard work may pay off in the long run, but lazyness pays off right now.

---

Kent Friis wrote:
>>Variablen der husker sidste måling bør initialiseres til en invalid
>>måleværdi når du starter op.
>
>
> Hvis man initialiserer tælleren til 0, og ellers tæller fra 1, burde
> det ikke betyde noget hvad sidste måling initialiseres til. Det er måske
> bare mig, men jeg bryder mig generelt ikke om initalisering til ugyldige
> værdier - de ender altid med at blive gyldige når man mindst venter det.

I så fald skal man teste om værdien er 0 først, hvis den er det skal
man ikke checke sidste værdi; det giver lidt ekstra kode.

Da der kun var 7 gyldige tilstande og disse er elementer i en enum
skulle det ikke være et problem at finde en ugyldig værdi.

--
Absolutely not the best homepage on the net:
http://home20.inet.tele.dk/midgaard
But it's mine - Bertel

---

Den Mon, 25 Jul 2005 19:52:33 +0200 skrev Bertel Brander:
> Kent Friis wrote:
>>>Variablen der husker sidste måling bør initialiseres til en invalid
>>>måleværdi når du starter op.
>>
>>
>> Hvis man initialiserer tælleren til 0, og ellers tæller fra 1, burde
>> det ikke betyde noget hvad sidste måling initialiseres til. Det er måske
>> bare mig, men jeg bryder mig generelt ikke om initalisering til ugyldige
>> værdier - de ender altid med at blive gyldige når man mindst venter det.
>
> I så fald skal man teste om værdien er 0 først, hvis den er det skal
> man ikke checke sidste værdi; det giver lidt ekstra kode.

Nej.

if(current==last) count++;
else {
last=current;
   count=1;
}

første gennemløb, current==last:

før: count==0
efter: count==1

første gennemløb, current!=last:

før: count==0
efter: count==1

Mvh
Kent
--
Hard work may pay off in the long run, but lazyness pays off right now.

---

Kent Friis wrote:
> Den Mon, 25 Jul 2005 19:52:33 +0200 skrev Bertel Brander:
>
>>Kent Friis wrote:
>>
>>>>Variablen der husker sidste måling bør initialiseres til en invalid
>>>>måleværdi når du starter op.
>>>
>>>
>>>Hvis man initialiserer tælleren til 0, og ellers tæller fra 1, burde
>>>det ikke betyde noget hvad sidste måling initialiseres til. Det er måske
>>>bare mig, men jeg bryder mig generelt ikke om initalisering til ugyldige
>>>værdier - de ender altid med at blive gyldige når man mindst venter det.
>>
>>I så fald skal man teste om værdien er 0 først, hvis den er det skal
>>man ikke checke sidste værdi; det giver lidt ekstra kode.
>
>
> Nej.
>
> if(current==last) count++;
> else {
> last=current;
>    count=1;
> }
>
> første gennemløb, current==last:
>
> før: count==0
> efter: count==1
>
> første gennemløb, current!=last:
>
> før: count==0
> efter: count==1

Smart

--
Absolutely not the best homepage on the net:
http://home20.inet.tele.dk/midgaard
But it's mine - Bertel

---

To kommentarer:

1) Du kunne måske (du har ikke skrevet så meget ...) også bruge et lille
digitalt FIR / IIR filter, og så slå op i en tabel, hvilken state en given
værdi modsvarer.
Nogen elsker filtre og de egenskaber der følger med dette. Til gængæld
mister du evnen til at sige på en simpel måde at inputtet skal være stabilt
5 gange i træk á 10. ms = 50 ms for at du gør et eller andet. Med filtre
bliver det noget med at sige, at man når 98 % af slutværdien efter 3 tau
(tidskonstanter for filtret), hvilket får det hvide frem i nogens øjne. Der
er fordele og ulemper ved alt ....

> 7 niveauer svarende til 7 tilstande. For at undgå støj og deslige, skal
> jeg måle 3 ens målinger i streg før jeg med sikkerhed kan sige at der er
> skiftet tilstand

2) Så vil jeg jo fundementalt sige at du har (mindst) 8 tilstande hvis man
regner "Input Not Stable" med.
Jeg gætter på at din applikation måske er tilfreds med sidste valide
tilstand, så hvis variablen blot skifter når den nye tilstand er opnået, så
virker applikationen måske som den skal.
Principielt synes jeg dog at det er driverens opgave at afspejle verden så
godt den kan, og så lade det være op til din ovenliggende applikation at
tage det aktive valg, at sidste måling er godt nok.

(- og JA, idéen om "driver" og "applikation" holder også i små embeddede
systemer)

tpt