Ok I have print ready to listen . But I don't have a php to send data .

@mnovella Hello Thus, we can say that currently the LoPy4 does not support RejoinRequest natively, and that for it to happen the LoRa Module would have to be v1.1 compliant. Is this correct? LoPy AND LoraWAN operator have to be conform to 1.1 specification to use it. If yes, then given it's not natively supported, the responsibility for rejoining, etc. would fall on the application programmer (that is, me, or the code my LoPy has), just like you said that you start a join procedure after X time of not getting a downlink. Am I right? Yes, that's i do, after two week if no downlink as been recevied the device do a new OTA join request The 1.1 specs say that: "Once activated a device MAY periodically transmit a Rejoin-request message on top of its normal applicative traffic" It's very important when reading ISO/RFC/ETSI/official specification to be veray careful to the use of 'MUST',"MAY" and 'SHOULD" and there's indeed meaning. The low-level stack MUST support processing RejoinRequest but it's not mandatory that the application use it or is allowed to use it. That "MAY" part was the one that made me dubious if it was supported by the device or not... so I guess that even if/when Pycom supports LoraWAN 1.1 it will be up to Pycom to decide if/when to do the RejoinRequest if I'm not mistaken... I don't know what pycom will do when they will working to 1.1 port, but for me it's a "No" if i have had to vote, sending a new RejoinRequest is IMHO and application job and not a low-level stack/driver job. However, RejoinRequest is not send by a device, it's send by the network. When you do roaming (even in same country) you cant be in a specific area where some frequence channel is unusable (jammed), the network send to the device a RejoinRequest, the device perfom a new joinrequest and in the answer it receive a new channel list used in the area (frequency plan). If your device is static you don't have to think about this. My device perform new joinrequest as it's a moved device and can be for a long time out-of-network and when it come back is framecounter is far from when it leave the network and we don't receive anymore it's frame if we don't do a new joinrequest.

@ruky87 You can't type the two instructions in the REPL and have it work. The setup_sleep function will start making changes to the configuration of the PIC on the Pysense which will disable the serial port before you can enter the go_to_sleep call. You need to put both in a function and call that function so they're both executed at once. This is actually documented here: https://docs.pycom.io/pytrackpysense/apireference/sleep/ This has been discussed in the forum at least here and here.

@apo1997 said in problem measuring battery voltage: @robert-hh even in this post the most recent answer i found is: Pycom Expansion board v3.0: 115 kΩ / 56 kΩ Pycom Expansion board v3.1: Undocumented, probably like v3.2? (yes, prooved) Pycom Expansion board v3.2: 1 MΩ / 1 MΩ So this post is wrong too about the 3.0 version i am using. These threads are from 2018. We are living in 2020 in few months and pycom still didnt corecct it in their official documentation, thats weird. But ty for your answers, 2.067 is a very precise factor for my application! Hi, have you even got any offical documentation for the v3.1 of the expansion board? I'm also interested in a circuit diagram of the expansion board. I have strange things happening depending if the board is powered via USB or battery, but I'd really want a circuit diagram to first try and rule out a mistake on my side, before I try and log a "bug"... Also explaining my issue would be much easier if I had the right info...

@Xykon Hi, how could I make sure I am using an unique MAC?, thanks

@philberingar You may want to check lora.stats(), specifically sftx. The issue will be that this tells you the data rate of the last frame sent, not the next one, but IIRC ADR will only move the DR up or down by 1 at a time, so it might be a good starting point.

Actually it joined the TTN network from my home location. But it needs a lot of time, so I guess it's really issue with the radio layer. I couldn't do downlink though. Apparently my location (Sofia, Bulgaria) is poorly covered and I have to install my own gateway to be able to use LoRa around the area...

@daniel Has this been implemented? I'm on a LoPy4 and am under the impression that in wlan.ap mode the device can only be addressed via 192.168.4.1.

@robert-hh It's working now with your driver. Thank you very much!!!

Dear @asergio, @Stefano-Tondini and @gman, back in the time you have been recognizing this issue, it looks like connecting to WPA2-Enterprise was not supported by the ESP-IDF at all. Since October 2018, appropriate support has been merged [1,2] and we can confirm we are seeing these bits within the current Pycom fork [3]. So, we would encourage you to try again with one of the more recent releases of the Pycom firmware. With kind regards, Andreas. [1] https://github.com/espressif/esp-idf/issues/2181 [2] https://github.com/espressif/esp-idf/pull/2354 [3] https://github.com/pycom/pycom-esp-idf

I still don't understand what the dude is tryna say? Like these UC Browser what?

@erick_braun said in Lopy4 resets and loses code.: Has anyone had this problem and could help me? @jcaron said in Lopy4 resets and loses code.: Switching to the newer LittleFS file system available in recent versions of the firmware seems to help people. We want to second that as we also have been bitten by this behavior badly the other day [1]. Since switching to LittleFS, I have not seen any cases of file system corruption. [1] https://community.hiveeyes.org/t/fipy-verliert-programm-nach-power-off-durch-leeren-lipo-file-system-corruption-through-brownout-conditions/2057

@Colateral said in Lopy4 433Mhz example: Does anybody have 433Mz lora initialization? I don't actually know any details about this, but just stumbled over [1] the other day. So, @robert-hh might be the right one to ask about this. Please also see [2], where you might find more appropriate details to go ahead on this. [1] https://packages.hiveeyes.org/hiveeyes/foss/pycom/robert-hh/LoPy4-1.20.0.rc13-eu433.tar.gz [2] https://github.com/pycom/pycom-micropython-sigfox/issues/345

@dwing At the moment the only Bandwidth parameters that are accepted by the Pycom firmware are the 125KHz, 250KHs and 500KHz, depending on the region. To use other bandwidths supported by the SX1276 you need to modify the standard firmware.