Received transmissions error

Hi,

on a new gateway I’ve just set up I see received transmissions that are indicated with “error” in my gateway’s log (my hardware’s log, not on TTN.) These transmissions are all using SF7, while my own (successfully forwarded) messages are always using SF9. I can see the message type (join-request, data up/down), but apparently my gateway can’t forward them.

Are these messages genuine errors (which I need to fix), or are they just messages using another network besides TTN (which are perfectly normal to see)?

My gateway should be able receive all transmissions regardless of SF, no matter whether they are SF7 or SF9, shouldn’t it?

Regards

There’s quite a lot of detail missing here, so wild guess, they are LoRa transmissions that fail CRC - hopefully your unknown make and unknown model of gateway is saying more than ‘error’.

So, random idea, yes, it may well be devices for another network.

It’s unlikely that if it can hear SF7 & 9 that it can’t then hear the other SF’s due to the way the hardware & firmware works.

I hope not, do you not have ADR turned on? It saves bandwidth, power and puppies.

If they were - would I still be able to see the type of the message (“join”, “data” etc.)? Wouldn’t the message then be completly unreadable, including its header?

Thanks.

Well, I haven’t turned anything OFF. But I never noticed anything about my gateway or my devices even mentioning ADR. (I haven’t created my devices myself, if that was the question. I’m using off-the-shelf hardware.)

Regards

EDIT:

Oh my, of course you’re absolutely correct about the source of the errors. The “error” statement is presented in, you guessed it, the column named “CRC”. Sorry about that! :slight_smile:

But what does this mean now? Is it a reception error or a message not for TTN?

More mystery electronics, so can’t comment really, but using my :crystal_ball: I see that the majority of devices have ADR as it keeps kittens safe so it’s hard to say what’s going on.

It means that the message CRC doesn’t match what the radio heard. It could be for TTN but no one will ever know because the messages were scrambled. Things like CRC are pretty fundamental stuff to radio comms, so I’d strongly recommend you read the entire of the Learn section (linked at the top of the page) so that you’ve got the core concepts.

Do other networks use the same message header that TTN does? If my router indicates a message type of “join-request”, is this even true or is there simply a value of X at offset Y, that would indicate a “join-request” if it were destined for TTN, but since it is not, it can be anything?

Not really. They all use the LoRaWAN spec. A subtle but important distinction.

Things like the LoRaWAN spec are pretty fundamental stuff, so I’d strongly recommend you read the entire of the Learn section (linked at the top of the page) so that you’ve got the core concepts.

Please don’t take this the wrong way, but I will not do that. I will not read hundreds of pages of a specification that may or may not answer my question.

Instead, since you surely already consumed all those documents, I’d kindly ask you for some very specific information which I’m sure you have right at hand. If you can’t be bothered, I understand that and no hard feelings.

No one suggested you read the 90 pages of the spec, but you’ve asked two questions that are pre-requisites to successful implementation and I directed you to one evening’s reading that covers the fundamentals so you can make more progress faster. And even if I had directed you to read those 90 pages, it would be because they would answer your question, even I’m not that much of a dick. Look at my profile, there’s a reasonable chance I know what I’m doing, so 95% of the time I’m dishing up good stuff, the other 7% of the time it’s down to poor maths.

Please don’t take this the wrong way, but it’s all volunteers answering here who have no obligation to answer, particularly answering basic questions that can be answered via forum search or reading the Learn materials or the documentation or the specification.

If we spend our time answering the FAQ’s, we’d have no time to help those with the more interesting knotty problems that need some group thinking to solve.

And as a volunteer that learnt LoRaWAN the easy way / properly, I’m not inclined towards offering a fast food service to those that will inevitably come back to ask another question and another question. It’s not a good use of a scarce resource and it leaves you with a patchy understanding of something that is somewhat detailed.

You got an answer in the first instance with a recommendation to look at the Learn section, that’s being given the Fishing for Beginners handout, because if you give someone a fish, you feed them for a day, teach them to fish and you feed them for life. Same applies here, read the Learn section and you’ll be all set. Or not and get a version of “read the Learn section” each time.

What are reported RSSI and SNR of the packets that have CRC errors ?

My question boiled down to:

“Does a LoRa transmission (vs. a LoRaWAN transmission) necessarily have the same header as a message intended for TTN, does it even have a CRC field, or am I looking at the interpretation of random noise?”

If I failed to ask the question succinctly enough, then that’s on me and I’d appreciate the hint.

I don’t expect to find this kind of question in any tutorial. I can draw my conclusions, but I would not get the positive answer I was looking for.

That’s why I’m happy you responded to my question. I shall always defer to the advice of an expert.

Which was what I was looking for with my forum post in the first place. A RTFM doesn’t help me, even if it is from an expert.

What you could have said instead: “Are you by any chance using a Mikrotik gateway? Look in the sub-forum, that issue has been discussed before.”

Now, THAT would have been helpful (and a whole lot both quicker for you and easier for me.)

Well, that didn’t work so great, did it? Instead, you - frankly speaking - offended me by treating me like a noob. Advising me to research on CRCs was - a bit much, shall we say.

When I trouble someone by asking a question, that means that I was unable to find an answer myself. It doesn’t mean I never looked into the problem myself before that.

I really need to stress this point: I ask the question from an expert (you) because your answer would be better than what I could get from any text. I don’t ask you because it is faster.

Regards

They are low, but not that low either: RSSI in the upper nineties, SNR between -10 and -13 dBm.

I since found that it is a “speciality” of Mikrotik gateways to interpret the uninterpretable, even random noise, so it’s perfectly normal to see those errors.

Do you really expect volunteers to have a crystal ball? There are tens, if not low hundreds, of brands of gateways, all with different user interfaces and some get different user interfaces with firmware upgrades. You happen to know what hardware you are using, for us it might be anything. So basically we need to match the limited information we are given with the user interfaces we happen to know which is a guessing game.

That is not limited to mikrotik gateways, alle gateways behave that way, it is just that the user interface on those gateways makes it more visible, most gateways show this only when looking at detailed logging.

Why would you expect that we might a specific targeted (random choice of manufacturer or self build GW) question? Here we are 2 Days later we finally get a key bit of information. One of the frustrations for regular contributors and forum volunteers and moderaters is

We dont…and often end up playing a game of “20 Questions” to get the info needed to give an informed answer and one that doesnt involve refering to go read “Learn”!

An appeal to ALL potential users would be think what others might need to know to help you and over inform vs forcing a Q&A session! :slight_smile: