dash7 webinar: working with open tag for mode 2

Copyright © DASH7 Alliance

OpenTag Mode 2 Webinar

JP Norair 12 January 2011

[email protected]

mailto:[email protected]



Webinar Agenda

‣Stuff you need to know

‣Stuff you probably want to know

‣Stuff you might not care about, that I’m going to tell you anyway


About the Author

• JP Norair

‣ [email protected]

‣ skype: jpnorair

• Chair of DASH7 Technology Working Group

• Chief architect of Mode 2 spec

• Leader of OpenTag project(Open source DASH7 firmware stack)

• Developer of products using DASH7 and related technologies

• Lover of all-night debug sessions




How You Can Help OpenTag

• Sponsor a port to your platform

‣ Helps fund general development

‣ Fast path to official platform support

‣ I will talk about your stuff all the time

• Join DASH7 Alliance and support Mode 2 (the spec that OpenTag implements)

• Write your own code, and submit it to the repository (I will make a branch for you)

• Get involved in the Beta Testing

• Send me energy drinks:2025 Broderick St. #08San Francisco, CA 94115

DASH7 Alliance Annual Meeting31 Jan - 2 Feb 2011: San Diego, CA

(Contact [email protected])

I will be presenting a 3 hour demo and developer seminar on OpenTag




Webinar Agenda




History & Timelines

Feature Overview

Architecture Overview

Getting OpenTag


Adding power makes you faster on the straights.Subtracting weight makes you faster everywhere.

– Colin Chapman, founder of Lotus Cars

OpenTag Design Philosophy


OpenTag Has Been Revised Many TimesDevelopment of OpenTag Mode 2 has been in parallel to the Mode 2 spec development itself

20082008 20092009 20102010 20112011

1st Half 2nd Half 1st Half 2nd Half 1st Half 2nd Half 1st Half 2nd Half

OpenTagMode 1 Betas

Early test versions

OpenTag Mode 1 Alphas

DASH7 Mode 2 Spec Drafted

Begin total rewrite of OpenTag for Mode 2

OpenTagMode 2 Betas

Mode 2 Spec FCD, OpenTag 1.x

OpenTag for Mode 1 was abandoned, in part due to lack of any Mode 1 SoC’s, but also because developing for Mode 1 is too painful to be practical.


DASH7 Mode 2 is a 2nd Generation WSN/IoT/RFID Technology

Mode 2

433 MHz band8 channels

Compact Stacktyp. 16KB

Optimized forMicro Power

Optimized forLow Latency(Bursty Data)

Universal Interoperability

Adaptive Data Rate28 - 200 kbps

Very FastMulticast


Near-Term Alpha and Beta Schedule

Nightly Alpha/Beta builds will be available on the sourceforge code repository

Alpha

Alpha

Beta 0

Beta 1

Beta 1

• Alpha Milestone: The core code works

• Beta 0 Milestone: A feature subset runs on HW

• Beta 1 Milestone: All 1.0 features run on HW

• Beta 2 Milestone: Passes regulatory testing and attains DASH7 compliance/certification

• 1.0: First Official Release


A Great Effort to Keep the Codebase Small & LightDesign elegance leads to reliability and low cost

Small Size Less Code Less to go wrong

Lower HW requirements Lower Cost

Comm Stack ROM/RAM KB

Open Source

Multihop Support

Multicast Queries

File-system

Crypto Security

IPv6 Scriptable Shellable Userspace Programmable

OpenTag DASH7 Mode 2 16 / 1 • optional • • • optional • • •

Contiki Proprietary 40 / 2 • • • • •

ZigBee ZigBee 115 / 4 • • •

ZigBee PRO ZigBee 136 / 4 • • •


OpenTag Can Run on Damn-Near Anything95%+ of Code is Platform-Agnostic ANSI C

OS Support Known Memory Support Known Core Support Known Transceivers [SoC]

“Bare Metal”(No OS)

Most RTOS’s

POSIX Shell(in simulation)

FLASH

SRAM

DRAM

EEPROM

MSP430 (Confirmed)

ARM (Confirmed)

x86 (Confirmed)

AVR (Likely)

CoolRISC (Likely)

CC11xx [CC430]

