European Utility Week, Amsterdam Recap

Last week (October 3-5) DSR took part in the European Utility Week in Amsterdam. European Utility week is the premier business, innovation and information event that connects utility community with network operators, vendors, consultants, and integrators covering the entire smart system value chain.

 

 

 

 

 

 

 

Together with Watt + Volt, the 3rd largest energy provider in Greece, DSR Corporation showcased its 4-times Gold Award for Utility Solutions (SmartWatt) at our shared booth. DSR is proud to be contributing to the success of SmartWatt by empowering the solution’s embedded software, mobiles apps and the hardware solution.

The event also showed a trend of utility companies moving towards analyzing smart metering data to enable them to provide advice and insights to their customers, enhancing the customer experience and delivering a more complete package of services for the modern day energy consumer. However, there still appears to be a large fragmentation of metering protocols and different standards in the European energy market. As the solution providers are continuing to work on unifying the market, the trends towards utility companies becoming more of lifestyle providers are evident.

Would you like to learn more about DSR Corporation, utility trends or Zigbee? Get in touch with us via e-mail: contact@dsr-corporation.com

#EUW17 #DSR Corporation #IoT #DSR ZigBee

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

8 Things to Know Before Choosing a Contract Software Developer

Introduction: Balance = Profitability

To operate profitably in today’s economy successful businesses must balance market conditions with product/project opportunities and available development resources.

Many companies attempt to achieve this balance using contract software developers—some realizing more success than others.

This white paper identifies eight things successful companies consider when choosing a contract software development partner. Understanding them can mean the difference between profit and loss—and between your project’s success and failure.

1. Successful Contract Software Developers Have (and Hit) a Schedule

If you’re investigating a contract software developer, your project probably already has some schedule risk. If you miss your schedule, you fail. Turning over development to a contract software developer who can’t answer schedule questions is a sure-fire recipe for you missing your schedule.

So, choose a contractor who asks you lots of detailed questions about your schedule and deliverables before taking the job. Then, you ask them about the tools they use to plan development work and allocate developer resources. Ask to see those tools with live data from a current project. Look for how detailed those plans are. Since you will often be paying by the hour, the tools the developer uses should provide scheduling and resource usage to the hour.

If they have this, they will likely hit your dates.

2. Successful Contract Software Developers Commit to Your Budget Requirements

Companies large and small have been victims of “outsourcing hype”—the promise of cheap engineering at a fraction of the cost of hiring and using your own employees. While the hourly rates were low, the number of hours spiraled out of control. The result—“outsourced” projects come back (too often significantly) over budget, and late as well.

When your budget can’t slip, and you can’t afford any surprises, look for a contract software developer who can bid the work in a way that meets your budget requirements. Three common ways to have them bid the project are:

  • Fixed hourly rate
  • Time and materials rate
  • Fixed price bid

If you have clearly defined requirements, a competent contract software developer can make one or more of these methods work for you and your budget. However, if you need assistance in defining the software requirements, ensure that the contractor you choose is experienced (and can provide examples and references) to assist you in requirements definition stage of your project as well.

Also, make sure the developer provides up-to-date time sheets. These are the best indicators that 1) the developer has sufficient resources working on the project, and 2) the developer is tracking to your budget requirements.

3. Successful Contract Software Developers Have Real-World Business Understanding

Talented contract programmers are a great asset; however, talent alone doesn’t guarantee your project will succeed in the marketplace. Experience in taking projects/products to market can be as important as the amount of technical competency possessed by a contract software developer. Knowing what works and what doesn’t work in the marketplace is an invaluable asset.

Look for a contract software developer with a track record of completed projects actually delivered to and used in the marketplace. Ask to see some up-and-running examples of live work done for other companies. This kind of portfolio is the best indicator the developer can bridge the understanding of their client’s business with the client’s project deliverables.

A developer who provides you with market experience-based feedback is a greater asset than one who simply agrees with you because you’re the client.

4. Successful Contract Software Developers do Quality Work (and Provide a Warranty)

It is rumored that US Government procurement people operate by an unwritten rule that purchasers expect at best to realize two of the following three attributes in buying a product or service:

  • Quality
  • Timely
  • Cheap

Because you already know you get what you pay for, applying this rule to contract software developers is simple: You want a quality product in a timely fashion.

