It is definitely possible to send and receive on a custom frequency (don't know about bandwidth). But not in a clean, fully supported way as far as I am aware.
There is a low-level function available in the WiFi stack that let's you configure the PHY frequency for TX/RX directly. You can link to it with this function declaration:
Code: Select all
typedef enum {
PHY_XTAL_FREQ_40M,
PHY_XTAL_FREQ_26M,
PHY_XTAL_FREQ_32M,
} phy_xtal_freq_t;
/// buf3 must be a 3-byte uint8_t array used as a buffer
void set_rfpll_freq(phy_xtal_freq_t xtal_freq, uint16_t target_base_mhz, int16_t target_offset_khz, uint8_t *buf3);
Use it like this for example (after your normal WiFi stack is set up):
Code: Select all
uint8_t buf3[3];
// the standard ESP32-S3-WROOM-1 module uses a 40MHz crystal oscillator
set_rfpll_freq(PHY_XTAL_FREQ_40M, 2435, 0, buf3); // non-standard channel frequency - nearest standard channels are at 2432MHz and 2437MHz
Be aware that this setting will be overwritten by some WiFi functions like the AP scan. The wifi stack keeps track of the current channel number as a simple integer in the range 0 through 14, so you will never get a clean integration with all APIs using this method.
I have verified that this works as intended when sending packets manually with `esp_wifi_80211_tx` and receiving packets with the promiscuous mode callback `esp_wifi_set_promiscuous_rx_cb` by using two ESP32-S3 to communicate on a custom frequency and additionally monitoring the RF signals with a spectrum analyzer.
Again, this is not a drop-in fix but rather a very low level access hatch for the WiFi peripheral. Using this in your application (whatever it is) will very likely require further research and engineering.
Do make sure to consult local regulations before experimenting with these low-level RF primitives.
This will no longer be a standards-conform WiFi device and transmitting on restricted frequencies may be illegal in your territory.