Branch
master
develop

pirouette is an R package that estimates the error BEAST2 makes from a given phylogeny. This phylogeny can be created using any (non-BEAST) speciation model, for example the Protracted Birth-Death or Multiple-Birth-Death models.

• Installation.
• Examples
• Interpretation.
• Academic article

• nsm: Nucleotide Substitution Model
• tral: TRue ALignment
• twal: TWin ALignment

See the FAQ.

See CONTRIBUTING, at Submitting use cases

See CONTRIBUTING, at ‘Submitting code’

See CONTRIBUTING, at ‘Submitting bugs’

Sure, just add an Issue. Or send an email.

Package
beautier
beastier
mauricer
mcbette
tracerer

Package
beautier
beastier
mauricer
mcbette
tracerer

Package	Status
babette_on_windows
beastier_on_windows
beautier_on_windows
mauricer_on_windows
tracerer_on_windows

• BEAST2 GitHub

• Bilderbeek, RJC, Laudanno, G, Etienne, RS. Quantifying the impact of an inference model in Bayesian phylogenetics. Methods Ecol Evol. 2020; 00: 1– 8. https://doi.org/10.1111/2041-210X.13514

AppointDent is a full-stack web application that allows residents of Sweden manage their dentist appointments, as well as a tool for dentists to organize their work. The system, internally, relies on a distributed system infrastructure that combines various architectural styles, namely microservices, publish-subscribe and client-server.

Table of Contents

• Introduction
• Tech-stack
• Pre-Requirements
  • Installation, Setup, and Running
• Architecture
• System’s Overview
• Continuous Integration
• Development team

AppointDent is a system that allows residents of Sweden to book dentist appointments. A user can find available times and see the dentist on an integrated map.

AppointDent allows users to book appointments, cancel them, as well as receive notifications about their bookings. The dentists in our system make use of a calendar to navigate their appointments and manage their availability.

The solution is based on a distributed system infrastructure that combines various architectural styles, namely microservices, publish-subscribe and client-server.

• TypeScript (client, server, services)
• Node.js (client, server, services)
• Vite.js (client)
• Express.js (server, services)
• Solid.js (client)
• Sqlite3 (node wrapper: better-sqlite3) [services]
• Tailwind CSS (client)

The only technology that is utilized in building and running all services, APIGateway (server), the client, and stress-testing is Node.js. Our project makes use of version 18.x.x. Ensure that you have a compatible version installed on your machine (we recommend 18.12.2). Read more about Node.js (and npm) here.

For the Solid.js framework, we recommend using npm as the package manager and installing the version from the package.json file with Vite.js as the build tool. Alternatively, install ^1.7.8 version of Solid.js (+^4.4.5 of Vite.js) with the help of your preferred package manager/environment utility.

In terms of stress-testing the system, we recommend using the latest version of k6. Navigate to stress-testing for more information.

This repository utilizes a monorepo structure, where the individual sub-folders represent a particular component of the system, wherein each component has its own README.md file.

The file contains the instructions on how to install all dependencies, it explains the structure of the directory, and it lists all the available scripts (with possible clarifications).

The following is a list of the available sub-folders:

• client: the client-side application.
• server: the server-side application (informally, the APIGateway/Proxy).
• services/admin-service: the additional service that adds an abstraction of an admin to observe the system’s state and trends.
• services/appointment-service: the service that handles all the appointment-related operations.
• services/dentist-service: the service that handles all the dentist-related operations.
• services/notification-service: the service that enables the system to send notifications to the users upon certain events.
• services/patient-service: the service that handles all the patient-related operations.
• services/session-service: a central service that handles all sessions of the users to enforce authentication and authorization.
• stress-testing: a folder that contains the scripts that are used to stress-test the system at a high load.

Our system is a distributed one and we have therefore decided to use a Microservices-based architecture. This means that different services are to be installed on different computers and are completely independent. The MQTT (Message Queue Telemetry Transport) protocol is implemented as the primary communication utility between the individual services of our system. See our Component Diagram for a detailed overview of the architecture in use.

Furthermore, several other decisions that have a substantial impact on the architecture that the team members dealt with during the project’s development may be traced with the ADRs.

The following section aims to provide an overview of the system’s architecture, as well as the deployment strategy. The individual diagrams can observed when clicking on the dropdowns.

The development team made use of the continuous integration (CI) testing practice to improve the development process model (which was Scrum) that was used in the development of the system. This allowed the team to continuously build and test the code in order to prevent pushing defective code into the main branch. The team made use of Postman as means of integration testing of the back-end and the database of the system. Moreover, the team made use of static analysis (ESLint) to make sure good quality and readable code with no syntax bug is pushed into the main branch. In order to make use of CI, the team made use of GitLab’s CI/CD feature. The gitlab-ci.yml file contains the instructions that are used by GitLab to run Postman tests, statically analyze code, and build the system.

The project has been developed over the course of 10 weeks by the following:

AppointDent is a full-stack web application that allows residents of Sweden manage their dentist appointments, as well as a tool for dentists to organize their work. The system, internally, relies on a distributed system infrastructure that combines various architectural styles, namely microservices, publish-subscribe and client-server.

Table of Contents

• Introduction
• Tech-stack
• Pre-Requirements
  • Installation, Setup, and Running
• Architecture
• System’s Overview
• Continuous Integration
• Development team

AppointDent is a system that allows residents of Sweden to book dentist appointments. A user can find available times and see the dentist on an integrated map.

AppointDent allows users to book appointments, cancel them, as well as receive notifications about their bookings. The dentists in our system make use of a calendar to navigate their appointments and manage their availability.

The solution is based on a distributed system infrastructure that combines various architectural styles, namely microservices, publish-subscribe and client-server.

• TypeScript (client, server, services)
• Node.js (client, server, services)
• Vite.js (client)
• Express.js (server, services)
• Solid.js (client)
• Sqlite3 (node wrapper: better-sqlite3) [services]
• Tailwind CSS (client)

The only technology that is utilized in building and running all services, APIGateway (server), the client, and stress-testing is Node.js. Our project makes use of version 18.x.x. Ensure that you have a compatible version installed on your machine (we recommend 18.12.2). Read more about Node.js (and npm) here.

For the Solid.js framework, we recommend using npm as the package manager and installing the version from the package.json file with Vite.js as the build tool. Alternatively, install ^1.7.8 version of Solid.js (+^4.4.5 of Vite.js) with the help of your preferred package manager/environment utility.

In terms of stress-testing the system, we recommend using the latest version of k6. Navigate to stress-testing for more information.

This repository utilizes a monorepo structure, where the individual sub-folders represent a particular component of the system, wherein each component has its own README.md file.

The file contains the instructions on how to install all dependencies, it explains the structure of the directory, and it lists all the available scripts (with possible clarifications).

The following is a list of the available sub-folders:

• client: the client-side application.
• server: the server-side application (informally, the APIGateway/Proxy).
• services/admin-service: the additional service that adds an abstraction of an admin to observe the system’s state and trends.
• services/appointment-service: the service that handles all the appointment-related operations.
• services/dentist-service: the service that handles all the dentist-related operations.
• services/notification-service: the service that enables the system to send notifications to the users upon certain events.
• services/patient-service: the service that handles all the patient-related operations.
• services/session-service: a central service that handles all sessions of the users to enforce authentication and authorization.
• stress-testing: a folder that contains the scripts that are used to stress-test the system at a high load.

Our system is a distributed one and we have therefore decided to use a Microservices-based architecture. This means that different services are to be installed on different computers and are completely independent. The MQTT (Message Queue Telemetry Transport) protocol is implemented as the primary communication utility between the individual services of our system. See our Component Diagram for a detailed overview of the architecture in use.

Furthermore, several other decisions that have a substantial impact on the architecture that the team members dealt with during the project’s development may be traced with the ADRs.

The following section aims to provide an overview of the system’s architecture, as well as the deployment strategy. The individual diagrams can observed when clicking on the dropdowns.

The development team made use of the continuous integration (CI) testing practice to improve the development process model (which was Scrum) that was used in the development of the system. This allowed the team to continuously build and test the code in order to prevent pushing defective code into the main branch. The team made use of Postman as means of integration testing of the back-end and the database of the system. Moreover, the team made use of static analysis (ESLint) to make sure good quality and readable code with no syntax bug is pushed into the main branch. In order to make use of CI, the team made use of GitLab’s CI/CD feature. The gitlab-ci.yml file contains the instructions that are used by GitLab to run Postman tests, statically analyze code, and build the system.

The project has been developed over the course of 10 weeks by the following:

This is a simple script that will erase users, their media, and redact all their events from a Synapse server based on specific criteria:

• not an admin
• not a guest
• not deactivated
• not contain a specific string in their MXID
• not older than a specific threshold in days

It was developed for the etke.cc demo server for the purpose of cleaning up the user database.

Another purpose of this repo is to be a test stand for migrating our gitlab repos to github

Don’t expect this to be a full-featured tool, it’s just a simple script that does one thing.

Configuration is done via environment variables (.env file is supported as well). The following variables are supported:

• SUAE_HOST – Synapse server host, e.g. https://matrix.example.com (without trailing slash)
• SUAE_TOKEN – Synapse homeserver admin token
• SUAE_PREFIXES – Space-separated list of additional MXID prefixes that should be excluded from deletion
• SUAE_TTL – Maximum age of the user in days, users younger than this value will not be deleted
• SUAE_DRYRUN – If set to true, the script will only print the list of users that would be deleted. You WANT to run it in dry-run mode first to make sure you’re not deleting the wrong users.

Check .env.example for an example configuration.

# if you want to run it with docker, do this
$ docker run --rm --env-file .env ghcr.io/etkecc/synapse-user-autoerase
# if you have binary, run it like this
$ synapse-user-auto-erase
# if you want to run from source
$ just run

⚠️ NOTE: This is a fairly new project. Functionally everything is working on tested Nerves systems.

NervesFlutterSupport is the base library for running Flutter based UI applications on Nerves devices.

