This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Need help on how to integrate this Industrial Analog Accelerometer+Temperature Sensor into nRF52810.

Datasheet of the Sensor:

www.ctconline.com/.../1_VS_TA102_DS.pdf

Accelerometer Out = 100mV/g =equivalent to=> +/- 8Vpk-pk

Temperature Out = 10mV/°C

Please provide hardware and software assistance. 

Thank you!

Paul

  • Hello Paul,

     

    You can start by looking into the SAADC example, as I think this will be what you use to read the measurements from the sensor.

     

    You must remember to scale down the input voltage for the nRF. 8V is a bit high to input directly on a pin.

     

    Best regards,

    Edvin

  • Hi Edvin,

    I am able to convert the +/-8V to 0-3.3V.

    Now we are working on a FW with SAADC plus UART.

    I found this post with a sample program:

    https://devzone.nordicsemi.com/f/nordic-q-a/13092/sending-saadc-over-ble

    The SAADC is working and it is sending to the UART, I can see the values using TeraTerm.

    But the problem is the data that it is being thrown to the mobile apps does not match the values shown in the console.

    What I am seeing on the nRF Connect app are random garbage characters.

    Can you help to look on that sample code and see if you can suggest for the fix?

    Also that sample is based on SDK11, is there a similar sample based on SDK15?

    Thanks,
    Paul

  • Hello Paul,

    I attached a project that is sending SAADC values over the Nordic Uart Service.

    The handling of the SAADC events to the softdevice is not perfect, as it ignores the errors that would suggest that there is something wrong with the connection handle, but that is only so that the project doesn't crash before you connect to it.

     

    However, the values are probably "garbage characters" here as well. I suspect that they are similar to your values. The reason for this is that they are sent as hexadecimal values. If you open nRF Connect for Desktop, you can see that the first two bytes represent the first number from the uart, and the next two are the second value and so on. If you want them to print in ascii format, you will have to convert the numbers before sending them. 

     

    The attached project is for SDK15.0.0. Unzip it to the same path as ble_app_uart.

    It is written in Keil, so if you want to use another IDE, you must include some of the .c-files. PPI, SAADC and TIMER files are the ones that are added. Your compiler should give you some hints on what files that are missing.

    I think all the files that I included are the following:

    nrfx_ppi.c
    nrfx_saadc.c
    nrfx_timer.c
    nrf_drv_ppi.c

    ble_app_uart_SAADC.zip

     

    The project that I used is the pca10040e (with the s112 softdevice). If you want to use one of the other DKs, I think that it should work as well, but I have not tested it. You would also have to add the files mentioned above, and use the same defines in sdk_config.h, that is used in the pca10040e project.

     

    Best regards,

    Edvin

  • Hi Edvin,

    We are able to use the sample code that you send and modify it to send the correct data into the mobile apps. Now, it works. Thanks.

    Now, we want to connect an external flash (MX25R6435F) to nRF52832.

    We want to save the gathered data from the sensors reading into this external flash.

    Do you have a guidelines on how to implement in HW & FW adding this external flash?

    Can we use any unused GPIOs to connect to the Flash?

    Thanks,
    Paul

  • Hello,

    Yes. You can use some of the remaining pins for this. The nRF52840 has a QSPI, and the SDK has an example using the MX25R6435F (which is on the nRF52840 Preview Development Kit). The nRF52832 does not have QSPI, but you can use regular SPI, but maybe you can use some parts of the QSPI example for the nRF52840 to implement the SPI for the same external flash using regular SPI.

     

    As for HW layout, I am no expert. If you have any HW questions, I can forward them to one of our HW engineers.

     

    Best regards,

    Edvin

Related