FiPy Sigfox - downlink ends in OSError: [Errno 100] ENETDOWN

[dmnk]

Hi together,

i've managed to get some packets into the network, now i'd like to get something back ;)

however, i'm miserably failing at that task.

is something wrong with my code?

this:

sigfox = Sigfox(mode=Sigfox.SIGFOX, rcz=Sigfox.RCZ1)
s = socket.socket(socket.AF_SIGFOX, socket.SOCK_RAW)
s.setblocking(True)
s.setsockopt(socket.SOL_SIGFOX, socket.SO_RX, True)
s.send(bytes([0x00, scale(lux.light()[0]), 3, 4, 5, 6, 7, 8, 9, 10, 0xAA, 0xFF]))
retval = s.recv(32)
print ("received " + retval)

gives me:

Traceback (most recent call last):
  File "<stdin>", line 164, in <module>
OSError: [Errno 100] ENETDOWN

whilst the backend shows me:

    Status : [ACKED]
    Data (Hexa) : cafecafecafecafe

any idea what i'm missing here?
It's definitively not the link - sender and receiver have free LOS.

Additionally i've checked if it might be the Sigfox operator - nope. Different Country - same misbehavior.

avgSnr=20.74
rssi=-52.00

Used HW: FiPy on '1.17.5.b6' and on new 1.18.

Best regards
Dominik

[Eric73]

@dmnk said in FiPy Sigfox - downlink ends in OSError: [Errno 100] ENETDOWN:

Hi Dominik, i have a question about your post. Sorry i am not an english native speaker, what does 'free LOS' mean ?

In posted code you request a downlink, a sigfox downlink come after an uplink and in sigfox backend you must have defined a 'BIDIR' callback function to produce data in downlink (have you do this?).

You said

Status : [ACKED]
Data (Hexa) : cafecafecafecafe

Data showed here cannot be a valid sigfox uplink payload, as this size is more than 12 bytes (max sigfox upload) and even worst in downlink as maximal size is 8 bytes in sigfox protocol so what this data mean ?

In my test ENETDOWN occurs when no data is sent by the sigfox's backend (or before i do the PAC declaration in sigfox backend)
Hope this help you

[dmnk]

Hi @Eric73
Thanks for your reply.
LOS is kind of a network term, line of seight. So no obstacles between sender and receiver.
I know that the downlink should be established after an uplink, therefore the s.send command where the socket s is configured to submit the "request downlink" flag (last parameter -> true)
The status [Acked] with the attached data is directly out of an sigfox example. if you look close enought you'll see that the data is hex encoded -> 2 chars = 1 byte, exactly eight byte.
To let that happen, the sigfox backend has to be configured for the downlink.

So from the network site, everything is done the way it should. Nevertheless the fipy NEVER came up with anything else than the ENETDOWN error, when i've requested downlink data.

What's your hardware module? Fipy, Sipy, ...?

Your answer is much appreciated, and is helping me to clarify the problems circumstances.

[Eric73]

@dmnk Hi Dominik, my hardware setup is Lopy4 (but in my job, all along the day i work with sigfox device as embedded software engineer on our product). So, your screenshot make sense, in backend 's point of view downlink was correctly send to base station.
But as i can see, your link quality is not so good as you said. In sigfox protocol downlink and uplink use two different signal (in RCZ1) uplink is done in DPBSK @100bauds and it's a narrowband signal (and base station can restore an altered signal and correct a frame even in case of serious disturbance), BUT downlink is only done in FSK, a weaker tx mode. So, have you try to do your up/down request outdoor and/or with a different antenna ? (what antenna did you use?)
Another point, keep in mind that sigfox downlink is theoricaly limited to 14 downlink/day, at each downlink base station is free to drop your request in order to keep some free frequency spectrum to serve other device and send/drop your request in better effort mode. (Frequency area used in downlink is not the same area that uplink frequency) [in RCZ1]

[dmnk]

@eric73 i've hestitated to provide that screenshot as the last entries where from my test within simplecell's range.
to convince you that my regular setup should have a connection quality where down and uplink should MUST work:

it's a dedicated test station, the tx power is limited, therefore not 5 green bars in the table.
if that setup isn't able to transmit both ways, i'll eat both parts, and the dove i'd have to use as fallback.
i don't think that there is another client in the ~2 km radius,

but your note with FSK seems to get me into the right direction.
i've checked my contact at sigfox who assured me that the downlink is sent with a higher TX power, which should make it impossible - for an IoT device - to send a packet which gets received by a base, and don't hear the response.

https://forum.pycom.io/topic/2574/sigfox-has-no-attribute-fsk-fipy/3
@seb could you please confirm that the broken downlink stems from the same cause?
is there any ETA on when this will be fixed?
how did you get this thing through sigfox's certification process without downlink.

kind regards

[Eric73]

@dmnk Sorry dominik, i have emergency on other projet and cannot do some test with my lopy4. In fact, as i previously said i work with sigfox on my company product. We send setting via downlink on our device to start them when necessary. For a 10K fleet device, 95% of them have receive downlink after 3 downlink (and aprox 50% one first downlink), so definitly for me downlink is more weak than uplink.
As i understood the ohter post from xorlover and answer from seb, it's sigfox FSK ptp that is not yet present in firmware.