[Mike Fiore]

Ajay,

I can respond for the mDot/xDot side. Our 3.x.x releases will support “custom channel plans.” This will allow you to create your own channel plan and inject it into the Dot Library. Obviously, you will need to certify your own channel plans yourself.

Hope this helps!
Cheers!
-Mike

[Mike Fiore]

Frank,

We have some example packet forwarder configs at the link I posted earlier. It has some comments about potential pitfalls, etc. If you have more questions, feel free to reach out via the forum.

Cheers!
-Mike

[Mike Fiore]

Frank,

The DotBox has the MPL3115A2 pressure/temp sensor. Here’s the datasheet:

http://www.nxp.com/assets/documents/data/en/data-sheets/MPL3115A2.pdf

The temp accuracy is +-1C @ 25C and +-3C for the whole range. This will account for some of the variation you see. The rest can likely be accounted for by the fact that the sensor is inside the box – the LoRa radio generates a lot of heat when it’s in TX and RX mode especially.

Hope this helps!
Cheers,
Mike

[Mike Fiore]

Frank,

The mDot (and all of our LoRa devices) can be operated safely without an antenna. Obviously, your range & output power will be diminished, but you don’t need to worry about damaging the devices.

It’s actually useful to remove one or both antennas if you have an endpoint and a gateway close to each other and are getting a lot of CRC errors. This is usually an indication of the devices overdriving the other’s RX paths (no damage, just packets getting distorted).

Cheers!
-Mike

[Mike Fiore]

Frank,
That’s correct! There are some example configurations at the following link (I think you’ve already found them, but here it is again):

Conduit AEP: Convert to Basic Packet Forwarder

Cheers!
-Mike

[Mike Fiore]

Frank,
Happy to help! Thanks for choosing MultiTech!

Cheers,
Mike

[Mike Fiore]

Francois,
The update to support GCC_ARM v5 and v6 in mbed-os is very recent. Prior to that update, only up to and including v4.9 was supported. The Dot Library is compiled with GCC_ARM v4.9, so I don’t think those binary builds are compatible with GCC_ARM v5 and v6. Can you try using GCC_ARM v4.9?

Cheers,
Mike

[Mike Fiore]

Peter,

We are looking into this discrepancy. I will let you know what we find out.

Cheers,
Mike

[Mike Fiore]

Shaheen,

If the pin isn’t connected to anything, I don’t think I’d expect the value to remain perfectly consistent. Have you tried connecting 3V or ground to the pin and seeing if your ADC reading is correct?

The following equation can be used to convert the 16 bit ADC reading to a voltage:

voltage = (read_u16() /65535) * (float)VREF

where VREF is the supply voltage to the mDot.

Cheers,
Mike

[Mike Fiore]

Momo,

You should use the event framework to print your RX data on the debug port. See mDotEvent.h in the Dot Library.

Cheers,
Mike

[Mike Fiore]

Tamas,

Unfortunately, our network server is closed source. We try to make the log messages as clear as possible, but we’re definitely not perfect. We’ve all seen our fair share of cryptic log messages. 🙂

Please let us know if you have other questions or issues and we’ll do our best to help you get to the bottom of them!

Cheers,
Mike

[Mike Fiore]

Your application would need to handle that scenario. There is no support in the Network Server for routing messages between nodes.

Cheers,
Mike

[Mike Fiore]

Momo,

Did you update the node to class C on your network server after it joined? You need to use lora-query to do this. That step is documented in the Class C example program.

Your node is in class C mode, but the network server needs to be informed of this and there is currently no LoRa message in the standard for that purpose. It must be an Out Of Band (OOB) message at this point.

Cheers,
Mike

[Mike Fiore]

Tamas,

You know your application doesn’t have any downstream data for your node, but the Network Server doesn’t. It tries to reserve a spot to send data down in case any comes between when the packet was received and the RX windows.

In this case, the Network Server tried to reserve a slot in RX1 but it would have been too much time on air, so it got a slot in RX2 instead. Since the gateway didn’t actually transmit, there was no time on air, which means there was no time off air either.

Hope this helps!

Cheers,
Mike

[Mike Fiore]

Momo,

Your application should not be calling RadioEvent. It will be triggered by the Dot Library when events happen. If you set everything up, the Class C Example from Dot-Examples should work.

https://developer.mbed.org/teams/MultiTech/code/Dot-Examples/

There needs to be something on the gateway side that is actually sending data to your device. We have some examples of how to do this on our developer site.

Conduit mPower: LoRa Communication and Node-RED

Conduit mLinux: LoRa Communication

Cheers,
Mike

[Mike Fiore]

Sergio,

You can use the USB peripheral on the mDot, but the mbed-os library doesn’t provide USB support. You’d need to work down at the CMSIS or register level – there aren’t any nice USB APIs available like mbed-os provides for other peripherals.

Cheers,
Mike

[Mike Fiore]

Just saw that you mentioned the MTDOT-BOX/EVB. If you’re using the ribbon cable to connect the dotbox/evb to the MTMDK, make sure the orientation is correct on both sides.

Update firmware using binary file

Cheers,
Mike

[Mike Fiore]

Hi TaeYang,

Is the ST-Link firmware on your MTMDK updated to the latest? You can find the FW and update instructions here:

