LOPY to ERA-LORA board communication

[pkilcoyne]

Re: Send Lora message to non pycom device

Hi,
I had a previous thread open a few months ago but it went stale. I'm following up now.

All I want to do is pass LORA messages between a LOPY and a ERA-LORA.

http://www.lprs.co.uk/products/easyradio-ism-modules/era-lora-through-hole-modules.html

So below is what I've set my LOPY to:

lora = LoRa(mode=LoRa.LORA, region=LoRa.EU868, sf=12, frequency=869850000, bandwidth=LoRa.BW_125KHZ, public=True)
s = socket.socket(socket.AF_LORA, socket.SOCK_RAW)

Seems fairly standard, but what does the "public" parameter do?

On the ERA-LORA side via the companion GUI software "easyRadio" I have the following set:

Bandplan (frequency): 869.85MHz
Bandwidth: 125KHz
Channel: 0
Spreading Factor: 12

This seems to be a match on both sides but I still cannot get them to communicate :(

Does the LOPY use any encryption by default?

Any other defaults I need to be aware of? Anything obvious I'm missing?

Thanks,

Paul

[Eric73]

@pkilcoyne Hello, my two cents about reading your topics,
Basically if two lora module have same center Freq, same SF, same SYNCWORD (0x34 for lorawan and 0x12 for private lora), same coding rate, same IQ (IQ is inverted for lorawan and not inverted for private lora usally) and same HeaderSetup (implicit or explicit) the RX/TX work.

I dont see where with lopy how we can set header mode, so i suppose it's always explicit ?

In ERA-LORA it seem to be the same think (cannot set header mode so may be alway set a explicit?). They use "group ID" term instead of SYNCWORD, and they don't speak about IQ (so it's be supposed to be alway inverted ?)
I suggest you to try inverting IQ in Lopy for RX and TX, set group ID to 12xx in era lora , be careful on how you select frequency on both module and try...may be it's change something.

*I dont speak about header CRC mode setup it's a little bit fuzzy how it work.

[pkilcoyne]

@catalin @jmarcelino I again guys. So I've been playing around with two ERA-LORA modules and two LOPY modules again.

I have the two ERA-LORA modules talking to each other and separately the two LOPYs talking to each other.

Here are the settings on both sets of devices;

Can you think of anything else I might be missing?

Thanks,

Paul

[pkilcoyne]

@catalin Hi, sorry for the tardy reply, I didn't see yours til now.

I gave up on getting the two devices to communicate, seems impossible.

Any thoughts?

Thanks,

Paul

[catalin]

hi @pkilcoyne, did you received any answer from LPRS?
I've understood you still have this problem, right?

[pkilcoyne]

@jmarcelino Well I stopped transmitting on the ERA-LORA to see, nothing received. I've emailed LPRS again in regards to the frequency, awaiting their reply.

Thanks again,

Paul

[jmarcelino]

@pkilcoyne
They're not transmitting at the same time by any chance?

[pkilcoyne]

@jmarcelino Yes I tried that. Basically both devices are programmed to transmit every 2 seconds and receive. But they're not receiving anything yet.

[jmarcelino]

@pkilcoyne
Did you also try receiving with the LoPy on the new frequency?

Going over 870Mhz is not allowed in ETSI (Europe), the legal range is 868-870Mhz

I guess with the ERA device to use a higher channel you'd need to lower the base frequency.

[pkilcoyne]

@jmarcelino Yep, I've tried that, no joy.

If c is anything over 0 the LoPy gives an error saying:

ValueError: frequency 870037500 out of range

[jmarcelino]

@pkilcoyne
If I'm reading their manual correctly I think you may have the wrong frequency on the LoPy:

This means the frequency the LoPy should be set to is: 869850000 + (0 * 125000) + (125000/2) = 869912500

[pkilcoyne]

@jmarcelino OK so it's implemented those changes to reflect your suggestions.

Attached is a screenshot of the EasyRadio software and it's settings.

Regards,

Paul

[jmarcelino]

@robert-hh
The default setting is indeed LoRa.ALWAYS_ON but it doesn't hurt to add :)

[robert-hh]

@jmarcelino I've read this post and wondered, if not in mode LoRa.LORA the receiver is not always on anyhow. The simple example LoPy to LoPy seem not to need that setting of power_mode=LoRa.ALWAYS_ON.

[jmarcelino]

@pkilcoyne

In LoRa all the possible parameters are passed to init so there's isn't much of a need to print the parameters...

Did you set public=False as they describe?

You init line should be:

lora = LoRa(mode=LoRa.LORA, region=LoRa.EU868, sf=11, frequency=869850000, bandwidth=LoRa.BW_125KHZ, public=False, preamble=8, coding_rate=LoRa.CODING_4_5, tx_iq=False, rx_iq=False, public=False, power_mode=LoRa.ALWAYS_ON)

If you have done this I think you've set all the parameters you can.

If you send from the ERA-LORA board and try to recv() on the LoPy you also don't receive anything?

[pkilcoyne]

@jmarcelino Hi again, both devices are set up to send and receive continuously.

I add that change to the LoPy:
power_mode=LoRa.ALWAYS_ON

Is there a way to print to screen all the curent parameter values set on the LoPy?

Regards,

Paul

[jmarcelino]

Which device is doing the receiving? The LoPy? If so you probably need to add power_mode=LoRa.ALWAYS_ON to the initialisation

[pkilcoyne]

@jmarcelino They said SF11 was preferable so I've changed it at both ends.

[jmarcelino]

@pkilcoyne
You were using sf=12 before and now sf=11 does this match what you have set?

[pkilcoyne]

@jmarcelino Thanks for the reply.

I've set the LoPy as follows now:

lora = LoRa(mode=LoRa.LORA, region=LoRa.EU868, sf=11, frequency=869850000, bandwidth=LoRa.BW_125KHZ, public=False, preamble=8, coding_rate=LoRa.CODING_4_5, tx_iq=False, rx_iq=False )

According to LPRS their settings are similar:

You also need to match:

1. the coding rate e.g. coding_rate=LoRa.CODING_4_5 - Yes we use the same coding 4/5
2. the Sync Keyword (the public=True means 0x34, public=False means 0x12) - Yes the module is set to 0x12
3. Preamble length (the Lopy default is 8, set by preamble=8) - Yes again the module is set preamble 8
4. Make sure the IQ matches the inversion setting (for transmit and receive, set by default to tx_iq=False, rx_iq=False ) - I think it is set to false.

Still no messages seem to be received at either end.

Is there something else that could be the issue?

Regards,

Paul