ADF7023 [ADµCRF101]

SX1212 [SX1282]

SX1231

Si442x [Si10xx]

8051 (Likely)FRAM


List of Main OpenTag FeaturesOr: “What you get for your hard-earned kilobyte”

Module Feature Availability Status Approx. KB*

APIC-based API Beta 0 Compile-time option 1

APISerial Console API-shell Beta 0 Compile-time option 0.1

MAC

Event-Based MAC Task Engine Beta 0 Mandatory 2

MACWake-on Radio Sequencing Beta 0 Runtime option 0.06

MACAutomatic Beacon Sequencing Beta 0 Runtime option 0.03

MAC

Real-Time Event Scheduling Beta 1 Compile/Runtime option 0.2

ProtocolBase Mode 2 Protocol Beta 0 Mandatory 2

ProtocolExtended Mode 2 Protocol(s) Beta 1 Compile-time option 2+

Radio Full Mode 2 PHY/MAC Support Beta 0 Mandatory 1

CRCStreaming CRC Engine Beta 0 Mandatory 0.1

CRCSW-based CRC Calculator Beta 0 Compile-time option 0.5**

Encoder

Streaming Codec Framework Beta 0 Mandatory 0.1

EncoderSW-based FEC Codec Beta 0 Compile-time option 1

EncoderSW-based PN9 Codec Beta 0 Compile-time option 0.1**

Encoder

HW-based Codec pass through Beta 0 Compile-time option 0.1

Veelite

POSIX-like Virtual Filesystem Beta 0 Mandatory 1

VeeliteFLASH Wear Leveling Beta 0/1 Compile-time option 2

VeeliteData Storage Encryption Beta 1 Runtime option 0.05

Veelite

File Heap Beta 0 Compile-time option 4+†

Total: 16.8 KB*Compiled on CC430 with mixed speed/size optimization **Not required for CC430 build †User file storage allocation


How to Download Nightly OpenTag BuildsIf you are a developer, you probably already know this routine

1.Go to the OpenTag sourceforge pagehttp://sourceforge.net/projects/opentag

2.Browse Code repository

1.Download any Git client“git” is the original (POSIX command line)

2.Go to (or create) an empty directory

3.Clone my repository to your directory. For classic git, see below.$ git clone git://opentag.git.sourceforge.net/gitroot/opentag/OpenTag_M2

http://sourceforge.net/projects/opentag

— OR —






Webinar Agenda




The world’s easiest tag code

Exploring the API

Configuring the Build


The World’s Easiest Tag Code

• Yes: this is simplified pseudocode, but the concept is accurate and even workable for simple “Tag” devices.

• One extra layer of complexity is to determine the longest runtime of my_program():

‣ Let’s say it is 5 ms

‣ Add a condition to skip my_program() if ot_run() returns 5 ms or less

• If you use an RTOS with a “system tick” period of 5 ms, then integration with the RTOS follows the same idea.

• As we will see later, my_program()can actually feed information back to OpenTag in a variety of ways.


UserData

(optional)

UserProgram(optional)

MAC Control

Protocol Layer

Veelite:(Virtual EEPROM Lite)

POSIX-like filesystem for Mode 2 Data.

OpenTag API: Shock & AweOpenTag is like a shell and possibly an OS, too.

LLDP:(Low Level Directive

Protocol)

Short messaging directives that can be used in combination

to do large tasks

ScriptEngine

(optional)

C API

Message Pipe

OpenTag can be controlled directly, with C, or indirectly, over a message pipe. Any kind of data interface will do (often it is a serial wire).


UserData

(optional)

UserProgram(optional)

MAC Control

Protocol Layer

Veelite:(Virtual EEPROM Lite)

POSIX-like filesystem for Mode 2 Data.

OpenTag API: Shock & AweRunning stored programs is the same as running API directives

LLDP:(Low Level Directive

Protocol)

Short messaging directives that can be used in combination

to do large tasks

ScriptEngine

(optional)

C API

Message Pipe

This is the feedback loop that allows users to script and store custom routines. This can be dangerous! By default it is disabled. On the plus side, it allows for users to load complex “stored procedures” or other sorts of programs, such as a PPP daemon.

