Rather than use the Dragino sensor which you may get to work on a single channel using AT commands, I suggest you use an Arduino with a LORA shield and connect a water level sensor. It will happily pass data to a second Arduino/LORA several hundred metres away. I’ve done it and it works well.
Welcome to the forum.
It’s OK to redirect someone to a non-LoRaWAN solution, please be aware that this TTI funded forum is for TTN/TTI LoRaWAN discussions only.
Hey there, I recently purchased “Waveshare SX1262 LoRa HAT for Raspberry Pi 868MHz Frequency Band”. I have the Dragino DLOS8N Gateway. Can I send data to the gateway using this LoRa Hat and Raspberry Pi? Can anyone please suggest possible ways to use this board?
Thanks In Advance
The basic version is LoRa (Proprietary) only and doesnt support LoRaWAN so will depend on which specific module you have bought
see e.g. yellow banner under picture here:
Also from another page:
SX1262 868M LoRa HAT
SX1262 868M LoRa HAT
Instruction
- This product is a Raspberry Pi expansion board based on SX1268/SX1262 chip, a wireless serial port module with LoRa modulation function.
- With multi-level relay to achieve ultra-long-distance communication, low power consumption wake-up communication, encrypted transmission, etc.
- This product uses a private protocol and does not support LoRaWAN.
…Even though they go on to discuss both LoRa & LoRaWAN further down the page - potentially confusing!
Their ‘HAT’ version supporting LoRaWAN is apparently actually one for use with the RPi Pico not a standard Pi :
1 Like
Thanks for your reply @Jeff-UK.
So, I can’t send data to the gateway using these modules mounted on Raspberry Pi 4? By using Pico, I can send data to the gateway! What could be the possible reasons? And are there any other modules available to use as nodes mounted on Raspberry Pi to send data to the gateway?
Not looked in details but think the Pi versions are LoRa only……you need to run a LoRaWAN stack - with somewhat deterministic/hard real-time behaviour hence need an embedded MCU for that rather than the general purpose/Linux base of the PI, but no doubt someone will correct me (not a Softie!). The PiCo of course is based on the RP2040 embedded mcu and I believe there are now LoRaWAN stack ports from various sources which therefore enables a LoRaWAN and not ‘just’ a LoRa node.
There are a number of Pi HATS in the market……these tend to be based on LoRaWAN modules ……running their own internal stacks on separate mcu inside, that typically communicate with Pi over UART/serial and often have +at like commands. (GIYF)
1 Like
Please do not share pictures that we can see online. Or at least, ensure we can read the writing on the important bits - zoomed in and left to right - volunteers don’t have time to download, rotate & zoom and it’s a multiplicative effort - you do it once or it ends up being down half a dozen times by other people - this does actually contribute to global warming.
But also, why post them at all when you already know that they don’t work with LoRaWAN?
You’ve already been told this. And it says on the vendors website.
Where did you get that idea from? If the Pi can’t send LW, why should the Pico, a much smaller & less capable MCU be able to send? And how do you intend to wire it up?
As @Jeff-UK suggests, a LoRaWAN stack on a Pi is tricky, which is why you don’t see much of it around. And to that end, you’ve been told that that HAT isn’t going to work with LW.
Please start a new topic telling us:
- What you want to achieve - not the full details, just an overview
- What you are familiar with - Pi, Arduino, ESP32, radio systems, programming languages, soldering skills etc
- What resources you have you’d like to use
And provide some indication of prior research in terms of ensuring you have read the Learn section on this website and that any particular products that you can get locally.
And then we can make recommendations of what will work which will be so so much easier.
Please also be aware that we don’t do student homework here, your job is to learn how learn, learn how to ask questions and learn how to research & evaluate. That’s what happens when you get a job, better to learn now than get a roasting at your desk.
@descartes Thanks for enlightening me on so many issues by spending your time. I will keep your suggestions in mind.
Thank you @Jeff-UK and @descartes.
I’m building an IoT-based weather station using a Raspberry Pi and sensors. I need to send data to the cloud via a LoRaWAN Gateway since there’s no internet access on site. I’ve used Arduino-based LoRa nodes with a Dragino Gateway successfully.
Does it have to be a Pi that is doing the sensor collection?
Because as outlined above, it is one of the harder platforms to implement a stack on. If it has to be a Pi, then you could use an AT-command driven module on a HAT - like the PiSupply RAK811 which is the last thing I used to do that which will take care of any timing issues critical for LoRaWAN whilst you do the sensing.
Otherwise there are sooooo many Arduino based boards that can do LoRaWAN it would be simpler for you to suggest options based on your local suppliers in India.
1 Like
I have a bunch of LHT65N-E5 that I want to use as loggers, at least for now (LoRaWAN use is planned for later)
I made a script to synchronize their timestamp with my computer’s clock, set them to ABP (AT+NJM=0) so that they don’t need a network, and set the recording interval to 3600000ms (AT+TDC=3600000). I checked that all the settings and clocks are correctly set, and they are.
Yet, after I activated all my devices at the same time with a long press on the ACT button until it blinked, I noticed that some of them get delayed in their recordings. They didn’t blink 60 min later, but 65 to 95 min later. Some of them, on the other hand, correctly woke up 60 min later and made their record as planned.
I checked timestamp, TDC and NJM settings again, and they are correct for all devices, late ones included.
Any ideas? A lower frequency would make delays non-issues, but unfortunately I cannot afford wakes more often than once per hour battery-wise, therefore such delays are signifcant issues for comparison purposes.
You may strike lucky and someone knows the answer, but please be aware that this forum is primarily for LoRaWAN & TTN/TTI, not so much for general product support of something that could be used for LoRaWAN but isn’t. That is to say that we are great at LW, individual product features not so much.
So you may want to reach out to Dragino as well.
Thanks for your answer. Yup, no worries, I am fully aware this may not be the best place to have a robust answer on a specific device, but it was worth asking anyway since this thread is quite general and may gather many Dragino users. At worst, it may still be useful to others to know that there might be clock/wake issues with some LHT65N, or at least undocumented behaviour.
In the end, I tried something else: deactivating all devices (5 short presses), and then re-activating them all again. I sampled a few of my devices this morning and they seem to have correctly respected the wake schedule now; hope it is true for all devices (they’re gone on the field already, couldn’t wait); else I will know at the end of the season.
If this indeed worked for all devices, I still find it weird that stopping them with a deep sleep (5 short presses) beforehand would be the key, as some of the devices did not need that in the first place, and “overriding” an ongoing mission with a new activation (long press) was enough to set a new wake schedule, but hey. I’ll try to remember updating this post in case some of the devices turn out to be out of sync again at the end of the season.
1 Like
Are you trying to run all you devices synchronous?
Do you understand that your gateway can communicate with one node at a time (downlink)?
Do you understand that they aren’t using the LoRaWAN element of this by just Tx’ing on ABP to no gateway at all?
Do you understand they want to use LoRaWAN in the future?
Apparently not until winter and even if something sends an uplink, there was no mention of all of them needing a downlink.
The OP has already said they are sorted but wants to provide additional feedback. Perhaps we can defer complicating their life until it becomes necessary.
1 Like
I want them to sample data synchronously, but when I’ll use LoRaWAN (not now), (1) they won’t be all in the same place and will therefore use several distinct gateways (even if it won’t be one node per gateway, of course), and (2) I would be happy with just logging the data and sending them asynchronously (which the LHT65N can do, if I’m not mistaken). If (2) is not possible, then just logging will be fine.
There even used to be a AT+RTP command that allowed decoupling data sampling and data transmission, to transmit several data measurements at once for instance, but it appears that this command doesn’t work on my devices. I assume their firmware was updated and the command no longer is supported, but the Dragino documentation is a bit flaky.