Transport overhead optimization

[mihai.aldea]

I couldn't not notice the large overhead associated with the MySensors transport protocol. You see, as discussed before, the issue at hand is not using a coin cell for 3 years instead of 2, but it's about the RFM69 and RFM95/RFM96 modules which are capable of using really low bitrates or special modulations.
Eg. I had a 14250 battery that drained within a month with an RFM96 sending data every 5 minutes using RFM95_BW31_25CR48SF512 which was sending only one sensor value. This happened because unlike RF24 which can have a total awake cycle of 100-150ms, the RFM96 had an awake cycle of about 5000ms. It took it 5 seconds to send the single sensor value.
RFM69 is another case in which a lower bitrate -> longer range -> longer TX time. I went as low as 300bps only to see that a single packet is sent in about 1500ms. That's way too much for a battery powered node.

Some of us need long range sensors and we don't want a constant power messy setup, or the complex circuitry and increased cost associated with adding "UPS" like features to our boards.

My RFM96 node now sends a ping every 3h and the RFM96 nodes run in 9600bps so that I wouldn't have to replace those 14250 batteries monthly and actually use them for the intended life-cycle, that's more than 3 years.

The alternative is to give up MySensors altogether and use third party libraries, concatenate the messages as raw data then parse them on the remote gateway based on predefined rule set. But although this gets the job done, it's not a really good idea to mix various libraries and properly maintain the whole system in the long run.

[mfalkvidd]

@mihai.aldea if I understand correctly, you are using the fsk mode of the rfm96? Could you describe the advantages of using a rfm96 instead of rfm69, when not using LoRa mode?

Just to note for other forum readers: the transport overhead discussed in this thread is not MySensors transport, but the LoRa radio protocol. MySensors does not add much overhead, it is the LoRa protocol itself that is designed to get long range by sacrificing transmission speed.

[mihai.aldea]

So what you're telling me is that I'm not using the RFM96 in LoRa mode? I now seem really dumb, but in all fairness, after a lot of digging, I only found these modem configrations available:

* | CONFIG                    | BW    | CR  | SF   | Comment
* |---------------------------|-------|-----|------|-----------------------------
* | RFM95_BW125CR45SF128      | 125   | 4/5 | 128  | Default, medium range
* | RFM95_BW500CR45SF128      | 500   | 4/5 | 128  | Fast, short range
* | RFM95_BW31_25CR48SF512    | 31.25 | 4/8 | 512  | Slow, long range
* | RFM95_BW125CR48SF4096     | 125   | 4/8 | 4096 | Slow, long range

I chose RFM95_BW31_25CR48SF512 after some extensive trial and error range tests.

If I'm not currently using LoRa, how can I actually switch to that?

[mfalkvidd]

@mihai.aldea it actually seems like the fastest LoRa mode supports 9380 bps. I found this in the datasheet:

The datasheet also says this

So by using the "special use case" of SF6, it should be possible to get close to your selected transfer speed, at the cost of losing 15dB of sensitivity (compared to SF12).

If I understand correctly, this is what RFM95_BW31_25CR48SF512 does?

If that's the case, what is left to configure? Or does MySensors not support using RFM95_BW31_25CR48SF512 ?

[mihai.aldea]

OK, trying to make a sense of those tables now, but my main question remains: Is RFM95_BW31_25CR48SF512 a LoRa mode or not? Because this is what I'm currently using.

[mfalkvidd]

@mihai.aldea yes that is a LoRa mode.

[mihai.aldea]

@mfalkvidd said in Transport overhead optimization:

Could you describe the advantages of using a rfm96 instead of rfm69, when not using LoRa mode?

Then I don't understand your statement.

[mfalkvidd]

@mihai.aldea That is because it was written before I knew you were using LoRa. Look at the sentence just before that question. It says "If I understand correctly, you are using the fsk mode of the rfm96?"