NRF52 real sampling rate different

RE: NRF52 real sampling rate different

Jong yoon lee — Fri, 26 Aug 2016 03:37:40 GMT

I Fixed the Problem! Even with TImeSlot going on, I am getting a transfer rate of a value little over 1000 when i have the sampling rate of 1KHz.

I just had a simple error in my code.(Off by one error)

RE: NRF52 real sampling rate different

Jong yoon lee — Fri, 12 Aug 2016 19:14:10 GMT

OK, that sounds good. I though using PPI would be the work around. Can you link me to any good source that I can read regarding this topic Thanks.

RE: NRF52 real sampling rate different

Øyvind Karlsen — Fri, 12 Aug 2016 11:35:17 GMT

Hi,

Yes and no. You can expect that there will be some packet loss, but BLE is a reliable protocol. Every packet is acknowledged if it is received, so if it does not get received it will get retransmitted. This is handled automatically for you by the SoftDevice.

What you are likely seeing is that the measurements that occur during BLE connections are failing. You can work around/with this, but I suggest doing some reading on time critical measurements and SoftDevice usage first and then creating a new question as we are moving beyond the scope of the initial topic.

RE: NRF52 real sampling rate different

Jong yoon lee — Fri, 12 Aug 2016 10:45:48 GMT

Sorry for the late update! I did some testing and as you said the ppi and ssadc timings were very accurate. However, it turned out that I was losing data while they were being sent to the phone via BLE. With the connection interval at 10ms and sending 16 bytes per packet, I was able to only receive 80% of the total packet I send. This was regardless of the sampling rate(I tried 125Hz 500Hz 1000Hz). I did some research online and some say that BLE is not a reliable protocol and is expected to lose some packets on air. Is this true about BLE? I expect the packet loss rate to be much lower. If the data loss rate is true is there other ways I can reduce the packet loss?

RE: NRF52 real sampling rate different

Øyvind Karlsen — Tue, 19 Jul 2016 07:45:12 GMT

Well, running a lot of things at the same time means there are more things that can potentially go wrong. However I think this should be fairly simple to get running. By the way, it may be worth looking into the Application timer tutorial if you will use the LFCLK.

The SoftDevice uses the HFCLK at two times, when the radio is running and when it has to calibrate the LFRC (Low frequency RC clock source, if you do not have a separate LF crystal). The HFCLK adds a lot of current consumption when running, and should therefore be left off when not in use.

RE: NRF52 real sampling rate different

Jong yoon lee — Mon, 18 Jul 2016 19:12:51 GMT

Hello, Thank you for your thoughtful answer. I will go ahead and do the GPIO test today.

In My question, I forgot to indicate that I was using timeslot for multiprotocol with nrf_esb. Can that be the reason it would not work?

Also, I have one question regarding your answer. With soft device working, I thought that HFCLK will always run because I do not have code anywhere that turns the HFCLK on. Is this not true and will the HFCLK only be turned on when a radio event is happening?

Thank you, John Lee

RE: NRF52 real sampling rate different

Øyvind Karlsen — Mon, 18 Jul 2016 13:29:39 GMT

Hi,

Since you are using 8ms sample intervals the HFCLK based TIMER is not recommended as it adds a lot of current consumption. Instead you can use the LFCLK.

The sample rate is relatively slow, so you should not need to be worried about being interrupted by SoftDevice activity. To ensure that you do not collide with the SoftDevice you can read the buffers from a lower priority interrupt when the application has time.

Instead of using the SAADC directly have you tried to set a GPIO using the task and measuring the frequency, if so, what did you get?

Best regards,

Øyvind