[Mike Fiore]

Martin,

I think you’re on the right track. Making sure the slave is idle before trying to TX is likely to resolve the issue, I think.

Cheers,
Mike

[Mike Fiore]

Martin,

That error code means the mac layer is busy with the previous transmission. If your device has TRACE logging turned on, you should see the following from the debug port: “Link is busy with previous send”

One slave wouldn’t know if it was transmitting over another slave or not, so that’s not the issue. This error usually happens when attempting to transmit too soon after the previous transmission.

1s is not a lot of time to TX a packet and RX an ACK, depending on the datarate and frequency band. Does the issue go away if you increase the interval between TX for the slaves?

Cheers,
Mike

[Mike Fiore]

Martin, another question…

Was your application interacting with the filesystem using the API in the Dot library or another method?

[Mike Fiore]

Martin,

The library version you’re using is indeed the most recent dev version. It takes steps to protect the flash when the voltage is too low to write. This seriously reduces the chances of filesystem corruption. However, the log output does look like the filesystem might be corrupted.

libmdot-dev-mbed5 -> 80:e85c370 was compiled against mbed-os-5.3.4.
mbed-os -> 2742:5faf4b2 is mbed-os-5.3.6 (you can see this by clicking “revisions” for mbed-os).

We recommend using the same mbed-os version in your application as the one the dot library was compiled with for maximum compatibility.

I’m not saying that using a slightly different mbed-os version caused the flash corruption, but I do recommend changing to mbed-os 2740 (5.3.4).

If you open a support case, we can help get your mDot back up and running.

Cheers,
Mike

[Mike Fiore]

Martin,

This is a known issue with older code. It is possible for the filesystem on the external flash to get corrupted when VDD starts to droop. We’ve implemented protection that significantly reduces the chance of this happening in our latest firmware & library.

Please open a support case and we can help you get your mDot back up and running.

Cheers,
Mike

[Mike Fiore]

Mark,

I checked with one of our HW guys. Leaving the USB unplugged won’t work because the reset pin will end up floating instead of being pulled high.

You don’t need to unplug the USB to power the xDot externally though. You can connect your battery VDD to pin 2 of JP30 and leave JP5 connected. Your battery ground can connect to P2 or P14 on the DK.

With JP5 connected, your UARTs won’t work and you won’t be able to program the xDot, but LED1 and the IOs (P1 – P24) should still be functional.

Cheers,
Mike

[Mike Fiore]

You don’t need to inject a custom events handler. A default one is always there. It’s just available in case you want to override it and do custom things when different events fire.

Cheers,
Mike

[Mike Fiore]

Ajay,

Glad everything is straightened out!

Cheers,
Mike

[Mike Fiore]

Ajay,

ADR is independent of the join mode you’re using. It will work for MANUAL, OTA, or AUTO_OTA.

Whether or not ADR is enabled is stored in the configuration, and the default is to have ADR disabled. Calling mDot::resetConfig() will disable ADR.

Cheers,
Mike

[Mike Fiore]

Events fire when different things happen in the MAC layer – TX done, TX error, RX done, RX error, join accept, etc, etc. The event handler is a way for the application to be notified of important things like those and others without constantly polling the library.

Cheers,
Mike

[Mike Fiore]

Ajay,

Based on the packets your GW is receiving, your endpoint isn’t requesting ADR.

The snippet “mhdr”: “8002000000000800” is actually the MAC header and Frame header from the packet. The MAC header is the first byte and the Frame header is the next 7 bytes. I’ve dissected below:

MAC header Device Address Frame Control Uplink Counter
80 02000000 00 0800

If your endpoint had ADR enabled, the Frame Control byte would be 80 instead of 00.

Also, with lsnr in the -6/-7 range and rssi in the -115 range, I don’t think the gateway would increase the datarate anyway.

Hope this helps!

Cheers,
Mike

[Mike Fiore]

The 915 band is divided into 8 frequency sub bands because there are 64 uplink channels and the gateway can only listen on 8 at a time. So this setting (1-8) must match on the Dot and the gateway. The device will only transmit on the 8 channels in the sub band if the setting is between 1 and 8. If the setting is 0, it will hop all 64 channels.

/** Set frequency sub band
* only applicable if frequency band is set for United States (FB_915)
* sub band 0 will allow the radio to use all 64 channels
* sub band 1 – 8 will allow the radio to use the 8 channels in that sub band
* for use with Conduit gateway and MTAC_LORA, use sub bands 1 – 8, not sub band 0
* @param band the sub band to use (0 – 8)
* @returns MDOT_OK if success
*/
int32_t setFrequencySubBand(const uint8_t& band);

Cheers,
Mike

[Mike Fiore]

The Dot-Examples code show how to use the Dot library in your application.
You’re free to use that code as a starting point or write your own code from scratch, but stealing code from the Dot-Examples might make things a bit easier.

[Mike Fiore]

There’s no reference to FB_915 in that file. There is a reference to FB_EU868. Perhaps you’re referring to the debug output from the example program.

The function that reference is in is just displaying the current device configuration. Some configuration items are only relevant for certain frequency bands, so the code is switching on the frequency band in order to only show relevant configuration.

Your mDot was programmed in the factory to operate in a certain frequency band. The band your device is configured for should come out as part of the debug output from the example program. It should also be on the sticker on your mDot.

[Mike Fiore]

Ajay,

Yes, the uplink packets (dot->gateway) are what are used in the ADR algorithm.

It is better to set your initial datarate to something you know will work based on the placement of the device and the gateway. Then ADR can change it to the most efficient setting from there.

Cheers,
Mike

