For your application I would look at a solution which contains a prebuilt and certified LoRaWAN stack like rn2484/rn2903 or RM1xx. That means the base won’t be open source, but the heavy lifting for the LoRaWAN stack has been done for you and that part of the design is something you do not need to worry about.
For the rn modules TTN released an Arduino compatible library enabling swift development.
1 Like
Arduino is ok for prototyping. However, if you plan to go commercial, at least start from a system based on a certified LoRaWAN chip (e.g., Murata or similar), not directly with radio chip + LMIC. Two names comes to mind for direct experience: Arduino MKR WAN 1310, if you need Arduino, and Onethinx.
However, I have a couple of LoRa32u4 (copies of the Feather 32u4) that run reliably for relatively long time, even if sometimes I had trouble to upload firmware through the Arduino IDE.
EDIT: I see Jac arrived first 
A few days ago a new line of arduino’s aimed at industrial usage was released. So for there’s no support for LoRa, but who knows in the future.
https://techcrunch.com/2020/01/07/arduino-launches-a-new-modular-platform-for-iot-development/
Still I think it’s an interesting approach. While they may have technically been hardened they still have the ‘arduino’ label. That label has both pro’s and con’s… and because of those in any serious company you can’t come up with something based on an arduino without being frowned upon. And in companies where it would be acceptable they would probably think these devices are too expensive compared to normal arduino’s. So I must say I’m curious what’s exactly their plan is.
Atmel Studio is free as is its compiler and, in my opinion, provides a significantly superior development environment. For a non complex node, such as the one you described, it is relatively easy to port the code to the environment and there are youtube videos that cover this. It gets more complex when you need to port multiple libraries (a more complex project). The Arduino IDE uses a bootloader in the target node to push code to the board without requiring an additional programmer (great for the hobbyist) but this is not supported in Atmel Studio 7 - instead you need to use something like a Atmel ICE (In Circuit Emulator) or a Segger J-Link adapter to program the board. So it costs a little more because you need the programmer/debugger but it is so much more powerful enabling real time debugging / tracing etc.
A variant on this option is to add the visualmicro extension to Atmel Studio 7. This enables you to import an Arduino project with minimal modification and still be able to bootloader the target using the target’s embedded Arduino bootloader.
There is also a compromise, you could use Visual Studio with an Arduino plug in. It is messy to setup initially for the SAMD21, getting intellisense setup correctly, but once you have done this you get a much better GUI giving you code complex and syntax highlighting enabling you to develop and debug faster than you can in the native Arduino IDE. It still uses the Arduino compiler and it allows you to bootload the target using the Arduino bootloader in the target but you cannot do any real time debugging that you can do with the Atmel ICE. If you are serious about developing with the SAMD class processor, the Atmel ICE is a bargain. If you are a student or associated with an educational institution the you can get the Segger Programmer for the bargain price of $20. This is fine if you are doing this as part of education studies but you are not allowed to use it for commercial projects.
You do not need a licence to use the LoRaWAN radios however the devices (gateways & nodes) still need to be certified for the country where they are being used. Incorporating a pre-certified modules helps but does not remove the requirement for the certification of the completed product.
Atmel studio is not a compiler! In actuality it uses the exact same gcc compiler that Arduino uses.
Much better to skip both, and just use that directly. In fact you can do so even if you want to use the Atmel ASF libraries.
Not true in practice. How you develop the code and how you load it are independent. The Arduino IDE doesn’t load code either, it defers it to a platform appropriate tool, and you can do the same thing with Atmel studio or any even remotely sane IDE. Or just include flashing as an operation/target in your Makefile.
Pre-certified sub-modules remove the need for intentional radiator certification, which is the complex and expensive part compared to unintentional radiator testing which applies regardless if the device is a “radio” or not.
There’s only one network provider that is on topic here, and TTN has no such requriement
Thanks @kersing.
So I can refer to this article to build my end-node. How to build your first TTN node: Arduino + RN2483
I see here that it uses Arduino IDE, I’m afraid I may see those join delays again, thus ending up with inconsistent data collection.
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.
… and it’s not matter of Arduino vs. others.
1 Like
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.
See https://github.com/mcci-catena.
Best regards,
–Terry
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.
The post is closed, so I’m posting a quick question here. Is there an integrated MCU which has RN2483 onboard?
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
Okay, why do we need to interface it with Arduino Uno/Nano then? Is for uploading the firmware? (sorry, that was a silly question).
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.
1 Like
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?
1 Like
Your question highlights the area of confusion.
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.
2 Likes