Nari Shin

Profile Data

Screen Name: Nari Shin

Screen Name*

Title

First Name

Address:

Last Name

URL (i.e. Company, Github, LinkedIn)

LinkedIn account

Company

Phone number

Country

Bio

Indicates required field*

My Activities
Following

Member Action Date

Nari Shin

Replied to When will the forum get fixed?

Hi Erik,

Please see the latest community release notes in the Announcements board.

https://www.silabs.com/community/about/announcements

23 hours ago

Nari Shin

Replied to Leaderboard disappears

Hi YK,

I confirmed the issue and reported it to the web team. I will keep you updated on this.

2 days ago

Nari Shin

Updated Building a Digital Tuner from Scratch on Projects

by Silicon Labs MCU and Micrium OS applications team members John Bodnar, Sharbel Bousemaan, Mitch Crooks, and Fernando Flores

What is tuning and why does it matter?

If you play a musical instrument, especially if you play a wind instrument, you’re going to want to tune once you’re sufficiently warmed up. For the not so musically-inclined, tuning is the process of making an adjustment to your instrument so that the notes you play, in particular notes which correspond naturally to the construction of the instrument, are produced accurately. Electronically speaking, you could say the notes are reproduced with the correct frequency.

For a simple example, consider the clarinet shown above. As with any tubular musical instrument, it’s fundamental pitch (the note it most naturally plays) is proportional to its length. In particular, the clarinet above is a B-flat clarinet, so by slightly lengthening it or shortening it, the fundamental note it produces can be made to match a concert B-flat.

Without going into too much detail, modern instruments tune to notes relative to A = 440 Hz above middle C (think the middle key on a piano). In the case of a B-flat clarinet, its fundamental pitch has a frequency of 466.164 Hz. Thus, a clarinet is “in tune” when a player adjusts his/her embouchure (the relative tension of the facial muscles and positioning of the lips and teeth) to play a B-flat and the sound that comes out of the instrument has a frequency of 466.164 Hz.

If the sound that comes out of a clarinet when attempting to play a B-flat has a frequency that is lower than expected, the instrument is said to be flat. Similarly, if the frequency of the sound is too high, the instrument is said to be sharp.

On a clarinet, the mouthpiece, which is the plastic and metal assembly against which the player blows, can be pushed in or pulled out slightly to adjust its tuning. So, if the player’s B-flat is sharp, the mouthpiece can be pulled out a little to lower the frequency and bring it in tune. Likewise, if the B-flat is flat (too low), the mouthpiece is pushed in slightly to raise the instrument’s pitch. Tuning an instrument to its proper concert pitch (B-flat in the case of our clarinet example) is a necessary first step to getting the other notes it can produce to also be in tune when they are played.

What is a tuner?

Experienced musicians and people with perfect pitch can tune by ear simply by listening to the note produced and adjusting the instrument’s tuning mechanism accordingly. The rest of us generally rely upon a device called a tuner that compares the frequency of the note we play to its mathematically calculated frequency. A modern digital tuner can be a standalone electronic device or even an application for a smartphone. An example is shown in Figure 2.

Figure 2. OEM Digital Tuner

These devices, which can be had for as little as $15, are generally powered by inexpensive, 8-bit microcontrollers. Knowing this, we can probably assume that such a tuner does not make use of digital signal processing (e.g. finding the fundamental frequency by means of a FFT) to compare the frequency of the note played to what it ideally should be. Instead, we figured such a device would probably operate in the time domain by comparing the note played to what it should be purely by means of frequency comparison.

Every instrument produces a unique sound that is colored by timbral impurities. These impurities are introduced by the shape of the instrument, the materials from which it’s constructed, and by the uniqueness of the musician’s embouchure (for wind players) or touch (for string and percussion players). The net result of these variations is that the waveform of the sound produced on a given instrument as played by any one musician is not spectrally pure but instead consists of a fundamental frequency superimposed by waveforms with various overtones (integer multiples of the fundamental frequency).

Knowing this, we felt that a tuning method that operates purely in the time domain with no consideration of spectral content would be most suitable for a low-cost processor. Considering that dedicated digital tuners run off one or two AA or AAA batteries, such an approach would also have the benefit of being particularly energy efficient.

Project Summary

Our goal was to construct a digital instrument tuner that could:

distinguish the fundamental frequency of the note being played,
determine the nearest equal temperament musical note (based on A = 440 Hz modern tuning),
visually display whether the note is sharp or flat relative to the target note/frequency, and
function without resorting to computationally intensive DSP concepts in order to minimize energy use.

We implemented what might be considered a very simply analog-to-digital converter that takes the output from an analog microphone and turns it into a pulse train with the frequency equal to that of the note’s fundamental. The pulse train is then easily captured by a microcontroller, which can then perform all of the aforementioned tasks.

Detailed Description

For hardware, we opted to use the EFM32 Series 1 Giant Gecko Starter Kit. While the Series 1 Giant Gecko microcontroller might be a bit overkill for the project at hand, the starter kit has a nice dot matrix memory LCD to use for output. Optimization for a smaller EFM32 microcontroller could follow later once the whole concept and application code had been proven.

To capture the sound from the instrument and output the pulse train, we used an analog MEMS microphone with an amplifier circuit connected to a 74VHC14 Schmitt-triggered inverter. Because we would need to both measure the frequency of the note being played and keep the tuner display updated, a multi-threaded software foundation was a no-brainer.

We used Micrium’s µC/OS real-time kernel to provide this environment, along with the kernel services needed to protect shared resources and synchronize the tasks. This RTOS foundation allowed us to simplify the design and implementation of our application code, which, at its most basic level, required just two tasks: one for sampling the pulse train and the other for displaying the tuner’s output.

For the display task to know what pitch is being detected, the measurement task needs some way to communicate results. To do this, we opted for a simple shared variable which the measurement task updates after each sampling period.

In multi-threaded applications, shared data must be protected by a kernel mechanism, such as a semaphore. Pending on a semaphore usually means that a task might block (be stuck waiting for new data) until it becomes available. This behavior is undesirable for our measurement task because it must sample the pulse train periodically.