NervesFlutterSupport contains the following components:

• Pre-compiled and patched runtime libraries for various dependencies. (See builder/ for more info.)
  • Including a pre-compiled version of Sony’s open source Flutter Embedder.
• A pair of Mix Release Steps that can be included in your existing Mix project.
  • Takes care of downloading the Flutter embedder and runtime libraries.
  • Will automatically compile your Flutter project using the gen_snapshot tool and output an AOT build.
  • Will help copy the runtime artifacts from the dependency source directory to the release directory at compile time.
• NervesFlutterSupport.Flutter.Engine – A module to create a Muontrap child_spec for running the embedder.
• NervesFlutterSupport.Udev – (Automatically started for you) A module that ensure eudevd is running for input devices to function properly.

NervesFlutterSupport has been tested on the following platforms:

• Raspberry Pi 4
• Raspberry Pi 5

However it should be noted that any aarch64 based Nerves System should be compatible with this library.

Please file any issues if you run into any problems with your ARM64 platform. We also welcome Buildroot config contributions for other platforms.

Currently we only support Linux and macOS hosts when building firmware. Windows users should use WSL.

If you are a macOS user, please ensure you have docker installed!

1. Install Flutter. See the top of this readme file for which version to use. (Flutter versions may change with Hex package versions!)
2. Create a new Flutter app in your Mix project using: flutter create flutter_app.
3. Add this package to your deps in mix.exs.
4. Add the release steps to your existing firmware’s steps::

  steps: [
    &Nerves.Release.init/1,
    &NervesFlutterSupport.InstallRuntime.run/1, # REQUIRED!! - Add this to install runtime artifacts into the release!
    &NervesFlutterSupport.BuildFlutterApp.run/1, # OPTIONAL - Add this if you want to auto-compile a flutter app!
    :assemble
  ],

5. Run mix firmware as you normally would, if all is well, you should see you Flutter app build and emit a bundle into your priv/ directory.
6. To run the Flutter app you can add the following to your Application or Supervisor children:

# With no options, your Flutter app bundle is expreted to be in `priv/flutter_app`
NervesFlutterSupport.Flutter.Engine.create_child(
  app_name: :my_flutter_app,
)

Example Project: NervesFlutterExample

NervesFlutterExample is a basic Flutter + Nerves firmware for :rpi4 and :rpi5 targets. It uses gRPC and Protobufs to communicate between the Nerves firmware code and the Dart Flutter application.

This project describes the process of connecting a bank account to your own Account. So when you log in you are taken to the choose a bank account, then as one bank is chosen you are asked to finish adding login data to complete login in. As the form is send you are send to a page where your latest bank transactions data is displayed.

Execute npm install to install dependencies

Execute npm run dev to run the development server on localhost:8080

or

Execute npm run prod to run the production server. For testing use localhost:4000

1. CSS Approach: I have changed boilerplate to add post-css and css-modules. Also, added redux-devtools to be able to work with redux data in a development setting. See wiki pages CSS-Methodology

2. Implement a bank selection that persists the login screen: Bank selection is done by saving the user selected bank to the redux store. To paint the buttons: We map through an inline array calling a BankListItem component to render on each iterate, passing th eprops necesary for each button. BankListItem resides on the components folder and it just renders the bank images as buttons. Each button will have an onClick handler triggering the action to save the bank name to the redux store when triggered. Special carefulness have been made into no binding but instead using arrow functions when declaring handlers within react classes. See BankListItem while the ChooseBankPage container is here.

3. Implement sensible form validation: I have implemented a HOC that wraps the form component and that deals with form state and actions present in the form. Additionally I have detached actual validations from the form state so the user only needs to define the validation rules and pass them onto the validation’s HOC as a config object. So these are not hard-coded into the HOC. See more on the wiki pages Form-Validation

The container component is LoginPage.js and the HOC is called Revalidation.js, both are found here and the login form is here.

4. Build the transactions screen using the api end-point localhost:3000/api/transactions: First, a server have been implemented to serve json from the data folder, enabling CORS to handle calls to localhost. I this sense I use the concurrently library to run both the development server and the API at the same time, with just one script. See scripts on the package.json file here and the dev API server here

Then, creating the views is just a mater of rendering the actual components defined on the components/statements folder. In more detail, the statementPage container renders AccDetails and ListView components, also declares and passes down to ListView the renderRow markup. Detaching the renderRow from the ListView permits us to reuse the ListView in any other part of the app. From there on, ListView maps through the passed props (renderRow) which calls and pains a row for each iterate of the map function.

See StatementPage here
ListView and ListRow are here

Another thing is that I am using selectors for the first time in this app to prepare and digest data before passing it to the rendering component. See getTransactions selector in the reducers/bank reducer file. What the getTransactions selector does is prepare and return an array of transactions by id and the actual collection of transactions. Later on, the ListView component will iterate through the array of ids, taking from the collection the current transaction and rendering the row with the data.
Selectors in the reducers/bank code is here

5. Fix and expand the unit tests: I am testing presentational components by creating snapshops. Also, testing event handlers and state where appropriate. On unit tests, there are behavioral tests for actions and reducers. See wiki pages Tests for more on this.

6. Login and authentication: I have used a HOC component that wraps the private routes and confirms the loggedIn state of user.
   See wiki pages Login-and-Authentication

1. Fork it!
2. Create your feature branch: git checkout -b my-new-feature
3. Commit your changes: git commit -am 'Add some feature'
4. Push to the branch: git push origin my-new-feature
5. Submit a pull request 😀

TODO: Write history

TODO: Write credits

TODO: Write license

In this project, you will use what you’ve learned about deep neural networks and convolutional neural networks to classify traffic signs. You will train a model so it can decode traffic signs from natural images by using the German Traffic Sign Dataset. After the model is trained, you will then test your model program on new images of traffic signs you find on the web, or, if you’re feeling adventurous pictures of traffic signs you find locally!

This project requires Python 3.5 and the following Python libraries installed:

• Jupyter
• NumPy
• SciPy
• scikit-learn
• TensorFlow
• Matplotlib
• Pandas (Optional)

Run this command at the terminal prompt to install OpenCV. Useful for image processing:

• conda install -c https://conda.anaconda.org/menpo opencv3

1. Download the dataset. This is a pickled dataset in which we’ve already resized the images to 32×32.
2. Clone the project and start the notebook.

git clone https://github.com/udacity/CarND-Traffic-Signs
cd CarND-Traffic-Signs
jupyter notebook Traffic_Signs_Recognition.ipynb

3. Follow the instructions in the Traffic_Signs_Recognition.ipynb notebook.

Original : [Tensorflow version]

Pytorch implementation of various GANs.

This repository was re-implemented with reference to tensorflow-generative-model-collections by Hwalsuk Lee

I tried to implement this repository as much as possible with tensorflow-generative-model-collections, But some models are a little different.

This repository is included code for CPU mode Pytorch, but i did not test. I tested only in GPU mode Pytorch.

• MNIST
• Fashion-MNIST
• CIFAR10
• SVHN
• STL10
• LSUN-bed

Name	Paper Link	Value Function
GAN	Arxiv
LSGAN	Arxiv
WGAN	Arxiv
WGAN_GP	Arxiv
DRAGAN	Arxiv
CGAN	Arxiv
infoGAN	Arxiv
ACGAN	Arxiv
EBGAN	Arxiv
BEGAN	Arxiv

Network architecture of generator and discriminator is the exaclty sames as in infoGAN paper.
For fair comparison of core ideas in all gan variants, all implementations for network architecture are kept same except EBGAN and BEGAN. Small modification is made for EBGAN/BEGAN, since those adopt auto-encoder strucutre for discriminator. But I tried to keep the capacity of discirminator.

The following results can be reproduced with command:

python main.py --dataset mnist --gan_type <TYPE> --epoch 50 --batch_size 64

All results are generated from the fixed noise vector.

Name	Epoch 1	Epoch 25	Epoch 50	GIF
GAN
LSGAN
WGAN
WGAN_GP
DRAGAN
EBGAN
BEGAN

Each row has the same noise vector and each column has the same label condition.

Name	Epoch 1	Epoch 25	Epoch 50	GIF
CGAN
ACGAN
infoGAN

All results have the same noise vector and label condition, but have different continous vector.

Name	Epoch 1	Epoch 25	Epoch 50	GIF
infoGAN

Name	Loss
GAN
LSGAN
WGAN
WGAN_GP
DRAGAN
EBGAN
BEGAN
CGAN
ACGAN
infoGAN

Comments on network architecture in mnist are also applied to here.
Fashion-mnist is a recently proposed dataset consisting of a training set of 60,000 examples and a test set of 10,000 examples. Each example is a 28×28 grayscale image, associated with a label from 10 classes. (T-shirt/top, Trouser, Pullover, Dress, Coat, Sandal, Shirt, Sneaker, Bag, Ankle boot)

The following results can be reproduced with command:

python main.py --dataset fashion-mnist --gan_type <TYPE> --epoch 50 --batch_size 64

All results are generated from the fixed noise vector.

Name	Epoch 1	Epoch 25	Epoch 50	GIF
GAN
LSGAN
WGAN
WGAN_GP
DRAGAN
EBGAN
BEGAN

Each row has the same noise vector and each column has the same label condition.

Name	Epoch 1	Epoch 25	Epoch 50	GIF
CGAN
ACGAN
infoGAN

• ACGAN tends to fall into mode-collapse in tensorflow-generative-model-collections, but Pytorch ACGAN does not fall into mode-collapse.

All results have the same noise vector and label condition, but have different continous vector.

Name	Epoch 1	Epoch 25	Epoch 50	GIF
infoGAN

Name	Loss
GAN
LSGAN
WGAN
WGAN_GP
DRAGAN
EBGAN
BEGAN
CGAN
ACGAN
infoGAN

The following shows basic folder structure.

