[Mike Fiore]

Ajay,

I was able to reproduce the issue. Revision 75 of libmDot-dev-mbed5 (latest as of right now) with mbed-os-5.2.2 seems OK. I’d suggest upgrading to those versions.

Cheers,

Mike

[Mike Fiore]

Ajay,

XBEE_IN is not a valid pin name – perhaps you meant XBEE_DIN?

Cheers,

Mike

[Mike Fiore]

Ajay,

Which pin is no longer working?

Cheers,

Mike

[Mike Fiore]

Yusuf,

We’re not aware of any I2C issues with mbed-os 5.3, but we also haven’t done much testing with that release yet. Please let us know how it goes if you try it out.

The mbed-cli documentation can be found on GitHub:

https://github.com/ARMmbed/mbed-cli

Cheers,

Mike

[Mike Fiore]

The documentation you’re looking for is linked from the developer page for the dotbox:
http://www.multitech.net/developer/products/multiconnect-mdot-box-and-evb/

If using LoRa Demo, Survey Single, or Survey Sweep mode: http://www.multitech.net/developer/software/dot-box-and-evb-software/data-packet-format/

If using Survey GPS mode:

Survey GPS

[Mike Fiore]

That’s correct. I will see if I can get the latest code pushed out.

Cheers,

Mike

[Mike Fiore]

Sabrine,

I don’t see any reference to RS485 or modbus in the STM32F411RE reference guide or datasheet, so I don’t think the UARTS on the processor natively support it. You might be able to implement it in software if you really really wanted to.

Your best bet is probably to use an external RS485 transceiver.

Cheers,

Mike

[Mike Fiore]

Tom,

The code is available on mbed. It’s a slightly older version, but it should be pretty similar.

https://developer.mbed.org/teams/MultiTech/code/MTS-Utils/

Cheers,

Mike

[Mike Fiore]

Adam,

Is your Dot US915, AU915, or EU868?

If it’s EU868, there are duty cycle restrictions that limit how often channels can be used. After a channel is used to transmit, it is disabled based on how long it was on air and what duty cycle applies to it. When all channels are disabled, the Dot can’t transmit.

Cheers,

Mike

[Mike Fiore]

Syzmon,

The libmDot-mbed5 libraries aren’t compatible with mbed & mbed-rtos and must be used with mbed-os. I think that was the issue all along.

To get the new FW to the mDot, you would need something on the server side that queues up chunks of the new firmware to be transmitted down the mDot. The mDot could keep sending empty packets so it gets the new FW faster. You could also use class C mode and basically have the network server stream the FW to the mDot. The mDot would need to put the firmware back together and store it in the filesystem on the external SPI flash. You’ll probably want some kind of application level protocol in order to successfully transfer the file.

Once you’ve got the full new FW on the mDot, rename the file and reset like I mentioned earlier and the bootloader will take care of the rest.

Hope this helps.

Cheers,

Mike

• This reply was modified 8 years, 6 months ago by Mike Fiore.
• This reply was modified 8 years, 6 months ago by Mike Fiore.

[Mike Fiore]

Martin,

Good to hear! Let us know if you have other questions.

Thanks for choosing MultiTech!

Cheers,

Mike

[Mike Fiore]

Martin,

I don’t believe “Master-1.0” is a valid FW version on the mDot. You can get the FW versions by issuing ATI on both devices.

Can you download the latest mDot and xDot AT firmware from multitech.net and try again. Please follow these steps after flashing both devices with new firmware:

AT&F
AT&W
ATZ

Then reconfigure both devices and try again.

Cheers,

Mike

[Mike Fiore]

Martin,

What version of firmware are you using on both devices? Does it help if you default config on both devices and reconfigure both? I’m assuming they’re both 915 or both 868 devices?

Cheers,

Mike

[Mike Fiore]

Syzmon,

WRT your first question:

RTX error code 4 is timer overflow. The error codes are defined in mbed-os/rtos/TARGET_CORTEX_M/RTX_Config.h. The only place where this error can be returned is from the systick isr (sysTimerTick) in rtx/TARGET_CORTEX_M/rt_CMSIS.c. I haven’t seen this show up in practice before. Can you share some information about the application that is causing this error? Is there some portion of your code that is running in a tight loop or starving other threads in some way?

WRT your second question:

We don’t currently support OTA firmware updates for the mDot, but it does have a bootloader that will flash new firmware if it finds new firmware in the filesystem on the external SPI flash. We have a writeup about updating firmware using the bootloader on mbed.

https://developer.mbed.org/teams/MultiTech/wiki/updating-firmware-using-MTS-bootloader

You’ll be interested in the “Updating Firmware from User Applications” section. You’ll have to get the FW to the mDot via serial, LoRa, etc, and put it into the filesystem using the mDot filesystem API. Then you’ll call

bool moveUserFileToFirmwareUpgrade(const char* file);

to give the file the proper name. Finally, initiate a system reset

void resetCpu();

On startup, the bootloader will detect the new firmware and update the application. The update should take ~15 seconds, but this will vary depending on the size of the new application.

Hope this helps!

Cheers,

Mike

[Mike Fiore]

Michael,

It’s true that you can currently only set 1 sub band at a time, but you should be able to achieve this by modifying the channel mask. The Dot library has functions to support this:

        std::vector<uint16_t> getChannelMask();
 
        int32_t setChannelMask(uint8_t offset, uint16_t mask);

The Dot AT firmware uses these functions to implement the +CHM command. It’s documented in the AT command guide.

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

Here’s the source of the +CHM command.

https://developer.mbed.org/teams/MultiTech/code/Dot-AT-Firmware/file/e20116281a78/CommandTerminal/CmdChannelMask.cpp

Cheers,

Mike

