The adc-uart sampling is only about 9k.

RE: The adc-uart sampling is only about 9k.

Karl Ylvisaker — Wed, 07 Apr 2021 14:07:16 GMT

[quote user="odenwar"]How do you handle the above method?[/quote]

Please keep in mind that I have no prior knowledge of the 'Arduino optimized float' implementation you reference - but it sounds to me like it is just a regular float type (4 bytes) with 2 bytes tacked on at the end, to delimitate the float, is this correct?
If so, you expect to send these two static bytes at the end of every float (every sample) you send. If you instead just do not send them, but add them at the receiver side (which might be an arduino?) instead, you save yourself the trouble of sending the two end characters over and over - since they always will be present.
So, you just send the 4 meaningful float bytes, and every time the Arduino receives a new float (every 4 bytes), it adds the delimination characters to the end.
I might have misunderstood you earlier, and I am unable to find any direct reference to 'Arduino optimized float', so my suggestion might not be applicable.
Please let me know if I should elaborate on this, or if any part of my suggestion is unclear.

[quote user="odenwar"]I'll check it out during business hours.[/quote]

Great, I look forward to hearing how it goes!
Please also see my earlier suggestion about increasing the sample buffer size.

Best regards,
Karl

RE: The adc-uart sampling is only about 9k.

odenwar — Tue, 06 Apr 2021 15:39:38 GMT

[quote userid="87869" url="~/f/nordic-q-a/73613/the-adc-uart-sampling-is-only-about-9k/303257#303257"]If you wish to maximize the frequency of useful bytes you should instead just send the 4 meaningful float bytes, and then add the 2 arduino overhead bytes on the receiver side. This will increase your throughput of SAADC samples by 33%, so its quite the improvement.[/quote]

How do you handle the above method?

[quote userid="87869" url="~/f/nordic-q-a/73613/the-adc-uart-sampling-is-only-about-9k/303257#303257"]Could you also tell me whether you are using the deferred logging option or not, like I asked in my previous comment? This is set by the NRF_LOG_DEFERRED define in your sdk_config.h file.
If this is the case, your logger will only process the logs once NRF_LOG_PROCESS is called, which typically is only when the CPU has nothing else to do - right before going to SYSTEM ON sleep.[/quote]

I'll check it out during business hours.

RE: The adc-uart sampling is only about 9k.

Karl Ylvisaker — Tue, 06 Apr 2021 15:21:09 GMT

[quote user="odenwar"]Thank you for responding to complex questions.[/quote]

No problem at all, I am happy to help!

[quote user="odenwar"]The final goal of this question is I would like to use all the resources of UART for ADC data output.[/quote][quote user="odenwar"]The version you are using is 15.3.0.[/quote]

Thank you for clarifying, this is very helpful for me to understand your issue and goal.

[quote user="odenwar"]

1Hz,

1Hz Freq Sine wave.
3.3 Ampl Vp-p
1.65V Offset

[/quote]

Aha, I not understand that you were referring to what is being sampled. Thank you for clarifying. I was not sure if this was the case, since exactly what is being measured does not matter for the frequency of the samples and their output through UART - but it is good to have mentioned never the less, thank you.

[quote user="odenwar"]1 Shipping data optimized for uart graph drawing is as follows.
Data character [4 bytes] + (\r\n) [2 bytes]
It is a total of 6 bytes.[/quote]

If you wish to maximize the frequency of useful bytes you should instead just send the 4 meaningful float bytes, and then add the 2 arduino overhead bytes on the receiver side. This will increase your throughput of SAADC samples by 33%, so its quite the improvement.

Furthermore, you could try to increase the sample buffer size, as mentioned in my previous comment.

[quote user="odenwar"]I want to capture the ADC data 70us after data transmission and send it to uart. (For 10us spare, the shorter the better, but if there is no problem, I want to send it immediately.)[/quote]

If you want the sample to happen exactly 70us after the previous sample was successfully transmitted, you should setup a timer to start when you receive the TX success event. Are you currently using NRF_LOG_RAW_INFO to send over the UART?
If you would like to reduce the time between bytes sent, you should use the UARTE driver directly.

Could you also tell me whether you are using the deferred logging option or not, like I asked in my previous comment? This is set by the NRF_LOG_DEFERRED define in your sdk_config.h file.
If this is the case, your logger will only process the logs once NRF_LOG_PROCESS is called, which typically is only when the CPU has nothing else to do - right before going to SYSTEM ON sleep.

Best regards,
Karl

RE: The adc-uart sampling is only about 9k.

odenwar — Tue, 06 Apr 2021 15:04:10 GMT

The final goal of this question is I would like to use all the resources of UART for ADC data output.

We will answer your questions on this basis.

[quote userid="87869" url="~/f/nordic-q-a/73613/the-adc-uart-sampling-is-only-about-9k/303220#303220"]but it fails in communication at 70us.[/quote]

Please check the third image.

60us about Data transmission,

I want to capture the ADC data 70us after data transmission and send it to uart. (For 10us spare, the shorter the better, but if there is no problem, I want to send it immediately.)

The version you are using is 15.3.0.

[quote userid="87869" url="~/f/nordic-q-a/73613/the-adc-uart-sampling-is-only-about-9k/303220#303220"] I am not sure that I am seeing any 1 Hz configuration[/quote]

1Hz,

1Hz Freq Sine wave.
3.3 Ampl Vp-p
1.65V Offset

[quote userid="87869" url="~/f/nordic-q-a/73613/the-adc-uart-sampling-is-only-about-9k/303220#303220"]the optimized Arduino float output[/quote]

This is the contents of using Arduino's serial plotter program.

1 Shipping data optimized for uart graph drawing is as follows.
Data character [4 bytes] + (\r\n) [2 bytes]
It is a total of 6 bytes.

When sending data continuously, is 20k correct as I calculated?
What is the maximum number of samples for ADC between uart 1000000 baud rate at 12bit ADC?

Thank you for responding to complex questions.

RE: The adc-uart sampling is only about 9k.

Karl Ylvisaker — Tue, 06 Apr 2021 14:21:29 GMT

Hello,

[quote user=""]but it fails in communication at 70us.[/quote]

Please elaborate what you mean when you say that it fails at 70us. Do you mean that you are not seeing the sample output on UART every 70 us, or are you saying that a sample is not taken every 70us?
Please also tell me if you are using the deferred logging option. This option will postpone log-processing until you reach your power management loop in the main context.

I am also not exactly sure what you mean when you say "I want to make 110us-40us, 70us data transmission cycle".
Are you saying that you would like your current setup of a sample written to UART every 110us to instead write out the sample every 70us to UART?
To reduce the time actively spent by the CPI in the SAADC interrupt handler you could increase your sample buffer size. A size of 1 means that you CPU has to intervene and go through the SAADC interrupt handler every time a sample is produced.
Additionally, please be aware that you are using the default channel configuration which uses 10us acquisition time.

Could you also tell me which SDK version you are using?

[quote user=""]

To check this, the following settings were made.

1 Hz, 3.3 Vp-p

0.nRF52832
Baud rate 1000000
ADC Sampling bit 12bit
Modify the source code to check the optimized Arduino float output value (data [4byte] + newline character [2byte] = 6byte)

[/quote]

I understand that you are working with the SAADC peripheral example from the SDK, and that you have made some changes to it. Could you elaborate on these two changes you have detailed? I am not sure that I am seeing any 1 Hz configuration, and I am not sure how you have included / what you mean when saying 'the optimized Arduino float output'. Please elaborate on this so I may understand your issue better.

Looking forward to resolving this issue together!

Best regards,
Karl