Day 5
|
From:
cto@fifih.com
To: fifih@olsonet.com
Subject: Re: enquiry
Dear Pawel,
Typical
application:
1.
The nodes are equipped with batteries and reset. They’re
supposed to be operational N minutes after reset.
N is common for all nodes in a network.
2.
They are deployed in an extreme environment, where
they’re supposed to operate for up to 2 weeks.
During this time, maintenance is impossible.
3.
Periodic status reports and alarms based on the IO
readings are to be sent to the sinks.
4.
Sinks send occasional queries about nodal status quo.
5.
Sinks connect via SPI to OSS running on an SBC.
6.
No partitioning; sinks are for redundancy, to maximize
probability that an alarm reaches at least one sink.
Also: some of the sensors readings are considered
emergencies, and should be delivered with higher priority,
resent, etc.
7.
Preferably, sink module is identical to the sensor
module, both in hardware and software. The difference
is in enclosures, and the functionality configured
for a given deployment.
Regards,
Jack
|
Day 7
|
From: fifih@olsonet.com
To: cto@fifih.com
Subject: Re: enquiry
Dear Jack,
We’re ready to demonstrate the functionality
on a few nodes with MSP430F1611 and CC1100. Alarms
are triggered by status change on a port (digital
or analog).
We would like to meet with you and your colleagues
in your offices in San Antonio, or in ours in Ottawa
or Edmonton. (From our past experience, the 1st visit
is optimal on your turf, as you can invite a larger
group, for the presentation.) FiFiH would pay for
hotel and reimburse our tickets. If we go, it’ll
be 2 people for 2-3 days.
Rough agenda:
- Inferno hopping sensors
demonstration;
- Presentation of PicOS, TARP, simulator, and praxis
blueprint concept;
- Business options: licensing, agreements
- Quo vadimus?
Regards,
Pawel
|
[FiFiH is a small
but reputable public company. We believe we are of
value they can both appreciate and afford, so we have
not asked for compensation for our efforts, so far.
If in doubts, we’d ask for a nominal fee, to
eliminate frivolous interrogations.]
Days 10-12
Details worked out.
Day 20-22
Visit at FiFiH Inc. in San Antonio.
Day 30
Definition phase
starts: Olsonet signs hardware
NDA, FiFiH signs software NDA.
Day 35
Olsonet receives detailed requirements, and several
modules and interface boards from FiFiH. Development
starts here, even if Definition
phase is not completed yet.
Day 50
Legal documents signed: Licences (source code, technology),
custom development agreement. This is also the 1st
“paying milestone”; 10% of the development
fee. Signing of statement
of works ends Definition phase.
Days 50-55
Requirements refinements (conference calls, emails).
Day 60-61
FiFiH visiting Ottawa.
Lower Inferno project conceived.
Day 70
Beta version and documentation delivered. End of
Development. 40% paid.
Day 70-80
Hardening phase
starts. Acceptance testing at
FiFiH.
Days 80-83
Closing seminar at FiFiH, sources delivered. 40%
paid.
Day 90
End of Hardening phase. 10% payment closes the project.
Day 99
Maintenance begins.
If software subscription agreement is signed, custom
updates, functional adjustments, improvements and
simulations are delivered every 6 months, or on demand.
Regardless, bug fixes are delivered as long as the
source code and technology licences are valid.
Here is the application:
Inferno hopping sensor
Hardware:
MSP430F1611
CC1100
Specialized temperature sensor
(interrupt-able GPIO1,
7-8, digital in/out)
Specialized air analyzer (GPIO3-5 digital in, GPIO6
analog in)
Reset circuit connected to interrupt-able GPIO 2
FiFiH mounting and enclosure (heat shield 5KdegC
/ 80degC, shock absorbers, crafted aerodynamics are
the core of the project’s feasibility)
Software based on RTag and NWatch blueprints:
Operations:
When flashed with firmware, the
node acquires a unique 32-bit serial number. Lower
16 bits form logical node id, with uniqueness enforced
at the network configuration phase.
Battery recharging and hard
resets are connector-less, performed within
an EM field in specialized devices, 250 units at a
time.
Hard reset / factory defaults:
The node cycles between low
power mode (LPM 3), and Active / LPM0
states. In LPM3 (deep sleep), the node stays comatose
for randomized 60 +/- 5 seconds, with ultra low power
consumption. In Active / LPM0, Rx is open and listen
before transmit (LBT) active, for 1 second
of silence in the "configuration channel",
to listen to a configuration message.
Configuration message contains several
threshold and timer values, as well as the network
id, and the RF channel. It is broadcast by a "custodian"
node connected via RS232 to a host running a housekeeping
OSS. A short handshake ensures unique node ids within
the network.
After successful configuration and handshaking, the
node writes the parameters to NVM (flash information
memory), and hibernates for a prescribed time. The
"custodian" ensures that the nodes will
wake up at the same time; configuration messages contain
its uptime, so the nodes can compensate for configurations
spread in time.
The nodes are deployed in forest
fire areas. Up to 5 sink nodes are deployed in fire
trucks, connected to hosts - gateways, which in turn
are connected to a command centre. At a command, sinks
start broadcast beacons with their node ids.
The field node wakes up and soft-resets,
to operate on the RF channel and with parameters read
from NVM. Rx stays ON, and microprocessor cycles only
between Active / LPM0.
The node responds to messages from the sink nodes,
periodically sends status messages, and sends alarm
messages according to the rules and sensor readings.
Status and alarm messages are reliable, i.e. retries
are sent to all configured sinks, until an acknowledgement
is received, or a configured number of retries exceeded.
Also, the node records extreme condition and extreme
deltas in conditions between its 1 hop neighbors.
The data are stored in a dedicated NVM page (smart
writes), and included in status messages.
Sink nodes pass the RSSI readings to their hosts
and command center; locations can be calculated according
to empirical calibration data, and a mapping to physical
terrain performed.
When the environment becomes extreme, the node
shuts itself off, and hibernates in configured
quanta, at short wakeups reading sensors and recording
extreme conditions. It stays in this state until temperature
drops below yet another prescribed level. Then, the
node sends out periodic "harvest"
messages, on several power levels, so it
can be triangulated with RSSI help, and harvested
after the fire.
Extreme readings from the shut-off periods are retrieved,
the outer shell retrofit, and the nodes switched off,
ready for a next deployment.
“Lower inferno” project conception
During discussions on wielding the praxis and networking
into an optimal application, it became apparent for
the field practitioners that a new type of a solution
is superior, if the environment meets certain criteria.
On our side, the new approach falls into the infrastructure
backed ad hoc network
paradigm, and Tags
and Pegs blueprint. A separate project
was born, and completed almost in parallel:
More expensive and heavily equipped nodes (Pegs)
are buried under ground (except antennas), to form
a well connected grid, over large areas being monitored,
this time not necessarily for fire fighting activities.
They're equipped with dual radios, and form self monitoring
groups (e.g. it is not possible to remove any, without
triggering an efficient and distributed alarm). Actual
sensing and measurements are done by sensors nodes
(Tags), but now most of the communication and data
is concentrated in the Pegs. The solution is more
expensive, but it adds attractive functionality that
was beyond reach in the previous approach. FiFiH is
in the process of patenting the method and apparatus.
Summary
FiFiH owns the solutions, and hardware rights.
Olsonet continues to own the blueprints, and
acquired additional pertinent experience.
Olsonet licenses its technology and source code
to FiFiH for $8 / 1-100K, $4 / 100K+ nodes, total
count running regardless of the application.
FiFiH is free to develop new applications, or
to ask for new custom development.
Total cost for the Inferno
hopping sensors custom development paid
to Olsonet was $150K. Lower
inferno had the same price tag.
Total cost of simulation and network models per
application was 40K (FiFiH was not interested in
licensing the simulator, as it is not interested
in maintaining the expertise needed to run it).
The risk was low, so the simulations were done afterwards,
on a FiFiH’s customer request.
Although the storyboard
is fictional, it illustrates our main
points:
The solution always improves the original requirements,
frequently beyond wildest expectations.
Custom development was done at cost (i.e. was
cheap); Olsonet deferred profits to the expected
licence payments.
We're looking forward to working with partners with
expertise in their field and realistic plans. The
co-operation may look very different; only sense and
reason must always apply.
