It seems that packet 4 is missing. Why ?
can you try move it further away from TTIG ?
1 Like
I move it a little bit further
{
“time”: “2019-04-06T15:25:08.960716565Z”,
“frequency”: 867.1,
“modulation”: “LORA”,
“data_rate”: “SF8BW125”,
“coding_rate”: “4/5”,
“gateways”: [
{
“gtw_id”: “eui-58a0cbfffe800301”,
“timestamp”: 110041692,
“time”: “2019-04-06T15:25:08.616035Z”,
“channel”: 0,
“rssi”: -67,
“snr”: 12.25
}
]
}
- and where is your payload (what’s the size)
- is ADR on/off ?
- lower the interval
The Payload is 37 bytes
what is ADR ( and where ) ?
what do you mean by “lower the interval” ?
- I’m not familiar with your node type/code
1 Like
Is it because of this fair access policy that my sensor is stalled after 67 packets in TTN ?
No. There must be something else wrong with you code to cause this.
My TTIG has been running uninterrupted for a couple of days receiving data from several nodes without any issue. If a reset of just the node makes things come alive again the error is on the node, not TTIG. If you need to reset TTIG as well it might be an issue with the gateway, but given the information available at this time that seems unlikely to me.
Thanks Jac, this was helpful.
I have set up another node ( again a STEVAL-STRKT01)
As it looked fine, I have also set up a third one and flash again the first one.
Now it seems that everything is OK.
At least it has been running with no problems for more than 3 hours.
which has never been the case before. I will let it run as such for a longer time to test
the devices.
1 Like
I need now to increase the range.
How do you change the coding rate (coding_rate) on the STRKT01 ?
I have already set the data_rate to the lowest possible :
“data_rate”: “SF12BW125”,
“coding_rate”: “4/5”,
To set the data rate, have a look at the “!loradr” command via USB to set the LoRa Data Rate and “?platformstatus” to double check. Restart the device after this procedure.
You can also change LORAWAN_DEFAULT_DATA_RATE in the main.c and send the “!defaultsettings” to use this new setting. Restart the device after this procedure.
To manage the Adaptive Data Rate (ADR), use the “!loraadronoff” command via USB and “?platformstatus” to double check. Restart the device after this procedure.
You can also change LORAWAN_ADR_STATE in the main.c and send the “!defaultsettings” to use this new setting. Restart the device after this procedure.
I found how to change the data rate ! ( see my post)
What I asked is how to change the coding rate .
“coding_rate”: “4/5”,
Thanks for an answer on this question.
My STEVAL-STRKT01 has been on for quite a while now, but
pressure, temp and humidity are out !
Did some one experienced the same problem ?
{
“accelerometer_4”: “map[x:-0.001 y:-0.001 z:-8.997]”,
“analog_in_5”: 4.17,
“barometric_pressure_0”: 0,
“digital_out_6”: 0,
“gps_3”: “map[altitude:79.51 latitude:48.3xxx longitude:2.5xxx]”,
“relative_humidity_2”: 0,
“temperature_1”: 0
}
Find the part of whatever unspecified code you are using that sets this, and change it. It will be somewhere in the SX12xx chip configuration, either initially or at each TX/RX switch. If you can’t find anything relevant in a case-insensitive search of the source tree, check the data sheet to learn which chip register it would get written to and look for writes to that register.
It’s likely however that this alone won’t solve your range problem. Also note that changing this will probably make your setup incompatible with TTN, and therefore not really on topic here.
I am using the code that is provided by STmicro with the
STEVAL-STRKT01 device.
This thread is about the STEVAL-STRKT01 so I thought it was clear.
I know how to search the code but before doing it, I prefer to see if the change of the coding rate was one of the options that dis available already in the STM code.
What does “probably” mean ? This is not very informative !
is it incompatible or not ? It cannot be both.
Does TTN assume 4/5 coding ?
if yes, where is it written ?
I am experimenting with the range, so it is normal to change all possible options that will affect the range.
Apparently trying to word things gently was unwise. Changing the coding rate will not work with TTN
This is because the LoRaWan regional parameters specification, on top of which TTN operates, explicitly dictates the coding rates to be used.
If you want to try alternate coding rates you will need to build your own independent system (not just nodes, but gateways and network infrastructure), and that is off-topic here.
I dont think it was more gentle. I far more prefer the clear statement that you are making now. Thanks for clarifying.
So if I want to use TTN, I will leave the 4/5 code.
Indeed, I am interested in P2P communication with very long distance. I am using TTN to understand better Lora communications, and the limitations of Lorawan and TTN.
But in the final application, I may well depart from the TTN protocol.
Hello All,
I have experimented over sometime with STEVAL-STRK01 and TTIG.
I am using the default application on the STEVAL-STRK01 module.
I notice that after sometime the sensors disconnect and all return 0.
This on several devices I have.
Probably the !powersens was turned OFF.
Does anybody know where in the code this is done, or which option can avoid this ?
Thanks
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.
1 Like