Communication Packet protocol

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i know you don't like lazy A** who don't search but i've been searching and getting confused by the minute .

this community has been helpful and i hope you could help me again , so a quick recall .

 

i'm doing a graduation project where there are Multi AVRs (sub nodes) communicating to a Raspberry pi (main node ) you can think of it as a star Topology .

based on alot of discussions i decided to use RS-485 network using MAX488 chip full duplex communication .

this is a home automation IoT project ,for the purpose of the project i made a model " maquette " to simulate home rooms or offices in a company , the same goal  to control light and get temp readings and all these stuff .  

 

pi working as the brain , DB server & web server & Micro controller at the same time , getting requests from a mob App to get readings (temp) or to give an order ( FAN or Light ).

AVRs are the muscles here they execute orders or  send readings  temp .

 

so a moderator here suggested the RS-485 and SNAP protocol , SNAP was simple and easy but there is something not clear here ,

i don't seem to find a clear way or i'm missing something about PACKET error detection and correction .

 

i know that there is checksum or CRC method for error detection , but lets say a packet gest lost or error occurred  during the transmission of the destination address byte . how to detect that and what is the re-transmission protocol here ???

 

also i've come across MODBUS protocol and when i Googled it i found that there are many protocols RTU,ASCII ,etc ? 

 

what i had in mind that whenever a packet is transmitted a timer ticks and wait for an ACK if it doesn't appear within time it gets re-transmitted again .

but i'm afraid of latency so there are to ways i re transmit three times only and if no ack received this means Fault in the bus OR

to continuously re transmit until an ACK  is  received .

 

so if you have in mind a protocol that prevents packet loss & guarantees low latency i'd appreciate it .

 

the protocol will be on both AVR and the PI

 

note that i can finish this project in 3 days but i'm aiming for quality here and the communication process is what i'm building my whole project upon . features come later .

 

thanks for your patience . :) appreciate your help .

 

 

 

 

 

This topic has a solution.
Last Edited: Wed. Dec 21, 2016 - 03:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For low latency you will want to reduce as much packet repeating as possible, as each attempt to timeout/ resend will increase your lag time..... (but you knew that)

So, do some research on "FEC" forward error correction in each of your packets, by increasing the size of your packet, a little with redundant data, that can be used to correct one, or more bit errors)  Then no retry will be needed, and the ack can be sent asap.

S.N.A.P will accommodate a larger payload so no changes are needed to your basic packet functions.  

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i decided to use RS-485 network using MAX488 chip full duplex communication .

RS485 is a half duplex communication mode, RS422 can be full duplex. Star topology and RS485 are not really great companions even though it can be done for your purpose and very carefully in the real world.

 

Freemodbus has example code for many types of processors.

 

Lots of RS485 info here https://www.avrfreaks.net/forum/r...

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hello john , i don't know about the full duplex thing for RS485 , but the chip MAX488 takes both RX & TX simultaneously .

so i'm sure you know how it works  , so i'm connecting the PI TX to all of the AVRs RX  this means the AVR only receive packets from the pi . so this line of communication have no worries one transmitter and the rest are receivers . 

 

what worries me is the other line , All of the AVRs TX connected to the PI RX so there is high chance of data collision or packet loss .

 

i've seen the link u gave me but this is a ready code , no explanation of the protocol or the algorithm , or maybe i didn't search enough .

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All of the AVRs TX connected to the PI RX so there is high chance of data collision or packet loss .

 

Not if your protocol requires the AVRs to be commanded to talk by the main node prior to talking.  

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Normally RS485 is half duplex. The master talks and the slaves listen. The protocol will usually have a means of addressing a slave, so the addressed slave will respond. This avoids collisions. Thus the master normally polls the slaves in sequence on a regular basis. This is the way modbus works as do a number of common protocols. Modbus is a simple protocol that has been around for a long time. You can find the documents at modbus.org. To modbus, the world consists of bits and 16 bit registers. If you can make your data fit this concept , then modbus is a good choice. If you wanted to send strings etc, modbus is probably not for you.

On the Pi side, there are programs like modbus2mqtt or mbusd and plenty of others.

Last Edited: Fri. Dec 16, 2016 - 02:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You might study TCP/IP.

 

If you number each packet, ie add an extra byte or two with a packet number, then ack by number.  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
RS485 is a half duplex communication mode, RS422 can be full duplex.

BY EIA standard RS-485 is Half Duplex, but it also can do Full duplex, multidrop with the right driver IC and software controls.

 

js wrote:
Star topology and RS485 are not really great companions even though it can be done for your purpose and very carefully in the real world.

As Wikipedia says:

Full duplex operation

RS-485, like RS-422, can be made full-duplex by using four wires. Since RS-485 is a multi-point specification, however, this is not necessary in many cases. RS-485 and RS-422 can interoperate with certain restrictions.

Converters between RS-485 and other formats are available to allow a personal computer to communicate with remote devices. By using "Repeaters" and "Multi-Repeaters" very large RS-485 networks can be formed. TSB-89A, The Application Guidelines for TIA/EIA-485-A has one diagram called "Star Configuration. Not recommended." Using an RS-485 "Multi-Repeater" can allow for "Star Configurations" with "Home Runs" (or multi-drop) connections similar to Ethernet Hub/Star implementations (with greater distances). Hub/Star systems (with "Multi-Repeaters") allow for very maintainable systems, without violating any of the RS-485 specifications. Repeaters can also be used to extend the distance or number of nodes on a network.

Your Application May Vary

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TCP does it's retransmission end-to-end across an internet, so it's probably more complex than you need for point-to-point links in a star topology.

I suggest you look at "LAPB"; the link level protocol for X.25 networks.  It has a simple scheme for doing retransmission (and also flow control) closer to the bottom level of the network stack (you should also review you "ISO network layers"), and is probably easily adaptable to RS485 as the physical layer.

 

unfortunately, I'm having trouble finding a web page that describes it very well, but it should be pretty well documented in networking books.)

Here are a couple that are ok:

http://www.farsite.com/X.25/X.25...

http://people.sabanciuniv.edu/le...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."