├── main.py # gateway
├── data
│   ├── mnist # mnist data (not included in this repo)
│   ├── ...
│   ├── ...
│   └── fashion-mnist # fashion-mnist data (not included in this repo)
│
├── GAN.py # vainilla GAN
├── utils.py # utils
├── dataloader.py # dataloader
├── models # model files to be saved here
└── results # generation results to be saved here

• Ubuntu 16.04 LTS
• NVIDIA GTX 1080 ti
• cuda 9.0
• Python 3.5.2
• pytorch 0.4.0
• torchvision 0.2.1
• numpy 1.14.3
• matplotlib 2.2.2
• imageio 2.3.0
• scipy 1.1.0

This implementation has been based on tensorflow-generative-model-collections and tested with Pytorch 0.4.0 on Ubuntu 16.04 using GPU.

Original : [Tensorflow version]

Pytorch implementation of various GANs.

This repository was re-implemented with reference to tensorflow-generative-model-collections by Hwalsuk Lee

I tried to implement this repository as much as possible with tensorflow-generative-model-collections, But some models are a little different.

This repository is included code for CPU mode Pytorch, but i did not test. I tested only in GPU mode Pytorch.

• MNIST
• Fashion-MNIST
• CIFAR10
• SVHN
• STL10
• LSUN-bed

Name	Paper Link	Value Function
GAN	Arxiv
LSGAN	Arxiv
WGAN	Arxiv
WGAN_GP	Arxiv
DRAGAN	Arxiv
CGAN	Arxiv
infoGAN	Arxiv
ACGAN	Arxiv
EBGAN	Arxiv
BEGAN	Arxiv

Network architecture of generator and discriminator is the exaclty sames as in infoGAN paper.
For fair comparison of core ideas in all gan variants, all implementations for network architecture are kept same except EBGAN and BEGAN. Small modification is made for EBGAN/BEGAN, since those adopt auto-encoder strucutre for discriminator. But I tried to keep the capacity of discirminator.

The following results can be reproduced with command:

python main.py --dataset mnist --gan_type <TYPE> --epoch 50 --batch_size 64

All results are generated from the fixed noise vector.

Name	Epoch 1	Epoch 25	Epoch 50	GIF
GAN
LSGAN
WGAN
WGAN_GP
DRAGAN
EBGAN
BEGAN

Each row has the same noise vector and each column has the same label condition.

Name	Epoch 1	Epoch 25	Epoch 50	GIF
CGAN
ACGAN
infoGAN

All results have the same noise vector and label condition, but have different continous vector.

Name	Epoch 1	Epoch 25	Epoch 50	GIF
infoGAN

Name	Loss
GAN
LSGAN
WGAN
WGAN_GP
DRAGAN
EBGAN
BEGAN
CGAN
ACGAN
infoGAN

Comments on network architecture in mnist are also applied to here.
Fashion-mnist is a recently proposed dataset consisting of a training set of 60,000 examples and a test set of 10,000 examples. Each example is a 28×28 grayscale image, associated with a label from 10 classes. (T-shirt/top, Trouser, Pullover, Dress, Coat, Sandal, Shirt, Sneaker, Bag, Ankle boot)

The following results can be reproduced with command:

python main.py --dataset fashion-mnist --gan_type <TYPE> --epoch 50 --batch_size 64

All results are generated from the fixed noise vector.

Name	Epoch 1	Epoch 25	Epoch 50	GIF
GAN
LSGAN
WGAN
WGAN_GP
DRAGAN
EBGAN
BEGAN

Each row has the same noise vector and each column has the same label condition.

Name	Epoch 1	Epoch 25	Epoch 50	GIF
CGAN
ACGAN
infoGAN

• ACGAN tends to fall into mode-collapse in tensorflow-generative-model-collections, but Pytorch ACGAN does not fall into mode-collapse.

All results have the same noise vector and label condition, but have different continous vector.

Name	Epoch 1	Epoch 25	Epoch 50	GIF
infoGAN

Name	Loss
GAN
LSGAN
WGAN
WGAN_GP
DRAGAN
EBGAN
BEGAN
CGAN
ACGAN
infoGAN

The following shows basic folder structure.

├── main.py # gateway
├── data
│   ├── mnist # mnist data (not included in this repo)
│   ├── ...
│   ├── ...
│   └── fashion-mnist # fashion-mnist data (not included in this repo)
│
├── GAN.py # vainilla GAN
├── utils.py # utils
├── dataloader.py # dataloader
├── models # model files to be saved here
└── results # generation results to be saved here

• Ubuntu 16.04 LTS
• NVIDIA GTX 1080 ti
• cuda 9.0
• Python 3.5.2
• pytorch 0.4.0
• torchvision 0.2.1
• numpy 1.14.3
• matplotlib 2.2.2
• imageio 2.3.0
• scipy 1.1.0

This implementation has been based on tensorflow-generative-model-collections and tested with Pytorch 0.4.0 on Ubuntu 16.04 using GPU.

This library provides a simple-to-use framework for taking advantage of many of the features of the MCCI Catena® Arduino products.

Apologies: This document is a work in progress, and is published in this intermediate form in hopes that it will still be better than nothing.

• Overview
• Coding Practices
• Components
  • Namespace McciCatena
  • Class Catena and header file Catena.h
  • Board-specific Classes
  • Class derivation
    • STM32 Classes
    • SAMD Classes
  • Platform Management
    • Platform GUIDs
    • GUIDs for the Catena 461x family
      • Catena 4610
      • Catena 4611
      • Catena 4612
      • Catena 4617
      • Catena 4618
      • Catena 4630
    • GUIDs for the Catena 4450/4460/4470 family
      • Catena 4450
      • Catena 4460
      • Catena 4470
    • GUIDs for the Catena 480x family
      • Catena 4801
      • Catena 4802
    • GUIDs for Adafruit Feather M0s
  • Polling Framework
    • Making a class pollable
    • Using pollable objects in sketches
  • Finite State Machine (FSM) Framework
    • Getting ready
    • Defining the state enum class
    • Identify the parent class
    • Add the state type to the parent class
    • Define the FSM instance in the parent class
    • Declare a method function in the parent class
    • Implement the FSM dispatch function
    • Implement the FSM initialization
  • The general time/date class McciCatena::cDate
    • Interval Seconds
    • cDate calendar types
    • cDate properties
    • cDate methods
    • Timekeeping, solar days, leap seconds
  • LoRaWAN Support
    • Sending an uplink message
    • Registering to receive downlink messages
    • LoRaWAN Class Structure
  • FRAM Storage Management
    • FRAM Storage Formats
      • Object Storage Structure
      • Bit layout of uSizeKey
      • The FRAM header object
    • Adding FRAM objects
    • Class hierarchy within the FRAM library
  • Asynchronous Serial Port Command Processing
    • Collecting lines asynchronously from streams
    • The command parser
    • Command stream methods for use by functions
    • Synchronous Command Functions
    • Asynchronous Command Functions
  • Clock Management and Calibration
  • Watchdog Timer
    • SafeDelay()
  • Si1133 driver
  • cTimer Timer object
    • Catena_Timer.h header file and initialization
    • cTimer begin() and end()
    • Checking for cTimer events
    • cTimer Utility routines
  • Catena_functional.h
  • cDownload
  • cBootloaderApi
  • cSerial
• Command Summary
  • Standard commands
  • STM32L0 commands
  • FRAM commands
  • LoRaWAN commands
    • LoRaWAN Parameters
• Adding your own commands
• Example sketches
  • catena_hello
  • catena_hello_lora
  • catena_usercommand
  • catena_fsm
• Board Support Dependencies
• Other Libraries and Versions Required
• Release History
• Meta
  • License
  • Support Open Source Hardware and Software
  • Trademarks

In order to assist people who are not everyday readers and writer of C++, this library adopts some rules.

1. All names are in the McciCatena namespace.

2. In classes with elaborate hierarchy, we normally define a private synonym of Super which refers to the parent class. This is done so that we can change parent/child relationships without breaking code.

3. We tend to use the m_... prefix on the names of class member fields.

4. We tend to use this->m_... to refer to class members (rather than omitting this->). We do this for emphasis, and to avoid visual ambiguity.

5. We tend to name classes starting with a lower-case letter c, i.e., cClassName. For the Catena... classes, we don’t follow this rule, however.

6. We don’t use most of the standard C++ library (because of the frequent use of exceptions), nor do we use exceptions in our own code. The exception framework tends to be inefficient, and it’s a source of coding problems because the error paths are not directly visible.

7. However, we do take advantage of some of the C++-11 header files, such as <functional>, <type_traits>, and <cstdint>. (Sometimes we have to do extra work for this.)

Unless otherwise specified, all symbols are defined inside namespace McciCatena. Usually sketches begin with something like this:

#include <Catena.h>

//... other includes

using namespace McciCatena;

Catena.h is the main header file for the library. It uses the #defines injected by board.txt and platform.txt from the Arduino environment to create a class named Catena derived from the Catena... class that is specific to the board for which the software is being built. This allows examples to be source-compatible, no matter which Catena is our target.

Catena.h defines the class Catena in terms on one of the following classes based on the setting of the BSP:

The known classes and header files are:

The following figures gives the class derivation hierarchy for the board classes.

The tree is too big to show in one diagram here. So we split according to the two families: STM32-based CPUs, and SAMD-based CPUS.

The first figure just gives relationships; the second has details about the members of each class.

Catena STM32 Class Relationships:

Catena STM32 Class Hierarchy (full detail):

The first figure just gives relationships; the second has details about the members of each class.

Catena SAMD Class Relationships:

Catena SAMD Class Hierarchy (full detail):

The hardware supported by this platform is generally similar. The architecture allows for the following kinds of variation (as outlined in the class hierarchy):

1. CPU differences (Cortex M0, RISC-V, etc.)
2. SOC differences (SAMD21, STM32L0, etc.)
3. PC-board differences (different sensors, power supply, capabilities)
4. Optional component population differences (pull-up resistor values, etc.)
5. Externally-connected sensors (one-wire temperature sensors, etc.)

