Experiences with RFM9x and SX127x based SPI LoRa modules

@jmarcelino @LoRaTracker I’m with Jose on this one. they may have improved over time but years ago stability and quality of RF implementation, documentation and product support wasnt great and dislike attempts to hide fact its SMTC based vs some ‘special’ HopeRF version of LoRa - at least one former customer decided it was so bad they had to re-implement own version to gain some quality control & concistancy. I’m not convinced wrt CE/RED testing & compliance, but others using will need to judge for themselves and test accordingly. Obviously this is purely my opinion and experience YMMV. Fact its widely used (convenient & cheap for many) doesnt make it good so I havent touched for a long time. I still keep seeing problems and hear horror stories with occasional clients who have gone that route but eventually changed…

Also enough said: RFM95W only SF6-9?

2 Likes

I think @Jeff-UK covered most points, just inconsistent products with poor RF characteristics overall. Also doubt the CE certification I was never provided with actual lab test certificates, missing a shielding can is already a bad sign and means it would never get FCC modular certification.

The SX1276 or whatever description HopeRF uses is VERY tolerant and hides many of these flaws, but you do pay in power consumption - as soon as you turn on the radio (a factor also hidden away as most people producing these devices only look at sleep mode power consumption, not during TX/RX)

Widely used doesn’t mean much in TTN context, you also find absolutely shocking antennas being “widely used”…

So friends if you want to design a really good product I recommend staying well away from HopeRF modules. There are much better options nowadays!

2 Likes

I agree the quality is dubious but this remains the most common option if you don’t want an MCU on the module.

1 Like

NiceRF and Ebyte are doing better modules and very easy to get these days

Actually for a new design without MCU on board I’d suggest going to the SX1262 modules - a much better transceiver!

2 Likes

There are some advantages in the SX1262 for point to point applications, the ability to use the very low bandwidths and the low listen current for instance.

But TTN nodes dont spend a great deal of time on listen, and the DCDC switching power save on the SX1262 does not operate on the transmit side.

A far beter device for TTN would appear to be the SX1261, which could considerably increase battery life on nodes, but no-one seems to make a simple module using this device.

Is there an Arduino based TTN\LoRaWAN library for the SX1262 ?

What about the shielded HPDTek modules like HPD13A?

I don’t know that one sorry. For transceiver only modules I only tried Ebyte recently. But being shielded in principle is already good thing.

To be honest and looking at price I think the future are the integrated MCU SiPs like the Microchip R34, AcSIP, ASR6501 and soon the STM32 WL. I don’t bother too much with transceiver only stuff other than very specific application (like getting onto Lacuna :slight_smile:

2 Likes

The HPDTek HPD13A is a SX1276 (and RFM95W) compatible module but then shielded.
I remember having read somewhere: that it has a 4-layer PCB while RFM95W has 2-layer PCB.

The HPD13A module is used on boards like BSFrance LoRa32u4 II, TTGO LoRa32 V2.x and TTGO T-Beam.

Does it have a TCXO?

That was another missing feature with the RFM95. HopeRF added that to the RFM95TW but from what I heard (haven’t actually checked it myself) you could not control the power to TXCO on it - it would be always on wasting power.

1 Like

I don’t know.

Regarding RFM95TW and TCXO power:

Source: RocketScream blog

We have been working on the SX1276 based modules for more than 2 years now. We found out that with long range settings such as using Spreading Factor (SF) of 12 and 125 kHz of bandwidth does not work reliably with the crystal based modules. This is more apparent when long data is being sent over the channel. This is due to the tolerance of the crystal used on these modules rated at 10 ppm (advertised as such). Across wider temperature range, it will further deviate. This is the reason we used a single byte data in the test code (RadioHead library will add a few more bytes in the header of the data packet). We were lucky enough to get our hands on a TCXO based (replaces the less accurate crystal with a better 2 ppm tolerance) module (RFM95TW) made by HopeRF. Even though these TCXO based module solves the issues at high SF and small and bandwidth setting, they are not low power as it continues to run even though the radio transceiver chip is in sleep mode. This result in a huge 600 uA (vs 0.1 uA) of sleep current!

2 Likes

I am very new to LoRa and I am currently considering SX1272 or SX1262 for an application. However, I am seeing that you propose RFM95TW over SX1276 in order to have better performance under 125SF12.

What about RFM95TW vs SX1262? Would SX1262 offer better RF performance AND lower power consumption?

The ‘performance’ of the devices in the SX127x range at SF12 and bandwidth 125khz should be the same, where have you seen it reported different ?

Again RF performance should be the same.

The SX1262 will have about half the current consumption when in receive mode, but TX power consumption should be little different.

Which software library are you using, does it support the SX1262 ?

In this part I was referring to the comparison between RFM95TW and SX1276.
So, I was thinking if this also applies to SX1272, given that SX1272 and 1276 are very similar.
Indeed, judging from your response it seems that RFM95TW would be “better” than SX1272, based on bluejedi’s measurements.

In the next part I was wondering if the new SX1262 transceiver solves this issue; if this were the case, then it would be like ‘combining’ RFM95TW with lower power consumption.

They are not my measurements.

What LoRa module / chip you can use very much depends on the type of MCU and development framework you are going to use because that determines which LoRaWAN libraries will be available and if your LoRa chip of choice will be supported by them.

There is an ‘issue’ that can be cured by the use of a TCXO, and it can affect very long packets at SF12. But then TTN packets are not very long in the first place and its not compulsory to fit a TCXO to a SX126x, so it may not have one.

So if the question was can an SX127x without a TCXO out perform a SX1262 with a TCXO, then yes in some circumstances.

Outside of TTN\LoRaWAN then then the SX1262 (with TXCO) can certainly out perform a SX127x (without TCXO) since the former can be used at the very low bandwidths, but these are not used by TTn\LoRaWAN.

Thank you very much for the concise response. it is very useful!

Oh! you were referencing a blog. I missed that. Thought I was your hands-on experience.

Remember that LoRaWAN packets have a fairly high header overhead, so by the time you get to SF12 you are spending around 3/4 of a second just to encode the headers and checksum, before even trying to move a single byte of useful message data payload.

However, this also means that the issue may be moot in some places - for example SF11BW125 and SF12BW125 are not usable with US915 because the overhead would consume the entire permitted packet duration, with no data moved. In Europe the restriction has more to do with accumulated airtime, so slow packets moving actual data are possible - though still extremely expensive of opportunity.

Modtronix too: Lora modules