I will regale you with my experience with the STEVAL-STRKT01. First, I have several Multitech gateways in my building, a handful of LoRa devices that are either based on the Murata part (such as the ST MB1296, along with a personal design), or based on a straight SX1276 and using the LMIC stack. I also have a couple Microchip RN2903’s on the network. I’m in the US and using TTN + the Cayenne site. All these devices work flawlessly and rarely drop a packet.
Trying to bring up the STEVAL-STRKT01 was a MAJOR pain. The serial interface was written by amateurs who apparently don’t even know the most basic thing about CR/LF handling. The reason some of you are changing the length from 29 to 28 is because SOME commands REQUIRE both CR and LF, yet other commands, like the help command, only require LF. Once you set CR+LF as the default EOL in the terminal program, it works fine.
What they don’t say ANYWHERE is that it comes set up for 868MHz. This is completely useless in the US, and cost me an hour or more before I fired up the SDR and saw where it was transmitting. That, of course, meant rebuilding the firmware as the don’t provide a pre-built binary for anything other than the EU868 band plan. Grrrr.
Rebuilding the firmware was a nightmare in itself, just like any time you have to mess with the CubeMX garbage. I’m a command like guy, I use vi and make. I’ve done hundreds of designs using this, it works on Linux, Macs, and Windows. But no, to compile ST software means loading the System Workbench page and wasting hundreds of megs of disk space. Once I finally got the project imported and finally found the setting to change to the US915 band plan in some menu buried 5 tabs deep, it won’t compile. Because someone was lazy at ST, they decided that it would be “easier” to generate the band plan frequency values on the fly and waste RAM. The US915 plan has 72 channels, and this resulted in exceeding the available memory by 640 bytes or so. I worked around this by reducing the number of channels to 18, as TTN in the US uses the second group of 8 channels. I plan to rewrite the Region_US915.c file to use constants. There’s 192K of flash in these things, but only 20K of RAM.
Once I got all that built and programmed, I was able to join the device on TTN, but after that, it moves maybe one packet. I haven’t seen any subsequent packets. Once the device joins, the channel mask should be set, and it will only be using the second group of 8 channels. At this point, I need to add some code to display the frequency that it’s on, and see if it’s on frequency via the SDR.
I bought three of these to play with and I am EXTREMELY disappointed with ST. I have several dozen ST eval boards, sensor kits, etc, and none of them have ever given me as much trouble as this thing. I suspect the reason they haven’t shipped US915 code is because they can’t make it compile.
FWIW it’s worth, if you know about the STM32CubeExpansion_LRWAN_V1.2.1 package, that’s the version this is using. 1.2.0 has some definite issues, but 1.2.1 is pretty solid. This tells me it’s either an RF chain issue, or there’s an interaction with their low power management functions. I’ve moved tens of thousands of packets using 1.2.1 and it works.
That’s where I am with this right now. I’ll mess with it some more in the next few days, and hopefully find a way to get it transmitting reliably. Just know that if you’re having problems with these things, you are not alone. ST did a really poor job supporting some really cool hardware.