Question: What are reasonable options for radio comms with MCUs?

Thread Starter

ApacheKid

Joined Jan 12, 2015
1,533
I'm interested in some reasonable options for using RF to communicate with an MCU. This is something that might become a project of some sort.

We have

  • WiFi
  • nRF24L01

are there others? The WiFi is not too complex but might have more overheads, like not idea for "real time" with sockets and so on to deal with. The nRF might have less overheads (software stack, power consumption, I don't know) and might be better for a more "real time" kind of mechanism.

There are some articles about using nRF2401 with STM32 all over the place, this seems good for example:

https://embeddedexpert.io/?p=870

But are there other options too? other devices? other RF bands?

A little about the overall objective, this is just an idea something I may or may not actually try to do.

Devise a system of hardware/software that can run on on an STM32 board and which enables a remote station (i.e. my desktop PC) to manipulate the boards peripherals remotely.

Like have abstractions on the desktop PC (probably developed in .Net/C#) that allows a desktop app to setup, configure and use peripherals on the STM32 board as if they were local.

In other words program the board by running remote code that manipulates the board at a low level.

This is just a very vague outline, clearly we can't expect code running on the desktop to perform as well as code running locally, it is just an idea at this point.

In principle setting up and reading data on the STM32 via an A/D converter, could be done remotely, if there was a messaging system setup so that the remote PC could - in effect - setup board peripherals via messages, e.g. we could have a message that represents actions like:

Code:
__GPIOC_CLK_ENABLE();
    __ADC1_CLK_ENABLE();

    gpioInit.Pin = GPIO_PIN_1;
    gpioInit.Mode = GPIO_MODE_ANALOG;
    gpioInit.Pull = GPIO_NOPULL;
    HAL_GPIO_Init(GPIOC, &gpioInit);

    HAL_NVIC_SetPriority(ADC_IRQn, 0, 0);
    HAL_NVIC_EnableIRQ(ADC_IRQn);

    ADC_ChannelConfTypeDef adcChannel;

    g_AdcHandle.Instance = ADC1;

    g_AdcHandle.Init.ClockPrescaler = ADC_CLOCKPRESCALER_PCLK_DIV2;
    g_AdcHandle.Init.Resolution = ADC_RESOLUTION_12B;
    g_AdcHandle.Init.ScanConvMode = DISABLE;
    g_AdcHandle.Init.ContinuousConvMode = ENABLE;
    g_AdcHandle.Init.DiscontinuousConvMode = DISABLE;
    g_AdcHandle.Init.NbrOfDiscConversion = 0;
    g_AdcHandle.Init.ExternalTrigConvEdge = ADC_EXTERNALTRIGCONVEDGE_NONE;
    g_AdcHandle.Init.ExternalTrigConv = ADC_EXTERNALTRIGCONV_T1_CC1;
    g_AdcHandle.Init.DataAlign = ADC_DATAALIGN_RIGHT;
    g_AdcHandle.Init.NbrOfConversion = 1;
    g_AdcHandle.Init.DMAContinuousRequests = ENABLE;
    g_AdcHandle.Init.EOCSelection = DISABLE;

    HAL_ADC_Init(&g_AdcHandle);
So the remote PC could send a set of messages (or some single message that combines several actions) that when received by the board cause it to execute such statements as

Code:
    g_AdcHandle.Instance = ADC1;

    g_AdcHandle.Init.ClockPrescaler = ADC_CLOCKPRESCALER_PCLK_DIV2;
    g_AdcHandle.Init.Resolution = ADC_RESOLUTION_12B;
    g_AdcHandle.Init.ScanConvMode = DISABLE;
    g_AdcHandle.Init.ContinuousConvMode = ENABLE;
    g_AdcHandle.Init.DiscontinuousConvMode = DISABLE;
    g_AdcHandle.Init.NbrOfDiscConversion = 0;
    g_AdcHandle.Init.ExternalTrigConvEdge = ADC_EXTERNALTRIGCONVEDGE_NONE;
    g_AdcHandle.Init.ExternalTrigConv = ADC_EXTERNALTRIGCONV_T1_CC1;
    g_AdcHandle.Init.DataAlign = ADC_DATAALIGN_RIGHT;
    g_AdcHandle.Init.NbrOfConversion = 1;
    g_AdcHandle.Init.DMAContinuousRequests = ENABLE;
    g_AdcHandle.Init.EOCSelection = DISABLE;

    HAL_ADC_Init(&g_AdcHandle);
This could all be encapsulated in a short message, every setting could be contained in the message so one message results in the board doing that setup step.

This is purely something I see a technical experiment, not advocating it as a serious or generally useful thing, but a pet project that might be fun to play around with.

Are there other options for the comms besides nRF or WiFI?

Here's one I just stumbled upon:

https://www.st.com/resource/en/user...radio-for-stm32-nucleo-stmicroelectronics.pdf
 

Jon Chandler

Joined Jun 12, 2008
1,029
Andreas Spiess "the Swiss Guy" on YouTube has a number of videos on how to drastically cut the overhead in wifi communications – something like a wakeup, set up comms and blast out a message in a second.

ESP8266s and ESP32s also have a direct link communication protocol (the name of which escapes me at the moment) to eliminate much of the wifi overhead.


https://youtube.com/c/AndreasSpiess
 

Ya’akov

Joined Jan 27, 2019
9,072
There are modules that emulate a serial connection over radio and so eliminate any need to actually deal with the radio part. They are very common.

As far as band choice, from what you describe, in the US you have one and a half choices. Obviously, you want unlicensed operation so it will have to be in an ISM band. The most obvious is 2.4GHz. There are quite a few options in this band, including the nRF2401L-based modules. Zigbee is possibly a good choice for you as well.

That's the one choice, the half choice is to use 915MHz which is a very nice band but hardware for it will almost all modules you will find are for LoRa which is unsuited to your purpose. However there is a different Nordic chip, the nRF905 which does operates in the 433, 868, and 914MHz bands.

The 868MHz band is ISM in Europe but not the states. 433MHz is an ISM band here but the regulatory restrictions, include transmission length (every short), duty cycle (very long), and total time on air per day (very little) make it useless to you. 915MHz, on the other hand, is very much like the 2.4GHz band with effectively no restrictions to worry about.

It is used for the sort of thing you are doing, and telemetry (weather stations), and proprietary IoT, HA, and the like. It is also obviously a lot less crowded than 2.4GHz.
 

Thread Starter

ApacheKid

Joined Jan 12, 2015
1,533
Last edited:
Top