Adrian Mitevski
A multifunctional and modular Firmware for Multitech's mDot based on ARM mBed provides a widerange of functionality for several Sensors such as MAX44009, BME280, MPU9250, SI1143 and uBlox. It allows you to quickly build a Sensornode that measures specific data with its sensors and sends it via LoRaWAN.
Dependencies: mDot_LoRa_Sensornode_Flowmeter_impl mbed-rtos mbed
LoRa-Sensornode Firmware for Multitech mDot
A multifunctional and modular Firmware for Multitech's mDot which provides a widerange of functionality for several Sensors. It allows you to quickly build a Sensornode that measures specific data with its sensors and sends it via LoRaWAN.
Supported Sensors
- MAX44009 (Lux Measurment) http://www.ebay.ie/itm/MAX44009-Ambient-Light-Sensor-Module-for-Arduino-with-4P-Pin-Header-/381676089124?hash=item58ddaaef24:g:-ecAAOSwzJ5XZm5E
- BME280 (Temperature, Pressure and Humdity Measurment) At the moment there are some known problem using this. https://www.adafruit.com/product/2652 https://www.amazon.com/Diymall-Pressure-Temperature-Sensor-Arduino/dp/B0118XCKTG
- MPU9250 (Acceleration, Gyroscope and Magnetometer) http://www.watterott.com/de/9-DOF-IMU-Module-With-MPU-9250
- Si1143 (Proximity up to 50cm) https://moderndevice.com/product/si1143-proximity-sensors/
- uBlox M8Q (GPS Position) http://www.dx.com/de/p/gygpsv3-m8n-u-blox-neo-m8n-001-flight-controller-gps-module-blue-394557#.V4lFW-uLRhE
Idea
The Firmware has some predefined Application Modes running different Tasks(Measurements). Each mode can be used in a different Scenario. Application_Modes define which sensors are used, how often they aquire data and how often the data has to be sent via LoRa. Lets say you just want to measure the Light then you choose an Application_Mode (or define one) that only runs TaskLight for light measurement. As a standard all measurements are taken every second and sent via LoRa but you can change that interval depending on your usage Scenario
Diff: app/uBloxConfig.h
- Revision:
- 0:f2815503561f
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/app/uBloxConfig.h Wed Jul 06 20:40:36 2016 +0000
@@ -0,0 +1,69 @@
+/**
+ * @file uBloxConfig.h
+ *
+ * @author Adrian
+ * @date 30.05.2016
+ *
+ */
+#include <string>
+#include <map>
+#include <vector>
+#include <stdint.h>
+#ifndef UBLOXCONFIG_H_
+#define UBLOXCONFIG_H_
+
+
+#define UBLOX_DISABLE_ALL_STRING "DISABLE ALL STRINGS"
+#define UBLOX_ENABLE_POSLLH_STRING "ENABLE POSLLH STRING"
+#define UBLOX_GNSS_ON "GNSS ON"
+#define UBLOX_GNSS_OFF "GNSS OFF"
+#define UBLOX_CONTINUOUS_MODE "CONTINUOUS MODE"
+#define UBLOX_POWER_SAVE_MODE "POWER SAVE MODE"
+#define UBLOX_ECO_MODE "POWER SAVE MODE"
+
+/**
+ * uBlox Modes. Modes define Sensor functionality
+ */
+enum uBLOX_MODE{
+ uBLOX_MODE_0,//!< uBLOX_MODE_0
+ uBLOX_MODE_1,//!< uBLOX_MODE_1
+ uBLOX_MODE_2,//!< uBLOX_MODE_2
+ uBLOX_MODE_3,//!< uBLOX_MODE_3
+};
+
+/**
+ * @class uBloxConfig
+ * @brief A configuration container for the uBlox.
+ * All its configuration values are stored an held inside
+ * this Class. Depending on the uBLOX_MODE it sets all the configuration values.
+ */
+class uBloxConfig {
+public:
+ uBloxConfig();
+ virtual ~uBloxConfig();
+
+ /**
+ * @brief Generates a configuration according to the chosen uBLOX_MODE. More exactly it builds
+ * the strings that have to be sent at the initialization of the uBlox to run the uBlox to
+ * run it in a specific configuration
+ * @param desiredMode the mode to build the configuration according to
+ */
+ void build(uBLOX_MODE);
+
+ std::vector< std::vector<uint8_t> > getInitialConfigurationString();
+private:
+
+ std::map<std::string,std::vector<uint8_t> > configCommands;
+ std::vector< std::vector<uint8_t> > initialCommands;
+
+ /**
+ * @brief Connects a command and its string that consists of Bytes
+ * @param command a command string describing the command
+ * @param string the content of the command
+ */
+ void connectCommandAndString(std::string command, uint8_t* string, uint8_t stringSize);
+
+
+};
+
+#endif /* UBLOXCONFIG_H_ */