I find this theory that certain patterns are disallowed rather dubious.
But if it is true, then it should be something that can be confirmed setting such a suspect eui in an ordinary SX1301 packet forwarder, too.
I agree, however back in June this was the case, equally why would adding temperature as an extra data element to the JSON string make it fail.
I was reporting my experience on the Mesh server and the issue here is on the SE Asia server. Remember the servers are not all the same, for example, there are a number of Integrations that don’t work off Meshed.
Essentially we were offering some options to explore not know if they applied to the SE Asia server or not. I may also repeat the tests on Meshed and see if its different now.
The problem is that a “lore” of unconfirmed suspicions causes people to waste a lot of time trying things without really knowing if they help. That’s magic, not engineering.
If there’s actual a problem with certain EUI patterns, then it’s a problem that can be confirmed using some other sort of packet forwarder, like a standard SX1301 setup.
That would be in contrast to something like say, a bug in the packet forwader, where it might use a different EUI in different situations (though lets hope anything so extreme would have been quickly caught).
why would adding temperature as an extra data element to the JSON string make it fail.
That would be another unconfirmed guess. A JSON parser is not supposed to care about additional fields. Though an implementation that had a fixed length buffer somewhere could choke on a longer message than previously seen. But again that’s something that could be confirmed, for example by modifying a standard packet forwarder to send a few extra bogus fields.
The community is served by having confirmed factual knowledge of issues. In addition to a confirmed dependence on specific gateway-side behavior, any real issue should be recognizable in the server source code, knowable aspects of Internet protocols, etc.
Hi, its not a guess, when I modified the SX1302 packet forwarder code last June and removed the temperature field it fixed the problem.
Reasonable idea. Over the next few days I’ll see if I can get the time to do this.
Hi @cslorabox, Am I a Magician or an Engineer? 
To assist, I have repeated the tests performed and reported in June (link provided above) as well as extending these to the V3 platform. I will report on these shortly.
Would be interested to compare these results with tests you could perform on your local server.
I have replicated the issue in the V3 stack and its the same as I found last June.
I’m sure this will be resolved in the longer term, but for now I’ve published a modified packet forwarder.
A more detailed description of the issue can be found on GitHub and its associated with the use of V1.3 of the gateway-to-server protocol.
It also includes a second patch to address the problem where the gateway radio module does not have a stts751 temperature sensor.
Presumably you mean the theory that the temperature field is causing an issue.
Your repo would be a lot more useful if in its commit history you identified where it forked from Semtech’s code (indeed, if you retained rather than eliminated Semtech’s commit history) and then had a single well-titled commit making the functional changes you feel are appropriate.
As I posted last week, I would be interested to see if this can be repeated on another server. I’ve only tried this on the Meshed server and more recently on a V3 instance running on The Things Industries.
I’ll have a look at taking on your suggestion re the Repo, in the interim I’ve deleted the Repo and will have another try.
When I use the global.conf and lora_pkt_fwd above, there is an error.
pi@raspberrypi:~/gw1302s/bin $ ./lora_pkt_fwd
*** Packet Forwarder ***
Version: 1.0.5
*** SX1302 HAL library version info ***
Version: 1.0.5;
***
INFO: Little endian host
INFO: found configuration file global_conf.json, parsing it
ERROR: global_conf.json is not a valid JSON file
Did you edit the global_config.json file and insert your own gateway ID?
this file has the following which needs to be changed
“gateway_ID”: “Place your gateway ID here”
Yes I did, and
When I use your global.conf and my own lora_pkt_fwd, it has the same error above.
When I ues my own global.conf and your lora_pkt_fwd, it has another error:
ERROR: invalid I2C file descriptor
ERROR: invalid I2C file descriptor
ERROR: failed to configure the temperature sensor
ERROR: [main] failed to start the concentrator
pi@raspberrypi:~/gw1302s/bin $ ./lora_pkt_fwd
Can you try two things with the combination of your global_config.json (with the 3 extra commands added) and my lora_pkt_fwd.
I suspect it has a temp sensor either not at the standard address or not the same type of sensor
- on the Raspberry Pi terminal run the command
sudo i2cdetect -y 1and see if you have a sensor at address 3b - in the global_config.json can you set the “temperature_sensor”: false,
My bad, just found an error in my global_config.json
The comment line below did not have the */ at the end. It should look like the following
/* if the following line is missing but required, the default value is 20.0C */
When I use my own lora_pkt_fwd and your global.config, I can communicate normally, but I can’t see the ‘Status：connection’. When I remove the temperature related code in lora_pkt_fwd , I can see ‘Status：connection’.
Next, I will use the control variable method to achieve a successful connection on the Japanese server.
By the way, in the global.config, I set the ‘gateway_ID’ the same as the ‘concentrator EUI’, and I do not use ‘FF FE’ and something like that.
The issue why the server rejects packets with the temp variable has been identified by TTN.
In the V3 stack it is coded as a signed integer while the SX1302 UDP packet forwarder, which is based on version v1.3 of the gateway-to-server protocol, is a float.
This can be seen in the open source code for the V3 stack on Line 118 of the link below.
While a future version of the V3 stack will be adjusted I would not expect the current V2 server to be modified given the freeze on making changes.
2 Likes
Is it possible to solve this problem simply by changing the variable type of variable temperature in lora_pkt_fwd.
1 Like
@haowong. Changing the SX1302 UDP Packet Forwarder to send an integer rather than a float does solve the problem.
I have just tested and it works on the Meshed server.
You can use your normal global_config.json file with this version of the packet forwarder.
1 Like
I believe that’s the answer to the question. Why are the designers of TTN so careless? If they have read the source code of the package forwarder, they should not have made such a mistake.
Please, please if you are going to create a github repo of a variation of the Semtech packet forwarder, retain Semtech’s commit history (either fork it on github, or pull from Semtech’s repo and push to yours) and then make your change in a commit. This is presumably a change to a single sprintf() line - a proper commit would represent it as such.
That way it remains compatible with any other changes or evolutions that may be needed.
Also posting a binary does little good - presumably it’s for a raspberry pi, but?
To be clear, the format is specified in sx1302_hal/packet_forwarder/PROTOCOL.md at master · Lora-net/sx1302_hal · GitHub which although distributed with the code is really documentation not source code.
The important point being that you’re not supposed to have to read the code of another component in order to correctly interface with it, but only the documentation. And the documentation does say “float”.
1 Like