[Peter Ferland]

Are you using the built in network server on both gateways? When a device joins a network using OTAA session keys are negotiated between the gateway and the end device. The session keys are stored in a database entry on the gateway for that device. This means that a device can only be joined to one gateway (Acting as a join server) at a time.

Configuring both gateways with different AppEUIs would reduce confusion between the gateways and ensure that you must treat them as separate networks.

In the next major firmware release for AEP there will be a feature that allows one Conduit to packet forward to another. This would probably be a better long term solution if both gateways are on a LAN. The firmware should be released in the next few weeks.

[Peter Ferland]

The gateway will operate fine but range will be quite limited. You likely will not receive a signal past about 10 feet. If the end point and the gateway are on the same workbench you should be fine.

WiFi antennas will not work.

[Peter Ferland]

The data packet format is described here: http://www.multitech.net/developer/software/dot-box-and-evb-software/data-packet-format/

If you are using nodered make sure that the LoRa input node is in binary mode so you an decode it.

[Peter Ferland]

That table is reporting what is done with all of the connections to the STM32L151CC processor. Those 4 pins are connected on the xDot itself to external (to the processor) clocks. 32.768kHz for the RTC and 24MHz for HSE. If you are using mbed 5 the xDot target sets up these clocks automatically.

• This reply was modified 7 years, 2 months ago by Peter Ferland.

[Peter Ferland]

That would plug straight into a MTDOT-xxx-xx-UFL. The part would be MTDOT-868-X1P-U.FL assuming you’re in Europe and want the programming header.

If you purchased a starter kit then it would only have the -SMA mDots and you would need an adapter.

[Peter Ferland]

Those antennas plug right into a MTDOT-xxx-xx-SMA. Did you purchase the -UFL or -TRC? For the TRC option you’d have to solder a connector of some sort, its intended to soldered straight to a customer board. For UFL you’d need a UFL to SMA connector like Andrew linked.

[Peter Ferland]

Yes, tech support can provide a way to fix the DevEUI if you get them the serial number of the XDot in the support portal.

[Peter Ferland]

The library does indeed block access to the configuration address range.

[Peter Ferland]

XDots do not have the exact same problem as they do not have an off processor flash. Does your application use the EEPROM in any way?

[Peter Ferland]

Hi Andrew,
The DevEUI is supposed to be permanent and read only. This could indicate a failure of the onboard flash memory. Support can help diagnose or exchange the xDot if there is indeed a hardware failure. https://support.multitech.com

Peter

[Peter Ferland]

The function returns a populated mDot::mdot_stats object. Did that object not contain any information?

[Peter Ferland]

Hi Alexis,
What are you using for the input to the flow? It sounds like the entire flow is being executed when its not intended to be.

As a quick work around, you can return null from a function node just before the LoRa output node to stop the flow. Your javascript function would be something like:

if(msg.payload === “”){
return null;
}

[Peter Ferland]

Alternatively you can include all this information in a javascript function, for example:

var azuremsg = {};
azuremsg.topic = "devices/" + 
    "your device id" + 
    "/messages/events/";
azuremsg.payload = {};
azuremsg.payload.protocol = "amqp";
azuremsg.payload.deviceId = "insert device id";
azuremsg.payload.key = "insert key";
azuremsg.payload.hostname = "insert hostname";
azuremsg.payload.data = "data to send goes here";
return azuremsg;

[Peter Ferland]

To directly use a connection string, in the msg.payload you can set a connectionString field:
{
“protocol”: “amqp”,
“deviceId”: “your device id”,
“key”:”your device key”,
“data”:”your json data”
“connectionString”:”your connection string”
}

• This reply was modified 7 years, 4 months ago by Peter Ferland. Reason: unrestricted html screwed up tags

[Peter Ferland]

What version of the AEP softwae are you running?

[Peter Ferland]

Pin 24 is connected to ADC voltage supply input, which is tied to an on board regulated 3V source. You can use it for sensors up to that 25mA limit.

