Rein, I tested the alpha server 0.9.27 last night and here are my comments: 1. This is working great. It is very responsive: I started mobile stationary and it switched to the higher speed very quickly. Then went mobile-mobile and it reverted to the slower speed (I had PSK500 and PSK500+FEC+Interleaver as the robust mode). Came closer to home with a stronger signal and it changed back to high speed. 2. RSID has to be reviewed. The hit rate is too low. It looks like a pre-sentisation issue. If I send an empty frame with pre and post RSID on, the second one has far far better chances to get picked up. My next task is to find why we have such a discrepancy in sensitivity. In practice it should be at least as good as a THOR22 or even THOR8 to be of real value for our application. I am convinced it has the capability to do what we need it to do. 3. The server may changes the timing a little too soon: I had overlaps when it switched to the fast mode. Not sure why. Maybe the timing is too short to start with. 4. QPSK31 for BPSK500+FEC creates a problem in that the initial timeout is very long (it thinks probably this is PSK31). That will be fixed when we have a separately allocated mode name and RSID for those. 5. One thing I propose: since the operator may connect in a different mode (say THOR22 due to conditions), the server should be able to still work effectively shifting speed up and down from the connect speed. So I suggest the final solution should be a list of several modes and the mechanism for changing is "one up" or "one down", from the current mode. Hope this makes sense. 6. Other point: while I am on the adaptation of BPSK for ARQ application, do you see a benefit either now or in the near future to change the varicode in order to better the chances of the control characters to get through QRM. The explanation: right now a space and the letter "e" require respectively 3 ("100") and 4 bits ("1100") to be transmitted correctly to be received without error. In comparison the <SOH> and <EOT> require 12 bits to be transmitted error free. If my recollection of statistics is correct that is a factor of 9 to 16 time more chances to be hit by QRM. So if we are going to do something on memory ARQ or other QRM fighting mechanism that need a start and/or end frame reference then it is of benefit to re-arrange the varicode. A new version of BPSK + FEC + variable (and longer) interleaver is coming. Regards, John