[Mike Fiore]

Simeoni,

Can you provide a link to the example program you’re referring to?

The frequency band of the device is normally stored in protected device configuration and can’t be changed by software.

Some documentation about LoRa and an introduction to LoRa can be found in the links below.

LoRa

Introduction to LoRa

Cheers,
Mike

[Mike Fiore]

Ajay,

Enabling ADR on both sides should be all you need to do.

See the ADR section on the page below:

Introduction to LoRa

The gateway must RX enough packets to get a good sample before it will request the end device make any changes to TX datarate or power.

You can find more info about ADR in the LoRaWan specification.

Cheers,
Mike

[Mike Fiore]

Ajay,

I am not saying a 5s timeout is a worst case number that will cover every possible scenario. It depends on a lot of settings. If you have ACK retries enabled, that will obviously affect how long your timeout should be as the Dot can make multiple attempts (each with its own RX1 and RX2 windows) before giving up. Also ADR, like you mentioned, may change the datarate. You can use the Dot library to estimate time on air with different datarate settings and payload sizes.

You will have to analyze your settings and determine what the maximum timeout is based on those settings. I can’t provide you with a “magic number” for your timeout.

Hope this helps!

Cheers,
Mike

[Mike Fiore]

Ajay,

Events should fire even if the TX or RX fails. However, if you want to set a global timeout, you should just set it to accomodate the transmission time + the 2 RX windows that will potentially open. I think something like 5s would be OK for regular packets, but you’d probably want to do some testing and validation before picking a specific value. For example, the RX1 window after a join request in EU868 doesn’t open until 5 seconds after transmission is complete if the device is in public mode.

Cheers,
Mike

[Mike Fiore]

Ajay,

Trying to send another packet while the mac layer is still sending or opening RX windows for the previous packet will fail. You should get an error about the radio being busy or something similar.

If you’re using a nonblocking send, you should always get an event that fires after the TX/RX is done. The mDotEvent class demonstrates this for you.

The “timeout values” would be based on when your receive windows are configured to open.

Cheers,
Mike

[Mike Fiore]

Ajay,

I think it would work fine. It would be good to make sure that no printf is called when the pins are configured as GPIO.

Cheers,
Mike

[Mike Fiore]

Ajay,

Is this xDot on a custom board? If it’s on the DK, the USBTX/RX pins are also connected to a UART on the interface processor. I’d have to ask our HW guys if that would be an issue. If it’s on a custom board, you probably know better than I do if it would cause any problems or not.

The NONE log level is only for the MTSLog class. It will prevent any LogError, LogInfo, LogTrace, etc statements from printing out the debug port, but it will not prevent printf statements from printing out the UART.

Cheers,
Mike

[Mike Fiore]

Ajay,

There’s no way to disable the creation of the uart object in the Dot library. I don’t see why you couldn’t override that declaration if you’re sure you aren’t going to use the uart. You can create analog or digital objects with those pins and set them to a low current state or configure them like the example code does around sleeping to reduce current.

It’s up to you.

Cheers,
Mike

[Mike Fiore]

Yogesh,

The implementation has changed so that consumers of the API no longer need to free the memory. You’ll notice that the mDotEvent object has its own buffer and that the RX data from the event gets copied into that. So there isn’t any dynamic allocation WRT the RX data that you need to worry about.

Cheers,
Mike

[Mike Fiore]

Andrew,

I’m not sure what you meant by your last comment. It’s possible to have a dot on a DK and still use the UART interface.

What pins are you using on both devices? Are the dots on DK boards or on custom boards?

What version of mbed-os are you using?

Did anything else from my previous post help you out at all?

Cheers,
Mike

[Mike Fiore]

Andrew,

What pins are you using on both devices? Are the dots on DK boards or on custom boards?

What version of mbed-os are you using?

As I’m sure you well know, the mbed Serial code should work on any mbed device. However, the underlying implementation is a little different between the F4 and L1 families. See the following files:

https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/TARGET_STM32L1/serial_api.c

https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/TARGET_STM32F4/serial_api.c

Cheers,
Mike

[Mike Fiore]

You can’t just connect the packet forwarder directly to a MQTT broker. There has to be a network server in between. If you want the Conduit gateway to push packets to a MQTT broker, you’ll need to enable the network server on your Conduit. The easiest way to publish info to MQTT would be to set up a Node Red flow:

For upstream (mote -> cloud) you’d want to wire the following
LoRa Input Node -> Function Node (processing) -> MQTT Output Node

For downstream (cloud -> mote) you’d want to wire the following
MQTT Input Node -> Function Node (processing) -> LoRa Output Node

[Mike Fiore]

https://developer.mbed.org/search/?q=mb7137

https://www.google.com/search?client=ubuntu&channel=fs&q=mb7137+example&ie=utf-8&oe=utf-8

Nothing on mbed but looks like there might be an Arduino example you could use as a reference for writing your own driver.

[Mike Fiore]

Here is the link directly to an example 8-channel configuration for EU868.

http://www.multitech.net/developer/wp-content/uploads/2016/03/EU-868-example-config.txt

I already posted links above that describe how to set your mLinux or AEP Conduit in packet forwarder mode.

You can use MQTT input and output nodes in Node Red on the AEP Conduit to communicate with an external MQTT broker.

[Mike Fiore]

There are multiple example configurations linked directly from this page:

Conduit AEP: Convert to Basic Packet Forwarder

Is that not what you’re looking for?

There’s also some discussion here:

https://www.thethingsnetwork.org/forum/t/setting-up-multitech-conduit-gateway-for-ttn/216/80

[Author]

Posts