[Peter Ferland]

Using the bitbake recipe you can build an ipk and install using opkg; assuming you have a bitbake mlinux environment available.

Otherwise, you could follow the build from source instructions: http://www.eclipse.org/paho/clients/python/
As git is not on the conduit you would have to clone to your desktop and then transfer to the conduit or download the latest copy on github as a tarball/zip ( https://github.com/eclipse/paho.mqtt.python/archive/master.zip ). Then you can cd into the directory and run ‘python setup.py install’

[Peter Ferland]

According to the description of the current inputs for that board the ADC channel is measuring the voltage across a 200 ohm resistor. One potential problem is that the max voltage on the ADC pin is 4.0V which is above the max voltage the ADC can read. If this was happening you would always see a max reading for anything above 3.3 (or whatever the 3.3V line is actually running at).

[Peter Ferland]

You’re using the 4-20mA inputs on that board, correct? Which input are you using? What ADC reading are you seeing across that 200 ohm sense resistor, if any?

[Peter Ferland]

Can you link the pinout for the specific shield you’re using?

[Peter Ferland]

Try using this link instead of the other: https://bootstrap.pypa.io/ez_setup.py

[Peter Ferland]

Did you stop the Multitech lora-network-server first?

[Peter Ferland]

Can you see packets in node red following this guide?

Conduit mPower: LoRa Communication and Node-RED

[Peter Ferland]

Double check that the public network switch agrees between the two. (AT+PN)

[Peter Ferland]

Do you just see “ERROR” or do you get an error code? If you do not see an error code, you can enable verbose error messaging using the command AT+CMEE=2

The description of the error codes is in the documentation for the AT+CSIM command for the particular modem you’re using. For 3G/H5 models refer to this guide (page 114): http://www.multitech.com/documents/publications/manuals/telit_3g_modules_at_commands_reference_guide_r9.pdf

[Peter Ferland]

Usually you can directly connect arduino shields. You should confirm the pinout of on page 50 of the MTDOT developer guide. The biggest difference is the no connects on a few of the analog and digital pins. However sensor boards that just use i2c on pins D15 and D14 will be fine.

http://www.multitech.com/documents/publications/manuals/s000612.pdf

Do you have a particular sensor board in mind? For reference, we’ve used the X-NUCELO-IKS01A1 sensor board on the UDK a lot without issues: http://www.st.com/en/ecosystems/x-nucleo-iks01a1.html

• This reply was modified 7 years, 6 months ago by Peter Ferland.

[Peter Ferland]

That blog’s installation instructions are correct, but the node red flow you create needs to have a “protocol” entry in the inject node’s payload. For whatever reason the azureiothub node’s protocol GUI entry gets wiped out if you set any other properties.

ie, the inject node’s payload for the Azure IoT Hub should be:

{
     "protocol": "mqtt", 
     "deviceId": "<your device id>", 
     "key":"<your key>", 
     "data":"<your json data>"
}

[Peter Ferland]

What firmware did you write to the MTQ? Which USB port are you using on the UDK2?

If you compile and run this program, are you able to communicate with the modem through the USB port on the UDK closest to the MTQ’s USB port? https://developer.mbed.org/users/pferland/code/YYY_Dragonfly_USBTerminal/

[Peter Ferland]

mosquitto-sub and mosquitto-pub are simple commandline clients for MQTT. They are provided by default on an mlinux conduit and can be installed on an AEP conduit by getting the mosquitto-clients package (opkg install mosquitto-clients).

What I wanted to establish was whether there was something wrong with node-red or mosquitto. If you ran ‘mosquitto-sub -t /lora/+/+’ every lora message would be printed to the commandline. You could direct out output of that command to a file and then compare the number of packets you see using mosquitto-sub with the number of packets seen by your node red flow.

[Peter Ferland]

Do you see any issues when using mosquitto-sub on the commandline? Just want to confirm that its not a problem with the lora or mosquitto server itself.

[Author]

Posts