Hi, I compiled a firmware for you to use on a Lopy4 (here) to check the EAGAIN error cause. For a case without error, it will output the following: Pycom MicroPython 1.20.2.r4 [v1.20.1.r2-357-g6153b01d3-dirty] on 2021-01-18; LoPy4 with ESP32 Type "help()" for more information. >>> Running selected lines >>> >>> Not yet joined... Not yet joined... Not yet joined... Joined b'' [TASK_LoRa] CMD TX [LoRaMAC] returning status 0 > Pycom MicroPython 1.20.2.r4 [v1.20.1.r2-357-g6153b01d3-dirty] on 2021-01-18; LoPy4 with ESP32 Type "help()" for more information. >>> You should be able to use the script you already wrote, but if you want to use the example I used: from network import LoRa import socket import time import ubinascii # Initialise LoRa in LORAWAN mode. # Please pick the region that matches where you are using the device: # Asia = LoRa.AS923 # Australia = LoRa.AU915 # Europe = LoRa.EU868 # United States = LoRa.US915 lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.EU868) # create an OTAA authentication parameters, change them to the provided credentials app_eui = ubinascii.unhexlify('') app_key = ubinascii.unhexlify('') #uncomment to use LoRaWAN application provided dev_eui dev_eui = ubinascii.unhexlify('') # join a network using OTAA (Over the Air Activation) #uncomment below to use LoRaWAN application provided dev_eui #lora.join(activation=LoRa.OTAA, auth=(app_eui, app_key), timeout=0) lora.join(activation=LoRa.OTAA, auth=(dev_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...') print('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(False) # send some data s.send(bytes([0x01, 0x02, 0x03])) # make the socket non-blocking # (because if there's no data received it will block forever...) s.setblocking(False) # get any data received (if any...) data = s.recv(64) print(data)

@Gusti-Made-Arya-Wijaya I just looked the details for this little board. I do not believe that the TP4056 is suitable for your requirements. The documentation I found says that the module is not suitable for simulataneously charging a battery and supplying a load.

Hi. Is your computer detecting the device in the USB manager?. Weeks ago I managed some difficulties to update the firmware but nothing like not detection like you. I also did the Firmware update via Windows10 because in Linux Mint took a lot of time.

@Mao Thanks man issue is finally resolved.

@jefferson-ayala I am not on the latest version. It seems that main.py is never called. outcomment the last 3 lines of boot.py. You do not need to set the UART and main.py to the default values. Once this was problematic. Especially the UART redefinition. If main.py is called, you are waiting for at least one satellite to go on. This may never happens. Sadly there is no flush. You can either set to LED color or a sleep of 4sec after each print. So you can see better the last executed instruction .

Last week I did check out the code for a bit, and when no network adapter is explicitely specified, it should default to AF_INET (thats WLAN or LTE). Im not exactly sure what is happening on your end. Do you check whether the network is connected beforehand (ie wlan.isconnected() should return True, it could take a couple of seconds for the WiFi handshake to complete) Let me know what you find Gijs

You have reason, the problem related to my sensor. I plug the cables GND and 3V3 to the ESP kit instead of Expansion board, and it works. I tried to connect another sensor to Expansion Board, and it also works! Now I can receive [26,80]. Thanks you. Because the problem is not about software but hardware, so I will close this topic. Thanks for your help anyway

Using the timeout in the declaration as you did will give you results only every 30 seconds, please keep that in mind while testing. Im assuming you took the example from https://github.com/pycom/pycom-libraries/blob/master/pytrack-2/main.py, which should work fine in any case. NB. on the forum we communicate in english, I would appreciate it if you could respond in english so other people can be helped as well :) Gijs

Thanks all for the help! :) @robert-hh @tuftec @jcaron

Thanks Robert for replying Much appreciated ...

In addition, I am not sure what is the samples per symbol of the Bluetooth signal in Lopy4. I noticed that I can change this value when I use matlab example to generate Bluetooth signal. [image: 1608889906305-2efe3a78-ffe6-4808-be1d-29d2a7c6e72c-image.png]

@M-m you need to tell the network (LNS) that your device is a class C device. This information is not sent in LoRaWAN joins or other MAC commands, you need to configure it separately (usually in the place where you set up the device in the network, where the IDs are).

Yes, in principle Sigfox supports encryption between a device and the Sigfox backend. Note, that this does not give you end-to-end encryption between the device and your own service/application/whatever you have behind the Sigfox backend. However, no, the implementation in the Pycom devices does not have this support. So either way you would have to roll your own.

@M-m unless you tell us what region you are in and the settings of your network+gateway (and the packet loss you observed, ideally with logs showing channels used), I think it’s going to be very difficult to know what your configuration should be and why those changes help (or if another configuration would help even more).

@Gusti-Made-Arya-Wijaya I've fixed this problem, basically, data from Modbus Slave is byte HEX, so I think to not use conversion function in serial.py. and here is the result, TTN receive HEX data from lopy4 [image: 1608527470430-sukses-baca-dan-kirim-slave.png] Thanks all for the replies

@Jamie In US915, RX2 uses a fixed channel and DR, which is by default downlink channel 0 (923.3 MHz) at DR8 (SF12BW500). This can be changed by the network through relevant MAC commands. You shouldn't have to specify anything on the LoPy. You only pick uplink channels, but class C downlinks automatically use either the default or whatever the network says. What LNS are you using? What are the settings of your LNS and gateway? Note that you must explicitly configure your LNS to let it know the device is class C, the device does not say anything about it to the network. If you don't, the network will continue to consider it's a class A device and send downlinks in the usual RX1 and RX2 windows.

@PycomDev-RedMountainMakers The ESP32 has three UARTs. The first one, UART0, is used for the Python REPL. The other two may be freely available. I say may, because on FiPy and GPy UART2 is used for the communication with the LTE modem. So there are not three UART devices available. You should be able to use uart.deinit() and the UART constructor to change the pins assignments. You should expect that on any change the receive buffer's content is lost. If your sensors are constantly sending, then this should not be an issue.