How to capture GPADC data through RFMON interface?

Hi,

 

The document REN_DA1470x_Errata_1v1_DVE_20220928.pdf mentions following information:

 

5.25 RFMON Fails to Capture GPADC Data when SYS_CLK is Asyncronous to CMAC_CLK

5.25.1 Effect

RFMON fails to capture GPADC data.

5.25.2 Conditions

When SYS_CLK is async to CMAC_CLK.

5.25.3 Technical Description

No synchronization exists between the GPADC_RESULT (sys_clk) and the RFMON (cmac_clk). This means that when the GPADC is running on an asynchronous clock (mainly RCHS, but also SYS_CLK = PLL and CMAC_CLK = XTAL32M) intermediate data will be sampled and can be corrupted.

5.25.4 Workaround

Run GPADC and CMAC on synchronous clocks.

 

Is there any example to demonstrate how to capture GPADC data through RFMON interface?

 

Thanks in advance!

Peter

  • Hi Peter, 

    Thanks for your question online. Let me check this and will get back to you.

    Regards, 

    PM_Renesas

  • Hi Peter, 

    My apologies for the delayed response but after checking this internally, please find my comments below : 

    The RFMON is used as an interface to get the IQ data of the RF signal and transfer it into RAM. Some test points are currently used for creating dummy data and are only for debugging the RFMON block. One of these test points is the ADC which is for debugging purposes. 

    Can you kindly explain what you would like to accomplish and share a high-level description of your application?

    Best regards, 

    PM_renesas

  • Hi PM_renesas,

    Thanks for your reply!

    In order to get more better performance, in our DA1469x application, the RFMON is used as an interface to route the IQ data of RF signal and ADC data of GPADC continuously to external FPGA chip which decode the IQ data to BLE packets or analyze the ADC data.

    For example, we can get all alarms from BLE monitor devices (such as patient alarm advertisement) without any loss.

    The inside BLE scanning function can get BLE ADV packets too, but some packets will be lost if the interval between packets is very short or some interference to RF signal (cause CRC error, in fact with more efforts, some packet with CRC error can be corrected)

    The advantage of our solution is higher performance with low cost, low power and very small PCB size.

    Although the hardware and software of our DA1469x application is good enough now, we still hope the DA1470x can achieve more better performance and can be used in future.

    Thank you again!

    Best regards,
    Peter

  • Hi Peter, 

    I have shared this internally and a local FAE will reach out to you directly. 

    Regards, 

    PM_Renesas

  • Hi PM_Renesas,

    Thank you so much for your help!

    Best regards,

    Peter