Well, the answer is basically no on there being a current chip that is only concerned with the PHY layer. Because chip count is a crucial part of system cost, years ago it became the practice to put the PHY and MAC, and now the protocol processing too, on the same mixed-signal chip. For example the ESP8266 (the IoT favorite WiFi maker gadget) has a 32 bit general purpose processor and all of the elements of basic MAC and PHY on the chip. You can program the ESP8266 and use its WiFi just fine.
But I would argue that it is no longer true that division by a hardware interface routed through the PC board need be the solution. Modularity on board the chip (as in the ESP8266) is sufficient to do what I described - the PHY layer can isolated (even if it is implemented in updatable firmware) if the firmware that controls the transmission DAC is isolated, locked down, and enforces the band limit and power limit required by the FCC. It can even be updatable, as long as it is protected with an adequate barrier to consumer modification. It need not be secret - in fact it would be better if it could be reviewed by those concerned with ensuring it will actually limit the output. Now in other radios, less integrated, there are separate chips for the transmit DAC path from the protocol path. I use those chips in my experimental Part 97 transceivers on 2.4 and 5 GHz, and there are chips from MAXIM and Analog Devices for example, that might be appropriate if you want to design your own router, however they are never going to be part of consumer devices because using them is costly. If you want to enforce a filter, you can do that fairly easily. But to implement full 802.11ac OFDM + MIMO would be a bear of a DSP program to build from scratch for these chips, though in principle they are capable of doing that. But in the fully integrated designs, there is enough modularity *on-chip* that one could make sure that there are no signals emitted that are outside the relevant band and power limits. (one might even just do this by detecting that limits are exceeded and powering of the transmit amplifier, which would probably make the FCC even more happy... the algorithm to detect excess power or out-of-band emissions could be quite simple, compared to a filter spliced in the signal path). An external "limit-exceeding signal detector" could also be very inexpensive, if it did not need to do ADC from the transmitted signal, but could get access to the digital samples and do a simple power measurement. On Monday, March 14, 2016 12:16pm, "Wayne Workman" <wayne.workman2...@gmail.com> said: > Is there an existing chip that is only concerned with layer 1? > On Mar 14, 2016 9:15 AM, "Jonathan Morton" <chromati...@gmail.com> wrote: > >> >> > On 14 Mar, 2016, at 16:02, dpr...@reed.com wrote: >> > >> > The WiFi protocols themselves are not a worry of the FCC at all. >> Modifying them in software is ok. Just the physical emissions spectrum must >> be certified not to be exceeded. >> > >> > So as a practical matter, one could even satisfy this rule with an >> external filter and power limiter alone, except in part of the 5 GHz band >> where radios must turn off if a radar is detected by a specified algorithm. >> > >> > That means that the radio software itself could be tasked with a >> software filter in the D/A converter that is burned into the chip, and not >> bypassable. If the update path requires a key that is secret, that should >> be enough, as key based updating is fine for all radios sold for other uses >> that use digital modulation using DSP. >> > >> > So the problem is that 802.11 chips don't split out the two functions, >> making one hard to update. >> >> To put this another way, what we need is a cleaner separation of ISO >> Layers 1 (physical) and 2 (MAC). >> >> The FCC is concerned about locking down Layer 1 for RF compliance. We’re >> concerned with keeping Layer 2 (and upwards) open for experimentation and >> improvement. >> >> These are compatible goals, at the fundamental level, but there is a >> practical problem with existing implementations which mix the layers >> inappropriately. >> >> - Jonathan Morton >> >> _______________________________________________ >> bufferbloat-fcc-discuss mailing list >> bufferbloat-fcc-disc...@lists.redbarn.org >> http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss >> > _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
