[Mike Fiore]

Lawrence,

We got a lot of feedback that indicated the “No free channel” message was ambiguous and confusing, so we attempted to make it more descriptive.

The join backoff is a feature that got added per the LoRaWan spec.

We will try to better communicate these kinds of changes via the changelog in the future.

Cheers,

Mike

[Mike Fiore]

Lawrence,

I apologize for the confusion. You are correct that the “No free channel” message has been replaced by “No enabled channel”.

I will see about getting the wording in our AT command reference doc updated.

Cheers,

Mike

[Mike Fiore]

Syzmon,

So you are using libmDot-dev-mbed5 with mbed-dev and mbed-rtos?

https://developer.mbed.org/users/mbed_official/code/mbed-dev/

https://developer.mbed.org/users/mbed_official/code/mbed-rtos/

Cheers,

Mike

[Mike Fiore]

Yogesh,

As long each conduit in near proximity has a different network name and passphrase from the others, you shouldn’t have any confusion among your devices. Even changing one character in the name will be enough.

Network ID = crc64(Network Name)

The chances of collision are extremely low since you probably won’t have more than a few gateways within range of each other.

Cheers,

Mike

[Mike Fiore]

Yogesh,

The mDot API documents the limits for network name and passphrase.

        /** Set network name
         * for use with OTA & AUTO_OTA network join modes
         * generates network ID (crc64 of name) automatically
         * @param name a string of of at least 8 bytes and no more than 128 bytes
         * @return MDOT_OK if success
         */
        int32_t setNetworkName(const std::string& name);

        /** Set network passphrase
         * for use with OTA & AUTO_OTA network join modes
         * generates network key (cmac of passphrase) automatically
         * @param name a string of of at least 8 bytes and no more than 128 bytes
         * @return MDOT_OK if success
         */
        int32_t setNetworkPassphrase(const std::string& passphrase);

Since the dot side limits the strings to 128 characters, it wouldn’t make sense to go any higher on the gateway.

WRT your second question, the name and phrase are turned into an EUI and KEY which are fixed length. So the same number of bytes are transmitted in your join request regardless of what the name and phrase are.

Hope this helps!

Cheers,

Mike

[Mike Fiore]

Szymon,

Can you indicate which versions of mbed-os and libmDot-mbed5 or libmDot-dev-mbed5 you’re using, as well as what your application is doing?

Cheers,

Mike

[Mike Fiore]

Hi Szymon,

The STM32F411RE reference guide mentions the internal temperature sensor. See section 11.9.

http://www.st.com/content/ccc/resource/technical/document/reference_manual/9b/53/39/1c/f7/01/4a/79/DM00119316.pdf/files/DM00119316.pdf/jcr:content/translations/en.DM00119316.pdf

I think there also mbed PinNames defined for the internal analog input channels on the ST platforms. I think this change was added in mbed-os 5.2. With those PinNames defined, I think you should just have to create an AnalogIn object using the PinName for the internal ADC channel connected to the internal temp sensor and do a conversion.

Hope this helps!

Cheers,

Mike

[Mike Fiore]

Andrew,

As I explained earlier, we removed deepsleep due to the fact that it was discovered to be unreliable and was causing a lot of customer frustration. Since sleep mode improvements were made to bring current consumption down to approximately the same level as deepsleep and you gain additional functionality with sleep mode, it was a logical choice.

Can you explain why you can’t use sleep mode instead of deepsleep mode now that the current consumption is similar? Migrating your application should basically be a matter of:

* removing the if (!dot->getStandbyFlag) from around your configuration and initial setup
* putting a while() loop around the functional component of your code

Cheers,

Mike

[Mike Fiore]

Andrew,

The goal was to remove peripherals that either weren’t available on the mDot pinout or mapped to pins used internally. UART6 was an oversight because one of the pins was marked RFU.

