[Guillermo Glaria]

Hi,

No, I am using a proprietary design with STM32+SX1276, and we are studing to use a Murata’s LoRa module in next coming projects.

The long distance and attenuation of obstacles are the reason to use modulation in the range of SF10 to SF12.

[Guillermo Glaria]

Thank you for your quick answer.
So the Conduit Gateway could initiate the message sending to an address simulating multicast if all the nodes have configured this address and accept messages with this, isn’t it?

But is there any broadcast address defined in LoRa standar?

And with this strategy, should I configure all nodes to listen in SF12 modulation to receive the broadcast?

Thank you and regards,

Guillermo

[Guillermo Glaria]

Hi,

Yes I have the SNR data and it is stable.

In my case the RSSI is not dropping, the meassurement is unstable and noisy.

I had done the test with a laboratory DC power source to discard any interference from the 220Vac power network. The result was the same periodic behaviour.

If the period would have been in exactly same time, hour and minute, I could think in an environmental cause. 14 hours period is very unusual.

Which is the period you have detected? Is your testbed with a 2G-3G connection Conduit Gateway?

Thanks,

Guillermo

[Guillermo Glaria]

Hi Jason,

I have done the test with ACK and without ACK.

SF12 node with confirmed uplink and SF7 node without unconfirmed uplink: The PER in SF12 is 3,6%, 55 packets and 2 lost.

SF12 and SF7 nodes with confirmed uplinks: The PER in SF12 is 56%, 30 packets and 17 lost.

My conclusion is that the half-duplex characteristic of the gateway is the responsible of this behaviour. So, the reability of a LoRaWAN network with ACKs or downlink packets is very low and the capacity of a gateway goes down drastically. It could be another reason in Loriot’s firmware, but the prime cause is that gateway doesn’t ear while downlink packets are processing.

Is there any full-duplex gateway in market?
I will open the support ticket.

Thank you and regards,

Guillermo

[Guillermo Glaria]

Hi Jason,

I have found a discussion in the below forum, and they talk about limitations in a LoRaWAN gateway. It could be interesting to understand our behaviour.

http://forum.thethingsnetwork.org/t/universal-lora-wan-gateway-limitations-because-physics/1749

Guillermo

[Guillermo Glaria]

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

• This reply was modified 7 years, 11 months ago by Guillermo Glaria.

[Guillermo Glaria]

Hi,

I have been studing the basic packet-forwarder implementation of Semtech and patches that MultiTech has added to 1.4.1 version.

I understand that the mCard is a half-duplex hardware design, and that any TX will loss an RX in progress, but only in the RX2 window moment. The ACK transmitted to the SF7 will be time-on-air of few miliseconds. So the probability of collission between the downlink frame with the SF12 node uplink frame is very low, in 15 seconds about 8% and no 40-50%. This doesn’t explain the high PER of SF12 node.

Another cause could be that the 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.

Are there full-duplex LoRa gateway designs in the Market? Has MultiTech any of those in its portfolio or roadmap?

Thank you and regards,

Guillermo

[Guillermo Glaria]

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

• This reply was modified 7 years, 11 months ago by Guillermo Glaria.

[Guillermo Glaria]

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

• This reply was modified 7 years, 11 months ago by Guillermo Glaria.

[Guillermo Glaria]

Hi Mike,

I have the “LA” ones. Which sleep consumption do I have to expect in those LA mDots?

Is that the only change, the regulator chip?

We are envolved in a project and I want to validate the low energy characteristics of LoRa, and I need the modules to continue with the implementation. Is there any warranty of replacement of the defective units with another six LB version mDots?

Regards,
Guillermo

[Guillermo Glaria]

Hi Jason,

I want to know which are the pins connected between STM32F4 and SX1272. As example, which are the antenna switch GPIOs? Are they PA_3 and PA_4?
I want to know the some components reference of the mDot, like DC regulator or crystal.

Thank you and regards,

Gilen

• This reply was modified 8 years, 6 months ago by Guillermo Glaria.

[Guillermo Glaria]

Hi Brandon,

I have the same problem as Nico. I have done a five seconds reset and the mlinux goes to the defaults configuration. Now I can´t access via ssh root@192.168.2.1.

I have tried with ssh admin@192.168.2.1 but the behaviour is the same.

This is an mlinux version, not a Conduit AEP.

Is another way of upgrading the mlinux image. Could I boot from SD and upgrade the firmware without a ssh connection from ethernet.

I am blocked. Please, I need help!

Thank you and best regards,

Gilen

[Author]

Posts