I was thinking further about the choice of frequencies for DSWM, matching exactly with the nine frequencies used by ASWM. Obviously that was done for compatibility reasons with ASWM. So I wondered how much compatibility between ASWM and DSWM is possible, and how easily could it be achieved?
Learning that it is possible for a DRE receiver to fix its SWM channel assignment indicates that receivers driving the SWM channel selection is at least possible with the DSWM13, but the more I think about it makes perfect sense that this is how SWM in general works. I had always sort of thought the SWM assigned channels without ever really thinking about it - bias from my computing background I guess thinking of the SWM as a "server". I'm still trying to come up with a way that can be tested/verified to be absolutely certain.
So assuming the receiver drives the process, how does a receiver choose its SWM channel? Well, the easiest way would be to start at the lowest channel and ask the SWM, "can I use channel x?" If it says no, the receiver goes up to the next channel until there are no more channels left and tosses out a 776 error. When I have fewer than 8 receivers connected to a SWM, they always use the lowest channels after a cold start of everything, so it is clearly using some sort of bottom-up assignment strategy. I haven't ever tried powering them on one at a time to verify they assign in a strict lowest to highest order, but I can if anyone is skeptical on this point (H20s still have the SWM signal screen so I can still determine what channels are being used)
When we look at the information Directv has released for ASWM, it shows the channel numbers and frequencies. Channel 1 is the guide channel, channels 2-9 are user channels. So the receiver would try 2 through 9, one at a time, before giving up. What happens if a receiver with firmware that knows about DSWM is connected to a DSWM? Well, it can ask for and receive channels above 9, of course. What if that same receiver was connected to a ASWM but "thought" it was connected to a DSWM? What happens when it asks for channel 10, which doesn't exist? Maybe the ASWM says "no" or maybe it says "error", either way it doesn't say "yes" so the receiver doesn't try to use it.
If this is indeed how it works, achieving compatibility with a receiver that knows about a DSWM being connected to either an ASWM or a DSWM would require no extra effort. So little effort, that there would be no need to tell a receiver it is connected to a DSWM - if it knows about the DSWM it knows channels higher than 9 exist and what frequencies they'd be found at, so it knows to ask about them and can use them if they're provided. It is possible it may ask any SWM it is connected to - no harm in asking them all for channel 10, the worst that can happen if you ask an ASWM for channel 10 is that it says something other than "yes"!
What about a receiver that only knows about ASWM connected to DSWM? It would ask for channels 2-9 as before, and the DSWM would reply "yes" to one of them. But wait, the DSWM spaces channels 51.03 MHz apart! The receiver thinks they're 102.06 MHz apart, so whatever channel it is assigned won't be found in the right spot. That's a problem, right? Maybe not. What if the DSWM uses the same channel number / frequency assignments for the first nine channels that the ASWM does, then channel 10 fits between channels 1 & 2, channel 11 fits between 2 & 3, and so on? That would preserve the compatibility, with the only "effort" needed being numbering them in a funny order. After all, 102.06 MHz is a rather odd number. Whatever reason that exact spacing was used in ASWM, there's certainly no reason it would have been used again in the DSWM, if not to preserve compatibility with receivers that don't know about the DSWM.
So why care about compatibility between ASWM and DSWM at all? Just include a "DSWM" switch type field and tell the receiver what it is connected to. That's certainly one way, and maybe that is how it works. But if it can be done so that "SWM" switch type represents both ASWM and DSWM, and receivers with firmware that know or do not know about DSWM can both interoperate with ASWM as well as DSWM, isn't that better? If this was difficult to achieve, it may not be worth the effort. But if it works like I'm describing, it was no effort at all. There are some obvious benefits to this compatibility, such as receivers with old firmware working on a DSWM until/if they're updated and MDUs being able to mix & match ASWM and DSWM without needing to re-do satellite setup on affected units.
There's one big potential gotcha here. What if the "channel number" field in whatever command format is sent over the SWM control channel is a 3 digit bitfield, allowing represention of channels 2-9 only? It's possible, if the protocol was not designed to ever be expanded with additional SWM channels. The Euro CSS standard uses a 3 bit bitfield for the "slot", for example. One key difference though may be in the physical layer used to send the commands. The Euro standard uses DiSEqC signalling, with 1.5ms needed to represent a single bit. With parity overhead, that's only 600 bps! It is easy to see why they wanted the most compact command format possible. The longer the duration of the command, the greater the possibility of collisions. According to P Smith, the 2.3 MHz FSK control channel has a 230 kbps rate "worst case", though I'm not sure where he came by that figure. If that's the case, there would be much less reason to save every bit as the Euro CSS command format did, and makes it more likely (though by no means certain) that there would have been some additional bits used to represent the channel number to allow for future growth.