[Andrew Lindsay]

It would be better if your customers were able to make the decision to use deep sleep or not themselves.

Have Multitech been taken over by Apple?

[Andrew Lindsay]

If you’re using deep sleep on the mDot then be warned that Multitech have removed this feature from the mDots and was only discovered during debugging to identify why it wasn’t working as expected anymore.

[WARNING] This mDot hardware version does not support deep sleep… using sleep.

Therefore a lot of your code may no longer work as expected. They claim that it is because some customers found it wasn’t as low power consumption as they expected. I’d like to have been the judge of that and decide if I want to use this feature in my designs.

The workaround is to not update the libmDot library and stick with the revision 15:b50f92f which does include the functioning deep sleep mode.

Andrew

[Andrew Lindsay]

Mike,

Deep sleep on the mDot in mbed-os5 was removed and replaced with a warning saying regular sleep was being used. This meant I couldn’t migrate the device to mbed-os5.

Thanks

Andrew

[Andrew Lindsay]

Yet more functionality removed from the mDot platform when moving from mbed-os2 to mbed-os5.

This really shouldn’t be happening as it annoys and frustrates customers.

Andrew

[Andrew Lindsay]

Using a 100% duty cycle is a bad idea as you’ll be blocking the signal for any other device using the same frequencies.

The spreading factor/datarate is a trade off:

Low SF will allow larger payloads to be transmitted in a shorter time but over a much reduced distance.
High SF will require smaller payloads to be transmitted over a longer time but the range will be much greater.

You pick whats best for your application and use-case.

Andrew

[Andrew Lindsay]

Sorted it now. I did have a pull-up on the input instead of a pull-down. Fixed now and working correctly.

Thanks

Andrew

[Andrew Lindsay]

Hi Mike,

I have a board with the mDot on it, this includes a programming header which is effectively connected to the programming header on the mDot. The board received no power from the UDK as it has its own power source. The UDK is linked to my board via a short cable connecting the UDK programming header to the header on the board.
I am able to program mDot this way as if it was plugged into the UDK.

I have an application that uses both the Interrupt wake up and the interrupt/rtc wakeup from deep sleep.
There is also the scenario where the RTC only wakeup is disable the wakeup pin for a number of minutes.

The device wakes up, checks if it was woken up by the timer or interrupt, if timer, checks if its time to send a heartbeat message then either sends a message or not. It then goes to deep sleep waiting for either the RTC or Interrupt with a 10 minutes sleep.

If it’s woken up via the interrupt then it sends a message and goes to deep sleep with RTC wakeup only after 10 minutes.

This all works fine while connected to the UDK with a serial monitor looking at the output. As soon as the cable between the two boards has been disconnected the mDot refuses to wake and is shown by not receiving any messages when it supposed to wakeup.

The only way to get it back to life is to press a reset button on my board. If I have then reconnected the cable to the UDK it then starts to send debug messages as normal.
I can also tell that it has not woken up in the meantime because there is a record of the last time it sent a message based on the RTC and a sequence number that is incremented each time a message is sent.

Any ideas? I’m going to try to put together a simple example to try to narrow down where the problem could lie.

thanks

Andrew

[Andrew Lindsay]

The other difficulty when developing your own board is that you need to create the footprint for xDot as Multitech don’t provide this. All you have to go on is a drawing with dimensions in the developers guide.

Andrew

[Andrew Lindsay]

Using a simple usb to serial adaptor you can connect to the mDot. Then you can drop into the bootloader by pressing a few keys after reset and upload files via YModem transfer and program them this way however I’ve found this transfer method to be unreliable even for small files of around 500 bytes.

Andrew

[Andrew Lindsay]

Further investigation on this issue, it looks like the device wont wake up once I disconnect the UDK dev board used to debug the device. Is there anything in the default UART configuration that could cause this to not wakeup?

Thanks

Andrew

[Andrew Lindsay]

no, you need the xDot developer board and a suitable cable to a programming header on your board.

[Andrew Lindsay]

[Andrew Lindsay]

The receive windows are there for downlink messages too.

[Andrew Lindsay]

Are you now saying that all of the libraries, whatever version I use will not allow deep sleep on the mDot?

I had tried mbed5 and got these issues, I’ve now had to roll back to the previously working libraries. I also found further issues with the mbed5 version of the library:

1. it would not wake up if using INTERRUPT
2. RTC failed to return the correct time, is starting from 0 when the mDot is powered on

Disabling the deep sleep should be up to the end user after they have done their own tests to see if its worked. Just disabling it without even creating a changelog is not acceptable.

Andrew

