[Mike Fiore]

There was an issue with the mbed system “tick” getting corrupted after xDot wakes from sleep mode. This is resolved in the latest Dot Library 3.0.0 release candidate and will be in the production 3.0.0 release.

[Mike Fiore]

Andrew,

Did the application reproduce with libxDot-dev or just libxDot? This may indicate that a certain mbed-os version has a bug and another version does not.

It is possible to debug your application (excluding the Dot Library code as it isn’t compiled with debug symbols) using OpenOCD and GDB. You’d want to use the cmsis-dap interface config file and the stm32l1 target config file.

Strange that adding a object declaration in the global space before main causes problems. I think I recall some issues with initialization order in earlier mbed-os versions. I think it was reproduced similar to what you’re doing – adding a global object before main.

Hope this helps!

Cheers!
-Mike

[Mike Fiore]

Jade,

The ARMmbed device is probably the debug port. You’d want to be issuing the AT commands on the other device which should be the command port.

Does communication with a PC (instead of the Android) work OK? If so, I’d be inclined to think the issue is on the Android side.

Are you using an existing Android app or writing a new one?

Cheers,
Mike

[Mike Fiore]

Scott,

We don’t normally allow customers to change the Dot’s factory configuration.

However, our 3.0 release of the Dot Libraries allows you to compile in the channel plan you’d like to use, regardless of the frequency band the Dot was configured for. Please note that this is for development only and devices **should not** be deployed this way. We’ve released development builds of 3.0 and the production builds will be out soon.

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

Cheers!
-Mike

[Mike Fiore]

Andrew,

Do you have a simple application (Dot-Examples for instance) that reproduces the issue reliably?

Cheers,
Mike

[Mike Fiore]

Jade,

The Dot AT firmware uses 8N1 at 115200 baud by default. You will want to make sure you Android side has flow control turned off.

Cheers,
Mike

[Mike Fiore]

Noman,

Your application needs to be compiled with the same mbed-os version the Dot Library was compiled with (see the revision for mbed-os and the Dot Library). When you’re looking at the revisions, the bolded line is the current version you’re using. You can switch to other versions by clicking the desired version and the “switch” button.

The STLink Virtual COM Port should be the device’s debug port. Make sure your terminal emulator has HW flow control turned off and has the baud set to match your application.

If you still run into issues, you can try out our example programs for the Dots. We have a manual mode example (looks like that’s what you’re trying to do).

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

You’ll need to import the mDot library. The development version for mDot is the newest and best and is compatible with the latest version of the examples.

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

Cheers,
Mike

[Mike Fiore]

Andrew,

What mbed-os version are you using? Does you application include the Dot Library or any other libraries? What versions of those libraries are you using?

Cheers,
Mike

[Mike Fiore]

Andrew,

You’re right, this is an issue because of the channel plan changes.

ChannelPlan.h has a new enum for channel plan definitions, including *_OLD versions that match the FB_* definitions. But the name is still different, so that’s not very helpful. This was an oversight on my part. Sorry about that.

I’ll add all the old enum names to this as well so everything is backwards compatible. That change should be in the next dev release and will make it into the production builds as well.

Cheers,
Mike

[Mike Fiore]

Jaco,

Currently there is no way to do this. I will document it as a feature request for the bootloader.

Cheers,
Mike

[Mike Fiore]

Scott,

I was mistaken on one point. When the LORA_BUFFER_FULL error code is returned to send, the packet has been sent, but just the MAC command responses (without the payload because there wasn’t enough room for it). So after that send is done, you should be able to call send again with your payload and it should go through.

Sorry for the confusion!

Cheers,
Mike

[Mike Fiore]

Scott,

This code is LORA_BUFFER_FULL. There was a bug where this wasn’t coupled with a good mDot error code in some cases. You’d get this when you’re attempting to send data but there’s not enough room because there are MAC command responses in the option bytes for the next uplink packet.

We intend to add a new function so customers can see how much space is available in the next uplink. A workaround is to send an empty packet first, then try sending again.

Cheers,
Mike

[Mike Fiore]

min,

Looks like issues with I2C which is the peripheral all those sensors are on. What mbed-os and Dot Library versions are you using?

Cheers,
Mike

[Mike Fiore]

min,

We have development builds of the Dot Libraries available that allow the AS923 channel plan to be used on mDot and xDot.

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

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

