SiPy Sigfox Antenna link quality

[iotmaker]

I am doing testing and i also have a Atmel Sigfox dev kit.

doing a test today sending data every 20 seconds( where i live the sigfox signal is not everywhere) on my way to work. i saw on my back end that the atmel device was able to send around 15 messages and my Sipy only 2.

is there any way to improve the link quality? on the sigfox backend i get

[daniel]

Hello,

Are you running the latest firmware version on the SiPy? On which Sigfox zone are you (1, 2 or 4)?

Cheers,
Daniel

[iotmaker]

Zone 2 which will be the US in Houston Tx..

[iotmaker]

i think i have the latest firmware, but i will update it just to be sure.. still compared with another sigfox device i have, it has problems.

i know houston, does not have the best sigfox coverage and i have not being able to get information of where the closes antena from sigfox is..

[daniel]

@iotmaker what problems do you see when compared to another Sigfox device? The SiPy in your zone has 22.5dBm output power and -126dBm Rx sensitivity. It passed all the Sigfox certification tests.

Please let me know in detail what problems you see as probably those are related to MicroPython and not the Sigfox stack. Thanks!

Cheers,
Daniel

[iotmaker]

let me first find out where the closest antenna is..

i will report more today since i will be going to houston downtown today, sigfox coverage should be better there.

[daniel]

@iotmaker I think your issues might be related with the config word. What Sigfox config word are you using on the Atmel dev kit? Perhaps setting this same config word on the SiPy will lead you to having the same results. The config word configures the channels that are used for the uplinks, which might explain the you only received 2 messages from the SiPy during your initial side by side comparison.

On the SiPy:

from network import Sigfox

sfx = Sigfox(mode=Sigfox.SIGFOX, rcz=Sigfox.RCZ2)
sfx.config()

Can you find out how to get the config word from the Atmel module?

I see that this is not documented yet so I'll make sure to fix that.

Cheers,
Daniel

[iotmaker]

i dont see any documentation about .config() on the pycom website

[iotmaker]

I run the config and go this

and according to atmel the default frequencies are the same

what does the 511 mean on the sigfox device

[iotmaker]

still having issues here in Houston. Could you check the signal integrity here in houston, or how many antennas they have.. i have not been able to get that information from them. but you guys have more leverage.

[jmarcelino]

@iotmaker
Have you tried querying the Sigfox coverage API?

A new API is available to provide coverage levels for any location in all public territories.
This API api/coverages/global/predictions uses both GET and POST methods.
For each input location (x,y), API results contain radio margin value in dB for the three best serving cells.
Through this API, power efficient business applications can be developed such as coverage checker interface or object/solution deployment planning.
Please check API documentation for full description.

[iotmaker]

@jmarcelino

thanks i just saw the documentation. i will try it out, because i did put the coordinates but i was not able to make it work.. do you know what format the latitud and longitude need to be... ?

[iotmaker]

well something might be wrong but the api shows as redundancy 0 an Global Coverage API (Single point) show 0

i dont think is updated for north america

[nicolsc]

Hi @iotmaker

I'm forwarding your feedback regarding the API to the team

It's most likely a bug along the lines of "devkit is registered on Sigfox France and cannot see Sigfox US network coverage" + says zero instead of a proper warning

[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