[Mike Fiore]

Yogesh,

Yes, the resetCpu function performs a soft reset of the device via software.

Cheers,

Mike

[Mike Fiore]

Lawrence,

That is correct. Either the gateway didn’t RX the ping packet from the endpoint or the endpoint didn’t RX the gateway’s pong packet.

Cheers,

Mike

[Mike Fiore]

Andrew,

Correct. We don’t currently support this feature in the library, but like I said, I’d like to get it added. I’m hoping that will be sooner than later.

Cheers,

Mike

[Mike Fiore]

Andrew,

We are disabling RTC Alarm A, our time based wakeup source, and clearing its interrupt flags as part of the wakeup process. I don’t think you’d see the RTC_ISR_WUTF bit getting set because we’re not using it in the sleep/wakeup process. I believe we did in very old versions of the library, but recently we’ve been using RTC Alarm A.

This is a feature I’d like to officially add support for in the library. I’ll see if I can get something into the dev library versions in the near future.

Cheers,

Mike

[Mike Fiore]

Syzmon,

Is the problem you were experiencing resolved, then?

Using mbed-os and libmDot-dev-mbed5 or libmDot-mbed5 is what I would encourage.

Cheers,

Mike

[Mike Fiore]

Andrew,

Glad to hear it! We greatly appreciate your feedback and your activity on the developer forum and mbed!

Cheers,

Mike

[Mike Fiore]

Hi Faustin,

I did some looking around and found a few things. Here’s the search:

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

And some results:

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

Hope this helps!

Cheers,

Mike

[Mike Fiore]

Syzmon,

I guess I’m a little confused. Earlier in the thread you said you were using libmDot-dev-mbed5, mbed-dev, and mbed-rtos. Perhaps one of us misspoke.

Can you share with me what versions (the more specific the better, links would be great) of the Dot library (libmDot, libmDot-mbed5, libmDot-dev-mbed5), mbed library (mbed, mbed-dev, mbed-os), and mbed-rtos you’re using?

Please note that if you’re using mbed-os, you won’t need to include mbed-rtos.

Cheers,

Mike

[Mike Fiore]

Andrew,

We’re working on updating documentation that explains the differences you’re observing. The short version is this:

libmDot 17:0da384b sleep mode sets most internal IO pins to analog input with no pull resistors to achieve the lowest possible consumption. A few must be set low or high instead of left floating. External IO pins are the responsibility of the user for the following reason: we don’t know what is happening on those pins. Your application may need to keep a pin high, low, etc while the device is asleep. We have code in the Dot-Examples program that demonstrates how the user application can put whichever of these pins they wish into the analog input no pull state for lowest consumption. If you add this code to your test for sleep mode, you’d see current consumption similar to deepsleep.

libmDot 17:0da384b deepsleep mode handles the internal IO pins similarly to sleep mode but also handles the external IO pins, emulating what would happen in ST standby mode. Nearly all of the external IO pins are set to analog input no pull except for the few we discovered that are causing the extra current consumption in some situations. The processor goes into stop mode just, RAM is retained, and the application resumes after waking up just like sleep mode. The only difference is what happens to the external IO pins.

We will be updating the warning box on the mDot platform page in the LoRa Stack section to better explain this difference.

Hope this helps.

Cheers,

Mike

[Mike Fiore]

Ajay,

If you want to investigate our new libraries that support mbed 5, you should take a look at our Dot-Examples program which contains a number of example applications for the mDot and xDot.

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

If you want to try out the latest libmDot in mbed 2 instead, you can use the mDot_LoRa_Sleep_Example.

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

In both cases, sleep mode on the mDot should get current consumption into the ~50uA range.

Cheers,

Mike

[Mike Fiore]

Yogesh,

You should use mbed 121 and mbed-rtos 116 as stated by the commit message for the latest version of libmDot.

Here’s a link to the changelog for the Dot libraries. Besides disabling deepsleep mode and reducing the current consumption in sleep mode, the latest libmDot revision doesn’t have any of the features listed for newer versions.

https://developer.mbed.org/teams/MultiTech/wiki/Dot-library-change-log

Cheers,

Mike

[Mike Fiore]

Lawrence,

I apologize again for the confusion. That’s actually what is happening. The library is disabling the channel, according to the duty cycle restrictions in that frequency band, until its time off air has expired and it is able to be used again.

Hope this helps!

Cheers,

Mike

[Mike Fiore]

Ajay,

That’s correct. Your session should also be saved so that you don’t need to rejoin the network after waking up.

Cheers,

Mike

[Mike Fiore]

Syzmon,

Can you share which versions of mbed-dev, mbed-rtos, and libmDot-dev-mbed5 you’re using? I wasn’t aware that mbed-dev and mbed-rtos (mbed 2 builds) were compatible with our mbed 5 build of libmDot-dev-mbed5.

Cheers,

Mike

[Mike Fiore]

Yogesh,

We’ve disabled deepsleep mode on mDots in the new library code because there is a HW issue that makes the deepsleep current draw unpredictable: it may be at the ~50uA level it should be at or it could be in the mA range instead.

That being said, we have been able to bring sleep mode current draw down to the ~50uA range as well, so there really isn’t a downside to using sleep mode instead of deepsleep mode. We are encouraging customers to go down this route and we think it should be an easy choice. The fact that RAM and IO state are retained in sleep mode should allow you to simplify your application quite a bit.

The latest version of libmDot (for mbed 2) will also disable deepsleep on the mDot for the same reasons I stated above. That revision should also have the lower sleep mode current draw I mentioned earlier.

https://developer.mbed.org/teams/MultiTech/code/libmDot/rev/0da384ba484b

Hope this helps!

Cheers,

Mike

[Author]

Posts