Is multitasking possible? and LoRa differences?

[dave_sausages]

Hi,

I asked this question at the end of another post https://lowpowerlab.com/forum/index.php/topic,1404.0.html

But as it was part of a post about a different topic, I don't think people will see it and reply. Plus it should help out other newbies. So here goes:

Is it possible to multitask with a Moteino when sending and receiving data? For example if I want to receive a data packet that takes 100ms, can I also flash an led during that 100ms, or will I have to wait until the data receiving has finished? My project needs to receive gps streams, look for button presses and also send and receive LoRa data. But for the sake of this post, the LED example seems easiest.

And what are the differences between the LoRa RFM95 libraries/uses and RFM69 ones? I'm asking because most replies to my LoRa questions are met with a solution used on RFM69. So at what point will RFM69 solutions not work for my LoRa modules?

Many thanks, and apologies if this has been asked before, but I couldn't find the answer in the forum.

Dave

[TomWS]

<snip>

Is it possible to multitask with a Moteino when sending and receiving data? For example if I want to receive a data packet that takes 100ms, can I also flash an led during that 100ms, or will I have to wait until the data receiving has finished? My project needs to receive gps streams, look for button presses and also send and receive LoRa data. But for the sake of this post, the LED example seems easiest.
<snip>

Leaving the LoRa part of your post to those who care... I'll take a stab at the first part:

YES! Easy peasy!

Think of the Arduino loop() as exactly that, a continuously self looping function in which you can maintain and service SW timers, handle volatile bool flags set by Interrupt Handlers, read I/O pins, etc.  At each stage in the progression through the loop you provide a segment defining a 'task'.  Each task gets executed if the 'if' condition for the task is met and gets bypassed if it doesn't.

What you cannot do is use resources that are being consumed by another task.  So, if you have one task servicing the radio, don't run one that yells "Hi Mom!" over the airwaves with another.

Make sense?

Tom

[dave_sausages]

Are you saying that if for instance I request the arduino to send a packet that takes 100ms, the program only stays on that instruction for one clock cycle (give or take), before moving onto to the next say 'turn led on instruction'? I would have thought that without specific programming, the program would stay on the 'send packet' line for 100ms before moving on? Or does the RFM69 library automatically do its sending and receiving in the background? Is it documented what background resources are used when sending and receiving?

[TomWS]

Are you saying that if for instance I request the arduino to send a packet that takes 100ms, the program only stays on that instruction for one clock cycle (give or take), before moving onto to the next say 'turn led on instruction'? I would have thought that without specific programming, the program would stay on the 'send packet' line for 100ms before moving on? Or does the RFM69 library automatically do its sending and receiving in the background? Is it documented what background resources are used when sending and receiving?

It depends.  If you use sendWithRetry() the method stays in a loop waiting for the acknowledgement and then returns.  If you do just a send() without acknowledgement, then as soon as the last byte is written to the TX buffer, the function returns to the caller so you can handle the blinkin' LED.  You do have to know what the libraries do and how they do it if you're going to get optimum utilization of your system.

Tom

[dave_sausages]

So you're saying that the LoRa module has it's own buffer? And that if you just use a send() command, once the buffer has accepted the data ( takes 18ms for example), then the Moteino moves past the send() function and will for instance blink the led while the LoRa sends out the data over 43ms in the background.

like this: (time going from left to right, text length indicates time taken. Moteino starts blinking led at 22ms, Lora is sending data from 22ms to 65ms)

                               10ms          20ms         30ms        40ms       50ms       60ms       70ms

Moteino------------send() data----led on---led off---led on---led off---led on---led off---led on---led off
Lora----------------recv     data---sending data all this time completely on its own------------------------


                               10ms          20ms         30ms        40ms       50ms       60ms       70ms      80ms       90ms

Moteino------------send with retry() data-------------------------------------------------------ack rcv---led on---led off---led on---led off---
Lora----------------recv                    data---sending data all this time completely on its own---ack rcv------------------------


I hope my crude 'drawing' helps. And many thanks

[TomWS]

As I said in my earlier post, I have no experience or interest in LoRa.  I was referring to the behavior of the base RFM69 library.

Tom

[Felix]

The LoRa radios work in a similar way to the RFM69, however they do not have hardware encryption. They do have a packet engine an internal buffers.

[dave_sausages]

In what ways are they different? So far I've found that the radio power levels use different numbers and scales. Well at least I think I've found that.

At some point I'm going to start playing around with using another moteino as a repeater node and obviously using rfm69 examples will be a lot easier. Hence why knowing the differences between rfm69 and Lora libraries is useful to me.

[Felix]

I put up this page outlining the features of LoRa radios, and a few bullets on how they are different.

[dave_sausages]

All I can find on that page is that they are based on the "radiohead" library but with "nessesary changes". Are these changes documented anywhere? And what library was it that they were adapted from?

[Felix]

Yes it's explained on that page. I made some changes to make it easy to compile RadioHead for Moteino in the Arduino IDE, nothing really significant. The link to RadioHead with my mods is on that page also.

[dave_sausages]

So the actual mods done by you are purely to allow it to work with the IDE? And every function of the RFM69 library can be used with the LoRa?

[Felix]

Yes my changes are simply for supporting Moteino and MoteinoMEGA.
The RFM95 library is different than RFM69, their APIs are different also. Treat them as apples and oranges.
EAch has a set of examples that you can follow to achieve sending/receiving.

[dave_sausages]

Maybe I'm missing something, but am I now back to asking what the actual differences are, and what RFM69 functions can't be used?

My question from Decemeber still seems valid

All I can find on that page is that they are based on the "radiohead" library but with "nessesary changes". Are these changes documented anywhere? And what library was it that they were adapted from?

I'm just wondering where these actual differences are detailed. Otherwise I can't follow the standard advice of using the RFM69 example sketches given by many people including Felix.

[Felix]

Ok so RFM69 is my own creation, and is the mainstream library for Moteinos that come with any RFM69 radio.
RFM96 is part of the RadioHead library, is a 3rd party library, and I had to fork it and make a few changes (not documented, just some low level stuff, if you really want to see the changes you may do a diff) so that you can use it seamlessly with Moteino/MEGA with LoRa radios. That's all.
You cannot use the RFM69 lib with LoRa radios or RFM95 with RFM69. However RadioHead does have a RFM69 subset.
Hope that helps.