[Mike Fiore]

Matt,
When you call mDot::setWakePin() and go to sleep, the Dot library is internally creating an InterruptIn object on that GPIO. So your solution would look basically the same whether or not you used setWakePin().

* delete your serial object
* set the wake pin or create your InterruptIn
* go to sleep
* wake on serial
* delete InterruptIn if you created it (Dot library handles this if setWakePin was called)
* create serial object
* RX serial data

Hope this helps!

Cheers,
Mike

[Mike Fiore]

The radio defaults to 115200. It might be worth trying some faster baud rates as well.

Cheers,
Mike

[Mike Fiore]

Vincent,

It’s possible the radio’s baud rate got changed. Can you try a few common rates and see if any of them work?

Cheers,
Mike

[Mike Fiore]

Lawrence,

If the mDot/xDot is set to public network mode using AT+PN=1 or mDot::setPublicNetwork(true), you should be good to go.

Just setting the join delay to 5 will not work because the sync words are different between public and private modes. Changing the join delay should only be done to match a gateway with non-standard delays between the packet reception and transmission of the response. This is not likely to be the case.

Introduction to LoRa

Cheers,
Mike

[Mike Fiore]

Assuming PA_0 is the configured wake pin in the mDot library. Can you confirm?

[Mike Fiore]

Correct. We don’t have a way to unset the wake pin for waking on interrupt, so once it’s used, it will remain in effect.

You could try declaring a DigitalIn/DigitalOut/etc (something that doesn’t register an interrupt handler) on the pin that was previously the wake pin. That may prevent that pin from waking the processor from sleep.

-Mike

[Mike Fiore]

When the mDot is in sleep mode, any interrupt will wake it. If the WAKE pin is configured as an InterruptIn, you need to delete it.

-Mike

[Mike Fiore]

Steeve,

The Dot-Examples default configuration when starting up – this sets the TX datarate to DR0 which is SF12@125kHz in EU868. You can add a code to set the TX datarate using the mDot::setTxDataRate(const uint8_t& dr) function.

Cheers,
Mike

[Mike Fiore]

Andrew,

There is no MTS bootloader on the xDot.

Cheers,
Mike

[Mike Fiore]

Aitor,

Some IOs need to be in specific states to minimize current consumption on the Dots. This is based on the HW design and our testing.

See the function sleep_configure_io() in our Dot-Examples code.

https://developer.mbed.org/teams/MultiTech/code/Dot-Examples/file/b7da620f9ae3/examples/src/dot_util.cpp

-Mike

[Mike Fiore]

If you look at the revisions for mbed-os and dot-libraries, you will see specific revision numbers.

You’ll want to make sure the mbed-os version you’re building with is the same as the version from the dot-library commit message.

When you have access to the mDot, please provide debug logs demonstrating the issue.

-Mike

[Mike Fiore]

Aitor,

We need more information.

Please let us know the following:
– mbed-os version
– dot-library version

Can you provide the source code for the application where you get increased current draw?

-MIke

[Mike Fiore]

Simeoni,

What mbed-os and dot-library versions were you using when everything worked? Please provide the specific revision numbers.

What versions are you using now that don’t work?

Are you using the same mDot as before?

Can you provide debug output from the mDot?

-Mike

[Mike Fiore]

The commit messages name the Dot library version. You can compare yourself but I think the 2.0.17 production build would be the latest.

[Mike Fiore]

Yogesh,

We pushed out 2.0.17 (same as 2.0.16) production builds for mDot & xDot just a little while ago.

Cheers.
Mike

[Mike Fiore]

Olivier,

We have a really nice diagram on the mbed mDot platform page that shows the pin names and different functions available on each pin.

https://developer.mbed.org/platforms/MTS-mDot-F411/#mdot-pinout-diagram

The mDot ships with our factory AT firmware, which will probably suit your needs. You can also find it on our developer page.

Downloads

Cheers,
Mike

[Mike Fiore]

