Well I've had a chance to try the ultrasonic Lora sensor project in the wild up here at the cottage and I'm greatly impressed!!! The data can broadcast almost a kilometre through dense northwest forest - and that's not even full power. Thanks to all who helped. But I am having one mystery. The transmitter unit at the tank reads one depth, but at the receiver(s) it's another depth - generally about 3" difference! My understanding of the program at the tank is the ultrasonic sensor reads the depth then sends it to the display on the unit. It THEN sends that same result to the receiver unit, which reads it and displays it. It appears that on the Transmitting unit the data that is sent is somehow altered before it's sent.
Here's the TX code:
// ask_transmitter.pde
// -*- mode: C++ -*-
// Simple example of how to use RadioHead to transmit messages
// with a simple ASK transmitter in a very simple way.
// Implements a simplex (one-way) transmitter with an TX-C1 module
#include<LoRa.h>
#include <SPI.h> // Not actually used but needed to compile
#include <Adafruit_GFX.h>
#include <Adafruit_PCD8544.h>
// Adafruit_PCD8544 display = Adafruit_PCD8544(SCLK, DIN, DC, CS, RST);
Adafruit_PCD8544 display = Adafruit_PCD8544(3, 4, 5, 6, A0);
#include <Ultrasonic.h>
#define TRIGGER_PIN 7 // Arduino pin tied to trigger pin on the ultrasonic sensor.
#define ECHO_PIN 8 // Arduino pin tied to echo pin on the ultrasonic sensor.
#define MAX_DISTANCE 200 // Maximum distance we want to ping for (in centimeters). Maximum sensor distance is rated at 400-500cm.
Ultrasonic ultrasonic(7,8); //Ultrasonic ultrasonic(Trig,Echo);
void setup()
{
display.begin();
Serial.begin(9600);
while (!Serial);
// use the (50) setting to change the contrast if the image is too weak or strong
display.setContrast(30);
display.clearDisplay();
Serial.println("LoRa Receiver");
if (!LoRa.begin(433E6))
{
Serial.println("Starting LoRa failed!");
while (1);
// LoRa.setTxPower(20);
}
LoRa.setSpreadingFactor(10);
LoRa.setSignalBandwidth(62.5E3);
LoRa.crc();
}
void loop()
{
delay(50); // Wait 50ms between pings (about 20 pings/sec). 29ms should be the shortest delay between pings.
Serial.print("Distance is: ");
Ultrasonic ultrasonic(7,8); //Ultrasonic ultrasonic(Trig,Echo);
Serial.print(ultrasonic.Ranging(INC));
Serial.println(" inches");
LoRa.beginPacket(); ///send packet
LoRa.print(ultrasonic.Ranging(INC));
LoRa.endPacket();
//Start the LCD display
display.clearDisplay();
//Print the data on the Nokia LCD
display.setTextSize(2);
display.setTextColor(BLACK);
display.setCursor(0, 0);
display.print((char) 25);
display.println(ultrasonic.Ranging(INC));
display.println("inches");
display.display();
delay(200);
}
and the receiver code:
#include<LoRa.h>
#include <SPI.h> // Not actually used but needed to compile
#include <Wire.h>
#include <LiquidCrystal_I2C.h>
LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE); // Set the LCD I2C address, if it's not working try 0x27.
/*-----( Declare Constants and Pin Numbers )-----*/
int ledPin = 6;
void setup()
{
{
// Serial.begin(9600);
lcd.begin(16,2); // iInit the LCD for 16 chars 2 lines
lcd.backlight(); // Turn on the backligt (try lcd.noBaklight() to turn it off)
delay(1000);
pinMode(ledPin, OUTPUT);
while (!Serial);
Serial.println("LoRa Receiver");
if (!LoRa.begin(433E6))
{
Serial.println("Starting LoRa failed!");
while (1);
}
LoRa.setSpreadingFactor(10);
LoRa.setSignalBandwidth(62.5E3);
LoRa.crc();
}
}
void loop()
{
// try to parse packet
int packetSize = LoRa.parsePacket();
if (packetSize)
{
// received a packet
// Serial.print("distance is ");
// read packet
// while (LoRa.available()) {
// Serial.print((char)LoRa.read());
// }
int targetDistance = LoRa.parseInt();
// Serial.print(targetDistance);
// Serial.print(" inches ");
// Serial.println(" ");
lcd.setCursor(0,0); //First line
lcd.print("water is down");
lcd.setCursor(0,1); //Second line
lcd.print(targetDistance);
lcd.print(" inches");
{
if (targetDistance <= 25 )
{
digitalWrite(ledPin,LOW);
}
else
{
digitalWrite(ledPin,HIGH);
}
}
}
}
The TX loop has 2 delays of 50 + 200 mS making it some 4 readings per second, not 20.
In receiver code You use this:
int packetSize = LoRa.parsePacket();
if (packetSize)
If statements uses boolean, not integer. Some compilers go for bit 0. That means that 0, 2, 4, 6, even numbers are treated as false, 1, 3, 5, odd numbers are treated as true.
Since you call the ranging code twice (once to print the range and once to send through the radio), and considering the unusual placement of the object instantiation, I suspect that you do not have a valid basis for comparing the transmitted and received results.
Try something like this instead:
Serial.print("Distance is: ");
dist = ultrasonic.Ranging(INC); //**declare correct variable type for dist
Serial.print(dist);
Serial.println(" inches");
LoRa.beginPacket(); ///send packet
LoRa.print(dist);
LoRa.endPacket();
Railroader:
If statements uses boolean, not integer. Some compilers go for bit 0. That means that 0, 2, 4, 6, even numbers are treated as false, 1, 3, 5, odd numbers are treated as true.
In C...My programing started 1973 and involves a number of different languages and sometimes different compilers within the same language. Matters like this have been compiler dependant.
It'd common that false is defined ss zero, sometimes called "nill". True has in some environments ben using only bit 0.
Why not be safe and use "if( intVar > 0)"!?
Railroader:
In C...My programing started 1973 and involves a number of different languages and sometimes different compilers within the same language. Matters like this have been compiler dependant.
It'd common that false is defined ss zero, sometimes called "nill". True has in some environments ben using only bit 0.
Why not be safe and use "if( intVar > 0)"!?
Why not bin a compiler that doesn't comply with one of the most fundamental truths (no pun intended) in K&R?
Never seen "nill" either.
Often saw
K&R stated that the result of a boolean operation (including comparison) is guaranteed as either 0 or 1, nothing else. This is fine to e.g. increment a variable by a boolean result. But a check for true/false condition simply compares the entire value to zero, not only a single bit. Some people - including compiler writers - may have misunderstood those two distinct definitions.
Remember that single bit operations require logic AND before the value can be tested, and this were against the C simplicity and speed doctrine. And how then would you test the result? Right, by a comparison to zero and a check of the zero status flag. A bit overly complicated, isn't it?
TheMemberFormerlyKnownAsAWOL:
Why not bin a compiler that doesn't comply with one of the most fundamental truths (no pun intended) in K&R?
Never seen "nill" either.
Often saw
#define FALSE (0)
#define TRUE (!FALSE)
I think "nill" was used as end of string, end-of-pointrr chain. no-pointer etc. in Pascal, the bird that didn't get very faar.
I just got home from the cottage, and see all the responses to my mismatch problem. Thank you all. I'll try them and see if they resolve the problem and report back.
Again thanks.
Jeff
Thanks for quick reply. I take it you are referring to the LoRa library? I am using Sandeepmistry's library. I'm using the Ultrasonic library for calculating the distance.
Hope this helps.
Jeff
Railroader:
The TX loop has 2 delays of 50 + 200 mS making it some 4 readings per second, not 20.
In receiver code You use this:
int packetSize = LoRa.parsePacket();
if (packetSize)
If statements uses boolean, not integer. Some compilers go for bit 0. That means that 0, 2, 4, 6, even numbers are treated as false, 1, 3, 5, odd numbers are treated as true.
That does not directly explain the issue.
A value is true if it is non-zero, a compiler that only looked at bit 0 would be not be a valid C++ compiler...
I will be setting up some test units at home (the other instillation is at the cabin to test some of the suggestions that members have kindly suggested.
A few thoughts on the problem. I originally designed the project for use with NRF24101 transmitter/receiver. The results were stable - that is the data at the transmitter side was the same as that at the receiver.
The problem was the NRF24101 didn't have enough strength to cut through the bush and trees, so I switched over the LoRa. It worked unbelievably well with a good signal for over 1km through forest!
I also switched from the traditional HC-SR04 unit to the waterproof JSN-SR04t waterproof unit. As mentioned in the first post, I now receive a different value at the receiver end as from the transmitter. A consistent 3". I also found the JSN-SR04t also is a bit more unstable the HC-SR04 in that it will throw wildly spurious values occasionally. I have considered running a filter program and/or using a 4.7k pull up resistor to see if it will improve stability. The bottom line is there are several places that may be causing the problem. Hopefully with help I'll find a simple solution.
Again thanks for the help. Looking forward to your suggstions.
Jeff