Hi!
I have purchased several RFM95W-868S2 from digi-key, SOS electronics and TME. When I test them, only Spreading Factor 6-9 works, and not 10-12. I can see in the data-sheet that RFM97W only supports SF6-9. Does that mean that all chips are RFM97W now? I used to have a lora dragino with RF95 that worked with SF6-12, so I’m very confused.
What is wrong?
So you bought a RFM95W-868S2 from Digi-Key, they did not work at SF10-12, so what did they say when you complained ?
I do note that the RFM9x data sheet that Digi-Key link to is a masterpiece of confusion, I quote;
> The RFM97 offers bandwidth options ranging from 7.8 kHz to 500 kHz with spreading factors ranging from 6 to 12, and covering all available frequency bands. The RFM97 offers the same bandwidth and frequency band options with spreading factors from 6 to 9. The RFM98 offers bandwidths and spreading factor options, but only covers the lower UHF bands
I bought 10-30pcs from each provider at different dates this year and they all behave the same. So can’t be random. I just wrote to HOPERF to see what they say.
But does it work for you? Where did you buy it?
So enabling lowDataRateOptimization fixed it, however SF=10 is still not working for some reason…
Sorry ?
Setting the low data rate optimisation has always been required when the symbol time is > 16ms and thats nothing to do with Hope.
I got so fed up trying to remember to set it when needed I added the required calculation to my library software.
At 125 KHz bandwidth that would only be for SF11 and SF12. It doesn’t explain SF10.
Also its unclear if these are working for downlink, where it wouldn’t apply at any supported SF.
The thing is that for SF10 the data is still being received by the gateway, but after the first 4-5 bytes the data is corrupted (CRC_OK). Very strange
So your saying the CRC error flag is not set but the packet is corrupted ?
Exactly, and it only happens when I set SF=10.
Corruption later in the packet is a symptom of the low data rate optimisation flag not being set when needed and the higher the transmit power the sooner in the packet the corruption occurs.
There is no CRC_OK flag as such in the SX1276, so its possible the packet is being sent without CRC enabled and the receiver assumes the received packet does have a CRC set.
I thought the only people manufacturing the LoRa RF IC was Semtech, if so then its difficult to see how Hope could mangle just SF10 by the inappropriate connection of some passive RF components.
No it does not explain the problem with SF10, but then the issue shifts to standard RFM95s not working on SF10 for some reason.
Unless Hope are using non-Semtech LoRa devices, is that even possible ?
A terrible thought just occured to me (no direct knowledge so feel free to dismiss as speculation and potential fake-news!)
Each SF step requires a step up in supporting memory for the mod/demod dsp fn (It may be ~2x per but cant be sure). Obviously this gets very large at higher SF’s - one of the reasons why SF beyond 12 likely not supported though possible from maths perspective (SF13/14?) as die size increase renders device uneconomic vs delivered benefit (halving bit rate/doubling on air time and barely 2db step coding gain)? Similarly there is a min on chip infrastructure for LoRa related mod/demo beyond basic RF circuitry and ability to support ‘legacy’ modulation schemes (FSK/GFSK etc.) hence if you have to pay for that in die area then might as well have a min SF supported - initially SF7 - to get benefit from LoRa phy layer. With improved process tech benefitting the logic elements/dsp fn and memory area sizing this then allows newer devices like SX126x series where the LoRa infrastructure cost in reduced hence SF5 & 6 support becomes economic.
Now to SX127x - yes only SMTC build (yet), but what about yield and how to deal with drop outs in test… might it be that memory block tests fail for larger memories supporting SF10?/SF11 & SF12…but device still tests good for SF(6)7-9? Allows for use of previosuly useless chips that would normally bin-out hence much lower cost…and it may be that some devices at the margin support higher SF’s under specific Vcc or Temp conditions but fail across spec.
I repeat no direct knowledge but 30+ years experience of Far East (particularly) semi supply chain and back end test & packaging infrastructure has shown a number of instances of drop-out abuse or even creative use of bin-outs by semi-oem’s! Could also explain Hope device remarking vs SMTC part #'s
Add in use of poorer spec Xtals vs TCXO’s only supporting lower SF’s before drift kills CRC etc. poor RF path implementation etc. and you can see how things can develop! 
Like I say a terrible thought and speculation can be very damaging and dangerous but may help explain some things observed over the years @jmarcelino
As you say @LoRaTracker
I’m not sure I share your certainty on that. It’s possibly true, it’s also possible that the recognizer just runs with a slower clock, but I think even if not it would still be a relatively small amount of memory - it’s not like it is looking at IQ samples for a whole packet, just a symbol and maybe half of each adjacent one.
That said, if there actually is a hardware difference of the actual silicon I’d join you in considering performance binnning at test to be a likely suspect.
My main suspect however would remain software misconfiguration. If you have a setup which works with one module and not another, that would perhaps point to something.
It might be worth doing a test with a node-class radio as receiver so that you could read out the frequency error.
I’ve mostly not been using radios in RFM95 format but have one board re-wired to one (sourced I believe also from digikey), you’re making me a little tempted to dig it out and see if it works, but not sure after a lot of focus on the CMWX1ZZABZ that the code of my main project still builds for the MCU connections of the one-off RFM95 lash-up.
I understand the point about far East suppliers, but if Hope were up to no good, they would be a very clear target for Semtech to attack. Hope have been rebadging devices for years, RFM22 and RFM69 for instance so if they had been engaging in dubious practices for years you would have expected to hear about the court battles.
So I would assume that Hope were using genuine, full spec, Semtech parts.
If the RFM97’s specification says it only does SF 6 through 9, that’s not really being “up to no good” if the part actually is that, though it’s still unclear how it got that way.
Anyway, I just verified the transmit path on my RFM95 works at SF10, albeit only tried across my desk.
I suspect the real issue here is some register getting the wrong setting.
Indeed not, but the OP was suggesting that Hopes RFM95 parts could be RFM97Ws as they were unable to do SF10, SF11 and SF12.
Untill when they were configured correctly and worked at SF11 and SF12. So the OP had RFM95s after all.
Complete non story really.
HOPERF confirmed that RFM97 was never released, so it doesn’t exist.
So the reason behind why I can’t get SF10 to work properly(corrupted packages) is either due to bad hardware or bad configuration. I use radioHead library so it’s strange…
So you only use LoRa, but not LoRaWAN?
This is the TTN support forum, and the radioHead library is not a TTN compatible library.
Some of what you are reporting could be down to a flaw in the radioHead library, which is not really anything to do with TTN.
Indeed. I also have my strong suspicions that there’s very little effort being made to wade through the extensive fine print of the data sheet, outside of LoRaWAN (or comparable proprietary) network contexts.