Firmware updates for the DotBox will be coming later.

Cheers,
Mike

[Mike Fiore]

Are you building your own application or using the default AT firmware? What version of the Dot Library or Firmware are you using? What version of mbed-os (if building an app)? If building an app, are you using the same mbed-os version the Dot Library was compiled with?

Do you have the speed set correctly on the COM port? The AT firmware defaults to 115200 on the command and debug ports.

Cheers,
Mike

[Mike Fiore]

Shaheen,

The xDot drive should automatically remount after it’s finished flashing the new firmware onto the target processor.

Is there a “fail.txt” file in the drive after it remounts?

What application are you trying to run? What versions of mbed-os and the Dot Library are you using?

What OS & version is your PC running? Is your xDot on a DK or a custom board?

Can you run mbed-ls with you xDot plugged in and post the result?

Cheers,
Mike

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

[Mike Fiore]

Noman,

The debug UART from the mDot is available over the USB connection. You should get 2 COM/tty ports on your PC when you plug in the MDK. One will be the AT command port and the other will be the debug port.

You’ll want to make sure that debug logging in the Dot Library/AT Firmware is enabled by issuing AT+LOG in the AT Firmware or using the Dot Library API call setLogLevel(const uint8_t& level). Level 0 is off and level 6 is maximum logging.

Cheers,
Mike

[Mike Fiore]

Eugene,

That may mean the flash filesystem on your device has been corrupted. Can you share debug logs so we can diagnose the issue?

Cheers,
Mike

[Mike Fiore]

Loic,

Do you have an EU868 mDot/xDot? If so, the regional regulations require the device to obey duty cycle restrictions. What you’re seeing is likely the result of the device obeying those rules.

How often the device can transmit depends on TX power, how many channels are enabled, etc. Do you remember how you had your device configured before you reset the configuration?

Cheers,
Mike

[Mike Fiore]

Eugene,

The ability to change the device’s factory configured frequency band isn’t in normal firmware. Can you help us understand why you need to do this?

Cheers,
Mike

[Mike Fiore]

Brandon,

The mts-io-sysfs script should be available on AEP and mLinux devices. It allows you to see EEPROM contents Jeff mentioned.

mts-io-sysfs show product-id

Cheers,
Mike

[Mike Fiore]

Amod,

We are finishing up development and testing on the new implementation. It will be publicly available soon.

Cheers,
Mike

[Mike Fiore]

Amod,

The current MTSAS implementation doesn’t allow this because of the way it handle sockets. Our new implementation (supporting mbed-os) handles sockets in a cleaner way and will allow concurrent open sockets and GPS queries.

Cheers,
Mike

[Mike Fiore]

Peter,

The operating range is -40C to +85C. We will get the doc updated.

Cheers,
Mike

[Mike Fiore]

Claudio,
mbed applications can be compiled using IAR, ARM, and GCC_ARM toolchains. Are you desiring to work offline instead of using the online compiler? If so, check out mbed-cli: https://github.com/ARMmbed/mbed-cli

We currently only support the mbed environment for the Dot devices. We provide versions of the Dot Libraries for use with ARM and GCC_ARM toolchains.

Hope this helps!
Cheers,
Mike

[Mike Fiore]

Ajay,

US dots should only be deployed in the US. You need to deploy AU dots into the AU region. Current firmware & library implementation doesn’t allow a US dot to operate on AU frequencies or vice versa.

The AU channel plan is similar to the US channel plan. You can look at the LoRaWan spec and regional parameters documents for more details.

Cheers,
Mike

[Mike Fiore]

The network server has a command port. You can query it for current config which will contain the EUI and KEY as well as the name and passphrase.

http://www.multitech.net/developer/software/lora/lora-network-server/

Cheers,
Mike

[Mike Fiore]

Ajay,

I asked around and it sounds like we don’t have plans to add custom channel plan support to the network server at this time.

Cheers,
Mike

[Mike Fiore]

Ajay,

I believe the 3.x.x release is slated for Q3. I can’t speak to the gateway/Network Server side of things, but I’ll ask around.

Cheers,
Mike

[Mike Fiore]

Current format for the data packet is here:

http://www.multitech.net/developer/software/dot-box-and-evb-software/data-packet-format/

You can see what’s taken already. Any ID values that aren’t taken could be used in your application for new data types.

Cheers,
mike

[Author]

Posts