I went ahead and bought 2x E22900M30S from Ebyte (SX1262) and with the library from @LoRaTracker I was able to make a successful connection between the two.
Incited by the success of my first Lora project I ordered the TTIG 868 gateway, and here comes the problem: nothing goes through. When starting the gateway, green steady LED on my eui-58a0cbfffe801d6e My console says connected and after some time the status changes to not connected.
Received messages is 0. I don’t have other Lora devices than the SX1262.
So my question is: Is the SX1262 to “new” and not compatible in some way, or do I miss someting?
Totally new here. Any help Is highly appreciated.
You need quite different software when using LoRaWAN to a gateway, than you do when doing point-to-point raw LoRa between simple devices.
In terms of hardware compatibility, there’s some difference in how the LoRa packet pre-amble should be set for SX1262 vs older devices in order to achieve the same result on-air. If it mismatches in theory no packets would be seen, though in practice occasional packets with the wrong preamble do tend to get through.
The main thing though is that you’ve provided no information on the software used when attempting to interact with the LoRaWAN gateway, so the most likely cause of failure is that you are either not using LoRaWAN software to operate the SX1262, or using LoRaWAN software with gross configuration (frequencies, etc) which mismatches your region and gateway.
OK, let me be more specific, the Arduino library is from @LoRaTracker
Hardware: ESP32 WeMos
I selected this library because it’s supporting SPI bus
In the Settings.h file:
//LoRa Modem Parameters
const uint32_t Frequency = 868300000; //frequency of transmissions in hertz
const uint32_t Offset = 0; //offset frequency for calibration purposes
const uint8_t Bandwidth = LORA_BW_125; //LoRa bandwidth
const uint8_t SpreadingFactor = LORA_SF7; //LoRa spreading factor
const uint8_t CodeRate = LORA_CR_4_5; //LoRa coding rate
const uint8_t Optimisation = LDRO_AUTO; //low data rate optimisation setting, normally set to auto
const int8_t TXpower = 10; //LoRa transmit power in dBm
BasicMac is a spinoff from LMIC, not LoRaMac-node.
@matthijskooijman’s Arduino port of BasicMac supports SX1262.
It is as far as I’m aware currently the only generic public LoRaWAN Arduino library that supports SX1262.
(Generic here means not bound to a specific hardware platform, in contrast to e.g. Heltec’s CubeCell Arduino support which only works with CubeCell ASR650x (SiP with ARM MCU + SX1262) modules.)
(Semtech unfortunately ceased further development of BasicMac)
It is hard to understand why Semtech would stop development of generic Arduino libraries for official Semtech chips or derived modules like the E22900M30S from Ebyte. Can anyone explain me why? These modules are ok, very affordable, low power…
“stop” would imply there was ever such a project. Was there? The statement above is that they ceased work on BasicMac itself, not the 3rd party Arduino port of BasicMac.
Not surprising at all. Arduino is an extremely goofy and non-standard approach to software, actively hostile to good software engineering practices. Supporting Arduino (for something with as complex an interplay with the processor as a LoRaWAN stack) would largely mean having to do everything twice, as the Arduino versions would be rejected out of hand in most product settings.
Take a look at something like Arduino-ified LMiC and start evaluating all the work you’d need to do to make it build instead in a normal embedded way (been there, done that…)
Anyway, there’s a link in the thread to an sx1262 LMiC derivative that claims it has some sort of script that will munge its file organization sufficiently to work with Arduino. It also points out that the various LMiC derivatives have diverged - which is somewhat understating things. There turn out to be insufficiencies in how LMiC tried to implement LoRaWAN, and different people have different opinions on the architectural changes appropriate to enable fixing those. I suspect the linked repo doesn’t have (and equivalent to) some of the bug fixes that others do.
Semtech has not ever developed a (public) Arduino LoRaWAN library yet.
The BasicMac Arduino version was ported to the Arduino framework by @matthijskooijman (with support from LacunaSpace), one of the the main contributors who also ported IBM’s LMiC to the Arduino platform which is still a great success and is used by many people (and forks are now further maintained by others).
Why Semtech has ceased further support for BasicMac has not been made clear, but could have different reasons (commercial, political, technical and possibly because of other new developments).
As alternative, for new designs Semtech recommends using their LoRaMAC-node library.
But unfortunately there is no public generic LoRaMac-node implementation available for the Arduino framework.
What’s your point? Above statements are not contributing to the contents of this thread in any way whatsoever. If they don’t contribute then don’t.
Your views appear to be from a commericial embedded software developer. Many TTN/LoRaWAN users are not and do not have the skills, tools and education of a commercial embedded software developer. These people use technologies like the Arduino framework because it requires lower skill level, is supported for many hardware platforms, supports cross platform development, is free and open source and has wide community support.
While from software engineering theory and practices perspective the Arduino framework may not be the best platform; from accessibility perspective, ease of use, cross platform support and availability of many software libraries and examples it is still the platform of choice for many.
Someone was surprised that Semtech doesn’t publish Arduino code. I explained that they do not because that would not meet the needs of their professional customers. It goes without saying that the monetarily significant market for LoRa chips is in commercial products running professionally developed firmware, not hobbyist projects.
The unfixed bugs in BasicMac vs other LMiC branches come from the readme of BasicMac itself in the context of knowledge of the kinds of bug fixes and architectural changes to work around design deficiencies that have gone on in other LMiC repos.
In terms of practical advice, while it looks like BasicMac is an Arduino-ified LMiC supporting the sx1262, it’s probably better for less experienced users to stick to sx127x/RFM9x as supported by the more active Arduino LMiCs and within the knowledge of more community members who can serve as resources, unless one is in a position to do some serious comparative archaeology on the evolution of LMiC internals and start to update BasicMac to catch up.
I think there is no such “black-white” division between “professional commercial developers” and “hobbyists”. There is definitely a grey area, e.g. education, citizen science communities, entry market or self built nodes where Arduino may be a valid option (even if you can argue about considering that ‘serious’)
That would still not be where Semtech is making their money.
Most of the volume of chip sales goes on in settings where someone designs something and then there are tens to hundreds of thousands of copies of that same exact hardware and firmware running. They really want the node chip to be in your washing machine and the gateway chip in your neighbor’s cable box.
Where it’s easy to do so, chip companies do sometimes target some support at the hobby-crossover market sometimes including some Arduino code, as that’s good for exposure. But this isn’t a circumstance where it’s “easy” - as a curious fact, even Arduino’s own LoRaWAN product the MKRWAN-1300 does not run an Arduino-code LoRaWAN stack but rather has a conventional sort of firmware for that which performs operations on behalf of the user Arduino sketch running on the application MCU. You can get an Arduino-based LMiC and mostly applicable Arduino BSP for the Murata radio/mcu module on the board, but from MCCI rather than Arduino.