Find out if the contract software developer operates the quality assurance (QA) function separate from the development function to test deliverables. Superior developers will even warrant their work and provide free bug fixes during the warranty period. A developer who is fearful of providing a warranty is a “red flag” from a quality-of work perspective.

5. Successful Contract Software Developers Provide Documented Deliverables

For companies that build their businesses on the backs of their software deliverables, few things are more frustrating than contract developers who deliver poorly documented (or undocumented) projects and source code.

Successful contract developers understand the need for accurate, readable, useable documentation. Ask for representative samples of:

  • Project requirements documents
  • Design documents
  • Fully commented source code
  • Test cases and methodologies
  • Project documentation
  • User training and help documents

This is vital for venture-funded companies, as these documents are essential in any exit or liquidity event.

6. Successful Contract Software Developers Keep You Informed on Your Project’s Status

Knowing where your project is at, and who you can talk to find out the details is critical to being successful when using contract software developers. It’s not a good sign when your contract developer keeps you in the dark about your project’s status. Direct access to project managers, programmers and QA staff can mean the difference between getting a question answered in five minutes or five days. If you’ve ever had to report that you “don’t know what’s going on with the contract programmers,” then you know what we’re talking about.

Clear communication using multiple means is a vital key to successfully working with contractors. See that the developer allows you to talk directly with the programmers, project managers and QA people. Find developers who share their code-developing tools with you so you can stay in-the-loop. Look for developers who offer multiple means of communication including:

  • Phone
  • Web conference
  • E-mail
  • Instant messaging
  • IP telephony
  • Web-based project management tools

These give you an added advantage and ensure collaboration when working with contractors and resources in multiple geographies and time zones, and will keep you in-the-know at every step along the way.

7. Successful Software Developers Protect Your Intellectual Property

A word to the wise: intellectual property (IP) ownership is one of those clauses that even the biggest companies forget to take care of. If you fail to do this, questions will almost certainly arise over what happens to the intellectual property (IP) or who has rights to it.

Another word to the wise: IP ownership conflicts are compounded when your contract software developer is incorporated in another country than your own.

Last word to the wise: Avoiding “open source” software licensure and IP entanglements is critical to protecting the value of your company’s IP in a technology sale, license or transfer to another company. You will be required to assure the buyer that your code is “clean” from an IP perspective.

From an IP ownership perspective, two of the biggest success factors for operating a contract software developer engagement are: 1) choosing a contract developer who assures you that what they develop for you is yours and yours alone; and, 2) choosing a contract developer incorporated in the same country as yours–and thus subject to the same laws as your company; and 3) choosing a contract developer with experience in delivering “clean” code free of any “open source” contamination. (You can lose your legal shirt on this one.)

These three factors will provide you with legal confidence and means of recourse that avoid the costs and difficulties associated with adjudication under US and international law.

8. Successful Software Developers Deliver Great Value for the Price

The one topic you’re guaranteed to discuss in every contract software developer engagement is price. Managing project headcount requirements by making additional labor costs a variable item rather than fixed item on the balance sheet is compelling to the people in your organization who count the money and manage profit and loss.

While this white paper has already raised multiple items to consider regarding budgets and pricing, the short answer is this: You get what you pay for. Low hourly rates are no assurance of a value-based engagement. If you do your part with clearly defined requirements (or find a contractor that is experienced in help you define your requirements to create a smart product), a successful contract software developer will deliver with high-predictability on those requirements.

Developers who deliver quality, timely software may cost a little more up front, but they’ll assure you have a solid deliverable in your hands by the deadline and will have delivered solid value for the dollars you spent.

Conclusion

Successfully using contract software developers to achieve your objectives doesn’t just happen. Companies who enjoy this success don’t do it on accident. Give your company a quick “self-diagnostic” and ask if your current contract software developers:

  1. Have (and Hit) a Schedule
  2. Commit to Your Budget Requirements
  3. Have Real-World Business Understanding
  4. Do Quality Work (and give a Warranty)
  5. Provide Documented Deliverables
  6. Keep You Informed on Your Project’s Status (Clear communication)
  7. Protect Your Intellectual Property
  8. Deliver Great Value for the Price

Find out today how DSR can help with you balance market conditions with product/project opportunities and available development resources. Contact us at contact@dsr-company.com.

The Real Reasons Behind Most ZigBee Interoperability Problems

