@testos Yes, you need to connect to the external IO header below the fipy. And you have to specify these Pins, when you open the UART, most likely UART1. On a Fipy, two of the three UARTs are already used by the firmware UART0 and maybe UART2. You have to try.

@smnc As prerequisite for a ABP join you have to register an applications and in the application your device at the TTN server. See https://docs.pycom.io/gettingstarted/registration/lora/ttn.html If during device registration you select ABP, the device address and communication keys are generate by the server. This data, device address, network session key and application software key, have to be used in your script. You just copy the from you web site and put them into your script. This data will not change, unless you ask at the server to do so. TTN has a message playback protection. That might be a problem during testing. You can disable that in the device setting at the TTN server. To be able to exchange data with the TTN server, you need a node (you Fipy) and a gateway. If there is a gateway close enough you can use that one. Gateways typically accept messages from any node. LoRa uses vertical polarity, so put your antenna upright. Not doing will not harm your device, but lower the chance of successful communication.

@john-baird Can you try this? https://forum.pycom.io/topic/4022/unable-to-update-gpy-modem-firmware/4

@emmecilab I have only managed to see this when I've done something like put the module in the wrong way round or I'm using a usb cable that makes a bad physical connection. Im sure you already have but could you try removing/reseating the module in the expansion board and trying again. Same with the USB. If its still failing. drop a ticket to support@pycom.io or pm me on here and I'll help get this sorted.

@robert-hh said in no can connect to vodafone spain NB-IOT with FIPY: The second number is the bit error rate (ber), whic is not know beforehand. So it means now the device detects is a proper signal. then. then, now I understand that it had a good signal, but the fipy was trying to attach herself all night, and she did not succeed. it's just waiting, or we should give it the command to attach repeatedly ... On the other hand, I'll check the commands you indicate

@kevin Best I can tell, Jersey Telecom is Things Mobile. My SIM cards came with a +88 phone number.

Hi, Have you considered a normal socket connection, and simply AES encrypting your data during transmission? You should be able to smash a checksum of the encrypted message down to like 4 bytes, and then include a delimiter sequence to snip the checksum off the datagram. You can use SSL to fetch the initial AES key from your backend, and then use that key in the future over normal network sockets. Sure, you might get MITM, but who cares, if the messages are encrypted and checksummed. Can't help with the AWS stuff, we just push messages to our own backend servers directly.

Hi @naveen, Sorry I'm late to the party here, but I believe that the PyMakr is the "expansion board". Take a look at the back of your PyMakr and it should say Expansionboard v2.X or v3.X. You should be able to update firmware using your PyMakr and this tutorial. https://docs.pycom.io/gettingstarted/installation/firmwaretool.html Hope this helps!

The LoPy4 I can get it down to 0.076A on 5V (*) The FiPy is still dramatic ... even with the newest firmwares? (*) MicroPython v1.8.6-849-83e2f7f on 2018-03-19

I would like to eventually do this as well. has anyone figured this out. how to allow fipy to act as wlan station and forward all data outbound via LTE?

Hello, here you have the link to the Espressif documentation (manufacturer of ESP32), but as far as I know Pycom firmware doesn't support ULP, so it can't be used. ULP (Ultra Low Power) coprocessor is a simple FSM which is designed to perform measurements using ADC, temperature sensor, and external I2C sensors, while main processors are in deep sleep mode. ULP coprocessor can access RTC_SLOW_MEM memory region, and registers in RTC_CNTL, RTC_IO, and SARADC peripherals. ULP coprocessor uses fixed-width 32-bit instructions, 32-bit memory addressing, and has 4 general purpose 16-bit registers.

@matt You should consider checking the connection state. ( Various brokers may time the connection out at the other end.) and then possibly explicitly closing the connection and re-connecting. I am using the core of the AWS MQTT package to talk to Losant and had to deal with the connection status and reconnections. That package maintains the connection in a seperate thread and the library doesn't clean up well so it needed some hacking. I have found the robust and simple implementations also needs some tweaking to be reliable on ESP8266 so it doesn't surprise me. You may even find it makes sense to disconnect after sending a message and then reconnecting later. Have a look at what the default timouts and the inactivity timeouts are set for the MQTT service you are talking to,

@nada-ali talk to each other over what network? The answers may be very different depending on context...

@sumanjha090 I assume you have some nodes around which send messages in the corresponding settings. Besides that, I would add a short sleep into the test_server() loop.

@stefan-1212 said in 1 Kilometer Wifi range on the FiPy: After that I also implemented the lr (long range) WiFi protocol supported by the ESP32 in the FiPy firmware What changes did you make?

@ioag Any chance you could share your Telstra connect code? I must be doing something wrong... Does anyone have an update on the stability issues?

@dommei That's means: "not registered, MT is not currently searching an operator to register to". At my device, it toggles between 2,0 and 2,2. The response you need is 2,1 or 2,5. The AT command set document is here: https://firebasestorage.googleapis.com/v0/b/gitbook-28427.appspot.com/o/assets%2F-LIL0iGdl11z7Jos_jpX%2F-LKN7scqKKkb6TqB3uYO%2F-LKN866sBhZY7wCqpQPA%2Fmonarch_4g-ez_lr5110_atcommands_referencemanual_rev3_noconfidential.pdf?generation=1534782117167775&alt=media