Pre-certification should always failed due to duty-cycle limitation
Closed this issue · 2 comments
Board: Custom
Stack version : 4.7
Lora spec : 1.0.4
Test instrument : redwood RWC5020M
Region : EU868
I'm trying to pass the certification process but my device failed each time because "DUT did not send any uplink". It appears that my device does not send the uplink because of the duty-cycle limitation. My device is always blocked in the same test (4.2.A), so I checked the credit time I consume on each channel only when the duty cycle is ON and I summarize everything on this table below:
| Channel | 0 | 1 | 2 |
|---|---|---|---|
| Consumed credit(ms) | 19761 | 15199 | 13876 |
| Test time(ms) | 1986000 | --- | --- |
| Ratio (%) | 0.995 | 0.765 | 0.698 |
As the certification process need 5s periodic uplink with any payload length (5 in my case), this is mandatory to enter in a duty cycle issue.
So, am I wrong with my calculation ? The test process could be done with some delay between each test ? The uplink period should be much larger than 5s ? Something incorrect in the test process or the test instrument ?
Thank you for any answer
I have tested with a nucleo-wl55jc1 with the example code and I have the same is issue.
Using the official LoRa Alliance certification tool LCTT v2.6.0 with technology package v3.11.0_R1all EU868 tests have passed. Please refer to attached loramac_node_master(6384af8f4c4a57016c83f3d34430f0f68855e695)_nucleol476_sx1261mb2xas_eu868.pdf
full test report.
The tests were run using the current master branch commit 6384af8 on a NucleoL476+SX1261MB2BAS platform.
I have also run the same test sequence as the one you reference (4.2.A), at least I think it is the same, in standalone mode and it succeeded as well.
Please refer to the attached BV_004_Result.TestCase.pdf file.
Therefore I think that the observed problem is either with your porting of this project or with the RedwoodComm RWC5020M test instrument.
As a final note, all LoRaWAN test sequences have been specified by the LoRa Alliance in such a way that duty-cycle restrictions should never happen. Every time a test sequence is supposed to trig a duty-cycle restriction there is a specific test step which disables the duty-cycle restriction on the end-device.
If you don't mind I close this issue.