µC/OS allows a non-blocking pend on semaphore, which provides resource safety without the risk of having a task block indefinitely. The drawback of this method is that some measurements might never be communicated to the display task. In practice, this is not an issue for the tuner because we are more concerned with a fast response to changes in pitch.

Display Task

The design of our display task (Figure 3) follows the general outline of the flowchart below. However, we have included a signaling semaphore that the measurement task uses to notify the display task when the frequency variable has been updated. The display task blocks on this semaphore to avoid updating the display multiple times with the same data. This helps to reduce the overall energy use of the application.

Once it is signaled, the display task tries to access the shared frequency variable. It does so by trying to grab the tuner semaphore which is used to protect the shared data. Eventually, the semaphore will become available, allowing us to read the frequency value. The frequency is converted into a pitch using a simple lookup table. The remainder of the task deals with how the user interface will look when the pitch is displayed. We decided on a minimal design which provides a visual representation of how in or out of tune the played note is, as shown in Figure 4.

Figure 4. Tuner Display Output

Measurement Task

The measurement task (Figure 5) implements an algorithm for reading the pulse train and calculating its average frequency. Pulses are captured using the WTIMER0 peripheral, while the LDMA reads a timestamp from WTIMER0 for each pulse detected. The timestamps are copied into a memory buffer over a period of 125 ms, as measured by the CRYOTIMER peripheral. Once the 125 ms has elapsed, the CRYOTIMER interrupt notifies the measurement task that the sample is ready.

The task averages the periods between pulses to calculate the frequency of the pulse train. This value is reported to the display task using the mechanisms described above. The LDMA and timer peripherals are then reinitialized for the next sample, and the task waits for the next CRYOTIMER interrupt.

Microphone and Pulse Generation Circuit

A primary goal of this project was to devise a means of detecting the frequency of a note played by a musical instrument without the use of complex and computationally expensive signal processing algorithms. Use of such techniques, for example, FFTs, complicates software development, requires a substantial number of processing cycles, and increases energy use.

We needed a computationally simpler and less energy-intensive solution that would still permit reliable detection of the frequency of the note being played. A combination of hardware signal processing and software capture and analysis allowed us to do this with a substantially smaller computational footprint and, thus, less energy, than an FFT-based or similar approach.

The hardware front end of the frequency measurement portion of the tuner consists of an ADMP401 analog MEMS microphone with preamplifier circuitry followed by a 74VHC14 inverting Schmitt trigger. Figure 6 shows the signal flow through each stage of the hardware.

**Figure 6. Audio Signal Flowchart through Hardware Front-end Stages**

Although not currently implemented in the project due to time constraints but available for future implementation, a digitally-tunable low pass filter is placed between the microphone and the Schmitt trigger. Ideally, this would filter out harmonics (overtones) above the fundamental frequency of the note being played in order to improve the quality of the input to the Schmitt trigger. Figure 7 shows the hardware front end prototype.

**Figure 7. Hardware Front-end Prototype**

The MEMs microphone captures the note played and passes an analog signal to the input of the Schmitt trigger. Depending on the instrument being played, this analog waveform will have a different envelope or shape, but it will still be periodic in nature and have the fundamental frequency of that note. As such, it will have periodic vertical crossings of the high and low Schmitt trigger threshold voltages if the input signal is properly scaled. In Figure 8, CH1 shows the input analog waveform at a frequency of about 866 Hz.

Figure 8. Oscilloscope Capture showing analog audio signal (microphone output) on CH1 and Schmitt-triggered output on CH2

A Schmitt trigger is essentially a comparator circuit with hysteresis, and, in this application, it functions as a 1-bit analog-to-digital converter. Thus, as the input signal rises above the Schmitt trigger input high threshold voltage (VIH), the inverting Schmitt trigger output transitions from logic high to logic low. Likewise, when the analog signal falls below the input low threshold voltage (VIL), the inverting Schmitt trigger output transitions from logic low to logic high.

Note that the Schmitt trigger implements hysteresis where VIH > VIL resulting in a more stable digital output in the presence of a noisy or non-monotonic input signal. The resulting output is a pulse train with the same frequency as the input analog waveform, in this case about 880 Hz. This digital signal is then routed to one of the MCU’s timer input pins where its edges are captured and used to quickly calculate the frequency of the note being played.

Results and Lessons Learned

Surprisingly, the application ran almost exactly as expected when first tested with simulated instrument sounds. However, we did encounter a problem with higher frequencies resulting in pulse trains that did not correspond with the expected frequencies. In this case, our problem was caused by failure to reset the timer before each new sampling period. This meant that any pulses occurring after one measurement task ended up being counted and affecting the frequency calculated in the next run of the measurement task.

The system responded well to clean inputs from frequency generators, sine waves recorded through the microphone, and some simulated instrument sounds. However, accuracy began to degrade when more complex tones were played, such as those from a brass instrument.

As noted above, one aspect of the project originally conceived but not yet implemented is a low-pass filter that can be tuned to strip out harmonics coloring the sound from instruments as played by real people. Time constraints prevented this feature from being integrated into the demonstrated project. Naturally, more effort can still be spent to optimize energy use and get the entire system to provide substantial operating life from one or two alkaline batteries.

5 days ago

Nari Shin

allow to EFM32GG11 Analog pin outputing 3.3V

Skip to content
Using National Oceanic and Atmospheric Administration Mail with screen readers

Search

Compose

Labels

Hangouts

1 of 85

Expand all

Print all

In new window

ADC Code

Inbox

Travis Singleton - NOAA Affiliate

7:45 AM (39 minutes ago)

Can I have the ADC code? Thanks,

James Elliott - NOAA Federal

Attachments 8:07 AM (16 minutes ago)

to me

Travis,

Here it is...

The only functions we are using are AnalogTest and adcSingle.

James
-------------------------------------------
James Elliott
Lead Software Engineer
National Data Buoy Center
Stennis Space Center, MS
228-688-2815
-------------------------------------------
"For the strength of the pack is the wolf, and the strength of the wolf is
the pack"
- Rudyard Kipling

