[Brandon Bayer]

You guys are wanting an AEP model that’s easy to configure only as a packet forwarder gateway, correct?

If so, that’s easy for us to implement (we already have a proof of concept for it). It’ll basically be an option in the AEP GUI that behind the scenes will do the type of reconfiguration described in the mLinux forwarder conversion guide. You can then point AEP to any public LoRaWAN network. But, you still couldn’t use Node-RED to process LoRa packets.

If you want to process packets with Node-RED, say to only forward important events to TTN, it’s probably doable but a significantly larger problem. One possible way is to configure the Conduit’s on-board network server with the same settings as the TTN server. Then use Node-RED to process LoRa packets and send important ones to the TTN server via a REST API. Another way might be to develop some type of protocol for LoRa network servers to communicate with each other.

-Brandon

[Brandon Bayer]

Ah, Lawrence, you are correct, and I was mistaking. LoRaWAN doesn’t have any peer-to-peer support. Any communication from mDot to mDot must go through the network server and be handled at the application layer.

-Brandon

[Brandon Bayer]

Antony,

Thank you very much for all info and logs! We’ll look through it further, but you may want to try changing the network server config’s public option to true. This changes the sync word from 0x12 to 0x34. The sync word is the first byte in the preamble and is used to distinguish between networks. If the sync word is incorrect, the radio shouldn’t receive them at all, but in practice, we’ve seen it actually receive a low percentage of packets in this case.

-Brandon

[Brandon Bayer]

mb, please open a support case for this.

-Brandon

[Brandon Bayer]

Hey Patrick,

I’m in contact with Johan and am working on getting the Conduit working with TTN.

But for a little background, LoRa networks consist of a number of gateways running packet forwarders each forwarding packets to a single central LoRa network server. Out of the box, the Conduit is configured as a self-contained LoRa network. It hosts both a packet forwarder and network server. The packet forwarder simply forwards packets to the on-board network server.

So to use the Conduit with a public network like TTN, the network server needs to be disabled, and the packet forwarder needs reconfigured to point to the TTN network server. Unfortunately, this cannot be done using a custom TTN node. The scenario described in your quote is basically using the Conduit as configured by default and then using Node-RED to send data to some cloud server like Bluemix, m2x, or a TTN application handler (but not the TTN network server).

Since the encrypted packets are simply forwarded in packet forwarder mode to the cloud-based network server, the Conduit can’t process LoRa packets. This renders Node-RED useless for handling them (it could still be used with something like a serial or GPIO mCard). You’ll have to handle the LoRa packets using a TTN application handler (which I believe they have Node-RED for this or have plans to have it).

Now, the AEP Conduit doesn’t currently support reconfiguration as a packet forwarder (probably sometime down the road), but the mLinux version does using these instructions.

Although those instructions will successfully point the Conduit’s packet forwarder to TTN, I have yet to successfully see packets through the TTN API. Johan and I are working on this.

Does that help?

-Brandon

[Brandon Bayer]

Adhavan,

Ok, please go ahead and open a case in our support portal for this.

-Brandon

[Brandon Bayer]

Andrew,

I’m not sure about Eagle, but we do have some CAD files available. Right now the best way to get these is to open a case in our support portal.

-Brandon

[Brandon Bayer]

Adhavan,

Yes, the AEP model of Conduit is the one with Node-RED. The Ethernet lights being unlit is definitely suspicious. Just changing the password shouldn’t affect the Ethernet interface. Did you change any network settings also? Can you try that ethernet cable with any other device to confirm your network connection is working?

To help debug, you can access the Linux console using the serial debug port behind the front panel (access instructions). From there, you can issue the ifconfig command to see your network interface details.

-Brandon

[Brandon Bayer]

Jonathan,

Unfortunately, mDots currently only support Class A LoRa communication. However, Class C support, which allows point-to-point communication, is on the roadmap, but I don’t know when you can expect it.

-Brandon

[Brandon Bayer]

Nicolas,

Yes, it’s possible to design your own accessory card, but we don’t have the documentation created for that yet. Open a support case, and we’ll see what we can do.

-Brandon

[Brandon Bayer]

Andrew,

Yes, you can use JTAG, but that would wipe out the bootloader. The other option is to design your PCB to allow access to the serial debug port via the USB pins, and then transfer the firmware to the onboard bootloader with Y Modem as described in this post:

http://www.multitech.net/developer/forums/topic/how-to-upgrade-mdot-board-without-development-baord/

-Brandon

[Brandon Bayer]

Do you have an mDot Developer Kit? That UDK is needed for programming the mDot because the required ST Link circuitry is on the UDK itself. Plus, the UDK will give you a DB9 connector for easy access to the AT Command port.

-Brandon

[Brandon Bayer]

James,

Since you are still having trouble, could you open a support case for this? We’ll be able to support you better that way.

-Brandon

[Brandon Bayer]

James,

Was the ping & rssi results you posted with Tx power 26/20? If not, please run that test again and post the results. If it was, then your MTAC-LORA needs replaced (open a support case).

-Brandon

[Brandon Bayer]

