I would like to know if connection scheme for HM-TRLR-S with the RPi3 (Raspberry Pi 3B) was made correctly (used UART on RPi). I have connected the 5V pins and the GND on the devices. I have connected TX of LoRa to RX of Pi and TX of Pi to RX of LoRa. I did not connect the NC pins. The serial device is ttyAMA0 (serial0) on the RPi3. I don’t get the data transmitted at all (the config jumper on LoRa device was removed for transmitting data). The LEDs on the LoRa device do not glow. On the oscilloscope it was seen that the data is transmitted from the UART of the RPi3, but the HM-TRLR-S does not seem to respond.
I had tried sending data through the HM-TRLR-PCconfig software and it works perfectly (micro USB interface). I sent data from one LoRa device and other one received it and vice versa. However the RPi3’s connection with LoRa device through UART does not seem to work.
I have kept the baud rate as 115200, no parity, Payload data length as 32 bytes, SF 12, SBW 125KHz, Code rate as 4/5 and with CRC enabled. I have disabled HFSS. (Please see the image below)…
Can you please suggest some solution for this connection problem ?
I suggest to thinking about RX TX …Maybe if you change wires it will work.
(Think for this: Tx is the talker. But…what aspect from?)
I also have a question maybe you can help. My HM-TRLR-S does not work via USB at all. It is suspicious me on my version the FTDI chip is not soldered on the board… (!) Would you please take a look on your board and see if right side just over the UART connector there is a chip soldered on your board?
seems to be the FTDI chip is missing…(!) Is that possible???
Thanks for your reply. Generally for using the UART the TX RX wires should be connected in the opposite fashion on the target board. I have checked this working by connecting one RPi3 to another and it worked.
The LoRa modules have not worked over UART yet !
Regarding your board, I guess your FTDI chip is missing like you said. My board does have the FTDI chip glued and soldered already.
This RX-TX connection is a bit messed thing…
Generally say you are right. We “used to” use them like Rx to TX and TX to Rx BUT…
Take a look an the “nature” of device what you are connecting to.
Lets talk about the radio first.
Radio is to send any info from its input to other radio via air. Also it is to receive other radio’s signal and send out the info over its demodulator output to your endpoint device.
In our case the radio has two port pins RX and TX.
TX is “talk”, RX is “receive”. If you want to send a series of bytes over the radio to another one which port would you use like the input of radio (input this case is the series of bytes what you want to send over the air) RX? No. RX is for the received info, what radio received from the air from another radio) So on RX port you will get what somebody else sent to you. Shortly RX is the output of your radio.
If you want to send out that byte series, you want to “talk” over the air, so the input point of the radio is the TX pin. (the bytes put to TX pin will be send over the air by the radio.)
Well the radio “input” is TX and the radio output is RX (from this aspect.)
If you agree up to this time then let’s take a look on your endpoint device (e.g. RPI3)
It function is to process data comming/receives from other devices via its input pin. This pin is called RX, To this pin we should wire the point of radio which “received” the information (with other words for that pin where info is comming out from the radio) Which is that pin of radio? TX? Not. it is the RX pin of the radio.
So you can see in this special case (because the “nature” of the two devices you are wireing together are different) you must wire RPI3 RX pin to radio RX pin!
Let’s look the TX.
The other function of your RPI3 device is to generated any information (series of bytes) then send it to the radio which will send that information via air to another radio/user.
Whic pin is RPI3 where bytes commin out? RX? No. (Rx is an input not output in this case) Bytes comming out from RPI3 on pin TX. Because of this RPI3 TX pin should be wired to radio’s TX pin too. !!!
Think over it!
with simple words:
in case of serial communication between devices we must wire 1st dev input to 2nd device output and 1st device output to 2nd device input.
in our case:
TX = input
therefore should wire TX to TX and RX to RX even it sounds weird.
take a try. Nothing will go wrong in your devices.
If you have an oscolliscope you can easily check out what I said.
In fact more attention should take to the function of pins than as they are named.
Thanks for the information. Actually that is exactly how it had worked. Tx to Tx and Rx to Rx.
I don’t know why Drotek have not had this information documented. In the first place there was no clear documentation at all. Such misnomers could damage the boards if connected incorrectly .
same here, i have a couple of those HM-TRLR-S (not using w/RPi but wanna use them directly wired to a pixhawk and a PC to get LR telemetry). Cannot even configure them with the win app (“read fail”, “write fail”). Is there a clear step-by-step guide to do so? Or at least some advice?
Thx a lot
Use the HM-TRLR-PCconfig software. Whenever you would like to write or read the flash, plug the jumper in the hardware. Use the correct baud rate and the COM-port number, open the device at the selected baud and COM-port. Then select your settings from the software and give write. It should display write success. You can then use test to see your results. In the test tab, if you would like to check transmission to multiple units, then remove the jumper and send some message. The LEDs on the hardware should blink. If you have a corresponding HM-TRLR connected as a receiver you will be able to see the message on the window of the receiver. Always remember to use the jumper while configuring and to remove the jumper while using for data transmission/reception…
Thanks Hari for the advice. I tried with jumber and i was able to configure my lora pair.
I tried to configure them in GSK modulation and 57600 baud rate, then tried to connect (px4 1.8.0):
from mission planner: only a red blink on one of the two modules once i click on “connect” then nothing
from QgroundControl: they slowly blink in sync once a second, one green other red. No communication and no veichle connection.