Attachments area

Thanks!

Got it, thanks!

Awesome, thanks!

ReplyForward

/*
 * analog.c
 *
 *  Created on: Nov 21, 2018
 *      Author: Jonathan.T.Brashears
 */

#include <stdlib.h>

#include "analog.h"
#include "smPlus.h"
#include "userInterface.h"
#include "utilities.h"
#include "os.h"
#include "memory.h"
#include "config.h"
#include "powerControl.h"
#include "em_adc.h"
#include "em_cmu.h"
#include "rtc.h"
#include "gpio.h"


#include <math.h>

unsigned int ADCresults[MAX_SUPER_SAMPLE_ANALOG_CHANNELS][NUM_SUPER_SAMPLES];


void CalibrateAnalog(CHAR* arg)
{

	typedef struct
	{
		float   avgCounts;
		float	varCounts;
		float 	setPoint;
		float 	refStandard;
	} CalibrationData;

	INT sensor;
	CHAR getNewSetPointFlag;
	CHAR dataReadyFlag;
	UCHAR escapeFlag;
	unsigned printHeaderCounter;
	float refStandard;
	float sampleArray[NUM_SAMPLES_TO_AVG];
	UCHAR sampleCounter;
	UCHAR calIndex = 0;
	CHAR* inputBuffer = GetUiBufferIn();
	double X_Values[MAX_CAL_VALUES];
	double Y_Values[MAX_CAL_VALUES];
	float gain;
	float divisor;
	float counts;
	float avgCounts;
	float varCounts;
	float avgVolts;
	INT inputCheck;
	INT i;
	double results[4];
	RTOS_ERR err;


	CalibrationData cal[MAX_CAL_VALUES];

	SmpPrintf("\n-----------------SM+ Analog calibration-----------------");
	SmpPrintf("\nPress ESCAPE at any time to complete calibration");
	SmpPrintf("\n\nEnter the channel to calibrate (0, 1 or 2): ");

	GetUserInput(100, DELAY_2_MS, FALSE);
	sensor = atoi(inputBuffer);
	if (sensor > 2)
	{
		//goto EndTask;
		return;
	}
	gain = configTable.analogConfig[sensor].channelGain;
	SmpPrintf("\n\nEnter channel %i Gain [%f]: ",sensor, gain);
	GetUserInput(100, DELAY_2_MS, FALSE);
	if (inputBuffer[0] > 0x2F) //0x2F and below are all invalid characters
	{
		gain = atof(inputBuffer);
		configTable.analogConfig[sensor].channelGain = gain;
	}

	divisor = configTable.analogConfig[sensor].channelDivisor;
	SmpPrintf("\n\nEnter channel %i Divisor [%f]: ",sensor, divisor);
	GetUserInput(100, DELAY_2_MS, FALSE);
	if (inputBuffer[0] > 0x2F) //0x2F and below are all invalid characters
	{
		divisor = atof(inputBuffer);
		configTable.analogConfig[sensor].channelDivisor = divisor;
	}

	//TODO: Power functions
	// Power up main supply
	//while (RequestMainSupplyPowerUp(THIS_TASK_ID) == FAIL)
	//	OSTimeDly(DELAY_SEC, OS_OPT_TIME_DLY, &err);
	//RequestAnalogPowerUp(sensor);
	OSTimeDly(DELAY_SEC, OS_OPT_TIME_DLY, &err);  //Allow circuits to stabilize

	//	OS_WaitBinSem(ECBP_BINSEM_ADCS, 255);	// Wait on ADCs semaphore.
	//	if (OSTimedOut())
	//	{
	//	  IF_DEBUG DebugOut(DEBUG_MODE_1, "\nFailed to get ADC checked out.\n");
	//	  goto EndTask;
	//	}

	SmpPrintf("\n\n***************************************");
	SmpPrintf("\nPress enter to set a calibration point.");
	SmpPrintf("\nPress backspace to remove the last point.");
	SmpPrintf("\nPress escape to complete the calibration.");
	SmpPrintf("\n***************************************\n");


	getNewSetPointFlag = 1; //force to get a new setpoint when starting
	//loop until user press escape to end the cal or enter to move to next point
	while (1)
	{
		//OSTimeDly(DELAY_4TH_SEC, OS_OPT_TIME_DLY, &err);

		if (getNewSetPointFlag == 1)
		{
			getNewSetPointFlag = 0;
			sampleCounter = 0;
			dataReadyFlag = 0;
			printHeaderCounter = 0;
			SmpPrintf("\nEnter reference standard value: ");
			inputCheck = GetUserInput(100, DELAY_2_MS, FALSE);
			if (inputCheck == -5)
			{
				escapeFlag = 1;
				break;
			}
			if (inputBuffer[0] == 'b')
			{
				if (calIndex > 0)
				{
					calIndex--;
					SmpPrintf("\nPrevious point removed.");
					getNewSetPointFlag = 1;
				}
			}
			refStandard = atof(inputBuffer);
		}

		inputCheck = GetUserInput(0, DELAY_2_MS, FALSE);
		//check to see what user wants
		if (inputCheck == -5) // Check if user wants to quit.
				escapeFlag = 1;

//		if (inputCheck == 2 && inputBuffer[0] == 'b')
//		{
//			if (calIndex > 0)
//			{
//				calIndex--;
//				SmpPrintf("\nPrevious point removed.");
//				getNewSetPointFlag = 1;
//			}
//		}
		if (inputCheck == 0)
		{
			getNewSetPointFlag = 1;

			if (dataReadyFlag == 1)
			{
				cal[calIndex].setPoint = calIndex;
				cal[calIndex].refStandard = refStandard;
				cal[calIndex].avgCounts = avgCounts;
				cal[calIndex].varCounts = varCounts;

				// increment the index
				calIndex++;
				if (calIndex >= NUM_SAMPLES_TO_AVG)
					escapeFlag = 1;
			}
		}
		if (getNewSetPointFlag == 1 || escapeFlag == 1)
		{
			// print out the current cal array
			SmpPrintf("\n\n%10s, %10s, %10s, %10s","SetPoint","Standard","Counts Avg","Counts Var");
			for (i=0; i < calIndex; i++)
			{
				SmpPrintf("\n%10.4f, %10.4f, %10.4f, %10.4f",cal[i].setPoint, cal[i].refStandard, cal[i].avgCounts, cal[i].varCounts);
			}
			SmpPrintf("\n\n");
		}

		// exit cal routine if an escape was found
		if (getNewSetPointFlag == 1)
			continue;

		// exit cal routine if an escape was found
		if (escapeFlag == 1)
			break;


		//get sample
		counts = SuperSampleADC(sensor);
		sampleArray[sampleCounter] = counts;
		sampleCounter++;
		sampleCounter= sampleCounter % NUM_SAMPLES_TO_AVG;

		if (sampleCounter == 0) //if the mod has set us to zero, then it is time to average
		{
			if (printHeaderCounter == 0)
			{
				SmpPrintf("\n%8s %8s %8s %8s","Standard", "Counts", "Var", "Volts");
			}
			printHeaderCounter = (printHeaderCounter + 1) % 40;

			dataReadyFlag = 1;
			avgCounts = AverageAoF(sampleArray, NUM_SAMPLES_TO_AVG);
			varCounts = VarianceAoF(sampleArray, NUM_SAMPLES_TO_AVG);
			avgVolts = ConvertCountsToVolts(avgCounts, gain, divisor);
			SmpPrintf("\n%7.4f, %7.4f, %7.4f, %7.4f",
				  refStandard,
				  avgCounts,
				  varCounts,
				  avgVolts);
		}

	}

	//data collection is now complete now to figure out what to do
	// make sure there is enough data
	if (calIndex < CALIBRATION_ORDER)
	{
		SmpPrintf("\nNot enough data to calibrate.");
		//goto EndTask;
		return;
	}



	//let user decide if we use this data or not
	SmpPrintf("\nUse the above data to calibrate? [Y/N]: ");
	GetUserInput(100, DELAY_2_MS, FALSE);
	if (inputBuffer[0] != 'y' && inputBuffer[0] != 'Y' )
	{
		//goto EndTask;
		return;
	}

	for (i = 0; i < calIndex; i++)
	{
		X_Values[i] =	 cal[i].refStandard;
		Y_Values[i] =	 ConvertCountsToVolts(cal[i].avgCounts, gain, divisor);
	}
	PolyRegression(Y_Values, X_Values, calIndex, CALIBRATION_ORDER, results);
	configTable.analogCal[sensor].VCalCoeffA = results[2];
	configTable.analogCal[sensor].VCalCoeffB = results[1];
	configTable.analogCal[sensor].VCalCoeffC = results[0];
	SmpPrintf("\n\nY=Ax^2+Bx+C\n");
	SmpPrintf("\nA=%f\nB=%f\nC=%f\n",
		  configTable.analogCal[sensor].VCalCoeffA,
		  configTable.analogCal[sensor].VCalCoeffB,
		  configTable.analogCal[sensor].VCalCoeffC);
	SmpPrintf("\n\n");

//EndTask:
}

