My Oyster seems to be in a downlink request/ack loop? 

Why is my Oyster sending so many message type 1's?

One of the most common setup mistakes we see is setting "Downlink mode" to DIRECT. It should be set to CALLBACK. 

This is accessible from Device Type -> Edit Device Type (click on the name you wish to edit) -> Information Sheet -> Edit (top right) -> Find Downlink Data -> Ensure it is set to CALLBACK.

If this is left as DIRECT, the Sigfox backend will reply to each downlink request with "Downlink data in hex". The device will reply with a "downlink acknowledge" message (type 1), probably indicating the downlink was not accepted. It will then request another downlink and continue this cycle until the downlink budget runs out.

Is the standard configuration to request 1 downlink per day?

The Oyster budgets one deterministic downlink every 23.5 hours.

On the One plan, it budgets an additional random downlink request every 8 transmissions on average.

On other plans, it budgets an additional random downlink request every 64 transmissions on average.

Does the Oyster only request a maximum of 1 downlink per day even if the number of "heartbeat" messages are increased?

The deterministic portion of the budgeting is independent of the number of transmissions.

The random portion will scale with the number of messages.

Can the Oyster downlink message be disabled if Budget Plan is set to Subscription Level "One" and Heartbeat Message is disable

No. The Oyster downlinks whenever it has downlink budget during an uplink.

By setting the heartbeat to a very large value you can delay the uplinks and downlinks.

But since heartbeats can’t be disabled in the latest firmwares, you can’t prevent uplinks or downlinks entirely.

What would happen if the Oyster did receive an invalid downlink payload? Without any meaning for the device, would it be automatically rejected by the device?

The firmware checks to see if the downlink type is within a valid range as an initial check.

The Oyster will save all received values into flash, then reboot and attempt to use them.

If the values are invalid, they will be validated when the parameters are loaded from flash.

This may lead to undesired behaviour, as random data will often end up being valid, but undesirable.

So for instance the heartbeat period could get reprogrammed to a large value, but the Oyster won’t allow it to be disabled.

Have you ever observed an Oyster with its standard configuration not requesting a downlink message once a day?

No. If you have Sigfox reception, and the callbacks are configured correctly, we expect it to work 100%.

Sending Sigfox Downlinks