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

Delay in 1st byte of sent UART message

I am currently trying to communicate with a GPS module using the UART on an nRF51422 (using the Dynastream N548M5CB module). I am using SDK v9.0.0 and the FIFO version of the UART module, with only software flow control.

I am sending UART messages to the GPS in order to control which NMEA messages it sends; however, the GPS module does not respond to the commands I send. I have tried viewing the serial message sent with both an oscilloscope and a serial monitor on my PC (by connecting the UART to a USB->UART adapter rather than the GPS) and have verified that the correct message is being sent, but that there is a significant delay (~500ms) between the first byte sent and all successive bytes.

I think that this delay is the reason why the GPS does not acknowledge the command; I have previously communicated with this GPS using an Arduino library. I have also simulated this delay using an Arduino, and also gotten the result of the command not being acknowledged.

Why is this delay occurring between the first byte and remaining bytes, and what can I do to fix it?

Here is the code that I am using to send a command to the GPS over the UART:

static void uart_init(void)
{
    uint32_t err_code;

    const app_uart_comm_params_t comm_params =
       {
           RX_PIN_NUMBER,
           TX_PIN_NUMBER,
           RTS_PIN_NUMBER,
           CTS_PIN_NUMBER,
           APP_UART_FLOW_CONTROL_DISABLED,
           false,
           UART_BAUDRATE_BAUDRATE_Baud9600
       };

    APP_UART_FIFO_INIT(&comm_params,
                          UART_RX_BUF_SIZE,
                          UART_TX_BUF_SIZE,
                          uart_event_handle,
                          APP_IRQ_PRIORITY_LOW,
                          err_code);

    APP_ERROR_CHECK(err_code);

    app_trace_init();
}



void println(char * data, uint32_t length) 
{
    uint32_t i;
    for (i = 0; i < length; i++) {
        while(app_uart_put(data[i]) != NRF_SUCCESS);
    }
    app_uart_put('\r'); app_uart_put('\n');
}


char * PMTK_SET_NMEA_UPDATE_200_MILLIHERTZ = "$PMTK220,5000*1B";

void gps_init(void) 
{
    nrf_gpio_cfg_output(GPS_ENABLE_PIN);
    nrf_gpio_pin_set(GPS_ENABLE_PIN);
    println(PMTK_SET_NMEA_UPDATE_200_MILLIHERTZ,  strlen(PMTK_SET_NMEA_UPDATE_200_MILLIHERTZ));
}
Parents
  • Thanks for the reply, Martin. The device I'm using is also serving as a BLE client; the gps_init function took place just before I initialized the BLE stack, called device_manager_init, db_discovery_init, and scan_start. I think one of these had something to do with the byte being delayed.

    Here is my original code:

    int main(void)
    {
    bool erase_bonds;
    
    // Initialize.
    APP_TIMER_INIT(APP_TIMER_PRESCALER, APP_TIMER_MAX_TIMERS, APP_TIMER_OP_QUEUE_SIZE, NULL);
    
    uart_init();
    gps_init();
    buttons_leds_init(&erase_bonds);
    
    ble_stack_init();
    device_manager_init(erase_bonds);
    db_discovery_init();
    bas_c_init();
    
    scan_start();
    for (;; )
    {
        power_manage();
    }
    }
    

    Moving the uart_init and gps_init to after all of the bluetooth initialization functions, as well as scan_start, seemed to resolve my issue.

Reply
  • Thanks for the reply, Martin. The device I'm using is also serving as a BLE client; the gps_init function took place just before I initialized the BLE stack, called device_manager_init, db_discovery_init, and scan_start. I think one of these had something to do with the byte being delayed.

    Here is my original code:

    int main(void)
    {
    bool erase_bonds;
    
    // Initialize.
    APP_TIMER_INIT(APP_TIMER_PRESCALER, APP_TIMER_MAX_TIMERS, APP_TIMER_OP_QUEUE_SIZE, NULL);
    
    uart_init();
    gps_init();
    buttons_leds_init(&erase_bonds);
    
    ble_stack_init();
    device_manager_init(erase_bonds);
    db_discovery_init();
    bas_c_init();
    
    scan_start();
    for (;; )
    {
        power_manage();
    }
    }
    

    Moving the uart_init and gps_init to after all of the bluetooth initialization functions, as well as scan_start, seemed to resolve my issue.

Children
No Data
Related