PDM conflict with bluetooth transceiver

RE: PDM conflict with bluetooth transceiver

Jeffrey Haynes — Mon, 06 Sep 2021 14:06:11 GMT

Did anyone ever figure this out? I'm seeing a similar issue although in my case the PDM update basically seems to nuke the radio.

RE: PDM conflict with bluetooth transceiver

bjorn-spockeli — Wed, 06 Nov 2019 11:21:20 GMT

I don't believe this is a buffer issue. If the PDM peripheral stops because of a lack of buffer, same result should be got when I stop the bluetooth advertising, while, in fact, the gap is gone and PDM woks normal when I stop the bluetooth.

The SoftDevice will interrupt the application and use the CPU for pre-processing of BLE events. Hence, if the buffer is filled up just as the SD interrupts the application, then the pdm_buffer_handler would not be allowed to run until the SD is finished. When not starting any advertsing or scanning, then there would be no events that would interrupt the application and possibly delay the buffer change.

However I agree that it does not appear to be the case as the DIN gaps occur after the STARTED event when there should be plenty of space in the buffer.

In screenshot 1, I see that the DIN line is pulled low aperiodically, while the advertisment events should be occuring every 40ms based on the advertisment interval set in the main.c . I see that you are using the ble_app_uart example, which doesnt set any scan response data so is the periods when the DIN line is low when you are connected to the nRF52840 with aphone and transmitting data to the nRF52840?

I am afraid that I do not have a PDM device to generate a PDM output to sample with the PDM peripheral. I will see if I can get hold of one to do some testing today.

RE: PDM conflict with bluetooth transceiver

Kyle@Shanghai — Mon, 04 Nov 2019 09:30:10 GMT

Hi bjorn:

I made the buffer size to 4096 and it has no change.

As you advise, I add toggle pins in the PDM event handler, here is the result:

1,BLE advertising enabled.

2,BLE advertising disabled

It will be really appreciate if you could run my case in your side, I believe it will speed up our debug process, saving the time both your and mine.

RE: PDM conflict with bluetooth transceiver

bjorn-spockeli — Fri, 01 Nov 2019 09:58:11 GMT

Ok, then I think we can rule out interference from the RADIO.

Could you just try to double the buffer size? Just want to make sure this isnt a buffer issue.

Also it would be nice if you could log or toggle pins when you get the

NRF_PDM_EVENT_STARTED

NRF_PDM_EVENT_STOPPED

NRF_PDM_EVENT_END

events in the nrfx_pdm_irq_handler in nrfx_pdm.c

RE: PDM conflict with bluetooth transceiver

Kyle@Shanghai — Fri, 01 Nov 2019 02:27:18 GMT

Hi bjorn:

I tried P0.26 and P0.27, but it doesn't help, same as before.

RE: PDM conflict with bluetooth transceiver

bjorn-spockeli — Thu, 31 Oct 2019 08:16:55 GMT

Hi Kyle,

I see that you're initializing the PDM peripheral with the CLK and DIN pins set to 37 and 38 respectively, i.e. PSEL.CLK and PSEL.DIN are set to Port 1, pin 5 and Port 1, pin 6. Looking at the Pin assignments in the nRF52840 Product Specification, these pins should only used for low frequency signal due to their proximity to the Radio power supply and antenna pins. By low frequency signals we mean signals with a frequency up to 10 kHz. So it could be that the RADIO is affecting the DIN pin.

Could you try using pins that are not restricted to low frequency signals, e.g. P0.26 and P0.27 and see if the behavior persits?

RE: PDM conflict with bluetooth transceiver

Kyle@Shanghai — Thu, 31 Oct 2019 02:47:51 GMT

Hi bjorn:

I don't think so, can you have at look at my code-- main.c, line 702 to 714, this is how I handle the PDM buffer. Every time I receive the buffer request, I call nrfx_pdm_buffer_set function to feed a buffer to PDM driver without delay, so I don't think this is cause by lack of buffer.

I do a experiment to prove this:

1, I modify the PDM callback function like the following, each time when a buffer is requested or released I will invert an LED.

2, I connect the pins controlling these LED to my logical analyser, they are P0.14 for LED1, P0.15 for LED2, P0.16 for LED3.

void pdm_buffer_handler(nrfx_pdm_evt_t const * const p_evt)
{
	if(p_evt->buffer_requested == true)
	{
		bsp_board_led_invert(2);
		nrfx_pdm_buffer_set(&pdm_buffer[buffer_ptr][0], PDM_BUFFER_BLOCK_LENGTH);
		buffer_ptr = (buffer_ptr + 1) % PDM_BUFFER_BLOCK_NUM;
	}
	
	if(p_evt->buffer_released != NULL)
	{
		bsp_board_led_invert(1);
	}	

	if(p_evt->error != NRFX_PDM_NO_ERROR)
	{
		bsp_board_led_invert(3);
	}
}

This is the result I got:

As you can see, LED2 and LED3 keep toggling even in the gaps, so I believe no NRF_PDM_EVENT_END happend.

RE: PDM conflict with bluetooth transceiver

bjorn-spockeli — Wed, 30 Oct 2019 14:19:10 GMT

HI Kyle,

the PDM driver should place all the received data directly to DMA without being affected by the SoftDevice using the CPU for BLE purposes.

Can you check if the buffers are full when the PDM transmission stops, i.e. if the NRF_PDM_EVENT_END occurs just before the gaps?

If this is the case, then it is possible to get notified by the SoftDevice in advance of any BLE activity by using the Radio Notification feature. This way you can set up a new and empty buffer just before a BLE activity to ensure contineous sampling.

Best regards

Bjørn