double VarianceAoF(float floatArray[], UINT arraySize)
{
	double mean = AverageAoF(floatArray, arraySize);

	double varSum = 0.0;
	for (UINT index = 0; index < arraySize; index++)
		varSum += (floatArray[index] - mean) * (floatArray[index] - mean);

	float var = varSum / (float) (arraySize - 1);

	if (var <= 0.0)
		var = NAN;

	return var;
}

double AverageAoF(float floatArray[], UINT arraySize)
{
	double avg = 0.0;

	for (UINT index = 0; index < arraySize; index++)
	{
		avg += (floatArray[index]) / (float) (arraySize);
	}

	return avg;
}

void PolyRegression(const double* X, const double* Y, INT numPoints, INT order, double* results)
{

	//double tempSum;
	INT matrixColumns =  order + 1;
	INT matrixRows =  numPoints;

	//assert
	if (matrixRows < matrixColumns)
		return;

	SMPMATRIX vandermonde = SmpMallocMatrix(matrixRows,matrixColumns);
	SMPMATRIX transpose = SmpMallocMatrix(matrixColumns, matrixRows);
	SMPMATRIX result1 = SmpMallocMatrix(matrixRows, matrixRows);
	SMPMATRIX result2 = SmpMallocMatrix(matrixRows, matrixRows);
	SMPMATRIX yMatrix = SmpMallocMatrix(matrixRows,1);


	//fill vandermonde matrix
	for (INT rowIndex = 0; rowIndex < matrixRows; rowIndex++)
	{
		for (INT columnIndex = 0; columnIndex < matrixColumns; columnIndex++)
		{
			//calc location with proper value
			//tempSum = 0;
			//for (INT poINTsIndex = 0; pointsIndex < numPoints; pointsIndex++)
				//tempSum += pow(X[pointsIndex], columnIndex);
				vandermonde[rowIndex][columnIndex] =  pow(X[rowIndex], columnIndex);
		}
	}


	// fill single column of matrix with y sums
	for (INT rowIndex = 0; rowIndex < matrixRows; rowIndex++)
	{
		//tempSum = 0;
		//for (INTpointsIndex = 0; pointsIndex < numPoints; pointsIndex++)
			//tempSum += pow(X[pointsIndex], rowIndex) * Y[pointsIndex];
		yMatrix[rowIndex][0] = Y[rowIndex];
	}

	//result is a  matrixColumns x matrixRows matrix
	MatrixTranspose(vandermonde, matrixRows, matrixColumns, transpose);

	//result is a matrixColumns x matrixColumns matrix
	MatrixMuliply(transpose, matrixColumns, matrixRows,
				 vandermonde, matrixColumns,
				 result1);

	//result is a matrixColumns x matrixColumns matrix
	MatrixInversion(result1, matrixColumns, result2);

	//result is a matrixColumns x matrixRows matrix
	MatrixMuliply(result2, matrixColumns, matrixColumns,
				 transpose, matrixRows,
				 result1);

	//result is a matrixColumns x 1 matrix
	MatrixMuliply(result1, matrixColumns, matrixRows,
				 yMatrix, 1,
				 result2);

	//store results into return value
	for (INT rowIndex = 0; rowIndex < matrixColumns; rowIndex++)
		results[rowIndex] = result2[rowIndex][0];

	return;
}

