If that works it would allow a grand unified approach: listen mode, frequency hopping, multiple bitrate coexistence all 'legit' and using the existing hardware.
It wasn't that easy since listen mode only has a resolution of 4.2ms at the > 1s range. With that granularity any clock differences quickly add up to intolerably large amounts of time. But I think I've figured out a scheme to make all of this work with stock Moteinos:
The key is not to calibrate the clients to the server, but the server to the clients: When a listen mode client joins the network it sends two requests to the gw (hopping appropriately via control channel), separated by one well defined listen mode period (say 10s). The server measures that interval using its crystal and can derive when the client will listen in the future.
When the server wants to send something it no longer needs to blast a burst for 3s. It will know with some accuracy (100ms at worst I would think) when the client will come online and can then deliver the packet using a 100ms burst. The client acks back together with any payload it might have for the server, plus frequency band and bitrate settings it will be listening at in the future (giving the client control over frequency hopping as well as bitrate optimization).
Gw acks the client ack. If received the client goes back into listen mode. Otherwise it reestablishes the connection as in the beginning. If the client notices a large temperature shift or if it doesn't receive a regular heartbeat (say every 5 minutes) from the gw it also reestablishes the connection.
AC powered clients use a less complicated version of the same scheme, telling the server at which frequency and with what bitrate they're listening and reestablishing via control channel if the connection is lost. They will be in rx at all times and can do without the listen mode synchronization. The gw will poll them regularly nonetheless to allow all communication to occur at the optimal bitrate. If they spontaneously want to send to the gw they will need to go via the control channel.
In addition to being legit via frequency hopping and saving power/air time by using adaptive bitrates this scheme has another huge advantage: it allows the use of client optimized listen periods. So if you need 300ms latency for some client and can afford the battery hit you can just configure that client for a 300ms listen period. Or if you want your listen period to be 1 minute that is now also possible: it no longer requires a 1 minute burst to wake that client.
I think this will work fine as long as the control channel isn't too slow. E.g. I could see the control channel running at 19200 baud. If you want to go down to 1200 baud for extreme range I think it would be best to just add a second gateway since you don't want to burden esp coin cell nodes with long duration control packets - even if it's only while establishing a connection.
Joe