Gen 3 improvements update - 2/12/19

Particle Updates
, ,
1

Hello from the Particle team!

It's been a while since our last "Gen 3 improvements update" last December, which documents the progress and priorities of the team working to improve the development experience of our Gen 3 hardware.

Here’s a roundup of updates since last December, and a sneak peak at what’s coming down the pipe:

1. Where we’re at

Feedback on rc.27

Generally, the feedback from the community was that v080-rc.27 improved the stability of the Gen 3 development experience for most of you. Here are the results of the previous survey.

16
16742×715 39.8 KB

  • 65% of you said that rc.27 made the development experience better.
  • Interestingly, the score of 5.88 / 10 represented a slight decline over rc.26 (which received an average score of 6.08 / 10).

As a result of this feedback, we’ve continued to focus our development efforts on improving the stability and completeness of the Gen 3 development experience.

2. What’s coming next

Device OS v0.9.0

We’re in the process of testing a new Device OS release for Gen 3 devices which will be released under the v0.9.0 line.

Note that this release was previously named v080-rc.28 in conversation on the forums.

As we already stated, this release is primarily focused on stability and completeness of the Gen 3 development experience, as opposed to new features. Here are some of the notable headlines in that release:

  • :zzz: Sleep modes

    We’re adding support for STANDBY and STOP modes for Gen 3 devices.

    Note that the RTC of the nRF52840 does not continue operating in STANBY mode, so it will not be possible out-of-box to wake the device from STANDBY mode after a fixed period of time. It will be possible to wake the device with either a falling edge on the RESET pin or a rising edge on WKP pin (D8), or after a fixed duration in STOP mode.

    The user APIs for these features will be exactly the same as the implementation for Gen 2 devices. If you’re not familiar with the APIs, you can check them out here:

    Particle Reference Documentation | Device OS API

  • :signal_strength: Cellular.command() support

    We’ve implemented the full set of cellular.command() APIs available for Gen 2 devices which unlock the full capabilities of the Boron's onboard cellular modem. Existing documentation about the Cellular.command() API can be found in our documentation, here.

  • :bug: General bug fixes and stability improvements

    We’ve fixed a bunch of bugs that should resolve some issues reported with Gen 3 devices. The release should resolve the following issues listed on our “Particle Mesh Known Issues and Fixes” post, here:

    • :white_check_mark: Device Issue #2 – SYSTEM_MODE(MANUAL) and SEMI_AUTOMATIC not working properly

    • :white_check_mark: Device Issue – Resolved NCP lockup issue present in rc.27

v0.9.0 is currently being tested by our internal team and a new Gen 3 Customer Council which has been formed to help us enhance our product development process with customer feedback from individuals in our community just like you.

3. Still in development

As we noted at the end of last year, we’re still working on a handful of high priority features and improvements that will further enhance the Gen 3 development experience. We don't have release dates for these features yet, but all are in various stages of progress.

Gen 3 stability

Gen 3 completeness

  • Support for over the wire / CLI setup flows for Gen 3 hardware
  • End device support for Argons / Borons in a Mesh network
  • Debugging support for Gen 3 hardware in Particle Workbench

New features for Gen 3

  • Bluetooth support
  • Support for High Availability networks (Mesh networks with backup / redundant border routers)

More to come this week / next as we prepare the v0.9.0 release! Feel free to ask questions / comments below.

Will

12 Likes
2

Thanks for this feedback/update. I am keen to see the sleep modes in operation but I am unclear how these 2 statements fit together:

the RTC of the nRF52840 does not continue operating in STANDBY mode, so it will not be possible out-of-box to wake the device from STANDBY mode after a fixed period of time

and

The user APIs for these features will be exactly the same as the implementation for Gen 2 devices.

Currently if I call System.sleep(wakepin, RISING, period); I get a wake after period seconds or on a rising signal on wakepin but if the nRF52840 can't continue the RTC whilst in STANDBY sleep then presumably the period is redundant? Does this mean a sleepy end node using a Xenon will require an external timer IC to generate the 'wake' signal?

3

@armor, I believe that will still work the same, since:

4

Nice work, and very well done on the write-up.

Do you foresee any obstacles to being able to process incoming SMS’s when Cellular. command() is used?

5

In this statement the WKP is fixed to D8. Is this set in stone or could we use any pins in future releases to wake the device from a DEEP/STANDBY sleep?

6

Right now, all of our cellular SIMs are data-only, and do not process SMS natively. That being said, we have a lot of reference examples of handling SMS server-side with services like Twilio and Tropo.

https://docs.particle.io/reference/device-cloud/webhooks/#sending-sms-text-messages-

7

I know that one of the benefits of the nRF52840 (Gen 3 host controller) versus the STM32F205 (Gen 2 host controller) is that it is possible to configure additional pins as wakeup sources from STANDBY mode on Gen 3 devices, versus only WKP on the STM32.

8

2 posts were merged into an existing topic: Can Boron be used to recieve and send SMS?

9

Correct, however, STOP mode is not the same as STANDBY mode. Maybe I am misunderstanding this, I thought STANDBY was equivalent to SLEEP and STOP is DEEP SLEEP? The fact that the nRF52840 cannot maintain its RTC through STANDBY or STOP or both means an external RTC is a requirement if date/time is required on a sleepy end-node - please correct me if I am missing something.

10

You have that reversed.

pin, pin + time, or time = stop mode sleep. You can still wake up after a specific number of seconds in this mode on 3rd-generation devices.

SLEEP_MODE_DEEP and SLEEP_MODE_SOFTPOWEROFF = standby sleep mode. You cannot wake up from this mode based on time on the nRF52 platform as the clock doesn’t run in this mode.

1 Like
11

Didn't say RTC doesn't work in STOP Mode.

12

OK- thanks for clarifying. Regards your recent tutorial on the Adafruit datalogger with RTC - you were referring to STANDBY sleep mode? Will the nRF58240 reset after a STANDBY wake like the STM32F205?

13

@rickkas7
I assume the Boron’s cellular handshake requirements are similar to the Electron.
So for the proposed v0.9.0 on Boron LTE:
If we want to avoid a Handshake for every wake event (a Session Restore), should we use SLEEP_NETWORK_STANDBY and an external timer to wake, for a project on a timed schedule ?

Or will Boron STOP modes perform a Session Restore if the sleep time is say, 5 minutes ?

14

Also I think I read a post on here that said the Boron LTE units require a Handshake every 5 mins vs the 23 mins on the non LTE Electrons?

Is that true about the Borons requiring a ping every 5 mins to avoid needing a full new Handshake session?

2 Likes
15

my experience when I was looking at detailed network logs is that the keep alive period is still 23 min with Boron LTE.

2 Likes
16

4 posts were split to a new topic: I2C not working with 0.8.0-rc.27?