Here is a list of common pitfalls encountered when integrating the Oyster Sigfox into a 3rd party system.

Other message types are not handled.

The Oyster mostly sends message type 0 (position data). However, it does periodically send Device Profiling Stats (message type 2). These other message types must be interpreted separately and specifically, or else you will get strange lat/long results. Pay attention to the first byte of the payload, which contains the message type.

The symptoms of this are:

1. "Device usually works correctly, but occasionally a bad position is received." What is actually happening is the device is sending a different message type periodically, and it needs to be interpreted differently.

Downlink data mode not set to callback.

The device type must be configured correctly. The downlink data mode must be set to CALLBACK:

The symptoms of this are:

1. Regular device transmission after a reset. The backend will respond to every device downlink request. The device will in turn respond that it does not understand the downlink, reset, and request another downlink.
2. Message type 1 is transmitted in response to the downlink. The "accepted" bit will usually be false.