This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Data Transmission with CC2538

Other Parts Discussed in Thread: CC2538, Z-STACK

Hello,

I am trying to use a CC2538 to transmit data from a MEMs Sensor to a CC2538EM which sends the data via the USB in the SmartRf06 Board to a PC. I have been trying to modify the GenericApp found in Z-stack Mesh 1.0.0, to send my data instead of the example's "Hello World", but I am having two issues. First, I modified the send message function to send sensor data as such: 

static void GenericApp_SendTheMessage( void )
{
InitGyro(); //initalize gryo for use
int8_t data = DataAcq(); //getting data from sensor

//request to send data
if ( AF_DataRequest( &GenericApp_DstAddr, &GenericApp_epDesc,
GENERICAPP_CLUSTERID,
(byte) data +1,
(byte *)&data, 
&GenericApp_TransID,
AF_DISCV_ROUTE, AF_DEFAULT_RADIUS ) == afStatus_SUCCESS )
{
// Successfully requested to be sent.
}
else
{
// Error occurred in request to send.
}
}

But all I get is jibberish on the receiving end. Does the data have to be characters like the original "Hello World"? Or is there maybe a better way to do this? I tried looking in the Temperature Sensor example in Z-stack Home, but I couldn't find where the sent any data.

Secondly, when I use the unedited code, I cannot get the data to properly show up on my terminal. Instead of "Hello World Rcvd: x" is usually comes through as "Helo Wo HHello Worldo Rcvd:x". I tried messing around with the parity, stop, etc. in the terminal but nothing would solve it. I have tried using the HalUARTWrite() function and the UARTprintf() function from the CC2538 firmware in the GenericApp_MessageMSGCB function but neither have worked so far. Again maybe there is a better way to do this?

  • Hi,
    you are getting gibberish because you are not setting the right packet size for the message you are sending out.
    The 4th parameter is the size of the payload you would like to transfer, and since the data is only one byte, you should hard code it to 1.
    Instead, you are telling AF_DataRequest to send a number of bytes equal to the value in the 'data' variable plus one. Consequently, all the bytes in memory after the 'data' variable get transmitted, up to a number which is 'data'+1.
    If really you are grabbing data from the gyro and it's only 1 byte, set it to 1.
    Please also note I don't think youbshould re-initialize the gyro every time you want to send the packet out. Just initialize it once and when you want to report data over the air, just acquire the data using AF_DataRequest API.
    Please also make sure that in your UART setting on your terminal you have activated flow control. The UART driver on the CC2538 activates it and It seems you are missing few characters.

    Thanks,
    TheDarkSide
  • Hi,

    Thanks for your help,

    In my attempts to solve this, I have realized that the output that is going to the computer is actually using the HalLcdWriteString function which doesn't seem right, and it only writes characters which is annoying since it changes my data to its ASCII character. Could this be achieved with HalUARTWrite(), and if so do you have an example implementation because I haven't had any luck in getting it to output to the computer (throught the SmartRF06 USB)?

    Also, when I used the Z-Tool with CTS/RTS Handshake enabled the output is good: "<RX>10:24:27.26 COM11 DEBUG_STRING (0x4880)
    DebugString: Hello World (0x48, 0x65, 0x6C, 0x6C, 0x6F, 0x20, 0x57, 0x6F, 0x72, 0x6C, 0x64)" but when I use other terminals such as TeraTerm and Realterm, even with flow control enabled, there are still some weird characters. Maybe the 0x4880 that can be seen in the Z-Tool output is messing it up? How could I get rid of it, if it is? Maybe its related to using the HalLcdWriteString function?

    Thanks,

    Brendon
  • Hi,

    The reason why you see extra characters when you use a terminal like teraTerm is because the CC2538 sends some extra bytes to specify the start of the frame, the type of message that it is and a check to make sure the frame was not corrupted. also if you are planning on using a terminal you will still need to convert the integer values from your sensor to ASCII characters to be able to properly read them in the terminal. To convert the values from int to ASCII you can use the "_itoa(uint16 num, uint8 *buf, uint8 radix)" function in OnBoard.c.
  • DebugString is generated by "debug_str( (uint8*)buf )" in API HalLcdWriteString(). You can disable it to not show this message.