Ensure message delivery for NASA packets #93
Conversation
atanasenko
force-pushed
the
transport
branch
6 times, most recently
from
d8082f4
to
e727d98
Compare
|
Thank you for that draft. Can you have a look into the test stuff. That is currently broken. Short reminder. That test stuff is designed to run without esphome. Regarding the preamble I have found this post https://buildingenergy.cx-associates.com/what-is-rs-485-part-2 . It seems that this is more to make devices sync up on the right boud rate. |
|
I'll try to find some time to work on the tests this weekend. |
atanasenko
force-pushed
the
transport
branch
from
e727d98
to
d6747cb
Compare
|
Do you had time to revisit this? Also there are merge conflicts. |
* Queue outgoing packets and send them during loop() * Only send packets during relatively quiet time * Do not send new packets until we receive an ack for the one already sent * Retry sending packet if no ack received * Make absolutely sure that there is no incoming data available or there is no more data expected to arrive before sending * Attempt to recover packets from incoming data if stars aligned in a way that all of the above failed * Modify logging to be able to easily change log levels during development * Optimize passing data buffers back and forth to prevent extra copies
|
@atanasenko |
|
It seems @atanasenko did not have the time anymore to look at it. It also did not makes sens to fix the merge conflicts. I plan to split Nasa and NonNasa into two different component. Then this could be handled directly within the nasa protocol file. |
|
Just stating that this branch is used |
This is a draft of my playground which I was testing with my NASA 3 indoor to 1 outdoor units and trying to fix the writes which were either ignored or also caused some incoming packets to get mangled (sometimes including acks for a successful message). I'd like to open a discussion and am open for any suggestions.
I'm running this code locally and so far I haven't had a single missed packet for quite a while.
I don't have a way to test this with non-nasa, so I retained the behavior where packets were sent immediately after F8.
I have a suspicion that the preamble bytes that are sent prior to each packet might have something in them for congestion control. But until somebody figures this out, sending packets has to happen during quiet periods.
See #57