DASH7 over LoRa confusion about sub-iot-stack HOT 15 CLOSED

from sub-iot-stack.

You are correct, this is broken. We played with DASH7-over-LoRa in the past but the implementation got removed in the radio driver later on during some refactoring. The other occurrences of PHY_CLASS_LORA should have been removed as well indeed.

Coincidentally, we are working on adding it to the driver again (in an offline branch, should be merged beginning of next week). The reason we are adding it to the driver again is not for using DASH7-over-LoRa but mainly because we need LoRa modulation as well for CE certification, and if it supported by the sx17x driver used by D7 stack we can reuse the engineering mode to drive the tests.

PHY_CLASS_LORA was added for testing to see what range we could get and what trade-offs we would encounter when running DASH7-over-LoRa. Basic foreground communication was working, but background communication (advertising and low power listening) would require more validation if it actually makes sense to use this over LoRa (low power listening uses energy detection on D7 as a way to scan the channel very efficiently, while in the case of LoRa this would only work on short range (loosing the benefit of LoRa). LoRa's channel activity detection method may be used but this might consume too much energy to be feasible).
So it is unclear if it makes sense to continue with DASH7-over-LoRa, especially since the D7 Alliance will not add a proprietary modulation to the spec. The D7 Alliance is currently looking into adding a ultra low rate FSK option as well, which might close the gap a bit with LoRa while not requiring proprietay modulation.

What is your use case by the way?

from sub-iot-stack.

Ah good, so I am not crazy. Thanks for the background information. I am happy to test the new LoRa patch when it comes available.

Regarding our use case. Right now we're evaluating DASH7 for a project where we will have 10-1000s of wireless battery powered sensors in a building. They would only need to send some data once per day with a very rare config or firmware update. The battery should last 1-3 years. And the number of gateways should be minimized to save cost.

So I think we only need push communication.

Next week we want to do range vs power consumption experiments to figure out which batteries would be needed for what range requirements. Therefor we would also like to use the LoRa modulation to be able to paint the complete picture. Because there is also the trade-off for the number of gateways to make.

Also, I was wondering, is it not possible to use LoRa modulation with very low Tx-power if you don't need long range? Or is FSK still more energy efficient then?

from sub-iot-stack.

LoRa PHY should now work since current master. Default it is using SF9 and BW 125 kHz, this can be modified in the FactorySettingsFile in the python template of the filesystem.

Next week we want to do range vs power consumption experiments to figure out which batteries would be needed for what range requirements. Therefor we would also like to use the LoRa modulation to be able to paint the complete picture. Because there is also the trade-off for the number of gateways to make.

Interesting tests. I would think that the datarate en TX power used has a very low impact on the total lifetime if you only send once a day, compared to the proportion of energy used during sleep.

Also, I was wondering, is it not possible to use LoRa modulation with very low Tx-power if you don't need long range? Or is FSK still more energy efficient then?

Should be possible yes. What the best option is depends on your battery I guess. Consumption itself easy to measure, but the impact of a certain load (current, time, off-time) on the battery is something else. If you put too much load on the battery the net capacity can decrease drastically. Your battery vendor might be able to simulate this, or you can add a supercap to reduce the burden on the battery.

from sub-iot-stack.

Closing for now since this should be fixed. If not, please re-open

from sub-iot-stack.

Hi @glennergeerts-aloxy, I was just testing this. However I am not sure it is working for me yet.

I created the lora channel header and access profile and added it as Access Profile 4:

lora_channel_header = ChannelHeader(
  channel_class=ChannelClass.LORA,
  channel_coding=ChannelCoding.FEC_PN9,
  channel_band=ChannelBand.BAND_868
)

# AP lora modulation, used for push only, no scanning
ap_lora_no_scan = AccessProfile(
  channel_header=lora_channel_header,
  sub_profiles=[SubProfile(subband_bitmap=0x00, scan_automation_period=CT.compress(0))] * 4,
  sub_bands=[SubBand(eirp=default_eirp, channel_index_start=default_channel_index, channel_index_end=default_channel_index)] * 8
)

...
  AccessProfileFile(4, ap_lora_no_scan),
...

Then I select this profile in the sensor_push.c example with Access Class 0x41:

void bootstrap()
{
    log_print_string("Sensor Push: Device booted\n");

    d7ap_init();

    d7ap_fs_write_dll_conf_active_access_class(0x41);

    alp_init_args.alp_command_completed_cb = &on_alp_command_completed_cb;
    alp_init_args.alp_command_result_cb = &on_alp_command_result_cb;
    alp_layer_init(&alp_init_args, false);
...
}

It compiles and flashes. I confirmed the eeprom contents with GDB. It has the channel header 0x36 which corresponds to BAND_868 (0x30) FEC_PN9 (0x02) and LORA (0x01) OR'ed together

(gdb) x/8x 0x8080F98
0x8080f98 <d7ap_files_data+924>:        0xffff2324      0x41000000      0x41000000      --->0x00000036 <---
0x8080fa8 <d7ap_files_data+940>:        0x00000000      0x00000000      0xff560e00      0x00000000

However when I test it with the regular gateway example, it still receives the messages from the sensor. Even though the gateway runs on FSK and the Sensor on LoRa modulation. At least that's what I am aiming for.

Am I forgetting something? or how can I be sure LoRa is actually used. Is there maybe a simple DASH7 with LoRa encoding example available?

from sub-iot-stack.

Hi @ijager, you changed the access profile used for scanning but not for sending.

Sensor_push uses two different access profiles, one for scanning and one for sending. The scanning access profile is set in the filesystem in DLLConfigFile but can indeed be overwritten using the function stated above. The sending access profile however can only be set in the d7ap_session_config which is configured at the top of sensor_push.c.

Something to watch out for is the fact that the gateway's scanning access profile and the sensor's sending access profile should be exactly the same in order to receive the messages.

Hope this helps, let me know if you encounter any problems.

from sub-iot-stack.

Thank you. I did miss the part about different profiles for scanning/sending, this brings me a step closer!

So far I have confirmed that changing default_eirp definitely has an effect on the range. However I did a few quick tests and I didn't notice any difference in range and link budget (max 120) between ChannelClass.LO_RATE and ChannelClass.LORA at the same eirp. So I am still a bit sceptical whether it is really using LoRa modulation or not. Tomorrow I will do some power measurements to be more sure.

What I also found out is that the same profiles on different slots (e.g. 0 and 5 below) don't seem to work together. For example, if the gateways is scanning on Profile 0 (access_class=0x01)(ap_cont_fg_scan) and the endpoint is sending on Profile 5 (access_class=0x51) (ap_cont_fg_scan) messages are not received. Is this supposed to work like that?

  AccessProfileFile(0, ap_cont_fg_scan),
  AccessProfileFile(1, ap_bg_scan),
  AccessProfileFile(2, ap_no_scan),
  AccessProfileFile(3, ap_lora_cont_fg_scan),
  AccessProfileFile(5, ap_cont_fg_scan),

from sub-iot-stack.

The rssi-value of Lora is not reliable at high values for now. I tested it myself and found low rate has a sensitivity of ~117 while Lora using SF9 125kHz has a sensitivity of ~127 (these are not accurate but mostly a guideline). The software is not optimized yet to show accurate rssi values though, I am currently working on improving this by combining SNR and Rssi values.

When receiving a message, the gateway will filter out messages that are not from exactly the same access class, this is indeed supposed to work like that. Scanning of 0x51 will physically receive messages with the same settings but will filter out all messages with a different access class (e.g. 0x01).

from sub-iot-stack.

In the newest commit of oss-7, the rssi value of Lora should be more accurate. The formulas in the datasheet are applied but there's still some optimizing to do, therefore the values are more to be used as a reference instead of something absolute.

The datasheet says without these optimizations, the rssi-values will not be linear, which means the higher the link budget, the higher it will diverge from the real value.

from sub-iot-stack.

We got it working. Turns out that LoRa with high Tx will result in current peaks too high for coin cell batteries, which was consistent with things I read online.

We did some tests with different types of batteries, to see how they perform during Tx. We got the following results for DASH7 (FSK, payload=88 bytes), with Tx=14dBm and Tx=20dBm (configured in d7ap_fs_data.c)

The results are more similar than I expected, which might be due to the batteries not able to source more current. We will probably limit to 14dBm anyway, since the range is already good enough.

With this data we could make a conservative estimate for battery life for DASH7-based sensors, with the following assumptions/settings.

Number of sensor measurements per day: 24
Number of data transmissions per day: 1
Duration of data transmission: 0.5s
Extra safety factor: 1.5x (to cover uncertainties)

@glennergeerts-aloxy was correct that the power consumption during deep sleep mode is way more significant than the Tx power when only transmitting once per day.

from sub-iot-stack.

from sub-iot-stack.

Thanks for the detailed feedback!

The results are more similar than I expected, which might be due to the batteries not able to source more current. We will probably limit to 14dBm anyway, since the range is already good enough.

Indeed it seems the batteries cannot source the current required. For 20 dBm you should pull about 120 mA. Also, the peak current for D7 and LoRa for a certain output power will be equal, but the duration of the load will differ and this might cause problems with the batteries. For instance the start of the packet might be transmitted at a higher power but the power might collapse when the battery is not able to deliver this peak load for the full duration.

from sub-iot-stack.

Yes, good point @maartenweyn. I will certainly consider it, but I think it is cheaper to put two batteries in parallel than to add a supercap.

from sub-iot-stack.

Must be an interesting course! Thanks for the figures. Our application would be between 30-50mA pulses.

We did apply a factor to compensate for the lower effective capacity. Not very scientific and quite conservative, but good enough I think (We don't want to over-promise to our client). This sheet shows is how we estimated it.

from sub-iot-stack.