Hi @joseph, No, not yet. I have spent a few days on it, but no progress. I keep getting Connection refused when trying to connect, so something must be wrong with my server code. Have you tried connecting it to a different device (e.g your computer)?

Hi @sh4nnongoh, Please check this post for updates about the modem upgrades. Hope this helps!

I've got an update. Today, I tried updating to the latest Sequans firmware and experienced strange issues. I tried updating to the latest firmware, downgrading to earlier release firmware, still problematic. Leaving the modem at 1.17, I unplugged and left it alone for a while. A few hours later, reconnected and tried running the exact code in this thread. So, at this point, the FiPy firmware and modem firmware are identical to when I first experienced these issues. This time, everything worked. I could successfully open sockets, send receive data, etc. This allows me to close out my evaluation of the FiPy modem. It seems there are still some major functional and reliability issues to be resolved from all parties, Monarch/Sequans, Pycom, and Verizon. I'll revisit this in the future and in the interim, drop in on the forums from time to time to see what current user experience has been.

@pmst It's not yet possible through the firmware updater tool but if you have Python3 + PySerial on your PC you can update through serial. See https://github.com/pycom/pycom-libraries/tree/master/lib/sqnsupgrade for more details. Let me know if you have any issues.

@rskoniec Hi, Only one of my Gateways out of two accepted join request, but still on the terminal I got the message as not yet joined. I saw the device eui displayes in Gateway join request message is APP eui which was false. I included device eui also in my code(Also I cant be very sure if it is what got my device to join but it worked for me). By the way I used sample code available on pycom docs for LoRaWAN OTAA. # create an OTAA authentication parameters device_eui = binascii.unhexlify('FFFFFFFFFFFFFFFFF') app_eui = binascii.unhexlify('FFFFFFFFFFFFFFFFF') app_key = binascii.unhexlify('FFFFFFFFFFFFFFFFF') # join a network using OTAA (Over the Air Activation) lora.join(activation=LoRa.OTAA, auth=(device_eui, app_eui, app_key), timeout=0) # wait until the module has joined the network while not lora.has_joined(): time.sleep(2.5) print('Not yet joined...') # create a LoRa socket s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) # set the LoRaWAN data rate s.setsockopt(socket.SOL_LORA, socket.SO_DR, 5) # make the socket blocking # (waits for the data to be sent and for the 2 receive windows to expire) s.setblocking(True)

@amket Thanks for the feedback, I'll look into adding some output such as "Connecting to Wifi network..." to make it more clear what is happening.

@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.

Note that the code above was inside a class with a contained 'lora' object. This will work better with your code snippet: for index in range(0,8): lora.remove_channel(index) for index in range(16,65): lora.remove_channel(index) for index in range(65,72): lora.remove_channel(index)

Later I realized I needed to download the pycom libraries in https://github.com/pycom/pycom-libraries. There was the mqtt lib and now it works. Isn't this supposed to be in the online documentation? Thank you.

@nicolac Yes, you have to update to the lastest firmware, which is like 1.17.3.b1 or later. You can tell the firmware version by the commands: import uos uos.uname()

@camdenkrupala You can already set an APN manually by doing lte.send_at_cmd('AT+CEREG=2') time.sleep(2) lte.send_at_cmd('AT+CFUN=1') time.sleep(1) lte.send_at_cmd('AT+CGDCONT=1,"IP","YOUR_APN_HERE"') time.sleep(2) while lte.isattached() == False: time.sleep(1) lte.connect() while not lte.isconnected(): time.sleep(1) print("connected")

@dylan Hi Dylan. I am using MQTT constantlty over CAT-M1 on Telstra. I am only using. lte.send_at_cmd('AT+CGDCONT=1,"IP","telstra.internet"') lte.send_at_cmd("AT!=\"RRC::addscanfreq band=28 dl-earfcn=9410\"") lte.send_at_cmd('AT+CFUN=1') And have not had to resort to the additional AT commands you are using. I have also found the reset the modem if I have lost the connection and am reconnecting without a power cycle. lte.send_at_cmd('AT^RESET') Other than that its working very reliably for me. I am not using mqtt but using the AWS client (not to connect to AWS) as I need TLS with certificate support. We use Losant. They do support port 1883. T

Figured out the issue. Looks like the FiPy was consuming more current that my USB was able to deliver even though it was just running the sample PyMakr code of changing LED color. I connected a LiPo battery to it and didn't have an issue since. For those interested in figuring out how I got to this: I removed the FiPy module from the PySense Connected through USB to the computer and checked device manager for a new COM port If present, then PySense is fine. Without removing the USB to the PySense, I connected the FiPy and was able to program it. With the above basic steps you can determine if the board is actually bricked or just requires power.

Hi @turbolego Power consumption will vary with usage, you can find all the details on the datasheet: https://docs.pycom.io/chapter/datasheets/downloads/fipy-specsheet.pdf

@grantosw Glad I could help. ;o)

@dylan It is hard to believe that this is the reason, because the standard value for sys.path is ['', '/flash', '/flash/lib']. Since main.py resides in /flash, any code to be imported may reside at that place too, like also in /flash/lib or the actual directory (frisdt entry). The latter may be the a cause, if you have multiple copies of your code, good and bad ones, on the file system.

@akshayjames I think the problem is the button on the Pysense goes low when pressed, not high, so you want to wake up on low.