problems sending class C multicast downlinks

[PawelOstropolski]

Hi, I'm getting the bellow, when scheduling the downlink packets for the temporary multicast session created by Chirpstack FUOTA -v3 deployments. None of the several downlink packets gets on air. It is an RPI + RAK2287 based gateway we use broadly in R&D. Have been using it for months with class A and Class C devices with no issues, but suddenly experienced the below when introduced multicasting. Anything that would immediately ring a bell here? Thanks.

Station Ver : 2.0.6(corecell/std) 2022-04-14 11:20:56

2023-10-26 22:50:24.839 [AIO:XDEB] [6|WS] < {"msgtype":"dnmsg","DevEui":"01-01-01-01-01-01-01-01","dC":2,"diid":23944,"pdu":"60b87429b9000200c9ac8cb22d450ecbc424620e049f147dfeea2d82f9c231eb35a039b5f54725e6d38d34d7f4a99e5e","priority":1,"RX2DR":5,"RX2Freq":868100000} 2023-10-26 22:50:24.840 [S2E:WARN] RxDelay mapped to 1 as it was not present! 2023-10-26 22:50:24.840 [S2E:VERB] 101:101:101:101 diid=23944 [ant#0] 868.1MHz - no DC in band: txtime=22:50:24.859 free=22:50:33.295 2023-10-26 22:50:24.840 [S2E:VERB] 101:101:101:101 diid=23944 [ant#0] 868.1MHz - no DC in band: txtime=22:50:24.959 free=22:50:33.295 2023-10-26 22:50:24.840 [S2E:VERB] 101:101:101:101 diid=23944 [ant#0] 868.1MHz - no DC in band: txtime=22:50:25.059 free=22:50:33.295 2023-10-26 22:50:24.840 [S2E:VERB] 101:101:101:101 diid=23944 [ant#0] 868.1MHz - no DC in band: txtime=22:50:25.159 free=22:50:33.295 2023-10-26 22:50:24.840 [S2E:VERB] 101:101:101:101 diid=23944 [ant#0] 868.1MHz - no DC in band: txtime=22:50:25.259 free=22:50:33.295 2023-10-26 22:50:24.840 [S2E:VERB] 101:101:101:101 diid=23944 [ant#0] 868.1MHz - no DC in band: txtime=22:50:25.359 free=22:50:33.295 2023-10-26 22:50:24.840 [S2E:VERB] 101:101:101:101 diid=23944 [ant#0] 868.1MHz - no DC in band: txtime=22:50:25.459 free=22:50:33.295 2023-10-26 22:50:24.840 [S2E:VERB] 101:101:101:101 diid=23944 [ant#0] 868.1MHz - no DC in band: txtime=22:50:25.559 free=22:50:33.295 2023-10-26 22:50:24.840 [S2E:VERB] 101:101:101:101 diid=23944 [ant#0] 868.1MHz - no DC in band: txtime=22:50:25.659 free=22:50:33.295 2023-10-26 22:50:24.840 [S2E:VERB] 101:101:101:101 diid=23944 [ant#0] 868.1MHz - no DC in band: txtime=22:50:25.759 free=22:50:33.295 2023-10-26 22:50:24.840 [S2E:VERB] 101:101:101:101 diid=23944 [ant#0] 868.1MHz - no DC in band: txtime=22:50:25.859 free=22:50:33.295 2023-10-26 22:50:24.840 [S2E:VERB] 101:101:101:101 diid=23944 [ant#0] - class C out of TX tries (11 in 1s100ms) 2023-10-26 22:50:24.840 [S2E:WARN] 101:101:101:101 diid=23944 [ant#0] - unable to place frame

[beitler]

Hi @PawelOstropolski ,

the error message points at duty cycle exhaustion in your band. By default, station enforces access to the spectrum according to regulatory requirements. This means, that station will block transmission if a particular duty cycle threshold is reached. You can disable the enforcement of duty cycle restrictions when building station in with variant=debug and setting the nodc flag to true inside station.conf (have a look at the doc). Can you confirm that the downlinks are properly placed when disabling duty cycle enforcement?

[PawelOstropolski]

Hi Anton, thanks for the reply. Yes, with did check the devel settings i.e. disabling DC checks and the packets are going through. What is worrying though is that we also checked it on 867.100 MHz - a non standard, less used ch - and the situation is the same - all C multicast downlinks are blocked - with BS stack throwing DC thing.... In fact on both GW with just a single device and a more loaded GW in our central test lab with multiple sensors, it is the same. We also performed an experiment with Tektelic Enterprise production GW - it uses classic semtech forwarder protocol in our setup - with the same network server - and the packets are going through to the air no problem - with no hacks.... Woudl you have any suggestions where to look next ?