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.
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.
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
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
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.
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.