Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Radio Packet Standard Protocols?

Status
Not open for further replies.

beano040461

Junior Member level 2
Joined
Oct 29, 2001
Messages
21
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
252
We have developed a remote radio application having up to 16 remote units and one master unit based on the atmel TRX01. can any one tell me if there is any standard protocols used for transmitting data between stations.
we would prefferably like the radio to act simular to a 485 serial system. any information would be greatly appreciated
 

Thanks for the info found some stuff on ax25
 

ax25 is quite a complex protocol. You might want to look for something simpler depending on your application. The only real differences when comparing radio to RS485 is that you need a preamble before the data, the chanell is much noisier and depending on your hardware you have to balance data for not having any DC offsets using manchester encoding or something similar. Do a search for the SNAP protocol, it seems to be a nice candidate for Radio tx/rx .

Best regards,
Alexg
 

thanks alexg did search and from some docs
do you know where i can find some c source examples? as this looks like it would do the job.
 

SNAP is a good protocol for multidrop applications, but for radio AX-25 is the best.

You can see a complete AX-25 stack with full source code in linux ready to make tests.

Get any linux, install kernel sources and use ax-25 kernel modules... 100% ready to work.
 

You can take a look at ww#.radiometrix.co.uk
to enhance your knowledge,Also search the google for Amature Radio there also Manchester .
I am planing to do the project with Radio but feel it is simple HOW About using TCP/IP Protocols ????
 

Hmmm TCP/IP for 16 stations can be rather time consuming is that it ensure end-to-end reliability transfer due to routers in between 2 terminals. That's why it require a IP layer to allow routing through different network and TCP layer to ensure reliability and flow control. Kinda tiem consuming to implement these 2 layers assuming your physiacl + data link layer (HDLC) is done.

As for your case, since there's a master to regulate the flow, the contention will be minimal. Maybe you can take a look at a simple but not effective protocol, "Aloha".

However, let say your bandwidth is 1Mbps, it can only utilize up to a maximum of 18.4%. If you use Slotted Aloha, the effective bandwidth can be twice as much as pure aloha of 36.8%. However, slotted require synchronization.

Hope that helps !

Best Regards
 

for all Packett radio look at :


https://www.F6FBB.org Webmaster : Jean-Paul ROUBELAT - F6FBB

you can find also with google with topic : WA8DED or Packett Radio , many , many topics

CP
 

u can find lot of infos at:
TAPR

73

cancel
 

lets cut the crap about packet

i personaly thought it was a shit waY TO TRANSFER DATA
lets face it
radio transfer realy means
ye ham data radio transfer when there is very little signal
so the error correction is 3/4 of the packet lenght

to those who just want to know what packet is
its simple

its like the way a mouse talks to the computer {with some added handshakes but exactly the same}

so has and can have no real content in each packet
amtor is better for week signals ssb
packet for medium and strong fm signals


THE BEST WAY I THOUGHT OF {ALTHOUGH NEVER got around to }
was to use multiple dtmf
rs232

for multiple channels

the source code would be unique
and very easy to write

and you can easily build in error checking

although this is no excuse for not making as good a link as possible



i used packet for many years
its reliable
but as pointed out about

far overcomplex for the job you need to do

hence dtmf rs232 would be the better choice
never tryed snap myself
so im off to hunt for some docs
{thanks}




<font size=-1>[ This Message was edited by: SIMBOX on 2001-11-08 15:00 ]</font>
 

having just come back from the lpra show in london it seems as though SNAP will do our application.It is simple and the packet size is small keeping the overheads low which i feel would not be the case for TCP/IP over the radio. However what did come out of the conferance i attended on monday is that what ever protocol i implement a system to detect errors needs to be robust as the european ISM bands at 868Mhz are now so crowded.
Thanks to every body for the feedback
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top