Trouble registering Browan TBHH100

End Devices (Nodes)
1

I’m helping a friend set up sensors for monitoring environmental conditions inside a depot. He ordered a set of browan nodes, at least one TBHV100 and a couple of TBHH100. These devices come each individually wrapped with a piece of paper with the dev eui, join eui and app key.

We first registered the TBHV100 and it did indeed join the network and is now sending data.
We also tried the TBHH100, set up the same way, but wouldn’t join (MIC error IIRC). Tried a couple more TBHH100 nodes, none of them will join. We registered them by selecting them from the lorawan device repository, which does things like setting the correct payload decoder etc.

What could we be doing wrong?
At first I thought that maybe we entered the dev eui, app eui, or app key wrong, double checked, triple checked, quadruple checked it, I even did a OCR of the piece of paper with google reverse image search to make really sure I typed it correctly. Verified that the piece of paper was matching the device id on the sensor, verified that the join data at the gateway matched the dev eui / app eui.

At this point I’m thinking that the code on the piece of paper must be wrong/incorrect. We’re contacting our seller. This is just super annoying and at the moment I really cannot recommend anyone to get any of these sensors.

Has anyone else experienced something like this?
image

And if so, have you resolved it? And if so, how?

image
image1233×946 124 KB

2

Possibly

Whilst it works Automagically when it does work, because of the huge number of variants of devices in the market, h/w versions, firmware versions, etc. you can sometimes find that the specific device in your hand isnt a 100% match to what is coded in the repository… it all depends how dilligent and thorough the vendors are in populating the data base (often they dont go back to cover old ones or may be slow to update for new ones, or could be gaps where there were rapid changes to either f/w or h/w :man_shrugging: ). If you have isses often best/easiest option is use manual registration… assuming details provided are correct of course :wink: Try it and see how you get on…

3

For whatever reason, it looks like the NS knows it has got this device in its database but there is an issue passing the data over to the Join Server to get things started.

Given the issue with console device registration that occurred Thursday, this may be a side effect.

1 Like
4

On the contrary. Registered several devices manufactured by them without any issues.

5

i have experienced before where the node are to close to the gateway, then the rssi is to high then it won’t join, what is the distance between the node and gateway

to high rssi causes channel bleed

6

Thanks for all the replies.

The RSSI is indeed rather high (I’ve seen -36 dBm for a failing join request). I can imagine this can result in problems like receiving the join request on the wrong channel and possibly the gateway responding on the wrong channel too, with the device missing the join response. I think we’ll try to get the RSSI down (e.g. reorient gateway antenna, and/or put more distance between gateway/device).

At least we managed to get the TBHV100 sensor working (the first one we configured). The failing nodes were all TBHH100. We’re in contact with the seller now. I’ll post an update later.

7

Progress so far (or lack thereof …) and things we’ve tried:

  • Moved the devices a bit farther from the gateway, RSSI is now about -55 dBm
  • Asked the seller for help, got the advice to remove batteries for 24h and try again. Batteries were plugged back in today, JOIN is still rejected.
  • Pressed the ‘reset device nonces’ button in the TTN console

I have a log of all incoming traffic of our gateway since last night, will review that tonight. For example, check if join nonces were reset or not after taking out the batteries for 24h, take another look at the RSSI. Re-re-re-re-check join EUI and device EUIs.

I’m starting to wonder perhaps we’re suffering from something like this Xerox scanners/photocopiers randomly alter numbers in scanned documents [D. Kriesel]

Or perhaps the TTN backend is still acting wonky, possibly related to

8

IIRC some of these devices (all?) have supercaps and I found a year or two back on a couple of devices that pulling for ~24hrs wasnt enough - I resorted to removing battery and discharging through a low’ish value resistor (:thinking: think it was high tens/low hundred ohm IIRC) for several seconds finished the job and allowed full reset/restart… might be worth a try?! :wink:

9

I see two series of join attempts. Two attempts at each spreading factor, starting at SF7, then switching to the next higher SF and a longer interval (seems like 0.1% duty). The starting dev nonce in each series appears to be random, and increasing by 1 for each attempt within the series.

image
image1468×421 189 KB

10

I believe that it is normal that the OTAA activation fails.
The shown Join Requests contain different JoinEUI and DevEUI than the ones you expect.

Lets take the first line in your table.

The base64 raw_payload is
AAAAUAEAy6ByEQ4JAQDheieF5+uy3Q=

Which is in hexadecimal
00 00 00 50 01 00 cb a0 72 11 0e 09 01 00 e1 7a 27 85 e7 eb b2 dd

The LoRaWAN specification states that a JoinReq is formatted as follows
image

Therefore in the received JoinReq we have

JoinEUI  : 00 00 00 50 01 00 cb a0 (LSB first) -> a0 cb 00 01 50 00 00 00 (MSB first)
DevEUI   : 72 11 0e 09 01 00 e1 7a (LSB first) -> 7a e1 00 01 09 0e 11 72 (MSB first)
DevNonce : 27 85 (LSB first) -> 85 27 (MSB first)
MIC      : e7 eb b2 dd (LSB first) -> dd b2 eb e7 (MSB first)

As you can observe

  • the JoinEUI a0 cb 00 01 50 00 00 00 is different from the expected one 58 A0 CB 00 01 50 00 00
  • the DevEUI 7a e1 00 01 09 0e 11 72 is different from the expected one E8 E1 E1 00 01 09 0E 79
  • the DevNonce is also way different from what I belive to be the expected one

You need to verify why you have such differences from what is being used by the end-device and what is expected.

You also need to ensure that the used keys are the correct ones.

Up until you fix this your end-device will never activate.

2 Likes
11

@mluis1 Very much appreciated that you did that analysis.

The data in the spread sheet is what I captured remotely from the TTN event stream for the gateway. The fields for raw payload, deveui, join eui, dev nonce are basically directly copied from that stream. There could still be a bug in my data collector of course, but since it’s basically a direct copy and matches what I see in the live console, matches what is printed on the node, matches the paper that came with the node, I am fairly confident that it is correct.

It could still be the case of course that there is some kind of mixup in the TTN stack, causing the EUIs/keys/etc shown to the user over the user interface to be actually different from the internal data exchanged with the join server.

Attached is what I see on the live console of the gateway (from a TBHH100 node that I am having problems with, not the exact one shown in the spreadsheet). At least on the console, the EUIs appear correct and in agreement with the EUIs printed on the node itself and on the paper that came with it.

image
image1920×1136 302 KB

One thing I suddenly realise: the 1 working node (TBHV100) was possibly registered on the account of the TTN application owner. Most of the other nodes were registered on my account. I am a collaborator with ‘all application rights’, whereas the TTN application owner has ‘all possible rights’. This allowed me to register the nodes without any problems/warnings/messages, but possibly something did go wrong silently internally in the TTN stack (like properly registering the node with the join server).

12

Seller contacted Browan and we got a different app key for one particular TBHH100 that wasn’t joining before, the new key works (allows successful OTAA join and node uplinks).

13

So, the problem was that we got the wrong keys. Solution was to contact our seller, who contacted Browan. Apparently Browan has a list containing (at least) our devices and their proper keys and they provided us with working keys.

Stuff under suspicion that didn’t turn out to be related:

  • Typos on our end (my first suspicion)
  • TTN network hiccups
  • The Browan devices themselves, behaving as expected with respect to lorawan protocol
  • Issue with authenticated user (collaborators can add/edit devices fine)
14

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.