[Ryan Klaassen]

Did this work without modification to the code?

[Ryan Klaassen]

sleep_wake_rtc_or_interrupt(deep_sleep, sleep_interval); Is this modified from the original?

[Ryan Klaassen]

I cannot reproduce this problem, could you share your code?

[Ryan Klaassen]

This is supposed to be the same part. It looks like there are slightly different dimensions for the layout example. Since the gain is lower, the certifications should still be valid.

[Ryan Klaassen]

That is correct, the ticker ISR in your code will only fire after the dot has been awake for 2 seconds.

[Ryan Klaassen]

I am not quite sure what you are asking. When the xdot is sleeping it can only be woken by a pin set as an interrupt in or the alarm. An ISR can happen when the dot is already awake or sleeping. No blocking code should be run in an ISR. An ISR should do as little as possible, such as set a send_flag. The main loop can then check this flag before it sleeps and send if needed.

[Ryan Klaassen]

No the ticker timer is not running across sleep. Also printing in an ISR can, and probably will, break things. The dot is waking up and immediately going back to sleep this will never allow the timer object to start counting. Only the RTC is running across sleep for the dot.

Other notes of interest from mbed:
Warnings and notes

No blocking code in ISR: avoid any call to wait, infinite while loop or blocking calls in general.

No printf, malloc or new in ISR: avoid any call to bulky library functions. In particular, certain library functions (such as printf, malloc and new) are not re-entrant, and their behavior could be corrupted when called from an ISR.

While an event is attached to a Ticker, deep sleep is blocked to maintain accurate timing. If you don’t need microsecond precision, consider using the LowPowerTicker class instead because this does not block deep sleep mode.

[Ryan Klaassen]

GCC 7.2.1 is not currently supported by mbed. It recommended to use GCC 6 with mbed-os-5.7.7. Have you tried GCC 6?

[Ryan Klaassen]

I cannot reproduce this issue currently. I used the dev-lib, mbed-os-5.7.7 and gcc 6. Is there something else that you are doing differently than this?

[Ryan Klaassen]

Are you using sleep or deepsleep? When you say “doesn’t appear to be working” does that mean nothing is printing out on the debug port? Are you using sleep_wake_rtc_or_interrupt(deep_sleep);?

[Ryan Klaassen]

Have you tried GCC 4.9? If using mbed-5.4.7 GCC 4.9 is recommended.

[Ryan Klaassen]

There is no function for retrieving the serial number. One way to do this would be to program it in a file on the mDot.

[Ryan Klaassen]

One example is:

char data[] = “hello”;

dot->saveUserFile(“test1”, (void*)data, 5);

Another way of doing it would be
char data[] = “hello”;
mDot::mdot_file file = dot->openUserFile(“test1”,(mDot::FM_RDWR|mDot::FM_CREAT));
dot->writeUserFile(file, (void*)data, 5);
dot->closeUserFile(file);

[Ryan Klaassen]

Hello Arty29,

Due to some I2C issues, the MTDOT-BOX should be built with mbed-os-5.1.4. The dot library should also have been compiled with mbed-os-5.1.4. The toolchain used with mbed-os-5.1.4 is gcc 4.9.

Let me know if this fixes your issues.

Thanks,

Ryan

[Ryan Klaassen]

Hello Gary,

According to Microsoft (https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-python-getstarted) “The pip packages for azure-iothub-service-client and azure-iothub-device-client are currently available only for Windows OS. For Linux/Mac OS, please refer to the Linux and Mac OS-specific sections on the Prepare your development environment for Python post.” Here is the link for Linux/Mac OS sections https://github.com/Azure/azure-iot-sdk-python/blob/master/doc/python-devbox-setup.md .

[Ryan Klaassen]

Here is a guide to help get you started, http://www.multitech.com/documents/publications/manuals/s000612.pdf. Page 11 has information on programs to communicate with the mDot, and settings.

-Ryan Klaassen

[Author]

Posts