Have you seen the pin out information on the mDot’s mbed platform page? I think that has what you need.

-Brandon

[Brandon Bayer]

James,

No, just changing the ethernet configuration shouldn’t have any affect on the LoRa network.

-Brandon

[Brandon Bayer]

James,

If you haven’t seen this forum thread, go ahead and read through it. It has discussion on range issues and also has a test to make sure your MTAC-LORA accessory card is functioning properly.

And the mDot.h file in libmDot has documentation on all of the functions you can use (like setting the tx power).

-Brandon

• This reply was modified 8 years, 7 months ago by Brandon Bayer.

[Brandon Bayer]

Matteo,

I think we can get that for you. Go ahead and open a support case for this.

-Brandon

[Brandon Bayer]

Lawrence,

As long as you had both antenna’s off (or both on), Conduit tx power at 26, and mDot tx power at 20, then your MTAC-LORA also needs replaced. You can open a support ticket to get it replaced.

We are really sorry about all these defective parts! We have fixed the problem and are doing more post-production tests to catch these types of things in the future!

-Brandon

[Brandon Bayer]

James,

If you ping 8.8.8.8 from your PC, then you are getting a response from Google (8.8.8.8 is a Google DNS server).

If your router has an IP address of 192.168.1.1 and the Conduit is 192.168.2.1, then they are on different subnets and can’t communicate with each other unless the netmasks are set properly.

I suggest changing the Conduit IP address to something like 192.168.1.50 which will probably allow you to ping it from your PC (and use ssh).

You can use the serial debug port behind the front panel to gain access to the linux console without using ssh. Instructions are on this page.

-Brandon

[Brandon Bayer]

James,

As the below screenshot from this page shows, by default, the AT+SEND command will print out any received data. As mentioned in the documentation, the mDot must transmit 1 packet in order to receive 1 packet. The AT+RECV command will simply print out the data from the last received packet (from when you last issued AT+SEND).

And yes, in that case “hello world” was data transmitted from the Conduit.

-Brandon

[Brandon Bayer]

James,

That looks good!

-Brandon

[Brandon Bayer]

Andrew,

I can’t give a range as the rssi varies by orientation, proximity, etc, especially without antennas. The main thing is the AT+RSSI result should be higher than AT+PING in this situation because the Conduit is transmitting at 26 dBm and the mDot at 20 dBm (or less).

-Brandon

[Brandon Bayer]

James,

I added instructions to this page for how to install and run the sample app.

On using mosquitto to receive packets, yes, you should see received packets while mosquitto_sub -t lora/+/up is running. For debugging, run this command to look at the log: tail -f /var/log/lora-network-server.log

If lora communication isn’t working for you, it’s possible you have a version mismatch. This page lists required versions for compatibility.

-Brandon

• This reply was modified 8 years, 7 months ago by Brandon Bayer.

[Brandon Bayer]

Andrew,

Unfortunately it looks like your MTAC-LORA is probably defective also.

To get it replaced, open a support case stating I diagnosed you with a defective MTAC-LORA and reference this thread.

-Brandon

[Brandon Bayer]

James,

That is correct, you need to upgrade your lora software (see instructions Jason linked to).

-Brandon

[Brandon Bayer]

Andrew,

You can test your MTAC-LORA using these steps:

1) Place Conduit & mDot right beside each other
2) Take antennas off mDot & Conduit
3) Set Conduit tx power to 26
4) Set mDot tx power to 20
5) Have mDot join network
6) On mDot issue, AT+PING then AT+RSSI and send us the output of these two commands.

-Brandon

• This reply was modified 8 years, 7 months ago by Brandon Bayer.

[Brandon Bayer]

Brian,

I took another look at your AT+PING and AT+RSSI results in your last post. It looks like you have a defective MTAC-LORA card as the AT+RSSI result should be higher than AT+PING with those transmit powers.

We actually just discovered this MTAC-LORA defect last week which is caused by a defective solder joint. They pass our production tests, and then fail after some amount of use. We have a plan in place to remedy this so it doesn’t happen in the future!

To get it replaced, open a support case stating I diagnosed you with a defective MTAC-LORA and reference this thread.

-Brandon

[Brandon Bayer]

Guillermo,

I don’t have any ideas as to what is wrong. Unfortunately, we can’t support third-party software. That response from Loriot is odd, as their website states they only support mLinux.

In any case, there are a few people using Loriot in the below thread. Perhaps you can find some more help there:

http://openlora.com/forum/viewtopic.php?f=5&t=6&start=10

-Brandon

• This reply was modified 8 years, 7 months ago by Brandon Bayer.
• This reply was modified 8 years, 7 months ago by Brandon Bayer.

[Brandon Bayer]

Guillermo,

Are you sure you have a network connection to the Conduit? I.e. can you ping it?

What actually happens when you try to SSH in?

mLinux default credentials are root/root on all versions, and the default IP is 192.168.2.1. So what you are trying should work.

You can access the Linux console using the serial debug port behind the front panel. From there, you can issue ifconfig to see what the actual eth0 configuration is.

And yes, you can upgrade firmware from a SD card using these instructions.

-Brandon

[Author]

Posts