Blog Stats
  • Posts - 12
  • Articles - 0
  • Comments - 19
  • Trackbacks - 7

 

Thursday, October 26, 2006

Wanted: Software Engineer for a RFID Software Product

Overview
GlobeRanger is a leader in the RFID industry focused on creating software built for and used by designers, developers, testers and adminstrators of RFID solutions.

Position Overview

We need a passionate and creative software engineer to join our engineering ranks to help design and develop the next generation of iMotion, GlobeRanger's flagship product.  This position requires an open mind, strong technical skill and a propensity to learn and have fun.

 

Qualifications

  • You must love creating software that is sold to and used by passionate users.
  • You must love and know C# and .NET
  • You must enjoy collaborating with others, debating and representing ideas and working along side team members
  • We consider working knowledge of EPCglobal standards such as ALE, Gen2, EPCIS, TDS and LLRP a definite plus
  • We prefer a technical degree or equivalent experience

How To Apply
Check us out at www.globeranger.com and send your resume with a cover letter to careers@globeranger.com

 

 

 

 

Saturday, February 25, 2006

Daisy Brand Gains Operational Efficiencies with Solutions built on GlobeRanger’s iMotion Edgeware Platform

The Daisy Brand IS team is one of the best I had the privilege to be around. Read more about their solution:

Saturday, January 28, 2006

International Geek Song

This is simply awesome!

 http://www.wantonline.com/blog/index.cfm/2006/1/10/International-Geek-Song

 

5.1 patch

We are working on a patch that will include .Net 2.0 compatability and resolutions of issues found to date. A beta program for select partners is under consideration so a GA date has not been set in stone. I'll post on that as soon as it's set.

Saturday, January 14, 2006

Saturday, December 17, 2005

ALE Overview

Adam Sills recently published Application Level Events (ALE) In A Nutshell  which provides a good technical overview of ALE and how it manifests within iMotion. For those unfamiliar with ALE, it is a specification that was the first ratified software interface standard from EPCglobal.  It defines provisions for the collection, filtering, counting, grouping and reporting of EPC and, in GlobeRanger’s implementation of ALE, non-EPC data. Edge processes use ALE to dictate where to obtain data, establish the conditions under which data aggregation starts and stops, specify data filtering and formatting rules and pick a communication strategy to obtain reports. The primary benefits of ALE:

  • It enables the true separation of business logic from physical deployments
  • It allows deployment and application engineers to focus on their areas of expertise. iMotion, for example, allows deployment engineers to configure, monitor and manage the physical infrastructure through the EMC and EDM and enables application engineers to create, configure and monitor edge processes through the Event Workflow Editor and EPM.
  • Device and application infrastructure can scale independently. iMotion’s flexible architecture allows you to scale EDMs separately from EPMs to adjust to system loads.
  • Allows edge processes to be constructed once and subsequently deployed into many physical environments. This results in highly leverageable software assets that can be used across solution and product engagements.
  • Enables interoperability at the edge

Sunday, December 04, 2005

Part One - iMotion Encoding Adapters: Quick Review of EPCglobal's TDS

The Tag Data Standards (TDS) define how EPC values are encoded on tags as well as how they are encoded for use in external applications.  Each version of the TDS supports a set of identity types and establishes rules of representation for each of that identity type’s supported encodings. Highlights of the TDS versions supported out-of-the-box within iMotion 5.1:

TDS Version 1.24 Highlights

  • Targeted for use on Class 1 Gen1 tags.
  • 6 supported identity types: GID, GTIN, SSCC, GIAI, GRAI, GLN.
  • Supported tag encodings: 64-bit and 96-bit.
  • Filter values do not have a corresponding numeric value.
  • Some encoding schemes are incorrect.

TDS Version 1.27 Highlights

  • Targeted for use on Class 1 Gen1 tags.
  • 7 supported identity types: GID, GTIN, SSCC, GIAI, GRAI, GLN, DOD.
  • Supported tag encodings: 64-bit and 96 bit.
  • Some filter values are different than those defined in 1.24 (Some changes introduced in version 1.26).
  • Filter values are normative.
  • Inconsistencies found in 1.24 included although some addressed in previous TDS versions.

Additional TDS versions will be supported in iMotion through downloadable encoding adapters as those TDS versions are ratified. iMotion developers and users benefit from the following capability within each iMotion encoding adapter:

  • Users can easily create EPC values for tag emulations within the Device Emulator through a wizard-based dialog.
  • Users can easily create filter and group patterns for ALE specifications through a wizard based dialog.
  • Developers can easily encode and decode EPC values as well as create and process filter and group patterns through a powerful object oriented API.
  • Users and developers can choose among any of the supported TDS versions.

