#include <SPI.h>
#include <LoRa.h>
#define SensorPin A0
int sensorValue = -1;
void setup() {
Serial.begin(9600);
while (!Serial)
;
Serial.println("LoRa Sender Test");
// Initalize the LoRa radio on the shield.
// NB: Replace the operating frequency of your shield here.
// 915E6 for North America, 868E6 for Europe, 433E6 for Asia
if (!LoRa.begin(915E6)) {
Serial.println("Starting LoRa failed!");
while (1)
;
}
}
void loop() {
sensorValue = analogRead(SensorPin);
Serial.print("Reading is: ");
Serial.println(sensorValue);
// Transmit the LoRa packet
LoRa.beginPacket();
LoRa.print(sensorValue);
LoRa.endPacket();
delay(300);
}
The documentation for that board suggests the Arduino needs to use a UART serial protocol to talk to the LoRa device and not an SPI based one, which is what the library your using needs.
@srnet , interestingly, I tried commenting out #include <SPI.h> and the program will still compile and run. I'm new to this kind of programming and this code was all taken from the tutorial so I'm not sure why I even needed it.
Since I was able to comment it out and still run the code, could the SPI vs UART issue be a secondary issue here?
I used the orginal Dragino Lora shield which used a Semtech SX1276/SX1278 chip with the hold microcontroller communicating via SPI - lora peer-to-peer communications used the lora.h library - if LoRaWAN was required the stack had to go in the host mico
the Dragino LA66 LoRaWAN Shield is based on the LA66 LoRaWAN module which includes the LoRaWAN stack with the host microcontroller communicating over serial using AT commands
don't know if the Dragino LA66 LoRaWAN supports LoRa peer-to-peer - certainly not using the lora.h library - have a read of the AT command documentation
yes - read thru post 6
what do you wish to do? we may then be able to recommend a suitable lora module and host microcontroller, e.g. have a look at TTGO LoRa32 SX1276 OLED - it supports lora peer-to-peer using lora.h library and LoRaWAN using the TTN_esp32.h library
Honestly, I'd love to stick with my current trajectory, i.e. get the actual shield the tutorial is calling for instead of doing what I did by getting the wrong one .
Heaps and heaps of practical working example projects.
Several well established Arduino librairies.
The ability to carry out very detailed configuration of the LoRa parameters.
Whereas the 'LoRaWAN' shield has none of those advantages if your interested in point to point LoRa, and your on your own basically.
you should draw up a requirements specification for your system, e.g. sensors required, motors/actuators required, communications required, etc etc
this will determine the IO requirements and give you some idea of the microprocessors and power supplies to support them
in particular why do you require LoRa? how far apart are the nodes? what is the environment, e.g. urban, buildings, trees, hills, etc?
In this case, it's a beginner project to get my feet wet in the LoRa world. Super simple, or at least trying to be. I'm in the agricultural sector and a possible application would be to communicate from a central hub/brain to actuators semi-buried in a field to irrigate plants. Another would be to read from sensors in a green house to determine soil moisture content.
This could be urban, but mostly expecting rural, as well as in locations all around the world so hills/trees/water could play a part.
For that specific purpose, then a board with a built in LoRa module is initially much easier to work with.
However if the long term goal is remote sensors in fields or greenhouses etc, then most all boards available with built in LoRa modules are not much good, they have sleep currents that are far too high. Such sensors need a low deep sleep current to make battery operation practical.
There are ESP32s that have low deep sleep currents, but the method of achieving deep sleep halts the program and it re-starts as if reset from scratch, which makes operation via LoRaWAN (popular in remote sensor applications) significantly more complicated.
I'll add to this that our goal is to create an IoT ecosystem (eventually) with these sensors as well. Would this make a difference as far as LoRaWAN is concerned?
Update: A LoRaWAN network, or at least a "network" that spans from the end node (sensor, actuator) to a user's smart device (phone, tablet) where remote monitoring and control is implemented is certainly what we're shooting for...
LoRaWAN is really designed as a method of lots of remote sensors feeding their data through a LoRaWAN gateway into a server that has an application you use to manage the data, this server can be on the Internet so it can be accessed remotely etc.
LoRaWAN is not really intended for 'control' since its not practible to issue quick and guaranteed control commands, its just not designed that way.
Maybe you need to recruit a knowledgeable professional to design your system ?
Interesting. What would you say the learning curve is for KiCAD in designing a commercial PCB for something like this? My background currently is software development, and my company is small, so this would probably fall to me (although we do have a part-time mechanical engineer on staff).
As far as off-the-shelf modules go, would these be examples:
.
Interesting. What would you say the learning curve is for KiCAD in designing a commercial PCB for something like this? My background currently is software development, and my company is small, so this would probably fall to me (although we do have a part-time mechanical engineer on staff).
