For packets with a path set; auto try again if no echo was heard. High Availability Link for Overwhelmed Meshes - Project HALO. Stop the flood#2367
Conversation
|
https://analyzer.letsmesh.net/packets?packet_id=671326411 
This seems to be working |
|
G2 Repeater.zip To monitor as meshdebug is set in these 2 firmware builds in one window
31 hop trace ping pong to one of the more busy repeaters in the area |
|
https://github.com/Brent-A/mcsim seems to show this helps; better than showing it hurts. DM TestResult 1 (count test: count=1 vs count=6)
Result 2 (explicit enable/disable by margin: margin=40 vs margin=0, both count=6)
|
…o-direct-path-retries
|
https://github.com/mikecarper/MeshCore/releases/tag/v1.15.0-dev-6c20a106-meshdebug-off debug off for set it and forget it locations |
| } else if (blended < -128) { | ||
| blended = -128; | ||
| } | ||
| return (int8_t)blended; |
There was a problem hiding this comment.
I don't think lines 89-93 are doing anything. Even if we have max values for curr_snr_x4 and new_snr_x4, weighted_sum maxes out at -512 or +512, which we then divide by four, so it can't be less than -128 or greater than +128.
|
@mikecarper, your work inspired me to get active again on the repeated sending feature I implemented for repeaters at the beginning of the year. In January I tested it with Brent's mcsim simulator and was in discussion with Brent after I saw weak results: the simulation didn't show an improvement and I questioned if this could come from a problem in mcsim. Unfortunately Brent turned to other projects so I was stuck here. Now I managed to find out
That way I could improve in a documented mcsim test scenario the package deliveries from 66% without repetition to 96% with activated conditional repetition. I now added the results to the original issue at #1342 to summarize the results. I am writing this to give you the context of my preceding work as I now
Don't take all analysis points as fully correct as it is AI generated; but I think the simulation test results are accurate and they show you might need to find out why the sending likelihood keeps low in your implementation. Furthermore I think the number of TX needs to be reduced in your implementation; maybe the RAM usage can be reduced as well. I'd like to see the best features of our implementations to be combined into one with a minimal impact approach to the MeshCore dev branch. |
I don't see anything in your data about collisions, so this conclusion seems very confident about the cause. Do you have some extra data about collisions that justifies that or is it an educated guess based on the number of transmissions? This is a real question coming from a standpoint of ignorance as I've only just started trying out mcsim, but I'm hoping to leverage it to test out some ideas I have to help bypass unresponsive nodes. If you run this again, it would be great to get the run data to put into Rerun and view how each works.
/**
* \brief Decide whether a DIRECT packet should get one delayed retry if the next hop echo is not overheard.
* Sub-classes can use neighbour tables or other link-quality data to opt in selectively.
*/
virtual bool allowDirectRetry(const Packet* packet, const uint8_t* next_hop_hash, uint8_t next_hop_hash_len) const;I don't think this function does what your writeup claims it does. I would expect the app or companion (which I think is currently incapable of knowing per-hop retries in repeater firmware even exist) should still attempt end-to-end retries regardless of per-hop success. If something were to collide, I would expect it to be a second (or third) attempt at sending DMs that is too soon because it doesn't realize that the HALO-powered repeaters are still working it down the chain. Worse would be a scenario where the app falls back to flood routing while the message is still working its way through the network via a HALO'd path. In any case, it's fantastic to see more work on raising deliverability and decreasing reliance on floods. Keep up the good work! |
Add Github Security policy
Configure GitHub Stale Bot
Added some missing CLI commands
…ries # Conflicts: # examples/simple_repeater/MyMesh.cpp # src/Dispatcher.cpp # src/Dispatcher.h # src/Mesh.cpp # src/helpers/CommonCLI.cpp # src/helpers/CommonCLI.h # src/helpers/SimpleMeshTables.h
# Conflicts: # examples/simple_repeater/MyMesh.cpp # examples/simple_repeater/MyMesh.h # src/Mesh.cpp # src/helpers/CommonCLI.cpp # src/helpers/CommonCLI.h # src/helpers/ESP32Board.h
# Conflicts: # build-iotthinks.sh # build.sh # docs/cli_commands.md # examples/companion_radio/MyMesh.cpp # examples/companion_radio/main.cpp # examples/simple_repeater/MyMesh.cpp # examples/simple_repeater/main.cpp # examples/simple_room_server/MyMesh.cpp # examples/simple_sensor/SensorMesh.cpp # platformio.ini # src/helpers/CommonCLI.cpp # src/helpers/ESP32Board.h # src/helpers/radiolib/CustomLLCC68Wrapper.h # src/helpers/radiolib/CustomLR1110Wrapper.h # src/helpers/radiolib/CustomSTM32WLxWrapper.h # src/helpers/radiolib/CustomSX1262Wrapper.h # src/helpers/radiolib/CustomSX1268Wrapper.h # src/helpers/radiolib/CustomSX1276Wrapper.h # src/helpers/sensors/EnvironmentSensorManager.cpp # variants/heltec_ct62/platformio.ini # variants/heltec_t096/platformio.ini # variants/heltec_tracker/platformio.ini # variants/heltec_tracker_v2/platformio.ini # variants/heltec_v2/HeltecV2Board.h # variants/heltec_v2/platformio.ini # variants/heltec_v3/HeltecV3Board.h # variants/heltec_v3/platformio.ini # variants/heltec_v4/HeltecV4Board.cpp # variants/heltec_v4/platformio.ini # variants/heltec_wireless_paper/platformio.ini # variants/lilygo_tbeam_1w/platformio.ini # variants/lilygo_tbeam_SX1262/platformio.ini # variants/lilygo_tbeam_SX1276/platformio.ini # variants/lilygo_tbeam_supreme_SX1262/platformio.ini # variants/lilygo_tlora_v2_1/platformio.ini # variants/xiao_c3/platformio.ini # variants/xiao_s3/platformio.ini # variants/xiao_s3/target.cpp # variants/xiao_s3/target.h # variants/xiao_s3_wio/platformio.ini
…Core into halo-direct-path-retries # Conflicts: # examples/simple_repeater/MyMesh.cpp # src/helpers/CommonCLI.cpp
…tries # Conflicts: # docs/cli_commands.md
# Conflicts: # examples/simple_repeater/MyMesh.cpp # src/helpers/BaseChatMesh.cpp # src/helpers/CommonCLI.cpp # src/helpers/CommonCLI.h # variants/heltec_t096/T096Board.cpp # variants/heltec_v4/HeltecV4Board.cpp
8 participants
This PR adds direct-retry behavior for direct-path traffic when an expected forward echo is not overheard, with link-quality gating that can be configured (5db is the default). So if the SF is 7 then we can expect that -7.5db is the limit; if the link is below -2.5db then this will not try again as the odds of success is low. The retry logic only triggers if the SNR is +2.5 or better. Default value is off. Wait uses 4 times the packet-time equivalent with minimum floor of 200ms
Behavior:
+3.00 dBSNR for adaptive CRselection.
0.25 dB.blend:
75%existing SNR and25%new heard SNR.repeater table.
skipped.
Covers direct retry target selection for:
PATH,REQ,RESPONSE,TXT_MSG,ANON_REQACKMULTIPARTpackets carrying ACK payloadsTRACE(with existing downstream-hop guard)CLI added:
get direct.retryset direct.retry on|offget retry.presetset retry.preset infra|rooftop|mobileget direct.retry.countset direct.retry.count <1-15>get direct.retry.baseset direct.retry.base <10-5000>get direct.retry.stepset direct.retry.step <0-5000>get direct.retry.marginset direct.retry.margin <0-40>get direct.retry.crset direct.retry.cr offset direct.retry.cr <cr4_min>,<cr5_min>,<cr7_min>,<cr8_max>get recent.repeater [page]set recent.repeater <prefix> <snr_db>clear recent.repeater