feather nrf9151 and HTTPS example

marjonz · 2025-12-05T08:06:04+00:00

I’ve followed the instructions in https://docs.circuitdojo.com/nrf9151-feather/using-vscode.html and need to build the “https” example. When generating the b...

marjonz

AchimKraus A quick test on my bench, yielded horrible results, nothing connected. I will go drive again to the place where i’m within 100m of the cell tower it was connecting to. Thank you again. I will report back results later.

marjonz

@AchimKraus I didn’t get much success with your out-of-the-box binary. It still failed.
What I did end up changing are:
struct timeval recv_timeout = { .tv_sec = 8 };

and same for the transmit. (from 5 seconds to 8)

And also increased the timeout when doing the client request, from 3 to 5 seconds.
I have also added this in the main.c:

K_SEM_DEFINE(lte_connected, 0, 1);
static void lte_handler(const struct lte_lc_evt *evt)
{
    switch (evt->type) {
    case LTE_LC_EVT_NW_REG_STATUS:
        if ((evt->nw_reg_status == LTE_LC_NW_REG_REGISTERED_HOME) ||
            (evt->nw_reg_status == LTE_LC_NW_REG_REGISTERED_ROAMING)) 
        {
            LOG_INF("LTE connected to network.");
            k_sem_give(&lte_connected);
        }
        break;

    default:
        break;
    }
}

int main(void)
{
    /* Register callback handler to handler LTE events */
    lte_lc_register_handler(lte_handler);
    /* Connect */
    LOG_INF("Connecting to LTE...");
    err = lte_lc_connect();
    /* Wait indefinitely (or add timeout?) */
    k_sem_take(&lte_connected, K_FOREVER);
    if (err < 0)
    {
        LOG_ERR("Failed to connect. Err: %i", err);
        return err;
    }

    LOG_INF("Safe to use sockets now. LTE is connected.");
}

I’ve gotten about 80% success rate indoors. The timeouts I think might be the key, as it seems bordering on the 5 sec limit during transmits especially. I will keep testing and update this thread if any other major changes. But looks like this might be usable at this stage. I am still marred by the fact that the provider the Onemondo SIM connects to, seems to be not so good where I am.

AchimKraus

marjonz I am still marred by the fact that the provider the Onemondo SIM connects to, seems to be not so good where I am.

FMPOV, the main culprit is the lack of information about the radio network in your location. Maybe the device selects NB-IoT or you’re 80m from the tower, but that’s not the one used. Or what ever.

In general, with rather normal radio conditions (I’m located in south Germany), it works pretty well.

I’m not sure about the scope of your work. Nor if this has a chance to succeed in your location at all. As I wrote above, there is a “Cellular Monitor” app in the “nRF connect for Desktop” application. Together with a nRF9151-DK that was the usual starting point for me to explore the radio network. But it may not be too easy.
An alternative maybe to “restore” the app, the Thingy:91X is shipped with. The app connects to a Nordic Server and you get access to a web-page, which contains some information about the radio network. But I also don’t know, if that’s easier.

I’m not too common with the Onomondo SIM, I used it only once for some weeks and never checked, what their SIM-Admin-Web-Page may offer. Other providers have web-pages, where you see the tower, signal-strength and technology (LTE-M or NB-IoT) used for that last connect. Maybe that’s worth to give a try.

marjonz

AchimKraus I will look into those. I also tried getting my hands on a local IoT SIM for comparison. I have tried the sample fw from nRF Desktop, that one gave me the page (after scanning the qr code on the thingy) and I can change the led, read the button press, etc. But that was also a bit sluggish (I was still using the Onemondo SIM). I will look for more examples, but I think for my application, it should be able to handle whichever provider, and should cater to these situations where I would have limited or failed connects to the remote server.

What I did find is the preset 5 second timeouts on the tx/rx for the socket, and the 3 second timeout for the HTTP post, seems a bit borderline. I might need to fine tune it more, specially when I start sending bigger chunks of data (looking close to the MTU limit of 1358). But you’ve been a great help and resource. I hope this thread will help someone else starting with the feather and nRF in general.

I find that amount of available functions in the nRF to be very helpful, but documentation is also very sparse, and finding out which modules are used for the certain example, is also a bit difficult for me. But just having the functions available on hand is really great.

I’m coming from an STM32/Silicon Labs background where only the LL or HAL functions are available, and I had to write the drivers to interface to a modem and such. So having it readily available, is a luxury. I need to do a lot of reading over the Christmas break and find out what else do I need from the library that is not there.

Thank you for all the help and support. I really appreciate it. A blessed Christmas to you and a prosperous New Year ahead.

« Previous Page