@robert-hh It seems like a firmware upgrade on the LG308 did the job. The code is working fine and I can successfully join the network without retrials. [image: 1608308922946-1e386495-77b7-43c2-be79-44b46086f4c1-image.png] Thanks!

Topic is old but I want to bump it anyway. Same problem here. Received message with this method is unusable. This might be why (from ESP32 documentation on UART wakeup): "Note that the character which triggers wakeup (and any characters before it) will not be received by the UART after wakeup. This means that the external device typically needs to send an extra character to the ESP32 to trigger wakeup, before sending the data."

After mastering LoRaWan node configuration to send packets (uplink), yes, it is possible : to read LoRa signal report if you configure a downlink (LoRaWan server -> LoRaWan gateway -> LoRaWan node); with Pycom MicroPython, use lora.stats(), which returns rssi, snr and sfrx of the last received packet (from a LoRaWan gateway).

...... a way to be more specific?

@yongyuan-wang you don’t need to repeatedly call anything to advertise. Just call set_advertisement to set parameters then advertise to start advertising and the BLE stack will do all the work. Also enable is an optional parameter, you can leave it out or set it to True to advertise.

@jcaron So you get a curve that varies during the whole awake time between 30 and over 100 mA. Ah I see. I think I confused myself when I saw the LoRa transmit in the documentation of 105mA and thought it was somehow the overall current draw of the awake time because it was similar to the 100mA you had mentioned before but I get it now. So the current draw is about 100mA (conservative) on average over the awake time. You've been a really great help. Thanks for all your patience :)

@justin said in LoPy4, Power Amplifier: Is Sigfox driven by SX1276? It is. The SX1276 can also provide the modulation required for Sigfox, even if that may not have been the primary focus.

Right, we do not have specific documentation on that (yet) I believe, as in my experience its a fundamental feature of microcontrollers in general. Could you recommend a place where you would expect this information? Gijs

Hi, At the moment, we are not planning on including this functionality as far as I know. Gijs

@Colin-Crook If you want full control the best option is to use raw LoRa, and then simulate what the LoRaWAN stack does (mostly adding quite a bit of overhead to the packets, including addresses, frame counters, checksums, etc.). Note sure how the frequency comes into play though, but my guess is that you're probably more interested in manipulating what is actually included in the frames, which (unless you modify the LoRaWAN stack), is probably much easier to do with raw LoRa.

Hello, Does it mean that dr=0 in the join will enable ADR? Or is there any additional paramters to set? Thanks, Nicolas

I've just changed the version to Pycom MicroPython 1.20.0.rc13 [v1.9.4-94bb382] on 2019-08-22; LoPy with ESP32 (legacy firmware) and light sleep works as expected. I'm not sure I understand the difference between different driver types, but I don't use pybyte, so it should be ok. Could it be a bug in the pybyte firmware?

Which network are you using? the error MBEDTLS_ERR_SSL_CONN_EOF signifies an error in the SSL connection for end of file, or abrupt disconnection. This could also be due to a memory error in the urequest module. Through google I was able to find several solutions that you can try (you'll probably be able to find them yourself as well :) ) Gijs

I do not know of the difference between the firmwares, but you could use the git hash to find the exact one in the source (At least, I think that is supposed to work..) I believe this is the one you are looking for: https://github.com/pycom/pycom-micropython-sigfox/tree/7bc2e5cdd34b79c5fa9f493f3df831f57b0b12ce You can follow the instructions in the readme to compile one for yourself (check for the pybytes version, that is the one updated in this commit, among other things) For the actual issue, I have no clue tbh Gijs

@kjm that’s a limitation of the ESP32 itself. There are two ways to wake up from deep sleep on pin state changes, and both require you to specify the target level. See https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/sleep_modes.html for details. There may be alternatives using the ULP co-processor, haven’t checked if that would actually be possible.

Did you found a solution or coded something already? Having seen and been teased (https://youtu.be/DInzisjAyh4) with mesh messenger demo, what is also available on github (https://github.com/pycom/pycom-libraries/tree/master/pymesh/mobile_app) hoping to get the LoPy/FiPy side of code example as well, to at least play around with the mesh demo app and test ranges in different environments while PyGo's are coming (month by now and counting).

@Stefano-Floriani That's better. The capacitor worked here as a means to suppress noise. You can also increase the value of R7 to 27k. Then the value should be at about 150.

SOLVED: The line adc.vref_to_pin('P22') was causing this. Should only be run for calibration with a multimeter for the vref value once, is the current conclusion.