Compatibility with Wizzilab stack about sub-iot-stack HOT 10 OPEN

Hi, Glad to see you back!

The main problem with the compatibility between this stack and Wizzilab is that this stack is still in development. The mode where we are constantly switching between channels at intervals instead of continuously scanning on one channel (which we call channel diversity) is not yet implemented in the master of this stack. However, we've been working on this in a separate branch, this branch is currently working but we are still testing it before pushing it to master. You could try this branch and let us know if you see any problems occurring.

Channel diversity is tested only between oss-7 devices and on certain time-intervals so there could still be problems there and perhaps it's best to first test with two oss-7 devices before testing between oss-7 and Wizzilab but I'm very curious about the results, please let us know!

Other issues I noticed in your code are:

• subband_bitmap is set to 0x05, this only activates the first and third Subband while you are trying to activate the first three. To make this more clear, I advise you to write this number as a bit-number. The number you are searching for is then 0b00000111.
• The scan automation period you set does not match the scan period of wizzilab. The scan automation period indicates the time in between two scans but also how long the transmitter has to advertise before sending the actual data. This time is put in ticks (1 seconds = 1024 ticks), therefor a scan period of 1/32s would result in scan automation period of 1024 / 32 = 32 ticks.

If there are any other problems you encounter, please be sure to let us know!

from sub-iot-stack.

Thank you for the feedback. Unfortunately even with the correct subband_bitmap and scan period it still doesn't get picked up by the wizzigate or vice versa. Maybe I can get my hands on a spectrum analyzer to compare the signals.

I will try the new branch now and report back later.

BTW I believe the python repo is not updated yet, since it is missing DllStatusFile

raceback (most recent call last):
  File "d7ap_fs_data.c", line 46, in <module>
    from d7a.system_files.dll_status import DllStatusFile
ImportError: No module named dll_status

from sub-iot-stack.

Connection with the Wizzigate is not possible without the new branch. I also updated PYD7A to the newest version including the file used in the new branch. Let me know if it works.

from sub-iot-stack.

Both the gateway as well as the sensor_push app have some troubles on the new branch so far.

The gateway doesn't connect to unsolicited_response_logger.py:

$ PYTHONPATH=. python -u examples/unsolicited_response_logger.py -d /dev/cu.usbmodem14403
2020-03-12 14:34:24,958 modem.modem  INFO     starting read thread
2020-03-12 14:34:24,978 modem.modem  INFO     Sending command of size 17
2020-03-12 14:34:24,978 modem.modem  INFO     Waiting for response (max 10 s)
2020-03-12 14:34:35,021 modem.modem  INFO     Command timeout (tag 195)
2020-03-12 14:34:35,021 modem.modem  WARNING  Timed out reading node information

The sensor crashes at the fs. I am getting this exception in the serial console:

14:48:10:720 [000] Device booted
14:48:37:781 assertion "e == SUCCESS" failed: file "dash7-ap-open-source-stack/stack/framework/components/fs/fs.c", line 261, functio

In the debbugger I can see that it crashes on the assertion while trying to read file_id=11, which is the new DLL_Status file.

Both cases are without MODULE_D7AP_USE_CHANNEL_HOPPING set.
If I revert back to master but keep the current filesystem it works again.

from sub-iot-stack.

Did you reload the cmake settings in the newest branch? DllStatusFile is set as a volatile file and needs room. That's why the cmake option for FRAMEWORK_FS_VOLATILE_STORAGE_SIZE changed from 57 to 85. I think in your case, this option is still at 57 resulting in an assert. To connect to the Wizzilab gateway, you need to enable the MODULE_D7AP_USE_CHANNEL_HOPPING option.

from sub-iot-stack.

Aah yes, rebuilding CMake helps. Now I have successful communication between OSS-7 device and gateway on multiple channels. It does seem like packets are missed. Success rate is maybe 1 in 4 tries:

16:17:01:203 [019] response payload:
16:17:01:200 [018] 42 31 35 34 00 4B 00 3D
16:17:01:198 [017] recv response @ 30 dB link budget from:
16:17:01:193 [016] Command failed, no ack received
16:16:29:918 [015] Command failed, no ack received
16:15:50:792 [014] Command completed successfully
16:15:20:272 [013]
16:15:14:742 [012] response payload:
16:15:14:740 [011] 42 31 35 34 00 4B 00 3D
16:15:14:737 [010] recv response @ 32 dB link budget from:
16:15:14:733 [009] Command failed, no ack received
16:14:41:151 [008] Command failed, no ack received
16:14:02:024 [007] Command failed, no ack received
16:13:22:897 [006] Command completed successfully

Next step is to change the AP parameters again to match the wizzilab gateway. However as soon as I switch to NORMAL_RATE, the sensor_push app will crash.

I am using the following settings:

wizzilab_channel_header = ChannelHeader(
  channel_class=ChannelClass.NORMAL_RATE,
  channel_coding=ChannelCoding.FEC_PN9,
  channel_band=ChannelBand.BAND_868
)

