From the bits you have, I guess you want to build your own device?
Attaching a screen to a LoRaWAn device isn’t “normal” - we generally think in terms of many devices running on batteries for a long time (years) - whereas a screen turns batteries in to months, even if you have a press to display button. You could create a webpage dashboard or app for your phone to act as a display.
The DHT22 isn’t very accurate so you may want to contrast it with a BME280 - no point uplinking every 15 minutes if you don’t see any changes due to the sensitivity of the sensor.
If you know Arduino, then an Adafruit Feather M0 with RFM95 is a good start.
If you are developing your own device it is recommended that you have access to a gateways logs or at the very least, the gateway’s console so you can figure out any issues with your device build. At a minimum you’ll need a gateway somewhere nearby to receive the uplinks.
For a prototype I would suggest the TTGO boards. They can be programmed in Arduino and some of them have OLED screens.
For production use at this point I would stick to STM32. When using something like the Microchip ATSAM D1, you will need to use the LMIC library. From what I can see the STM32 CubeLoRa library is more widely used and supported.
Thanks for the reply guys! The reason for the LCD screen is because we need to calibrate the sensor every year. So low power consumption isn’t our main priority.
I did some tests with my Arduino nano 33 and the RFM95 to send some data to the TTN but i have not been very lucky with getting it connected.
I have a Gateway approx 3km from my house, would it be better to get one myself?
Yes. Any debugging questions when people don’t have a gateway drag on forever until they buy one - a TheThings Indoor Gateway is fine and under 100 (€/£/$).
3km is an academic number, you could have one 250m away and circumstances mean your device isn’t picked up, or there could be one on a hill you can see from your window 10km away that picks up the signal each and every time.
For annual calibration, why not plug in a screen, rather than have screens on each and every device (thinking of the planet here).
What would i need to do to have the screen plug and play? Just a connector to connect to the screen or do i have to change something in the code aswell?
Something in the code that checks if the screen is plugged in makes sense and initialises it and starts displaying info on the screen would be indicated.
Depends on if you are making 10 or a 1,000 really.
An on-device screen isn’t really a very good way to do calibration. To do calibration you need to expose the device to two or more humidity levels, along with some means of verifying those levels (reference meter, or realities of physical chemsitry in a closed volume, eg a supersaturated salt solution). As such you may not have good visibility of an on-device screen during calibration.
Basically, use the radio network during calibration, too. Transmit uncalibrated humidity and apply the calibration on the back end.
While much better than DHT11, for more accurate temperature and humidity readings I would not suggest a BME280, but more something like Sensirion SHT31 or similar. For outdoor use and use in moist or dusty conditions a version with protecting membrane film would be preferred.
I would also prefer a Heltec board over a TTGO board. Their support and documentation has just been proven better the last two years. If you want ESP32 based and it should be low power battery operated then have a look at Heltec Wireless Stick, Wireless Stick Lite or Wireless Shell. Other nice (and newer) boards are the Heltec CubeCell boards which are ARM based and also support Arduino.
Even nicer would be the ability to adjust calibration compensation data on the device via downlink messages. The data then comes in already calibrated without the need to maintain calibration data for each device on a server.
Exactly. The only reason to send calibration data down to the node would be if it also drives a local humidity display; but even if it does, there’s more consistency in transmitting the raw value and applying (potentially more sophisticated) compensation infrastructure side - including the ability to go back and re-evaluate past data if assumptions change.
Eg, you can transmit raw values as uplink, but also downlink calibration information that can be used to make a more crude correction to drive an on-device display.
@descartes: You are spot on with your comment whether it’s for 10 or 10.000pcs.
Also: is it a (semi)professional or industrial application?
The user-case would dictate the components to use, for both the Transceiver/mcu part and for the sensor side.
Personally I wouldn’t use an Arduino for an industrial application, but a Miromico module. They are available with STM, Renesas and Maxim microcontrollers.
Also I like the Renesas/IDT HS3001 for temperature and humidity. It’s very accurate and extremely stable over time.
Being stable would eliminate the need for an annual calibration
@LouThings I am not sure about the DHT22. We are requiring a precision of 0.4 degrees C and 2% humidity. It looks to be quite stable compared to the sensors we have installed right now. A initial calibration will tell if it is working over the range.
The calibration is mandatory for our procedures. Even if the device is extremely stable.
I am currently evaluating the Hardware we could use, it needs to be friendly priced. But also the size of the total package needs to be taken into a count.
Adafruit Feather 32u4 RFM95 (€41,95)
Arduino Nano Every with headers with RFM95 (€12,50 for arduino €8,50 for rfm95)
Arduino MKR WAN 1310 - LoRa (€39,95)
Our usecase, provided that the prototype is successful is to use it in about 100 locations. Arduino seems an easy way to go since im familiar with the code.
You should probably look at ARM based platforms not ATmega based ones. The 32u4 should be crossed right off the list due to limited memory resources, the nano every might barely survive but still doesn’t offer much advantage since the radio doesn’t share its wide voltage range.
It’s not clear that there’s currently any TTN V3 compatible codebase maintained for either of those.
More importantly, consider the initial board only a proof-of-concept since you’d probably move to placing the same processor and radio module on your own with the needed sensor.
So for example, look at the Feather M0 LoRa, but price it in terms of the constituent parts.
Arduino seems an easy way to go since im familiar with the code.
Arduino tends to make it easy to get started but then a real nightmare later since it insists on doing absolutely everything in a way that is both non-standard and truly terrible in terms of software development practice.
Fortunately there is the option of later going to a non-Arduino codebase on the same hardware.