https://developer.mbed.org/teams/ST/wiki/Nucleo-Firmware

What OS and OS version are you using?

Make sure the mDot is properly seated on the MTMDK as well.

Cheers,
Mike

[Mike Fiore]

Wesley,

My basic question remains. If you don’t want to RX any packets from the network, why is your mDot in Class C mode?

Class C mode is specifically for use cases where the mDot needs to RX packets outside the regular RX windows. If you don’t need that functionality, you don’t need to be in Class C mode.

I think you’ll have better luck with Class A mode as it is much more compatible with what you’re trying to do.

Cheers,
Mike

[Mike Fiore]

Wesley,

Can you explain a little more about what you’re trying to do?

Class C mode is used when you want your mDot to receive outside the normal RX windows – in Class C mode the mDot is opening RX windows whenever it is not transmitting. It sounds like you’re trying to transmit frequently but close the RX windows because you’re not expecting a response.

To allow your mDot to transmit more frequently, you can call mDot::setTxWait(false). This will cause the mDot to not open RX windows and mDot::send() will return immediately after data has been transmitted.

Can you provide more detail around your statement “The newer library does not work very well”?

Cheers,
Mike

[Mike Fiore]

Peter,

Can you link the docs you’re looking at that have different ranges?

Cheers,
Mike

[Mike Fiore]

Mark,

Version 2.0.17 is actually the same as version 2.0.16. Sorry for the confusion.

WRT the issue mentioned in the changelog, that is a copy paste error I have fixed. That issue was present in very old versions of the library but was resolved in version 1.1.0 (almost a year ago).

I will update the changelog.

Cheers,
Mike

[Mike Fiore]

Nicolas,

Were your Conduit’s username/password still at the default values? The defaults are easy to guess. We suggest changing them in order to prevent situations like this.

Cheers,
Mike

[Mike Fiore]

Sergio,

Those pins are connected to the USB interface on the mDot. The reason we don’t explicitly put it in the pinout diagram is because the mbed library doesn’t support USB for all platforms.

Hope this helps!

Cheers,
Mike

[Mike Fiore]

Alex,

The 5 additional channels are derived as follows:

“additional channels” center frequency – 400kHz
“additional channels” center frequency – 200kHz
“additional channels” center frequency
“additional channels” center frequency + 200kHz
“additional channels” center frequency + 400kHz

So for an additional channels center frequency of 869.5 MHz, you’d get the following 5 channels:

869.1 MHz
869.3 MHz
869.5 MHz
869.7 MHz
869.9 MHz

Hope this helps!
Cheers,
Mike

[Mike Fiore]

The second link I posted before is to a set of example programs for mDot and xDot.

-Mike

[Mike Fiore]

Alex,

In that case, the gateway is listening on the 3 default channels for the EU868 frequency band and sends down the center channel for the other 5 in the join accept. You can see the configured center channel in the AEP web UI on the LoRa configuration page.

Once you have the center frequency for the extra channels, you can determine the frequency for each of the 5 channels and configure your endpoint to use them as well as the default 3 channels.

Cheers,
Mike

[Mike Fiore]

https://developer.mbed.org/platforms/MTS-mDot-F411/

The mDot has SPI, I2C, uart, and digital and analog IOs, so it can be connected to sensors and other devices and can be programmed to report sensor data back to the gateway. This would involve writing an application using libmDot.

https://developer.mbed.org/platforms/MTS-mDot-F411/#lora-stack-libmdot

We have some example applications that provide a good starting point.

https://developer.mbed.org/platforms/MTS-mDot-F411/#example-programs

Hope this helps!
Cheers,
Mike

[Mike Fiore]

Alex,

If you’re in the US915 frequency band (I’m assuming you are), you’ll end up configuring your conduit for a certain frequency sub band. This is because the MTAC-Lora card only has the bandwidth to receive on a portion of the available channels in the US915 frequency band.

You can get full information about the US915 band from the LoRaWan specification, which you can access from https://www.lora-alliance.org/For-Developers/LoRaWANDevelopers.

Here’s a quick rundown of how the US915 frequency band is set up:
* 64 total 125kHz uplink channels, numbered 0-63
* 8 total 500kHz uplink channels, numbered 64-71
* 8 total 500kHz downlink channels, numbered 0-7

FSB 0 is default operation where the device uses all channels – gatewawy must be able to listen on all channels. Our gateways can receive on a group of 8 125kHz channels.

Each of FSBs 1-8 consists of the following:
* 8 125kHz uplink channels
* 1 500kHz uplink channel
* 1 500kHz downlink channel
FSB 1 uses uplink channels 0-7 and 64 and downlink channel 0.
FSB 2 uses uplink channels 8-15 and 65 and downlink channel 1.
Etc, etc.

So the channel mask for your device will depend on what FSB you have your gateway configured for.

Hope this helps!
Cheers,
Mike

[Mike Fiore]

Ajay and Chad,

Can either of you supply a simple application that reproduces the issue? This would be very helpful for us to get to the bottom of this issue.

Also, the explicit version number (e.g. 2.0.14 – can be found in commit messages) of the mDot/xDot library would be helpful as well.

Cheers,
Mike

[Author]

Posts