I've tried usbradio and simpleusb. I've tried editing the rxondelay and all the other nonsense. This is driving me crazy and makes listening to nets super annoying.
I think this would have to be an issue with the squelch settings on your radio.
This is not really an ASL issue.
What radio(s) are you receiving your node sa818 with? This absolutely matters.
If your radio has PL decoding enabled, and have programmed the sa818 with "reverse burst" enabled, which is really not that at all, it's actually STE, then the sa818 sends an odd tone burst at the end of transmissions. This is a 59 Hz tone that lasts for about 300 milliseconds.
Some radios will quietly close their CTCSS decoders when they encounter it. Others won't.
Examples of radios that don't include Baofeng and many other low-end Chinese radios, and Yaesu.
My Kenwoods, Icoms and radios running OpenGD77, such as my TYT MD-UV380, do, however.
If the sa818 put out a 55 Hz tone instead of a 59 Hz one, this would be a different story. Pretty much everything likes that tone, as many Chinese radios are set up to close squelch as soon as they hear it, even without CTCSS decoding enabled. It's more likely to work even than reverse burst or notone, where the tone drops out before the carrier.
I have actually been meaning to do a feature request in ASL3's usbradio driver to add 55 Hz STE as an option. Then you could, assuming you have a V1.2 (generic) or V5.5 (SHARI) firmware version of the sa818 radio, which is baseband, use usbradio to do the CTCSS encode and decode rather than your radio's PL using usbradio, then select this 55 Hz STE instead of notone or reverse burst, then almost no radio in existence would crash like that. Yaesu radios still would, though, unless the burst is about 500 MS long. They are just ridiculously bad about that.
So, unfortunately, my best advice would be to try other radios for receiving, or use something better than the sa818 on the node.
The Retevis RT85 as a node radio, or set of radios, sends out the 55 Hz STE that most radios like. DCS would be even better in that case, since ASL3's simpleusb radio doesn't have a delay line to eliminate squelch bursts received by the node, I.E. what others hear when you transmit to it. This can be fixed by using usbradio and manually configuring things in the configuration file, like rxsquelchdelay = 200 (the setting I've found to mwork very well with my ANF101M and RT85's) and opening the RX and TX HPF/LPF filters as far as they go for best audio quality, but that won't help you as far as you receiving squelch bursts from your radio at the end of node transmissions.
Unfortunately, I can't even tell you to use DCS on the sa818, which should solve that problem, because the sa818 doesn't properly implement DCS. All radios that use that method should send a 134.4 Hz tone at the end of transmissions, which breaks the coded squelch. The sa818, even when set to DCS, still sends a 59 Hz tone, so you'll still get that static crash.
Squelch tails are my enemy. I have done lots of things to insure no one will ever hear one of those from any of my nodes, and likewise, that I won't hear it from my nodes, either.
Using better radios makes this easier, but that's not always possible.
I should add that the simple act of someone owning a Yaesu radio makes me occasionally think about committing murder... Other than this one issue, they're pretty nice radios, but in all the years they've existed they've continued to have the world's worst squelch crashes on FM.
Okay...let me chime in with what I just experienced this evening and why I don't think this is a reverse burst or STE thing.
I have a DM32UV...which I'm sure falls in to that class of chinese radios being called out. My node is a kit4hams shari pihat with uhf sa818. I just checked the configuration...and I don't have reverse burst enabled. I do have Tx and Rx CTCSS enabled.
I flipped my radio on to my node's preset. Due to a programming error on my part and the fact I have two of the same radio; I grabbed the one I hadn't fixed the open squelch on. The first option I hit to fix this was enabling CTCSS.
So...squelch on the radio was actually open, CTCSS enabled, with no tail.
Net starts....net control says first part of stanza...unkeys. And holy cow I see what w4tts was talking about. A good half second of no-carrier open receive. I turned the volume down, jumped in to channel settings, bumped the squelch up to 1. Problem solved.
The key here is that it seems w4tts is getting open-receive. It can't be squelch tail or reverse burst if it's open rx noise. In order for either of those to be sent, you need a carrier. You would hear silence...but you wouldn't hear open noise.
I don't know if w4tts is using this odd config of open squelch with CTCSS. That's the only way I can see CTCSS being involved...the radio just takes longer to drop from CTCSS than it does from carrier. If the squelch is turned up and still does it; then that's a problem with the radio and not with the node or anything else.