Protocol for Radio Transmission

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

formatting link
for the protocol.

I read the example which is turning LED on and off.

formatting link

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.

Reply to
sommes
Loading thread data ...

Read the PDF defining the protocol:

formatting link

Cheers, John

Reply to
John - KD5YI

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

Reply to
Luhan

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

Reply to
sommes

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.

Reply to
The Real Andy

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

Reply to
Meindert Sprang

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.

Reply to
The Real Andy

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 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;ilength;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; }
Reply to
Meindert Sprang

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

Reply to
Luhan

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.