To upload a whole project to the pycom board with Visual Studio Code, one has to the File > Open Folder command. Choose the folder where all your .py files are in, e.g., main.py, boot.py and so on. By opening the folder instead of a single file, the IDE and pymakr recognizes all files and interprets them as project. It took me ages to understand how this works... There are so many tutorials and guides around pycom, but there is not guide going through really ALL steps.

@peter_ The doc speaks about external pull-up resistors. I do not have such ones on my boards, and it still works well.

Hmm, seems I cannot send sensor uplink data to TTN v3 via MQTT? How else would a LoPy4 module report to TTN if it only has WiFi connectivity to cloud?

I have the same problem. I am using the Pycom firm update to update new firmware for my Sipy. But it got stuck after I've chosen the country (Singapore). Thanks. [image: 1635568185144-af9e412e-b688-42ab-96d8-dc5dc5cdf829-image.png]

@Ryan-Finn Your questions is missing some detail. Do you want point-to-point communication or do you want to communicate to the cloud? What distance are you trying to bridge? For point-to-point you certainly can use LoRa between the 2 LoPy modules. Or you can communicate from a LoPy to the cloud via LoRaWAN - if you already have a gateway in your area you wouldn't need the 2nd module for that. Or are you considering the second LoPy as gateway via WiFi/Bluetooth?

@Gusti-Made-Arya-Wijaya I using downlink to trigger lopy4 to send payload data that saved in .txt file, here is the code def new_req_log(self): try: print('fungsi new_req_log') downlink = self.dlink[2:] print(downlink) targetfile = downlink[:2] print(targetfile) targetmsg = downlink[2:] print(targetmsg) cari_tgl=(''.join(['{:02x}'.format(b) for b in targetfile])) print(cari_tgl) print('Request Log tanggal '+ cari_tgl) header = b"\xee" + targetfile[1:] print('selecting file') file_log = os.listdir('log') file_log.sort(reverse=True) c = 0 targeted = 0 for a in range(len(file_log)): c = c cari = file_log[a] target = cari[4:8] if target == cari_tgl: targeted = c c = c + 1 read_log_last = file_log[targeted] print(read_log_last) with open('log/' + read_log_last) as f: content = f.readlines() for n in range(len(targetmsg)): i = int.from_bytes(targetmsg[n:n+1], 'big') data = content[i].replace('FF04', 'FF05') # log data id log_data = ubinascii.unhexlify(data.replace('\n', '')) # convert string log to byte print(log_data) replaceHead = header + log_data[2:11] print(replaceHead) self.s.send(replaceHead) utime.sleep(60) except: print("downlink error")

@Haruko-viet-nam What do you expect this do do? You probably didn't copy the full code, this code doesn't do anything at all. Note that to quote code you should use backticks rather than quotes ``` not ''' Or click on one of the </> buttons in the toolbar.

@Stuart-Watt said in LoPy REPL in VSCode not working with firmware higher then 1.20.1: @peterp I'm stumbling on this old issue as it seems to match what I am finding now -- this is a blocker for me. To answer the questions: I can connect in everything, but the serial connection seems to be one-way. I get reset logs back from the device, but I cannot get into the REPL, update, or control it in any way. The connection behaviour seems identical in Pymakr, npmjs mctl, and even the Mac screen program at 115200. No idea about Pybytes because I'm not competent to use it. Let's stick to your own thread https://forum.pycom.io/topic/7305/after-firmware-update-to-1-20-2-r4-serial-is-broken otherwise we risk mixing unrelated issues

@jcaron Did some further testing into that direction. In the end I got a separate wlan router (completely under my control, with enough ip addresses available) and had modules connect in STA mode to it. And all of them connected. Thanks for the hint.

@Wled-Tlas Lopy1.0r

Were you able to resolve this issue and achieve communication between the LoPy and the RF95?

@cduplouy I am also getting around 15mA during deepsleep. I tried with 3.3v and 3.7v using resistor but then it is not sufficient power for the pycom to run.

I just want to share my experience. I think this can happen if your power supply voltage is not sufficient. For example the device we are working on will handle most commands but when it tries to write to memory and voltage is below 3 V it will stall and output this kind of message. I have had this issue on two GPys and could replicate that the problem was solved by merely upping the voltage and rebooting the device.