SMPMATRIX SmpMallocMatrix(INT rows, INT columns)
{

	//we're going to hide the number of rows
	//right in front and then increment the pointer
	UINT sizeOfPointers = ((rows) * sizeof (double*));
	UINT sizeOfData = (rows*columns) * sizeof(double);
	UINT sizeTotal = sizeOfPointers + sizeOfData;

	SMPMATRIX matrix = StaticMemAlloc(sizeTotal);
	if (matrix == NULL)
		return NULL;

	//move past memory allocated for pointers and point to the first data location
	double* matrixStartOfData = (double*) (matrix + rows);

	//set each pointer to proper location in data memory
	for (INT i = 0; i < rows; i++)
		matrix[i] =  &matrixStartOfData[columns * i];

	return matrix;
}

void MatrixTranspose(SMPMATRIX A, UCHAR aNumRows, UCHAR aNumColumns, SMPMATRIX result)
{

	for (INT i = 0; i < aNumColumns; i++)
		for (INT j = 0; j < aNumRows; j++)
			result[i][j] = A[j][i];

	return;
}

CHAR MatrixInversion(SMPMATRIX input, int order, SMPMATRIX output)
{

	INT diagonalIndex, rowIndex, columnIndex;
	INT result;
	double factor;


	// load output, augmented matrix, with identity matrix
	for (rowIndex = 0; rowIndex < order; rowIndex++)
	{
		for (columnIndex = 0; columnIndex < order; columnIndex++)
		{
			//diagonal gets 1, all other zero
			if (rowIndex == columnIndex)
				output[rowIndex][columnIndex] = 1.0;
			else
				output[rowIndex][columnIndex] = 0.0;
		}
	}


	//following operations apply apply to the combined matrix [input | A]
	//which is an order x order * 2 matrix..
	//row operations will occur to the full row of the combined matrix
	result = SUCCESS;
	for(diagonalIndex = 0; diagonalIndex < order; diagonalIndex++)
	{
		//matrix is not invertible?
		if (input[diagonalIndex][diagonalIndex] ==  0.0)
		{
			result = FAIL;
			break;
		}

		//divide each entry in current row by input[diagonalIndex][diagonalIndex];
		//Every number to the left of column diagonalIndex is alreay set to zero
		//from the last run
		factor = input[diagonalIndex][diagonalIndex];
		for (columnIndex = 0; columnIndex < order; columnIndex++)
		{
			if (columnIndex > diagonalIndex) //skip useless math
				input[diagonalIndex][columnIndex] = input[diagonalIndex][columnIndex] / factor;

			output[diagonalIndex][columnIndex] = output[diagonalIndex][columnIndex] / factor;
		}

		//for each row other than the current row
		//subtract a multiple of the current row
		//the multiple is factor at [row,diagonalIndex]
		for (rowIndex = 0 ; rowIndex < order; rowIndex++)
		{
			if (diagonalIndex == rowIndex)
				continue;

			//for each row we are adding the current row time the factor
			//since output[diagonalIndex][diagonalIndex] == 1, if we multiply it by
			//-(factor) it will cause the current column  to be zero
			factor = input[rowIndex][diagonalIndex];
			for (columnIndex = 0; columnIndex < order; columnIndex++)
			{
				if (columnIndex > diagonalIndex) //skip useless math
					input[rowIndex][columnIndex] = input[rowIndex][columnIndex]
					- factor * input[diagonalIndex][columnIndex];

				output[rowIndex][columnIndex] = output[rowIndex][columnIndex]
					- factor * output[diagonalIndex][columnIndex];
			}
		}

//		//if debug print results results
//		IF_DEBUG
//		{
//			DebugOut(DEBUG_MODE_2,"\n\n");
//			for (rowIndex = 0; rowIndex < order; rowIndex++)
//			{
//				DebugOut(DEBUG_MODE_2,"\n");
//				for (columnIndex = 0; columnIndex < order; columnIndex++)
//					DebugOut(DEBUG_MODE_2,"%8.3f", input[rowIndex][columnIndex]);
//				for (columnIndex = 0; columnIndex < order; columnIndex++)
//					DebugOut(DEBUG_MODE_2,"%8.3f", output[rowIndex][columnIndex]);
//			}
//		}


	}

	return result;
}

void MatrixMuliply(SMPMATRIX A, UCHAR aNumRows, UCHAR aNumColumns,
					SMPMATRIX B, UCHAR bNumColumns, SMPMATRIX result)
{
	if (result == NULL)
		return;

	for (UCHAR resultRow = 0; resultRow < aNumRows; resultRow++)
	{
		for (UCHAR resultColumn = 0; resultColumn < bNumColumns; resultColumn++)
		{
			result[resultRow][resultColumn] = 0;
			for (UCHAR i = 0; i < aNumColumns; i++)
				result[resultRow][resultColumn] += A[resultRow][i] * B[i][resultColumn];
		}

	}

}

float SuperSampleADC(UCHAR channel)
{
  	UCHAR i;
	ULONG sumOfSuperSamples = 0;

	//TODO: we should disable the analog interrupt while reading from shared variable ADCresults
	for (i=0 ; i < NUM_SUPER_SAMPLES ; i++)
	  	sumOfSuperSamples += (long) ADCresults[channel][i];

	return ((float)sumOfSuperSamples/(float)NUM_SUPER_SAMPLES);
}

//TODO: Currently returns test value
double ConvertCountsToVolts(float counts, float channelGain, float channelDivisor)
{
//	double volts = 0;
//	volts = (double)counts * (double)SMP_REFERENCE_VOLTAGE / (double)4095 / (double)channelGain * (double)channelDivisor;
	//return volts;
	return 1;
}

