Announcing: Radius Wearables Core

Archive
1

Justin and I would like to take the lid off some ongoing work - the Radius Wearables Core and Radius Reference Hardware. This work is still in its early days and will continue to evolve, but here’s an early peek…

The Radius Wearables Core (RWC) is a .Net Micro Framework codebase and accompanying Windows, Windows Phone, Android and iOS companion apps, all written in managed code. The idea behind the RWC is to create an integrated software framework for connected wearables - watches, pendants, and all manner of headless devices too.

The RWC software is free and open-source for non-commercial uses. Commercial use requires a separate license. Distribution of the mobile phone companion apps through app stores involves a separate approval process through Microsoft, Apple and/or Google, though it is intended that the default app (which we will publish) will accomodate custom wearable devices you might create. The RWC software is tested on the Radius, Molecule, IoT Dx Blue, and GHI hardware.

The Radius Watch reference hardware v1, includes:
[ul]STM32F401 - 82Mhz 512kb Flash 96kb ram or STM32F411 - 96Mhz 512kb Flash 128kb ram
1.26inch Sunlight readable Sharp MemoryLCD
BLE113 Bluetooth LE with separate vreg
MPU-9150 9 DOF sensor
MPR121 Capacitive touch sensor
Battery backed up RTC
8mb External SPI flash
Buzzer
Lipo power with charge circuit
3 User buttons
Power on/off push button[/ul]

The Radius Wearables Core software features include :
[ul]Mobile-phone companion apps for all major mobile platforms
Installable Radius apps (requires filesystem - apps are managed from your PC or mobile device)
Notification routing and display
Radius app sandboxing and resource-management
Structured messaging over any serial channel (e.g., BLE on the Radius Reference Hardware)
Support for private host-app-to-Radius-app messaging (create your own app protocols)
Support for mobile device control (call management, media controls, volume, messaging, etc.)
Support for headless devices (annunciators and sensors)
Support for multiple Radius-compatible devices attached to a single host (mobile device or PC)
A touch or button driven navigation framework[/ul]

And on the Radius Hardware, includes default apps for:
App Menu, Watch, Notifications and a touch-gesture navigation framework

The source code is available at : GitHub - MoleculeDotNet/Radius: Radius Wearables Core

Demo video is upcoming…

15 Likes
2

Very Cool!

Want one!

:clap: :clap: :clap:

3

Awesome !

4

@ mcalsyn - So it sounds like the apps could be used to set the wifi code on my customer’s wifi gateway module correct? Shipping Ethernet version of a gateway is easy, the hard part is shipping a wifi version due to the need for them to join the network.

5

Actually, I think you are conflating two projects : Radius and the Molarity onboarding service.

The Molarity onboarding service (which has not been released yet) will handle no-touch onboarding of devices in a wifi network.

The Radius Wearables Core (RWC) is all about creating a common .Net Micro Framework software stack for wearable devices, designed to work with existing popular mobile devices. Using the RWC stack means that you can concentrate on designing your wearable’s look and its behaviors, while the app management, app delivery, messaging, and the host apps are all done for you already (although you can create additional peer apps for the host device).

In fact, the idea (still not realized in the code) is that if you create a new Radius-compatible hardware device, then NETMF apps created for existing Radius devices should run on your device (depending on their resource requirements relative to your new hardware). We need to finish a contracting and capabilities framework before that becomes real. But when it does, you should be able to start up with a ready-made store of apps for your new hardware device. Designers are freed to be designers - we give them a leg up on the gnarly plumbing and app-management spaces. And we lubricate the app development process by using powerful and efficient .Net tooling.

One key design point is that messages will be sent to a ‘contract’ endpoint. That contract may be exposed on multiple Radius devices and each device will handle the message sent to that contract according to it’s own design (a smartwatch might display a message, a bracelet might change colors, etc). But the sending app on your phone does not need to know about your Radius device before-hand because they all obey well-known contract definitions. This aligns well with AllJoyn, and in fact, should be able to bridge to AllJoyn.

So Radius (wearables) and Molarity (home/office/auto automation services) is the party, and the Molarity Onboarding Service is how wifi devices join the party. This announcement was about Radius.

6

ah - and @ terrance - one more point. Whether it be AllJoyn or Molarity or whatever, you need an established beachhead in your wifi network. Sometime in the future, that beachhead will probably be the AllJoyn onboarding service built-in and running in every wifi router. Until then, you have to deploy at least one distinguished device - a beachhead device - that is either ethernet attached on one side, or which has been manually joined to the wifi network. There’s no way around that.

7

“Beam me up, Scottie!”

8

Nobody ever said you could only have one beachhead device. :whistle: (My fiber modem and home wifi are single-point-of-failure too, but you scale your countermeasures to the needs. Not all single point of failure architectures are ‘bad’. I don’t know too many people with dual pathways to their ISP PoP)