Capturing GPIO transitions of a 4kHz signal with BLE enabled

RE: Capturing GPIO transitions of a 4kHz signal with BLE enabled

RSchmale — Thu, 18 Aug 2022 07:46:05 GMT

hi dj1234

i have the same question about capture gpio to read manchester code. do you solve the problem and it is possible to get the code from you?

RE: Capturing GPIO transitions of a 4kHz signal with BLE enabled

dj1234 — Thu, 03 Oct 2019 05:57:14 GMT

Ok got it working! Here's my flow

SAADC points to a sample buffer to capture 512us worth of samples
Start SAADC (loads the contents RESULT.PTR registers and generates a STARTED event)
PPI initiates Sampling of the SAADC on the STARTED event
STARTED event generates an interrupt. Prepare the RESULT.PTR register with the next buffer
SAADC generates an END event when sampling buffer is full
PPI Starts the SAADC on the END event (outcome same as step 2)
END event generates an interrupt. Notify the thread that sampling is complete.
Thread processes the buffer with the sampling data that was complete

I measured a 4kHz input signal and the period measurement was spot on. Thanks a lot for your help haakonsh.

RE: Capturing GPIO transitions of a 4kHz signal with BLE enabled

haakonsh — Tue, 01 Oct 2019 13:54:07 GMT

[quote user="dj1234"]The STARTED event is generated when SAADC starts filling in the supplied buffer.[/quote][quote user="dj1234"]An Interrupt is generated where I'm free to update the RESULT.PTR register.[/quote]

The STARTED event is generated after the RESULT.PTR and RESULT.MAXCNT registers have been read and loaded by the SAADC peripheral. At which point it is safe to update the .PTR and .MAXCNT registers again by the application. When the END event is fired a START task can be immediately triggered to load the next .PTR and .MAXCNT values into the SAADC.

You can, for instance, connect the START task to the END event via PPI, given that the .PTR and .MAXCNT registers have been updated since the last STARTED event fired.

static void ppi_saadc_init()
{
	NRF_PPI->CH[0].EEP = (uint32_t)&NRF_SAADC->EVENTS_END;
	// NRF_PPI->CH[0].TEP = (uint32_t)&NRF_SAADC->TASKS_SAMPLE; Undefined operation, STARTED event must fire before sampling can continue.
	NRF_PPI->FORK[0].TEP = (uint32_t)&NRF_SAADC->TASKS_START;
    nrf_ppi_channel_enable(NRF_PPI_CHANNEL0);
}

It seems that you trigger the sample task via CPU at regular intervals, I recommend that you instead employ a TIMER's COMPARE event to trigger the SAMPLE task, trigger the TIMER's START task from the SAADC's STARTED event, and trigger the TIMER's STOP task from the SAADC's END event.

This will set up a continuous cycle of sampling with a fixed delay between the END event and until the first sample is taken.
You can even refreign from stopping the TIMER at the END event and let it run to get a truly jitter-free sample rate across all buffers, but only if the SAADC's STARTED event has fired before the first SAMPLE task is triggered by the TIMER. I don't know the exact time from the SAADC's started task until it fires the STARTED event btw.

Also, by enabling the shortcut between a TIMER's COMPARE event and it's CLEAR task you create a free-running timer. See SHORTS.

RE: Capturing GPIO transitions of a 4kHz signal with BLE enabled

dj1234 — Tue, 01 Oct 2019 06:03:43 GMT

Yes it is a fun project.

One more thing. I don't think I can simply rely on the GPIO to start the SAADC because, a transponder may not be in contact, in which case I think the DOUT pin will be toggling at random intervals. The Manchester sample code that I linked to earlier looks for the preamble to actually get the timing. So I think I will need an edge detection algorithm.

This is what I started doing:

Setup the SAADC to run continuously at 16us intervals (using the internal timer) filling a 64 sample buffer (which covers a millisecond worth of samples)
Run a process that looks for edges. At 16us, I have 16 samples within a 256us interval which gives me a 6% error margin which I think is acceptable.
Run the Manchester decoder on the processed data

My implementation assumes the following:

The STARTED event is generated when SAADC starts filling in the supplied buffer.
- An Interrupt is generated where I'm free to update the RESULT.PTR register.
Once the buffer is filled, an END event is generated
- The PPI restarts the SAADC with the new RESULT.PTR register value
- By the time the END interrupt handler is invoked, the SAADC is already filling up the next buffer, I have plenty of time to process the previous buffer
- Because the PPI has restarted the SAADC, a STARTED event is generated allowing the process to continue

But I seem to be occasionally missing some samples as the period between transitions vary a bit too much (especially while BLE is running).

Here's an extract of my implementation (C + pseudocode):

#define BUFFER_COUNT		3
#define BUFFER_SIZE			32

static nrf_saadc_value_t     adc_buf[BUFFER_COUNT][BUFFER_SIZE];
static uint8_t buffer_head;
static uint8_t buffer_tail = 1;


