First of all apologies for the long delay with this. We have solved this problem with the latest firmware (1.6.13.b1). The issue is a bit complex and it's not because of a firmware bug, it's more because of an undocumented characteristic of the Sigfox network in RCZ2 and RCZ4:

There are 9 macro-channels with 2 micro-channels on each of of those 2 zones. However (and this is the undocumented part), only the first macro-channel is actually usable (for the time being). The Sigfox library itself behaves in a way that only the packets sent on the first macro-channel are transmitted properly (and the Sigfox library is a blackbox to anyone outside of Sigfox). The solution to this is to either call sigfox.reset() after every 2 transmissions and then wait 20s before transmitting again in order to comply with FCC regulations, or, as we have implemented it, handle this delay internally and only apply the amount of delay (if any) needed in order to comply. This latter approach is the one that we have preferred and therefore there's nothing to do at user code level besides knowing that more than 2 consecutive transmissions will have a delay in between. This is now documented in: https://docs.pycom.io/pycom_esp32/library/network.Sigfox.html

This characteristics of the Sigfox network are not tested during the Sigfox certification phase and also not very well documented, which is why it took us so long to fix it.