Radar chip with other MCUs via SPI

Discussion in 'X2 & X4 SoC' started by Sergi, May 23, 2018.

  1. Sergi

    Sergi New Member

    Hi,

    Once I have tested correctly that for example both XEP_example.py and XEP_plot_record_playback.py works OK, I want to connect only the radar with another MCUs rather than with Atmel, via SPI.
    Modifying a bit XEP_example.py, I have an output like the log file attached:

    upload_2018-5-23_16-7-10.png

    1. What is the dispatching packet?

    I have already another MCU board with an available SPI port , and I just want to replicate the config done on XEP_example.py in order to get data from radar, the same as:

    upload_2018-5-23_16-12-29.png

    On my system, I attached you a picture from the oscilloscope, where you could see the SPI signals (CLK, MISO, MOSI and CS respectively), where after sending correctly on the MOSI port, with the CLK signal right the same data as in the XEP_example.py->ping command, nothing happens on the MISO port, no answer from Xethru radar. CS is on low level to select the radar chip and begin SPI communication.

    We are using SPI frecuency around 500kHz, and we don´t know if anything else must be set before communicating at SPI low level.
    upload_2018-5-23_16-22-59.png

    2. How to get answer by SPI from the radar chip?

    3. How to decode the radar frame received to get distance?
    upload_2018-5-23_16-27-41.png


    Kind regards,
    Sergi.
     

    Attached Files:

  2. Charlie Shao

    Charlie Shao Moderator Staff Member

    Hi Sergi,
    1. The dispatching packet can be interpreted from the serial protocol used by XeThru sensor and host device. The serial protocol is called Module Communication Protocol (MCP), you can find its document from here: https://www.xethru.com/community/resources/xethru-module-communication-protocol.130/

    2. The X4M03 is composed of X4M05 and MCU board connected by SPI. There is a firmware built from open source XEP (XeThru Embedded Platform) running on MCU board. If you want to replace with your own MCU, you have to transplant XEP to your customized MCU at first. XEP initializes X4 chip and handles communications with both X4 chip and host. There is one example using Raspberry Pi to configure X4M05 through SPI: https://xethru.box.com/s/pzr6ojx11hajz21s57jhuthfhnaaoo18

    3. X4M03 with XEP only support only raw radar data output. In order to get the distance ( distance of people in detection area?), developer has to implement their own algorithm. There is a distance demo can be found from here: https://www.xethru.com/community/resources/xep-x4-distance-demo.89/
    Or you can choose turn-key sensor like X4200, X4M300.

    Charlie
     
  3. Sergi

    Sergi New Member

    Hi Charlie,

    We have been reading all the documentation and the example using Raspberry Pi to configure X4M05 through SPI, but
    as we don´t have answer from the MISO line, we have still some doubts on how to integrate the driver:

    1.- Is it a must to load a previous config to the X4 like "8051_firmware.h" as on the example using Raspberry Pi, in order to be able to get answers from SPI MISO port?

    2.


    2.- Reading the " Protocol Communication" the workflow is described in these steps:

    Set Module to stop mode

    Load profile

    Load parameters (detection zone, sensitivity, noise map, led, output, etc.)

    Run profile

    Get message

    Is it necessary to set the module to stop mode at the beginning to get SPI communication available?

    Kind regards,
    Sergi.
     

    Attached Files:

  4. Charlie Shao

    Charlie Shao Moderator Staff Member

    Hi Sergi,
    For your questions:
    1. Yes, the 8051 firmware must be loaded to X4 chip at first. It is the software running on X4 internal CUP core.
    2. No, this part is the flow to configure XeThru sensors like X4M200, X4M300, they have profile or application messages that developed based on radar raw data. If you use SPI communication, you will only get radar raw data from X4 chip to host MCU.
     
  5. Sergi

    Sergi New Member

    Thank you Charlie for your answer.

    To load the 8051 firmware at first to X4 chip, which is the right order. I mean:

    Begin SPI
    Put the line X4_EN High level
    Put the line X4_CS Low level
    Begin transfer: Data_8051_onboard
    Put the line X4_CS High level
    Put the line X4_EN Low level

    After that, is it necessary a reset or other any command in order to get directly communication with the X4 via SPI?

    Thanks.

    Kind regards,
    Sergi.
     
  6. Charlie Shao

    Charlie Shao Moderator Staff Member

    Hi Sergi,
    It is hard to simply say the order of configuring process. I believe every step is necessary on the x4driver_init function.
    The correct way to transplant XEP to your host MCU is keeping the original XEP code as much as possible and just replace the SPI driver part to be compatible with your hardware. I think it is not necessary to rewrite the XEP codes, or it will take much more effort.
     
  7. Sergi

    Sergi New Member

    Hi Charlie,

    Finally it seems that we have integrated correctly the x4driver_init function, so we are able to collect radar raw data, as attached.
    upload_2018-6-8_14-24-52.png

    Now we begin the next step, that consist in how to implement our algorithm to translate it to distance. I have been reading the X4XEPDistancedemo.c, where this function:

    int x4xepdistancedemo_frame_processing(XepHandle_t* xep, uint32_t frameCounter, float *frame, uint32_t frameLength)

    1. Output from radar is configured to be downconverted, i.e. baseband IQ data.
    2. Convert baseband IQ to amplitude
    3. Calculate distance using start value and bin length information

    Is there any other information available to code this?

    Thanks.

    Kind regards.
     
  8. Charlie Shao

    Charlie Shao Moderator Staff Member

    Hi Sergi,

    Glad to hear your good news!

    I can provide you more information about the third step, which is the distance algorithm implementation.
    The purpose of this algorithm is to detect the moving target and output presence inside detection zone at the same time.

    It create an adaptive_cluttermap at initialization or when frameLength change, which means user changes detection zone.
    Code:
        if (!adaptive_cluttermap || (last_frame_length != frameLength))
        {
            last_frame_length = frameLength;
            if (!adaptive_cluttermap) xtmemory_free_slow(adaptive_cluttermap);
            adaptive_cluttermap = xtmemory_malloc_slow(bin_count * sizeof(float));
    
            // New cluttermap, start by copying current frame.
            memcpy(adaptive_cluttermap, frame_amplitude, bin_count*sizeof(float));
        }
    Update adaptive cluttermap and calculate result.
    Code:
        for (int i=0; i<bin_count; i++)
        {
            adaptive_cluttermap[i] = adaptive_cluttermap[i] * (1-adaptive_factor) + frame_amplitude[i] * adaptive_factor;
            frame_amplitude_filtered[i] = frame_amplitude[i] - adaptive_cluttermap[i];
        }
    Locate the position of largest moving target
    Code:
        uint32_t index;
        float max;
        arm_max_f32(frame_amplitude_filtered, bin_count, &max, &index);
    Calculate filtered distance
    Code:
         if (distance_filtered < 0) distance_filtered = distance;
            distance_filtered = distance * distance_filter_factor + distance_filtered * (1 - distance_filter_factor);
    Send presence and distance information to host.
    Code:
            if (distance_filtered < 0)
                dispatch_message_hostcom_send_data_string(xep->dispatch, 0, 0, "No presence");
            else
                dispatch_message_hostcom_send_data_string(xep->dispatch, 0, 0, "Presence at %f meters (value: %f)", distance_filtered, max);