[Andrew Lindsay]

As another side effect of this bug, the function getStandbyFlag() no longer works. Previously it returned true when waking up from deep sleep, now deep sleep is not working it always returns false.

Thanks

Andrew

[Andrew Lindsay]

The BLE module I have, the Microchip RN4020, is UART so not SPI/I2C. However I’m not sure its actually the best one for what I was trying to achieve and may change it for another more suitable device.

Andrew

[Andrew Lindsay]

The latest mbed and mbed-rtos dont work with the libmDot library. You need to use:

libmDot 1.0.8-1-g7ae9ef7
mbed 121
mbed-rtos 110

or the releases listed on the libmDot page if you are using the latest version of the library. The above is what works for me and is a pain in the butt to keep it at this level.

thanks

Andrew

[Andrew Lindsay]

Thanks Mike.

[Andrew Lindsay]

Yes I did create an Eagle footprint for the mDot, but only the through hole version. I was looking to include the SMD pads as an alternative technology within the library but never finished it.

I’ll check it and post to github when I remember.

Focus has now moved to the xDot but not having one to examine that isnt on a dev board or decent documentation doesnt help. Come on Multitech, how are customers expected to uses these module when you don’t provide footprint diagrams yet.

thanks

Andrew

[Andrew Lindsay]

Not sure about your versions, but for libmDot 14 I’ve been using mbed 121 and mbed-rtos 110 as the latest version combinations that work without error. Later versions of mbed-rtos wont compile at all.

There may be some delay in instantiating the libmDot library depending on what join mode you are using. If using AUTO OTA then this is likely to be reading the preserved session data from flash. You might like to try different join methods and see if this makes a difference, for example MANUAL might be quicker, but without access to the code we cant see exactly what its doing internally.

If you’ve saved the config then I wouldn’t expect you’d need to set the TxPower, AntennaGain and Ack each time.

Andrew

[Andrew Lindsay]

I have used the mDot with a Microchip RN4020 BLE module and have been able to use this to create a LoRa with BLE temperature sensor using one of the built in profiles. For a laugh, the probe was advertising itself as Rectal Health Thermometer!

I was intending to use a bluetooth module as a way of configuring and managing the sensor but the BLE profiles don’t directly support a UART mode. The RN4020 does support a Microchip version of the UART and requires code on the mDot to actually make it work properly.

Andrew

[Andrew Lindsay]

What news on the wDot?

[Andrew Lindsay]

I’ve used this sensor or an equivalent (AM2302) with this library on port PA_0 without issues. This pin was chosen as it was available on the PCB I’ve developed for the mDot.

Andrew

[Andrew Lindsay]

mDots are powered by 3.6V LTC cell.

All seems to be working now.

Thanks.

[Andrew Lindsay]

I’ll try this again. I did have some mDots that had failed first time, swapped for new one, then put them back so they had been powered off.

Let me retry and get back to you.

Thanks

Andrew

[Andrew Lindsay]

That would explain it.

Thanks

Andrew

[Andrew Lindsay]

Hi Leon,

Its on-line, libmDot 1.0.8-1-g7ae9ef7
mbed 121
mbed-rtos 110

I cant provide the app in a public forum due to it being for a client, plus it is on custom hardware with a PIR sensor driving the input. A generic app with alternate deep sleep using INTERRUPT and RTC_ALARM should show the effect.

After further updates, I think I might have found a workaround and got it working.

Thanks

Andrew

[Andrew Lindsay]

I’ve got some something that might be connected. I’m using the mDot::INTERRUPT and mDot::RTC_ALARM deep sleep options in the same application. The idea is that once it has been triggered and sends data, it uses the RTC_ALARM to sleep for 5 or 10 minutes before allowing itself to be woken again.
Once it wakes from deep sleep via the RTC it will sleep using INTERRUPT until it is triggered by the input.
What I am seeing is the mDot goes into deep sleep from the RTC_ALARM but can be immediately triggered by the input pin which is not what I’m expecting.

Is there something I’m doing wrong?

**UPDATE** After posting this, I notice it is not every time this happens. So, is there a reason the RTC_ALARM would not sleep properly. Is it due to a wrong state on the INTERRUPT input?

Thanks

Andrew

[Andrew Lindsay]

You should be able to buy the parts elsewhere as this is a regular external enclosure that the conduit mounts inside. I did see a supplier of the same enclosures but cant remember where. All the other components are available too.

Andrew

[Andrew Lindsay]

Hi Mike,
Any timescales for when you’re likely to have the online mbed available?

Thanks

Andrew

[Author]

Posts