A join delay, if it happens, should only happen when you power on the node. Once the node is operational it should reuse the information it got during that join.
If you are rejoining too often you are bound to get delays because you will be reusing previously used random values of which only 65536 are available anyway before you need to program the node with new keys.
I have a node based on rn2483 operational that joined almost three years ago and is still running. Is has uplinked well over 100000 packets during that time.
Perhaps English is not your native language and you read more into my post than was intended.
I did not say it was. Note the as is its in my comment.
Actually it is specifically true in practice. In practice you install packages into the ardunio IDE these packages setup up all that is required in the Arduino environment. You cannot install these packages in Atmel Studio, instead it is up to you to do all the heavy listing to set up the environment each time you want to add or potentially update an already integrated package.
Sounds too good to be true and it is too good to be true. If you read the certification documents for the specific modules you will find comments to the effect that certification is only valid if it is the only radio in the device. This is likely true for any simple node but not so otherwise. If for example you want to add a certified LTE radio module to a gateway and put it in the same enclosure then neither certification is valid. Similarly if you add satellite module, a bluetooth module, or some other type of radio module to a node, the same is also true.
Who made you the judge of what relevant information I should share with someone looking for help?
MCCI uses the Feather M0 LoRa extensively. They work fine. The USB is quirky – if you wedge the device, you have use the double-reset trick to get it into boot mode, then change the link. Indeed, the USB is not fully compliant, but based on my experience, I think the problem is that the device is wedging in your sketch before it can bring USB up enough to engage the boot loader.
The double-reset trick: plug in the Feather, press reset twice (like double-clicking a mouse). The status LED will start blinking with a distintictive “breathing” pattern. Windows will see the device as a different COM port. Change the IDE (or VS Code, or whatever you’re using) to point at the COM port and download a known-good app like blinky. Things will be back to normal. You’ll have to change the COM port again to point at the regular one.
MCCI also makes boards using the Murata module, also on Feather form factor, using STM32L0.
We have our own BSPs for both the Feather M0 LoRa and the STM32L0 that take some of the rough edges off.
Alternatively, instead of programming the Feather M0 via the USB bootloader, the Atmel ICE could be used in the Arduino IDE to program the Feather M0 directly
That’s interesting. Do you mean to say that I’ve to regenerate random keys (and incorporate them in the code) every time I upload the code!
I’ve uploaded the same firmware many times - the total number is definitely not less than 40 times (the changes were in the TX interval to test, and portions of void do_send block whenever there are changes in my electric circuit). Out of those attempts, it got joined in some cases, but it’s not joining in the recent attempts. I think this could be a potential reason in my case, for no-join. What do I do now, is there a way out?
Another thing I’ve done is I regenerated new random keys (devEUI, appEUI) and incorporated that in the firmware and uploaded the code (again multiple times, my bad).
EDIT:
Is this what I’ve to do, to overcome the problem? But even then it’s not working.
It’s actually the other way around. The RN2483 contains both the LoRa radio module and a Microchip PIC microcontroller.
You might want to look at the Atmel SAM 34/35 which contain both an Atmel SAM 32 bit processor and the LoRa radio. There is a SAM35 Xplained Pro evaluation board
It is possible to program the PIC in the RN2483 with your own application code - but the PIC is not supported in the Arduino environment nor in the Atmel Studio environment. Instead you could download MPLAB-X IDE from Microchip and the associated compiler from Microchip (all free for commercial use) or use compilers from companies like CCS (www.ccsinfo.com)
However I would not do it that way. I use the RN2903A which is the same device as the RN2483 but supporting frequencies in the US and most other places in the world outside of Europe. They are pin compatible and have identical APIs so developing for one automatically means you are have a hardware compatible solution for the other just by changing modules. Both of these devices function conceptually like the old Haynes style modems. You send them commands and data over a serial interface and receive command responses and data over the same interface. Naturally it is not quite that simple, different frequency bands to setup, different limitations on payload sizes, time-on-air etc.
In my case I use an Arduino environment to develop applications on microcontrollers to communicate with these modules. Specifically I have use the STM32 and SAMD 32bit microcontrollers however the choice of these controllers was determined by other tasks they had to perform. Talking to the radio modules themselves is very simple. Having said that, keep in mind that I do not use any special function Arduino library functions (like software serial ports, software I2C ports, temperature / humidity drivers, PM sensor interfaces etc) instead I either write my own or I modify the libraries to achieve the performance and error handling capabilities that I need. If you want to stay with the Arduino environment, and needed a powerful 32 bit processor, then, based on my experience, the Atmel SAMD is a good option.
Apparently the feather M0 started working on its own (I didn’t do anything specific), I was able to flash the firmware. However I noticed something strange. The distance between the device (interfaced with the Solar PV) and gateway is about 300 meters. Since the feather was not working on the rooftop, I took it to the laboratory where my gateway is present. When I powered the feather, surprisingly, it got connected immediately, and the device started sending data (its junk though). Once it got connected, I took it to the rooftop hoping that it would work. But it was not communicating with the gateway.
It seems to me that range could be the issue, but its just 300 meters, and on top of that, the same feather had communicated a lot of data from the same place in the past. When I brought it back to lab, it got connected and started sending data. It seems that there are no issues so long as the device is in the vicinity of the gateway. No clue as to why was it not able to communicate when the device is taken to the rooftop…
Was just thinking if changing the hardware is really going to solve this problem! I mean to say, what additional benefit can a certified LoRa chip (with full LoRaWAN stack on board) can bring than a radio chip + LMIC. I’m sorry to ask this again and again, I’m still not clear about the difference between the two (Certified module Vs (Lora chip + LMIC)) from the view point of establishing the communication between device and gateway reliably (which was my first question in this post). Hoping to get this doubt clarified. Thanks for your understanding.
What is the construction of the building your gateway is in?
BTW, a gateway in the lab with a node at the rooftop is kind of the other way around of usual deployments. You want a gateway with a decent antenna on top of a building, not inside it, if possible.
Have you checked the antenna connection of your node?
A module could be as simple as a LoRa radio transciever supporting LoRa encoding or it could also contain a processor running the LoRaWAN stack (or similar). In your question (LoRa chip + LMIC) should more accurately be (LoRa chip + Processor + LMIC stack).
Now LMIC is a piece of software running on the processor. The user application communicates with the processor via the LMIC API. LMIC is a specific software implementation. A company that is producing their own radio + processor modules may or may not use LMIC between the the radio and the processor, that is, they could be using some other software stack on the processor to interact with the radio.
Irrespective of whether we are talking about modules that contain only LoRa radio transceivers or modules that contain a radio + processor, these are available as either certified or non certified.
The real question “Module + Embedded processor” to handle the stack, or “module plus external processor running the stack” comes down to what level of abstraction you want between your application code and the radio transceiver and how much you really want to be involved in the controlling the operation of the radio.
A module that incorporates its own stack (LMIC or otherwise) is simple to implement, and consequently, your product can have a much shorter development cycle. You typically communicate with these modules via a serial port. If there is a requirement to upgrade the software for this type of module, the update from from the manufacturer.
If you go the other way and build a solution using your own processor and LMIC (or other software stack), it is now your problem to ensure your application does not impact the operation of the radio or LoRaWAN protocol and you are responsible for ensuring the software stack is maintained.
From a cost perspective, a radio module alone, non-certified in very low quantities costs about $5 whereas a module with than embedded processor that is FCC certified is around $20 in very low quantities. As already discussed earlier in this thread, pre-certified modules can significantly reduce the cost of bringing a product to market provided your system is designed within the constrains of the certification of the respective modules.
Since it was working fine in the past (I mean since it was transmitting), I did not bother to move it outside of the building. I’ll move it outside of the building, and see if gets connected.
Upon reading your questions, I now have a doubt. I’ve set the spreading factor to SF7, and the ADR is turned off in the LMIC code which I’m using. Could this also be a reason why it’s not able to communicate?
Is there any specific test to do that? Something like S11 and S21 measurements using VNA?
Ah, it’s working after changing it to a different location (removing the distractions). I’m in the process of putting it inside the box, and moving it outside of the building.
Interesting to see this discussion, it seems like it is about “how to make end node” and it surprises me to see than no one is mentioning Semtech’s lorawan stack.
I work on making an end node myself, and it is a painful experience. Everything else is working (gateways, I use R-pi based and indoor gateways. TTN and http integration, to my own app server and in the end, a javascript map app). But I struggle with the end node.
As far as I have seen, I find only two proper ways to make an end node (software) from scratch and that is to use either the “Semtech LoRaWAN endpoint stack”, https://github.com/Lora-net/LoRaMac-node, or use mbed and start with there “LoRaWAN network interface”, https://os.mbed.com/docs/mbed-os/v5.15/apis/lorawan-api.html#lorawaninterface-class-reference.
For my project, it is difficult because I use a micro controller not supported by the Semtech stack. But for The Feather M0, it should take little effort to get the Semtech stack run, as there is already a SAM board supported. And for mbed it should work almost out of the box.
I am not to happy about mbed, it is just to big. I like Zephyr much better, it is much cleaner and easy to understand, but it have no LoRaWAN support. So now I working on two approaches: Use Semtech LoRaWAN endpoint stack on my own OS, or port the stack to Zephyr. I use the mbed alternative as a kind of reference, since it seem to work on my board (tested it first time yesterday).
There are multiple options, depending on how you define from scratch. For speed of development and easy certification you could go for one of the LoRaWAN modules that contain their own stack and interface with your controller.
If you mean you want to integrate the stack yourself, yes then you are setting yourself up for a lot more work and ‘pain’.
BTW, LMiC is a valid option for some controllers, there is a version that is actively maintained.