static void saadc_init()
{
    nrf_saadc_resolution_set(NRF_SAADC_RESOLUTION_8BIT);
    nrf_saadc_oversample_set(NRF_SAADC_OVERSAMPLE_DISABLED);

    nrf_saadc_int_disable(NRF_SAADC_INT_ALL);
    nrf_saadc_event_clear(NRF_SAADC_EVENT_END);
    nrf_saadc_event_clear(NRF_SAADC_EVENT_STARTED);
    nrf_saadc_event_clear(NRF_SAADC_EVENT_STOPPED);
    NRFX_IRQ_PRIORITY_SET(SAADC_IRQn, 6);
    NRFX_IRQ_ENABLE(SAADC_IRQn);
    nrf_saadc_int_enable(NRF_SAADC_INT_END);
    nrf_saadc_enable();
}


static void saadc_channel_init()
{
	nrf_saadc_channel_config_t channel_config = SAADC_HISPEED_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_AIN0);
    nrf_saadc_channel_init(0, &channel_config);
}


static void saadc_buffer_init()
{
    nrf_saadc_int_enable(NRF_SAADC_INT_STARTED | NRF_SAADC_INT_END);
	nrf_saadc_buffer_init(adc_buf[0], BUFFER_SIZE);
	nrf_saadc_event_clear(NRF_SAADC_EVENT_STARTED);
	nrf_saadc_task_trigger(NRF_SAADC_TASK_START);
}


static void ppi_saadc_init()
{
	NRF_PPI->CH[0].EEP = (uint32_t)&NRF_SAADC->EVENTS_END;
	NRF_PPI->CH[0].TEP = (uint32_t)&NRF_SAADC->TASKS_SAMPLE;
	NRF_PPI->FORK[0].TEP = (uint32_t)&NRF_SAADC->TASKS_START;
    nrf_ppi_channel_enable(NRF_PPI_CHANNEL0);
}


void process_thread()
{
    uint8_t buffer_index;
    nrf_saadc_task_trigger(NRF_SAADC_TASK_SAMPLE);
    
    for(;;)
    {
        // Wait for END notification
        AWAIT_BUFFER_READY(&buffer_index);
        ; // process data saadc data here
    }
}


main()
{
    saadc_init();
    saadc_channel_init();
    nrf_saadc_continuous_mode_enable(256);
    saadc_buffer_init();

	ppi_saadc_init();
	
	process_thread();
}


void nrfx_saadc_irq_handler(void)
{
	BaseType_t xHigherPriorityTaskWoken = pdFALSE;

	// This is a higher priority event. Handle END first and if necessary also handle the STARTED
	if (nrf_saadc_event_check(NRF_SAADC_EVENT_END))
	{
		nrf_saadc_event_clear(NRF_SAADC_EVENT_END);
		
		// Sampling complete / buffer full event. The PPI has already initiated next
		// sampling already started on the next buffer so we have no problems with interrupt latency.
		// Simply notify the running thread that a buffer is ready to be processed. The thread needs
		// to process this buffer before the next one buffer is filled.

		NOTIFY_BUFFER_READY(buffer_head)
        buffer_head = (buffer_head + 1) % BUFFER_COUNT;
	}

	// End of conversion events need to be lower priority compared 
	if (nrf_saadc_event_check(NRF_SAADC_EVENT_STARTED))
	{
		// Yes. Prepare the next buffer that the data will be written to
		nrf_saadc_event_clear(NRF_SAADC_EVENT_STARTED);

		nrf_saadc_buffer_pointer_set(adc_buf[buffer_tail]);
        buffer_tail = (buffer_tail + 1) % BUFFER_COUNT;
	}
}

Do you see anything obvious that would account for it?

RE: Capturing GPIO transitions of a 4kHz signal with BLE enabled

haakonsh — Mon, 30 Sep 2019 11:22:04 GMT

Aah, I see.

FromHT2 Transponder Family Communication Protocol, page 8:
"The first bit of the transmitted data always starts with the Modulator ON (loaded) state."

It looks like the data signal always starts with a logical high, so you can start a TIMER based on a low-to-high GPIOTE transition, as long as you've got a weak pull-down resistor on the line.

Also, the Manchester encoding is of the G.E Thomas variety, so you don't even need to XOR the data bits with the clock, as long as you sample in the first half-period of a symbol.

With BIPHASE decoding you'll need to sample both half-periods of each symbol and find what pair has two identical values, representing a '1', and who's got two different values, representing a '0'.

Anyways, this looks like a fun project, let me know if you need any more help.

RE: Capturing GPIO transitions of a 4kHz signal with BLE enabled

dj1234 — Mon, 30 Sep 2019 00:25:04 GMT

[quote userid="13562" url="~/f/nordic-q-a/52388/capturing-gpio-transitions-of-a-4khz-signal-with-ble-enabled/212098"]The HTRC110 does not appear to be using a manchester encoded protocol since it has a separate clock signal.[/quote]

That's true as long as we're talking to the reader chip. However, once the READ_TAG command is issued, the reader chip becomes a effectively a pass-through device to the RF transponder (specs for that are here).

I just realised that the CPU uses the READ_TAG and WRITE_TAG commands to communicate with the transponder which sends it's data in Manchester encoded format.

