Is LBT implemented in libmdot?
- This topic has 13 replies, 2 voices, and was last updated 7 years, 11 months ago by
.
-
Dear Jason,
OK. Thank you for your quick response.
Now, I understand.
So, how can I explain the 40-55% PER?
If time-on-air of an SF12 node frame is about 1.3 seconds, if the mDot only uses 3 channel, and there is an interferer like another SF7 node sending with a period of 15 seconds, the probability of collisions should be very high.
Does this testbed explains the high PER and the responsible for this is the no LBT LoRaWAN end node?
Or I have to search the cause in the gateway? Can SX1301 or MultiTech mCard firmware be the cause of this behaviour? Can they ear and process two frames simultaneously, in same period of time?
Has there been any change or firmware update in mCard? I had purchased the Conduit gateway in July of 2015. If there is a firmaware new version, can I upgrade it by myself? Or is there any mCard replacement under warranty?
Thank you and regards,
Guillermo Garia
The nodes are about 10 meters from the gateway. With distances of the SF12 node >20m the beahviour is the same.
We have configured ACKed frames, and the ACK downlink is in RX2 window (869.525MHz channel).
I have checked the firmwares in downloads page link. We are working with a Loriot’s packet-forwarder, no with MultiTech’s original Linux applications.
Nevertheless, I was asking for the firmware of the mCard, because I suppose that the mCard itself has a MCU connected to the SX1301 Base Band Processor (another microcontroller different from the Conduit’s ARM9). Isn’t it?
Thanks,
Guillermo
Dear Jason,
We have been evaluating our LoRaWAN system during last month. We have obtained results that concern us and we have doubts about reabillity of this LoRa system.
The system parts are:
– mDot node with SF12: mbed application based in libmdot library that sends uplink frames every 3 minutes and waits for ACK (reception in RX2 window because the latency in 2G-3G connection is high).
– mDot node with SF17: mbed application based in libmdot library that sends uplink frames every 15 seconds and waits for ACK.
– Multi-Tech Conduit gateway with LORIOT gateway binary loriot_multitech_conduit_mCard_USB_1.0.1.tgz.
– Loriot Network server with comercial account.With Loriot’s API we have programmed an application that takes data and saves them in a database. We can calculate the PER (Packet Error Rate) and present graphs with temperature, the gateway’s RSSI (GW RSSI) and the RSSI meassured by the mDot in ACK frames (RSSI). When any frame is lost the RSSI value is presented like 0dBm.
Test 1: Only mDot SF12 node sending frames.
In next two graphs you can see the values obtained with this node locating it in different positions during a few days.
The PER is too high (2-6 %). If the node and the gateway are so near and there is only one mDot transmitter, if LoRa is a modulation with low susceptibility to interference, if the spread factor is SF12 with redundancy and error correction, and the 868 MHz band in my environment is clean…, I would expect lower PER, around 0.1% or less.
Most of the lost frames sent by mDot are not arriving to the Gateway, so neither to the server. I am sure that the frames are lost between mDot and Gateway, because I have monitored the log of “loriot_multitech_conduit_mCard_USB_1.0.1”, and those frames are not appearing. The problem could reside in mDot, in the gateway’s LoRa mCard or in the Loriot’s packet forwarder executable.Another curious behaviour is in the Gateway meassured RSSI with this spread factor SF12. As you can see, the GW RSSI has variations in time, however the RSSI meassured by the node is very stable. It is striking that this behaviour is repetitive with a period of exactly 14 hours in gateway (14 hours noisy and 14 hours stable). Is there any explanation for this behaviour? Any bug in gateway implementation?
29/04/2016 – 2/05/2016, SF12 PER 2.89% (1500 total frames)
29/04/2016 – 6/05/2016, SF12 PER 3.44% (3400 total frames)
3/06/2016 – 6/06/2016, SF12 PER 5.5% (1252 total frames)
Test 2: Only mDot SF7 node sending frames.
In next graph you can see the values obtained with this node locating it in different positions during 5 days.
With SF7 the PER is less than with SF12. But we still think that the PER is too high considering that the distance between node and gateway is very short, less than 10 meters. We expected about 0%.10/05/2016 – 14/05/2016, SF7 PER 0.66% (20680 total frames)
Test 3: mDot SF7 and mDot SF12 nodes sending frames simultaneously.
In next two graphs you can see the values obtained with the two nodes during some hours in different days. The RSSI meassured by the two nodes are presented in same graph. The nodes and the gateway are near, less than 10 meters between them.
The PER is drastically incremented in the two nodes, and much of the SF12 node frames are lost. Can mCard ear two channels at the same time and process two frames? Can Multitech’s or Loriot’s gateway firmware manage frames in different channels simultaneously, and forward them to Loriot server? As we have discussed above, another cause could be that the uplink reception thread and the downlink thread would be blocking processes, or that the packet-forwarder waits to transmit de queued downlink to take other frames from SX1301. Do you know if there have been any mCard firmware update by Multitech? The new SX1301 Calibration firmware could have any relation with this?10/05/2016 (7:15 – 16:36), SF7 PER 2.05% (1907 total frames), SF12 PER 57.07% (191 total frames)
17/05/2016 (12:00 – 17:47), SF7 PER 1.96% (1175 total frames), SF12 PER 38.92.07% (167 total frames)
In the next test, I will analyze PER without ACK in SF7 node, and the SF12 node with the ACK on. I will send you the results.
Thank you and regards,
Guillermo
- You must be logged in to reply to this topic.