The first day in the lab was to say the least, difficult. We started out by running the provided Matlab code and testing out different transfer functions, record lengths, sampling frequencies, and nffts. We noted that for second order systems decreasing the sampling time below 0.1 msec or above 32msec tends to produces undesired results if none of the other parameters change. Also, if you return to default conditions and decrease the nfft value skewed data results. However, it was found that increasing nfft really high did not play as significant of a role. Of course, increasing or decreasing the record lengths changed the length of sampling time in addition to providing a more or less continuous curve.
After these effects were acknowledged we continued onto establishing a communication with the Arduino and Matlab. Here is where the difficulties begin. After we uploaded the SerialCallResponse.pde into the Arduino and then closed it, we ran SerialCallResponseSim.m to run the echo function. The problem was that after running the first time correctly, it would say from then on that the serial port was closed. After much debugging and errors we decided to continue at another time.
Subscribe to:
Post Comments (Atom)
We had the same problem with communications between Arduino and Matlab. We found that Matlab is incredibly slow and could not maintain a sufficient sampling rate for the task at hand. To remedy this, we coded Arduino using two separate for() loops, one for sending the white noise and measuring the response, and another loop for sending the response to Matlab. This eliminated Matlab from the measurement portion of the code so that Arduino could run unhindered.
ReplyDelete