Spreading Factor settings with PJON

[jwktje]

I'm using arduino-LoRa with PJON. It works great when using Spreading Factor 7, but when I change it to anything else it stops working. I'm communicating between two arduino's using the RFM95W.

Is there anything else I need to configure for other spreading factors to work? I want to increase the range I get and I wanted to experiment with a higher SF but can't get it to work.

Any help at all is really appreciated!

[Matheus-Garbelini]

@jwktje By increasing Spreading factor, each symbol time increases by a little when transmitting. Try increasing TL_RESPONSE_TIME_OUT in Timing.h Your message may be exceeding the 100ms default timing.

[jwktje]

Hey Matheus,

Thanks for your input! I tried increasing the timeout by 10 times by defining it before including the library like so #define TL_RESPONSE_TIME_OUT 1000000UL

I printed the value later to check it was defined as such and that worked. But even going from Spreading factor 7 to 8, the sketch doesn't work.

On spreading factor 7 the two nodes communicate fine, but on 8 or higher, it doesn't.

I'm using the PJON dynamic addressing which works great on SF 7. I feel like there must be more that I need to config for other Spreading factors to work. Any idea?

EDIT: I did some more testing but whatever parameter I tweak it doesn't seem to change anything. For completion, below are the settings that work:

LoraPJON.strategy.setSignalBandwidth(125E3);
LoraPJON.strategy.setFrequency(868100000UL);
LoraPJON.strategy.setSpreadingFactor(7);

If I change that spreading factor the messaging fails. Randomly on SF 8 it worked once and then never again. Would the bandwidth or frequency need to change for other SF's to work?

[gioblu]

Ciao @jwktje thank you very much for reporting this issue. I will try to replicate this using 2 Arduino Duemilanove/nano. @Matheus-Garbelini have this ever occurred in your tests? If not, probably this may be an issue related to the dynamic addressing classes.

[gioblu]

@jwktje have you tried tweaking the amount of time dedicated to reception or receive(reception_time)?

[jwktje]

Thanks for responding! No I haven’t yet. How can I tweak that? I’ve only tweaked the mentioned parameters in the code in my previous code.

[Matheus-Garbelini]

@jwktje ah so you're using auto addressing. I remember tweaking PJON_ID_REQUEST_INTERVAL in PJONDefines.h

It's defaulted to 100ms which is too low when using other sf. Try increasing it by 1 sec.

Also, did you test pjon without auto addressing with a higher sf?

@gioblu, the thing is that sf would affect even default values for auto addressing. We'd need to update the strategy documentation on how to use higher sf. We have a lot of latency the higher we go with sf.

[jwktje]

Increasing that interval I got SF8 to work in a stable way too. But anything higher is still having the same issue.

The TX/RX windows are important with LoRa I think. I did a little testing with TTN and this was the case there. So I wouldn't be surprised if there are more parameters to tweak to get SF10+ to work well.. If you have any pointers on what I could try, or the time to test, that would be awesome.

Your point about testing higher SF's without the auto addressing sounds like good advice to debug this issue. I will try that and report back once I have the time to get some testing in.

[jwktje]

Did some testing without dynamic addressing based on the example sketches. A weird problem appeared. When using setSignalBandwidth and setSpreadingFactor, the Transmitter example never seems to start sending. When disabling setFrequency functionality returns.

I don't know if this gives you any insight to a possible cause? I will return to my original test-case and I will stop using setSignalBandwidth for now and see if that changes anything.

EDIT:

Sadly have to confirm that this doesn't improve my original use-case. For now the only stable way to get it to work on my end is:

• Use default intervals for TL_RESPONSE_TIME_OUT and PJON_ID_REQUEST_INTERVAL
• Use Spreading Factor 7
• Use default bandwidth

Just wanna say, apart from this little challenge/issue I really am loving PJON and am super thankful for your help. If you have specific things you want me to test let me know. I'd love to get to the bottom of this and increase LoRa range by upping the SF, in combination with the PJON protocol.

[gioblu]

Ciao @jwktje I am sorry for answering you so late. A lot of real life issues piled up. Thank you for your support to the project. I also would go to the bottom of this because I agree would be nice to higher up the SF. I am now not able to test practically but I see some timing issues could affect the functionality.

https://github.com/gioblu/PJON/blob/master/src/PJONDefines.h#L169

Not only PJON_ID_REQUEST_INTERVAL should be higher, also the PJON_ADDRESSING_TIMEOUT may be required to be higher and also PJON_LIST_IDS_TIME may be required to be higher.

I am sorry if you have experienced this issues, although I am happy to hear that at least in some configuration those classes work out of the box over the air, when initially was all designed for wired networks.