Are there other features or functionality that you feel have been lost during the transition from mbed 2 to mbed 5? If so, please let us know.

Cheers,

Mike

[Mike Fiore]

Javier,

Sorry for the lingo. RFU = Reserved for Future Use.

If your PR is accepted (and it should be since it’s such a minor change), the changes should make it into the next mbed-os release.

Cheers,

Mike

[Mike Fiore]

Javier,

We removed tjat uart because PA_12 is marked as RFU in the official pinout for the mDot. If you’re willing to edit the PeripheralPins.c file for the mDot, you can add the functionality back. You could make a PR to the mbed-os github repository so that uart gets back into the platform support. Will that work?

Cheers,

Mike

[Mike Fiore]

Greg,

I exported revision 16:71f51c7 of the mbed-os-example-blinky project

https://developer.mbed.org/teams/mbed-os-examples/code/mbed-os-example-blinky/

to IAR for the MTS Dragonfly platform. The export succeeded and I was also able to successfully build the application by opening the project in IAR and selecting “Project->Rebuild All.” I’m using IAR version

IAR Embedded Workbench for ARM 7.30.4.8187
IAR Embedded WOrkbench common components 7.1.7.3552

An application built for the Dragonfly in IAR won’t run on the target until the MTS bootloader is prepended and the application is padded to a 64kB offset, but that’s another issue.

Could you downgrade your IAR version to 7.30?

Cheers,

Mike

[Mike Fiore]

Huo,

The latest version of libmDot-dev-mbed5 will also have this fix if you’d prefer to use that until the next libmDot-mbed5 release instead of implementing the workaround.

https://developer.mbed.org/teams/MultiTech/code/libmDot-dev-mbed5/

Cheers,

Mike

[Mike Fiore]

Huo,

I have verified this issue. We will get this fixed in the next release. A simple workaround is to set the TX datarate after the join is successful.

The following block of code can be used to change the data rate after joining.

        if (dot->getTxDataRate() != mDot::DR1) {
            logInfo("changing TX datarate to DR1");
            if (dot->setTxDataRate(mDot::DR1) != mDot::MDOT_OK) {
                logError("failed to set TX datarate to DR1");
            }
        }

I apologize for the trouble this has caused you. We will get it fixed in the next mDot release.

Cheers,

Mike

[Mike Fiore]

Huo,

Can you post the contents of your get_fake_data() function?

Also, all of your functionality is within the if (!dot->getStandbyFlag()) block. That may not be what you intended.

Cheers,

Mike

[Mike Fiore]

Andrew,

Can you clarify exactly what “disconnect the UDK dev board” means? Are you disconnecting a serial cable or the micro USB cable or something else?

Also, is your UDK dev board populated with the Dragonfly 40-pin connector and the SMC headers or just the mDot header? The UDK with only the mDot header is powered from the micro USB port while fully populated model is powered via the J3 power connector.

Cheers,

Mike

[Mike Fiore]

Greg,

I wouldn’t expect any MTSAS examples to work if the mbed blinky example doesn’t even work. Let’s start there. What versions of mbed/mbed-os are you exporting? What version of IAR are you using?

Cheers,

Mike

[Mike Fiore]

Huo,

You can see from the source of update_ota_config_name_phrase() in dot_util.cpp that that function does not change the tx datarate. However, all the examples in Dot-Examples do default the configuration during initialization – if you are adding code to set the tx datarate before that default happens, that could explain the issue. Can you post your complete source code?

Cheers,

Mike

[Mike Fiore]

Andrew,

You are correct that deepsleep has been disabled in the dev and production libraries for mDots. We did this because we discovered that the feature was unreliable, sometimes drawing over 1mA of current while sleeping, and was causing confusion and frustration for many of our customers.

The new libraries have improved the sleep current consumption to the point where it is approximately equivalent to what deepsleep achieved. That improvement plus the fact that RAM is retained across sleep and the application can resume instead of restarting makes sleep much more desirable than deepsleep. For these reasons, we made the decision to disable deepsleep for the mDot until we do a HW revision and fix the deepsleep unreliability.