void AnalogTest(CHAR* arg)
{

	time_t lastTime;
	time_t currentTime;
	CHAR rxData=0x00;
	RTOS_ERR err;
	OS_MSG_SIZE size;
	CPU_TS ts;
	OS_Q* uartMsgQ = GetUartMsgQ(USER_PORT_NUMBER);
	uint32_t sampleA2D;
	float volts;
	INT channel;
	INT parameter;
	float gain;
	float divisor;
	CHAR *tokPtr;

  /* Enable ADC clock */
	CMU_ClockEnable(cmuClock_HFPER, true);	//Enable the High Frequency Peripheral Clock
	CMU_ClockEnable(cmuClock_ADC0, true);	//Enable the ADC CLock
	PinOutSet(TWO_V5_RELAY_ON);				//Turn on the 2.5 Volt Reference

	// If there is a parameter then parse it
	if (arg != NULL)
	{
		// First token
		tokPtr = strtok(arg, ",");
		channel = atoi(tokPtr);
		tokPtr = strtok(NULL, ",");
		parameter = atoi(tokPtr);
		if (parameter == 0)
			gain = 2.5;
		else
			gain = 1.0;
		tokPtr = strtok(NULL, ",");
		parameter = atoi(tokPtr);
		if (parameter == 0)
			divisor = 1.0;
		else
			divisor = 5.0;
	}

	else
	{
		SmpPrintf("\nAnalogTest Channel,Gain,Divisor\n");
		SmpPrintf("\nChannel:\t0 - 4 = channel\n");
		SmpPrintf("\t\t5 = Supply Voltage\n");
		SmpPrintf("\t\t6 = Supply Current\n");
		SmpPrintf("\t\t7 = Backup RTC Voltage\n");
		SmpPrintf("\nGain:\t\t0 = 2.5 , 1 = 1\n");
		SmpPrintf("\nDivisor:\t0 = 1 , 1 = 5\n");
		SmpPrintf(STR_EXAMPLE_USAGE);
		SmpPrintf("\n\tAnalogTest 0,1,1\n");
		return;
	}

	if (channel == 0)
		PinOutSet(CH0_ON);						//Turn on the OP-AMP
	if (channel == 1)
		PinOutSet(CH1_ON);						//Turn on the OP-AMP

	if (channel == 2)
	{
		gain = 0.91/10.91;
		divisor = 1.0;
	}
	currentTime = GetSecondsCounter();
	lastTime = currentTime;

	while(rxData != ESCAPE)
	{
		while(currentTime == lastTime)
		{
			currentTime = GetSecondsCounter();

			// Get characters from message queue.
			rxData = (CHAR)(CPU_INT32U)OSQPend(uartMsgQ,				// MsgQ pointer.
										DELAY_HALF_SEC,				// Timeout in ms converted to ticks.
										OS_OPT_PEND_BLOCKING,		// Task will block.
										&size,						// Size of message.
										&ts,						// Timestamp when message was received.
										&err);						// Error code.

			if (err.Code == RTOS_ERR_NONE)
			{
				// Exit function if ESCAPE was received.
				if (rxData == ESCAPE)
				{
					break;
				}

			}
			else if (err.Code == RTOS_ERR_TIMEOUT)
			{
				continue;
			}
			else
			{
				ErrorOut("OSQPend failure.");
			}

		}

		lastTime = currentTime;

		sampleA2D = adcSingle(channel);
		volts = ((float)sampleA2D / (float)ADC_16BIT_MAX) * (2.5/gain) * divisor ;
		SmpPrintf("\nAD0: Counts = %lu , Volts = %3.3f\n",sampleA2D, volts );

	}
	
	PinOutClear(CH0_ON);						//Turn off the OP-AMP
	PinOutClear(CH1_ON);						//Turn off the OP-AMP
	PinOutClear(TWO_V5_RELAY_ON);				//Turn off the 2.5 Volt Reference

	//SmpPrintf("\n- This is where we will test the analog channels -\n");
}

uint32_t adcSingle(INT channel)
{
  ADC_Init_TypeDef       init       = ADC_INIT_DEFAULT;
  ADC_InitSingle_TypeDef singleInit = ADC_INITSINGLE_DEFAULT;

  init.ovsRateSel = adcOvsRateSel16;

  ADC_Init(ADC0, &init);

  singleInit.acqTime = adcAcqTime32;
  switch(channel)
  {
  	case 0:
  		singleInit.posSel = adcPosSelAPORT2XCH9;
  		break;
  	case 1:
  		singleInit.posSel = adcPosSelAPORT2XCH11;
  		break;
  	case 2:
  		singleInit.posSel = adcPosSelAPORT1XCH8;
  		break;
  	case 3:
  		singleInit.posSel = adcPosSelAPORT2XCH13;
  		break;
  	case 4:
  		singleInit.posSel = adcPosSelAPORT0XCH3;
  		break;
  	case 5:
  		singleInit.posSel = adcPosSelAPORT0XCH1;
  		break;
  	case 6:
  		singleInit.posSel = adcPosSelAPORT0XCH0;
  		break;
  	case 7:
  		singleInit.posSel = adcPosSelAPORT0XCH2;
  		break;
  	default:
  		break;
	}
  singleInit.negSel = adcNegSelVSS;
  
  singleInit.reference = adcRefExtSingle;
  singleInit.resolution = adcResOVS;
  ADC_InitSingle(ADC0, &singleInit);

  ADC_Start(ADC0, adcStartSingle);
  
  /* Wait while conversion is active */
  while (ADC0->STATUS & ADC_STATUS_SINGLEACT)
    ;
  
  /* Get ADC result */
  return(ADC_DataSingleGet(ADC0));
  
}

analog.c

Open with

Displaying analog.c.

5 days ago

Nari Shin

Replied to Leaderboard disappears

No, it was not. Let me check with the team and send you an update.

6 days ago

Nari Shin

reopen KBA_BT_0903: SPP-over-BLE example on blog

Introduction

This example shows how to implement transparent serial data connection between two radio boards or modules.

