-
Notifications
You must be signed in to change notification settings - Fork 2
User Stories
#Categories
- [Unsuitable Applications](#Unsuitable Applications) for which The Things Network is not a fit
- By type of Sensor I have a good idea where to start
- By Application I know what I want to do but not where to start
- Outputs I want to control something via The Things Network
- When reliability is required.
The Things Network makes no guarantees that your node will find an active gateway within range, that data sent to a gateway will propagate through the backend, or that the backend will correctly handle your data. Normally these things work, but you cannot count on that. Therefore, uses where someone's health and safety or the security of property could be imperiled by failure are not appropriate.
- High Bandwidth
The Things Network is designed to move tiny amounts of data - status reports and updates, configuration changes, etc. Think of it as sending well less than an SMS text message, only a few times a day, or just a few bytes of data hourly. Therefore, Video, Audio, and "chatty" data sources are not a fit. For these you should explore GSM/LTE or Wifi type of connections.
A user has a problem they want to solve, and a starting idea of what sort of sensor they will use, so our view is mostly how to make that sensor work with The Things Network. Sensors will probably include both common hardware store / hobby / Arduino accessory types of things, and also esoteric industrial / environmental / scientific sensors.
- I want to read a switch/button/mechanical contacts
These are some of the simplest cases. But we have to distinguish between "normally open" and "normally closed" contacts. The real question is in which state the electrical circuit will be the majority of the time, as this impacts power usage. Contact Bounce is probably not generally an issue as we'll inevitably have rules that preclude reporting again before several seconds, though if we implement a local event counter (where we periodically report the count, rather than each individual event) then we can recognize "events" that are brief enough (such as a single person walking through a busy doorway) that we do have to account for it.
- I want to report when switch contacts close
This is the easy one, we configure a digital input with a pullup resistor and a falling edge interrupt. But power is being consumed in the pullup resistor whenever the switch is closed, so if the switch is expected to then stay closed for some time, we turn off the pullup, and periodically wake up and briefly turn it on to see if the switch has been opened, in which case we can then leave it on. This tends to mean that there is a minimum time (vs battery usage decision) before which we can re-report a distinctly new event. That's especially relevant if we are counting events. The situation is better if the mechanical or electrical design of the switch means that the contacts can't stay closed for very long.
- I want to report when switch contacts open
This is harder. We can use a 100K or so pullup, but each one will increase battery consumption about 50% over normal sleep. High pullup resistors may mean unreliability in contact. We could try pulsing them with a stronger current source then backing off to a weak pullup? A more power efficient idea is to periodically wake up and poll the switch state, but that means a delay in reporting and potentially missing short events that entirely begin and end in the time between polling events.
- I want to read a light sensor
Unless it is photovoltaic (solar cell) and the change between light and dark is fairly dramatic, this is probably the kind of thing we would need to periodically poll: wake up, power the sensor, power on and read the ADC, and read it. We can then write rules for what is worth reporting - values above or below absolute thresholds, or values that have changed by a certain amount of percentage in a period of time or since the last report. PIR sensor modules can probably be used as interrupt sources, but the modules themselves consume power.
- I want to read temperature
We should be able to relatively easily support both thermistor / RTD type analog sensors, as well as digital ones like the Dallas 1-wire devices. Thermocouples for high temperatures would require an additional amplifier circuit. In any case, this is probably another of the analog type sensors where we configure a polling interval and reporting rules.
- I want to read a digital signal from something else
This is fairly simple, we will not use a pullup resistor so trigger on either polarity works, we just need level conversion (voltage reduction) as we probably have a 3.3v class MCU running at around 2 - 2.5 volts (note that the voltage conversion may consume power from the external device). Extension to monitoring serial output from something, or potentially the piezo buzzer or status LED in something is fairly straightforward providing the user is willing to crack it open and explore with a meter. But parsing trigger conditions from serial output, or distinguishing different buzz/flash patterns probably requires custom firmware or some future plugin.
- I want to read an analog sensor / voltage
The first question we have to ask is if the sensor requires power we need to supply. If so, do we need a boost converter? Generally, we'll have to wakeup and take an ADC reading periodically. Our configuration can include how often to wake up, and minimum-maximimum threshold levels that trigger reporting. We can also have a "delta" rule for reporting changes greater than a certain amount/percentage. And we may want to have some tunable parameters for how many readings to average / filter to remove noise. We also have to look at scaling input voltage ranges to the ADC - either requiring the user to install some (potentially included) discrete resistors for a divider, or an adjustable potentiometer.
- I want to report movement/vibration
Many MEMS accelerometer chips have a low current motion alarm wakeup mode. Mostly its a question if we want to put (space for) one on the node board itself or require an external module. And filtering out garbage trucks going over speed bumps.
- I want to measure distance with an Ultrasonic Sensor
This should be fairly simple, somewhat like analog inputs we'd have a configuration for how often to wake up and take a reading, and what results are interesting to report. However the sensors tend to require 5v.
- I want to build a GPS tracker
Your main challenge may be getting satellite fixes without consuming too much battery. It should not be too hard to have the node's MCU parse the key data elements out of NMEA UART output from a GPS receiver, however it will definitely be necessary to write some rules about what gets transmitted and when - you cannot simply transmit the entirety of an NMEA message, or even data extracted from every one of them. Think minutes to hours between updates.
##User Stories by Application
The "how do I even do this?" section - a user has an idea, but is not sure what sort of sensor they need.
- I want to report when a rat bait station is empty
Bait stations are typically molded plastic enclosure with several extruded blocks of bait stuck on spikes or wires inside. Since there are several using a light sensor to "see" when they have been removed as an obstruction to a beam of light may be hard. Depending on design it might be possible to weigh the bait tray (probably requires about 1/2" clearance between the tray and the underlying housing floor), though that could be confused if any foreign objects are brought in (though a persistent increase in weight could be a reportable condition). Hopefully water does not pool in there. What else might work - measuring the capacitance of the prongs and see if it changes when the bait is or isn't surrounding them?
- I want to see a picture of someone who does...
The Things Network can only support nodes which produce tiny amounts of data, so image sensors are out, unless they have local image processing which can produce a small, infrequent output based on what is seen. General webcam (even if only one picture every once in a while) type applications require wifi, or at least GSM/LTE type of uplinks.
- I want to count people/cars/bicycles
Mostly this comes down to the counting sensor, and if it requires power (from us or elsewhere). Potentially an air-hose type sensor could be self powered enough to generate a signal or close switch contacts and generate a wakeup interrupt.
- I want to weigh something
We should be able to pull data from an HX711 load cell (scale) interface, the question is more powering it (requires 2.6 volts minimum, but does have good powerdown/sleep) Again this requires the periodic wake up and check approach. Data sheet does not seem to say what the I/O voltages are - particularly, if the MCU's "high" output would be enough to register if the HX711 has a higher supply voltage, ie, run the MCU on 2xAA but the HX711 on a 3rd in series with them.
##Outputs
The Things Network is capable of passing messages down to nodes as well, though we may not support this in the first version of the firmware. The simplest form of downstream messaging is that when a node reports an item of interest, or just checking in every few hour(s) it can receive a similarly brief message in reply, which our firmware can decode to actions. Implicit in this, is that you can't control something quickly except in response to an event that makes the node wake up and contact the network.
- I want to turn on a small LED
For low-current examples, this can be done directly from an output of the node's processor. Likely the node will even have a tiny LED on it which you can control as one of the basic demos.
- I want to switch Mains (AC) power to something
We should be able to run a Solid State Relay, especially if we can use a mains power supply for the node. The main challenge is safe implementation. In the early stages it may be best to use a packaged relay solution ("powerswitch tail" etc). It is critical to make sure the switching device can handle the power and type of load (lights vs. motors, etc).
- I want to dim a Mains powered light or speed control a Mains powered motor
Much like the simple on/off case, this requires care to safely implement. Although implementing a delay after zero crossing to run a TRIAC is within the theoretical capability of our node's process, it is probably better at least initialy to use a separate, connectorized speed controller module.
- I want to play a sound / song
The node should be able to buzz a piezo speaker by itself. Playing audio could be done with an additional small board hosting a micro SD card and a class-D amplifier.
- I want to switch low voltage DC power to something
If we can use the same source to derive power for the node, running one of the common import multi-channel optoisolated relay cards should be possible. Users will need to be cautioned not to exceed the ratings of the relays. Power supply safety will be a concern.
- I want to run a DC motor
This can be done with a relay, or if variable speed is desired an H-bridge driver chip like the TB6612FNG or older, more lossy L293D, L297 etc. can be used. Adapting an Arduino-type "Motor Shield" may be an option.
- I want to run a stepper motor
Weak motors can be driven with an H-bridge, moderate power ones 3d-printer type "Poluluo" style driver modules, higher power ones with industrial type drives (Geckodrive, etc). Keep in mind that stepper motors consume lots of power when kept on to hold position. If turned off, or if subjected to torque beyond what they can resist, the MCU will have no way of knowing their position.
- I want to run a hobby servo
Most of the MCUs we are considering can product a pulse width modulated output to a servo. We may need to boost to closer to 5v. Servos will consume substantial power even when not moving, so we may want to use something like an RT9701 to enable power to them. Our firmware could have a configurable rule for how long to leave their power on.
- I want to run a strip of addressable LED lights
This should be possible, but TTN is probably most appropriate for switching between pre-configured patterns stored on the node - actually downloading the pattern would use too much network bandwidth. LED lights typically require a 5v output logic signal, some clever timing, and local pattern storage (if it is a data- rather than program- based pattern). Utlimately that can all be implemented on the node board itself, but in the first version it may be simplest to have the node board communicate with another MCU that drives the LEDs (also avoids any chance of the LEDs blinking when the radio is active, something that could otherwise require care to avoid)