ap2_wizzilab = AccessProfile(
  channel_header=wizzilab_channel_header,
  sub_profiles=[SubProfile(subband_bitmap=0b00000111, scan_automation_period=CT.compress(32, ceil=False))] * 4,
  sub_bands=[SubBand(eirp=default_eirp, channel_index_start=channel_index_0, channel_index_end=channel_index_0, cca=80),
             SubBand(eirp=default_eirp, channel_index_start=channel_index_1, channel_index_end=channel_index_1, cca=80),
             SubBand(eirp=default_eirp, channel_index_start=channel_index_2, channel_index_end=channel_index_2, cca=80),
             SubBand(eirp=default_eirp, channel_index_start=channel_index_3, channel_index_end=channel_index_3, cca=80)] * 2
)

And this is the stack trace:

#0  __assert_func (
    file=file@entry=0x8017564 "stack/framework/hal/chips/sx127x/sx127x.c", 
    line=line@entry=546, func=func@entry=0x801747c <__func__.10300> "fifo_level_isr", failedexpr=failedexpr@entry=0x8013fa4 "false")
    at stack/framework/hal/platforms/NURTIO1/libc_overrides.c:72
#1  0x0800bbba in fifo_level_isr ()
    at stack/framework/hal/chips/sx127x/sx127x.c:546
#2  0x0800de9c in scheduler_run ()
    at stack/framework/components/scheduler/scheduler.c:385
#3  0x080078ea in main ()
    at stack/framework/hal/platforms/NURTIO1/platf_main.c:117

Which means it detects an underflow

//sx127x.c
542:    // detect underflow
543:    if (flags & 0x08)
544:    {
545:        DPRINT("FlagsIRQ2: %x means that packet has been sent! ", flags);
546:        assert(false);
547:    }

But I guess this hasn't been tested yet

from sub-iot-stack.

indeed, I've seen this happen before with rates higher than low rate but this hasn't been solved yet. I will be trying to fix this in the future but I'm too busy for this feature right now. Thank you for letting us know!

from sub-iot-stack.

Are there any LOG sources enabled in cmake? Maybe disabling all logging can already help with this? Do you have the possibility to adapt the Wizzilab AP to lo-rate btw?
Otherwise we indeed need to make normal rate with background sync work on oss-7. We need to do compatibility testing with Wizzilab again in the future, until now only foreground has been tested.

from sub-iot-stack.

I will try to disable the LOG sources, see if that helps for normal rate. I have indeed tried configuring the wizzilab gateway and devices to LO-RATE. They work with each other on LO_RATE but not with OSS-7. So I am not sure what other variables are in play here to let them talk to each other.

Same AP. Rate, frequency bands, channel header, channel_index, subband_bitmap, scan_period. They're all the same. So I run the unsolicited_response_logger, then I power on a wizzilab SH2050. I would expect some output from the gateway, or an ACK. But the SH2050 gives an D7A_ERROR_NO_ACK.

I must be missing something, but I am not fluent in dash7 yet. Maybe later when I am more familiar with this stack I could also look into helping improving things. Do you have something like a roadmap? Or contribution guidelines?

We wanted to start out with an off-the-shelve gateway to save some development time initially. But it starts to look like we'll need to build an OSS7 gateway instead. Does Aloxy sell a gateway maybe?

from sub-iot-stack.

I will try to disable the LOG sources, see if that helps for normal rate. I have indeed tried configuring the wizzilab gateway and devices to LO-RATE. They work with each other on LO_RATE but not with OSS-7. So I am not sure what other variables are in play here to let them talk to each other. Same AP. Rate, frequency bands, channel header, channel_index, subband_bitmap, scan_period. They're all the same. So I run the unsolicited_response_logger, then I power on a wizzilab SH2050. I would expect some output from the gateway, or an ACK. But the SH2050 gives an D7A_ERROR_NO_ACK.

Any idea if the wizzilab Gateway requires network layer security by default? Can you turn it off?
Maybe it is easier to first test the other way around: use an OSS-7 gateway and try to receive a Wizzilab device. If it uses encryption for instance it should be visible in the logging on the gateway side. If you enable MODULE_D7AP_PHY_LOG_ENABLED, MODULE_D7AP_DLL_LOG_ENABLED and FRAMEWORK_PHY_LOG_ENABLED, what do you see?

I must be missing something, but I am not fluent in dash7 yet. Maybe later when I am more familiar with this stack I could also look into helping improving things. Do you have something like a roadmap? Or contribution guidelines?

That would be great. We need to make it easier for external contributions indeed, for now the roadmap is mostly internal. We are in the process of proposing the project to become part of Eclipse IoT umbrella, which will also means we need to improve procedures wrt contributors.

We wanted to start out with an off-the-shelve gateway to save some development time initially. But it starts to look like we'll need to build an OSS7 gateway instead. Does Aloxy sell a gateway maybe?

At the moment this is not the goal of Aloxy to do this. We only sell gateways as part of a solution for industrial IoT and connected to our IoT Hub.

from sub-iot-stack.