I'm hoping to be shown sample code to send an acknowledgement from a "receiving" Arduino with LoRa, back to the "sending" Arduino, to confirm receipt. These radios use the AT command set. Sending from (T)ransmit to (R)eceive works fine. Sending from the R Arduino to T works fine with stand along programming. I cannot make it work when it sends a transmission (AT+SEND...), is received, and then the receiver transmits an acknowledgement. I only see OK on the original T radio, response to AT+SEND but I never see the acknowledgement from the original R radio.
Perhaps there is a timing issue, or a need to reset to "receive" right after AT+SEND... but I cannot get it to work.
I moved your topic to an appropriate forum category @ptmii.
In the future, please take some time to pick the forum category that best suits the subject of your topic. There is an "About the _____ category" topic at the top of each category that explains its purpose.
Yes, plus YouTube videos. I've used these to make one Arduino a transmitter and one a receiver. Works great. I can reverse the functions, so I know each Arduing - Radio combination works for both transmit and receive. What I can't find, hence my request on this forum, was whether anyone has a sketch which transmits to the receiver, then the receiver turns around and transmits an acknowledgement to the sender. After receiving the acknowledgement, the sender will send the next information after waiting for the 1% usage limit to expire. But when I incorporate transmit then receive, or receive then transmit in one sketch, the acknowledgement is not received by the original sender.
Thank you for your follow up question. I'm thinking I may use a third Arduino / radio combination to determine whether the acknowledgement is not getting sent, or is being sent but not received. Unfortunately I do not have a third LoRa radio on the 915 US band.
There are a few of these UART front ended LoRa devices and they all seem to use different control protocols.
Whilst they might intially seem to be simple to use, there is a notable lack of examples and libraries.
The SPI based LoRa modules might well need a couple more IO pins but there are quite a few libraries and heaps of examples that would probably do exactly what you want. Send and ack functions are common too.
what host microcontroller are you planning to use?
take care many LoRa modules use 3.3V logic which require level shifters when used with 5V logic micros such as UNO and Mega
As @horace has pointed out take care to match the 'LoRa Module' to the Arduino.
The bare Semtech LoRa devices are 3.3V logic level and its best you use them with 3.3V logic level Arduinos.
There are alledged logic level conversion fixes, but whilst I have been using LoRa devices since circa 2015, I have never used them with 5V logic level Arduinos, so cannot comment on how reliable the fixes are.
I did use a couple of resistors to make a voltage divider. 5v to 3.3 v. That part works fine. I'm struggling because each LoRa radio transmits to the other perfectly with stand alone sketches. When I combine "acknowledge after receipt", i.e. transmit after receive, that acknowledgement is not received. When I figure it out I'm certain to feel embarrassed. Thank you. [Voltage Divider from Tx on Uno to LoRa Rx. R1,100Ω pin 3 board to radio pin, plus R2, 200Ω radio Rx pin to ground. Formula: 3.3 = 5 * 200/(100+200). Appears to work fine as a level shifter.] 3.3v pin Arduino to Vcc on the radio.
I did use a couple of resistors to make a voltage divider. 5v to 3.3 v. That part works fine. I'm struggling because each LoRa radio transmits to the other perfectly with stand alone sketches. When I combine "acknowledge after receipt", i.e. transmit after receive, that acknowledgement is not received. When I figure it out I'm certain to feel embarrassed. Thank you. [Voltage Divider from Tx on Uno to LoRa Rx. R1,100Ω pin 3 board to radio pin, plus R2, 200Ω radio Rx pin to ground.
Formula: 3.3 = 5 * 200/(100+200). Appears to work fine as a level shifter.] 3.3v pin Arduino to Vcc on the radio. Tx pin on Uno is reported to be 5 v.
Arduino Uno. Correct about code. I wasn't asking for debugging help. I hoped someone had a sketch doing transmit, acknowledge, receiving acknowledgement already. I thought that with a working code example I'd have a better shot.
I've been able to isolate my issue to timing and the LoRa's serial buffer. I don't have a complete grasp of my incorrect approach yet, but I believe I'll get there.
Thank you and all the others who've made suggestions. Perhaps someone who has done this already will read my post. I'm also ordering the more "robust" radios from Adafruit to try those.
your are probably not going to find exactly what you are looking for with the module you are using
there may be similar, e.g. seeed-lora/Grove-LoRa-E5-P2P-Example which uses serial to communicate with the LoRa module
what would you do if an acknowledgement is not received within a set time ? retransmit? implement a sliding-window-protocol?
do you have several transmitting devices? if so how can you be sure transmissions do not corrupt each other - to avoid this I use polling e.g. polling example using LoRa.h library which uses a SPI LoRa module
A sincere thank you to you and the others who've taken time to share knowledge and information.
This application involves sending a reading from a digital water meter, for a private water system unattended in the cold months of NY's Adirondacks. It allows checking for any leaks, or adjustment of the chlorination if one of the families uses their camp in the winter. I have been using WiFi but it's a long way to our camp so I'm trying this LoRa. Only one sender, twice per day, with one receiver.
I've completed the project with way too much trial and error. As in "don't quit your day job" even though I'm retired. I still don't understand what is happening entirely. I've found that when I transmit to an address from a radio with a different address, the "from" radio still sends an "OK" response from its serial port for each transmission. So I was stepping on my own acknowledgements from the receiver. My sketches aren't pretty. They would not win any competitions on this forum. However, the solution works. I send the meter reading five times in a loop. The receiver is reading the radio's serial signal in an endless loop with 1/4 second delays. I've found that it must be listening continuously. The radio does not "store" the last received signal. Once the receiver gets the meter reading, it breaks from the loop and sends a serialized acknowledgement ten times. The meter sending unit waits in a loop for up to a minute with millis timing. Once it receives the acknowledgment it goes back to waiting for a meter read in the next period (morning, evening). I suspect it is inefficient to be listening for activity on the receiving LoRa radio all the time, but it works. I built in a code in the meter reading string so I can reject any incoming transmissions not meant for my project. It has the added advantage of being rural, with no humans or IOT devices emanating RF in the winter. So far, with an uptime of one day, it picks up the meter reading on the first, second or third transmission. It has never failed to get the acknowledgement in five tries.
I have the project sending a reading every 1/2 hour while I'm on site. I'll switch it to twice per day once I leave.
So many thanks and much appreciation to all who took time to share ideas.
what is the distance between transmitter and receiver?
I would look at using a 3.3V Microcontroller module with an onboard LoRa device - removes the problem of different logic levels and jumper wires which are a source of poor connections and intermittent faults.
e.g.ttgo-lora32, Adafruit Feather 32u4 LoRa, TTGO-Beam, Hiltec LoRa 32, The Things UNO, etc