Connect with us

Protocol for Radio Transmission

Discussion in 'Electronic Design' started by sommes, May 10, 2006.

Scroll to continue with content
  1. sommes

    sommes Guest

    I require to send 10bit data from ADC (Atmel AVR 8535) to other Atmel AVR
    8535 via radio transmission.

    I decided to use S.N.A.P (Scaleable Node Address Protocol) from HTH
    (http://www.hth.com/snap) for the protocol.

    I read the example which is turning LED on and off.
    (http://www.hth.com/filelibrary/snap/usrcode/SNAP-IO.ZIP)

    However I just found this is only for receiver part as the program is only
    wait for the incoming packege byte.

    I would like to ask, What I need to set in the transmitter to send out
    proper packege?

    Could you guy please give me some simple idea about serial protocol?

    Thank you very much

    Please let me know if more infomation are desired.
     
  2. John - KD5YI

    John - KD5YI Guest


    Read the PDF defining the protocol:

    http://www.hth.com/filelibrary/pdffiles/snap.pdf

    Cheers,
    John
     
  3. Luhan

    Luhan Guest

    I have found it best in almost all cases to send data values in ascii
    decimal terminated with a CR character (13). You can monitor this
    with any termial program to confirm that the data is tansmitted
    properly.

    What advantage do you intend to gain from the SNAP protocol?

    Luhan
     
  4. sommes

    sommes Guest

    Thank Luhan,

    I just found quite a lot of infomation about SNAP protocol, I didn't know
    that much about it.

    Could you please give me some more infomation about Wireless Protocol?

    I knew manchester coding would be sutiable for my task, however I couldn't
    find example in Bascom-AVR on the web.

    Cheers
     
  5. THat is ok for small time work and debug outputs, but unfortunately it
    does not work well when you want reliable error free comms, unless the
    ascii you are sending contains, or is layered on some form of error
    detection.

    Error detection.
     
  6. Question: How are the frames delimited in SNAP? What I mean is: when I start
    listening to an ongoing SNAP transmission, how do I know when a frame is
    finished and when a new one begins? The sync byte can also be present in the
    data stream and there is nothing defined in terms of escape characters or
    guard times around frames. So I have now way of knowing when if a received
    sync byte is really a sync byte or just a part of the transmitted payload.
    Considering all this, I think SNAP sucks.

    I would go for a simple SLIP-like protocol where start/end bytes are defined
    and where similar bytes in the payload have to be escaped.

    Meindert
     
  7. I don't know, I have never looked at the SNAP protocol. I assume that
    it has a len field, and based on that you can find the crc and
    subsequently validate.
    I agree. The bonus about escaping and data that shares the same start
    sequence is that synchronization becomes much faster.

    Most protocols I have ever designed have been loosley based on HDLC /
    DDCMP. Thats only because it is what I have used and grown used too.
     
  8. It does have a length field, but if I missed that, and "drop in" in the
    middle of a packet, how do I know it's finished?
    Indeed. The code for this is very straightforward. Heck, I'll include it
    here and now. This is C code written on a Philips XA, so a few bits a
    registers must be adapted to the OP's processor. This is the low level link
    protocol which provides framing of a binary packet. Add your flow control
    and CRC to suit your needs.
    Below is the complete description and source code.

    Meindert
    -------------------------------------
    Link protocol
    The reader uses a link protocol to communicate with the host. This link
    protocol provides a transparant 8 bit serial link for binary data.
    The link protocol defines frames of a fixed or variable length which are
    framed by START and END markers.

    The link protocol is derived from the SLIP protocol according to RFC-1055
    and slightly modified. Three special link control bytes are defined to
    uniquely frame a packet of data:

    ESC (0xFF): This byte is inserted in the serial stream immediately
    before a data byte identical to one of the three link control bytes.
    START (0xFE): This byte marks the start of a frame.
    END (0xFD): This byte marks the end of a frame.

    The link protocol only provides framing of binary data. There is no error
    handling or checksum. Both parties shall ignore a frame in case of a timeout
    between bytes or START and END.

    Implications for the transmitter
    The choice of the values of the control bytes is such that no testing is
    required on the presence of all three if them in the datastream. A simple
    test whether a byte is greater then or equal to 0xFD is sufficient. When the
    byte to be transmitted is lower, it can be transmitted immediately. When
    equal or greater, an ESC is inserted in the datastream.

    Implications for the receiver
    When and ESC is received, the next byte will always be regarded as data and
    not as link control byte. When a START or END is received without an ESC,
    they will be regarded as start or end markers. The advantage of having
    separate START and END markers is that on reception of a START, all
    previously received bytes can be regarded as noise and therefore discarded.
    Unlike SLIP, which uses only one marker for both the start and end of a
    frame, in which case the receiver always has to check the validity of the
    previously received bytes.


    Code example (this is production code, which has proved to work)
    Reception is done in rx_int() and send() and recv() are called to send and
    receive frames.

    /***************************************************************************
    **/
    /*
    */
    /* Filename : serial.h
    */
    /* Revision : 1.0
    */
    /* Project : xxxxxxxxxxxxxxxxxxx
    */
    /* Description: Header file for serial communication driver
    */
    /*
    */
    /* Author : M.H. Sprang, CustomWare
    */
    /*
    */
    /* History:
    */
    /* Rev. Date Description
    */
    /* -------------------------------------------------------------------------
    */
    /* 0.0 23-05-00 Initial version
    */
    /* 1.0 11-07-00 First release
    */
    /*
    */
    /***************************************************************************
    **/

    #ifndef __SERIAL_H
    #define __SERIAL_H

    #include "types.h"

    #define PACKET_SIZE 387

    // special protocol characters
    #define C_ESC 0xFF
    #define C_START 0xFE
    #define C_END 0xFD

    typedef enum dummy {S_IDLE,S_RCV,S_ESC,S_RDY} RX_STATE;

    typedef struct
    {
    uint length;
    char data[PACKET_SIZE];
    } PACKET;

    void send(PACKET *packet);
    PACKET *recv(void);

    #endif


    /***************************************************************************
    **/
    /*
    */
    /* Filename : serial.c
    */
    /* Revision : 1.0
    */
    /* Project : xxxxxxxxxxxxxxxxxxxx
    */
    /* Description: Serial communication driver
    */
    /*
    */
    /* Author : M.H. Sprang, CustomWare
    */
    /*
    */
    /* History:
    */
    /* Rev. Date Description
    */
    /* -------------------------------------------------------------------------
    */
    /* 0.0 23-05-00 Initial version
    */
    /* 1.0 11-07-00 First release
    */
    /*
    */
    /***************************************************************************
    **/

    #include "serial.h"

    PACKET packet;
    char * _near rx_ptr;
    uint rx_cntr;
    char rx_sum;
    RX_STATE rx_state;


    /***************************************************************************
    **/
    /*
    */
    /* init_comm(): Initialise serial driver to desired speed.
    */
    /*
    */
    /* The baudrate generator is T2, which is initialised in the
    */
    /* timer module.
    */
    /*
    */
    /***************************************************************************
    **/
    void init_comm(void)
    {
    // serial port configuration
    S0STAT = 0; // clear serial status, no interrupts on events
    S0CON = 0;
    SM1_0 = 1; // set 8 bit UART with variable speed
    REN_0 = 1; // enable reception
    TI_0 = 1; // 'enable' transmission

    rx_state = S_IDLE;

    ERI0 = 1; // enable receive interrupts
    }



    /***************************************************************************
    **/
    /*
    */
    /* rx_int(): Receive interrupt handler.
    */
    /*
    */
    /***************************************************************************
    **/
    _interrupt (VEC_RX0) _using(0x8000 | (P_RI0 << 8))
    void rx_int(void)
    {
    char c;

    RI_0 = 0;
    c = S0BUF;
    switch (rx_state)
    {
    case S_IDLE:
    if (c == C_START)
    {
    rx_ptr = packet.data;
    rx_cntr = 0;
    rx_sum = 0;
    rx_state = S_RCV;
    }
    break;

    case S_RCV:
    case S_ESC:
    if ((c < C_END) || (rx_state == S_ESC))
    {
    if (rx_cntr < PACKET_SIZE)
    {
    *rx_ptr++ = c;
    rx_sum += c;
    rx_cntr++;
    }
    rx_state = S_RCV;
    }
    else
    {
    switch (c)
    {
    case C_ESC:
    rx_state = S_ESC;
    break;

    case C_START:
    rx_ptr = packet.data;
    rx_cntr = 0;
    rx_sum = 0;
    rx_state = S_RCV;
    break;

    case C_END:
    if ((rx_cntr > 0) && (rx_sum == 0))
    {
    packet.length = rx_cntr - 1;
    rx_state = S_RDY;
    }
    else
    rx_state = S_IDLE;
    break;
    }
    }
    break;
    }
    }


    /***************************************************************************
    **/
    /*
    */
    /* send(): Send a packet.
    */
    /* In: pointer to a packet structure
    */
    /*
    */
    /***************************************************************************
    **/
    void send(PACKET *packet)
    {
    char *c;
    uint i;

    putchar(C_START);
    c = packet->data;
    for (i=0;i<packet->length;i++)
    {
    if (*c >= C_END) putchar(C_ESC);
    putchar(*c++);
    }
    putchar(C_END);
    }



    /***************************************************************************
    **/
    /*
    */
    /* recv(): Check if a packet is received. Returns a pointer to a packet when
    */
    /* data is received, nil if not.
    */
    /*
    */
    /***************************************************************************
    **/
    PACKET *recv(void)
    {
    if (rx_state == S_RDY)
    {
    rx_state = S_IDLE;
    return &packet;
    }
    else
    return 0;
    }
     
  9. Luhan

    Luhan Guest

    First of all, SNAP is a network protocol, what you seem to be asking
    for is a point to point protocol.

    For the actual coding level, I like to use plain old asynchonous serial
    using UARTS already in most micros today. Then it just depends on how
    important it is to detect errors in transmission. The ascii/decimal is
    fine if occasional errors going undetected are not an issure in your
    specific use.

    Since you are specifying only one-way transmission, error correction is
    cumbersome, but error detection is quite easy. Send your 10 bit number
    as decimal ascii, send a comma, then invert all of the original 10 bits
    and send that as decimal ascii with a CR character to end it.

    This slows down the theoretical data transmission rate by a factor of 4
    or 5. If that is not an issue, its a clean and easy way to send the
    data.

    Luhan
     
  10. sagala2003

    sagala2003

    2
    0
    Oct 25, 2009
    Hi Lunan,
    I try to write your code in ATMEGA8535. Could you translate them to AVR Codevision? I'm newbie for this.
    Thnks
     
  11. sagala2003

    sagala2003

    2
    0
    Oct 25, 2009
    Hi Lunan,
    I try to write your code in ATMEGA8535. Could you translate them to AVR Codevision? I'm newbie for this.
    Thnks

    Regards,
    Faisal
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-