Interoperability is a buzzword that we hear often when talking about wireless protocols, including ZigBee. Being an already trusted but still young standard, ZigBee itself can raise many questions when reading the official documentation. However, that is not the topic of this blog. With over a decade of experience in wireless communications software development and 7 years working closely with ZigBee, we have seen many cases where although the specification gives adequate description, developers invent their own bicycle. Our extensive experience integrating and working with a large number of sensors from different manufacturers provided us the valuable insight we are sharing in this blog.

The field where there is so much space for creativity and hence mistakes, is the application layer, when profiles join the game.

Let us start with one simple flag – “Manufacturer specific” flag in ZCL header, invalid usage of which may cause a variety of problems. The right way of using it is extending the functionality of ZCL (HA), adding attributes or whole clusters that are not provided officially. For example, we cannot guess, why “Temperature measurement” cluster has a “tolerance” attribute, while the “Humidity measurement” does not. It is about the fact that if you want “Tolerance” attribute in your humidity sensor, you need to make a manufacturer specific attribute. Or, in another example, let’s say you are working on a ZigBee-based pet tracking system. We promise there is no “Animal tracker” cluster in any specification. You will need to implement it yourself and, yes, it will be manufacturer-specific.

The common mistake of using this flag is marking general attributes and commands with it. We faced it while working with IAS sensors and made us wonder why the standard enrollment procedure needs any manufacturer code. Do developers really consider their manufacturer code safer from intruders than the entire ZigBee security system?

Anyway, it can be easily debugged, because the only thing we need to know in this case is the manufacturer code. There is a way to obtain it using only ZigBee tools: the code is placed into the node descriptor. If the node descriptor does not work, it can be requested from the manufacturer. And, when there are no contacts, ZigBee sniffer can help too. If there is a coordinator that the intended device successfully enrolls with, then with the proper enrollment procedure caught by the sniffer, we will get the code. Another way to achieve this is by writing any attribute in the intended cluster and probably getting the response with the code. Moreover, configuring and binding the intended cluster may cause some manufacturer-specific attribute to be reported with the code. So, they key is just to be patient.

This mistake may be worse when the device confuses ZDP discovery tools: for example, the cluster is not returned in a simple or match descriptor response, but some commands are supported and they are manufacturer-specific. In this case, discovery does not work and you will need either a technical contact or a lot of time to experiment.

In this case all we know is that the device in our hands is a ZigBee device and what it is used for. So we can predict its cluster list. The only thing we can do without manufacturer help is to send commands to the predicted cluster waiting for the response with some status.

The next issue has to do with attribute semantics misunderstanding. When the number of attributes exceeds two-three and cluster logic becomes complicated, this can lead to misunderstanding of an existing attribute’s meaning . Just imagine the situation when you try to set temperature on a thermostat but it is still too cold or hot in the room. Now we take this HVAC system and try to guess, which setpoint the “Setpoint Raise/Lower” command operates with? It depends on the command’s mode as well as current system’s mode. But some developers may like only one clear attribute and of course it will cut the existing logic. In this case, specification misunderstanding can even cause attribute duplication.

One of the last common problems has to do with a very useful HA extension – poll control. Even though it is strongly recommended to implement it, it is often ignored. However, real problems come, when the device has its own long poll interval that is much longer than the default one. If we leave the situation as is we will for sure have many packets lost for such a sleepy device. Therefore, we should increase the timeout for deleting expired indirect packets. This does come with a risk: if the interval is too high, the queue most likely will got overflowed. That is why when increasing the indirect queue timeout, updated coordinator should be tested in a large network with a lot of sleepy devices connected.

To close, we want to add a few words about the mistake that will not break interoperability, but can be frustrating and easily avoided. Unfortunately, as of today we do not have as many reportable attributes as we may want. And everybody who faces this problem solves it in his or her own way. We have seen “Write attributes” sent to the client cluster and even reports that were not configured. It is the only problem described here that can be attributed to by the lack of functionality in the official specifications. We are sure this will be addressed in one of the next updates. But we are sure that the devices that skip the configure/bind logic before sending reports will not disappear for many years.

We hope this blog gave enough examples to show that most interoperability problems at the application layer appear because of not completely understanding ZigBee Alliance documents. With the growth of ZigBee technology and the number of well-designed devices, such misunderstanding may make the product less competitive and supported. It is key to take time to understand and follow the standard to avoid these issues and ensure the success of your products.