Items 1-3 are to some degree known at compile time, based on the Catena model chosen. However, it’s inconvenient to update the BSP for every possible modification, so we allow some variation at run time, guided by the contents of FRAM.

The system is identified to the software by a platform object, of type CATENA_PLATFORM. Several platform objects are built into the firmware image, based on the known variations for component population and external sensors. The appropriate platform object is located at boot time by the Catena Arduino Platform framework. Some values representing possibly variation are stored as PlatformFlags in the CATENA_PLATFORM. This variable is of typePLATFORM_FLAGS.

Each CATENA_PLATFORM has a unique identification. This is a 128-bit binary number called a GUID (or UUID), generated by MCCI during the system design process. The platform GUIDs are defined in the header file Catena_Guids.h. For convenience, here’s a table of the known GUIDs.

All of these names begin with the string GUID_HW_, so we omit that from the tables below.

The M101 and M102 designations are used by the Catena-Sketches family of applications to determine what external sensors are available. This lets them avoid trying to poll external hardware unless the appropriate platform configuration is set. The well known configurations are:

• M101: external sensors on screw terminals are contact closures, and should be totalized.
• M102: external sensors on screw terminals are a mixture of one-wire temperature sensors and two-wire soil temperature/humidity probes.

The designations “M103” and “M104” are reserved for use by MCCI.

For boards with FRAM, the appropriate platform GUID should be selected and programmed into FRAM using the command system configure platformguid, followed by the GUID value. For boards without FRAM, the library has provisions for tying the GUID to the CPU serial number. Contact MCCI for details.

The tables below were generated from Catena_Guids.h using a script, and then hand annotated. The script is a one-line shell command using awk:

awk '/^[/][/]/ {
    s = $2; gsub(/[{}]/, "", s);
    getline;
    g = $2; gsub(/\(f\)$/, "", g);
    gsub(/^GUID_HW_/, "", g);
    printf("`%s` | `%s` |\n", g, tolower(s));
    }' src/Catena_Guids.h | LC_ALL=C sort

The Catena 4610 uses a LiPo battery like traditional Feathers, and includes a BME280 temperature/pressure/humidity sensor, and a Si1133 light sensor.

The 4611 uses a boost regulator that is either on or fully off, controlled by the enable pin. It’s therefore a hybrid between the 4610 (which uses a battery charger switch controlled by the enable pin), and the 4612 (which instead uses the switch to jump from raw Vbat to regulated 3.3V). The 4611 is available by special order from MCCI. Generally, MCCI uses the 4612 instead.

The 4612 runs off an unregulated battery supply, with the option of a boost regulator that can bring the system voltage up to 3.3V.

The Catena 4617 is a variant of the Catena 4612 with a IDT HS3001 temperature/humidity sensor in place of the Bosch BME280.

The Catena 4618 is a variant of the Catena 4612 with a Sensirion SHT31-DIS-F temperature/humidity sensor in place of the Bosch BME280.

The Catena 4630 is a variant of the Catena 4610. It deletes the Si1131 light sensor, and adds an IDT ZMOD4410 atmospheric gas sensor, plus a connection for an external Plantower PMS7003 PM2.5/dust sensor.

The 4450 Feather Wing includes a BME280 temperature/humidity/pressure sensor, and a BH1750 lux sensor.

The 4460 Feather Wing includes a BME680 air quality sensor, and a BH1750 lux sensor.

The 4470 Feather Wing includes a BME280 temperature/humidity/pressure sensor, a BH1750 lux sensor, and a Modbus/RS-485 interface connected to Serial1.

MCCI also uses this library with Feather M0s without MCCI hardware. These GUIDs are useful in that situation.

When composing software from components, it’s inconvenient and bug-prone to have to manually edit the Arduino loop() function to poll each component.

To compensate, the Catena platform defines a framework for polling, and allows components to register to be polled.

The foundation of the framework is cPollableInterface, an abstract class. Any object inheriting from cPollableInterface will provide a poll() method; this provides a standard way to poll an object.

Pollable objects are managed via a central instance of cPollingEngine, which works on objects that are derived from cPollableObject. You create your pollable class by arranging for it to inherit from cPollableObject; then at run time you arrange to register and normally created by arranging for them to inherit from cPollableObject. This adds a few tracking fields to your class, and makes them available to the cPollingEngine when you register the object with the polling engine.

The abstract relationships are shown below.

Let’s say that UserClass1 exists and has the following definition.

class UserClass1 : public ParentClass {
public:
  // constructor
  UserClass1() {}
  void begin();
};

To make UserClass1 pollable, you change the class declaration as follows:

1. Change UserClass1 to inherit from McciCatena::cPollableObject, using multiple inheritance if needed. List McciCatena::cPollableObject last. No need to make it public.

2. Declare a new public virtual method void poll(). We recommend that you use the override keyword to make it clear that this is an override for a method declared in the parent class.

You also, of course, must supply an implementation of UserClass::poll().

Here’s an example of the transformed UserClass1:

class UserClass1 : public ParentClass, McciCatena::cPollableObject {
public:
  // constructor
  UserClass1() {}
  void begin();

  // <<Pollable>> requirements:
  virtual void poll() override;
};

Each instance of your pollable class (in our example, each instance of type UserClass1) must be registered with a polling engine. The most convenient polling engine to use is the once provided by the CatenaBase class, which is normally instantiated as gCatena. Simply call gCatena.registerObject() to register your object with the Catena polling engine. So for example:

#include <Catena.h>

// create the gCatena instance.
McciCatena::Catena gCatena;

// create an instance of my object.
UserClass1 myUserObject;

void setup() {
  // conventionally, we call gCatena.begin() first:
  gCatena.begin();

  // now register the object.
  gCatena.registerObject(&myUserObject);
}

void loop() {
  // poll all the objects registered with gCatena.
  gCatena.poll();
  // do any other work...
}

If you’re not using the full Catena class framework, you still can use polling; just declare your own cPollingEngine instance. For example:

#include <Arduino.h>
#include <Catena_PollableInterface.h>

// create the polling engine instance.
McciCatena::cPollingEngine gPollingEngine;

// create an instance of my object.
UserClass1 myUserObject;

void setup() {
  // conventionally, we call gPollingEngine.begin() first:
  gPollingEngine.begin();

  // now register the object.
  gPollingEngine.registerObject(&myUserObject);
}

void loop() {
  // poll all the objects registered with gCatena.
  gPollingEngine.poll();
  // do any other work...
}

Finite state machines are very useful when implementing non-blocking asynchronous programs, or modeling external hardware that changes state independently of the system.

We’ve ported an implementation of MCCI’s standard FSM approach. It’s good for Mealy or Moore designs, and is intended to be easy to implement and maintain. This version is C++ oriented; it assumes that each FSM instance is associated with a C++ class object (the “parent” object). The work of implementing the FSM is divided between the parent object and the FSM object. The FSM object does all the bookkeeping and handling of corner conditions; the parent object provides a method function, which the FSM calls whenever it seems appropriate to do so.

Here’s what you need:

• an enum class type with all of your states, and a couple of distinguished states. This type is referred to as TState; and
• an associated C++ class type (referred to as TParent), containing…
• a method that will be used as the dispatcher by the evaluator, of signature TParent::someName(TState currentState, bool fEntry) -> TState.

In addition to the states relevant to your problem, TState must have three distinct values with well-known names.

• TState::stNoChange does not correspond to any state. Instead, it’s the value returned by the dispatch routine when the state is not to be changed. (Returning the current state will cause the FSM to transition from the current state to the current state.)

• TState::stInitial is the initial state of your FSM.

• TState::stFinal is the final state of your FSM. Once the FSM reaches this state, it will remain there until another call to fsm.init() is made.

We’ll use the coin-operated turnstile example from Wikipedia to make things more concrete.

The author usually starts by drawing a diagram, labeled with the states and transitions.

For example, here’s the turnstile state diagram:

Define an enum class as follows:

enum class MyStateEnum {
  stNoChange = 0,    // this name must be present: indicates "no change of state"
  stInitial,         // this name must be presnt: it's the starting state.
  // use-case-specific states
  // ...
  stFinal,           // this name must be present, it's the terminal state.
};

For example, for the turnstile diagram:

enum class State {
  stNoChange = 0,    // this name must be present: indicates "no change of state"
  stInitial,         // this name must be presnt: it's the starting state.
  stLocked,
  stUnlocked,
  stFinal,           // this name must be present, it's the terminal state.
};

This means finding the class name for the class that is going to contain this FSM. One class can contain many FSMs, but each FSM class has only one parent class.

For our example, we’ll say that the class modeling turnstiles is Turnstile.

Add the type you defined above to the parent class. For example:

class Turnstile {

  // states for FSM
  enum class State {
    stNoChange = 0,    // this name must be present: indicates "no change of state"
    stInitial,         // this name must be presnt: it's the starting state.
    stLocked,
    stUnlocked,
    stFinal,           // this name must be present, it's the terminal state.
  };

};

Add an FSM instance as a member of the parent class. It’s up to you whether to make it public, private, or protected.

class Turnstile {

  // states for FSM
  enum class State {
    stNoChange = 0,    // this name must be present: indicates "no change of state"
    stInitial,         // this name must be presnt: it's the starting state.
    stLocked,
    stUnlocked,
    stFinal,           // this name must be present, it's the terminal state.
  };

  // the FSM instance
  McciCatena::cFSM<Turnstile, State>  m_fsm;
};

Finally, we have to declare a method function that the FSM can call. Extending the turnstile example again:

class Turnstile {

  // states for FSM
  enum class State {
    stNoChange = 0,    // this name must be present: indicates "no change of state"
    stInitial,         // this name must be presnt: it's the starting state.
    stLocked,
    stUnlocked,
    stFinal,           // this name must be present, it's the terminal state.
  };

  // the FSM instance
  McciCatena::cFSM<Turnstile, State>  m_fsm;

  // the FSM dispatch function called by this->m_fsm.
  State fsmDispatch(State currentState, bool fEntry);
};