Paul,

The new Conduit will be a modified HW design, so I don’t think retrofitting will be an option.

I did some looking around a found a forum post where people got WiFi dongles working with the Conduit.

https://www.thethingsnetwork.org/forum/t/wifi-config-on-a-multitech-mlinux-conduit/1244

Hope this helps!

Cheers,
Mike

[Mike Fiore]

Mark,

Thanks for the debug info. The mbed-os-5.3.4 release introduced a bug that affected the xDot platform – essentially, setting a GPIO to 0 was impossible via the DigitalIn, DigitalOut, InterruptIn, etc APIs. The fix is in the mbed-os-5.4.1 release, but we don’t have any builds against that release yet.

We should have some new dev builds out relatively soon, but for now, the versions built against mbed-os-5.3.2 are your best bet.

Cheers,
Mike

[Mike Fiore]

Mark,

You could use the RTC to see how long the xDot was sleeping. Just save the time to the EEPROM before going to sleep and compare to the time after you wake up.

We don’t currently have a method to let you know what the wakeup source was, but it’s on our list. I’ll see if I can get it into the next release.

Cheers,
Mike

[Mike Fiore]

Martin,

There’s no Dot Library API for any of this – we’re in the application realm now.

You’ll have to send a message to all the slaves (from the master) with the RTC time they should be set to. Or you’ll have to come up with some other way to sync the RTC.

Once that’s done, your slaves should be able to figure out when they should or shouldn’t be transmitting a few different ways:
* poll the RTC (it has a sub-seconds register)
* use the RTC Periodic Wakeup Timer

Full documentation for the RTC is found in the STM32F411RE reference guide.

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

Hope this helps!

Cheers,
Mike

[Mike Fiore]

Martin,

Unfortunately not. Peer-to-peer mode is listening whenever not transmitting.

One thing you could do is sync up the RTCs on your slaves and then assign each device a “slot” for its communication with the master device.

Cheers,
Mike

[Mike Fiore]

Albert,

Are you asking about a specific MTS product?

Cheers,
Mike

[Mike Fiore]

Excellent! Glad to hear things are working!

Thanks for choosing MultiTech!

Cheers,
Mike

[Mike Fiore]

Naushad,

RTX error code: 0×00000001 is a stack overflow. One of the threads in your application is using too much static memory. Try allocating any large buffers, etc from the heap instead. If you still have issues, you’ll need to reduce your application’s overall memory consumption (stack & heap).

Cheers,
Mike

[Mike Fiore]

Martin,

Assuming based on your info that you’re using rev 80 of libmDot-dev-mbed5. Can you try rolling back to rev 79 or 78? They’re both the same version of library source but use slightly older mbed-os versions.

Cheers,
Mike

[Mike Fiore]

Mark,

I haven’t tried using OpenOCD 0.10.0 – results may vary there. I have had good results with 0.9.0 on Ubuntu 14.04.

Also, I suggest making sure your UDK2 has been updated to the latest ST-Link interface firmware.

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

Cheers,
Mike

[Mike Fiore]

Martin,

Are you using AT command firmware or building a custom application? What firmware/library version are you using? What mbed-os version are you building against?

Do you see these errors on startup or after attempting LoRa communication?

Cheers,
Mike

[Mike Fiore]

Mark,

If you’re using a UDK2 already, why not just use the onboard interface to flash and debug?

We have a pretty detailed guide for debugging mDot using GDB and OpenOCD on our mbed wiki:

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

Cheers,
Mike

[Mike Fiore]

Mark,

Sorry for the confusion – the USBTX/RX pins are regular GPIOs. I think using the RX pin as a GPIO should be fine.

I will open a doc ticket as well so the developer guide is made more clear.

Cheers,
Mike

[Mike Fiore]

Andrew,

You’re correct. The fix is currently only in the development build.

I’ll be pushing out a 2.0.16 production build for mDot in the near future.

Cheers,
Mike

[Author]

Posts