socket.send() stops working (Sigfox)



  • Hello, I hope this is the correct place for my problem and i hope my english is well enough.

    I'm working with a SiPy on a Pytrack. Both were working fine until I made a firmware upgrade yesterday
    The old firmware was release 1-13.0.b1, the new firmware is release:

    os.uname()
    (sysname='SiPy', nodename='SiPy', release='1.15.0.b1', version='v1.8.6-849-baa8c33 on 2018-01-29', machine='SiPy with ESP32', sigfox='1.0.1')
    

    The problem occurs when I call the method send() of the socket which should send out a message to the sigfox network. To investigate this I wrote a simplified program

    from network import WLAN
    wlan = WLAN(mode=WLAN.AP,ssid='sipy-pytrack2', auth=(WLAN.WPA2,'XXXXX'))
    from pycom import heartbeat, rgbled
    from time import sleep
    from gc import collect
    from network import Sigfox
    import socket
    from machine import Timer
    
    
    heartbeat(False)
    rgbled(0x110A00)
    
    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, False)
    sleep(3)
    
    timer=Timer.Chrono()
    timer.start()
    i=0
    
    while i<10:
        try:
            rgbled(0x000011)
            timer.reset()
            print('start '+str(i))
            s.send(bytes(6))
            print('end')
            print(timer.read())
            i+=1
            rgbled(0x001100)
            sleep(30)
        except Exception as error:
            print('error'+str(error))
            break
    

    The output of the program is (in the worst case):
    '''start 0'''
    The LED stays blue and nothing seems to happen. Sometimes I reach the output "start 3" (best case so far), sometimes "start 2" and so on. I can also enter "s.send('test')" via console (Atom with pymakr package) and it sometimes seems to do nothing. Also CTRL+C doesn't work to abort it, I have to press the resetbutton.

    Sadly I can't check what is recieved by the backend because the location I'm working at has no sigfox coverage.

    Can someone help me with this problem?
    Can i view/edit the code of the method send() somehow to get more information (at which point of the code does the problem occur)?
    Has someone experienced the same or a similar problem?



  • An additional update: While it is emitting some sort of radio signal, I have yet to have one successful sigfox connection on a long distance drive test through various coverage areas. Perhaps Sigfox has its own issues, but this seems a bit odd not one came through.



  • @losi

    Hi, almost the same proble of @losi. FiPy become quite warm and in addition it send Sigfox data only with command sent by REPL interface, after a "timed" wakeup from deepsleep or with external interrupt, no data is send. Still having a current absorbtion of 30ma when battery power and peak of 270 ma while Sigfox is trying to transmit. Can be a defected FiPy or expansion board ( CTS and RTS pin removed )? Are there new hw version of the FiPy board? Thanks, Andrea

    @losi said in socket.send() stops working (Sigfox):

    @heikowalter said in socket.send() stops working (Sigfox):

    From the new firmware(v1.17.0.b1) release:

    esp32: Fix Sigfox lock-up on the SiPy.

    Does this comment mean the problem described in this topic?
    If yes, can someone confirm that it realy works?

    I have done some extensive testing, and while it does work better, it will still get stuck transmitting and become quite warm.

    Re: socket.send() stops working (Sigfox)

    Hi, almost the same proble of @losi. FiPy become quite warm and in addition it send Sigfox data only with command sent by REPL interface, after a "timed" wakeup from deepsleep or with external interrupt, no data is send. Still having a current absorbtion of 30ma when battery power and peak of 270 ma while Sigfox is trying to transmit. Can be a defected FiPy or expansion board ( CTS and RTS pin removed )? Are there new hw version of the FiPy board? Thanks, Andrea



  • @heikowalter said in socket.send() stops working (Sigfox):

    From the new firmware(v1.17.0.b1) release:

    esp32: Fix Sigfox lock-up on the SiPy.

    Does this comment mean the problem described in this topic?
    If yes, can someone confirm that it realy works?

    I have done some extensive testing, and while it does work better, it will still get stuck transmitting and become quite warm.



  • From the new firmware(v1.17.0.b1) release:

    esp32: Fix Sigfox lock-up on the SiPy.

    Does this comment mean the problem described in this topic?
    If yes, can someone confirm that it realy works?



  • @seb After further testing with older firmware, I can confirm that SiPy-1.15.0.b1.tar.gz and SiPy-1.14.0.b1.tar.gz are buggy but SiPy-1.13.0.b1.tar.gz is good. I was able to send 50 messages without any crashes with SiPy-1.13.0.b1.tar.gz.

    Hope that helps!



  • @seb Thanks, that link explains the long delays I was observing that weren't present when I last updated firmware a few months ago. However, your documentation suggests the delay occurs after every 2 sends, implying that you can send twice quickly after first powering up, but I observe that it occurs after the 1st send and THEN after every 2 sends.



  • @daveatmac Yes, deepsleeping after every send is an effective workaround for now. It never crashes for me during the first send.



  • @seb No, no improvement with 1.16.0.b1. Here are the characteristics:

    1
    It still often completely locks up during the send() command at a high current level (150mA) suggesting that the RF section is transmitting continuously. Pushing the reset button is the only fix. Sometimes I only get 1 message out before it locks up, sometimes 10 or more. I am not doing any resets or sleeps in between messages, i.e., a high-power application.

    2
    Creating the socket and deleting it before and after every send does not help. I am in zone RCZ4 and only 100m from a Sigfox tower and am only calling the following line once not every time I send a message:

    sigfox = Sigfox(mode=Sigfox.SIGFOX, rcz=Sigfox.RCZ4)

    3
    settimeout still does nothing.



  • @seb Sorry Seb, I've just upgraded my SiPy and run a simple test but I'm finding that the Sigfox socket hangs on the second message every time.

    Here's the code I used:

    0_1519157990086_main.py



  • Hi all,

    I have just retested this bug using the latest firmware and it no longer seems to occur. Can you all please update to 1.16.0.b1 and report back if this solves the issue?



  • @seb @aevraewrvaervea I'm in RCZ1. Since I introduced the workaround I haven't seen the stack hang. My application doesn't send many messages, in testing I'm sending them every few minutes. Perhaps one thing to note is that I was only calling this line once:

    sigfox = Sigfox(mode=Sigfox.SIGFOX, rcz=Sigfox.RCZ1)

    Calling it more than once does cause a system hang, but since it's not intended that you initialise the modem multiple times that's understandable and not a problem.

    I've also just re-configured my app to use deep sleep, so because of the way that works the effect is that I only send at most one message between complete resets of the app. This too probably sidesteps the stack problem and most practical apps will probably have to work this way (unless they don't rely on battery power).



  • @aevraewrvaervea
    Are you perhaps in RCZ2 or RCZ4? If so there is a rate limit set in the firmware which would explain the 20s to send, please check the notice at the top of this page: https://docs.pycom.io/chapter/firmwareapi/pycom/network/sigfox.html

    In regards to the other issues, this has all been reported to the firmware team, I will report back as soon as I know more.



  • @daveatmac @seb I was having similar problems and tried your idea of "creating the socket, sending the message then closing the socket" every time but it doesn't help. I still get it crashing after about 10 messages and some of those messages take 15 or 20s to send instead of the usual 1-2 seconds. I'm also finding using s.settimeout(2) doesn't do anything when it should cause a timeout on almost every message because hardly any of them complete the s.send in less than 2 seconds. Does settimeout really work?



  • @seb Thanks for your reply. For the moment I've found a workaround. If I close the socket after sending a packet and then re-initialise it before sending the next one I don't encounter the stack blocking issue. Not a great solution but at least one that allows me to move forward.



  • @daveatmac
    There is a known issue with the sigfox stack blocking after sending a few packets. This is being actively investigated. In regards to blocking vs. non-blocking, it really depends on if your code relies on something occuring AFTER the data has been sent, for example going into deep sleep. With non-blocking sockets, you cant guarantee if the data has been sent. You could try setting a timeout on the blocking operations using the settimeout function



  • I've encountered the same problem. The first message after a board reset always seems to get through, but after that it is rare for two more to be transmitted without the board hanging. I'm using a SiPy module with a PySense carrier card.

    As Heiko did I'm using a blocking socket because I just followed the example code in the documentation. Are there any undesired side effects of using a non-blocking socket?

    Thanks



  • @heikowalter said in socket.send() stops working (Sigfox):

    Can i view/edit the code of the method send() somehow to get more information (at which point of the code does the problem occur)?

    Hi,

    I have been able to replicate this bug, we are now investigating the cause.

    In the mean time to answer some of your side questions. The reason Ctrl+C stops working is because you have set the socket to blocking, when the socket blocks it stops all other code running on the device, including the code that detects the Ctrl-C keypress. If you find yourself stuck by this you can use the safeboot procedure to prevent boot.py and main.py from executing (https://docs.pycom.io/chapter/toolsandfeatures/bootmodes.html). If you want to look at the code for any of the modules included with our firmware you can find them here: https://github.com/pycom/pycom-micropython-sigfox/tree/master/esp32/mods, if you wish to modify them you will need to recompile the firmware yourself.


Log in to reply
 

Pycom on Twitter

Looks like your connection to Pycom Forum was lost, please wait while we try to reconnect.