The goal of this example is to provide a simple template for users that want to use SPP-like communication in their projects. To keep the code as short and simple as possible the features are quite minimal. Users are expected to customize the code as needed to match their project requirements.

The associated sample code is a single application that implements both the server and client roles (in their own C-files). The role is selected dynamically at power-up using pushbuttons, details are found later in the section Running the demo.

The client part of this example (spp_client_main) can be also used as a starting point for any generic BLE central implementation that needs to scan for devices and automatically connect to those devices that advertise some specific service UUID. The client performs service discovery after connection establishment and this process works similarly for any GATT based services. With small modifications the spp_client_main code can be converted into e.g. a “heart rate client” or “thermometer client”.

Project setup

This section guides you through setting up an SPP example application on your kit.

To run this example you need:

Two Wireless Starter Kits (WSTK)
Two radio boards or modules
Two terminal windows (such as TeraTerm or PuTTY) running on your PC

1. Create a new SoC - Empty application project with Bluetooth SDK using version 2.12 or newer.

The example sits on top of the basic SoC - Empty application. We will replace the app.c files with the files provided with this article.

2. Click on the .isc file in your project tree, select the Custom BLE GATT field on the right side of the configurator and finally select Import GATT from .bgproj file from the icons next to the field (the bottommost icon)

3. Select the provided gatt.xml, click Save and finally press Generate. You should now have a new SPP service and within it one characteristic.

4. Copy the following files to your project:

- app.c

- spp_utils.h

- spp_utils.c

- spp_client_main.c

- spp_server_main.c

5. Enable printing to console by setting DEBUG_LEVEL from 0 to 1 in app.h

That's it! When you program the application to your development kit, you should see this print at the serial output:

* SPP server mode *

Keeping button PB0 or PB1 pressed during reset will select client mode, in that case the print will be:

* SPP client mode *

SPP server

There is no standard SPP service in Bluetooth Low Energy and therefore we need to implement this as a custom service. The custom service is about as minimal as possible. There is only one characteristic that is used for both incoming and outgoing data. The service is defined in the gatt.xml file associated with this article and shown below.

<!-- Our custom service is declared here -->	 
  <!-- UUID values generated with https://www.guidgenerator.com/ --> 
  <service uuid="4880c12c-fdcb-4077-8920-a450d7f9b907" advertise="true">
    <description>SPP Service</description>  
    <characteristic uuid="fec26ec4-6d71-4442-9f81-55bc21d658d6" id="xgatt_spp_data">
      <description>SPP Data</description>
      <properties write_no_response="true" notify="true" />
      <value variable_length="true" length="20" type="hex"></value>
    </characteristic>
</service>

At boot event the server is put into advertisement mode. This example uses advertising packets that are automatically filled by the stack. In our custom SPP service definition (see above) we have set advertise=true, meaning that the stack will automatically add the 128-bit UUID in advertisement packets. The SPP client will use this information to recognize the SPP server among other BLE peripherals.

For incoming data (data sent by the SPP client and written to UART in SPP server) we use unacknowledged write transfers (write_no_response). This will give better performance than normal acknowledged writes because several write operations can be fitted into one connection interval.

For outgoing data (data received from UART and sent to SPP client) we use notifications with the command gatt_server_send_characteristic_notification. Notifications are unacknowledged and this will again allow several notifications to be fitted into one connection interval.

Note that the data transfers are unacknowledged at GATT level. This means that at application level there are no acknowledgements. However, at the lower protocol layers each packet is still acknowledged and retransmissions are used when needed to ensure that all packets are delivered.

The core of this SPP example implementation is a 256-byte FIFO buffer (data[] in send_spp_data function) that is used to manage outgoing data. Data is received from UART and it is pushed to the SPP client using notifications. Incoming data from client raises the gatt_server_attribute_value event. The received data will then be copied to UART.

Some simple overflow checking can be optionally included. If the number of bytes exceeds 256 then FIFO overflow happens. Depending on application the overflow situation may be handled differently. For some applications it could be best to just drop the bytes that do not fit in buffer. For other applications it may be better to immediately stop all data transfer to avoid any further damage. See comments in spp_utils.h for more information.

SPP client

In terms of incoming/outgoing UART data, the SPP client works the same way as the SPP server. A similar 256-byte FIFO buffer is used as in the SPP server. The only differences are that:

Data is received over the air by notifications (event gatt_characteristic_value).

Data is sent by calling gatt_write_characteristic_value_without_response.

The client is a bit more complex than the server because the client needs to be able to detect the SPP server by looking at the advertisement packets. Additionally, the client needs to do service discovery after connecting to the client to get the needed information about the remote GATT database.

To be able to use the SPP service the client needs to know the characteristic handle values. The handles are discovered dynamically so that there is no need to use any hard-coded values. This is essential if the SPP server needs to be ported to some other BLE module and the handle values are not known in advance.

At startup, the client starts discovery by calling le_gap_start_discovery. For each received advertisement packet the stack will raise event le_gap_scan_response. In order to recognize the SPP server the client scans through each advertisement packet and searches for the 128-bit service UUID that we assigned for our custom SPP service.

Scanning of advertisement packets is done in function process_scan_response. The advertising packets include one or more advertising data elements that are encoded as defined in the BT specification. Each advertising element begins with a length byte that indicates the length of that field. This makes it easy to scan through all the elements in a while-loop.

The second byte in advertising element is the AD type. The predefined types are listed in Bluetooth SIG website

In this case, we are interested in types 0x06 and 0x07 that indicate incomplete/complete list of 128-bit service values. If such AD type is found, then the AD payload is compared against the known 128-bit UUID of our SPP service to see if there is a match.

After finding a match in the advertising data the client will open a connection by calling le_gap_connect. When connection is opened, the next task is to discover services and figure out what is the handle value that corresponds to the SPP_data characteristic (see XML definition of our custom service attached).

The service discovery is implemented as a simple state machine and the sequence of operations after connection is opened is summarized below:

1) Call gatt_discover_primary_services_by_uuid to start service discovery

