I’m a new member of TTN and a newbie of LoRa/LoRaWan.
I’m currently looking for a microcontroller and a module LoRa using LoRaWan for my thermal array sensors to build about 20-50 nodes and 1 gateway . That will be awesome if the suggested hardware has a lot of examples and LoRaWan library for being ease of coding . I see there are many examples with arduino, but in production do we have to rewrite the firmware again?
Now, I am looking at STM32 kit dev which support LoRaWan such as P-NUCLEO-LRWAN2. Do you think it is a right choice? Could you please share me your experience?
I’m seeking for a solution that help me programming quickly, not only in prototype but also in production.
yes! The project is to develop a people counter which will be installed in the building (radius of 500m ). So I would like to use SF7/ SF8. I hope that each node could send a message (like how many people passed under the sensor) per minute (ideally per second but I know it impossible). I can modify data rate to adapt to the requirements of LoRa if necessary.
Sending once a minute is on the unusually often side for TTN beyond initial experiments, though at SF7 or iSF8 it wouldn’t be too bad. It’s within realm of reason for private networks in most jurisdictions.
I do think it would be worth comparing a solution with ESP32 boards running on WiFi though.
As for the ST kit, after a bit of research I’m afraid it gets a “dis-recommend” because the gateway is not very suitable for anything more than lab experiments. One issue is that it’s a non-standard embedded sort of design where any behavior changes would be a bit painful. The greater one though is that they left off the transmit amplifier, so it has a maximum output of 6 dBm, well weaker than even nodes. TTN is an “uplink mostly” network, but critically relies on gateways being able to get key OTAA and ADR responses back to nodes it can hear, and a weak gateway can’t really do that. Worse, because TTN shares gateways between all users, the inability to get a message back to a node at distance could negatively impact other users, not just you.
If you are doing the programming, what are your strengths, do you have any prior experience with any embedded systems, the STM32 dev kit is one of many potential solutions, what made you mention that instead of any of another 10+ common platforms?
How quickly do you need a first working version (assuming there will be a number of prototypes along the way, at least two). What do you perceive are the differences between programming for prototypes & for production?
When you say you would like to use SF7/8, have you checked if the building will allow that or can you modify the building to allow that. What if you have to use SF10?
When you say product, do you mean a bespoke solution for a single building, or are you developing a solution for all circular 500m buildings?
Does this project have a requirements document that’s problem focused, not technical solution focused, because @cslorabox’s suggest of ESP32 on WiFi is almost a no brainer for a 500m radius but you seem to have pre-selected the technical requirements.
I realise I’m being a bit pointed, but making a recommendation for a LoRa based solution that is easy to code - which countless numbers of questions on here indicate that many many people have to re-evaluate their definition of easy - for a ‘product’ implying a level of serviceability that goes beyond a self-managed collection of devices is fraught with too many gotchas without knowing a boat load more details!
Hello Descartes,
I really appreciate your time and sorry for my stupid questions.
I will try to answer all your questions:
I’m just a fresher with a specialisation in image processing. I had a few experiences with Arduino, Raspberry Pi when I did some small projects in university but this one is my first real embedded project. The reason I told about STM32 because my friend suggested me it. I’m open to anothers also.
I hope to have a first version in 3 months. I have already made a prototype with a raspberry pi and my sensor, coding in Python. I will re-code in C for the kit dev and the PCB. I hope that my code for kit dev will be the same for the PCB.
(What if you have to use SF10?) I have no choice, so I will find a way to send less message from the node.
My project is for a single building!
There are not many requirements: we just cannot use ethernet cable to connect with sensors, the wireless is a MUST, and we have to build our communication system, cannot not use the Wifi system at client building. If possible, we hope to send data more frequently. That’s all. Before, I though I have to develop both of transceiver and gateway, so I mentionned the kit of STM above. But I realized that I should develop only the transceiver, and buy a ready gateway on the market. That would save my time.
definitely buy a ‘proper’ gateway for the first project - building your own using for example mPCIe gateway cards on a rPi is possible but a bit of work.
think about how your gateway will communicate up to the backend cloud - wifi? ethernet? 4G?
for the device, might be worth looking at the PyCom LoPy board https://pycom.io/product/lopy4/
as this will let you code in python and is pretty solid for LoRa comms too!
if you really want to go for a standard firmware route, the STM32 MCUs are (IMHO) a good choice. Reasonable software support and good ecosystem.
use a embedded OS with tools - this will help get an operational project asap. I’ve been using the Apache MyNewt project for a while and it has support for a few STM32 boards.There are also open source libs for embedded apps that might help with structuring your app…
There are no stupid questions, just grumpy old engineers answering!
So no puppies will be harmed if you don’t ship a working product and as student project I hope you are evaluated more on the journey than the end result. If you can consider some of the points above, it will add some substance / reality to the above. If it has to be wireless but no WiFi, then there are other radio chips available that are less restricted to consider like the NRF24L01 - which is what we’d do in evaluating potential solutions before evaluating the most likely candidate.
As for a recommendation, now is not the time for you to learn a whole new eco-system - which is exactly the sort of mess people like to indulge in for real projects that then ship late. So stick with Arduino based systems. And in that respect, again, plenty to do, either go for a larger Arduino with a SAMD and run the LMIC LoRaWAN stack on it (if you like some pain) or go pain free and use a LoRaWAN serial module like the RAK4200 or RN2483 where the LoRaWAN components are all done for you.
And absolutely do not try to make your own gateway in the sense of buying a board as you may as well buy a complete solution - a RAK7246 entry level developer Pi based gateway will give you something you can see what’s going on at gateway level which is pretty essential for developing.
You’ll probably be fine for data rates, but again, as a commercial product, at the technical solution evaluation stage, I’d go to the building with a couple of devices setup on peer to peer mode to do a quick survey - taking my NRF devices at the exact same time - all the while wondering if I should just stick in my own WiFi router
From open plan\space with thin walls to lots of small rooms with thick walls and steel floors and ceilings. Could be massive differences in coverage.
Before you can start to plan the hardware you really do need to carry out some tests in the building, you really do need to know what are the fastest data rate LoRa settings that will work in your building.
Your saying that sending data once a minute would be enough, but it would likley be a mistake to plan to that minute. Surely as soon as the system is in place there will be pressure to ‘improve’ the send rate or amount of data sent, and that brings the risk of exceeding TTN fair access limits and\or make it illegal to operate.
You just cannot plan the project until you carry out a site survey, fortunately that is not difficult, you just need a couple of Arduino or similar boards with LoRa modules, no Gateway needed for a survey.
Grasshopper development board uses a Murata CMWX1ZZABZ-078 module (STM32L082 + SX1276), open-source design, programmable using the Arduino IDE via USB connector, has many examples of use, and is easy to program and use as well as sleeping at 2.1 uA…
The query was for “LoRaWAN hardware easy to code…”. What is easier than C++ over USB?
Quantify “easy to program an use”?
Not sure this can be quantified. But if someone can learn to blink an led using the Arduino IDE then it should be easy to copy example Arduino sketches, change the keys, and Tx LoRaWAN using the device. Certainly programming with the Arduino IDE via USB is easier than programming using ST’s CUBE MX and an ST LINK debugger! And the user won’t be frustrated by the leaky, gappy ST HAL since the underlying L0 system layer is robust and efficient.
Typical run time current with LoRaWAN Tx every ten minutes is <40 uA. The point of the sleep current quote is that low power is properly handled in hardware (e.g., LDO Iq is 500 nA) and software.
BBC micro:bit over USB? That uses Blocky, drag & drop for the win.
I think the jump from getting an Arduino to blink the LED to configuring a LoRaWAN interface and coding for sensors is a bit of a wider gap than you think, stick around for a few days and help answer some of the questions. And it still doesn’t matter that sleep is properly handled - the OP needs his MCU on all the time to count people.
I sort of understand what you mean, but there no private gateways - there are gateways which you can connect to a network - which could be private, aka closed, or could be a community one like TTN. The gateways themselves don’t know (or care).
Like this:
Or a Dragino LPS8.
Very low cost options include the TTIG which you can modify to get access to the serial port & add an external antenna.
However, the TTIG is also the only gateway that is only suitable for the community network and cannot be connected to private stacks.
Since this has already been asked, it should be mentioned.
And with sources for the pygate now available (if untried by the community), TTIG is also the only frequently encountered gateway that is fundamentally closed source with no apparent path to building and running key components from source.
I would like to point out another option without evaluating any of those already mentioned or finding them not good. For some projects the time was rather even shorter and I made good experiences with Microchip RN2483. The chip is very sociable and can be connected very well via UART to a MCU. In connection with a C-optimized MCU (e.g. PIC18F27Q43) sensors (analog as well as digital) can be addressed very easily. The creation of the firmware in C is very close to ANSI C99 with the XC8. The development environment and the compiler are freely available (a later purchase of a single workstation license is recommended).
To get very fast into development the development environment from Microchip DV164140-1 or DV164140-2 helps, depending on the region you are in. The soureccode for the mote is freely available and brings you very quickly into your project. The gateway comes with its own network (Docker image with mySQL database and LoRaServer) or you can register the gateway directly with TTN. You can find instructions in the TTN.
As stated at the beginning, this remains an option you might want to look into. Should the impression have arisen … no, I do not work at Microchip.
