IoTopenTech

IoTopenTech

Member Since 2 years ago

Experience Points
38
follower
Lessons Completed
2
follow
Best Reply Awards
12
repos

133 contributions in the last year

Pinned
⚡ Hardware y software del nodo TTN MAD V2 desarrollado por la comunidad The Things Network Madrid
⚡ IoT platform
⚡ Documentación genéral sobre The Things Network Madrid
Activity
Jan
3
2 weeks ago
Activity icon
issue

IoTopenTech issue bozhinov/pChart2.0-for-PHP7

IoTopenTech
IoTopenTech

[Question] Use irregular intervals in X axis for timestamps

If I draw a time series with irregular intervals [10:00, 10:01, 11:00], pChart uses the same distance between the points.

For example, the distance in the X axis between 10:00 and 10:01 is the same as the distance to the next point in the series (11:00).

Is there any scaling option to avoid this behaviour?

Kind regards from Madrid

Dec
13
1 month ago
Activity icon
issue

IoTopenTech issue comment ARMmbed/mbed-os

IoTopenTech
IoTopenTech

STM32WL I2C_1 and I2C_2: Unable to deep sleep

Description of defect

Using STM32WLE5C, I2C_3 is able to enter deep sleep, but I2C_1 and I2C_2 no.

Target(s) affected by this defect ?

STM32WL

Toolchain(s) (name and version) displaying this defect ?

ARM GCC

What version of Mbed-os are you using (tag or sha) ?

mbed-os-6.15.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

Mbed Studio: 1.4.3

How is this defect reproduced ?

The following code in https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/i2c_api.c for I2C_1 and I2C_2 seems to lock deepsleep

imagen

But there is no way to re-enable deepsleep (for example in a low power device that only needs to read a sensor once per hour).

This increases the power consumption in 3mA.

It would be useful to have a free or deinit method.

IoTopenTech
IoTopenTech

Thanks @LMESTM, I've made that local change and it seems to work properly (no the uC is deepsleeping).

Dec
10
1 month ago
Activity icon
issue

IoTopenTech issue comment ARMmbed/mbed-os

IoTopenTech
IoTopenTech

STM32WL I2C_1 and I2C_2: Unable to deep sleep

Description of defect

Using STM32WLE5C, I2C_3 is able to enter deep sleep, but I2C_1 and I2C_2 no.

Target(s) affected by this defect ?

STM32WL

Toolchain(s) (name and version) displaying this defect ?

ARM GCC

What version of Mbed-os are you using (tag or sha) ?

mbed-os-6.15.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

Mbed Studio: 1.4.3

How is this defect reproduced ?

The following code in https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/i2c_api.c for I2C_1 and I2C_2 seems to lock deepsleep

imagen

But there is no way to re-enable deepsleep (for example in a low power device that only needs to read a sensor once per hour).

This increases the power consumption in 3mA.

It would be useful to have a free or deinit method.

IoTopenTech
IoTopenTech

Sorry @jeromecoutant I'm not experienced enough with mbed as to know what to look on there (i2c_free of mbed_hal_fpga_ci_test_shield/i2c/main.cpp).

I think that there should be a free method in I2C.cpp; something like this void I2C::free(void) { lock(); i2c_free(&_i2c); unlock(); }

As there is already a i2c_free function in https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/i2c_api.c

imagen

That unlocks deep sleep in I2C_1 and I2C_2 imagen

Kind regards

Activity icon
issue

IoTopenTech issue comment ARMmbed/mbed-os

IoTopenTech
IoTopenTech

STM32WL I2C_1 and I2C_2: Unable to deep sleep

Description of defect

Using STM32WLE5C, I2C_3 is able to enter deep sleep, but I2C_1 and I2C_2 no.

Target(s) affected by this defect ?

STM32WL

Toolchain(s) (name and version) displaying this defect ?

ARM GCC

What version of Mbed-os are you using (tag or sha) ?

mbed-os-6.15.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

Mbed Studio: 1.4.3

How is this defect reproduced ?

The following code in https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/i2c_api.c for I2C_1 and I2C_2 seems to lock deepsleep

imagen

