Hi All, I am resending this mail because nobody responded. Can please somebody look on this issue?
Regards Ondrej Pilat Dne 6/9/2020 v 10:22 AM Ondrej Pilat napsal(a): > > Hi All, > > Is it possible to tell Nimble to send only 1 or 2 packets per each > connection event when Nimble is as peripheral? I have application > which serves as 1 to X bridge (X can be up to 18). I need to restrict > connection between PC and the NRF52 to send only 1 to 2 packets per > connection event otherwise it uses to much from the throughput that > connection between nrf52 and 18 devices cannot have interval window 60 > to 120ms. Instead they are communicating with 300 to 500ms period. > > From previous communication: > > /My assumption are following:/ > > // > > * /only one packet per each connection event/ > * /send/receive 132B packet between NRF52 and PC each connection event/ > * /send/receive 20B packet between NRF52 and peripheral each > connection event/ > > // > > /I made following rough computation:/ > > // > > /PC <-> NRF52: 132B data + 21B header => (153B * 8) / 1Mbps => 1224 uS > + 150 uS IFR + 80 uS ACK + 150 uS IFR => 1604 uS * 2 (send/receive) => > 3208 uS // > / > > // > > /NRF52 <-> peripheral: 20B data + 21B header => (41B * 8) / 1Mbps => > 328uS + 150 uS IFR + 80 uS ACK + 150uS IFR => 708uS * 2 (send/receive) > => 1416 uS/ > > /It means one big and six small packets should fit in each PC <-> > NRF52 connection event 3208 + 6 * 1416 = 11 704 < 12.5ms interval > window. For 18 peripherals it means 3 such cycles to serve them all > therefore 37.5ms interval window between NRF52 and a peripheral. > / > > /On this I received response:/ > > You need to take NimBLE scheduling into account here. Each connection event > is preallocated a fixed amount of time in 1250us slots - see > BLE_LL_CONN_INIT_SLOTS. This means effectively connection events cannot be > scheduled less than 1250us apart. Also, scheduler overhead is ~200us (for > nRF52, may be different for nRF51) for each connection event so effective > connection event time with 1 slot allocated is 1050us. Note that this is > min time since connection events can be extended pretty much indefinitely > as long as there is no other activity scheduled so e.g. until another > connection event. > > I do not know if "20B packet" means "20 bytes of LL payload", but will > assume so since we are talking LL level here. This can fit into a single > scheduled slot: 240us + 150us + 80us = 470us < 1050us. Let's assume 1ms for > each connection event including scheduler overhead so you need 18ms to > serve all 18 devices in one direction. If you need to send data in both > directions you need 240us + 150us + 240us = 630us < 1050us so nothing > changes and you still have quite a lot of extra time to spare in each > connection event (e.g. for retransmissions). It will be a bit different if > you need to transfer data in both directions in separate connection events > as basically you need twice as much connection events, this means you need > at least 36ms to serve all peripherals. One possible problem here is that > connection may not be scheduled exactly 1.25ms apart and this will create > gaps where no connection can be scheduled, you can't really control this > with default scheduler. Possible solution would be to use > BLE_LL_STRICT_CONN_SCHEDULING which schedules connections in central role > at fixed intervals, although I never used it so not sure if there's > anything that requires more configuration than just enabling this feature. > > When I take these information in account I get that Nimble should be > able to have: > 10ms interval window between a PC and NRF52 (Nimble is as peripheral) > 60ms interval windows with 18 devices (Nimble is as central device) > > I am not able to achive such values. Attached is sniffed communication > between PC and NRF52 which shows that there is no space left for the > other devices to communicate with 60ms windows. During my tests the > Nimble is sending packets betwen NRF52 and devices with 300ms to 500ms > period although interval windows is set to 120ms with them. > > Best regards > Ondrej Pilat > > -- --
signature.asc
Description: OpenPGP digital signature
