Aktionen
  Retransmits » Historie » Revision 3
      « Zurück |
    Revision 3/20
      (diff)
      | Weiter »
    
    Maximilian Seesslen, 02.04.2025 11:39 
    
    
Modes¶
Stubborn¶
- Send CAN messages as Broadcast messages; fire and forget
 - Good enough for sensor values
 - Robust code, not much that can fail
 - Not good enough for e.g. Flashing firmware on remote device or even scanning nodes.
 
Guaranteed¶
- Each package need an acknowledge
 - Retransmitts are send if acknowledge is missing
 - Heavy traffic if nodes are blocking each other.
 - Complex code, but ok
 
Retransmits¶
- In starting phase there is an auto-tune which requires traffic
 - There are at least some CRC errors
 
Send package¶
- ringTransmitted.canPush()?
 - store essage there
 - Send it via RFM69
 
Receive package¶
- If type is "Acknowledge" 
	
- find corresponding message
 - mark slot as acked/nacked
 
 
- If regular message/resend
	
- If resend: is the package older than the last?, drop it
 - is it not last+1? send NACK via RFM69
 - fill it in the receive buffer
 - directly send acknowledge via RFM69
 
 
Loop¶
- iterate Slots
 - If WAITing: is message is older than ??ms, perform an resend
 - If ACKed, pop it from the ring. Not the first non-ACKed? Error
 - If NACKed, resend it, if there is no WAITing before
 
Open points¶
- Acknowledge gets lost; retransmit started
	
- last-id for every net. Drop message if it matches
 
 
- RFM-Class receives messages in ISR as fast as possible. Sending acknowledge is done in the loop. 
	
- Order should be preserved.
 - Makes things super slow
 
 
Von Maximilian Seesslen vor 7 Monaten aktualisiert · 3 Revisionen