Indeed we have the "socket.accept ()" method in the first LoPy, but the problem was in the pointing address to the other LoPy which was wrong. It's already solved, thank you!

@jcaron The issue has been worked out and it works quite well now! Thanks a lot!

I am seeing a similar issue with my FiPy device (when using NB-IOT communications). I suspect the problem has something to do with the sockets code and not specifically LoRa. I am running the latest version of software on my FiPy.

I'm trying to use nano-gateway with loraserver.io but I can not downstream messages just upstream. Can you share if you had the same problem?

I'm trying to use nano-gateway with loraserver.io but I can not downstream messages just upstream. Can you share if you had the same problem?

I'm trying to use nano-gateway with loraserver.io but I can not downstream messages just upstream. Can you share if you had the same problem?

I'm trying to use nano-gateway with loraserver.io but I can not downstream messages just upstream. Can you share if you had the same problem?

I have exactly the same behavior you describe. Downlink do not get messages. Could you find a solution?

I switched the code on the gateway to the single channel version and TTN shows an output as intended. You are probably correct about the chip getting confused about which channel it is listening on. Thank you!

@goldfishalpha It is possible, and not too complicated. You have to to a few changes to modlora.c, application.mk and a few of the region specific files, mostly along what is present for e.g. region EU868. But you would have to maintain that every time that the firmware is changed.

@Wolli01 Both SX1272 and SX1276 oprate at a range of 1.8 to 3.7 V, the esp32 at a range of 2.6 to 2.6 V. So 3.33V should not be a problem. The voltage should however be taken at the 3.3 V output of the LoPy, to be sure, that the supply arrives. But there may be short supply drops during send bursts. If you have an oscilloscope available, try to trigger for voltage drop sat the 3.3V output. The current demand for WiFI is higher than that for Lora, 250mA worst case for the ESP32 vs. 120mA worst case for the SX127x, but I doubt that these high power output modes for Lora are supported. So yes, worst case can be in the range of 500mA. Given your power consumption, battery impedance, especially at low voltage, may more be an issue than total capacity.

i think the function does not return any thing. it just connects the internal 1,1 V to a pin so voltage does not become anything. what software version are you running. if i run adc.vref_to_pin('P22') i get nothing if i run voltage = adc.vref_to_pin('P22') print (voltage) i get None

It's a little odd that the LoPy includes the mesh functionality but the LoPy4 doesn't in rc8. I would have expected it to be the other way around based on the increased memory capacity on the LoPy4. Will there be build options available via the firmware update tool to include mesh or not for all supported devices? Thanks Andrew

@asb No, because the reset pin, connected to CHIP_PU on the ESP32, actually switches the power. That is in the data sheet: CHIP_PU High: On; enables the chip Low: Off; the chip powers off

@kps Thanks for the help. It 'almost' worked. It sent the first "ping" successfully, then printed "sending ping" and was never heard from again. If I use the reset button on the LoPy4 to get back to REPL and try to run the same code again from Atom, then the code won't send even that one ping. However, if I power-cycle the unit and run the same code from Atom again, then it completes the send command successfully exactly once before it hangs on the second send. Could this behavior be a clue? Why does the "hard" reset matter?

@goldfishalpha LinkADRReq is only send by a lorawan base station/gateway . Pycom device as only a device stack not a gateway one. So a pycom device can only process received LinkADRReq if you have the correct setting in lora constructor from documentation, set adr to true and the gateway will send you Linkadrreq IF needed by link quality transmission lora.init(mode, * ,region=LoRa.EU868, frequency=868000000, tx_power=14, bandwidth=LoRa.BW_125KHZ, sf=7, preamble=8, coding_rate=LoRa.CODING_4_5, power_mode=LoRa.ALWAYS_ON, tx_iq=False, rx_iq=False, adr=True, public=True, tx_retries=1, device_class=LoRa.CLASS_A)

@xsklero There's an example of a BLE server here: https://docs.pycom.io/firmwareapi/pycom/network/bluetooth/gattscharacteristic.html Whatever you try, if you have an issue, you need to be more specific. Tell us what code you are using and the exact issue you are facing.

@caroline It's simple, just change one line of your code def pin_handler(arg): global bouton_appuyer bouton_appuyer=bouton_appuyer+1