But there is no way to re-enable deepsleep (for example in a low power device that only needs to read a sensor once per hour).

This increases the power consumption in 3mA.

It would be useful to have a free or deinit method.

IoTopenTech
IoTopenTech

Yes, deepsleep is currently disabled during I2C init, and re-enabled in deinit... Maybe it should be implemented with more detailed conditions; Help would be required for that.

In the current implementation, I suppose that sensor should be "init" before each transmission..

Thanks @jeromecoutant

The problem is that there is no way to deinit I2C in the I2C API (https://os.mbed.com/docs/mbed-os/v6.15/apis/i2c.html)

Activity icon
issue

IoTopenTech issue ARMmbed/mbed-os

IoTopenTech
IoTopenTech

STM32WL I2C_1 and I2C_2: Unable to deep sleep

Description of defect

Using STM32WLE5C, I2C_3 is able to enter deep sleep, but I2C_1 and I2C_2 no.

Target(s) affected by this defect ?

STM32WL

Toolchain(s) (name and version) displaying this defect ?

ARM GCC

What version of Mbed-os are you using (tag or sha) ?

mbed-os-6.15.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

Mbed Studio: 1.4.3

How is this defect reproduced ?

The following code in https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/i2c_api.c for I2C_1 and I2C_2 seems to lock deepsleep

imagen

But there is no way to re-enable deepsleep (for example in a low power device that only needs to read a sensor once per hour).

This increases the power consumption in 3mA.

It would be useful to have a free or deinit method.

Dec
1
1 month ago
Activity icon
issue

IoTopenTech issue comment ARMmbed/mbed-os-example-lorawan

IoTopenTech
IoTopenTech

Can not reach low power state when radio is declared outside of main()

Description of defect

Inability to enter sleep mode (or at least reach expected sleep mode average current) after calling static LoRaWANInterface lorawan(radio); when working with NRF52840-DK + SX1262MB2xAS mbed shield

even when building with Develop profile. Results in average "sleep" current of ~6.5mA. Uncommenting all code before main() (except for above line) and removing all code except sleep_for within main() yields expected sleep current (~14uA).

Target(s) affected by this defect ?

NRF52840-DK

Toolchain(s) (name and version) displaying this defect ?

Mbed Studio 1.4.0

What version of Mbed-os are you using (tag or sha) ?

6.3.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

Mbed CLI 2

How is this defect reproduced ?

Set up 2 NRF52840 DK's: one with PowerProfilerKit, another with SX1262MB2xAS mbed shield. Connect both to PC via microUSB (not nRF USB). Have PPK DK power LoRa shield DK via External supply, switch power on LoRaDK ON, nRF ONLY switch, VEXT->nRF switch to ON. Load up nRF Connect utility for the power profiler kit application, and enable DUT power and monitoring.

Use the default example for this sketch, but remove most of the code such that all that remains looks as below:

#include <stdio.h>

#include "lorawan/LoRaWANInterface.h"
#include "lorawan/system/lorawan_data_structures.h"
#include "events/EventQueue.h"

// Application helpers
#include "SX126X_LoRaRadio.h"
SX126X_LoRaRadio radio(D11,//MOSI
                       D12,//MISO
                       D13,//SCK
                       D7,//CS/NSS
                       A0,//RESET
                       D5,//DIO1
                       D3,//BUSY
                       A1,//FREQ_SEL
                       A2,//DEV_SEL
                       A3,//XTAL_SEL
                       D8);//ANT_SW

#include "mbed.h"

//DigitalOut led1(LED1);
using namespace events;
uint8_t tx_buffer[30];
uint8_t rx_buffer[30];
#define TX_TIMER                        20000
#define MAX_NUMBER_OF_EVENTS            10
#define CONFIRMED_MSG_RETRY_COUNTER     3
#define PC_9                            0

static EventQueue ev_queue(MAX_NUMBER_OF_EVENTS *EVENTS_EVENT_SIZE);
static void lora_event_handler(lorawan_event_t event);
static lorawan_app_callbacks_t callbacks;

static LoRaWANInterface lorawan(radio);

int main()
{       
rtos::ThisThread::sleep_for(1000);
}

change the following in mbed_app.json:

"target_overrides": { "*": { "platform.stdio-convert-newlines": true, "platform.stdio-baud-rate": 115200, "platform.default-serial-baud-rate": 115200, "lora.over-the-air-activation": true, "lora.duty-cycle-on": false, "lora.phy": "US915", "lora.device-eui": "{ 0x00, 0x80, 0xA0, 0xD0, 0x09, 0xEA, 0x82, 0x37 }", "lora.application-eui": "{ 0x70, 0xB3, 0xD5, 0x7E, 0xD0, 0x03, 0xE4, 0x02 }", "lora.application-key": "{ 0xEE, 0xB6, 0x72, 0x7D, 0xEB, 0x52, 0x08, 0x1C, 0x2E, 0x32, 0xC4, 0x3B, 0xB8, 0x96, 0x86, 0x6D }", "target.components_add": ["SX126X"], "lora.app-port": 2, "lora.fsb-mask": "{0xFF00, 0x0000, 0x0000, 0x0000, 0x0002}" },

"macros": ["MBEDTLS_USER_CONFIG_FILE=\"mbedtls_lora_config.h\"", "MBED_TICKLESS=1"]

Now, compile, upload and compare the average currents when static LoRaWANInterface lorawan(radio); is commented, and uncommented. For me, results for commented are ~14uA average sleep current over 52ms period, while uncommented shows an average sleep current of approximately 6.5mA over 52ms period.

IoTopenTech
IoTopenTech

Thank you very much @evandavey Problem solved. It was probably a soldering issue.

Now I am getting 2.5uA after uplink.

Nov
30
1 month ago
Activity icon
issue

IoTopenTech issue comment ARMmbed/mbed-os-example-lorawan

IoTopenTech
IoTopenTech

Can not reach low power state when radio is declared outside of main()

Description of defect

Inability to enter sleep mode (or at least reach expected sleep mode average current) after calling static LoRaWANInterface lorawan(radio); when working with NRF52840-DK + SX1262MB2xAS mbed shield

even when building with Develop profile. Results in average "sleep" current of ~6.5mA. Uncommenting all code before main() (except for above line) and removing all code except sleep_for within main() yields expected sleep current (~14uA).

Target(s) affected by this defect ?

NRF52840-DK

Toolchain(s) (name and version) displaying this defect ?

Mbed Studio 1.4.0

What version of Mbed-os are you using (tag or sha) ?

6.3.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

Mbed CLI 2

How is this defect reproduced ?

Set up 2 NRF52840 DK's: one with PowerProfilerKit, another with SX1262MB2xAS mbed shield. Connect both to PC via microUSB (not nRF USB). Have PPK DK power LoRa shield DK via External supply, switch power on LoRaDK ON, nRF ONLY switch, VEXT->nRF switch to ON. Load up nRF Connect utility for the power profiler kit application, and enable DUT power and monitoring.

Use the default example for this sketch, but remove most of the code such that all that remains looks as below:

#include <stdio.h>

#include "lorawan/LoRaWANInterface.h"
#include "lorawan/system/lorawan_data_structures.h"
#include "events/EventQueue.h"

// Application helpers
#include "SX126X_LoRaRadio.h"
SX126X_LoRaRadio radio(D11,//MOSI
                       D12,//MISO
                       D13,//SCK
                       D7,//CS/NSS
                       A0,//RESET
                       D5,//DIO1
                       D3,//BUSY
                       A1,//FREQ_SEL
                       A2,//DEV_SEL
                       A3,//XTAL_SEL
                       D8);//ANT_SW

#include "mbed.h"

//DigitalOut led1(LED1);
using namespace events;
uint8_t tx_buffer[30];
uint8_t rx_buffer[30];
#define TX_TIMER                        20000
#define MAX_NUMBER_OF_EVENTS            10
#define CONFIRMED_MSG_RETRY_COUNTER     3
#define PC_9                            0

static EventQueue ev_queue(MAX_NUMBER_OF_EVENTS *EVENTS_EVENT_SIZE);
static void lora_event_handler(lorawan_event_t event);
static lorawan_app_callbacks_t callbacks;

static LoRaWANInterface lorawan(radio);

int main()
{       
rtos::ThisThread::sleep_for(1000);
}

change the following in mbed_app.json:

"target_overrides": { "*": { "platform.stdio-convert-newlines": true, "platform.stdio-baud-rate": 115200, "platform.default-serial-baud-rate": 115200, "lora.over-the-air-activation": true, "lora.duty-cycle-on": false, "lora.phy": "US915", "lora.device-eui": "{ 0x00, 0x80, 0xA0, 0xD0, 0x09, 0xEA, 0x82, 0x37 }", "lora.application-eui": "{ 0x70, 0xB3, 0xD5, 0x7E, 0xD0, 0x03, 0xE4, 0x02 }", "lora.application-key": "{ 0xEE, 0xB6, 0x72, 0x7D, 0xEB, 0x52, 0x08, 0x1C, 0x2E, 0x32, 0xC4, 0x3B, 0xB8, 0x96, 0x86, 0x6D }", "target.components_add": ["SX126X"], "lora.app-port": 2, "lora.fsb-mask": "{0xFF00, 0x0000, 0x0000, 0x0000, 0x0002}" },

"macros": ["MBEDTLS_USER_CONFIG_FILE=\"mbedtls_lora_config.h\"", "MBED_TICKLESS=1"]

Now, compile, upload and compare the average currents when static LoRaWANInterface lorawan(radio); is commented, and uncommented. For me, results for commented are ~14uA average sleep current over 52ms period, while uncommented shows an average sleep current of approximately 6.5mA over 52ms period.

IoTopenTech
IoTopenTech

And success! 2uA in sleep following an uplink. It does beg the question what is different about this target versus the others - newer radio driver that handles the GPIOs?

image

Dear @evandavey I'm not able to reduce power consumption below 1.5mA with a RAK3172 (STM32WLE5C), similar to E5, using mbed-os-example-lorawan

Please, could you share how to configure Mbed to get 2uA. Kind regards

Nov
22
2 months ago
Activity icon
issue

IoTopenTech issue comment ARMmbed/mbed-os

IoTopenTech
IoTopenTech

STM32WLE5: I2C unknown instance for I2C_1

Description of defect

I am building a program with two APDS9930 I2C distance sensors.

Both use the same I2C slave address, so I decided to use 2 I2C peripherals (STM32WLE5 has 3 I2C available).

I2C_2 and I2C_3 work with any of the pin configurations available, but I2C_1 always fails.

Target(s) affected by this defect ?

STM32WLE5 (RAK3172)

Toolchain(s) (name and version) displaying this defect ?

Mbed Studio

What version of Mbed-os are you using (tag or sha) ?

Mbed OS 6.15

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

Mbed Studio 1.4.3

How is this defect reproduced ?

Trying to initialize an I2C configuration for I2C_1 using any of the available pin configurations for SDA/SCL (PA_10/PA_9, PA_10/PB_6, PB_7/PA_9, or PB_7/PB_6) always fails.

imagen

IoTopenTech
IoTopenTech

Thank you very much @jeromecoutant Yes that modification solves my problem. Kind regards from Madrid.

Nov
21
2 months ago
Activity icon
issue

IoTopenTech issue ARMmbed/mbed-os

IoTopenTech
IoTopenTech

STM32WLE5: I2C unknown instance for I2C_1

Description of defect

I am building a program with two APDS9930 I2C distance sensors.

Both use the same I2C slave address, so I decided to use 2 I2C peripherals (STM32WLE5 has 3 I2C available).

I2C_2 and I2C_3 work with any of the pin configurations available.

Target(s) affected by this defect ?

STM32WLE5 (RAK3172)

Toolchain(s) (name and version) displaying this defect ?

What version of Mbed-os are you using (tag or sha) ?

Mbed OS 6.15

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

Mbed Studio 1.4.3

How is this defect reproduced ?

Trying to initialize an I2C configuration for I2C_1 using any of the available pin configurations for SDA/SCL (PA_10/PA_9, PA_10/PB_6, PB_7/PA_9, or PB_7/PB_6) always fails.

imagen

Nov
12
2 months ago
Oct
29
2 months ago
Oct
22
3 months ago