| ??? 06/20/06 17:38 Read: times |
#118631 - One way protocol Responding to: ???'s previous message |
I guess it's somewhat personal choice, but if your sender must transmit additional copies of the data in order to "guarantee" delivery, I'm not sure that's cheaper energy-wise than listening for an ACK. However, many types of data are "streaming" in that it's not necessary to receive them all (things such as temperature or audio that come in a sequence -- if you miss a few bytes, who cares?). If you really need to rx them all, I think 2-way is preferrred.
Also this all depends on if you have a dedicated radio frequency/channel or if there is some agility there. Anyway, it seems you have your buffer situation sorted out... GB |
| Topic | Author | Date |
| Buffer management optimalization | 01/01/70 00:00 | |
| Simple things first ... | 01/01/70 00:00 | |
| You can use circular buffer | 01/01/70 00:00 | |
| Fragmentation problem... | 01/01/70 00:00 | |
| all methods have some problems | 01/01/70 00:00 | |
| Start of package or End of package | 01/01/70 00:00 | |
| Packages explanation | 01/01/70 00:00 | |
| Individual buffers | 01/01/70 00:00 | |
| Good Idea | 01/01/70 00:00 | |
| New packages | 01/01/70 00:00 | |
| hash table unefective | 01/01/70 00:00 | |
| why keep that many | 01/01/70 00:00 | |
| Reason of 5 or more buffer | 01/01/70 00:00 | |
| Protocol specifics | 01/01/70 00:00 | |
| One way protocol | 01/01/70 00:00 | |
| One way protocol | 01/01/70 00:00 | |
| never | 01/01/70 00:00 | |
| Definition of need | 01/01/70 00:00 | |
| Grant, I agree with what you post re thi | 01/01/70 00:00 | |
| Simply reason why one way transmission | 01/01/70 00:00 | |
then why not just do it the easy way | 01/01/70 00:00 |