Hello, I have two modules E32 868T20D & E32 868T30D, they both seem to have the Semtech SX1276 chips but no LoRaWAN capabilities? Anyone had any luck connecting it to a gateway?
A few people have asked, no-one seems to have managed it.
Looking at the manual, it does seem unlikely.
I have found some code, however it seems to be point to point.
I also tried simply using the usual lmic library and defining only the rxtx pins, didn’t work either.
Basically to use this you would have to figure out how to reprogram the internal MCU and make it take requests over the serial line to operate the radio - either low lever requests, or implement the LoRaWAN stack on the module the way Microchip, Murata, etc often do and expose high level operations via an AT command set or similar.
Looked at an internal photo in the FCC test report and wasn’t seeing a familiar MCU there, it may be something minimal chosen for cost reasons. Even if the MCU were identified and reprogrammable it would be a complex project.
Here is my very old code for E32-868T20D and E32-868T30D (both are equally designed but second one have amplifier transistor):
Both OTAA and ADR modes are supported.
Some weather sensors - are supported: bme280, bmp280 and bmp180.
Also analogue data is sent (battery voltage). and state of UART pins (if UART is disabled).
Data is packed by cayenne lpp which is umpacks automatically by TTN.
DevEUI is auto-generated from device’s unique ID value.
Pulling down M0 triggers UART-based configuration UI.
More info on github. Please note that project is frozen as-is, because STM8 have low-precision clock (HSI clock) which is hard to count exactly specific time intervals as well as receiving acknowledgement at exact reception window.
Unfortunately, this code appears to be drastically out of date, missing many critical LMiC bug fixes that have happened since you forked it, and as a result really should not be used on TTN given the likelihood of failing to make proper response to configuration commands from the network.
Can You point to bugs fixes? Or at leaser show best supported codebase for LMIC. Because original LMIC - is unchanged during 5 years. And my fork - is 3 years old with fixes for coarse timing represented in STM8L with HSI oscillator. I’ll happily add protocol fixes for that, since that sensors still works pretty fine after 3
years and don’t require any service.
OFFTOP: My gateways is still works in TTN v2 and is visible on map. The main issue with TTN - is that it can’t be trusted for a long-term use, because it’s always change something and I’m unsure that my self-powered LoraWan weather sensor will not disappear someday because someone decided to change few bits in protocol.
TTN made breaking changes after running V2 for 5 years and they provided migration tools for uninterupted use of the nodes and a migration window of 9 months. So I think your judgement could be a bit more nuanced. And you could have used half an hour during those 9 months to move your gateway to V3…
Maybe safer then that you deploy your own network server and own Lora network then you are in control and ‘someone’ can affect you.
And apart from minor configuration knobs that an insistent person can still set the old way, breaking changes in terms of device firmware were mostly that device firmware needs to now actually meet the LoRaWAN spec…
If the OP wants to come up with something that works on the STM8, they should start with a current checkout of MCCI LMIC that there’s effort being made to bring into spec compliance (which the IBM and previous versions never remotely had), review the open issues on that, and then begin their port.
Another approach could be to use a different codebase, for example LoRaMAC Node.
1 Like