Your FSM dispatch function will look like this.

void Turnstile::fsmDispatch(Turnstile::State currentState, bool fEntry) {
  State newState = State::stNoChange;

  switch (currentState) {

  case State::stInitial:
    if (fEntry) {
      // entry is not considered in this state, always move on.
    }
    digitalWrite(LOCK, 1);
    pinMode(LOCK, OUTPUT);
    newState = State::stLocked;
    break;

  case State::stLocked:
    if (fEntry) {
      digitalWrite(LOCK, 1);
    }
    if (this->m_evShutdown) {
      this->m_evShutdown = false;
      newState = State::stFinal;
    } else if (this->m_evCoin) {
      this->m_evCoin = false;
      newState = State::stUnlocked;
    } else if (this->m_evPush) {
      this->m_evPush = false;
      // stay in this state.
    } else {
      // stay in this state.
    }
    break;

  case State::stUnlocked:
    if (fEntry) {
      digitalWrite(LOCK, 0);
    }
    if (this->m_evShutdown) {
      this->m_evShutdown = false;
      newState = State::stFinal;
    } else if (this->m_evCoin) {
      this->m_evCoin = false;
      // stay in this state.
    } else if (this->m_evPush) {
      this->m_evPush = false;
      newState = State::stLocked;
    } else {
      // stay in this state.
    }
    break;

  case State::stFinal:
    // by policy, we idle with the turnstile locked.
    digitalWrite(LOCK, 1);
    // stay in this state.
    break;

  default:
    // the default means unknown state.
    // transition to locket.
    newState = State::stLocked;
    break;
  }
  return newState;
}

Somewhere in your initialization for Turnstile, add the following code. For example, if Turnstile has a Turnstile::begin() method, you could write:

void Turnstile::begin() {
  // other init code...

  // set up FSM
  this->m_fsm.init(*this, fsmDispatch);

  // remaining init code...
}

When logging data, we frequently need to keep time on a scale that is correlated with other devices. Although the Arduino environment provides interval times based on the seconds(), millis() and micros() APIs, there’s no built-in concept of calendar time. The cDate class provides calendar time objects and the ability to perform conversions between calendar time and interval time. The cDate object is also an important component for clock drivers.

#include <Catena_Date.h>

// allocate a date object, initially invalid
McciCatena::cDate myDate;

It’s common to compare intervals and transmit timestamps using a simple up-counter. Traditional Posix systems count seconds since 1970-01-01 00:00:00Z; GPS systems count seconds since 1980-01-06 00:00:00Z. These base times are commonly called “epochs”. Times can be (theoretically) in the past (negative) or future (positive) relative to the epoch. For a variety of reasons, we call times based on the Posix epoch “Common times”; we call times based on the GPS epoch “GPS times”. The types CommonTime_t and GpsTime_t are used to record times in common and GPS times. Both are of type std::int64_t. Both have a range of designated values that are valid; this range is chosen to allow any valid CommonTime_t to be converted to GpsTime_t and vice versa.

constexpr cDate::CommonTime_t cDate::kCommonTimeInvalid;
constexpr cDate::CommonTime_t cDate::kGpsTimeInvalid;

constexpr bool cDate::isCommonTimeValid(CommonTime_t);
constexpr bool cDate::isGpsTimeValid(GpsTime_t);

constexpr cDate::CommonTime_t cDate::getCommonTime(GpsTime_t);
constexpr cDate::GpsTime_t cDate::getGpsTime(CommonTime_t);

Many numerical values of std::int64_t are not valid times. The library uses kCommonInvalidTime and kGpsInvalidTime when it needs to create an invalid time, but it (and clients of the library) should use isCommonTimeValid() or isGpsTimeValid() to check whether a given time is in fact valid.

getCommonTime() and getGpsTime() convert valid times between the two systems, handling invalid cases.

The types cDate::Year_t, cDate::Month_t, cDate::Day_t, cDate::Hour_t, cDate::Minute_t, cDate::Second_t are used to represent years (from 0 to 65535), months (from 1 to 12), days (from 1 to 28, 29, 30, or 31, depending on the month and year), hours (0 to 23), minutes (0 to 59), and seconds (0 to 59). The year zero corresponds to ISO-8601 year zero. We use, technically speaking, a proleptic Gregorian calendar with astronomical year numbering (i.e., year zero).

bool cDate::isValid() const;

This function returns true if the entries in the cDate object are valid, false otherwise.

cDate::Year_t cDate::year() const;
cDate::Monty_t cDate::month() const;
cDate::Day_t cDate::day() const;
cDate::Hour_t cDate::hour() const;
cDate::Minute_t cDate::minute() const;
cDate::Second_t cDate::second() const;

These functions return the various fields of the date.

cDate::CommonTime_t cDate::getCommonTime() const;
cDate::GpsTime_t cDate::getGpsTime() const;

These functions return the CommonTime_t or GpsTime_t equivalent of the date object.

bool cDate::setDate(Year_t y, Month_t m, Day_t d);

Set the date portion of the cDate instance (only if a valid date is passed). Return true if and only if the date was updated.

bool cDate::setTime(Hour_t h, Minute_t m, Second_t s);

Set the time portion of the cDate instance (only if a valid time is passed). Return true if and only if the time was updated. Time is set in zone UTC+0.

bool cDate::setCommonTime(CommonTime_t commonTime);
bool cDate::setGpsTime(GpsTime_t gpsTime);

Set the date and time of the cDate instance from the common or GPS time stamp. Returns false if the incoming timestamp is invalid, or if the specified time is out of range.

This section is provided for background, and can be skipped if you’re not interested in the theory behind the implementation.

Timekeeping is a thorny topic for scientific investigations, because one day is not exactly 86,400 seconds long. Obviously, the difference between two instants, measured in seconds, is independent of calendar system, but converting the time of each instant into ISO date and time is not independent of the calendar. Worse is that computing systems (e.g. POSIX-based systems) focus more on easy, deterministic conversion from a time serial number to UTC time, and so assume that there are exactly 86400 seconds/day. In UTC time, the solar calendar date is paramount; leap-seconds are inserted or deleted as needed to keep UTC mean solar noon aligned with astronomical mean solar noon.

In effect, the computer observes a sequence of seconds. We need to correlate them to calendar time, and we need to interpret know the interval between instances. Let’s call the sequence of seconds interval time, as opposed to calendar time.

Let’s also define an important property of sequences of seconds — “interval-preserving” sequences are those in which, if T1 and T2 are interval second numbers, (T2 – T1) is equal to the number of ITU seconds between the times T1 and T2.

Real-time calendar clocks typically measure intervals using a mixed-radix system (year/month/day hour:minute:second). This looks much like UTC calendar time, but in fact doesn’t include leap seconds, and is a pure interval counter (with inconvenient arithmetic).

There are (at least) three ways of relating interval time to calendar time.

1. Keep interval time interval-preserving, and convert to calendar time as if days were exactly 86,400 seconds long. (GPS is such a time scale.) Differences between instants (in seconds) are in ITU seconds.
2. Keep interval time interval-preserving, but convert to calendar time accounting for leap seconds (most days are 86,400 seconds long, but some days are 86,399 seconds long, others are 86,401 seconds long). (UTC is such a time scale.) Differences between instants (in seconds) are in ITU seconds.
3. Make interval time not interval-preserving by considering leap seconds. A day with 86,401 ITU seconds will have two seconds numbered 86,399; a day with 86,399 ITU seconds will not have a second numbered 86,399. Convert to date/time as if days were exactly 86,400 seconds long. The difference between two instants (in interval time) is not guaranteed to be accurate in ITU seconds. This is how POSIX time works.

Steve Allen’s website has a number of good discussions, including:

• Issues involved in computer time stamps and leap seconds
• Two kinds of Time, Two kinds of Time Scales

The onboard real-time clocks provided by various Catena platforms count intervals in “calendar” time, and are set by people (again in “calendar” time) from watches etc. that run from UTC or a derivative. We avoid the additional complication of local time zones by assuming that the user will use GMT (UTC+0, or “Zulu” time) We will assume that the user can input the time in Zulu time and that the battery-backed RTC is recording time in Zulu time.

Therefore, we use a timescale that simply states that days have 86,400 seconds. In effect, we choose option 1 above. In our applications, we think that this will be good enough. If we ever start to use LoRaWAN (“GPS”) time, we assume that the network will be able to send us the information needed to convert to calendar time as needed. This may add a little complication but it’s future complication and we’ll deal with all this if the need arises.

The Catena Arduino Platform includes C++ wrappers for LoRaWAN support, based on the MCCI version of the Arduino LMIC library and MCCI’s Arduino LoRaWAN library. It includes command processing from the Serial console for run-time (not compile-time) provisioning, and uses the non-volatile storage provided by the Catena FRAM to store connection parameters and uplink/downlink counts.

The Catena::LoRaWAN class is derived from the Arduino_LoRaWAN class defined by <Arduino_LoRaWAN.h>.

The example catena_hello_lora.ino is a complete working example.

To use LoRaWAN in a sketch, do the following.

1. Instantiate the global Catena object, with the name gCatena.

   #include <Catena.h>
   
   using namespace McciCatena; // to save typing
   
   Catena gCatena;  // instantiate the Catena platform object.

2. Instantiate the global LoRaWAN object, with the name gLoRaWAN:

   Catena::LoRaWAN gLoRaWAN;  // the LoRaWAN function.

3. In your setup function, initialize gCatena, gLoRaWAN, and register gLoRaWAN as a pollable object (see Polling Framework).

   void setup() {
     // other things
   
     // set up Catena platform.
     gCatena.begin();
   
     // set up LoRaWAN
     gLoRaWAN.begin(&gCatena);
     gCatena.registerObject(&gLoRaWAN);
   
     // other things
   }

Use the Catena::LoRaWAN::SendBuffer() method to send an uplink message. Usually it’s best to send it with an asynchronous callback, so that’s what we’ll show.

Definitions:

