LongReach (LoRa) mLink Module (HCMODU0250)

[andrew]

Thank you. I had missed the tabs on the examples and only seen the first one.

I suggest retaining LORA_Tx_Done with the correct meaning as deleting it would break user code.

Easily done.

Just for reference, I've now updated the Arduino library and python module. The LORA_Tx_Done() function is now deprecated and has been replaced with LORA_Tx_Busy(). The appropriate examples in the first post have been updated to reflect this.

The reason why I have done this is because simply flipping the operation of the LORA_Tx_Done() function will not be obvious to existing users and may cause much hair pulling. Removing the function will cause a compile error but will make it more obvious something has changed.

[JohnF]

Andrew

I have been able to get transmission from a LoRa device attached to my OPEN-SMART ONE to another attached to a Raspberry Pi 4 using the Python code. I had it working on Saturday and for some reason it did not start up today. It is working now.

There are some things about the operation which I do not understand. The specification document V1.02 gives information on the Long Reach Enable Register 0h17. It says there is a default value of 0h07 and that it is write only. That default value sets bit 0, which is stated to be controlling LongReach mode. Therefore the default value sets LR mode on, if the documentation is correct.

As far as I can work out, running LORA_LR_Mode writes the whole byte both in the Arduino and Python code. There is no way to find out what the byte is set to as it is write only. Attempts to read it in the Python code give me 255.

Does this make any sense to you?

John

[JohnF]

Andrew

I now have communication to a second Arduino. I notice that there is some interaction with the Arduino Serial output as the red light on the LoRa module is on most of the time.

John

[JohnF]

Andrew

Thank you.

I have just noticed your updates. The above messages from me were before getting the updates. I have now implemented the updates. The Python update is very easy. The examples are working as before.

One further thing, I think that the LongReach transmit example should have the line

while(mLink.LORA_Tx_Busy(I2C_ADD));

after each transmit. Without it I don't always get the transmission,

John

[andrew]

One further thing, I think that the LongReach transmit example should have the line

while(mLink.LORA_Tx_Busy(I2C_ADD));

after each transmit. Without it I don't always get the transmission,

Good point. Technically because the examples invoke a delay after transmitting it doesn't need that line but I guess if someone was to remove the delays it would cause problems. I've now updated the example to include it.

[JohnF]

Hi

I want to use a pair of the LoRa mLink modules to transfer information. One way to do this is to use PJON (https://github.com/gioblu/PJON). I have a library which converts PJON to LoRa using SPI rather than I2C. I can work on an I2C version. Is there any way to convert SPI output to I2C to avoid this?

John

[andrew]

I want to use a pair of the LoRa mLink modules to transfer information. One way to do this is to use PJON (https://github.com/gioblu/PJON). I have a library which converts PJON to LoRa using SPI rather than I2C. I can work on an I2C version. Is there any way to convert SPI output to I2C to avoid this?

I'm not deeply familiar with PJON, so please take this as a general observation rather than a definitive answer. From what I’ve seen in the PJON library, it’s unlikely that it can directly interface with the mLink modules out of the box. While the mLink Longreach modules do use LoRa, they aren’t just basic LoRa radios, they include a smart I2C interface that handles all the internal LoRa configuration and communication for you. This design simplifies things on the Arduino side, but it also means that PJON won’t automatically know how to communicate with them, even if you could somehow adapt SPI output to I2C.

That said, PJON seems to implement something called a custom 'strategy’ (https://github.com/gioblu/PJON/tree/mas ... strategies), which allows you to connect unsupported devices to the library. So there is a good chance you could use this feature to link the mLink library to the PJON library. It would also mean you can directly interface PJON to the mLink modules without needing some SPI to I2C adapter.