So I don't believe that I'll be able to use the SCLK as a trigger. However, SAADS with a pure timer sampling the data as you suggested I think will do the trick. i'll give that a go.

Thank you very much for your help

RE: Capturing GPIO transitions of a 4kHz signal with BLE enabled

haakonsh — Thu, 26 Sep 2019 14:53:30 GMT

I just realize that you can probably use the SPIM peripheral for this as this looks like SPI without CS/SS. If this is the case then this will be the easiest solution by far.

It looks like you'll have to find the frequency of SCLK by trial-and-error, I suggest starting at 125kHz.

RE: Capturing GPIO transitions of a 4kHz signal with BLE enabled

haakonsh — Thu, 26 Sep 2019 14:16:39 GMT

The HTRC110 does not appear to be using a manchester encoded protocol since it has a separate clock signal. The defining attribute of a manchester encoded signal is that it's self-clocking, where the clock signal is modulated into the signal itself.

But this does not really change much in your case, it actually makes things a lot easier since the MCU controls the SCLK and DIN lines. Now we can use the SCLK timings to trigger SAADC sampling of the DOUT line on positive clock periods.

See "Fig 4. Serial signaling" in https://www.nxp.com/docs/en/data-sheet/037031.pdf.

What you need to do:

Create a clock signal with a TIMER and GPIOTE.
Create a driver for the digital input line, DIN, with manual SW GPIO toggling or maybe even use the PWM peripheral for that. I'm not 100% sure we can use the PWM for this, but if we can then you will be able to send commands to the HTRC110 without using the CPU to control the GPIO for the DIN line, as the PWM peripheral can be configured to use a pre-defined 'sequence' in RAM with EasyDMA.
Setup the SAADC to sample on the SCLK's positive flank changes, based on the TIMER it runs on.
Run the process I described earlier on the samples to get the data.

RE: Capturing GPIO transitions of a 4kHz signal with BLE enabled

haakonsh — Thu, 26 Sep 2019 13:17:44 GMT

Only the first rising edge (or low, as long as it's consistent), we can use the first rising edge to trigger the start of a TIMER that in turn triggers SAADC sampling in the middle of the positive clock periods.

RE: Capturing GPIO transitions of a 4kHz signal with BLE enabled

dj1234 — Thu, 26 Sep 2019 02:58:42 GMT

This is a bit tricky to answer. I'm interfacing with an HTRC110 reader chip and none of the documentation clearly states what Type of Manchester it is. The only reason I believe it's Manchester is because a sample driver found here mentions it.

I had a look at a waveform of the RF chip on an existing product (I don't have the source for it) and it's a waveform with a minimum duration of 256us between two rising edges. This tallies with the comments in the sample code.

RE: Capturing GPIO transitions of a 4kHz signal with BLE enabled

dj1234 — Thu, 26 Sep 2019 02:48:30 GMT

Hi Thanks very much for your response.

That's an interesting idea... I hadn't considered using the ADC to manually sample a waveform. However, I'm a bit confused with your suggestion to start the timer on the rising edge. Did you mean the *first* rising edge of the signal or *every* rising edge?

RE: Capturing GPIO transitions of a 4kHz signal with BLE enabled

haakonsh — Tue, 24 Sep 2019 09:48:28 GMT

Can you specify exactly what kind of Manchester encoding you're using?
Can you ensure that each transfer starts with a low-to-high or optionally high-to-low transition?

RE: Capturing GPIO transitions of a 4kHz signal with BLE enabled

haakonsh — Tue, 24 Sep 2019 08:41:35 GMT

If you know the clock frequency and length you can set up a TIMER to trigger a SAADC sample task in the middle of each positive clock period. You start the TIMER on a GPIOTE pin change. That way you can capture a waveform and store it in RAM without using the CPU at all, and then process the data whenever the CPU is available.

Since the signal is digital it should be fairly easy to convert from analog to digital, I suppose you can right-shift the analog 16-bit integer down to msb, then XOR with 1 to get the original data bit.

ex:
At 10-bit accuracy, say the SAADC samples yield between 512-1023dec for '1's and 0-511dec for '0's. Then right shifting the samples by 9 bits will leave you with the manchester-encoded bit.

The samples are stored as an array, so for a 32-bit transmission, you will need a buffer size of 16bit x 32 = 64bytes

#define BufSize 32

int16_t     MyBuffer[BufSize];
uint32_t    Data = 0;

//After the data is captured:
for(uint16_t i=0; i < BufSize; i++)
{
    My_Buffer[i] &= 0x3FF;          // Remove sign bit if a '0' is registered as negative number
    
    MyBuffer[i] = (MyBuffer >> 9);  /* '9', because at 10-bit precision with signed value 
                                    the 9th bit is half of max value*/
                                    
    Data |= (MyBuffer[i] << i);        // OR-in the Manchester-encoded bit into a data buffer
}
Data ^= 0xFFFFFFFF; //XOR with the clock signal, represented by '1's. 

//Repeat for however many 32-bit words your transfers are.