typedef void (Arduino_LoRaWAN::SendBufferCbFn)(
  void *pClientData,
  bool fSuccess
);

bool Catena::LoRaWAN::SendBuffer(
  const std::uint8_t *pUplinkBuffer,
  size_t nBuffer,
  Arduino_LoRaWAN::SendBufferCbFn *pDoneFn,
  void *pClientData,
  bool fConfirmed,
  std::uint8_t port
);

SendBuffer attempts to start the transmission of a buffer. This attempt might fail for several reasons, for example:

• A transmission might already be in progress.
• The LoRaWAN system might not be properly provisioned with device identity and suitable keys.
• The LoRaWAN system might be shut down.

If the transmission is not accepted, SendBuffer() returns false.

If the transmission is accepted, then the following steps are taken:

• pDoneFn and pClientData are saved internally for use when the transmission completes.
• The data from pUplinkBuffer is copied into an internal buffer (so you can immediately start reusing the buffer in your own code).
• If the device is provisioned for OTAA mode, and the device is not yet joined to a network, a JOIN attempt is initiated; and the message is transmitted if the JOIN attempt succeeds.
• The message is transmitted on the uplink port specified by port. If fConfirmed is true, a confirmed (acknowledged) uplink is used; otherwise unconfirmed uplinks are used.
• Control then returns to the caller (with the result true).

When the transmission attempt finishes, the LoRaWAN subsystem calls pDoneFn(pClientData, fSuccess), with fSuccess true if the uplink seemed to be successful. Success means different things in different circumstances.

• For an unconfirmed uplink, success means that the device is joined to a network, and was able to transmit the message without any local errors. If not joined, and the join attempt fails, then fSuccess will be false.
• For a confirmed uplink, success means that the message was sent, and a confirmation downlink was received. Failure doesn’t necessarily mean that the network didn’t receive the message; it only means that we didn’t get an acknowledgement.

Receiving a message is a somewhat passive operation. The client registers a callback with gLoRaWAN; later, whenever a downlink message is received, the client’s callback is called.

typedef void Arduino_LoRaWAN::ReceivePortBufferCbFn(
  void *pCtx,
  uint8_t uPort,
  const uint8_t *pBuffer,
  size_t nBuffer
  );

void Arduino_LoRaWAN::SetReceiveBufferBufferCb(
  ReceivePortBufferCbFn *pReceivePortBufferFn,
  void *pCtx
  );

In order to allow code to be portable across networks and regions, we’ve done a lot of work with abstraction classes. If you’re curious, here’s a somewhat simplified diagram (click on the diagram to get an enlarged SVG version).

As the diagram shows, Catena::LoRaWAN objects are primarily Arduino_LoRaWAN derivatives, but they also can be viewed as McciCatena::cPollableObject instances, and therefore can participate in polling.

Many MCCI Catena models include FRAM storage for keeping data across power cycles without worrying about the limited write-tolerance of EEPROM or flash. (FRAM, or ferro-electric RAM, is essentially non-volatile memory that can be freely written. Flash EPROM and EEPROM can be written, but tend to have non-local error properties and limited write durability. They are good for storing code, but troublesome for storing counters, because a location must be updated each time a counter is written.)

The abstract class cFram is used to represent a FRAM-based storage element. It is abstract in that is uses several virtual methods that must be supplied by the concrete class that represents the specific FRAM chip. (For example, cFram2K represents a 2k by 8 FRAM.)

All FRAMs managed by cFram use a common object format on the FRAM, defined by the header file Catena_FramStorage.h.

• Storage is viewed as a linear sequence of objects.

• Each object uses a common format.

• Each object consists of a common 24-byte header followed by a variable-length storage field.

• Objects are always a multiple of 4 bytes long.

• Objects are identified by “globally unique ID” (or GUID) and “key” (an 8-bit value). GUIDs are 16-byte values, generated by a standard algorithm with low likelihood of collision. We considered using one GUID for each object, but that would consume a lot of room in system flash memory. So instead, we use an extra one-byte key, which allows most objects to share a common GUID. This approach allows for more space-efficient code on systems with limited system memory.

Each standard object contains a data payload. For any given object, the payload size is fixed when the object is created.

Objects normally contain two payload slots. The slots are written alternately (so that the old version is always available). A voting scheme is used to determine which slot is currently live. Three bytes are used for storing the “current” slot indicator, and are updated only after the new data have been written. A system interruption before the second byte of the trio is written will cause the system to use the old value after recovering from the problem; a system interruption after the second byte of the trio is written will cause the system to use the new value.

The first uint32_t of an object records the overall size of the object, and the size of each data payload slot. Objects are always required to be a multiple of 4 bytes long, so the size is recorded as a count of uint32_t values. Objects are allowed to be up to 2^18 bytes long. Data payload fields are specified in bytes, and are limited to [0..32767] bytes.

There is an escape clause. If bit 31 of the first uint32_tis set, the object is not “standard”. In such a case, the contents of the object after the standard header cannot be used for a standard data payload (as defined above). This may be desirable payloads that are written only once, when the FRAM is initialized; but it leaves redundancy management to the client.

This format is summarized in the following tables.

An FRAM store managed by this library is expected to begin with a header object. A header object is identified by the well-known GUID {1DE7CDCD-0647-4B3C-A18D-8138A3D9613F} and the key kHeader (zero).

The header object carries a single 4-byte (uint32_t) payload, which is interpreted as the end-of-storage address — the offset of the first byte on the FRAM that is not used for object storage. If an object is added to the store, this pointer is updated after the new object object has been fully committed. The new object is not permanently committed until the end-of-storage pointer is atomically updated.

1. Determine the GUID and key you want to use. If you are adding the item as part of the Catena library, you can use the GUID GUID_FRAM_CATENA_V1(WIRE), {1DE7CDCD-0647-4B3C-A18D-8138A3D9613F}; add the key to McciCatena::cFramStorage::StandardKeys, defined in Catena_FramStorage.h.

   There is no presentable way to use a non-standard GUID; several changes must be made in Catena_Fram.cpp to enable this.

2. Ultimately, the metadata for your new object is represented by a 32-bit value of type cFramStorage::StandardItem. The constructor takes three (optionally four) arguments:

   • uKey, the 8-bit key value
   • uSize, the 16-bit object size. (If your object is variable size, you must specify a maximum size, and the actual size of the object must be represented as part of the object data somehow.)
   • fNumber, a Boolean value. If true, then the value represents a little-endian value; if false, big-endian. This is used for displays and the command interpreter.
   • Optionally fReplicated (assumed true), which controls whether the replicated data-storage scheme should be used.

3. Find the table McciCatena::cFramStorage::vItemDefs[] in Catena_FramStorage.cpp, and add your StandardItem value at the appropriate offset.

4. To query the value of your object, you can use gCatena.getFram()->getField(uKey, Value); this is a templated function which will set Value according toe the current value stored for uKey.

   • You may also use gCatena.getFram()->getField(uKey, (uint8_t *)&buffer, sizeof(buffer)).

5. To set the value of your object, you can use gCatena.getFram()->saveField(uKey, Value); this is a templated function which will write Value to the object identified by uKey.

   • You may also use gCatena.getFram()->saveField(uKey, (const uint8_t *)&buffer, sizeof(buffer)).

The Catena Arduino platform provides both an asynchronous command-line collection object and a full command parser.

The Catena::begin() method normally creates a command parser instance that’s linked to a command parser instance. For

The header file Catena_StreamLineCollector.h defines the class cStreamLineCollector. This class is a cPollableObject, and as such is polled automatically by the governing cPollingEngine. A read is launched by calling cStreamLineCollector::readAsync(), passing a callback function, a buffer (base and size), and a context handle. When a command has been accumulated, the specified callback function is called according to the following prototype:

typedef void (cStreamLineCollector::ReadCompleteCbFn)(
    void* pCtx,
    cStreamLineCollector::ErrorCode uStatus,
    uint8_t *pBuffer,
    size_t nBuffer
    );

• pCtx is the user-supplied context parameter passed to cStreamLineCollector::readAsync.
• uStatus indicates whether the read was successful, and gives a rough idea of the failure reason if not.
• pBuffer points to the first byte of data. This might be nullptr in case of error, and it might be different than the user’s original buffer pointer.
• nBuffer is passed as the actual number of data bytes in the buffer. In case of error, nBuffer will be zero.

A command parser is initialized with a reference to a cStreamLineCollector instance and a convenience reference to the governing cCatena instance. It is initialized with