2) Call gatt_discover_characteristics to find the characteristics in the SPP service (in FIND_SERVICE state)

3) Call gatt_set_characteristic_notification to enable notifications for spp_data characteristic (in FIND_CHAR state)

Note that in step 1) above we want to discover only services that match the specific UUID we are looking for. Another option would be to call cmd_gatt_discover_primary_services that will return list of all services in the remote GATT database.

After each procedure in the above sequence is completed, the stack will raise event gatt_procedure_completed. The client uses a variable main_state that is used to keep track what is the current state. The gatt_procedure_completed event will trigger the state machine to move on to the next logical state.

When notifications have been enabled the application is in transparent SPP mode. This is indicated by writing string "SPP Mode ON" to UART. After this point, any data that is received from UART is sent to server using non-acknowledged write transfer. Similarly, all data received via notifications (event gatt_characteristic_value) is copied to the local UART.

Note that on the server application there is also "SPP Mode ON" string that is printed to console. On server side this is done when the remote client has enabled notifications for the spp_data characteristic.

The data is handled transparently, meaning that the program does not care at all what values are transmitted. It can be either ASCII strings or binary data, or mixture of these. The connection can be closed by pressing either of the pushbuttons on the client.

Running the demo

Simplest way to run the demo is to use two WSTKs with the same radio board (for example two BGM13S radio boards). In this case you can use the same binary for both boards.

When the application boots, it checks the state of pushbuttons PB0, PB1. If buttons are not pressed, the application starts in SPP server role.

By keeping either PB0 or PB1 pressed during reboot the application starts in SPP client mode.

In server mode, the device advertises the custom SPP service and waits for incoming connections.

In client mode, the device starts scanning and searches for the custom SPP UUID in the scan responses. If match is found, the client connects to the target, discovers the SPP service and characteristics and then enables notifications for the SPP_data characteristic. At this point, any data that is input in the client side is sent over the air to the server and printed on the remote UART. Similarly, any data input to the server UART is transmitted back to the client.

To connect to the kit using terminal program use the following UART settings: baud rate 115200, 8N1, no flow control.

NOTE: Make sure that you are using the same baud rate and flow control settings in your starter kit and radio board or module firmware as well as your terminal program. For WSTK, this can be checked in

Debug Adapters->Launch Console->serial vcom (config speed/handshake)

The above screencapture illustrates what happens when the client and server boards are powered up. Client is on the left side and server on the right. Quickly after power up the client will find the server and open a connection automatically. When the connection is set up properly and notifications are enabled then both applications will output string "SPP Mode ON". This indicates that the transparent serial connection is open. From this point on, any data you type into the client terminal will appear on the server terminal and vice versa.

You can try pressing reset button on either of the boards and see what happens. The connection should be restored automatically when both units are back online. Pressing either of the buttons on the client board will close the connection and print the stats for the last session to the terminal.

Power management

USART peripheral is not accessible in EM2 sleep mode. For this reason, both the client and the server applications disable sleeping (EM2 mode) temporarily when the SPP mode is active. SPP mode in this context means that the client and server are connected and that the client has enabled notifications for the SPP_data characteristics.

When SPP mode is entered, the code calls SLEEP_SleepBlockBegin(sleepEM2) to temporarily disable sleeping. When connection is closed (or client disables notifications) then SLEEP_SleepBlockEnd(sleepEM2) is called to re-enable sleeping.

For more details on the power management details, see article here.

Known issues

This example implementation does not guarantee 100% reliable transfer. The implementation uses retargetserial driver for reading data from UART. The driver is found in <project_root>/hardware/kit/common/drivers/ . For incoming data, the driver uses a FIFO buffer whose size is defined using symbol RXBUFSIZE (default value 8).

To get more reliable operation, it is recommended to increase the RXBUFSIZE value. However, even with a large FIFO buffer, there is a chance that some data is lost if the data rate is very high. If the FIFO buffer in RAM becomes full, the driver will simply drop the bytes that do not fit in. More discussion about this topic is found in following forum thread: SPP-over-BLE C example for UART receive data is lost

Conclusion

This example is a simple C-based SPP implementation for BGMxxx / EFR32BG products. It is not optimized for performance or low power. The code has been kept as simple as possible.

UART input/output is handled using stdio retarget functions (see this article for details.)

This is not the most efficient way to handle UART input/output but the benefit is that it is portable and allows the sample code to be used easily on several radio boards without any modifications.

7 days ago

Nari Shin

reopen KBA_BT_0903: SPP-over-BLE example on blog

Introduction

This example shows how to implement transparent serial data connection between two radio boards or modules.

Project setup

This section guides you through setting up an SPP example application on your kit.

To run this example you need:

Two Wireless Starter Kits (WSTK)
Two radio boards or modules
Two terminal windows (such as TeraTerm or PuTTY) running on your PC

1. Create a new SoC - Empty application project with Bluetooth SDK using version 2.12 or newer.

The example sits on top of the basic SoC - Empty application. We will replace the app.c files with the files provided with this article.

3. Select the provided gatt.xml, click Save and finally press Generate. You should now have a new SPP service and within it one characteristic.

4. Copy the following files to your project:

- app.c

- spp_utils.h

- spp_utils.c

- spp_client_main.c

- spp_server_main.c

5. Enable printing to console by setting DEBUG_LEVEL from 0 to 1 in app.h

That's it! When you program the application to your development kit, you should see this print at the serial output:

* SPP server mode *

Keeping button PB0 or PB1 pressed during reset will select client mode, in that case the print will be:

* SPP client mode *

SPP server

<!-- Our custom service is declared here -->	 
  <!-- UUID values generated with https://www.guidgenerator.com/ --> 
  <service uuid="4880c12c-fdcb-4077-8920-a450d7f9b907" advertise="true">
    <description>SPP Service</description>  
    <characteristic uuid="fec26ec4-6d71-4442-9f81-55bc21d658d6" id="xgatt_spp_data">
      <description>SPP Data</description>
      <properties write_no_response="true" notify="true" />
      <value variable_length="true" length="20" type="hex"></value>
    </characteristic>
</service>