search

timmbogner / Farm-Data-Relay-System

A system that uses ESP-NOW, LoRa, and other protocols to transport sensor data in remote areas without relying on WiFi.
MIT License
485 stars 108 forks source link

revert sendFDRS to Synchronous operations, add sendFDRSAsync #217

Closed aviateur17 closed 2 days ago

aviateur17 commented 2 weeks ago

Initial coding for Synchronous sendFDRS()

Need to test compilation and functionality before this PR is complete.

aviateur17 commented 2 weeks ago

Calls to sendFDRS from nodes will be synchronous. Added sendFDRSAsync() to use Asynchronous calls. Added code in sleepFDRS to check for Async functionality complete before going to sleep.

aviateur17 commented 2 weeks ago

Working through issue where large amount of DR Data (~40 DRs) sent via LoRa, the receiving gateway is getting garbage data and CRC Mismatch. Up to 32 DRs has no issues.

Also, when splitting large amount of DR data (~40 DRs) into multiple transmits (packet size exceeds 250 bytes), receiver is not receiving 2nd set of data.

Edit - seems to be timing related - putting a delay between send of the first and second packets seems to correct the issue with the data corruption in the first packet but now second packet has data corruption - looking into what delays are needed.

Edit2 - Somewhere around 500ms inter-message transmit delay needs to happen. My concern is that is only when controllers are close to each other with the current LoRa spreading factor and coding rate. Larger spreading factors and larger distances may require longer inter-message delays. Could build an algorithm to change the delay based on the size of the packet, spreading factor and coding rate and node to node distance but that would require a bit of testing.

Edit3 - Possibly take the previous LoRa airtime and add some additional factor. I think spreading factors and coding rates would be reflected in the airtime so those variables would be already accommodated for.

timmbogner commented 2 weeks ago

Are these issues affecting all operations or just synchronous ones?

We've run into issues in LoRa stuff that required arbitrary delays before, but 500ms is a lot. I'd like to study up on where/why the timing is getting thrown off before we do an algorithm to make up for it. It's worth noting that I've needed to add delays for compatibility with SX1262 in the past.

Just saw edit 3: That seems like the best fix for now, but there has to be a better way. I might try a deep-dive into the LoRa timing stuff soon, as I'll hopefully have some free time on an upcoming vacation. I think we can add the synchronous LoRa stuff sooner, and then fix the large transmission issue.

aviateur17 commented 2 weeks ago

Just saw edit 3: That seems like the best fix for now, but there has to be a better way. I might try a deep-dive into the LoRa timing stuff soon, as I'll hopefully have some free time on an upcoming vacation. I think we can add the synchronous LoRa stuff sooner, and then fix the large transmission issue.

Agreed. We can handle the larger data operations in another PR. Hopefully can submit this soon.

aviateur17 commented 2 weeks ago

Got the inter-message delay down to 100ms and large number of DRs seem to work properly with and without ACKs. Creating commits soon.

aviateur17 commented 4 days ago

I believe this should be complete. Let me know if you run into or see any issues.

timmbogner commented 3 days ago

It seems to work flawlessly! I'll merge this soon.