Friday, December 09, 2005

RFID Deployment Lesson: Photo Eye Calibration

There are conveyor application scenarios that require the detection of untagged or unread product in order to enable corrective action. These scenarios typically revolve around the verification of tags to ensure that they are properly placed and encoded. Using a photo eye and two simple business rules, this condition is inferable:

  • Business Rule #1: If the photo eye tripped and there was no tag detected within a configured period, then it can be inferred that there is an untagged or unreadable product on the conveyor.
  • Business Rule #2: If a photo eye is tripped and then tripped a second time without any tags being detected, then it can be inferred that the first product to trip the photo eye is untagged or unreadable.

These rules work perfectly so long the product that passes the photo eye breaks the beam just one time.  When the beam is broken more than once for a single item, business rule #2 takes effect and causes unexpected behavior. Unfortunately, this is not uncommon in deployment scenarios so here are a couple of gotchas and ways to mitigate them:

  • Reflective Photo Eyes with Reflective Material on Product
    • Problem: You are using a reflective photo eye that uses a mirror to detect beam breaks and have packages with reflective material such as clear tape or shrink- wrap that cause multiple physical beam breaks for a single item.
    • Steps to mitigate the problem: 
      • Physically adjust your photo eye’s sensitivity so that it is less sensitive to reflective material.
      • Use the Stable Set Interval within your B-ALE specification to smooth double detections.
      • If there is non-reflective material at a consistent height across all packages then consider adjusting the height of the photo eye mounts so that it misses the reflective material.
  • Irregular Shaped Product that Causes Multiple Beam Breaks
    • Problem: You have irregular shaped packages that cause multiple breaks for a single item.
    • Steps to mitigate the problem:
      • Use the Stable Set Interval within your B-ALE specification to smooth double detections.
      • If there are consistent solid sections of the package then consider adjusting the height of the photo eye mounts so that the photo eye is targeted at solid sections.

Saturday, December 03, 2005

Helloworld()

My name is Daniel Hernandez.  I currently work as a product development manager for iMotion, GlobeRanger's edgeware product. I'll use this blog to publish relevant iMotion and RFID content as a way to contribute to and enhance the experience of the growing GlobeRanger user community.

Disclaimer
The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts or opinions of my employer as it is solely my opinion. Any code samples are provided "AS IS" without warranty of any kind, either express or implied.

Tuesday, December 06, 2005

Part Two - iMotion Encoding Adapters: RFID Tag Encoding and Decoding

Overview

As noted in my previous post about iMotion Encoding Adapters, iMotion 5.1 introduced a new encoding library that allows developers to easily encode and decode EPC values as well as create and process tag filter and group patterns.  This new library improves upon the previous 5.0 library in three significant ways:

  • Introduces a feature rich object-oriented API that allows developers to interact with tags at various levels of abstraction.
  • Raises the status of RFID tags to strongly-typed first class citizens within applications.
  • Provides a framework for existing encodings as well as future TDS and non-TDS tag encodings.

Encoding Tags

To use the encoding library, applications must reference the Globeranger.Core.Tag and Globeranger.Core.Tag.Epc assemblies.  You can select both assemblies from the list of available assemblies within the Add Reference dialog in Visual Studio if iMotion 5.1 is installed. After adding the references, you will need to import namespaces the Globeranger.Core.Tag, Globeranger.Core.Tag.Epc and the one referring to the TDS version you wish to target. Within 5.1, you can choose either 1.24 or 1.27 but unless you are supporting legacy applications you should always use 1.27 by importing Globeranger.Core.Tag.Epc._1_27.   Your imported namespaces should look like:

using Globeranger.Core.Tag;

using Globeranger.Core.Tag.Epc;

using Globeranger.Core.Tag.Epc._1_27;

After importing your namespaces, select an identity type, bit-level encoding and a constructor option for your selected tag type.  As noted in my previous post, you can select from one of the seven supported identity types within TDS 1.27: GID, SGTIN, SSCC, GRAI, GIAI, SGLN and DOD.  Each identity type within TDS 1.27, outside of GID, supports two bit-level encodings so select from one of the following: 64-bit or 96-bit.  For tag type construction, you have two options: 1) supply the UCC identity value if the identity type supports one or 2) supply all the encoding scheme’s required field values. Your code should look similar to the following if you're constructing a SGTIN 96 bit tag:

//
//Option 1
//
SgtinFilter filter = SgtinFilter.StandardTradeItemGrouping;
string companyPrefix = "0037000";
string itemReference = "012345";
long serialNumber = 1;

