Join our next webinar: Tracking Tools with RAIN RFID – Learn more and register

All blog posts

Employee Spotlight – Voyantic’s Solution Specialists

Feb 01, 2024

I talked with Voyantic’s Solution Specialists, Lasse Saarinen and Gerald Smid, about their work in the field with production testing clients. 

Voyantic provides quality testing systems for various label and tag production machines, for different stages in the production process. Although Tagsurance 3, our next-generation production testing system, is easy to integrate practically into any machine, there are always variables and machine features where our customer service team is needed to support the implementation and commissioning of the system. They are also at the forefront of demonstrating our system performance to prospective customers. 

Lasse Saarinen (left) and Gerald Smid help Voyantic’s customers in the field and online.

But what is it like to work in the field with Voyantic’s prospects and customers? To find out, I decided to talk with Voyantic’s Solution Specialists, Lasse Saarinen and Gerald Smid.

The role of Voyantic’s Solution Specialists is to support customers in finding the best solution for customers’ needs, integrating Voyantic systems, conducting product demonstrations, and providing training as needed. They are closely involved with both current and prospective customers. The job also involves a fair amount of travel to customer sites and various events.

– Voyantic is not just a “systems provider” but our customers receive assistance and support for system implementation, benefiting from our expertise and excellent customer service, explains Lasse.

– So, we provide solutions to our customers, summarizes Gerald.

And what does your work involve in practice?

– Typically, when a system is sold to a new customer we visit the customer on-site and ensure that the installations are working correctly. – On the second day, the customer does it themselves, and we are immediately available when questions arise.

– When the customer does it themselves, they learn the best. Soon, the customer’s questions become more detailed.

– After meeting face-to-face, it’s much easier to communicate both ways. We often have remote meetings in the demo room when demonstrating systems via camera. Video connection helps to some extent, but of course, it doesn’t replace being at the customer’s site for 2–3 days.

Who are the typical production testing customers and what challenges does Voyantic help to address? 

Typical customers for Voyantic’s production testing solution are either machine manufacturers who make production machines for different stages in the RFID label production process or companies that use the machines to make RFID inlays and finished labels. I asked Gerald and Lasse what are the machine types they see in the field.

-Machine manufacturers’ machine types include chip attachment machines, label converting machines, RFID inlay insertion machines, and different kinds of finishing and control machines where our RF quality testing system can be integrated, Lasse explains.

-Customers can also be broadly divided into those for whom RFID production is new and those who already produce RFID labels, Gerald defines. -One typical customer group, for example, includes label manufacturers. They receive requests from their customers to include RFID tags in labels and then try to figure out the best way to do it. This customer group naturally has many questions related to RFID technology in general.

– Another typical customer group is those already producing RFID labels with an existing, perhaps reader-based testing method. They might want to upgrade their system to a more comprehensive system.

– Many questions revolve around the installation of the testing system: How to integrate the system, and how quickly can the line run?

– A customer may have their own testing system. They can test to some extent whether the tags work but may not know if they meet the required quality standards.

– And if it’s a legacy testing system, the person who created the system may have retired, and no one else knows how to develop it. And there may not be spare parts available for the old system anymore.

Why is testing RFID labels so important?

It was mentioned that some customers may even have self-made testing systems. Why, for example, is a reader-based testing system not sufficient for an RFID label producer?

– Well, everyone knows the radio. We’re talking about frequencies. I could compare it to reader-based systems figuring out if the radio works. If something is heard, the radio works. In our system, using this analogy, in addition to hearing the radio, you identify different radio stations that are heard.

What are some tangible benefits of Voyantic’s testing system? 

– Consistency, both Lasse and Gerald agree.

– Rejecting tags that don’t meet the predefined performance requirements. 

– When the production output is consistent the read distance stays roughly the same in the end-use case. If there are deviations, it works less well. 

– Several meters of read distance may be lost with tags that are not consistent. If the tag is designed to be read from 3 meters away and doesn’t work, the system doesn’t recognize the product at all. That is why consistency is a vital element in RFID tag production.

– One reason for testing RFID tags is simply the quality requirements that many customers know to demand from the tags. 

– Quality test requirements also come from quality certifications. RFID tag production can be quality-certified, and there are test criteria that tags must meet to receive a certain certification. Then the tags must be tested in a specific way. The quality of the manufactured product must match the criteria.

What kind of classification are we talking about?

– The University of Auburn has the ARC program. Auburn’s ARC program has become a main quality certification for the RFID industry. It is the source of the criteria for testing.

– The need to prove quality is a basic requirement of any quality system, such as ISO 9001-based systems. These standards do not have detailed criteria for the testing, but some way to show the quality of the product is needed. We help tag manufacturers to use the quality control systems in a good way.

