Matrisberäkningar med för STM32?

[Al_Bundy]

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?

[Al_Bundy]

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.

Markering_030.png

Så här ser datan ut över tid.

Markering_029.png

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;
		}

	}

och jag skickar värderna med denna C kod. Från STM32.

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);

Edit:
Ibland blir det

Markering_031.png

[Al_Bundy]

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.

Markering_032.png

En fråga! Vad tror ni att jag kan göra åt detta? Ska man sätta kondensatorer mellan analog in och GND?

Markering_033.png

[jockwe]

Göra åt vad? Hur önskar du att datat ska se ut?

[Al_Bundy]

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.

[Al_Bundy]

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.

[AndLi]

Varför är fördröjningar och filter okej idag när det inte var det igår? Vad är skillnaden?

[bearing]

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.

[Al_Bundy]

Varför är fördröjningar och filter okej idag när det inte var det igår? Vad är skillnaden?

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.

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.

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:

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

Dessutom har jag byggt en TCP/IP server i Java som ska fungera som en hållare för data. Då kan jag ansluta klienter till denna som begär eller skickar data till servern.

[jesse]

Mätvärdet vid 21:39:32 ser ju inte ut att följa kurvan.

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.

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....

[bearing]

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.

[Al_Bundy]

Vi får se. Jag kommer köra på en hemmasnickrad modbusvariat för jag håller på med kommunikation mellan octave och Java.

[bearing]

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.

[Al_Bundy]

Du ska inte säga så där. Du vet inte modellreducering är för något och hur det fungerar.

[Shimonu]

Så man borde inte uttrycka sig om saker man inte har bra koll på? Det är ju en bra lärdom från dig..........