all | frequencies |
|
|
|
|
|
|
|
exhibits | applications |
---|---|---|---|---|---|---|---|---|---|---|
manuals | photos | labels |
app s | submitted / available | |||||||
---|---|---|---|---|---|---|---|---|
1 2 |
|
Manual | Users Manual | 574.96 KiB | October 03 2014 | |||
1 2 |
|
User Manual | Users Manual | 1.01 MiB | ||||
1 2 |
|
Internal Photos | Internal Photos | 353.82 KiB | ||||
1 2 |
|
External Photos | External Photos | 212.11 KiB | ||||
1 2 |
|
FCC ID Artwork | ID Label/Location Info | 49.89 KiB | October 03 2014 | |||
1 2 |
|
FCC ID Label Location | ID Label/Location Info | 419.44 KiB | October 03 2014 | |||
1 2 |
|
Label & Label Location | ID Label/Location Info | 181.39 KiB | ||||
1 2 |
|
Class 2 change request | Cover Letter(s) | 77.74 KiB | ||||
1 2 |
|
Confidentiality Request | Cover Letter(s) | 260.34 KiB | ||||
1 2 |
|
Letter of Agency | Attestation Statements | 163.02 KiB | ||||
1 2 | RF Exposure Info | |||||||
1 2 | Test Report | |||||||
1 2 | Test Setup Photos | |||||||
1 2 |
|
Drug Declaration | Attestation Statements | 101.14 KiB | October 03 2014 | |||
1 2 | Test Report | October 03 2014 | ||||||
1 2 | Test Setup Photos | October 03 2014 |
1 2 | Manual | Users Manual | 574.96 KiB | October 03 2014 |
System Installation Guide for v3.3 Software Release 685-0003-08 21st October 2012 Document Number:
Date:
The information disclosed herein is the exclusive property of ZBD Displays Ltd. and is not to be disclosed without the written consent of ZBD Displays Ltd. No part of this publication may be reproduced or transmitted in any form or by any means including electronic storage, reproduction, execution or transmission without the prior written consent of ZBD Displays Ltd. This document is intended for limited circulation. The information contained in this document is subject to change without written notice and should not be construed as a commitment by ZBD Displays Ltd. unless such commitment is expressly given in a covering document. Copyright ZBD Displays Ltd. (2012) 1 Scope This guide is intended to cover the following scenarios. An initial lab test system. A Proof of Concept (PoC) in a live store. A full trial in a live store. A full roll-out of EPOPS (Electronic Shelf Epops) technology. Project management is a key element of a successful deployment of all the above scenarios. The more time that is spent on creating a defining a project plan the more successful and quickly a system can be deployed. This guide is designed to take users through the essential steps that will allow EPOPS to be deployed effectively within a store environment, ensuring that the system is fully working and that all of the required tools are available to support the installation when its live. The solution is designed to be operational as a 24/7 solution which means it is always on and ready. The epops (epops) run in a low power mode when inactive. To facilitate the 24/7 operation it is necessary to ensure that all power saving modes (hibernation/standby etc) are disabled from the Bounce devices. The IT solution usually does backups and price file and image updates overnight. This guide focuses on the Bounce software version 3.3 release and above. The guide references the Bounce Enterprise Interface as a means to drive the label system using XML, this is one of ZBDs preferred methods to build a coherent, working solution. However there are many different methods that can be used to pass data to and from the Bounce system (i.e. OLeDB, direct API, also text based files). If you are creating a system that links to something different or which isnt referenced in the ZBD documentation then we recommend that you contact the ZBD Support Team support@zbdsolutions.com and discuss the requirements, it is possible that the idea may have already been implemented somewhere else!
2 Change History Date 24Feb2011 08Jul2011 08Feb2012 30Mar2012 06Aug2012 13Aug2012 21Oct2012 Version Author 02 03 04 05 06 07 08 PS PS DP DP AP GL AP Changes Updated for v3.0 software release Updated for v3.2 software and Ethernet Communicators Updated to add in Chiller deployment information Updated to reflect v3.3 software release Added Power Saving Mode conditions Added Appendix A Bounce Manager installation Minor changes to formatting Strictly Private & Confidential 2012 ZBD Displays Ltd Page 2 of 37 685-0003-08 3 Table of Contents 1 Scope ___________________________________________________________________ 2 2 Change History ___________________________________________________________ 2 3 Table of Contents __________________________________________________________ 3 4 System Overview __________________________________________________________ 5 4.1 Introduction ________________________________________________________________ 5 4.2 Overview Diagram ___________________________________________________________ 6 4.3 Bounce Architect ____________________________________________________________ 6 4.4 Processor ___________________________________________________________________ 7 4.5 Communicate _______________________________________________________________ 7 4.6 Manager ___________________________________________________________________ 8 4.7 Workflow __________________________________________________________________ 8 4.8 Step 1 Defining the Template Fields ___________________________________________ 9 Step 2 Template Creation ___________________________________________________ 10 4.9 Step 3 Product Data Acquisition ___________________________________________ 12 4.10 4.11 Step 4 Product Image Rendering ___________________________________________ 12 Step 5 Update EPOPS ____________________________________________________ 13 4.12 4.13 Step 6 Report Viewing ____________________________________________________ 13 5 External Documents - Caution ______________________________________________ 13 6 Project Delivery Observations _______________________________________________ 14 Project Initiation Project Management Project Plan ___________________________ 14 6.1 6.2 Technical Integration Specification ____________________________________________ 15 6.3 Fixtures and Fittings ________________________________________________________ 16 6.4 Ordering and Shipping ______________________________________________________ 16 6.5 Installation ________________________________________________________________ 16 6.6 Handover __________________________________________________________________ 17 7 Site Survey ______________________________________________________________ 17 7.1 Site Survey basics ___________________________________________________________ 17 7.2 RF Range testing and positioning the communicator ______________________________ 17 RF Range Test tool _______________________________________________________________ 17 RSSI scan ______________________________________________________________________ 17 Smaller format stores (approx. 5000 m2) ______________________________________________ 17 Larger format stores ______________________________________________________________ 17 Environmental considerations ______________________________________________________ 17 Note the position of the IT infrastructure ______________________________________________ 18 Fixtures and Fittings ________________________________________________________ 19 HL Display and Sitour. ____________________________________________________________ 19 EPOPS Angling ________________________________________________________________ 19 Ongoing Staff maintenance ________________________________________________________ 20 8 Training ________________________________________________________________ 20 7.2.1 7.2.2 7.2.3 7.2.4 7.2.5 7.2.6 7.3.1 7.3.2 7.3.3 7.3 Strictly Private & Confidential 2012 ZBD Displays Ltd Page 3 of 37 685-0003-08 13 11 10.1 10.2 10.3 12.1 12.2 12.3 11.1 11.2 11.3 9 Chiller label deployment _________________________________________________ 20 10 Communicator Positioning _______________________________________________ 21 USB Communicator _______________________________________________________ 21 Ethernet Communicator ___________________________________________________ 21 Positioning _______________________________________________________________ 22 Software Requirements, Setup and Installation _______________________________ 22 Documentation available ___________________________________________________ 22 Software Installation Clean Install __________________________________________ 23 Testing __________________________________________________________________ 24 12 Adding Epops to the Network _____________________________________________ 24 Adding epops step by step _________________________________________________ 24 Offsite configuration _______________________________________________________ 25 Synchronisation and Label Management ______________________________________ 25 12.3.1 Synchronisation _________________________________________________________________ 26 12.3.2 Network Management ____________________________________________________________ 26 12.3.3 Moving epops between stores/sites __________________________________________________ 26 Product Data Loading ___________________________________________________ 26 Enterprise Interface product data loading ___________________________________ 27 Other connection types _____________________________________________________ 27 Linking epops to Products ________________________________________________ 27 XML or Enterprise interface method _______________________________________ 28 ZBD Bounce Manager Product Assignment __________________________________ 28 Training and Procedures before handover ___________________________________ 29 Training _________________________________________________________________ 29 Procedures and handover __________________________________________________ 29 System Management ____________________________________________________ 30 Support Overview _______________________________________________________ 30 Store level diagnostics______________________________________________________ 30 17.1.1 Is the RF network working? ________________________________________________________ 31 17.1.2 Whats the status of the label? ______________________________________________________ 31 Partner / Support Level Diagnostics __________________________________________ 32 Enterprise Interface error logging ____________________________________________________ 32 17.2.1 Error logs ______________________________________________________________________ 33 17.2.2 17.2.3 System Management Tools ________________________________________________________ 33 17.2.4 Other ZBD Software Tools ________________________________________________________ 34 Summary______________________________________________________________ 35 18 19 Appendix A Bounce Manager installation __________________________________ 36 13.1 13.2 14.1 14.2 15.1 15.2 16 17 17.1 17.2 14 15 Strictly Private & Confidential 2012 ZBD Displays Ltd Page 4 of 37 685-0003-08 4 FCC Warning Statement (related to Epop Displays) These devices comply with Part 15 of the FCC Rules. Operation is subject to the following two conditions:
(1) This device may not cause harmful interference, and
(2) This device must accept any interference received, including interference that may cause undesired operation. This equipment complies with FCC radiation exposure limits set forth for an End users must follow the specific operating instructions for satisfying RF exposure This transmitter must not be co-located or operating in conjunction with any other uncontrolled environment. compliance. antenna or transmitter. Changes or modifications not expressly approved by the party responsible for compliance could void the user's authority to operate the equipment 5 System Overview An overview of the solution has been included to ensure that all parties involved in planning and implementing the system have a clear understanding of the basics. 5.1 Introduction The EPOPS is ZBDs electronic point of purchase (epop) display and is designed to replace and/or enhance retailers existing paper ticketing systems and promotional display systems. For an EPOPS system to work effectively the EPOPS must be linked into the retailers product data feeds and the bounce system needs to have access to the feeds that contain any information required to be displayed on an EPOPS. The bounce software suite is designed to provide a number of software modules and tools for defining the integration points between the customer data and the EPOPS. The software enables the development of image templates for simplifying the design of ticketing information and provides tools for defining rules that must be applied to the data feeds in order to ensure that the correct information is displayed on the EPOPS at the right time. The software also provides a network management layer for controlling the update of the EPOPS and recording auditing information that can be retrieved using the reporting module. The software consists of four core elements:
Product Communicate Description This product consists of a Microsoft .Net application that runs continuously on a server and is responsible for transmitting the appropriate product images to any EPOPS that have been assigned to the defined products. Communicate is responsible for providing the underlying communications structure for deploying a large number of EPOPS display devices. This product consists of a Microsoft .Net application that runs continuously on a server and uses the Policies and Collections defined within Architect to acquire the data when scheduled, perform the required transformations, determine what data has changed and render product images for those products whose data has changed. This product consists of a Microsoft .Net application that Processor Architect Strictly Private & Confidential 2012 ZBD Displays Ltd Page 5 of 37 685-0003-08 provides the means for a User to define the data sources for their product information, set up what to do with the data and create a schedule of when the data should be examined for changes. Architect also provides tools for defining EPOPS product image templates and for creating Collections of templates that will be used with the defined data set. The Policies and Collections that are created within Architect will then be used by Processor to generate images for the EPOPS displays. This product consists of a web application, written for the Microsoft ASP.Net web application framework, residing on an ASP.Net compatible web server. It provides all the tools required to manage a Bounce software installation via a Web interface. Manager 5.2 Overview Diagram 5.3 Bounce Architect Component Policy Architect
(Define data sources, transformations &
template fields) Description The Policy component consists of a Windows .Net application for defining the sources of data that will be used in acquiring the product information for the image generation process. Data transformation are also created and edited within Policy Architect. Transformations can be used when the format of the data in the acquired data sources needs to be changed or reformatted to represent what will be rendered in the product image. Any data changes (a trigger) result in new images being generated. Policy Architect provides a means to preview both the acquired data and the EPOPS images that will be created from the data. Any policies that are defined within the Policy Architect Strictly Private & Confidential 2012 ZBD Displays Ltd Page 6 of 37 685-0003-08 Template Architect
(Define image templates) application can be saved and imported into Bounce Processor as a configuration file. The Template component consists of a Windows .Net application for defining EPOPS image templates. A template defines the information that should be displayed on an EPOPS. It consists of a set of instructions detailing where and how data fields are rendered within the EPOPS image. Template Architect provides a template Design view alongside a Preview view. This allows the User to be able to see exactly how a product image (or set of product images) will be rendered from the product data set. Template Architect also allows the user to create a Collection of templates. This feature ensures that different templates can be used when rendering the data to handle products that may be on offer, or in a different product category that requires its own style. A Template Collection also includes templates for each of the different EPOPS types e.g. EPOPS 500 and EPOPS 300. Once a User has completed the design of their Template Collection it can then be saved and imported into Bounce Processor as a configuration file. Saved files can also be used by Policy Architect to preview the acquired data. 5.4 Processor Component Processor
(Acquire/Transform/Render) Description This component runs as a Service on a Windows OS machine and performs the function of acquiring the data (a trigger is a change in the data source) as defined in Architect. It then performs any required transformations and uses the acquired and transformed data to render a product image. For each product in the acquired data set a unique image will be generated using the specific template style defined within the data. Product images are created for each EPOPS type included in the Template Collection e.g. EPOPS500 (epop500), EPOPS300
(epop300). Once an image has been rendered it is then passed to the Communicate component for transmission to the EPOPS. An audit trail is kept of when the data is acquired and when any product images are created and sent to the Communicate component. 5.5 Communicate Component Communicate
(Transmit, Log) Description This component also runs as a service on a Windows OS machine and is responsible for managing the transmission of any product images delivered via Acquire/Transform/Render to the appropriate EPOPS units assigned to the product. Strictly Private & Confidential 2012 ZBD Displays Ltd Page 7 of 37 685-0003-08 When Communicate receives a product image update it will check to see if any EPOPS have been assigned to the product and then select the appropriate image for the specific EPOPS type and queue it for transmission e.g. if a product has both an EPOPS 500 and an EPOPS 300 assigned, then Communicate selects the EPOPS 500 image for transmission to the EPOPS 500 and the EPOPS 300 image for transmission to the EPOPS 300. Communicate manages the RF communications layer and will ensure transmissions are re-tried if failures occur due to RF noise etc. An audit trail is kept of all EPOPS communications, retries and failures. Description The Configuration component consists of a web application that enables Users to remotely configure and control the Bounce Processor product. Users will be able to stop and start the Processor service and update the Policy rules and Template Collections. The Reports component provides a web based application that enables the User to generate reports detailing when products, EPOPS etc. have been updated. Reports can also be generated of failed transmissions. 5.6 Manager Component Manager
(Configuration, Assign, Report) 5.7 Workflow The following diagram shows an overview of the workflow required to integrate a bounce system into a retail environment. There are 5 steps to complete a full integration. These are:
1. Use Policy Architect to set the data sources and define the Template Fields that will be used in creating the product images. Template Fields are derived either directly from the Product Data Fields in the imported data sources or from transformations on the Product Data Fields. 2. Use Template Architect to create a Collection of image templates for each EPOPS type and for each offer type using the Template Fields defined in step 1 Strictly Private & Confidential 2012 ZBD Displays Ltd Page 8 of 37 685-0003-08 Steps 1 & 2 often become an iterative process as the templates are developed. 3. Acquire the Data Values according to the transformation and policy rules defined in steps 1 & 2 4. Render the product images using the Data Values acquired in step 3 and the Template Collection defined in step 2. 5. Use Bounce Manager to view the updated statistics. 5.8 Step 1 Defining the Template Fields Product Data Fields Link Transformation Template Fields Price Db SKU Price Description
[PromoPrice] = [Price] * 0.8 Model Db SKU Brand Model SKU Stock Stock Db
[StockLevel] =
If [Stock] > 100 Then In Stock Else If [Stock] = 0 Then Out of Stock Else Low Stock Standard SKU Price PromoPrice Description Brand Model StockLevel Template Policy Rules Template Fields are created using Policy Architect. Definition of the Template Fields begins by determining all the different data sources that will be used to create them and registering these with the Policy Architect application. A data source can take any form and may consist of a simple comma separated value file, an Excel spreadsheet, an XML file, a bitmap image directory, an Access database or more complex transactional databases such as Oracle or Microsoft SQL Server. Once the data sources have been registered the user then defines the data tables and the Product Data Fields that contain the relevant product information to be used in creating the product images. Each of the data source tables registered to Policy Architect needs to be linked to at least one other table to enable Policy Architect to determine how to retrieve the correct Data Values from each of the tables to make a consistent data set. Normally each of the data source tables would be linked via the product ID as this is a unique identifier that would usually be consistent across multiple data sets. Strictly Private & Confidential 2012 ZBD Displays Ltd Page 9 of 37 685-0003-08 Once the user has registered all the data sources and linked the tables they can then concentrate on determining what fields to be retrieved from them in order to define the Template Fields. Obvious fields such as [SKU], [Price], and
[Description] etc. can normally be imported without the requirement to perform any transformations on the data as it is acquired. A special Template Field called [Template] must always be defined. This field contains the name of a Template Architect template that will be used by the Bounce Processor when creating the product image. Using Policy Architect the user is able to create new Template Fields by applying transformations to the Product Data Fields e.g. The user can create a new Template Field called [UnitPrice] that is calculated from the data sources by taking the [Price] and dividing it by the [UnitWeight]. Policy Architect is extremely powerful as it allows the user to combine the data source fields in many different ways to create new Template Fields for use by the Bounce Processor during rendering. Conditional fields can be created that enable the renderer to determine whether to show information on the display e.g. If the word vegetarian is found in the [SpecialConsiderations] data source field Policy Architect can create a Template Field called
[Vegetarian] and set it to TRUE. Within Template Architect you could then create a template that would act on this Template Field and add the text Suitable for vegetarians or place a vegetarian icon on the display if this field is not NULL. In the example above the [Template] field has been set to Standard, but a transformation could be applied to one or more of the Product Data Fields to select different templates based on the data in the sources e.g. If [PromoPrice] is non-zero then set the [Template]
Product Data Value to Promotional else set to Standard. Once the user has created their initial set of Template Fields it is time to move on to the next step: Template Creation. 5.9 Step 2 Template Creation Strictly Private & Confidential 2012 ZBD Displays Ltd Page 10 of 37 685-0003-08 Templates are created using a Template Architect. In this stage the user creates a Collection of image templates for each of the EPOPS types and for promotions or special offers etc. A template is a list of instructions for the Bounce Processor renderer detailing what Template Fields, background images and icons to place in an EPOPS image and what attributes, such as font style, to use when rendering the Data Values held by the Template Fields on to the image. Template Architect provides a graphical user interface for defining where and how the Template Fields should be rendered within the product image. Using the GUI the user can select a Template Field and define the area on the EPOPS display that the values contained in the Template Field should be rendered. A selection of field attributes is also available so that the user can apply different fonts, font styles, font sizes etc. The Template Field objects can be inverted to display white on black or the object can be set to auto fit within a bounding rectangle defined by the user. The user can apply conditions to Template Field objects based on the Data Value contained in the field. When a condition is applied the object will only be rendered on the EPOPS display if the condition evaluates True at the time of rendering the image. The user can place Template Fields into a group having its own bounding rectangle and apply group attributes e.g. the user may apply the [Description]
and [Ingredients] Template Fields into a group and set the CentredVertical attribute. This would cause the renderer to combine the [Description] and
[Ingredients] Data Values into a single object that it would then render around a vertical line central to the group bounding rectangle. Static text objects and basic line drawing objects can also be applied to a template. Users can also import their own background bitmap images into the template providing the ability for creating a consistent graphical look and feel of an EPOPS image. Graphics libraries are also provided for the user to map Template Fields to graphical images that will be rendered in place of the text contained in the field i.e. the user can associate a vegetarian graphic icon to the [Vegetarian]
Template Field and the renderer would apply this icon to a specific location for every product where the Data Value is True. The user may end up iterating between this and the previous step during template creation as they may decide to create new Template Fields or make use of different data source fields in the template. Once the user has created a Collection of templates to accommodate the different EPOPS types they can then move on to define the scheduling rules that will be applied to the bounce system. Strictly Private & Confidential 2012 ZBD Displays Ltd Page 11 of 37 685-0003-08 5.10 Step 3 Product Data Acquisition Product data acquisition is triggered when the data is presented to Bounce. Once the data is presented bounce Processor will use the Product Data Definition rules set up using Policy Architect in step 1 to retrieve the data from the relevant data sources, apply the data transformations and create a local copy of the transformed data. The acquired data is referred to as the Data Values and consists of a table of data with a row for each product. Each row contains data values for each of the Template Fields. The table of Data Values are then used by bounce Processor as the data source for the renderer to create the product images that it will sent to bounce Communicate for transmission to the appropriate EPOPS. Data acquisition can occur completely independent of any of the subsequent steps and is merely the means of creating the data set that can be used within bounce. 5.11 Step 4 Product Image Rendering Product image rendering occurs within Bounce Processor upon receipt of the data . Bounce Processor will use the Data Values and the Template Collection file to create new product images for each of the products that have changed according to the defined scheduling policies. A new product image will be generated for each of the different EPOPS types supported in the Template Definition File. Strictly Private & Confidential 2012 ZBD Displays Ltd Page 12 of 37 685-0003-08 5.12 Step 5 Update EPOPS Bounce Communicate queues EPOPS image updates whenever the renderer generates a new product image in Step 4. 1. All newly rendered product images are delivered to Bounce Communicate as soon as they have been created and will commence to transmit the images to the epops Bounce Communicate keeps an audit log of all transaction requests. All updates and their status are logged for future retrieval using Report Manager. 5.13 Step 6 Report Viewing The Report Manager component of Bounce provides a means for the user to view status and statistical information about the EPOPS system. All actions that are performed by Bounce are logged and reporter provides a means to view those actions in a number of different ways:
The user can get a summary of the last 7 days transactions. The user can view what updates occurred to a particular product over a specified period of time. The user can view what updates occurred on a specific date or within a specified time frame. 6 External Documents - Caution References to external documents are made throughout and shown as
[Document Class - Reference number (Title)] so for example 530-0027-xx
(Batch Configuration Tool). There will also be a version number for each document (-xx). Please check that you have the most recent versions of each document before using it. These documents are likely to change on a regular basis so it is worth checking with ZBD support before beginning a major project that you have the latest versions. Strictly Private & Confidential 2012 ZBD Displays Ltd Page 13 of 37 685-0003-08 7 Project Delivery Observations Delivering a solution and getting it installed can be broken down into a number of phases. Each has its own challenges and some of the major ones are explained here so that the project manager can anticipate them and help manage the customers expectations. 7.1 Project Initiation Project Management Project Plan You should use the information below to thoroughly plan all the stages of the project. Each new customer will have unique issues which need to be understood and mapped to a new project document. This document provides the basic plan which you can expand to cover all aspects of what will be required to provide a successful solution. The Project Plan should contain all aspects of the Project and allocation of the required time to complete and who is responsible for completing. Key elements will be as follows:-
Initial meeting to assess what is required and also timescales for the complete project and the important when is it required by? Until you have mapped out all the requirements and assessed the time required to achieve them, you will not know if it is possible to achieve a target date. Define Data feeds from Company Company to provide current paper label samples Confirm epop Quantity/Type Confirm Pilot Store Provide Store Plan and internal pictures of store. Provide an example data file for pilot store Agree system architecture for Pilot Store ZBD EPOPS solution training Host server configured Delivery of lab demo kit ZBD solution on site training Backup solution testing Label/epop Assignment Confirm assignment method Develop label/epop assignment method - Company Test label assignment Change Control Approval Technical Development Mock up (label/epop layout with all required fields) Mock up complete Mirror Mock-up Environment in-house at Partner/ZBD Test end-to-end integration Generate Policy/Templates Sign off Template design Implementation Planning Order Epops/epops Order Shelf Edge Strip/Epops Stands Details of Pilot Store Work Program Date of system installation Confirm data content for F&V product (country of origin?) RF site survey of Pilot store RF site survey report Project Leader Holidays (make sure any absence is planned for) Install Data/Power into Pilot store Strictly Private & Confidential 2012 ZBD Displays Ltd Page 14 of 37 685-0003-08 Install Bounce Software
"install 'products', template & policy onto lab system"
"Deliver~18,000 epops to store"
Installation Pre-Installation Testing Deliver qtyxxx epop50 to labo Configure epops -qtyxxx Lab_Pre-Installation Testing - Mini Pilot Move labo server +ethernet comm +xxx epop50's to Pilot store PC hardware installed Test System with live data Fixtures installed Shelf Edge Installed Company Staff Training - store deployment Backup solution for trial store - testing Drop dead date for install Support Requirements - Pilot setup Weekly Support Meeting Support Requirements - Live store Weekly Support Meeting 3month Pilot Weekly KPI assessment
"Configure epops - ~18,000"
Install Epops/epops and assign to products Installation complete A typical Project Plan will look something like the diagram below. 7.2 Technical Integration Specification This should cover the detail needed to build the solution core data, structure, what are the schema files, folder structures, and processes that the system is going to manage?
This document should form the blueprint as to how the system is supposed to function. More importantly this is the specification document that all parties Strictly Private & Confidential 2012 ZBD Displays Ltd Page 15 of 37 685-0003-08 need to agree to before proceeding as the specification needs to be tied down very early in any project. If you do not do this you will be forever changing and developing the solution at your own cost. 7.3 Fixtures and Fittings We must stress the impact that fixtures and fittings can have on the delivery timescale, costs and overall success of any shelf label project. The minimum time we would suggest allowing for delivery of fixtures is 4 weeks if they happen to be readily available from a supplier such as HL. Having custom fixtures designed, tooled and produced could easily stretch into 24 weeks for challenging environments or shapes. Creating a multi-cavity tool that may be needed to press 100K fixtures is also an expensive process. It is also worth stressing that fixtures have a big impact on how the epops look in the store. EPOPS rely on passive light reflection for good readability so not dealing with this issue will have a negative effect on customers and lead to less than positive feedback. 7.4 Ordering and Shipping From a standing start (i.e. without forecasts) the lead-time for components up until finished production units being available is 18 weeks. On this basis its very important to place orders and plan the implementation schedule as far in advance as possible. Shipping product by surface (ship) rather than by air is our recommended option. Airfreight is very expensive, needs close tracking and must have correct import paperwork and documentation to minimise customs delays. 7.5 Installation Walking into a busy store (or even one that is still being built) to install electronic epops can be a stressful event for staff and the installation team. We recommend completing as many steps as possible off site, in advance before going near the store to make the installation process run smoothly Is the store/manager aware that youll be there?
Do they know what theyre expected to do?
Have Ethernet/power points been installed as requested?
Is someone contactable on the customer side if theres a data issue?
If it looks like everything will be ready and the installation will happen then we also recommend creating a task list for the day which details what needs to happen when and who is responsible for that tasks completion. This will mean everyone should know what theyre doing. No-one wastes time and people can follow a plan, rather than having to keep all the steps in their heads. Following a written task list reduces risks, leads to fewer errors and should avoid needing to make repeat visits to fix issues. Task RT Test label area Photograph store Photograph fixtures Check power connectivity Notes
(make sure enough readings are taken)
(capture any unusual aspects in the store)
(Capture all types including chillers etc)
(24 hour required, UPS (Uninterruptable Power Supply) Strictly Private & Confidential 2012 ZBD Displays Ltd Page 16 of 37 685-0003-08 Check network access
(Switch port available, cabling type) 7.6 Handover Once everything has been installed it is essential to check that all store operatives have received adequate training. Leaving this activity too late may impact any KPI measurements for the project. See section 8 It is possible that store layouts may change after the installation has been completed that could adversely affect the RF characteristics of the system, it is therefore important that the original installation details are retained by the implementation team to allow easier identification of the changes and to propose corrective actions. 8 Site Survey Doing a site survey is absolutely necessary to avoid running into problems when doing the actual installation. This needs to include looking at fixtures and fittings as well as the RF characteristics of the environment to site the communicator properly. 8.1 Site Survey basics Get as much detail about the site in advance. Site Layout plan (map) Site Name, full postal address Contact details of store managers Attendees Create a plan for the site survey before visiting the site 8.2 RF Range testing and positioning the communicator 8.2.1 RF Range Test tool The RF Range Test tool will be made available to partners please ask for copies of this from ZBD Support [Document 530-0025]
8.2.2 RSSI scan A document explaining how to do an RSSI scan for conflicting RF noise will be made available to partners please ask for copies of this from ZBD support [Document 530-0024]
8.2.3 Smaller format stores (approx. 5000 m2) If its not a particularly large store or contains less than 7,000 items then one communicator might be enough, unless the store is an unusual shape or has unusual RF characteristics. In all cases an RF range test should still be carried out. 8.2.4 Larger format stores Most shops will require a multiple communicator system and it is mandatory that a full RF survey is conducted to confirm the best placement of communicators to ensure full RF coverage throughout the store and of course this applies to multi-level stores. 8.2.5 Environmental considerations What departments and product types are going to be labelled?
Proposed location and orientation of the Communicator(s) Strictly Private & Confidential 2012 ZBD Displays Ltd Page 17 of 37 685-0003-08 Ceiling Height, type [demountable, solid concrete, wood, asbestos etc]
Fixture construction/height [steel, wood, 1.2Metres/1.8 Metres etc]
Size/shape of coverage area [Rectangular, L shaped, 48M x 71M etc]
Ceiling infrastructure [traywork/H&V etc]
Features such as low ceilings, traywork carrying high power cables, wooden shelves and high metal shelves can have a negative effect on the RF range. Maybe some epops will need a few retries to receive price updates moving the communicator around to find the optimum position is worth taking time over. To help troubleshoot any technical issues that arise later its mandatory to have a map of the store that details the products and departments in each section, this will assist in diagnosing any issues that the store may report post-installation. Standard (0-40) Freezer Department Medicines Mens Health Nail & Accesories Nails Oils Prepared Meals Toys & Gifts etc. EPOPS50 350 250 500 150 200 400 EPOPS300 EPOPS500 750 500 Y Y Y Y Y Y Medicines Health Products Nails Oils Prepared Meals Toys Y Try to link EPOPS required to map locations 8.2.6 Note the position of the IT infrastructure IP Addressing requirements [allocated IP addresses for Bounce devices]
Connectivity [Ethernet Category, RF etc]
PC locations [inc new Bounce PC]
Communications Cabinet Switch/Patch capacity for Bounce devices Make sure the customers IT team or contractor is aware if new power or network points need to be installed. Strictly Private & Confidential 2012 ZBD Displays Ltd Page 18 of 37 685-0003-08 8.3 Fixtures and Fittings 8.3.1 HL Display and Sitour. ZBD EPOPS are supported by shelf-edging and other in-store fixings available from several manufacturers, including HL Display and Sitour. Fixing options include:
Standard shelf edging Shelf edging covers Bumper strips Hook item holders Hanging displays (peg hooks) Stands (e.g. for Delicatessen) Clamp fixings Full details of all products available are defined in the ZBD Fixtures &
Fittings Guide which is available from your ZBD Account Manager. NOTE: lead-time for some fixtures & fittings can be protracted. These requirements should be addressed at the beginning of the project to ensure delivery does not impact the implementation plan. 8.3.2 EPOPS Angling ZBD Displays are based on reflective LCD technology. This means that the overall readability of the screens can be affected by their positioning (relative to light sources) within stores. It is most important therefore that the angling of display is set properly for consumers. IMPORTANT NOTE: It is essential that the correct angling of EPOPS is considered in determining shelf-edging, and some other fixtures. Proposed fixings must be tested in-store to confirm acceptability with the client. Spacers to adjust angling, as well as options for reverse angling (for high shelves) are also available through ZBDs Fixtures & Fittings partners. Above 2M: 15o Negative Above 2M: 15o Negative 1M 2M: Neutral 1M 2M: Neutral Below 1M: 15o Positive Below 1M: 15o Positive Bottom ledge: 45o Bottom ledge: 45o
(should be protected
(should be protected by Bumper Bar) by Bumper Bar) Strictly Private & Confidential 2012 ZBD Displays Ltd Page 19 of 37 685-0003-08 Whatever system is selected EPOPS must be held firmly by the fixture and this can be done in a number of different ways. 8.3.3 Ongoing Staff maintenance Staff in-store should take responsibility for checking that ticket-edging is in place and correctly positioned. The implementer should ensure that staff have access to replacement fixtures & fittings, as well as access to services should the re-installation of units be required. 9 Training It is very important to ensure all levels of staff are adequately trained in the continued use of an EPOPS system. Store processes and procedures are key to ensuring compliance with local laws on pricing accuracy, labelling information
(e.g. country of origin) and general business trading best practises. All partners must train people at the various levels required during the deployment. Remember as a partner you are providing the second level of support and the customer is providing the initial first level of support. Customers must be shown how to maintain an EPOPS system in full functionality. A system Health Check should be performed Daily, Weekly, Monthly. It is important to take action with any issues that are flagged during a Health Check. Failure to do so will mean the system gradual becomes bogged down with issues that have not been addressed in a timely fashion. Any failing epops need to be investigated to ascertain if the epop is in the store (it may have been removed) and will not be communicating. Adequate training might be what determines a successful outcome to any KPIs that have been defined by the customer. Please ensure you provide adequate training for the solution. 10 Chiller label deployment It is very important to understand some basic principles with regard to the deployment of epops (epops) into a Chiller environment (temperature controlled fridges that are below 10degC). All epops will usually be configured in a normal ambient room temperature environment (~20degC but could be as high as ~30degC). Once they have been configured onto a system, they can then be placed into a chiller unit. It is extremely important that all the epops (epops) are allowed time to thermally stabilise at the new colder temperature before any image updates are carried out. It is essential to allow 45mins for the epops to reach thermal equilibrium before sending images to the epops. Failure to wait for thermal equilibrium will result in a display which is blackened or smudged, (contains black shadows) and the text/graphics will be hard if not impossible to read. Please note that the same thermal equilibrium time applies to moving a label
(epop) from a Chiller into a normal ambient temperature zone. Strictly Private & Confidential 2012 ZBD Displays Ltd Page 20 of 37 685-0003-08 11 Communicator Positioning Determining the installation positions of Bounce communicator(s) into a site should be carried out by ZBD or approved installers following a full RF survey of the intended site. Documents are available detailing the Site Survey approach for single and multiple Communicator installation:
530-0040-xx (Site Survey Guide) 530-0049-xx (Multi-Communicator RF Survey) ZBD manufacture 2 types of Bounce Communicator:
USB connected Communicator Ethernet connected Communicator Communicators are not auto-detected by the bounce software. You must use the Communicators tab in Bounce Manager to make the system aware of Ethernet communicators or additional USB communicators. These are not plug and play devices. Bounce Software should be loaded before any hardware is added to the system. 11.1 USB Communicator The USB Bounce Communicator is limited to a maximum permitted cable length connection of 5 metres. Note that if a cable longer than 5Metres is used then it will not function correctly and will not be supported by ZBD. In most cases the Communicator would need to be mounted in a central location above the sales floor and would be further than 5metres away from the PC. As such the only practical answer is to use the Ethernet Communicator. The USB communicator is best used as a back office configure and update device for ongoing store operations, or for sales demos and support purposes. 11.2 Ethernet Communicator The Ethernet Bounce Communicator is connected directly to the Ethernet network within a site, the device supports Power-over-Ethernet (PoE) or an external power supply. If multiple units are to be deployed it is essential that all devices, including the Bounce PC are all on the same network segment
(e.g. 192.168.200.xxx), this will alleviate any network issues. The Ethernet unit is mounted with the aerial in the upward direction. bou nce Strictly Private & Confidential 2012 ZBD Displays Ltd Page 21 of 37 685-0003-08 Detail of Ethernet Communicator in bracket 11.3 Positioning The Bounce Communicator should ideally be located in a central position in the area that the epops will be located, ideally the position should be at height of at least 2.5 metres above the floor level and have no metal obstructions within 2 metres to the front, rear and sides. ZBD can provide an off-the-shelf bracket to mount the Communicator in a variety of positions, and also offer extension brackets if required. See diagram below You should make sure that the power can be cycled from the IT room so you do not need a ladder to physically disconnect the Ethernet communicator. This could be a physical mains switch if the Ethernet communicators are powered or the ability to remove the Ethernet PoE cables. The orientation of the Communicator should be as detailed in any Site Survey documentation produced as this could affect coverage in larger sized operations. Bounce Holder Bounce Wall Bracket 12 Software Requirements, Setup and Installation 12.1 Documentation available As part of the overall project management process, the setup of the system should be detailed in the Technical Specification. Due to the greater flexibility available our recommendation is that the solution runs based on the Enterprise Interface [550-0009-xx]
The Bounce Software suite is available on the ZBD FTP (ftp.zbd.co.uk) site and can be downloaded and installed onto a number of platforms. The Bounce System Software fully supports the following Windows host operating systems. Windows XP Professional (SP3 or higher) - (32bit) Windows Vista Business Edition (SP2 or higher) - (32bit) Windows 7 Professional Edition (SP1 or higher) - (32bit & 64bit) Windows Server 2003 R2 (SP1 or higher) (32bit) Strictly Private & Confidential 2012 ZBD Displays Ltd Page 22 of 37 685-0003-08 Windows Server 2008 R2 (SP1 or higher) (32bit & 64bit) Please remember that the USB communicator only has drivers available for the 32bit versions of these operating systems. We recommend for deployments, whether single or multiple communicators, that Ethernet communicators are used because they are easier to install and support. Installation guides have been produced for each platform and should be referenced prior to any live deployment:
530-0012-xx Windows Vista & Windows 7 530-0013-xx Windows Server 2008 Please read the Release Notes for the version of software you are going to be installing. This contains valuable information about a clean install and also upgrading from a prior version. Additional applications for running the USB communicator from a remote machine on the network and other ways to improve the system architecture are available. With a complete Technical Specification we can look at providing tools that may benefit the solution as a whole. Copies of these documents can be requested through ZBD Support support@zbdsolutions.com. If an installation is requested on a platform other than those listed, the request will be submitted to a ZBD Technical review where consideration will be given to the request and business opportunity. 12.2 Software Installation Clean Install It is important to understand that a clean install is usually the quickest and easiest installation as there will not be any conflicts with any other application software loaded on a used PC system. Regardless of what PC is used the steps below must be followed. Run the Microsoft Update and download and install all hotfixes, patches and security updates that are available. Reboot the PC Run the Microsoft Update (expect to find more updates are now available that were not shown on the last update) and download and install all hotfixes, patches and security updates that are available. Re-run the Microsoft Update again and ensure no more updates are available. If this is a used PC, make a backup of the PC. Install Bounce v3.3 software components in the following order:-
(Please note you may be requested to reboot the PC, and if so you must do this after each module has completed its installation process.) Bounce Communicate Bounce Processor Bounce Architect Bounce Manager [please see Appendix A Bounce Manager installation for more details]
Run Microsoft Update on the host OS. Reboot the PC. Run Microsoft Update again to ensure all patches are applied. Strictly Private & Confidential 2012 ZBD Displays Ltd Page 23 of 37 685-0003-08 Reboot the PC. Run Bounce Manager and login with username=admin, password=admin You are now ready to use the Ethernet Discovery Tool and connect the Ethernet Communicator to the system. Do basic checks to see if the bounce communicator is connected and all epops are attached to the system. 12.3 Testing Before going anywhere near the real store environment we strongly recommend creating a lab system to run tests on the integration, store management and error reporting processes for the pilot. This will help in creating an installation checklist that can be sent to the customers IT group in advance. This will save a lot of time in-store getting everything up and running so important topics like training and user education can take place. Spending 80% of the time on network and connectivity issues is not the best way to start an installation with a new customer!
Example questions: -
File connection path for Bounce Processor Machine user permissions required Login details Etc. 13 Adding Epops to the Network Of course EPOPS delivered from the factory are essentially ready for use. They need to be added to a system before they can be assigned to products and display content. 13.1 Adding epops step by step Strictly Private & Confidential 2012 ZBD Displays Ltd Page 24 of 37 685-0003-08 The epops MUST be within 10m of the Bounce Communicator antenna to be configured 1. Adding epops to a network uses Channel 5 (in European territories) and Channel 60 in the USA. It is not possible to build two systems of epops for different stores using two machines in close proximity as there will be contention (conflict) for the same RF configuration channel. 2. Each box of EPOPS contains a number of 2D barcodes listing all the serial numbers of the EPOPS it contains. Record the label serial numbers using a 2D scanner into Notepad [or equivalent text editor]
3. Repeat for each box that you want to add in that session 4. Save the file and ensure all serial numbers are on separate lines and there are no gaps between lines or separator characters in the file. 5. Import this as a CSV file using Bounce Manager a. The process uses a list of epops in CSV format and configures each label, it then generates a list of successful and failed epops, any failures are automatically removed from the system making the installation clean. b. Failed epops should be re-run again the Batch Configuration process results in a report which gives the option to rerun the configuration process again for any that have failed to configure. This should definitely be done. 6. Epops are then added by Bounce to the network automatically 7. Adding epops takes ~10 hours for circa 1,000 displays 8. The status progress can be viewed through the command line window or through the Batch Configuration Report in Bounce Manager. Once the process completes the total number of epops will be shown on the Bounce Manager Dashboard. 13.2 Offsite configuration If it is not practical to configure epops into a new installation (this could be due to construction delays, incomplete data cabling etc) then the configuration can be undertaken off-site. 1. Build a Bounce PC using the licence key for the installation 2. Configure the epops using Bounce Manager 3. Back up the database using Bounce Manager 4. Take the epops and the back up to the store and restore the database 5. After 15 minutes all of the epops should have resynchronised 6. Epops can be allocated to product in the normal way. 7. Delete the database from the off-site system and uninstall the software IMPORTANT NOTE: For sites that already have epops installed this process must NOT be used as it would generate duplicate RF addresses in the epops and could overwrite previous data changes in the live environment. If such a requirement is necessary contact support@zbdsolutions.com. 13.3 Synchronisation and Label Management In order for the system to function smoothly all epops should be kept in the store within range of the Bounce Communicator antenna. This is a must do Strictly Private & Confidential 2012 ZBD Displays Ltd Page 25 of 37 685-0003-08 as staff need to be aware of some of the factors associated with how the RF system works. Part of the staff training must makes it clear that EPOPS that are out of range of the communicator will fail to update and will appear on a list of update failures. 13.3.1 Synchronisation The Bounce Communicator sends out synch pulses in the background of normal operation so that all the EPOPS within range stay listening on a specific channel and react in a timely fashion to update commands. If the EPOPS are taken out of range of the communicator then they change state internally and begin listening on an alternative channel for RF commands. This is in order to conserve battery life when the epops may be out of RF range for an extended period When these epops are then brought back into RF range it can take a maximum of 20 minutes for them to regain synchronisation with the RF system and be available for the store staff to assign to products. Of course if the staff are not aware of this fact then their initial assessment when they try to allocate a new label to a particular product may well be that it doesnt work and they will incorrectly report an error, not trust the system (or both) 13.3.2 Network Management Adding epops to the network (once the network is live) has to happen based on the rules outlined above i.e. within 2-10m of the Configure&Update communicator. Deleting epops from the network can be done from any distance from the communicator providing they are in range of course. 13.3.3 Moving epops between stores/sites Our recommendation is that when epops need to be taken from one store and sent to another then the following steps are taken:
Use a Hand Held Terminal (HHT) to delete epops from the network individually as you move around the store or scan the serial numbers of the epops that are going to be moved to create a .CSV file If the HHT doesnt have the Delete EPOPS menu option then this would have to be done at the back office PC Delete the EPOPS from the system using Bounce Manager There is now a DeleteEPOPS command line tool that can delete a large number of EPOPS listed in a csv file. This is run from a command line and the tool can be found in the c:\Program Files\ZBDDisplays\Bounce\Tools\DeleteEpops folder Epops that have been deleted from the network in the store will be blank Take the CSV list of deleted EPOPS and import this into Bounce Manager in the second store while the epops are within 2-10m of the new Bounce Communicator Antenna The main point with label management, movement and setting up the system is that a pre-planned process should always be followed. Taking ad-hoc action to fix a problem, however urgent or justifiable in the short term, can very easily create long term issues requiring numerous store visits to correct. 14 Product Data Loading As well as adding physical epops to the system the products have to be created for them to be linked to. The settings defined in Policy Architect come into effect when Bounce Processor runs and the Bounce Database is populated with product information. This product data is then used by Processor to create bitmap images for each product using the rules that were defined in Template Architect Strictly Private & Confidential 2012 ZBD Displays Ltd Page 26 of 37 685-0003-08 Policy Architect Configuration
- Data sources
- Product Data Fields
- Template Fields
- Transformations Policy Architect Configuration - Template Fields Policy Architect Configuration
- Schedule info Table Table Table Price Model Stock Retailer Databases Bounce Processor
(acquire phase) Data Values bounce Architect Database Bounce Processor
(render phase) Template Collection Bounce Communicate Bounce Database 14.1 Enterprise Interface product data loading In this case Bounce Processor is monitoring a folder on the local machine in each store for incoming XML product information. So the first stage is to begin an initial load of product data which has to be started by the retailers systems. Sending all the product information for the store means Bounce Processor has a starting image/dataset for a product. Any new information for a product is compared to whats already in the database and a new bitmap created and sent out if needed. 14.2 Other connection types Bounce Processor will read the data from a database or .csv file (for example) and then store a local copy of the information it needs. Depending on the rules defined in the policy file, Bounce Processor with then re-read the database and send out updates with new images if needed. 15 Linking epops to Products Essentially there are a couple of scenarios to consider. A small store with up to a hundred epops A medium store with 100 to 1,000s A large store with 1,000s to 10,000s Unless its a very small installation the only practical way of linking EPOPS to products is by using a mobile hand-held terminal (HHT) that has a barcode scanner. Store staff can go along a shelf scanning a product barcode and then an EPOPS barcode to associate or link the two in the database. This will trigger Bounce Communicate to send a product image to the EPOPS. If the product information changes then another image will be sent to that label automatically. There are a few ways to set this up in the software and this is a very important process that needs to be fully discussed with the customer before a solution is implemented. Strictly Private & Confidential 2012 ZBD Displays Ltd Page 27 of 37 685-0003-08 It should be noted that medium and large stores will have their own locked down HHT application. ZBD and partners can only advise on techniques to implement. It is entirely the customers responsibility to integrate, test and approve any HHT application. 15.1 XML or Enterprise interface method This is the most flexible and easy to implement way of linking EPOPS to products because it can be programmed by the retailer so they are using their own HHT. It also means that the links can still be made if the retailer doesnt have a wireless network in their store. (batch)
</link>
<link>
<art>121525800000</art>
<label>012345678900000040</label>
<linktype>LINK</linktype>
- <link>
<art>121525800000</art>
<label>012345678900000060</label>
<linktype>UNLINK</linktype>
</link>
15.2 ZBD Bounce Manager Product Assignment There is nothing built into Bounce Manager in the current release. Should you require the ability to do this in Bounce Manager, please contact support@zbdsolutions.com Strictly Private & Confidential 2012 ZBD Displays Ltd Page 28 of 37 685-0003-08 16 Training and Procedures before handover 16.1 Training Staff training is a very important part of the success of any project. Since the staff are such a key part of any retail organisation their opinion and user experience carries great weight with any decision making process later in the sale. Staff training must incorporate the basic functionality such as:
o Knowing how to access the Bounce Manager application o How to use the HHT application device o How to manually assign/un-assign epops to products o How to manually add/delete epops to the system o The correct handling and care of the epops [cleaning etc]
o Use of the built-in scanner to read bar-codes effectively. o Ongoing training to ensure all operators can use scanners correctly. o How to attach/remove epops from fixtures and correct use of fittings
(i.e. to optimize viewing angles etc.) o The correct thermal stabilization (thermal equilibrium) period if epops are moved from ambient temperature to chiller environments or vice versa. It is recommended that display image updates are not carried out during the 45min thermal stabilization period. If updates are carried out the image will be blackened or smudged and the correct time must elapse before a new image update is downloaded which will correct the smudged image. The staff should have access to User Guides that they can use to administer the labeling system; these documents should be the responsibility of the customer or agent to provide. We recommend getting hold of any User Guides created by the customer to check that what theyve created is correct and clear. 16.2 Procedures and handover Retailers usually have a pre-defined set of procedures and will know what their roles and responsibilities are in most situations. These scenarios need to be discussed and agreed with the project team before the system is handed over to them. Does the project team know how the store gets more EPOPS? Whats the procedure for reporting faults or issues? Unless these are dealt with before the store takes over responsibility for the system then the whole installation may fail. The handover process should confirm that the store management has accepted the system, and these processes have been agreed. o Staff training & supporting procedures documentation (eg: Quick Reference Guide) o Support contact information (who to call, how to escalate). o Typically in the form of an A4/A5 o Support Notice with information and contact numbers o Where to get spares displays, shelf-edging or other consumables?
Strictly Private & Confidential 2012 ZBD Displays Ltd Page 29 of 37 685-0003-08 o Returns Management Process has been agreed and the store management knows what it is. So, the staff will know what to do if theres a problem, where to get more epops from and theyll have had training. 17 System Management The system is managed through the Bounce Manager application and provides status updates, reports and alerts. The Bounce Manager application guide is documented in 530-0058-xx (Bounce Manager User Guide). This document is very important and must be read before the system is made operational 18 Support Overview Issues that need ZBD assistance should be sent via our support email address
(Salesforce portal) with all the necessary information to be able to reproduce the problem. support@zbdsolutions.com In most cases ZBD are likely to be responsible for third level support only. So partners will provide the first and second level support for most system installations whether they are trials, proof of concept or full roll-out. ZBD will deal with third level support issues once the partner has been able to reproduce the issue themselves in-house and is able to give ZBD the means to reproduce the issue in order to fix it. The different parts of the Bounce software suite all have logs available on the live system to help diagnose issues and solve problems. This support section focuses on the XML based Enterprise Interface [550-
0009-xx] since this is our preferred method of driving the system. This offers the greatest flexibility for interfacing to the system and controlling it without significant integration/coding work needing to be carried out. This support chapter has been split into three sections: -
1. Store level diagnostics Information and questions for store personnel to help them either solve the problem themselves or help in the diagnosis 2. Partner / Support level diagnostics Locations for support logs and some information on mid-level issues that can occur as well as how to fix them 3. Advanced Selected challenges and more detailed information 18.1 Store level diagnostics The main challenge with problems reported by store staff is lack of information thats useful to actually solve the problem. These are usually vague statements like: -
Nothing seems to be working Strictly Private & Confidential 2012 ZBD Displays Ltd Page 30 of 37 685-0003-08 A label didnt update A price change didnt happen Instead of trying to use this vague information as the basis for diagnosing the fault and fixing the problem its actually more time efficient to go through a set number of steps. 18.1.1 18.1.1.1 Is the RF network working?
There are a couple of ways for staff to check whether the RF network is actually functioning properly Is the green or orange light flashing on the communicator?
This may not be visible to the staff, depending on where it is mounted in the store 18.1.1.2 Can you assign an EPOPS to a different product?
Pick an EPOPS from the shop floor and try to assign it to something different (remember to assign it back afterwards!) Try a couple if the first attempt doesnt work remember, depending on the way the system is set up, that there may be a wait for this action to complete. 18.1.1.3 What is the general system status?
18.1.2 There is an alert log in Bounce Manager and visible alerting in the Dashboard to warn the store staff whether there are significant problems anywhere with the system Whats the status of the label?
Its important to find out from the staff what the label actually says: -
Successfully configured*
The label is on the network but has never been linked to a product Unassigned*
The label is on the network and was linked to a product but is not linked to a product anymore No image available*
The label is assigned/linked to a product but the problem could be that the product information isnt available from the retailers host system [see section 13.2.1.2 later]
Product image bitmap The label has a product image with price/barcode etc. means that its currently linked to the product shown
*It is possible in some environments that these default images have been replaced with specific customer images. Strictly Private & Confidential 2012 ZBD Displays Ltd Page 31 of 37 685-0003-08 18.1.2.1 Interrogate Bounce Manager about the label In order for store staff to interrogate the system about a specific EPOPS look at the Bounce Manager page and type/scan its serial number into EPOPS History 18.1.2.2 Force the label to update Using the HHT it may be possible to force the label to update or to use the retailers host system to send the product information to the label again. REMEMBER: The store back office system may be out of range of the communicator if its sitting out in the middle of the sales area. Holding a label and trying to send it updates when out of range of the communicator is obviously going to cause even more confusion!
18.1.2.3 Is the label update or assignment in the Update Queue?
Apart from sitting and looking at a label and maybe missing changes on the screen its possible to check the bounce queue in Bounce Manager 18.2 Partner / Support Level Diagnostics 18.2.1 We recommend that partners and support organisations should have remote access to the machines running the Bounce software in store. The main reason for this is that EPOPS are still quite new technology and while we are confident the solution is robust the customer will be nervous about relying on something they may not understand. So it is very important for support organisations to be able to react quickly and answer questions that the customer might have. The only way to really achieve this is by having remote access to the machine in the store. Enterprise Interface error logging The main advantage of using XML files and folders is that files (product updates, link requests and system commands) which arent processed are moved into their respective error folders. So its easy to see whether files have been processed or not. More detail on setting up the system this way is available in the Enterprise Interface [550-
0009-]
There is also a general logging output file which can be activated in Policy Architect. Policy Architect > Edit > Logging Settings
[The schema file for this is available from the ZBD technical team]
All this information can be accessed by the retailers host system and used to send status information back to the organisation rather than having to rely on store staff managing the system and trying to diagnose issues themselves. Strictly Private & Confidential 2012 ZBD Displays Ltd Page 32 of 37 685-0003-08 18.2.1.1 Incoming XML data doesnt match the Schema If files are sent from the host system that dont match the schema for the products, EPOPS or system commands then they wont be processed and re-named as errors 18.2.1.2 XML files didnt actually arrive to be processed There may be a classification of products or a switch higher up within the retailers host system that means products arent categorised or available as electronic epops Weve seen this where the request is made to the host system for the information for a particular product but he host has ignored this request because that particular product shouldnt be merchandised
(sold) using an electronic label. Error logs There are quite a few logs available to diagnose system issues although it takes some experience to draw conclusions from them. System Management Tools In the latest release (3.3) there are a number of command line tools which are designed to carry out batch processes, solve problems and diagnose possible faults across the network of epops in the store. 18.2.2 18.2.3 18.2.3.3 Bounce Processor Database Cleaning Tool The Bounce Processor Database Cleaning Tool is a command line application that is designed to remove unused data from the Bounce Processor SQL Server database instance and reclaim storage space. The tool requires no user interaction and can therefore be used from a scheduled task within Windows.
[530-0034-xx]
18.2.3.4 SQL Database Cleanup Tool The SQL Database Cleanup Tool is a command line application that is designed to remove unused data from the Bounce SQL Server database instance and reclaim storage space. The tool requires no user interaction and can therefore be used from a scheduled task within Windows.
[530-0032-xx]
Both these cleanup tools should be scheduled to run in installations to ensure that SQL Express 2008 does not reach its 10GB data limit. Strictly Private & Confidential 2012 ZBD Displays Ltd Page 33 of 37 685-0003-08 18.2.3.5 Get Log Tool This tool copies and zips all the log files for the system and places the zip file in the same directory that the batch file was run from. The default location for this is: -
C:\Program Files\ZBD Displays\Bounce\Tools\GetLogFiles This saves users hunting around locations for all the logs and brings them together into one place. It does not send the file anywhere however!
When logging a support request it is good practice to include the zipped log files in the request. 18.2.3.6 SQLBounceXMLBackup and SQLBounceXMLRestore These tools create an XML based backup of the Bounce Comms database but only retain the information needed to recover a network of EPOPS with their product associations. Since the amount of information retained is less these files are not as big as standard SQL backups so they can be emailed and sent without the same network issues that a 300Mb file might have. 18.2.3.7 BackupDB Tool A standalone tool for backing up the bounce database 18.2.3.8 EPOPS Command Line Application (CLA) The CLA tool is a powerful command line application that should only be used when directed to by ZBD Support. Making improper changes to the system using this tool can have a detrimental effect on the system and in some cases loose communication to the EPOPS altogether. Please refer to the detailed notes in the documentation for this tool
[530-0037-xx]
18.2.4 Other ZBD Software Tools These utilities are available to make batch tasks simpler and save time 18.2.4.1 Auto EPOPS Assign Allows you to assign a .csv file or EPOPS serial numbers to a .csv file of product IDs automatically. The next EPOPS serial number in the list will be associated (linked) to the next product in the list. Its also possible to use Auto EPOPS Assign to automatically link an EPOPS serial number list to products with the same ID as the EPOPS serial numbers. [530-0036-xx]
18.2.4.2 Delete EPOPS Allows mass deletion of a .csv list of EPOPS serial numbers from a system without having to find individual EPOPS in the Bounce GUI list
[530-0035-xx]
Strictly Private & Confidential 2012 ZBD Displays Ltd Page 34 of 37 685-0003-08 19 Summary The main challenges to set up a working system are: -
o Understanding the retailers wishes for the system and the procedures that have to be followed in the store. o Agreeing a written technical specification that meets these requirements and get signoff by both parties. o Planning the installation to take into account lead-times and fixtures/fittings. o Following a set of logical, sequential steps while installing the EPOPS solution. o Ensuring the staff have received proper training from the retailer. We hope this document will greatly assist in meeting these challenges and welcome any feedback. Strictly Private & Confidential 2012 ZBD Displays Ltd Page 35 of 37 685-0003-08 20 Appendix A Bounce Manager installation Bounce Manager can be installed in either of 2 modes: either in Standalone mode or in IIS mode. In Standalone mode, access to Bounce Manager is restricted to the PC on which it is installed. In IIS mode, Bounce Manager can be accessed from remote PCs. The installation and correct configuration of Microsoft Internet Information Services (IIS) is a pre-requisite in this case. Installation files: the Bounce Manager installation package contains 2 folders Standalone and IIS. The Standalone folder contains the Bounce Manager installation files (setup.exe and BounceManagerSetup.msi) which install Bounce Manager as a web service running on TCP/IP port 8000. If Bounce Manager is installed as Standalone it will only be available on the PC on which it is installed via http://localhost:8000/. [N.B please run the file setup.exe to install]
If access to Bounce Manager is required from a remote PC, then the IIS alternative needs to be installed. The IIS folder contains the installation files (setup.exe and BounceManagerIISSetup.msi) which install Bounce Manager as a module or web application under Microsoft Internet Information Services (IIS). [N.B please run the file setup.exe to install]
Configuration steps:
The IIS option requires a number of configuration steps, as listed below:
(1)Enable IIS 6 Management Compatibility The location of this Windows module depends on your operating system please refer to Windows documentation for more details. Under Windows 2008 Server R2 64-bit the IIS 6 Management Compatibility module can be found under Web Server (IIS), Add Role Services and select IIS 6 Management Compatibility. Under Windows 7 32-bit, the IIS 6 Management Compatibility module can be found in Control Panel > Programs & Features > Turn Windows features on or off. Figure 1 - enable IIS 6 management compatibility
(2) Bounce Manager runs under the DefaultAppPool under IIS. Strictly Private & Confidential 2012 ZBD Displays Ltd Page 36 of 37 685-0003-08 For Bounce Manager to function correctly, please ensure that the following parameters are set correctly in the Advanced Settings of the DefaultAppPool. a. Under section (General) , and if Bounce Manager is running on a 64-bit system, please set Enable 32-bit Applications to True see Figure 2 below. b. Under section Process Model, please set Load User Profile to True. Figure 2 - IIS DefaultAppPool parameters Strictly Private & Confidential 2012 ZBD Displays Ltd Page 37 of 37 685-0003-08
1 2 | User Manual | Users Manual | 1.01 MiB |
Aura and Chroma label Installation Guide Document Number:
Date:
550-0020-11 06 June 2017 Table of Contents Table of Contents _____________________________________________________________ 1 1 Label shelf installation _____________________________________________________ 2 1.1 Aura and Chroma mounting position _____________________________________________ 2 1.2 Chroma 16 mounting orientation. _______________________________________________ 2 1.3 Aura 21/29 and Chroma 21/29/37 mounting orientation. _____________________________ 2 1.4 Aura 42 and Chroma 42/60/74 mounting orientation. _______________________________ 2 1.5 Aura and Chroma fixing angle. _________________________________________________ 2 2 Low temperature label variant deployment _____________________________________ 2 3 FCC Warning Statement ____________________________________________________ 3 4 Radio Equipment Canadian Warning Statements ______________________________ 3 5 Radio Equipment Mexico Regulatory Statement _______________________________ 4 6 Battery Caution Statements__________________________________________________ 5 2017 Displaydata Ltd Page 1 of 5 1 Label shelf installation 1.1 Aura and Chroma mounting position The label should be mounted to the shelf edge using a shelf rail, available through Displaydatas Fixtures & Fittings partners. It should not be mounted directly to a metal surface. 1.2 Chroma 16 mounting orientation. The label should be mounted along the shelf edge with the front bar code below the display. 1.3 Aura 21/29 and Chroma 21/29/37 mounting orientation. The label should be mounted with the display aligned horizontally along the shelf edge with the front bar code on the left-hand side. 1.4 Aura 42 and Chroma 42/60/74 mounting orientation. The label can be mounted with the display in landscape or portrait orientation using the mounting bracket available through Displaydatas Fixtures & Fittings partners. 1.5 Aura and Chroma fixing angle. The Aura and Chroma range of Electronic shelf labels are based on EPD display technology with a viewing angle close to 180degrees. This means that the overall readability of the screens is not subject to the fixing angle. The same vertical fixing angle can be used independent of shelf height. 2 Low temperature label variant deployment It is very important to understand some basic principles with regard to the deployment of labels into a Chiller environment (temperature controlled fridges that are below 10degC). All labels will usually be configured in a normal ambient room temperature environment
(~20degC but could be as high as ~30degC). Once they have been configured onto a system, they can then be placed into a chiller unit. It is extremely important that all the labels are allowed time to thermally stabilise at the new colder temperature before any image updates are carried out. It is essential to allow 45mins for the labels to reach thermal equilibrium before sending images to the labels. Failure to wait for thermal equilibrium may result in a display where the text/graphics will be hard if not impossible to read. Please note that the same thermal equilibrium time applies to moving a label from a Chiller/Freezer into a normal ambient temperature zone. 2017 Displaydata Ltd Page 2 of 5 3 FCC Warning Statement These devices comply with Part 15 of the FCC Rules. Operation is subject to the following two conditions:
(1)
(2) This device may not cause harmful interference, and This device must accept any interference received, including interference that may cause undesired operation. This equipment complies with FCC radiation exposure limits set forth for an uncontrolled environment. End users must follow the specific operating instructions for satisfying RF exposure compliance. This transmitter must not be co-located or operating in conjunction with any other antenna or transmitter. Changes or modifications not expressly approved by the party responsible for compliance could void the user's authority to operate the equipment 4 Radio Equipment Canadian Warning Statements English
"Under Industry Canada regulations, this radio transmitter may only operate using an antenna of a type and maximum (or lesser) gain approved for the transmitter by Industry Canada. To reduce potential radio interference to other users, the antenna type and its gain should be so chosen that the equivalent isotropically radiated power (e.i.r.p.) is not more than that necessary for successful communication."
"This device complies with Industry Canada licence-exempt RSS standard(s). Operation is subject to the following two conditions: (1) this device may not cause interference, and (2) this device must accept any interference, including interference that may cause undesired operation of the device."
French
"Conformment la rglementation d'Industrie Canada, le prsent metteur radio peut fonctionner avec une antenne d'un type et d'un gain maximal (ou infrieur) approuv pour l'metteur par Industrie Canada. Dans le but de rduire les risques de brouillage radiolectrique l'intention des autres utilisateurs, il faut choisir le type d'antenne et son gain de sorte que la puissance isotrope rayonne quivalente (p.i.r.e.) ne dpasse pas l'intensit ncessaire l'tablissement d'une communication satisfaisante."
"Le prsent appareil est conforme aux CNR d'Industrie Canada applicables aux appareils radio exempts de licence. L'exploitation est autorise aux deux conditions suivantes : (1) l'appareil ne doit pas produire de brouillage, et (2) l'utilisateur de l'appareil doit accepter tout brouillage radiolectrique subi, mme si le brouillage est susceptible d'en compromettre le fonctionnement."
2017 Displaydata Ltd Page 3 of 5 Canada product approval detail Model name ISED/IC identity number Chroma 16 Chroma 21 Chroma 29 Chroma 37 Chroma 42 Chroma 60 Chroma 74 Aura21 Aura29 Aura29F 8910A-1200144 8910A-1200118 8910A-1200112 8910A-1200165 8910A-1200129 8910A-1200131 8910A-1200157 8910A-1200118 8910A-1200112 8910A-1200112 5 Radio Equipment Mexico Regulatory Statement De acuerdo con la NOM-121-SCT1, seccin 4.6.2 La operacin de este equipo est sujeta a las siguientes dos condiciones: (1) es posible que este equipo o dispositivo no cause interferencia perjudicial y (2) este equipo o dispositivo debe aceptar cualquier interferencia, incluyendo la que pueda causar su operacin no deseada. 2017 Displaydata Ltd Page 4 of 5 Battery Caution Statements 6 2017 Displaydata Ltd Page 5 of 5
1 2 | Label & Label Location | ID Label/Location Info | 181.39 KiB |
Example of rating plate label for updated Displaydata Chroma 29 model ESL:
Location of rating plate label on ESL:
Oli Bailey (Email: oli.bailey@displaydata.com) Hardware Engineer Displaydata Ltd.
1 2 | Class 2 change request | Cover Letter(s) | 77.74 KiB |
CLASS II PERMISSIVE CHANGE REQUEST Class II Permissive Change Request VC7120-0112 19th October 2017 Element Materials Technology 100 Frobisher Business Park Leigh Sinton Road Malvern, Worcestershire WR14 1BX UK RE:
FCC ID:
Model Name: Chroma 29 To Whom It May Concern:
Please be advised that pursuant to FCC Rule 47CFR 2.1043 the manufacturer requests that the above-referenced model be approved for class II permissive change. The reason for the Class II change is that to improve robustness and reduce manufacturing costs of this product, some changes have been made to the plastic mouldings and the PCB orientation to implement these improvements. For example, to reduce the occurences of cracked display glass, the display rests directly on plastic ribs in the rear cover, as well as using the PCB bottom side for support. However, since the product antenna type, external dimensions, appearance and materials are so similar to the currently manufactured Chroma 29 model, and the schematic is almost identical (except for two RF capacitors), it is intended to maintain the same FCC ID for this product. Testing by a certified test house has been undertaken to verify that there are no changes to the RF performance that could impact this application. Thank you for your attention to this matter. Yours faithfully, Oli Bailey. Hardware Engineer, Displaydata Ltd.
1 2 | Confidentiality Request | Cover Letter(s) | 260.34 KiB |
REQUEST FOR CONFIDENTIALITY IN ACCORDANCE WITH FCC RULE 0.459 Chroma 29 Certification Application Please be advised that the following information is to be held confidential on behalf of Displaydata Limited. The application contains technical information which Displaydata Limited deems to be trade secrets and propriety. If made public, the information might be used to the disadvantage of the applicant in the market place. Thank you for your attention to this matter. 2nd November 2017 Element Materials Technology. 100 Frobisher Business Park Malvern Worcestershire WR14 1BX UK RE:
FCC FRN: 0016544652 FCC ID: VC7120-0112 To Whom It May Concern:
Block diagram Parts list/Bill of Materials Schematics Operational discription Yours faithfully Displaydata Oli Bailey Displaydata Ltd, Century Court, Millennium Way, Bracknell, Berkshire, RG12 2XT Displaydata is registered in England and Wales. Registration number: 03929602 Registered office: Malavern Hills Science Park, Geraldine Road, Malvern, Worcestershire WR14 3SZ
1 2 | Letter of Agency | Attestation Statements | 163.02 KiB |
LETTER OF AGENCY 2nd November 2017 Element Materials Technology 100 Frobisher Business Park Malvern Worcestershire WR14 1BX UK FCC FRN: 0016544652 To Whom It May Concern:
Yours faithfully Displaydata Limited Oli Bailey We certify that we are not subject to denial of federal benefits, that includes FCC benefits, pursuant to Section 5301 of the Anti-Drug Abuse ACT of 1988, U.S.C. 862. Further, no party, as defined in 47 CFR 1.2002(b), to the application, is subject to denial of federal benefits, that includes FCC benefits. Thank you for your attention to this matter. Displaydata Ltd, Century Court, Millennium Way, Bracknell, Berkshire, RG12 2XT Displaydata is registered in England and Wales. Registration number: 03929602 Registered office: Malavern Hills Science Park, Geraldine Road, Malvern, Worcestershire WR14 3SZ
1 2 | Drug Declaration | Attestation Statements | 101.14 KiB | October 03 2014 |
LETTER OF AGENCY 19th February 2014 Displaydata Building 3 Kingswood Kings Ride Ascot Berkshire SL 5 8AD United Kingdom FCC Product ID: VC7120-0112 To Whom It May Concern:
Thank you for your attention to this matter. Yours faithfully Displaydata Robert Sweetman We certify that we are not subject to denial of federal benefits, that includes FCC benefits, pursuant to Section 5301 of the Anti-Drug Abuse ACT of 1988, U.S.C. 862. Further, no party, as defined in 47 CFR 1.2002(b), to the application, is subject to denial of federal benefits, that includes FCC benefits.
frequency | equipment class | purpose | ||
---|---|---|---|---|
1 | 2017-12-18 | 902.5 ~ 927.5 | DXT - Part 15 Low Power Transceiver, Rx Verified | Class II permissive change or modification of presently authorized equipment |
2 | 2014-03-10 | 902.5 ~ 927.5 | DXT - Part 15 Low Power Transceiver, Rx Verified | Original Equipment |
app s | Applicant Information | |||||
---|---|---|---|---|---|---|
1 2 | Effective |
2017-12-18
|
||||
1 2 |
2014-03-10
|
|||||
1 2 | Applicant's complete, legal business name |
Displaydata Ltd.
|
||||
1 2 | FCC Registration Number (FRN) |
0016544652
|
||||
1 2 | Physical Address |
Greenwood House
|
||||
1 2 |
Bracknell, RG12 2AA
|
|||||
1 2 |
United Kingdom
|
|||||
app s | TCB Information | |||||
1 2 | TCB Application Email Address |
P******@element.com
|
||||
1 2 |
p******@tracglobal.com
|
|||||
1 2 | TCB Scope |
A1: Low Power Transmitters below 1 GHz (except Spread Spectrum), Unintentional Radiators, EAS (Part 11) & Consumer ISM devices
|
||||
app s | FCC ID | |||||
1 2 | Grantee Code |
VC7
|
||||
1 2 | Equipment Product Code |
120-0112
|
||||
app s | Person at the applicant's address to receive grant or for contact | |||||
1 2 | Name |
O****** B********
|
||||
1 2 | Title |
Mr
|
||||
1 2 | Telephone Number |
+4413********
|
||||
1 2 | Fax Number |
+4413********
|
||||
1 2 |
o******@displaydata.com
|
|||||
app s | Technical Contact | |||||
n/a | ||||||
app s | Non Technical Contact | |||||
n/a | ||||||
app s | Confidentiality (long or short term) | |||||
1 2 | Does this application include a request for confidentiality for any portion(s) of the data contained in this application pursuant to 47 CFR § 0.459 of the Commission Rules?: | Yes | ||||
1 2 | Long-Term Confidentiality Does this application include a request for confidentiality for any portion(s) of the data contained in this application pursuant to 47 CFR § 0.459 of the Commission Rules?: | No | ||||
if no date is supplied, the release date will be set to 45 calendar days past the date of grant. | ||||||
app s | Cognitive Radio & Software Defined Radio, Class, etc | |||||
1 2 | Is this application for software defined/cognitive radio authorization? | No | ||||
1 2 | Equipment Class | DXT - Part 15 Low Power Transceiver, Rx Verified | ||||
1 2 | Description of product as it is marketed: (NOTE: This text will appear below the equipment class on the grant) | Chroma 29 Electronic Shelf Label | ||||
1 2 | Aura 29 Electronic Label | |||||
1 2 | Related OET KnowledgeDataBase Inquiry: Is there a KDB inquiry associated with this application? | No | ||||
1 2 | Modular Equipment Type | Does not apply | ||||
1 2 | Purpose / Application is for | Class II permissive change or modification of presently authorized equipment | ||||
1 2 | Original Equipment | |||||
1 2 | Composite Equipment: Is the equipment in this application a composite device subject to an additional equipment authorization? | No | ||||
1 2 | Related Equipment: Is the equipment in this application part of a system that operates with, or is marketed with, another device that requires an equipment authorization? | No | ||||
1 2 | Grant Comments | Class II permissive change. | ||||
1 2 | Is there an equipment authorization waiver associated with this application? | No | ||||
1 2 | If there is an equipment authorization waiver associated with this application, has the associated waiver been approved and all information uploaded? | No | ||||
app s | Test Firm Name and Contact Information | |||||
1 2 | Firm Name |
Eurofins Hursley Ltd
|
||||
1 2 |
Element Materials Technology Warwick Ltd
|
|||||
1 2 | Name |
A****** C********
|
||||
1 2 |
S**** B******
|
|||||
1 2 | Telephone Number |
00-44********
|
||||
1 2 |
01695********
|
|||||
1 2 | Fax Number |
00-44********
|
||||
1 2 |
01695********
|
|||||
1 2 |
a******@eurofins.com
|
|||||
1 2 |
s******@element.com
|
|||||
Equipment Specifications | |||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Line | Rule Parts | Grant Notes | Lower Frequency | Upper Frequency | Power Output | Tolerance | Emission Designator | Microprocessor Number | |||||||||||||||||||||||||||||||||
1 | 1 | 15C | 902.50000000 | 927.50000000 | |||||||||||||||||||||||||||||||||||||
Line | Rule Parts | Grant Notes | Lower Frequency | Upper Frequency | Power Output | Tolerance | Emission Designator | Microprocessor Number | |||||||||||||||||||||||||||||||||
2 | 1 | 15C | 902.50000000 | 927.50000000 |
some individual PII (Personally Identifiable Information) available on the public forms may be redacted, original source may include additional details
This product uses the FCC Data API but is not endorsed or certified by the FCC