I’m trying to activate several Arduino MKRWAN boards on Chirpstack using a Dragino LPS8N.
The gateway and Arduino’s were working previously on the Things Network, but I had to switch to Chirpstack due to firmware compatibility issues between the Arduinos and TTN.
After several weeks of reading docs, test configs, more reading, more tests I’ve reached a standstill. I have the Dragino configured correctly and have configured Chirpstart according to the guides. I can see packets leaving the Dragino, packets arriving at the Chirpstack Gateway (located on the host, not the Dragino), and the forwarded packets arriving at the Chirpstack Main Program. BUT, according to the Chirpstack GUI , there are no packets acknowledged and no LORAWAN frames arrive.
**With The API BIND statement in chirpstack.toml set at #bind “0.0.0.0:8080”, the resulting output from ‘chirpstack.toml’ returns **
*Following a suggestion from another post I set the BIND statement to empty #bind “” . The result was packets beginning to flow freely. I though it was fixed, but without the bind statement the packets are tying up port 8080, and now the Chirpstack GUI is either refusing or unable to load. If I change the Bind back to “0.0.0.0:8080” the GUI returns to normal, but the packets again halt. I’m caught in a circle.
My hardware:
Dell PowerEdge blade server running VMware ESXi 7.6.3
VM is running Ubuntu 22.04.3 LTS x64 (VM is assigned 10GB DDr4 RAM, 120GB SAS)
Chirpstack is V4.x latest release, Mosquitto and other support programs are the latest
-Dragino LPS8N Firmware is 5.4 –Dragino is configured for Semtech UDP
Network: Both the Dragino and Chirpstack VM are on the same subnet: 10.10.30.X/24. Both end devices are reachable from the other
Other than unique changes to the regions, passwords, and the above-mentioned API BIND statement my gateway and chirpstack toml files are stock from the website examples.
Please help, after wasting a month on TTN with no solution, I’ve bet all my money on Chirpstack.
Sorry, I have other things to post, but as a new member, the forum will only let me post one item.
Thanks!
The port 8080 is used for web and gRPC traffic. You should study the networking between the Gateway Bridge and your LoRa Gateway. It likely involves UDP port 1700.
Binding means that only packets that come through network interfaces with matching addresses will be accepted. So if you put 0.0.0.0 (which I believe is the default), connections can come from anywhere.
If I remember correctly, the API that is disabled, refers to something else.
Please look at the logs for the Gateway Bridge first, to determine whether it can communicate with the gateway. You should increase verbosity to debug or trace, to see the exchange of GWMP UDP messages with the gateway.
Okay…another 12 hours of beating my head into the wall with zero progress…
You are correct, the API bind command doesn’t appear to be the problem.
But what is worse is that I cannot seem to isolate what IS causing the problem. I took the following measures:
Turned on debug, but it didn’t provide much usable new info
I moved the Gateway Bridge from the Chirpstack virtual machine and installed it directly on the Dragino gateway. I configured it exactly as directed by Dragino and Chirpstack, but still nothing 'was recognized by Chirpstack
From the console output below, it ‘appears’ that packets are received by Chirpstack. it processes the incoming messages and subscribes to the gateway traffic, but NOTHING ever gets past the incoming buffer and into the database, the LORAWAN gateway packet counter is a big fat zero and says “Never Seen”
Please note the one error in the trace below, I don’t think it is the problem, but it’s the only anomaly I can find
Please ! Any new ideas??? I have reconfigured everything 100 times, at this point I’m just moving in circles. I expected to have a more difficult time with the end devices, connecting the gateway is usually the easiest part.
I would suggest picking a pattern and staying with it. Having come from outside Chirpstack, I believe that using either the UDP packet forwarder or Semtech BasicStation would allow you to move between LNS.
I see an “event/conn” message in your screenshot. This means that the gateway has either become online or offline. If it stayed offline (e.g. “never seen”), then it could mean that the gateway bridge never successfully received the statistics message from it.
That being said, did you look at the gateway bridge’s logs? I don’t think anything can really go wrong between Chirpstack and the Chirpstack Gateway Bridge (GWB) because they are both components of Chirpstack, so you should confirm that the GWB is receiving messages from the gateway. If you find no message logged (regarding the gateway’s messages) while the GWB has verbosity turned to either debug or trace, then you probably have some sort of networking problem.
In your second screenshot I see an error message: Unknown event type region_id=us915_0 and in your first screenshot I see that chirpstack is subscribing to region us915_4 so maybe you haven’t enabled the right region in chirpstack config enabled_regeions or don’t set the mqtt topics right in the gateway bridge. You can also try to subscribe with an mqtt client to your mqtt broker to -t ‘#’ to see whats going on there an turn gateway bridge marshaler to json.
Thank You, I did see the debug errors, but could not determine the exact cause. so I solved the problem by erasing all the devices and starting with a fresh set of code. The Gateway joined the server and was able to add devices. Thank you!
I still have a problem, but its not technical, its a lack of programming knowledge on my part. I am a WAN engineer and do not work at code or API level, most sensors and equipment I use already has pre-built APIs that ingest uploaded ASCII data and convert it to hex/binary transmissions over the WAN, my focus is on the WAN equipment and ensuring an error-fee transmission path.
In this case I have to take sensor readings (ie DHT22 etc) attached to an Arduino MKR WAN, and convert them to a hex payload stream. I have been with successful with Arduino to Chirpstack Server communications: The device joins successfully, and traffic is going up and down:
However, I am unable to recover any of my sensor readings (all are just simple Celsius temperature data) on the Chirpstack Server. I believe that my Arduino sketch is flawed and that the data received is not formatted properly to allow decode. To be completely honest my JSON and Arduino coding skills are very basic, programming sensor data into payloads using advanced javascript is above my head. Do you know of any pre-made arduino>Chirpstack sketches available anywhere online? If I have a template I have enough skill to adapt it to my needs, I just don’t have the knowledge to write from scratch.
These are the Device Metrics …empty… I have failed to provide the proper encoding (on the Arduino side) and decoding (on the Chirpstack side) to fill these charts. This is the goal.
I feel like you’re either skipping a lot of details or perhaps something isn’t sufficiently clear to you. Let’s start with the basics first.
LoRaWAN allows a certain number of bytes to be sent over the air, without specifying how the payloads must be encoded. The format of the payloads is defined by the device maker. It’s possible to convey readings as individual bytes or even bits of a byte.
Since the odds of collisions increases with the payload length, keeping messages as short as possible would be ideal. Formats like JSON introduce unnecessary overhead.
Chirpstack is a LoRa Network Server, which communicates with devices through LoRaWAN, via LoRa gateways. The payload is made available to 3rd party applications and also displayed via its UI. Since the payload can be interpreted as a sequence of bytes, this is the default representation (as seen in your post #6). If you register a codec, you can decode this message into a JSON representation. But this is another, optional step that you can get Chirpstack to take.
So, I don’t think it is necessary for you to have written the codec, yet. Since you’re working on an end-to-end solution, I suggest breaking this problem into two. If you designed and wrote the code on the Arduino to convert the sensor input into the uplink payload, you should be able to interpret that sequence of bytes indicated by Chirpstack, by hand. If you are able to do that and the values makes sense to you, then the data coming from the Arduino has been correctly encoded and transmitted.
If you need coding help, do post the code that you’ve written. At least the part that reads the values from the sensors and encodes them into the message for transmission.
You are correct, its not clear at all. As a WAN engineer, I work almost exclusively at OSI model layers 1 - 5, I handle very little application layer protocols; they are provided to us as pre-compiled and provided to us as complete programs. That said, your explanation did help fill in many areas of missing knowledge. Thank you.
The following is the Arduino code I am using. It is a mix of self-developed code through trial and error, and other pieces were added from sketches found on various forums. This code does compile and successfully registers with my Chirpstack server, but as mentioned, the packets either contain no sensor payload or the payload is not formatted correctly:
The MKRENV is an Arduino Shield that provides onboard sensor readings to the motherboard: Temperature, Humidity, Pressure, Lux, and UV index
#include <Arduino_MKRENV.h>
#include <SPI.h>
#include <MKRWAN_v2.h>
int counter = 0;
LoRaModem modem;
void setup() {
Serial.begin(115200);
// Init modem & Send OTAA EUI ID
modem.begin(US915);
int connected = modem.joinOTAA("3535313166377b0a", "a9fca61b82e9b0bb9348a1bcb1e3afae");
//INITIALIZE Arduino MKRENV BOARD
ENV.begin();
}
void loop() {
//Assign MKWENV Sensor Variables
float temp = ENV.readTemperature();
float hum = ENV.readHumidity();
float pressure = ENV.readPressure();
//translate float value to int 16 bit *100
int16_t temperature = (int16_t)(temp * 100);
int16_t barometer = (int16_t) pressure ;
int16_t humidity = (int16_t)(hum * 100);
//shift bits and store the value in bytes
byte data[6];
data[0] = temperature >> 8;
data[1] = temperature & 0xFF;
data[2] = barometer >>8;
data[3] = barometer & 0xFF;
data[4] = humidity >> 8;
data[5] = humidity & 0xFF;
//show data in the serial monitor
Serial.print (temp);
Serial.print (pressure);
Serial.print(hum);
//send the data to the gateway.
modem.setPort(1);
modem.beginPacket();
modem.write(data, sizeof(data));
modem.endPacket(false);
delay(15000); // send a message every 15 seconds for TESTING ONLY
}
Thank you for sharing the code and explaining what hardware you use. Your data format consists of 6 bytes and looks like this:
TTttBBbbHHhh
Field
Description
TTtt
Temperature (℃) x100
BBbb
Air Pressure (kPa)
HHhh
Humidity (% rH) x100
Each field is 16-bit, encoded in big-endian format. Whereby uppercase denotes the upper octet, while lowercase denotes the lower octet.
However, this doesn’t seem to align with what we see in post #6, which suggests that this is a different version of your program. The payloads there are 7 bytes long and are sent on FPort 3 (instead of 1, as shown in your code).
So anyway, you need to verify whether you can decode the data shown with this knowledge.
You are also printing the values read from the sensors on the Arduino’s side. If the values shown in the terminal look correct, there should be no issues with your hardware.
For example, we have this 7-byte payload shown in post #6:1ebc0c5c017900
TTttBBbbHHhh??
1ebc0c5c017900
It’s 7 bytes for some reason (likely a different program), so I ignore the 7th byte. The values don’t seem to be correct, but let’s assume they are for a moment.
(One thing that makes me wonder is, whether this version just had a different layout from the one you posted. For example, TTtt here is actually humidity, BBbb is the temperature, HHhh is the barometer… which means 78.68% rH, 31.64℃ and 3.77 kPa)
Assuming that there are no problems with the Arduino side, what is the codec script that you are using for Chirpstack like?
The goal is to convert the payload (an array of bytes) into JSON, which is a more human-readable representation of the data.
I’ve not used the device charts before. But surely you need to configure them, including specifying which attribute to plot the graph with. This likely needs to align with the returned structure from decoding. Do feel free to post what you have entered for this too.
On a side note: you mentioned that sometimes, there are uplinks with no payload. This may be because the message was sent by the LoRaWAN link layer (similar to OSI layer 2), containing only MAC commands.
Now I get it ! I made two stupid mistakes, I was grouping by four bytes, but my dumbest mistake was trying to convert HEX > TEXT, when I need HEX>DECIMAL.
Yes, my earlier sketch was different. The last sketch I sent is the most accurate, six bytes and fp1
So, following your example with this recent server payload:
So now a success, three sensor parameters are received at the device buffer, but still have to apply my very flawed DEVICE PROFILE/PAYLOAD CODEC>javascript function/codec Function which is as follows:
The arguments are variables too.
You need to divide by 100, since you previously multiplied by 100.
The goal is to return an object, so we compute the values and return an object.
JavaScript has no concept of unsigned bytes, so we probably need to perform a logical AND with 0xff. Otherwise, sign-extension could occur and the wrong bits will get OR’ed into the result. Unless we can be sure that only unsigned values will be passed in.
It is better to give the attributes of the object, meaningful names.
Mr. Liu: I still cannot get the payloads to decode into the application “gauges.”
I can see the payload and sensor data, and can manually decode. I believe all the sensor variables are properly assigned to gauges, but nothing registers.
Before troubleshooting further, I received a Dragino LHT65N in the mail. I will connect it and see if I can recover the data in the chirpstack server. Removing the Arduino will eliminate a lot of technical problems and unknown factors. I will report the results in a few days. Thank You, Brian
Here is my current decoder based on your suggestion: (please note that I expanded the decoder to include all six parameters of the Arduino MKRENV Board: Temperature, Humidity, Pressure, Illumination, UVA, UVB, UV Index - The length is no longer six bytes, its now 14 bytes)
Unfortunately, but NOT unexpectedly, this decoder still fails to function. I tried manually creating the variables, and tried with “AUTO”. It won’t decode and/or fill in any variables.
My Apologies,I have made great progress, but again need your help.
Does Chirpstack successfully decode with your codec? Under the Events tab, it’s supposed to show all those decoded values and not just the raw payload, according to what you have written. There should be also no errors with decoding.
Yes, your comments make sense, however, the Dragino Packets are decoding and posting to the gauges, even though they appear as a single-byte streams in the packet monitor.
Neither the Dragino or the Arduino payloads appear with headers suing the +UP button. The embedded fields of RSSI, SNR. etc do appear, but no actual sensor data,
I can manually decode the hex code from both payloads and translate them into decimal; it is correct.
Additionally, the Dragino’s payloads are automatically detected and posted to the Chirpstack device metrics page.
Now I get it ! I made two stupid mistakes, I was grouping by four bytes, but my dumbest mistake was trying to convert HEX > TEXT, when I need HEX>DECIMAL.