bool cCommandParser::begin(cStreamLineCollector *pStream, cCatena *pCatena)`

The command parser works by parsing the input line into words, and then finding the command in command tables, which the client registers at run time using the following function:

void cCommandParser::registerCommands(cDispatch *pDispatch, void *pContext);

Multiple command tables can be registered dynamically; this allows modules to add commands as they are initialized. There’s no need to edit a central command table.

The command tables consist of a top-level cCommandParser::cDispatch instance. This is not a const — it has bookkeeping entries to help with building the tables at runtime without requiring malloc(). The dispatch instance points in turn to a

static cCommandStream::cDispatch myTable(/* cCommandStream::cEntry * */&table, sizeof(table));

or

static cCommandStream::cDispatch myTable(/* cCommandStream::cEntry * */&table, sizeof(table), "groupname");

In the first case, the commands are each entered into the top-level name space. In the second case, a top-level command named groupname is entered, and each of the commands in the table is entered as a secondary command.

The command tables themselves are simple arrays of name/function pointer pairs.

static cCommandStream::CommandFn function1, function2 /*, etc. */;

static const cCommandStream::cEntry table[] = {
    "cmd1", function1,
    "cmd2", function2,
    // ...
};

The signature of each function is:

cCommandStream::CommandStatus function1(
    cCommandStream *pThis,
    void *pContext,
    int argc,
    char **argv
    );

pThis points to the parent cCommandStream instance. pContext is the user data from the relevant cCommandStream::cDispatch object. argc and argv are very much like the command arguments to a C main() function. argv[0] is the matching command, and argv[1..argc-1] are the parsed arguments from the command line.

A command function may operate synchronously or asynchronously.

Command stream functions may call any of these functions:

• pThis->printf() formats results to pass back to the command source.
• pThis->getuint32() scans an argument and converts to uint32_t.
• pThis->completeCommand(CommandStatus) signals the completion of an asynchronous command.

A synchronous command function does all of its work in the initial function call, and returns a status code. The status code can be any value except CommandStatus::kPending. Synchronous commands must not call pThis->completeCommand(CommandStatus).

An asynchronous command function allows for work to continue after the initial function call. The main command function typically has two parts.

1. The first part of the command is normally coded synchronously; it checks parameters, etc., and returns non-kPending status. In this part of the command, there’s no chance of pThis->completeCommand being called.

2. The second part of the command is coded asynchronously. The asynchronous paths each call pThis->completeCommand() when all work has been done. Once the function has established at least one asynchronous completion path, the main function must return kPending (and must ensure that all the completion paths call completeCommand()).

On some platforms, the system clock needs to be calibrated explicitly in order for the real-time ticks from micros() and millis() to be accurate. Do this by calling uint32_t gCatena.CalibrateSystemClock(). This function updates the clock calibration, and returns a platform-specific value indicative of the calibration. On platforms that don’t support (or that don’t need) calibration, a dummy implementation is provided that returns 0.

The independent watchdog is used to detect and resolve malfunctions due to software failures. It triggers a reset sequence when it is not refreshed within the expected time-window (we use 26 seconds time-window). Along with the watchdog timer, we use SafeDelay() function.

It serves as an alternative to the Arduino delay() function. Its purpose is to refresh the watchdog time-window, thus preventing any potential resets during delay operations within the application. Like Arduino delay(), it accepts milliseconds as a parameter.

The library includes a simple driver for the SiLabs 1133 light sensor found on many Catena boards.

The header file is Catena_Si1133.h. It defines the class Catena_Si1133.

The constructor, Catena_Si1133(), takes no arguments.

Call Catena_Si1133::begin() prior to using the sensor, and Catena_Si1133::end() to shut it down.

Catena_Si1133::configure() configures one channel of the sensor. It has one of two forms. The original form allows you to choose from pre-configured measurement profiles. Prototype:

bool configure(uint8_t uChannel, uint8_t uMode, uMeasurementCount = 0);

Up to six channels may be configured. uMode is one of the following: CATENA_SI1133_MODE_NotUsed to configure a channel as not used, CATENA_SI1133_MODE_SmallIR to use the small IR sensor, CATENA_SI1133_MODE_MediumIR to use the medium IR sensor, CATENA_SI1133_MODE_LargeIR to use the large IR sensor, CATENA_SI1133_MODE_White to use the regular white sensor, CATENA_SI1133_MODE_LargeWhite to use the large white sensor, CATENA_SI1133_MODE_UV to use the ultraviolet sensor, CATENA_SI1133_MODE_UVDeep to use the deep UV sensor.

uMeasurementCount is zero to use the channel in forced mode, and non-zero to have the channel run in autonomous mode.

An advanced form provided complete flexibility. A special object is defined, Catena_Si1133::ChannelConfiguration_t, which can represent all aspects of a measurement. To set up a measurement configuration, write something like this:

auto const measConfig = Catena_Si1133::ChannelConfiguration_t()
    .setAdcMux(Catena_Si1133::InputLed_t::LargeWhite)
    .setSwGainCode(7)
    .setHwGainCode(4)
    .setPostShift(1)
    .set24bit(true)
    .setCounter(Catena_Si1133::ChannelConfiguration_t::CounterSelect_t::MeasCount2);

This creates a value, measConfig, that defines a measurement of the large-white LED, with software gain 7, hardware gain 4, and a post-shift of 1. The measurement, if periodic, will be driven by counter 2. (In forced mode, the counter settings are ignored.)

A number of methods allow you to modify and query ChannelConfiguration_t values.

To define a channel using a ChannelConfiguration_t object, call the following method:

bool configure(uint8_t uChannel, ChannelConfiguration_t config, uMeasurementCount);

In the advanced method, uChannel and uMeasurementCount have the same meaning as in the pre-configured method.

bool start(bool fOneTime = false);

Start a repeated or one-time measurement.

bool isOneTimeReady();

Return true if a one-time measurement is complete. All the measurements must have completed.

uint32_t readChannelData(uint8_t uChannel = 0);

Read the value for the specified channel.

void readMultiChannelData(uint16_t *pChannelData, uint32_t nChannel);
void readMultiChannelData(uint32_t *pChannelData, uint32_t nChannel);

Read nChannel channels of data, starting from channel 0, into the table at pChannelData. If all measurements are 16 bits, then the 16-bit form may be used. If any measurement is 24 bit, then the 32-bit form should be used.

Timer objects are used to simplify the implementation of periodic events.

#include <Catena_Timer.h>

This header file contains all the definitions for the cTimer class.

The constructor takes no arguments. To create a timer named myTimer, write:

McciCatena::cTimer myTimer;

Timers are initially stopped. To start a timer, call:

bool cTimer::begin(std::uint32_t nMillis);

This method initializes the timer to run with a period of nMillis milliseconds. The timer automatically restarts each time the period elapses; so it’s like a clock that ticks every nMillis milliseconds.

To stop a timer, call:

void cTimer::end();

To check whether a timer has ticked, call one of the following:

bool cTimer::isready();

std::uint32_t cTimer::readTicks();

std::uint32_t cTimer::peekTicks() const;

std::uint32_t cTimer::getRemaining() const;

isready() returns true if the timer has ticked at least once since the last time isready() or readTicks() was called. readTicks() returns the number of ticks that have occurred since the last time readTicks() or isready() was called. Both of these, in effect, reset the tick counter.

peekTicks() returns the number of ticks since the last call to readTicks() or isready(), but doesn’t reset the tick counter.

getRemaining() returns the number of milliseconds remaining in the current timer cycle.

std::uint32_t cTimer::getInterval() const;

std::uint32_t cTimer::setInterval(std::uint32_t nMillis);

void cTimer::retrigger();

getInterval() returns the number of milliseconds per timer tick.

setInterval() changes the timer period to a new value, but doesn’t change the base time of the current period. If the period is lengthened, then the next tick occurs relative to the base time plus the new period. If the period is shortened, ticks will immediately occur to cover any ticks between the base time of the period and now.

retrigger() sets the base of the current period to the current time, and resets any pending ticks.

This wrapper allows the C++ <functional> header file to be used with Arduino code.

The technical problem is that the arduino.h header file defines min() and max() macros. This causes problems with parsing the <functional> header file, at least with GCC.

The solution is a hack: undefine min() prior to including <functional>, and then redefine them using the well-known definitions.

This class may be instantiated as a general-purpose wrapper for supporting the MCCI Trusted Bootloader on STM32L0 platforms. It has two primary entry points. cDownload::evStartSerialDownload() starts a download over a serial port, which is assumed to support 8-bit clean data transport. cDownload::evStart() starts an abstract download; the client supplies a cDownload:Request_t object which includes callbacks for fetching data. An instance of the cBootloaderApi is also required.

This class may be instantiated as a singleton to provide the interface to the Trusted Bootloader. It allows access to the APIs exported by the bootloader, as well as to the application structures that accompany the bootloader.

This class provides an abstract wrapper for various Arduino Serial-like classes so that a single pointer can be used to refer to any of the possibilities (hardware serial, USB serial, software serial, etc.) It’s intended primarily for use by the downloader, so doesn’t provide 100% of the Serial-like methods.

The following commands are supported by the Catena command parser.

The following commands are added by the Catena LoRawAN module.

These parameters are generally not loaded into the LMIC immediately. They are primarily used at boot time and at join time.

Here’s a step-by-step procedure. There’s a fully worked example, catena_usercommand.

• Include the header file.

#include <Catena_CommandStream.h>

// for simplicity, we always assume this:
using namespace McciCatena;

• Declare your command functions.

// forward references to the command functions
cCommandStream::CommandFn cmdOne, cmdTwo /*, .. etc. */;

• Create a table of commands. In this example, we use static, but that’s not required.

// the individual commmands are put in this table
static const cCommandStream::cEntry sMyCommmandTable[] =
  {
    { "one", cmdOne },
    { "two", cmdTwo },
    // other commands go here....
  };

• Create the top-level structure that represents the command table to the parser. This cannot be const, because internal fields are used for linkage (to avoid run-time memory allocation in the library).

// a top-level structure wraps the above and connects to the system table
// it optionally includes a "first word" so you can for sure avoid name clashes
// with commands defined by the framework.
static cCommandStream::cDispatch sMyCommands(
    sMyCommmandTable,           // this is the pointer to the table
    sizeof(sMyCommmandTable),   // this is the size of the table
    "application"               // this is the "first word" for all the commands
                                // in this table. If nullptr, then the commands
                                // are added to the main table.
    );

• Register the table with the framework. As usual, we assume gCatena names the global top-level object.

gCatena.addCommands(
    // app dispatch table, passed by reference
    sMyCommands,
    // optionally a context pointer using static_cast<void *>().
    // normally only libraries (needing to be reentrant) need
    // to use the context pointer.
    nullptr
    );

• Write your command functions. Here’s an example.

// process the command "application one"
// argv[0] is "one" (the matching word)
// argv[1..argc-1] are the arguments, if any
cCommandStream::CommandStatus cmdOne(
    cCommandStream *pThis,
    void *pContext,
    int argc,
    char **argv
    )
    {
    // output your response using pThis->printf(), so that if there
    // are multiple command sources, the answers will go to the right
    // place.
    pThis->printf("Hello, world!\n");

    return cCommandStream::CommandStatus::kSuccess;
    }

This is a very simple sketch without LoRaWAN support. It shows the minimal boilerplate needed to use this library. Although it’s not obvious, while looping, the program automatically flashes the LED and accepts commands from the console.

This sketch adds LoRaWAN uplink to the basic hello-world application. If the LoRaWAN system is provisioned, the app transmits a single message to port 16, containing the bytes 0xCA, 0xFE, 0xBA, and 0xBE, in sequence.

If the LoRaWAN system is not provisioned, the application enters an idle loop; you can use the LoRaWAN commands to set things up.

This sketch is very similar to catena_hello. It shows how to add a user-defined command, application hello, that prints “Hello, world!“.

This sketch demonstrates the use of the Catena FSM class to implement the Turnstile example described in Finite State Machine Framework.

• v0.24.1 fixes an error in library.properties that prevented installation with newer versions of the Arduino IDE #364, #355. Thanks to Aidan McNay for the pull request.

• v0.24.0 includes the following changes.

  • fix #356: add support for storing uplink interval to FRAM (v0.24.0-pre1)

• v0.23.0 includes the following changes.

  • fix #350: add library support for STM32Lxx watchdog timer (v0.23.0-pre1)

• v0.22.0 includes the following changes.

  • fix #346: add support to Catena4618 and Catena 4612 with LTR329 sensor (v0.22.0-pre7)
  • fix #342: add support to Catena4610 version-2 (v0.22.0-pre5).
  • fix #321: add 24-bit float encoding support (v0.22.0-pre1).
  • fix #319: accomodate missing two-arg UsbSerial::begin() (v0.21.3-pre1).

• v0.21.2 includes the following changes, non breaking, all bug fixes.

  • Check SessionState for validity when fetching ABP info (#312, v0.21.2-pre1).
  • Set LMIC clock error for STM32 even when running from HSI clock; we encountered a test board that needed this and conclude that it’s generally a good idea (#313, v0.21.2-pre2).

• v0.21.1 includes the following changes; only #305 is an API extension and it’s non-breaking.

  • fix #304: invalidate library cache as part of FRAM reset processing (version 0.21.1-2).
  • fix #305: make it a little easier to debug FRAM code.
  • fix #300, #307: fix build issues for SAMD21 boards. (version 0.21.1-1, 0.21.1-3)

• v0.21.0 includes the following changes.

  • fix #286: support enhanced state save/restore for Arduino LoRaWAN library. Requires Arduino LoRaWAN v0.9.0-1 or later.
  • fix #287: switch to semantic versioning, which means that bottom 8 bits must be compared using macros, rather than directly.
  • fix #288: correct bugs in Si1133 driver.
  • fix #294: make Flash driver more gCatena.poll() friendly.
  • fix #293: don’t clobber user’s write buffer in Catena_Mx25v8035f::programPage().
  • remove the global gpCatenaBase in favor of the static CatenaBase::pCatenaBase.
  • add an API to fetch a pointer to the line collector, to allow commands to collect additional input.
  • add firmware download support, and support for the Trusted Bootloader. Firmware download can come from the serial port, or it can come from other (arbitrary) sources.
  • fix #295: rearrange log flags for more utility.
  • fix #296: add access to AppInfo block and signing info related to running app and the bootloader.

• v0.20.1 includes the following changes.

  • fix #275: add cTotalizer::setDebounce(), allowing the debounce time to be adjusted from 50ms. This can also be done in the constructor. (Version 0.20.0.30.)
  • fix #279: system could sleep forever if the beginning and end of a time range straddled the end of a month. Also fix #280, adding ability to set the time (version 0.20.0.20).
  • fix #273: in very low light conditions, with 24-bit measurements, Si1133 can generate negative light readings. Detect such values and force to zero (version 0.20.0.10).

• v0.20.0 includes the following changes.

  • Fix #268: adds support to the new board Catena 4802 (version 0.19.0.40).
  • Fix #266: clear EOC flag after every analog read (version 0.19.0.30).
  • Fix #261: add support for low level FRAM driver Catena_Mb85rc64ta::read() and write() to read/write > 255 bytes (version 0.19.0.30).
  • Fix #260: add more control to the Si1133 library (version 0.19.0.20).
  • Fix #253: add AdcStart() before each AdcGetValue() to read channel value (version 0.19.0.10).

• v0.19.0 includes the following changes.

  • #248 Add interactive command lorawan configure to display all the parameters.

• v0.18.1 includes the following changes.

  • #247 Add a generic application block to FRAM map

• v0.18.0 includes the following changes.

  • #240 Change to requiring MCCI_FRAM_I2C library.
  • #241 List required libraries in library.properties.
  • #238, #236 Add flash-based mfg data (0.17.0.60).
  • #233, #230 Add input line editing and echo control (0.17.0.50).
  • #277 Slow down polling of the Si1133; accumulate interrupt reports.
  • #228 add cDate class and parser (0.17.0.30).
  • #222 Use Arduino_LoRaWAN_network consistently as base for LoRaWAN classes. Requires Arduino_LoRaWAN 0.6.0.20 or later. (0.17.0.20)
  • #213 Vbat voltage read is inaccurate on STM32L0 platform. (0.17.0.12)
  • #211 Catena_Si1133 cannot be copied or moved. (0.17.0.11)
  • #208 Add McciCatena::cTimer class to simplify timing. (0.17.0.10)
  • #209 Fix error in Si1133 driver that caused UV measurements to be wrong. Add an API to query whether a forced measurement is done.

• v0.17.0 includes the following changes

  • #129 Improve accuracy of CatenaSTM32L0::Sleep() timing.
  • #197, #204 Add system version command.
  • #199 extract key-making script to own file and adapt for latest ttnctl, update comments. See mcci-catena-provision for USB-based provisioning, using a variant of the same script.
  • #202 Add system clock calibration for STM32L0 platforms, and add system calibrate command. Version 0.16.0.50.

• v0.16.0 includes the following changes.

  • #189 Add Catena FSM class, example, documentation.
  • #190 document the polling framework.
  • #191 Document the LoRaWAN framework.
  • #192 Document platform GUIDs for 4617, 4618, 4630.
  • #187, #184, #183, #182 CI improvements.
  • #185 eliminate warnings from gLog.isenabled() declaration.
  • Miscellaneous documentation cleanups.

• v0.15.0 includes the following changes.

  • #135, #178 add platform support for Catena 4617, 4618 and 4630.
  • #176 add documentation on platform GUIDs.
  • #170 increased size of BME680 key to allow support of recent BSEC library versions.
  • #168 updates TxBuffer_t for usability.
  • #158 add clock info to CatenaWingFram2k, and add API to get configured clock rate.
  • #164, #165, #163 enhance logging APIs.
  • #161 adds asynchronous command processing. v0.14.0.60.
  • #160 add section in README.md: Adding Your Own Commands.
  • #157, #153 Map SleepMode::Standby to STOP, and remove ineffective calls to __HAL_PWR_CLEAR_FLAG() in STM32 SleepForAlarm(). #150 change STM32 Sleep() to request STOP mode instead of STANDBY mode.
  • #28 add lorawan join command.
  • #145 Fix errors in catena_hello_lora example.
  • #143 clean up a compile warning for cFramStorage::setCurrent().
  • #142 add CATENA_ARDUINO_PLATFORM_VERSION to allow careful clients to #error rather than die with obscure compile problems.
  • #141 add cCommandStream::getuint32().
  • #140 Add example sketch for user commands.
  • #138 Check ARDUINO_LORAWAN_VERSION.
  • #137 Document command parser and commands.
  • #136 Add system reset command.
  • #125 Turn on and off HSI clock as needed if system clock is using MSI clock.
  • #127 Improve，stabilize AnalogRead() API.

• v0.14.0 (2019-02-10) includes changes for the following issues.

  • #65 refactors the STM32/SAMD code so that code common for the two ports only appears once.
  • #117 adds Catena::ReadAnalog() method for STM32 that reads the analog reference and adjust the raw ADC counts.
  • #119 corrects an error that prevented provisioning on MCCI Catena 4612 and 4801 boards.

• v0.13.0 incorporates recent bug fixes and enhancements. We added our own implementation of the RTC class (issue #86. We updated the UML docs (issue #111). We refactored the STM32 classes (issue #99 and #103). A few other minor changes (754f4b and 71d45d0).

• v0.12.0 adds support for the 4610, 4611, 4612, and 4801, and relies on the LMIC 2.3 pre-integrated pin map feature to simplify maintenance and make things more structures. We added more UML diagrams to document the class hierarchy. Now depends on MCCI SAMD BSP 1.2.0 and STM32 2.0.0. A common Catena::Sleep() method was added for architecture-neutral low-power standby (issue #83). Added experimental machineQ network support. Various minor bug fixes and enhancements.

• v0.11.0 adds a flash driver for the Catena 4470, adds a flash object for storing BME680 calibration data, and fixes bugs.

• v0.10.0 adds explicit support for the Catena 4470, and fixes minor issues.

• v0.9.0 adds explicit support for the Catena 4460.

• v0.8.1 corrects an issue with the STM32 library (some things were here that belonged in the main Arduino libraries).

• v0.8.0 has some minor changes (add the Catena4551 m101/m102/m103/m104 platform, add the Catena4450 m103/m104), and a flag change which effectively changes the API (hence the bump). We add CatenaBase::fHasLuxS1113, which indicates the presence of a SI 1113 Lux sensor (as distinct from the BH1750 or the TSL2561 lux sensor used in the Catena4410). Further, we correct the platform flags for the 4551, as it doesn’t have an I2C mux. Also incorporates some minor bug fixes for USB serial.

• v0.7.0 is a major refactoring adding support for the Catena 4551, which is based on the STM32L0. Although we think that there are no breaking changes, there might be a few, especially if code relied on structured defined internally to the MCCI-Catena-Arduino library Catena... classes.

This repository is released under the MIT license. Commercial licenses are also available from MCCI Corporation.

MCCI invests time and resources providing this open source code, please support MCCI and open-source hardware by purchasing products from MCCI, Adafruit and other open-source hardware/software vendors!

For information about MCCI’s products, please visit store.mcci.com.

MCCI and MCCI Catena are registered trademarks of MCCI Corporation. All other marks are the property of their respective owners.