It worked like a charm! I wasn't using that example, but the one I did rip off may have been based on it. Thanks!

@Paul-Thornton I have the same problem. Using the solution proposed by you does not fix the issue. I disabled also the firewall. Firmware: 1.18.2.r3 Pybytes: 0.9.10 Pybytes configuration read from /flash/pybytes_config.json WiFi connection established MQTT ERROR! Avialable Interfaces are down ERROR! Could not connect to Pybytes! This is error printed in the REPL console. @dnear1 If you want to connect to Pybytes and you did all the steps to register your board it is not necessary to connect to wi-fi in the boot.py The wi-fi network connection is handled by pybytes so basically the pybytes will not have the wlan interface.

@mk IIRC a reset will have the same effect as deep sleep, resetting LoRaWAN counters and other state. Unless you join every time you reset, you need to save and restore state.

Using the CLI I was able to program the L01. Thanks @robert-hh ! Just to recap: I use a L01 mounted in a custom board, which uses a FTDI as USB-Serial bridge Implement the two transistors that drive reset and IOO lines through DTR and RTS lines (https://dl.espressif.com/dl/schematics/ESP32-Core-Board-V2_sch.pdf). Using Pycom FW update tool does not work. Using CLI commands for the flasher tool worked (pycom-fwtool-cli -v -p COM12 -r --ftdi flash -t LoPy-1.17.0.b1.tar.gz) Special note: There is a catch as noted in https://forum.pycom.io/topic/4518/firmware-update-elf-vs-tar , that the latest relases are in *.elf format and must be converted to tar.gz.

@mk The physical size of the antenna does not matter. The electric properties count. If it has the proper impedance at the chosen frequency, it's OK.

@carne it works very well now ! I downgraded to 1.20.0.rc8 to use the border router feature. Thanks again !

Gern geschehen. Grüße aus Dänemark

Doesn't anybody have such a sensor running and could help me get mine to run?

The Pi3 has problems to use the UART and on board WiFi at the same time. If you need them both, disable the on board WiFi and use a stick

@Martinnn said in Please help me! Micro USB card to my Lopy and Wipy: The adafruit board you referred to is simply a breakout board for a micro USB connector. The ESP32 does not have USB hardware, so there's nothing to connect it to... If you want to connect to (the serial port of) the Wipy via USB, you need a USB to serial converter. Easiest is to buy an interface board like the expansion board. Thank you

@jcaron Thanks again for your help. Just uploading the profile of the test unit waking up, disabling the radios and going to sleep right away with a total of 15 lines of code for the record and future reference. Looks like the effect of program size is not much as you suggested. [image: 1554431061121-0292f0f1-67f1-4bd6-b189-40c8d344886b-image.png]

Nevermind, I solved it. I'm new to real time programming and apparently had to find out the hard way not to put code that's too time consuming into an ISR. I changed it so that the ISR just changes a flag and that the actual work is being done in the main loop.

@Eric73, thank you very much. Everything is functioning properly now!

If i read the code correctly ( https://github.com/pycom/pycom-micropython-sigfox/blob/master/esp32/mods/modlora.c : 1737 ) Pycom Software try to send joinrequest until timeout is expired. A joinRequest is TXtime, 5 secondes,RX1, 1secondes time wait,RX2 With small DR5(SF7) TXtime is less than 100ms but at DR0 (SF12) it long 1.4 secondes. When i read the software i see that OVER_THE_AIR_ACTIVATION_DUTYCYCLE is set to 10s so the lorawan stack try to send a join request after every 10s (with small SF we found the nearly (10+5)s but for SF12 it will be more than that (aprox 16.5s). BUT when maximum time on air is reached (as join is done only on 3 frequency in EU868) the lorawan stack will delay the tx. (max time on air is 1% in on band so 36 sec tx time on air by hours) and time grows to 1 hours after 108 try. As pycom use Semtec original stack it's use have a 48 try pattern 7 DR5 then DR4 7 DR5 then DR3 and so on last try is done with SF12. With a 768 (basically 48*16) secondes timeout you will be sure that all joinrequest is tryied without succes, so your device is unable to communicate (no network coverage).

Update: If I select the newest stable firmware, i.e. not flash from local file, I am able to update the firmware. The older firmware is downloaded from here: https://software.pycom.io/downloads/LoPy.html As I have already mentioned, I have updated 30+ devices, flashing from local file and only this particular device is giving me problem.