Hi,
I asked this question at the end of another post https://lowpowerlab.com/forum/index.php/topic,1404.0.html (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
Quote from: dave_sausages on December 01, 2015, 03:53:10 PM
<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
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?
Quote from: dave_sausages on December 01, 2015, 04:29:33 PM
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
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
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
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.
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.
I put up this page (https://lowpowerlab.com/moteino/#lora) outlining the features of LoRa radios, and a few bullets on how they are different.
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?
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.
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?
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.
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
Quote from: dave_sausages on December 09, 2015, 03:35:43 PM
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.
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.