The getStandbyFlag() function returns false because the mDot isn’t actually entering deepsleep mode.

WRT the issues you listed, can you supply more information? mbed-os version, libmDot-mbed5/libmDot-dev-mbed5 version, which GPIO is being used as the wake pin, which DK board you’re using, etc.

Please note that the deepsleep limitation only affects this specific HW version of the mDot and does not affect the xDot at all.

Cheers,

Mike

[Mike Fiore]

Andrew,

We discovered an issue on the mDot where the current draw wasn’t consistently at the levels it should be in deepsleep. Some customers were seeing over 1mA instead of the expected <50uA levels.

Because of that, we rolled out a change in the mDot 2.0 release that prevents the mDot from going into deepsleep and uses sleep mode (now also at <50uA draw) instead.

Hope this helps!

Cheers,

Mike

[Mike Fiore]

Greg,

One thing you could try is uninstalling and reinstalling the ST-Link drivers.

Do you have another PC you could test against? Or another UDK and/or Dragonfly to try?

Cheers,

Mike

[Mike Fiore]

Greg,

Are you using the latest interface firmware on your DK board?

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

What OS (type and version) are you using?

Cheers,

Mike

[Mike Fiore]

Greg,

The Dragonfly module should work with mbed-os just fine. I think there are some issues compiling the MTSAS library with mbed-os at the moment. We’re hoping to get them resolved soon.

Cheers,

Mike

[Mike Fiore]

Yogesh,

You’d need to emulate a UART in software. We don’t have any software support for that.

I did find this repo in mbed

https://developer.mbed.org/users/Sissors/code/SoftSerial/

Sissors is pretty active in the mbed ecosystem and puts out a lot of good code. You could give that repo a try.

Cheers,

Mike

[Mike Fiore]

Kiran,

Here’s an example program that properly turns off the radio and puts the processor into STOP mode.

https://developer.mbed.org/teams/MultiTech/code/Dragonfly_Low_Power_Example/

Cheers,

Mike

[Mike Fiore]

Boris,

Can you share what versions of the mbed-os and libmDot-dev-mbed5 libraries you’re using? Also, are you building in the online compiler or offline?

Cheers,

Mike

[Mike Fiore]

The upcoming mDot 2.0 release will support mbed 5 instead of mbed 2. Applications will need to use the mbed-os library instead of mbed and mbed-rtos. While the mDot 2.0 release hasn’t happened yet, we do have a development version available on both mbed and github.

We’ve refactored our library releases into a single repository which is compatible with both the ARM toolchain used in the online compiler and the GCC ARM toolchain used in offline environments (no more separate libraries for different toolchains!)

https://github.com/MultiTechSystems/libmDot-dev-mbed5

https://developer.mbed.org/teams/MultiTech/code/libmDot-dev-mbed5/

Cheers,

Mike

[Mike Fiore]

Dinesh,

The online compiler does not support debugging. You’ll have to use a local IDE. We have published a wiki page outlining how you can do this:

https://developer.mbed.org/teams/MultiTech/wiki/debugging-mDot-MTQ-via-command-line

Cheers,

Mike

[Mike Fiore]

Andrew,

We will be releasing a developer guide for the xDot which will contain mechanical drawings, pinouts, etc. You may be able to get this info now via a portal case.

Cheers,

Mike

[Mike Fiore]

Ajay,

The UDK2.0 is compatible with Arduino Shields. There are a number of bluetooth shields available:

https://developer.mbed.org/components/cat/bluetooth/

I took a quick peek at the Seeed Bluetooth Shield and it has a couple of example applications right on the page.

https://developer.mbed.org/components/Seeed-Bluetooth-Shield/

Should at least help you get started.

Cheers,

Mike

[Author]

Posts