I’m using Murata’s CMWX1ZZABZ-093 module running their stock v1.1.03 AT-command modem firmware. I have an application in which I would like to send a few packets one after another periodically. I’m having trouble doing this with the AT command firmware. I’m configuring the modem to enable ADR and initially use DR0. All my packets are 9 bytes long by design. And all my testing so far is at short range, maybe 10 feet between node and TTIG Gateway. I’m in the USA using the 915MHz band.
After joining, my first AT+CTX generally works fine and I get an ACK. Then right away, my next AT+CTX give an error that my 9-byte message is too long, because I guess the MAC layer “borrows” from the available payload because of reasons. I then send one-byte AT+UTX messages every 4 seconds until the AT+MSIZE? query tells me there is enough space for my 9-byte payload again. I end up getting a bunch sequence of +EVENT=2,2 an a NOACK. If I do AT+JOIN again and get an +EVENT=1,1 and try the same AT+CTX again, it works. but this whole process takes an unacceptably loooong time to complete (over 2 minutes sometimes to send two consecutive packets successfully).
RSSI’s look good in the TTN console. What’s going on here? I don’t think it should be such a challenge to send a sequence of 9-byte packets. Feels like I’m missing something fundamental. I’m asking a question here hoping that this community might have some experience / knowledge that might help me.
I can’t tell if this is:
(a) this is normal / expected behavior,
(b) indicative of a hardware problem with my end node,
(c) a problem with the gateway
(d) a problem with the things stack
I have my TTIG instrumented with an FTDI cable so I can see the logs there but I don’t know what I’m looking for. Any help / advice on diagnostics or the fundamentals of what I’m trying to accomplish here would be greatly appreciated. Thanks in advance!
Yes, I’m familiar. That’s why I’m posting this question. It doesn’t seem like that should be a problem since I’m sending so little data. I’m in development though, and I’m basically in the country side, highly unlikely to be affecting anyone else’s RF experience. Incidentally is there somewhere that you can actually view the uptime of a given node in TTN console or something?
If we got a nickel every time someone used that excuse we would be rich. Also, keep in mind you are still are still using more than your fair share of the backend resources when uplinking too often.
Have you looked at the data stream in the end device console? It lists a lot of information. If you enable verbose mode you might even see the mac commands being send to your device so you can check what responses it should be sending and the amount of bytes those responses will take.
In the gateway console you should be able to see the data transmitted to the node and what it sends in an uplink so you can count the bytes.
Btw would you happen to have a linkt to the documentation of the at command set?
There’s this github repo that is aiming to make an open source alternative and the documentation of the AT command set I think matches pretty closely with the Murata manual: AT Command Interface · hardwario/lora-modem Wiki · GitHub
Last I tried, the firmware implements some element of duty cycle check that may not window as you expect - or at least the firmware that’s on the MKR WAN Murata module tends to do that.
But it’s a bit of a guess without knowing how far apart your “back-to-back” sends are.
Any reason they have to be split up in to 9 byte packets and not sent in one?
What do you mean by this?
Really - that is so bad practice - what will you do with all the dev nonces and puppies you’ve killed?
The module won’t know what the gateway heard, unless you are using confirmed uplinks, and even then only what the return downlink signal strength is, is this may well be rather totally irrelevant. Are you using confirmed uplinks? Oh, wait, you are, so how many is “a few packets” and how often do you do attempt this run?
It’s not. It’s just the timing that’s causing you an issue and there are many many issues related to that. But we don’t know what the gap between sends you are setting …
Erm, is this the gateway that won’t stay connected to the LNS? If so, this potentially adds an extra dimension to the failure reasons.
I’d be tempted to suggest, all things considered, that running your own TTS OS may be better overall. Fundamentally the design has so many issues but without knowing why you are sending a stream of messages & not just one and why it has to be confirmed for each one, there’s no hope of real advice other than please stop abusing TTN like this.
My back-to-back sends are like after a second, but I can change this.
I wanted to make sure all my packets fit in (what I thought was) the minimum length payload size for any DR/SF, which as I understood it, was 9 bytes.
When the AT+MLEN command indicates less than 9 bytes, I am taken to understand that’s because
the server will send some MAC commands (e,g, LinkAdrReq, DevStatus…) in a downlink after device joins successfully. Then modem sends MAC answers in an uplink (unbeknownst to my application). As such, the length of data that can be sent as a payload is (temporarily) reduced.
For now it’s literally two in a row, but I want to implement a queuing strategy, so if my node fails to send data over lorawan it can try again next cycle (e.g. 30 minutes later). So I guess my strategy would be something like, if there are buffered messages to send in memory, then in addition to sending two payloads for the “current cycle” also try and offload 2*N more buffered messages if those first two succeed. So in the most conservative implementation where I ‘flush the queue’ as slowly as possible, I would be trying to send four consecutive messages per cycle.
I’m open to taking instruction on a set of parameters that will definitely work.
Well, yes, but I’ve observed the behavior whilst connecting to a completely unrelated Multitech gateway (that I don’t have any administrative authority over).
You know you are allowed just 10 downlinks including ACKs a day? Using confirmed uplinks does not scale. Specifically if you are sending ‘a few packets one after another periodically’. Unless the period is about one day…
Right, ok… I get it, this is a limitation that will not be a concern if/when I switch to using an Enterprise license right? I don’t think I can compromise my application by allowing for unbounded data loss due to network failures.
As the module has to wait 5 seconds to listen for the Rx1 window for the Ack you have requested, this will never work …
… have you read the basics of LoRaWAN, or the spec?
You can query what DR you are on, you can tailor the packet size to suit.
But the whole design would need so much more detail to be able to comment, if so inclined to partake in free consultancy, that I can’t see this
OMG I think that answers my question above. What did you think a confirmed uplink meant?
Please read the Learn section, top right of every forum page. It is not fair to TTN and the forum if you are going to proceed to ask questions about a design that fails due to the fundamental nature of LoRaWAN and the appropriate use of the community network that is provided free of charge.
We know, if you are asking, the question is why you don’t know rather than finding out - like someone who knows he’s been found out but not going to admit it.
But even if you were on a network that allowed “unlimited” downlinks, there would still be the legal duty cycle to adhere to. But there is no bypassing the Rx1 window time to get your Ack back.
You’ll see us saying many many times on the forum, if you can’t tolerate 10% packet loss, then LoRaWAN is not the right application for you. TTI say it in the docs too.
Your gateway will still be half duplex, so unable to receive uplinks while transmitting a downlink and it need to adhere to the legal limits which makes too many confirmed uplinks a scalability issue.
As this discussion isn’t new you could search the forum and look for suggested work arounds.
You are dealing with RF. Lost uplinks are seldomly a failure between the gateway and the application, most of them are due to interference or other RF issues. If you call that network failures you’ve choose the wrong technology for your use case.
I think that answers my question above. What did you think a confirmed uplink meant?