UPLINK in our implementation don't work

[Tiago Lima]

Good afternoon,
I belong to an electronics and telecommunications student group, and we are making a lora gateway to chirpstack and we are using your packet forwarder.
I'm creating this issue since we couldn't receive any packets sent from the end-node with the SX1278 chip. We have no reception either on chirpstack or on the MQTT topic defined in the chirpstack-gateway-bridge configuration file. The chip used in the gateway is also the SX1278, implemented in a raspberry pi 3. What is giving us food for thought is this problem, since when running the packet forwarder we have the gateway appearing active in the chirpstack.

This is our config file, this configuration is the same that we use in end-node.
`{
"ic_model": "SX1278",

"spi_speed_hz": 2000000,
"spi_port": 0,
"spi_channel": 1,

"pin_nss_cs": 6,
"pin_dio0": 9,
"pin_dio1": 10,
"pin_rest": -1,

"spreading_factor": 7,
"carrier_frequency_mhz": 433.0,
"bandwidth_khz": 125.0,
"coding_rate": 5,
"sync_word": 99,
"preamble_length": 8,

"latitude": 42.0,
"longtitude": -8.0,
"altitude_meters": 10,

"platform_definition": "1chan_uplink_pkt_fwd",
"platform_email": "[e-mail]",
"platform_description": "OPiPC LoRa 1-Ch GW",

"servers": [
{
"address": "192.168.137.246",
"port": 1700,
"recv_timeout_ms": 500,
"enabled": true
}
]
}`

Thank you for the help.

[zhgzhg]

Greetings,

1. If I understand correctly you don't have any logs on the node or the packet forwarder indicating any errors, and your node appears to be transmitting, but the packet forwarder cannot hear it?
2. How exactly does the node transmit - is it based on the Transmit example in this project, or something else?
3. If we assume your hardware is wired correctly, and the Transmit example is used, then you should double check if both node(s) and forwarder use the same RF config in terms of:

• spreading_factor
• carrier_frequency_mhz
• bandwidth_khz
• coding_rate
• sync_word
• preamble_length

Any mismatch will cause the devices to not hear each other. For e.g. it's common for the people to forget setting the correct sync_word on all sides.
(If the packet forwarder receives anything it will print it in the console.)

[Tiago Lima]

Good Morning,
Yes that's our problem, the packet forwarder doesn't listen to any packets. We have the settings all correct on all nodes in the system, including the sync_word.
Our transmission node is an esp that every second sends a "Hello World" through lora.

[zhgzhg]

@tiagodalima00 , are you using the latest version of this project? In its old versions there used to be some issues with the Transmit example.
Apart from the above without any logs or sample code I could hardly think of other troubleshooting hints.

[Tiago Lima]

Yes, we are using the latest version of this project.
Thank you

[Tiago Lima]

Now we have connection.

But they only appear in the terminal, in chirpstack live lorawan frames don´t appear this packets. Where we can hear this packets? We can have that on node-red?

[Tiago Lima]

I just changed the frequency of the spi.

[zhgzhg]

Well done, now it's certain the devices are capable of communicating with each other. But logs with that many CRC errors is unusual. There could be plenty of reasons like distance, noisy environment, weak/noisy power supply, etc... Lowering the communication speed, and increasing the SF may help...

Regarding ChirpStack - it's normal not to show the data from the Transmit example, because that example is not using LoRaWAN but is just sending raw data via LoRa modulation.

The LoRaWAN data is encrypted, following a special format, and complying with fair air time usage constraints. To implement a real LoRaWAN node you'll have to use another library, because RadioLib doesn't have a LoRaWAN protocol implementation. Popular ones are Arduino LMIC, Arduino LoRaWAN, and the various modifications of LoRaMac-node. Another simple one is LoRaNow.

Approximately said, the LoRaWAN specification requires the RF transmissions to happen across several predefined frequency "channels" (frequency plans) from which the node selects randomly. every time. The challenge with all of the libraries above is enforcing them to always transmit on the same "channel", so the single channel packet forwarder can hear the transmissions every time.

[Tiago Lima]

Thank you very much for your help, we already have the topic to read on node-red as we intended. Now we just have to decode the payload and the main objective is accomplished.
We will after this give some upgrades to our system.
Thanks again.