I am considering to iterate the dynamic addressing specification and implementation to make it effectively useful for setups like the one I think you would achieve. For now the dynamic addressing procedure let devices self assign a random slave id, although a user inserted, known id could be useful to reach a certain device that moves in a network of PJON-LoRa routers.

Thank you again.

[jwktje]

Yes that would sound great. To still dynamically have nodes join but have a user defined node-id. Maybe from a custom board that has a DIP to address or something. This would be perfect for my use-case.

I will test with the mentioned intervals and see if increasing these makes SF12 work. If I succeed, then maybe these could all be changed in the library to be overridden before including the library with an ifndef.

Again, compliments on PJON. Loving it. We can get this to work easily. Just some tweaking to do! 👍

[gioblu]

@jwktje This is what was rolling in my mind about this:

• We have a network layer that handles 1 trillion nodes
• We have a sort of dynamic addressing with a sort of narrow applicability envelope
• We have a network layer able to go over internet, LoRa, wires, other radio modules, RS485 and so on

Why not to make the actual RID or randomly generated 4 byte slave identifier, a 5 bytes "device name" that can be obtained by the PJON website as it is done for the bus id?

With some coverage wouldn't that be cool? Couldnt internet initially be able to close the gaps? A sort of new free internet made and maintained by makers?

It could even give some sense to exist to the LoRa pager project :) If I have to be sincere, this always was the goal of the project, although it was never advertised too much because i did not want to be ostracized or judged as crazy.

[jwktje]

Hey @gioblu

Just tested by upping all mentioned intervals times 8. This made it work on SF10, which is an improvement. But the joining process was a lot more flaky than on SF7. It continuously took about 4+ tries to get an ID and sometimes it would just hang and do nothing.

So I feel like someone with more Lora expertise than me would be able to apply some logic to this problem, to get specific correct timing/intervals for the different SF's. Do you have experience in this regard?

But the good news is, it did work to a certain extent. Not stable yet but for a quick test this is good news!

About your other point; I think I kinda understand what you are getting at. So a public universal network that can traverse all sorts of infrastructure? That would be awesome for a lot of use-cases I imagine, especially when using a universal protocol like this one.

For my specific use case, I have an idea for an application that would use Lora to get one central node (that would function as a bridge) to send downlinks to a bunch of nodes in a ~5km radius. I want to control hardware through this from a central point without needing GPRS or WiFi. For this use-case it would probably make sense to have one universal Arduino Sketch for all nodes (excluding the bridge) without a hardcoded ID. But be able to set the address on the hardware by solderpads or a DIP. So that I know that a certain node will always be on a certain ID without having differences in the code.

That's at least what I'm thinking at the moment. So I wouldn't probably need dynamic addressing for this? I'm using it in my prototype as I don't have any addressing hardware solution in my prototypes so dynamic ID's made sense.

[gioblu]

@jwktje 5 km radius is a high distance, I am not sure LoRa at those ranges is fast and stable enough to let the dynamic addressing exchange occur properly but @Matheus-Garbelini has more experience than me on this strategy.

1. In most cases static addressing is more stable and reliable and uses less bandwidth.
2. In few cases dynamic addressing is required to obtain the result. For example @ovedmo wants to have many identical modules to be plugged or removed without needing to refer to them directly.
3. In even fewer cases dynamic addressing with a static known name is absolutely required to obtain the result. For example I would let users register a name and let other users' central nodes be able to assign network layer identification (bus and device id) that may change if the device moves in the network, but let the device have a fixed name that makes it reachable everywhere a central node able to give connectivity is present.

Depending on the amount of address maintenance you would be required to do you can decide if to waste some bandwidth and have additional complexity traded for less time required to configure a new device or maintain an already deployed one.

If the node number is not huge, I would consider static addressing with a 8-bit dip switch that is latched to the PJON device id. It would be cool to think about a dedicated board including this :)

[Matheus-Garbelini]

@jwktje Actually there's a mode called Channel Activity Detection (CAD) that these Lora transceivers can operate and allows to detect the preamble of an incoming message before sending anything. There's planning to include this in the strategy, but it still needs to be tested, this should not only increase reception efficiency but avoid a lot more broadcast collisions.

Also, as Lora radios have a low bandwidth (using normal Lora modulation), dynamic addressing with distance sensors become more difficult due to reliability. If your applications allow the dynamic addressing to take a lot of time then you should be fine. I'm not sure if 5KM is achievable with these normal Lora transceivers. Ideally, this is just achievable in a perfect line of sight scenario and with a transmitter with additional PA Amplifier going to the antenna. Also be aware that using Lora in a huge radio for a custom application can disturb nearby innocent Loran networks :-).