Closed tiagodalima00 closed 1 year ago
Greetings,
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.)
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.
@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.
Yes, we are using the latest version of this project. Thank you
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?
I just changed the frequency of the spi.
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.
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.
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": "contact@email.com", "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.