Programs are stored in Veelite, they run in userspace, and they require authentication to run. They cannot affect data that is not accessible to the user (i.e. root-only data)


OpenTag API: A Practical PerspectiveWriting Data to a Mode 2 Data Element via the Messaging API (LLDP)

• Does this make any sense to you?(Probably not)

• This code changes the value of the Mode 2 Sleep Scan Sequence UDB, which in turn changes the way the device monitors channels for activity.

• The otapi_set...() and get functions are accessing a message pipe.

• This kind of code would generally never run on a tiny embedded device. It is meant to run on the thing that is connected to your tiny device.

‣ If you are a developer, this means the PC that is connected to your dev kit with a wire.

‣ If you are a system integrator, this means the piece of edgeware that is driving your stuff.


OpenTag API: A Practical PerspectiveWriting Data to a Mode 2 Data Element via the C API

• Does this make any sense to you?(It probably does, if you’ve seen stdio.h)

• This code does the same job as the last code

• The UDB_open_su() opens the UDB as the root user, which guarantees write access.

• This kind of code is used all over the place inside OpenTag. You could use it in my_program() just as easily.

‣ The UDB contains all sorts of configuration registers that control OpenTag behavior.

‣ The UDB contains data elements, like location lists and sensor data lists.

Still confused? Don’t worry too much: It won’t be long before there are

libraries of cookbook-type OpenTag functions on SourceForge.


Configuring a Build The secret to OpenTag’s portability

• You don’t need to understand this code, it is just an example of Compile-Time options

• Without touching any of the code (apart from the config headers), you can dramatically change the scope of features available to your build of OpenTag. It is even address size and endian agnostic at the C code level.

This is an OpenTag Feature. It only compiles if you want

to use streaming CRC

This is a Platform Feature. It only compiles if your HW cannot encode PN9 per the

Mode 2 Spec


Configuring a Build Configuration File Examples (CC430 in this example)

/OTlib/OT_config.h /Platforms/CC430/platform_config_CC430.h

Software Features for Any Platform Features (or Limitations) of the Hardware

Some of these lists go on for hundreds of lines and allow deep-drilling optimization


Wakeup! (The code example part is over)


Webinar Agenda




Porting OpenTag to New HW

Running in Simulation

Pending Releases


Porting OpenTag to New HWStuff you don’t really need to touch

• The OTlib directory is all ANSI C, and has hooks that allow it to be as close to 100% platform agnostic as a C program can be.

• You will need to add your Platform Name to platform_support.h (pretty easy)

• You will need to add your Platform header to platform_config.h (pretty easy)


Porting OpenTag to New HWStuff you need to create

• You WILL need to write some drivers and headers for anything that interacts directly with the platform.

• Create a new directory in /Platforms/

• A lot of platforms are similar. Most of the time I am able to copy the files from one port to another, and modify them only slightly.


Using the Simulator

• Since the code is portable and doesn’t hook into hardware at the library level, it is pretty easy to test compared to the traditional embedded build-load-debug cycle.

• I have written a handful of test programs- as simple as make & run

• On a modern PC I can go take a nap, and when I come back, 100 billion test vectors have run.

‣ This is orders of magnitude more transactions than all WSN & active RFID devices have been put through, combined, to date.

I use a pleasant sea anemone motif for my shell


What Each Release Entails

Alpha Beta 0 Beta 1 Beta 2

Beta 0 OTlib featureset tested to exhaustion via

Simulator

Get Platform layer to run just once on CC430

Platform layer tested thoroughly on CC430

Port to ADµCRF101

Beta 0/1 OTlib featureset tested to exhaustion via

Simulator, and HW

Full-scale interoperability tests between CC430 and

ADµCRF101

Regulatory Testing

Work with DASH7 Alliance to define Mode 2

Certification process

By most accounts, Beta 2 will be a deployable version.

Changes between Beta 2 and v1.0 should just be configuration settings.


When this is all over, I will treat myself to some fine wine.


Questions & Comments

dash7 webinar: working with open tag for mode 2

Technology

support mode

kbcopyright dash7 alliance

likelycopyright dash7

anywaycopyright dash7

hwcopyright dash7 alliance

ca join dash7 alliance

betasopentag mode

radiofull mode