Matrisberäkningar med för STM32?
Re: Matrisberäkningar med för STM32?
Om man estimerar ett tillstånd och har utsignalsmatrisen som en identitetsmatris så kommer ett kalmanfilter fungera som ett filter.
Men jag ska börja med att få upp mätutrustningen och börja analysera och utforska var det kan "vibrera" någonstans. Kanske inte behöver ett filter trots allt?
Men jag ska börja med att få upp mätutrustningen och börja analysera och utforska var det kan "vibrera" någonstans. Kanske inte behöver ett filter trots allt?
Re: Matrisberäkningar med för STM32?
Jag har byggt ihop en u741A förstärkare för min PT100 givare. Det är en riktig PT100 som kommer från en massafabrik. Förstärkaren ger ut nära 0...3.24 volt från 0 till 100 grader. Jag försökte pricka 3.3 volt så nära som det gick. Men det skulle inte väll vara några program att ställa ned referensen till 3.2 i STM32? Eller är det fast? Jag menar, maximumreferens är ju 3.6 volt.
Så här ser datan ut över tid. Jag löser värderna med denna C-kod.
och jag skickar värderna med denna C kod. Från STM32.
Edit:
Ibland blir det
Så här ser datan ut över tid. Jag löser värderna med denna C-kod.
Kod: Markera allt
/*
* Flush
*/
tcflush(program->usb.serialPort, TCIFLUSH); // Get the latest values
/*
* Collect
*/
int receiveBytes = read(program->usb.serialPort, readBuffer, sizeof(readBuffer));
/*
* Print
*/
int count = 0;
int adc = 0;
for (int i = 0; i < receiveBytes; i++) {
if (count == 0) {
adc = (int) readBuffer[i] * 256;
count++;
} else if (count == 1) {
adc += (int) readBuffer[i];
count = 0;
printf("value %d\n", adc);
program->usb.output = program->usb.slope * ((double) adc) + program->usb.offset; // y = kx+m
adc = 0;
}
}
Kod: Markera allt
/*
* adc is beteen 0 to 4095
*/
int adc = adcValues[0]; // We store adcValues[i] into a temporary array due to changes of adcValues
/*
* Send
*/
uint8_t data = (uint8_t) (adc >> 8); // First data
HAL_UART_Transmit(&huart2, &data, sizeof(data), TIME_OUT);
data = (uint8_t) (adc & 0xFF); // Second data
HAL_UART_Transmit(&huart2, &data, sizeof(data), TIME_OUT);
HAL_Delay(10);
Ibland blir det
Du har inte behörighet att öppna de filer som bifogats till detta inlägg.
Re: Matrisberäkningar med för STM32?
Nu har jag fått det bättre. Har tagit i som Bundy normalt brukar göra. 480 ADC samplingar och DMA på detta.
Här kan vi garanterat se första ordningens ODE när jag hällde i kallt vatten på systemet.
En fråga! Vad tror ni att jag kan göra åt detta? Ska man sätta kondensatorer mellan analog in och GND?
Här kan vi garanterat se första ordningens ODE när jag hällde i kallt vatten på systemet.
En fråga! Vad tror ni att jag kan göra åt detta? Ska man sätta kondensatorer mellan analog in och GND?
Du har inte behörighet att öppna de filer som bifogats till detta inlägg.
Re: Matrisberäkningar med för STM32?
Jag förväntar mig att dessa toppar kan reduceras bort. Jag kan acceptera dem, men har jag möjligheten att få bort dem på ett bra sätt, så gör jag det.
Re: Matrisberäkningar med för STM32?
Satte dit en 104 keramkondensator mellan analog in och GND och så här blev resultatet. Lite fladder, men fullt godkänt. Dessutom så reagerar den lika snabbt som utan kondensator.
Du har inte behörighet att öppna de filer som bifogats till detta inlägg.
Re: Matrisberäkningar med för STM32?
Varför är fördröjningar och filter okej idag när det inte var det igår? Vad är skillnaden?
Re: Matrisberäkningar med för STM32?
Mätvärdet vid 21:39:32 ser ju inte ut att följa kurvan. Och vad det beror på kan ju säkert vara intressant att ta reda på. Det första du bör göra är att mäta signalen från sensorn med någon annan utrustning, någon sorts mätlogger eller liknande, och sedan jämföra resultaten.
Din ADC är 12-bitar, och jag antar att vad vi ser i grafen är det råa ADC-värdet. Vanligtvis brukar bruset ligga i de två lägsta bitarna, dvs 4 enheter. Men värdet ser ut att avvika kanske 40 enheter, vilket ju ser mycket konstigt ut.
Jag kan komma på massor med ideer på varför du fick resultatet du fick, t.ex:
-Det blev dålig elektrisk eller termisk kontakt vid 21:39:32
-Ditt mjukvarufilter har någon bugg som kastar bort bitar vid vissa kombinationer av mätvärden.
-Något är felinställt med ADC
-Överföringen till mobilen har buggar.
Du får skriva exakt vad du har för hårdvara och relevant kod (filtret tex.) och om du kan ha petat på någon sladd vid 21:39:32, eller om du alltid får avvikande värden likt i den här grafen.
Din ADC är 12-bitar, och jag antar att vad vi ser i grafen är det råa ADC-värdet. Vanligtvis brukar bruset ligga i de två lägsta bitarna, dvs 4 enheter. Men värdet ser ut att avvika kanske 40 enheter, vilket ju ser mycket konstigt ut.
Jag kan komma på massor med ideer på varför du fick resultatet du fick, t.ex:
-Det blev dålig elektrisk eller termisk kontakt vid 21:39:32
-Ditt mjukvarufilter har någon bugg som kastar bort bitar vid vissa kombinationer av mätvärden.
-Något är felinställt med ADC
-Överföringen till mobilen har buggar.
Du får skriva exakt vad du har för hårdvara och relevant kod (filtret tex.) och om du kan ha petat på någon sladd vid 21:39:32, eller om du alltid får avvikande värden likt i den här grafen.
Re: Matrisberäkningar med för STM32?
Jag testar mig lite fram bara. Jag vill helst köra utan filter så mycket som det går för att inte få fasförskjutningar. Jag funderar på att använda ett kalman filter.AndLi skrev:Varför är fördröjningar och filter okej idag när det inte var det igår? Vad är skillnaden?
Jag tror det kan vara så att när jag delar upp 12-bit till först 4 bitar och sedan 8 bitar så kan det vara så att 4:an inte kommer med. För min "formel" efter överföriningen är:bearing skrev:Mätvärdet vid 21:39:32 ser ju inte ut att följa kurvan. Och vad det beror på kan ju säkert vara intressant att ta reda på. Det första du bör göra är att mäta signalen från sensorn med någon annan utrustning, någon sorts mätlogger eller liknande, och sedan jämföra resultaten.
Din ADC är 12-bitar, och jag antar att vad vi ser i grafen är det råa ADC-värdet. Vanligtvis brukar bruset ligga i de två lägsta bitarna, dvs 4 enheter. Men värdet ser ut att avvika kanske 40 enheter, vilket ju ser mycket konstigt ut.
Jag kan komma på massor med ideer på varför du fick resultatet du fick, t.ex:
-Det blev dålig elektrisk eller termisk kontakt vid 21:39:32
-Ditt mjukvarufilter har någon bugg som kastar bort bitar vid vissa kombinationer av mätvärden.
-Något är felinställt med ADC
-Överföringen till mobilen har buggar.
Du får skriva exakt vad du har för hårdvara och relevant kod (filtret tex.) och om du kan ha petat på någon sladd vid 21:39:32, eller om du alltid får avvikande värden likt i den här grafen.
4-bits tal * 256 + 8-bits tal = 12-bits tal.
Translationen ser ut så här: [4 8 4 8 4 8 4 8 4 8 4 8]. Jag flushar så att jag tar alltid det första som skickas. Men jag kanske läser 8 och sedan 4 vid vissa tillfällen? Jag hade faktiskt kollat upp detta, men hittar dock inget. Skumt dock. Jag tror inte på denna orsak. Så det kan vara lite fel i själva kommunikationen för modbus.
Nu är det så att jag går ifrån C till GNU Octave och det har endast med beräkningar att göra. C kunde inte klara av beräkningar och gick dessutom segare än Octave, trots att jag använde Lapack. Octave hade dessutom möjlighet till bättre modellreducering än C. Jag kan posta skriptet så ska ni få se. Jag återkommer med information när jag har börjat köra upp programmet.
Kod: Markera allt
# This is the main file. We start here.
function main()
# Begin to load instrument-control
pkg load instrument-control % Load the library for USB and TCP/IP
# Connect the USB
path = input("Enter the path or COM to the USB: ", "s");
program.serial = serial(path);
# Connect to TCP/IP
program.ip = input("Enter the IPv4 number to connect the TCP/IP server: ", "s");
program.port = input("Enter the port of the TCP/IP server: ");
program.client = tcp(program.ip, program.port);
## Set some initial values
program.countTime = 0;
program.maxCount = 200;
program.inputSignal = 0;
program.outputSignal = 0;
i = 1;
program.y = [];
program.u = [];
# This is our while loop
while(true)
## Read the TCP/IP server
tcp_write(program.client, "GET"); # Order the TCP/IP server to get all the values
n = tcp_read(program.client, 1); # Read the length of the data
tcpData = tcp_read(program.client, n); # Now read all
tcpData = char(tcpData); # Turn uint8 to string
## Split the strin tcpData at "#" and load it into the structure
splitedString = strsplit(tcpData, "#");
program.sampleTime = splitedString(1,1);
program.pwmStartSignal = splitedString(1,2);
program.referencePoint = splitedString(1,3);
program.controlHorizon = splitedString(1,4);
program.predictHorizon = splitedString(1,5);
program.sensorSlope = splitedString(1,6);
program.sensorOffset = splitedString(1,7);
program.running = splitedString(1,8);
program.time = splitedString(1,9);
# don't need inputSingal here
# don't need outputSignal here
## Read the USB
srl_flush(program.serial); # First flush
usbData = srl_read(program.serial, 2); # Read two bytes
output = usbData(1)*256 + usbData(2); # The STM32 sending shifted bites due to 8-bit UART
program.outputSignal = program.sensorSlope*output + program.sensorOffset; % y = kx + m formula
## Check if we should control
if(strcmp(program.running, "true")
## Start to collect data if...
if(program.countTime < program.maxCount*program.sampleTime)
## We use the initial input signal here
program.inputSignal = program.pwmStartSignal; % 0..255
## Add the signals
program.u(i) = program.inputSignal;
program.y(i) = program.outputSignal;
## Add to the counting
program.countTime += program.sampleTime;
i++;
else
## OKID/ERA - Find the model
## Kalman filter - Find the initial state
## MPC - Find the best input value
## Send the best value to USB
## Update signals for next iteration
endif
else
## Reset some values
program.countTime = 0;
program.inputSignal = 0;
i = 1;
program.u = [];
program.y = [];
endif
## Send the best input value, output value and time to TCP/IP server
## Pause before next iteration
pause(program.sampleTime);
endwhile
endfunction
Re: Matrisberäkningar med för STM32?
Den kan ju ha missat att läsa in något värde alls av någon anledning (kan ju hända var som helst i kedjan från ADC till graf) och i så fall behållit föregående värde.bearing skrev:Mätvärdet vid 21:39:32 ser ju inte ut att följa kurvan.
Att det skulle bli nåt fel o Modbus-kommunikationen är väl det minst sannolika. Modbus är robust och fungerar felfritt i miljoner av applikationer. Såvida inte modbus-koden är hemmasnickrad förstås....
Re: Matrisberäkningar med för STM32?
Jo det är ju sant. Det kanske är något fel i "tajmingen" mellan funktionen som beräknar värden och skickar värden, om de inte anropas i följd, utan triggas individuellt, och har en aning olika anropsintervall.
Re: Matrisberäkningar med för STM32?
Vi får se. Jag kommer köra på en hemmasnickrad modbusvariat för jag håller på med kommunikation mellan octave och Java.
Re: Matrisberäkningar med för STM32?
Nu uttrycker du dig inte särskilt korrekt.
Sen tycker ju jag att dom här senaste problemen tydligt illustrerar att det inte hjälper att byta programmeringsspråk/utvecklingsmiljö om man ändå inte har/skaffar sig de grundläggande kunskaperna.
Sen tycker ju jag att dom här senaste problemen tydligt illustrerar att det inte hjälper att byta programmeringsspråk/utvecklingsmiljö om man ändå inte har/skaffar sig de grundläggande kunskaperna.
Re: Matrisberäkningar med för STM32?
Du ska inte säga så där. Du vet inte modellreducering är för något och hur det fungerar.
Re: Matrisberäkningar med för STM32?
Så man borde inte uttrycka sig om saker man inte har bra koll på? Det är ju en bra lärdom från dig..........