Comments (10)
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.
Related Issues (20)
- noise_logger.c compile fails - userbutton.h not found HOT 2
- sniffer.c compile fails - alp_cmd_handler.h not found HOT 1
- I2C on B_L072Z_LRWAN1 platform HOT 2
- Sensor Action example: assertion "is_fs_init_completed" failed HOT 1
- Sensor Action example: incorrect value in RTT logs HOT 4
- STM32 hw_get_unique_id() bug HOT 4
- Gateway software ? HOT 1
- RTT Logging does not work well with Sleep
- Performance results available? HOT 1
- Bug scheduling messages in the unsollicited response callback HOT 8
- Board resets when sending message using default access class at index 1 set to normal rate. HOT 6
- Scheduler hangs when scheduling a task through interrupt service routine HOT 1
- Unkown hardfault when running C++ on B-L072Z-LRWAN1 HOT 2
- Enforce .clang-format
- Assertion fail in timer_fired() HOT 5
- Some compiler flags that cause errors now that might be worth it to be fixed HOT 2
- ALP_ITF_ID_D7ASP interface config format doesn't seem to match spec (same with pyd7a impl) HOT 2
- One-Hop Routing HOT 2
- ALP layer: unsolicited commands are sent back in the response HOT 1
- Compilation Error while running make HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sub-iot-stack.