Lite tokigt med att det här blev två trådar men då jag ändå tänkte filtrera resultatet, och har fått förslag på hur, så behåller jag nog det så här.
Ungarna hade framme smältpickan för lite pyssel så jag passade på att limma fast en hylsa över sensorn. Eventuellt ska jag korta ner röret en aning. Modden med före och efter-bild syns nedan. Oj vilken skillnad det blev på resultatet!
Har också bifogat 10 samples utan och 10 samples med röd pärla. Nu tycker jag det ser bättre ut.
Japp, det blev mycket bättre separation, men någonting är fortfarande knas med korrelerade sampel. Titta på grafen över dina sampel nedan. De tjocka linjerna är din referens, och de tunna linjerna är när sensorn tittar på en röd pärla.
take2.png
Den röda kurvan är den som ändrats mest mellan testen, och det är ju rimligt och bra. Frågan är om det vi ser är bra nog när du skall separera många färger. För att utröna det behövs mera data, och det kan vi återkomma till.
Notera att alla kurvorna verkar bete sig periodisk. Svårt att säga med så få sampel, men det ser ut så. Hade samplena varit oberoende hade det sett mera stokastiskt ut, slumpmässigt upp eller ner längs kurvan. Det hade varit bra att röka ut detta problemet. Ignorerar du det kommer det antagligen att bita dig senare
Undrar också hur du kan få ut så stora heltal ur en 10-bitars omvandlare? Kan du ta nya "referens-sampel" med enfärgade ytor så kan man plotta in de värdena också i grafen?
Du har inte behörighet att öppna de filer som bifogats till detta inlägg.
Nu vet jag inte hur det är byggt mekaniskt, men en tanke är ju att det är ljus från omgivningen som påverkar? Det ljuset är ju antagligen "modulerat" med 50 eller 100 Hz och kan ju då ge periodiska störningar?
Men är mätningarna gjorda så att pärlan bara utsätts för ljuset från de fyra lysdioderna på modulen så är det ju knappast det felet.
Nej det är nog något att bita i det här...Efter modden så är sensorn extremt känslig för placeringen av pärlan (givetvis). Så en bättre rigg krävs!
Det får bli en 3D-printing så det går att få ärlig repeterbarhet vid pärlbyte.
Tror inte heller att något yttre ljus kommer in då jag direkt ser i mörkret om min mätare inte tätar riktigt mot boken.
Gör gärna fler mätningar gruckrum men det är nog något knas ändå. Det finns väl ingen anledning som helst att värdena ändå varierar så här mycket när jag belyser en helt svart yta?
Rullade tom från skrivbordet och det finns verkligen inget fysiskt som kunde påverka mätningen.
Den senaste rundan ser mycket bättre ut! Kanske är det bara för att det är fler sampel än tidigare. Två frågor:
1. Hur ofta samplar du? (Och vilka frekvenser är det som skall mätas?)
2. Hur kan du få heltalsvärden som vida överstiger 10 bitar?
Kanske skall jag läsa på de referenser du skickat, jag har inte alls kollat hur det du byggt egentligen fungerar.
Att det brusar är helt normalt, det viktiga är att bestämma hur mycket (och gärna varför, samt ta reda på om det är i samma nivå som man förväntar sig teoretiskt. Annars kan man ju göra bättre.) Du får gärna mäta på några pärlor i olika färger, minst 100 sampel per pärla.
Ligger pärlan fixerad på ett exakt vis, eller kan det vara så att en pärla kan hamna i olika orienteringar i sensorn och därmed ge olika värden ut, tro?
Du har inte behörighet att öppna de filer som bifogats till detta inlägg.
@guckrum:
Sensormodulen fungerar så här:
Genom att ställa 2 ingångar på modulen som hög/låg (dvs 4 kombinationer) så bestämmer jag vad jag vill få levererat på ut-pinnen. Antingen R, G, B eller Ofiltrerad.
Modulen innehåller en ström-till-frekvens-omvandlare och det är denna frekvens jag mäter på utgången.
Pulsen är alltid 50% i pulsbredd så man kan nog likaväl mäta pulsbredd som frekvens för att få ett relativt värde.
Det finns även 2 andra ingångar där jag kan ställa skalningen på utsignalen. 2%, 20%, eller 100%. Minns inte vad jag hade nu senast med har oftast använt 20%.
I originalkoden så satte man "RGB+O"-pinnarna till en färg, läste direkt ut frekvensen/pulsbredden och presenterade dessa. Sen direkt över till nästa färg.
I det senaste resultatet så la jag in en 100ms väntan mellan omställning av registret (MUX:en?) och avläsning av frekvens. Tänkte att det kanske behövdes för att stabilisera signalen.
Som svar på fråga 1 så samplar jag i nuläget alltså i ca 3Hz. Tyvärr är lekbordet undanplockat så kan inte koppla upp skopet igen men beroende på skalningen så blev självklart utsignalen olika. Dock inga hejdundrans hastigheter. Gott och väl < 1kHz vill jag minnas. I något läge var signalen kring 60 Hz bara.
På fråga 2 så får jag skämmas. Det är jag som lurat in er på 10 bitar.
När jag mätte första gången så hamnade samtliga värden alltid under 1024 så jag tänkte att det räcker med 10 bitar att filtrera och labba med. Det har således inget med ADC-upplösning eller annat att göra.
Dock efter modden så blev saker och ting helt annorlunda och frekvensen är betydligt lägre (längre puls) så det utlästa talet blir således mycket större.
Vet inte riktigt vad pulseIn() ger tillbaka för nummer... ms? Nej jag vet inte.
Det hela handlar nog om att få till en pålitlig testrigg och därefter kalibrera efter dom nya förhållandena.
Pärlan hamnar tyvärr inte exakt på samma ställe och värdena varierar helt oroligt mycket bara av att jag sensorn en millimeter åt ena eller andra hållet. Här måste det alltså till lite precision. Det blir också väldigt stor skillnad i mätvärdena om jag lägger resp ställer pärlan upp. Den ska helt klart ligga ner.
Om du orkar så kan jag presentera 200 värden för 10 olika pärlor imorgon, så kanske det går att se med hjälp av dina grafer om det verkar genomförbart?
Ska lura på en anordning som fixerar både pärla och sensor i exakt position till imorgon i så fall.
Hur stabil och avkopplad är spänningsförsörjningen? Vid förändring av spänningen så ändras frekvensen med 0.5%/V
Hur har du ställt in ingången på din mikrokontroller för att få bästa möjliga skala på frekvensmätningen relativt områdena som modulen ger ut?
10-12kHz
100-120kHz
500-600kHz (detta verkar ge bäst noggrannhet då dom andra alternativen passerar signalen genom frekvensdelare)
På vilket sätt mäter du frekvensen? Maximum resolution and accuracy may be obtained using frequency-measurement, pulse-accumulation, or
integration techniques. Frequency measurements provide the added benefit of averaging out random- or
high-frequency variations (jitter)
Hur stabil är kristallen/oscillatorn på din mikrokontroller?
Hur styr du ingången OE? A low-impedance electrical connection between the device OE pin and the device GND pin is required for
improved noise immunity.
Nu är du något på spåret, det hade jag missat i databladet!
OE har jag lämnat ej ansluten då jag läste någonstans att "det gick bra"
Jag spänningsmatar just nu direkt från datorn till Nanon. Vet inte hur den matningen ser ut men borde inte vara jättedålig i alla fall.
Dom andra frågorna har jag inte en aning om. Kristallen som sitter monterad är en liten ytmonterad sak så jag fick googla fram att det är en 16Mhz-kristall. Hur stabil den är vet jag tyvärr inte.
Vilket sätt jag mäter frekvensen är jag lite osäker på. Jag använder som sagt en funktion som heter pulseIn(). Vet inte hur den fungerar, dock så har jag testat lite olika interrupt-baserade andra bibliotek men det blir så mycket kod att ändra så jag börjar må illa. Som du kanske vet så är jag inte speciellt bra på det här...
Ska dra ner OE mot jord imorgon också och se hur utvärdena ser ut, bara av att göra det.
#include <FreqCounter.h>
void setup() {
Serial.begin(57600); // connect to the serial port
Serial.println("Frequency Counter");
}
long int frq;
Void loop() {
FreqCounter::f_comp= 8; // Set compensation to 12
FreqCounter::start(100); // Start counting with gatetime of 100ms
while (FreqCounter::f_ready == 0) // wait until counter ready
frq=FreqCounter::f_freq; // read result
Serial.println(frq); // print result
delay(20);
}
Tänk att jag jag läste precis den kodsnutten idag, samt laddade ner det biblioteket, men jag förstod aldrig hur jag skulle använda det.
Vet inte vart jag ska trycka in pin-numret den ska mäta frekvensen på.
Oavsett så verkar du fast vid din sak så jag får fortsätta och googla på det. Ju mindre jag behöver programmera desto roligare blir det.
#include <FreqCounter.h>
#define S0 4
#define S1 8
#define S2 6
#define S3 7
#define sensorOut 5
void setup() {
Serial.begin(57600); // connect to the serial port
Serial.println("Frequency Counter");
digitalWrite(S0,HIGH); // S0 high & S1 low = scaling 20%
digitalWrite(S1,LOW);
}
long int frq;
void loop() {
digitalWrite(S2,LOW); // Set S2 & S3 to get RED frequency on output
digitalWrite(S3,LOW);
FreqCounter::f_comp= 8; // Set compensation to 12
FreqCounter::start(100); // Start counting with gatetime of 100ms
while (FreqCounter::f_ready == 0) // wait until counter ready
frq=FreqCounter::f_freq; // read result
Serial.println(frq); // print result
delay(500);
}
Och så här ser utläst frekvens ut för enbart röd färg:
Det hjälpte om man ställde om pinnarna till I eller O
Kollade med skopet samtidigt som mätningen nedan och den ligger kring 350-360Hz just vid den här mätningen. Den högsta frekvensen jag uppnått än så länge är 2,5kHz och det var med vitt papper under.
#include <FreqCounter.h>
#define S0 4
#define S1 8
#define S2 6
#define S3 7
#define sensorOut 5
void setup() {
pinMode(S0, OUTPUT);
pinMode(S1, OUTPUT);
pinMode(S2, OUTPUT);
pinMode(S3, OUTPUT);
pinMode(sensorOut, INPUT);
Serial.begin(57600); // connect to the serial port
Serial.println("Frequency Counter");
digitalWrite(S0,HIGH); // S0 high & S1 low = scaling 20%
digitalWrite(S1,HIGH);
digitalWrite(S2,LOW); // Set S2 & S3 to get RED frequency on output
digitalWrite(S3,LOW);
}
long int frq;
void loop() {
FreqCounter::f_comp= 8; // Set compensation to 12
FreqCounter::start(100); // Start counting with gatetime of 100ms
while (FreqCounter::f_ready == 0) // wait until counter ready
frq=FreqCounter::f_freq; // read result
Serial.println(frq); // print result
delay(500);
}