Maker Pro
Maker Pro

Protocol for Radio Transmission

S

sommes

Jan 1, 1970
0
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.
 
J

John - KD5YI

Jan 1, 1970
0
sommes said:
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.


Read the PDF defining the protocol:

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

Cheers,
John
 
L

Luhan

Jan 1, 1970
0
sommes said:
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 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
 
S

sommes

Jan 1, 1970
0
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
 
T

The Real Andy

Jan 1, 1970
0
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.

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.
What advantage do you intend to gain from the SNAP protocol?


Error detection.
 
M

Meindert Sprang

Jan 1, 1970
0
The Real Andy said:
Error detection.

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
 
T

The Real Andy

Jan 1, 1970
0
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 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 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.

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.
 
M

Meindert Sprang

Jan 1, 1970
0
The Real Andy said:
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.

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?
I agree. The bonus about escaping and data that shares the same start
sequence is that synchronization becomes much faster.

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;
}
 
L

Luhan

Jan 1, 1970
0
sommes said:
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?

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
 

sagala2003

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

sagala2003

Oct 25, 2009
2
Joined
Oct 25, 2009
Messages
2
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
 
Top