Is IoT finally here? (CES 2015)

DSR has been a regular attendee and a recent exhibitor at CES. Every year there is a little bit of a familiar and a lot of new. With 170,000 attendees and thousands of innovative products in every possible market segment now or soon to be available for end user consumption, CES draws consumers and customers from around the globe. The world continues to evolve and CES highlights creative implementation of technology.

The general CES highlights included innovations in a variety of areas, from curved TVs to personal transporters to innovative wearables, CES was a sight to behold and spoke to every interest and gadget category imaginable. Check out Mashable’s Best of CES 2015 picks for additional highlights.

DSR was representing in the Sands Expo and it was all about IoT (Internet of Things). IoT market has been steadily growing every year and each year promising to be bigger than its predecessors. This year, the IoT (Internet of Things) market was very much on display. Lowes and Bosch were two companies with large full home automation solutions demonstrating the many advantages of the automated home.

Other IoT solution providers, including DSR, were showi2015-01-06-12.25.39-640x480ng the wide range of device (Gateway and Sensor) interoperability. DSR is a ZigBee Alliance member and had our demo set up at the ZigBee booth along with other alliance members.

Traffic was heavy and constant in the ZigBee area all four days of the show and we feel that ZigBee is continuing to pique interest and gain traction amongst wireless protocols and overall HA industry.

We observed the following general trends in the IoT area that will shape the market for the next several years:

  • There is a general consensus that IoT is finally mature enough to truly “take off.” The trend that was long time coming and brewing may finally be here and it is noticeable by the expanded interest from both the consumer and business sides.
  • There were more parties interested in commercial applications (lighting and elevators) than previous years, which is another indicator of the market growing up quickly.
  • In contrast to commercial applications that tend to be larger complex deployments, home owners are looking for small, easy to use full featured solutions. The emphasis in this area is really on the ease of use. This will be the deciding factor of why some solutions succeed and others fail.
  • With people really getting serious about deploying solutions, security is now a common question to address.
  • There is still concern and confusion related to the various IoT standards (ZWave, AllJoin, Home Kit and ZigBee).   People stated it was like the old VHS vs. Beta debate from the past.
  • Some of the common questions that we received at our booth were around the size of the ZigBee stack, number of devices (sensors) and their connectivity range both indoors and outdoors, cost and scalability of DSR IoT cloud, and consumer-facing mobile apps.

Overall, the show reinforced the decision made five years ago by DSR to be part of the IoT market and we are excited about IoT market growth and the opportunity to bring innovative products to market and put the control at homeowner’s fingertips.

DSR is truly a one-stop-shop in the IoT area with solutions for operators/service providers, for access point set-top-box manufacturers, IoT cloud platform vendors, or anyone looking for a complete IoT solution including hardware and software components. Contact us to learn more!

Resolving iPhone apps GPS accuracy problems

We have been creating mobile solutions for our customers for almost a decade. But with each project’s experience come interesting challenges. Recently, we developed an iPhone application that is now available in the Apple Store. It required us to determine a user’s location at various points using GPS. It turned out that in developing GPS-based mobile applications, the accuracy of the coordinates can vary. These inaccuracies appear on the screen as sudden jumps in a user’s location on the map and are especially visible if the application is trying to plot a route that the user is traveling. These inaccuracies are the result of not discarding bad coordinate points and not detecting fluctuation of points in a route.
In certain situations the CoreLocation framework can return points with incorrect coordinates. To deal with this issue, we developed the following criteria to determine that a point is invalid:
  • Object’s location is null
  • horizontalAccuracy < 0
  • Temporary marker of the new location has a value less than the value of the temporary marker of the previous location. This indicates that the LocationManager has returned locations in the wrong order.
  • New location’s temporary marker indicates that it was returned prior to starting the application because the CoreLocation framework caches points from the last time the GPS was used. This can create an undesirable result. For example, the user exits the GPS application, drives 40 miles, re-launches the GPS application, and the LocationManager returns the coordinate point that is off by 40 miles from the user’s current location.
