Sipy only send first message when restart

[bucknall]

Hi @irvinvp could you post your complete snippet with the loop for every 5 minutes?

It may have something to do with how you are looping your code.

Thanks!

Alex

[irvinvp]

Hi @bucknall,

For now i'm sending manually, only typing s.send('message') every time.

Thanks,

Irvin

[bucknall]

@irvinvp can you show me your terminal after you send a message? It should return the number of bytes that were sent after each message

[irvinvp]

@bucknall Yes, every time returns the number of bytes, i'm try to send 12 bytes or less, with same result.

Some times take more time the return of the number, but if i restart the sipy the first message is send every time.

[bucknall]

@irvinvp If you placed your code into the main.py file then this should be normal behaviour if you restart?

Apologies, I'm not sure that I'm following exactly what your question is!

Thanks,

Alex

[irvinvp]

@bucknall The problem is that the following messages do not arrive, for example:

First i type this:
from network import Sigfox
import socket
sigfox = Sigfox(mode=Sigfox.SIGFOX, rcz=Sigfox.RCZ2)
s = socket.socket(socket.AF_SIGFOX, socket.SOCK_RAW)
s.setblocking(True)
s.setsockopt(socket.SOL_SIGFOX, socket.SO_RX, False)
s.send('message') # This message arrive to Sigfox server

then i type this:

s.send('message') # This message not arrive to Sigfox server

then wait and i type this:

s.send('message') # This message not arrive to Sigfox server

Then if i restart and repeat the process only the first message is arrived to Sigfox server!

[bucknall]

@irvinvp Ahh ok! I understand your concern! Let me give this a test and see if I can resolve your issue!

Thanks,

Alex

[iotmaker]

Do you wait some time between sending messages? are you on an area that is covered by Sigfox?

You could call the IotMx guys they manage the network. or check the sigfox api

Coverage API
Redundancy

Get base station redundancy for a given latitude and longitude.

Request

GET https://backend.sigfox.com/api/coverages/redundancy?lat={lat}&lng={lng}&mode={mode}
Parameters:

lat: the latitude.
lng: the longitude.
mode: the coverage mode (UNDERGROUND, INDOOR, OUTDOOR). This parameter is optional, default is INDOOR.
OUTDOOR: max link budget
INDOOR: link budget with dB margin
UNDERGROUND: link budget with dB margin
Response

{
"redundancy":3
}

Fields:

redundancy: the base station redundancy : 0 = none, 1 = 1 base station, 2 = 2 base stations, 3 = 3 base stations or more

[irvinvp]

@iotmaker My redundancy is 3, and the problem is only for messager after the first.
Always transmits without problems the first message every reboot!

[irvinvp]

@irvinvp said in Sipy only send first message when restart:

is 3, and the problem is only for messager after the first.
Always transmits without

[daniel]

Hello,

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.

Cheers,
Daniel