Sgtin96BitTag tag = new Sgtin96BitTag(filter,companyPrefix,itemReference,serialNumber);

//
//Option 2
//
SgtinFilter filter = SgtinFilter.StandardTradeItemGrouping;
string eanUccGtin = "00037000123453";
int companyPrefixLength = 7;
long serialNumber = 1;

Sgtin96BitTag tag = new Sgtin96BitTag(filter,eanUccGtin,companyPrefixLength,serialNumber);

Once the tag type is constructed successfully, you can access that tag's field values through properties:

SgtinFilter filter = tag.Filter;
string companyPrefix = tag.CompanyPrefix;
string itemReference = tag.ItemReference;
long serialNumber = tag.SerialNumber;

You can also serialize the tag type to any of its supported representations by invoking conversion methods:

string hex = tag.ToHex();
string pureUri = tag.ToPureUri();
string tagUri = tag.ToTagUri();
string rawUri = tag.ToRaw();
string decimalUri = tag.ToDecimal();

And finally, you can extract the EAN UCC elements from a tag type that represents a UCC identity:

string  gtin = tag.ToEanUccIdentity();
string  eanUccItemReference = tag.ToEanUccItemReference();              

Decoding Tags

There will be scenarios within you RFID application that require you extract field values from an encoded tag. You can do this by constructing a strongly typed representation from any well-formed tag representation (i.e., Tag URI, Raw URI, Decimal and Hex) by using EpcTagCreator:

string hex = "30740242200C0E4000000001";  //Could be any tag representation format
EpcTagCreator creator = new EpcTagCreator();
ITag tag = creator.CreateTag(hex);

if(tag is Sgtin96BitTag){
      //Do something interesting with tag
}

Monday, December 05, 2005

Watch out for System.Threading.Timer on Windows 2003 SP1

About a month and a half ago, one of my guys worked with Microsoft to diagnose a problem within Windows 2003 SP1 which prevented timer events from being signaled under severe loads. Check out the knowledge base article here for an explanation: http://support.microsoft.com/?kbid=900822. I just ran into the same situation while deploying at a customer site so thought I'd post this to keep you from the pain of diagnosing this very tricky problem.  I strongly encourage everyone that plans on using iMotion or other applications that use System.Threading.Timer on a Windows 2003 Server SP1 machine to contact Microsoft to obtain the hot fix before deployment.

Note: If you're running iMotion on a Windows 2003 SP1 machine without the hot fix applied and are experiencing what appears to be dropped tags then you'll likely benefit from the hot fix so obtain it immediately.

Saturday, December 03, 2005

iMotion 5.1 Feature Snapshot

iMotion 5.1 is the latest significant release of GlobeRanger’s flagship product.  It brings to bear features categorized into five major design pillars:

  1. Improved Usability
  2. Improved Performance
  3. Improved Durability
  4. Standards Compliance
  5. Market Driven Requirements

Although the official product datasheet will provides a much more comprehensive and compelling description of each feature, a distilled list of features organized by category is listed below for brevity:

Major Usability Improvements

  • Consistent look-and-feel and user experience
  • Contextual descriptions to increase dialog intuitiveness
  • Object renaming support within the EMC
  • Object duplication support within the EMC for rapid configuration
  • Comprehensive multi-select support within the EMC for batch operations
  • Multi-project start and stop within the Device Emulator and Event Workflow Editor

Major Durability Improvements

  • General improvements to increase reliability
  • Automatic recovery support in ALE and B-ALE components to increase workflow resiliency

Major Performance Improvements

  • Faster EDM startup times
  • Dramatically improved EMC responsiveness
  • Faster EMC to EDM transaction response times
  • Reduced EDM working memory set
  • Reduced CPU utilization and smaller working memory set in the Device Emulator

Standards Compliance

  • Gen2
    • Updated reader adapters
    • Extended data support in ALE
    • Gen2 reader and tag emulation in the Device Emulator
  • ALE 1.0 with extensions
    • TDS 1.24 and 1.27 with plugin support for future encodings

Market Driven Requirements

  • Accessible according to the Microsoft Accessibility Design Guidelines to extend support for the hearing, vision, and physically impaired.
  • Globalized to enable use on non-English versions of Windows.
  • Encrypted EDM to EPM communications for secured communications.
  • RF control within reader controllers through binary device triggers.
  • Device Emulator SDK enhancements to support non-RFID devices and hardware.
  • Ability to modify Device Emulator control images at runtime.
  • Event Workflow Editor stencils for increased component portability and management
  • Additional ALE and BALE application components to support advanced deployments.
  • Event Monitor support for ALE Reports
 

 

Copyright © Daniel Hernandez