In a situation where the signal is weak or the mobile device is on standby, the CoreLocation manager can return coordinate points that greatly vary from one another. To address this problem, we have applied specific filters (Kalman filter) and interpolation algorithms for detecting these false coordinates and smoothing out the points on the route. However, if you are building an application that requires you to know a user’s precise location without performing the additional analysis, you can use a shortcut that can significantly decrease the amount of inaccurate points – discard all points where horizontalAccuracy > 150 m.
Until next time, when we continue to share our experience in the mobile world!

The Importance of Project Estimations

We wanted to share our approach to project estimation based on our extensive experience on a variety of projects. Early project estimation is the key to proper project definition and communication with customers. It helps establish project attributes (such as cost, duration, resources, and tasks), set expectations, and ensure that all parties involved have the same understanding of the project objectives.

Estimation process is a difficult task for a variety of reasons, including over/under estimation, exclusion of risks, lack of requirements, failure to involve the experts, etc.

DSR’s project estimation is done at a WBS (work breakdown structure) level and each task is estimated down to an hour. Estimating at this level helps identify areas of potential concern and expose inconsistencies between the estimates and client’s expectations. Inconsistencies may exist either due to client’s lack of understanding of the underlying complexities or DSR’s incomplete understanding of a task. Resolving these types of issues early in the process decreases the overall project risk, increases the quality of the estimates, and creates a realistic representation of a project.

During the estimation process, we generally try to keep in contact with the customer as much as needed to get the necessary clarifications on tasks and customer’s expectations. This ensures that the scope of the project is set correctly and increases the quality of the estimates.

At DSR, estimates are always done by resource(s) with most experience in the given task type and are reviewed by other specialists in the company to ensure validity.  In addition, the estimation process goes through several iterations, which allows the customer and DSR to develop full understanding of the project and its execution, which contributes to the overall quality of the project delivery. Using previous projects’ performance and experience to refine the estimates increases the accuracy. Estimates are produced in three measures – optimistic, expected, and pessimistic. The final estimate is a combination of those measures taking into account the risk of each task.

All of these factors contribute to DSR’s project estimation process and deliver our customers quality information about the cost and duration of their projects.

A Tip for Better Video Optimization when Porting Android to New Hardware

Several Android porting projects we’ve been working on require video optimization.

Video performance issues are usually related to one of the following:

  • video drivers
  • OpenGL
  • codecs

The most recent video performance issue occurred because video displayed with a rate of 7 frames per second instead of 25 FPS (the way it should be).

After using a series of benchmark programs to isolate the problem cause, it became clear the video player was displaying frames with frequency based on the audio stream time. As soon as we changed the frame rate frequency based on system time, everything started working OK.

Of course, this partial fix is not the final solution since some side effects are possible, such as non-synchronized video and audio streams. Experience shows that troubleshooting such issues becomes the essential and significant part of Android porting projects.

Welcome to our blog!

Why a DSR Blog?

Why on earth would a contract software development company produce a blog? It’s a good question. People blog to share, to make money, or to feed their egos. Companies aren’t much different. Our company, DSR (Data Storage Research), isn’t much different either. That’s why we’re doing this—at least it’s a main reason why.

We’re blogging a several other reasons, too. Reasons like:

  • Keeping in touch with our customers, partners, and anyone else interested in the things we are working on and working towards.
  • Providing insight into our culture and experience. An open book is much better read.
  • Posting about the various projects we have going on, discussing the challenges we encounter along the way, and talking about the tools, techniques, and processes we use to overcome them.
  • Providing expert solutions and advice from our team’s knowledge and experience of our team. Common software development issues–both technical and process related—are interesting to explore in a blog format. (At least we think they are…)

This blog will let you get to know our team a little better and become a little more familiar with our culture. We’ve been around for about 12 years, and we use standard management and software development methodologies. Since DSR has extensive experience developing:

  • Web-based systems
  • Embedded systems applications
  • Enterprise databases
  • Device drivers
  • iPhone, BlackBerry, Android, Brew, Symbian applications

we believe this blog will provide you with an insider’s look at how this development work happens. We hope we all learn something along the journey.

“New knowledge is the most valuable commodity on earth. The more truth we have to work with, the richer we become.” – Kurt Vonnegut

What’s Next?

This conversation place starts mostly as a monologue, but will evolve to include more integrated methods of direct communication. Please share your comments, questions, and suggestions.

Thank you, and we look forward to getting to know you. Like they say in Russian:

Do vstrechi, druz’ia! (Until next time, friends!)