Most products with Marvell radios can be modified to control the dozens of 802.11 parameters. Greenfield is definitely one of them. However, the client device's configuration controls have to allow it. Normal device documentation might not explain how to do it.
VARs and package providers often keep the details from their customers, as it gives them more control over their installed base and makes the customers more beholding to them. They also get fewer support calls that way.
Zebra, for example, has a publicly available Wireless Commands book, a couple hundred pages long, describing all but their "hidden commands". Sad to say, compared to its other great pieces of documentation, it's written very poorly, but at least it gives the format of all the possible commands. If you know the standard name of the 802.11 feature you want to control, you'll be able to identify it.
Another example is the channel selection list, which you could shorten to 1,6,11 (for 2.4 GHz) and greatly shorten the printers roaming delay. Great for warehouses with forklifts speeding along at 4x the human walking speed - especially at night when fewer supervisors are on-site.
And of course, all sorts of parameters that are better left alone. But they are available if someone wants to change them.
I found the discussion and here is a pretty good link:
Basically with a/g and no legacy rates there will only be OFDM and ERP-OFDM Preambles which will be transmitted at 6Mbps.
Thank you for the link. I had not seen that one before.
I would like to add one more "fly in the ointment", so-to-speak.
Not all Firmware follows the IEEE specs. Sometimes this is due to "secret sauce", and sometimes it is due to ignorant decisions by either a programmer or a project manager. Personally, I find the latter inexcusable. Their decisions are often foisted on the engineer/programmer with little or NO technical consideration as to their effects.
When chip set firmware is initially released, the chip set manufacturer's try to ship out generic code that prohibits unstable combinations of parameters. When a, so-called, more sophisticated and $ rich company purchases the source code/development package that is available (~ $80k ?), all bets are off. Yes, their new code may potentially be vastly superior in terms of options and possibilities, but just like other technologies, they are more things to break - and boy do they !
Even if you have signed NDA's, the manufacturer's product and parameter descriptions are still often written with the real details obscured - apparently to make it hard for their competitors to re-engineer their secrets. If, in addition, you replace IEEE terminology with the manufacturers internal company-speak, even the best engineers may never know how something really works, or the ramifications of setting particular bit combinations. Even your extra multi-thousand dollar investment may not get you access to the experts.
All this can end up creating products with mangled MAC or PHY protocols, creating problems that may take years to be resolved. Yes the radio's still might be able to "talk", but not without work-around's or substantial numbers of retry packets
If you ever get a chance to REALLY see the "secret sauce" documents, you'll be amazed at the things a chip can actually do. You sound like the kind of person who might enjoy it. Just keep an open mind.
Yeah, thanks for sharing this. This is a recent write-up mentioning ax and all. An interesting read.
However, I couldn't find where it said the preamble wouldn't contain DSSS. Figure 4 shows an OFDM-only packet for 802.11a where there never was DSSS. 5GHz has always been OFDM-only so there is no need for backward compatibility. The article says fig 4 is for a and g, but when g came around there were mostly b devices and networks around. 802.11g was definitely backwards compatible with them. 802.11n introduced the concept of green field without compatibility, but it didn't gain popularity so it was scrapped in ac, which was bad IMO. Figures 5 and 6 again sport a DSSS/DBPSK preamble.
I am not yet convinced. I haven't dug through my library, yet. I could be wrong, I have often been.
You're not wrong very often . I don't recall any instances here.
You are welcome Howard. It is a good article and explains everything really well. Funny you mention about the "Secret Sauce" and vendors. I have heard that from a certain vendor once and it made me laugh when I asked about a specific feature. I'm sure vendors do stuff. I have not had a chance to read such documents however but would love to some day. I am however just really focusing on the actual standards especially for the CWAP test and understanding of how the actual technology architecture was written by the 802.11 folks.
There is so much to CWAP IMO and I don't think a single test can really cover it all.
Petri thanks for the response, I don' think you read what I wrote and perhaps did not get a chance to read the full article or perhaps there is a misunderstanding of what we are both talking about here, so few thoughts here:
1- Article literally mentions 802.11ax once:
"Since 802.11n, 802.11ac, and 802.11ax are all based on OFDM, the same operational rules apply to them, so there is no need to go any further than 802.11a for the purposes of this discussion. The point of this section was to show that PPDUs are not transmitted at a single data rate."
2- You mentioned figure 4, not sure if you read what is says under the figure but here it is:
"In the Fig 4 frame format, the PLCP Preamble and SIGNAL field is transmitted at 6Mbps, and the PSDU (and surrounding sub-fields) are transmitted at the data rate specified in the RATE field, which is 6-54Mbps. This means that OFDM and ERP-OFDM PPDUs are transmitted at either 1 or 2 data rates."
So if it is a pure OFDM and ERP-OFDM network preambles should be at 6 Mbps and they should not be using DSSS or HR-DSSS preamble rates. Here is another link that explains it:
3- Figure 5 and 6 ofcourse will support DSSS Preamble because it is DSSS-OFDM Long Preamble with a bit value or 144 and DSSS-OFDM Short preamble with a bit value of 72.
NOTE: This is before 802.11n introduced the concept of Green Field
In relation to Greenfield. At the time many people didn't think it would be used very often, if ever. And given that the idea was dropped from the standard, it looks like we/they were right.
It was probably added to /n at the behest of one of the members of the IEEE /n working group, who planned to make some marketing "swoop" with it.
That's why we want standards to be flexible from the start - because we also remove features, not just add them.