The LoRa Developer Forum is now in read-only mode and new content will not be added. If you require technical support related to LoRa, please contact our experts here. For sales enquiries, please contact us here.

FORUM

Sx127x syncword issue

Hello everyone, I am starting to run some test using Lora, I am far from being an expertise so I apologise for the mistakes that could appear on the post.

Boards: pycom4; Sx1278.
Language: micropython.

The communication between the devices works perfectly, but the problem appears when we try to filter which node should receive the packet and which should ignore it.

After a few days of researching and exploring deeply the datasheet provided, we could not find any solution to the issue so I will try to explain it clearly and will be willing to hear any recommendations.

What we are trying to do is to communicate 3 Lora devices (2 of them as receivers, 1 of them as sender). Our initial idea was to fix a sync_word = 0x15 for example for one of the receivers and the sender, whereas the other receiver will have a fixed sync_word = 0x17.

lora.sleep()
time.sleep(1)
print ('SYNC_WORD=', lora.read_register(REG_SYNC_WORD))
print ('Payload length =', lora.read_register(REG_PAYLOAD_LENGTH))

time.sleep(1)
lora.write_register(REG_PAYLOAD_LENGTH, 26)

lora.set_sync_word(0x15) \\CHANGES in the second receiver
time.sleep(1)

print ('SYNC_WORD=', lora.read_register(REG_SYNC_WORD))
print ('Payload length =', lora.read_register(REG_PAYLOAD_LENGTH))

lora.standby()

This is the code we are using to be sure we are adding the correct payload lenght to the three devices together with the sync_word; after reading on the datasheet we realiced we need to setup the microprocessor in sleep mode to write on it thats why we placed lora.sleep just before changing the sync_word value.

The problem is that it does not matter which sync_word is placed, both receivers get the data.

If any of you have had this issue and have been able to solve it would be great to have any feedback and recommendations.

Sync words are best left alone to the two standard ones.

You might think its a good way to filter packets, but it really does not work as the datasheet might imply, as you have discovered.

Thanks for your answer, then we will have to implement a way to filter packets into our program.
Then if I understood well we have two ways of working.
0x34 Public with fixed parameters.
0x12 Private with different possible configurations.

Now a new question arises from this. I am assuming from here from what we could understood from the datasheet. By using the private syncword (which I assume is inside the preamble of the packet), the rest of the structure of the LoRa packet can be configured manually depends on our demands on the net.

So in the end parameters as header, crc, payload and payload crc should be completely avaliable for costumization.

Thanks in advance.

You can change\customise the payload.