@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…
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!
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 ?
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
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.
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.
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 huge600 uA (vs 0.1 uA) of sleep current!
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?
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.
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.
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.
