Wisblock Sensors - Radio.IrqProcess();

Hi @makahernandez, @beegee and @carlrowan,

In the WisBlock Solution examples, in the void loop() has only a call for the function Radio.IrqProcess().

As WisBlock has other boards I would like to split the Radio.IrqProcess(), to be able mix differents boards, for example:

  1. Core: to control the processes and transmit/receive by LoRa Radio
  2. RAK1906: Get environments measurements
  3. RAK1903: Get light presence

I found in the header file radio.h, void “(*IrqProcess)(void)”, as member of “struct Radio_s”, but I didn´t find where the functions call for LoRa and BME680.

I couldn´t find the function Radio.IrqProcess() to rewrite it in small pieces to control when the MCU will do LoRa operations, Environment operations and Light operations. I already read the documentation about it, but I didn´t find the answer there, too:

I am creating small libraries, each one with the code for one kind of board. This way, it will be easier to share with other people in my team, what part of the code is doint what :slight_smile:

Today I am spending a lot of time to track where is the part of the code that it does what I need in a specific timeline.

I am since yesterday looking for the functions call.

Could you help me?

Regards,

Cláudio

I’m seeing Radio.IrqProcess() get translated to:
src/radio/sx126x/radio.cpp: RadioIrqProcess()

at least when stepping in via debugger.

You are correct and I was looking for manually a object called Raio.IrqProcess and I forgot that I could work with the debugger to track it. I was not paying attention that in the radio.h, the declaration is extern “c”. This fact change the way that I was seeing…

I need to study more C++ to understand what it is being expected when the declaration is “extern “c””.

Radio.IrqProcess should not be “cracked down” into smaller pieces.
It checks if a LoRaWAN event has happened (DIO1 IRQ was set), checks which event has happened and calls library internal callbacks for RX, TX done, CRC error, … When using LoRaWAN, these callbacks are handled by the LoRaWAN MAC, the application should not interfere with here. You might break timings (like RX1 window, RX2 window, join timeouts), if you change something here.

The examples are intentional kept simple, to just explain how to use a module. Of course it makes sense in a “real” application to split sensor readings, LoRa handling, BLE handling into separate tasks that run independent, triggered by events or timer controlled. We show this in the Low Power example. And I use tasks as well in the RAK4631-LoRa-BLE-Config example code.

@beegee

My intention is to be able to change the way that different sensors information can be sent by LoRa Radio. I mean, if in WisBlock we can mix different type of boards, how to add information about each sensor if I don´t know where/when in the code?

I mean, In the loop, I only have on call Radio.IrqProcess. How/Where/When could I add some sensor information ?

I cannot answer the “WHEN”, it depends how often you need to read your sensors.
WHERE” is simple. If you look into our solutions, for example the Intelligent Agriculture you can see that you put the sensor data into the structure that is given as a parameter to lmh_send() function.
HOW” depends on how you want to send the data. Usually the sensor data is broken down into single bytes and then copied into the structure that represents the send data buffer. But some applications just send the data as a “readable” string. Again you, as the developer, decides how you want to send the data. It might be as well that your “Integration” (service that receives the data from the LoRaWAN server) requires a pre-defined format (Like Cayenne).
Before you can answer the “HOW” you need to know what you want to do with your sensor data and who (which application/integration/…) receives the data.

@beegee ,

I know that you are working hard in these WisBlock codes. Well, please let me know if you need any help, I am working on them too. I can work in the documentation and code.

I am trying to make them as a building blocks, plug-and-play. I am trying to split the code in one library for each board, sensor or IO. This way, it will be easier to a new IoT user “just” add a library and some functions calls to make a mix of boards mounted in the base board, and make them happen :slight_smile:

Let me use the Environment Solution Code, as a example below. The LoRa Radio is a way to send Environment information to the system. I understand that it should be better if a BME680 function code get the environment information and then it call the LoRa to send the information, but today we have a LoRa Function the call a BME680 function. It could seens that the order make no difference, but it does for who is trying to learn what is the code purpose.

Well I am here to try to learn and help in what I can :slight_smile:

The environment information is gotten by function “bme680_get()” in the middle of function to send LoRa packet

Blockquote
void send_lora_frame(void)

void send_lora_frame(void)
{
if (lmh_join_status_get() != LMH_SET)
{
//Not joined, try again later
return;
}
bme680_get();

lmh_error_status error = lmh_send(&m_lora_app_data, gCurrentConfirm);
if (error == LMH_SUCCESS)
{
	count++;
	Serial.printf("lmh_send ok count %d\n", count);
}
else
{
	count_fail++;
	Serial.printf("lmh_send fail count %d\n", count_fail);
}

}

Blockquote

Hi Leroy,

I was ask to my C++ teacher and he explained to me this about the “extern “c””

Blockquote

The extern “C” command tells your C ++ compiler that functions with the extern keyword should not undergo the process of changing from name to unique name. As well?

The C ++ language allows the same function names or so-called function overload. But during compilation, the C ++ compiler changes function names to unique names to avoid conflicts. Type XXY_ etc. It turns out that the C language does not allow functions with the same names and if the C ++ compiler changes the name you will not be able to call the C function because it will have changed its name

Thus, extern “C” tells the C ++ compiler not to perform this name change process and keep the original name of the C function so that your C ++ code can call this external function developed in C language and in another .c or dll file .

Blockquote

Now everything is clear to me about what you saw in the debbuger :slight_smile: . It is a C code, I mean it isn´t C++, and the extern “C” is saying to compiler that the “old C” code will be used the way it is :slight_smile:

Thank you by your support.

Regards,

Cláudio