-The starting point is that if you want RFID on labels, it’s advisable to test them. Only through testing can any issues with the performance of the RFID label be identified before they go to customers.

– One feedback we have received from our customers after acquiring the systems is that when even one bad production lot is not delivered to the customer, the system has already paid for the investment, Gerald says.

– For future customers, we could encourage them by advising them to go ahead boldly. Our systems are surprisingly easy to use once you understand the concept, and you can always get help, the Voyantic Solution Specialists summarize.

All blog posts
All blog posts

Life of Voyanticians Blog Series – Part 1: The Lazy Engineer

Oct 13, 2022

Content Warning! This post includes some serious engineering terminology. Reader discretion is advised! 😉

“Being Lazy”

At Voyantic we value “lazy engineers”, a term that often is linked to efficiency in the engineering context. One key aspect of efficiency in software development is automation, and software engineers have been working with CI (continuous integration) / CD (continuous delivery) systems for eons to have their code automatically built, tested, and deployed. Typically these CI systems run neatly on the cloud, either self-hosted or as a service.

The same CI / CD practices are not nearly as widely adopted on the embedded side as those are on the server-side software. This was also true for Voyantic, but we have decided that there are no excuses not to have HW part of the CI cycle, especially when the other option is to do manual regression testing – ouch!

In this blog post, I’ll describe how we try to be lazy while leveraging automation in our development and testing practices.

Efficient Test Automation

4 Key aspects for efficient test automation

  1. Test triangle as a guideline
  2. Automate everything
  3. Fast feedback loop for development
  4. Reliable tests and automation

How these are applied at Voyantic

For those unfamiliar with the test triangle, it is best depicted by the following diagram.

Lower-level tests are running faster and have the opportunity to test corner cases more easily but are run in isolation, without testing the interoperability of the code and components. Capability for rapid code changes requires fast test cycles. Pull request (PR) builds are running unit tests and integration tests to have that fast feedback cycle, typically within minutes, and covering both the fine-grained unit tests and integration tests ensuring interoperability.

Unit test definition always seems so clear until you realize that developers have vastly different unit sizes that they test. Our approach is to test code in isolation, one file/module/class at a time, and mock anything external. Truly testing just the unit.

At the integration test level, we prefer the real thing over mocks. Firmware changes are flashed to the device and tested using its API and cloud services are deployed and tested using their API. If a tested piece of a component depends on other services or hardware, then real hardware or deployed service is used instead of the mock. In some cases, it is not possible to avoid mocking or simulation but those are the exceptions that make the rule. Mocking is avoided for a couple of different reasons; 1. There is a significant amount of development and maintenance required to mock something. 2. Mock always fails to simulate the real thing perfectly, allowing bugs to go unnoticed.

End to End tests are gating software release and performed on a high level, simulating the end-user behavior, potentially having a long execution time. For example, we are using Playwright to test ReactJS-based Web UIs. This category includes also other long-running test types, like soak tests, where for example our Tagsurance 3 system is run for days without interruption to simulate its usage on the production line producing RFID tags. These types of tests will catch issues that only manifest over time, like a slow memory leak, data store efficiency with bigger data sets, overheating, etc. 

Theory Meets the Hardware

The above diagram depicts the high level CI-system architecture. Jenkins leader is running on a dedicated AWS CI account. The leader is starting on-demand Jenkins followers for build jobs not requiring access to the Voyantic hardware devices. Build jobs using Voyantic hardware devices are run on the on-premise Jenkins follower. This gives us the ability to test cloud services efficiently with co-located cloud-based followers, as well as embedded software running on our own HW devices connected to our on-premise servers.

All continuous integration pipelines are fully automated. Once the developer creates a PR, it will start the Jenkins pipeline to build the code, run static checks and unit tests, deploy it to its target environment, and run integration tests. After merging the PR to the main branch, the pipeline is started again and the same tests are executed but in addition, E2E tests are run too. 

Not to be overly rosy in this description, this does not apply to all of our git repositories and some are lacking direly behind but all new software is following this model and we are relentlessly working to add all other SW components under active development to this model.

The last key aspect of test automation is reliability. Regular failures due to badly designed tests will cause failing test jobs to be ignored, leading to gradual test deterioration. This matters a great deal, especially on the e2e test phase – since e2e tests are not gating the PR merging to the main line, it makes it easier for developers to ignore. Rather test less and more reliably, than have complex brittle tests.


After reading the above “Wikipedia” page of the testing and falling asleep, here are a few key points to take home.

  • Use the test pyramid as a guideline to define and understand your test levels on CI
  • Aim to have a fast feedback cycle
  • Simple reliable tests over complex but brittle ones
  • Provide infrastructure to support the continuous integration with your own devices
  • Be “lazy” and automate all repetitive tasks
All blog posts