About Us

Products: Custom Development Path

Custom development storyboard; illustration based on true events.

The phases:

To conclude the study, we give a summary, and underline pivotal points.

Day 0

From: cto@fifih.com
To: enq_newprojects@olsonet.com
Subject: enquiry


I’d like to introduce Firefighters Helpers Inc. and the project we’re seeking proposals for.

At www.fifih.com, we provide expertise, materials, systems and services to help with fire prevention and fighting. We have designed, and manufacture several devices built around MSP430F148. In some of them, we use RF links, via CC1000. We put together a prototype of the device with these two components, plus several sensors connected via digital and analog IO ports. This is the hardware context we are set in.

We’d like to enquire about a custom built system with the following characteristics and requirements:

- Unpredictable topology, with some mobility after a deployment.
- Low hundreds to low thousands nodes in a network.
- High redundancy is a must, high and uneven node distribution is typical.
- Several networks must be able to operate without interference (on different channels).
- Narrowband communication, in overwhelming majority directed at a few sink nodes placed on the deployed network’s perimeter.
- Battery powered, expected lifetime on 1 cell is 1 year.
- Rough differential location awareness is desirable.

I am looking forward to your response,

Jack Sparrow, CTO
FiFih Inc.

Day 2

From: fifih@olsonet.com
To: cto@fifih.com
Subject: Re: enquiry

Dear Jack,

Dedicated mailbox for our correspondence is fifih@olsonet.com, and I’ll be personally responding to your mail.

To fit your requirements into one of our blueprints, we need additional information:

1. A typical configuration and deployment scenarios, e.g.:

  • Do you want to reconfigure the nodes (change their attributes) after their physical deployment?
  • Is the network configuration (i.e. configuration of all nodes forming the network) separated from the network operations? If so, can each node be configured with a local start trigger (e.g. a timer, daylight sensor, etc.)?

2. Are the multiple sinks meant for redundancy, or network partitioning?

3. What is an OSS (external) interface to the sinks? Do they have hardware resources different than the sensor nodes?

I believe that a narrative description of a typical application should answer all my questions.


Pawel Gburzynski, Chief Scientist
Olsonet Comms.

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.



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?



[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


  • 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:

  • PicOS (customized IO)

  • VNETI (customized)

  • TARP (optimized for up to 3 sinks, 12 hops maximum range, fuzzy acks)

  • Inferno praxis


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.


  • 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.