Sending CTRL-Z over UART

[frijj2k]

Hi, I have a SIM800L GSM/GPRS module that I can successfully talk to via the UART on the nRF51.

I can tell it to dial numbers etc and that all works fine.

My problem is that to send an SMS, the final character (after inputting the message) needs to be a CTRL-Z sequence. (Dec 26 - Hex 1A)

If I enter the AT commands via a terminal and an FTDI cable, everything is working. But when I try sending the sequence from the nRF51's UART, everything 'looks' good apart from the CTRL-Z character which shows itself as a '.' on my terminal and the SIM800L module ignores it.

I have tried placing the CTRL-Z sequence within my string via sprintf and also I have tried manually sending it at the very end directly via app_uart_put as follows...

err_code = app_uart_put((uint8_t)0x1A);  // CTRL-Z

But this doesn't work.

What am I doing wrong?

Thanks in advance!

[Andrew]

Just looking at the command listing for that module, are you sure you are in text mode and not PDU mode?

Also, looks like all AT commands need to terminate with (0x0D), so I'm assuming the last bytes in an SMS command would be {0x1A, 0x0D}

I'm no expert, but that is what I see after spending 5 minutes with the AT command sheet that seem like red flags.

[frijj2k]

Thanks for your quick reply Andrew... Yes I am using it in text mode ( AT+CMGF=1 )... Here's what I am sending...

AT
AT+CMGF=1
AT+CMGS="[phone]"
This is a test message from SIM800L.

Notice the full stop ( . ) added to the end in the terminal (Where CTRL-Z is sent)... Maybe this is just CoolTerm (OSX) showing this instead of the control character although it doesn't do this when I type it direct into the terminal to the SIM800L via an FTDI cable... (That works just fine).

[frijj2k]

Some more information (code)...

#define CTRL_Z 26

void uart_putstring(const uint8_t * str) {
    uint32_t err_code
    uint8_t len = strlen((char *) str);
    for (uint8_t i = 0; i < len; i++) {
        err_code = app_uart_put(str[i]);
        APP_ERROR_CHECK(err_code);
    }
}

void dial_number(const uint8_t * number) {
    char cmd_string[255];
    cmd_string[0] = '\0';
    sprintf(cmd_string, "ATD%s;\r", number);    
    uart_putstring((uint8_t*)cmd_string);
}

void send_sms(const uint8_t * number, const uint8_t * message) {
    uint32_t err_code;
    char cmd_string[255];
    char msg_string[255];
    cmd_string[0] = '\0';
    msg_string[0] = '\0';
    
    //sprintf(cmd_string, "AT+CMGS=\"%s\"\r%s\032\r", number, message);   // \032 = CTRL-Z
    //sprintf(cmd_string, "AT+CMGS=\"%s\"\r%s%c", number, message, CTRL_Z);
    //sprintf(cmd_string, "AT+CMGS=\"%s\"\r%s", number, message);
    
    sprintf(cmd_string, "AT+CMGS=\"%s\"\r", number);
    sprintf(msg_string, "%s", message);
    
    uart_putstring((uint8_t*)"AT+CMGF=1\r");    // Set TEXT mode cmd
    uart_putstring((uint8_t*)cmd_string);       // Send to number cmd
    uart_putstring((uint8_t*)msg_string);       // Send actual message
    err_code = app_uart_put((uint8_t)0x1A);     // Send CTRL-Z to finish	    
    APP_ERROR_CHECK(err_code);
}

// USAGE...
dial_number((uint8_t *)"07123456789");	// This works!
send_sms((uint8_t *)"[phone]", (uint8_t *)"This is a test message from SIM800L");	// This sends all commands but final CTRL-Z isn't received correctly by modem

Please note, the original code only had cmd_string (no msg_string) but I split it up and added fixed delays to see if timing was a problem but that had no effect either...

Hopefully somebody can shed some light on this... (As you can see... I have tried many ways to send that CTRL-Z, all of which have not worked) Thanks!

[Andrew]

One thing with CoolTerm, you should be able to see the actual hex values of the ascii characters that are coming back. In the view menu, switch it to hex and see what the real value of that (.) is. This should also verify that the header command and tail of the command is terminated correctly. asciitable.com is a good place to have bookmarked for all of the different ascii commands and their hex / decimal values.

[frijj2k]

Good thinking... I checked in the Hex view and 0x1A IS getting sent so the problem is elsewhere.... My thinking is now that I need to wait for the success/error messages before sending the actual text message body... Simply adding an nrf_delay_ms (YUK!) is not enough as the data is getting buffered and then sent in one burst...

Just writing properly some code to handle the responses and will let you know what happens...

Thanks!