Hi @radec, thanks. According to documentation, machine.deepsleep() works well when you are not using a shield or expansion board, but in my case I'm using SiPy + Pysense, so I must use the deep sleep methods of Pysense library. I've found a solution which I posted here: https://forum.pycom.io/topic/3594/how-to-deep-sleep-with-sipy-pysense-3-7v-lipo By the way, I also tried machine.deepsleep() with my setup, but didn't work (the deep sleep current was ~60 mA).

My lopy4 arrived and i tested with it, too, although i was pretty sure it wouldn't make a difference. It didn't, it does the same thing. I left my lopy running since yesterday noon and from 270 readings, 223 were correct. So that's around 17-18% loss.

@vicky_ Malaysia uses the AS923 plan: https://www.thethingsnetwork.org/wiki/LoRaWAN/Frequencies/Frequency-Plans#lorawan-frequencies_as923

@wgtthompson I found this to be the case as well. Just hung at the lte instantiation until i started resetting it after declaring it even if using the same carrier as before.

@seb and @robert-hh Thank. @seb I'm waiting for your post.

@johncaipa Hi, Im getting this same error - did you work out why this occurs?

@archana-kadam Normal LTE no.. unless you use a WiFi-LTE router (MiFi) or external LTE modem.

@vflorio94 pymakr.conf is local file on your PC, configuring pymakr. Why should you not be able to modify it. You may have to restart Atom after that.

@zceld I often see an issue like this when I have another atom window/tab open that is also connected to the same serial port. Can you make sure nothing else is trying to access the serial port?

@robert-hh I see that in current 1.7.2 it is fixed - all calculations are cast to uint64 and also constants are with ull suffix https://github.com/pycom/pycom-micropython-sigfox/commit/3284efccc8e4488a56c4cc93a494a58d6b348908

@daniel - someone needs to reply to each issue posted by users, we are not mind readers !

@bmarkus After removing all files and directories left over by ATOM uninstall on WIN10 and reinstalled it works and at first time at least for me upload and download also works. It's the time to restart using LoPy.

@Colateral bus = I2C(0, I2C.MASTER, baudrate=100000, pins=("P19", "P20")) return: b'U\x02' print(ubinascii.hexlify(bus.readfrom_mem(119, 0xD0, 1))) b'55' print(ubinascii.hexlify(bus.readfrom_mem(119, 0xD0, 2))) b'5502' and chip revision: >>> print(ubinascii.hexlify(bus.readfrom_mem(119,0xd1, 2))) b'0206' it looks ok 550206

@colateral Hi, i am using 1 gateway that only with pymaker opened while the node i using the power bank to power up. I have try both in vice versa yet no result showing out.

@gertjanvanhethof said in LoPy as LoRaWAN Basestation?: @bmarkus Yes that is correct. Only a LoRa Nano-Gateway is possible. This is not compliant with LoRaWAN. But for development and without a full compliant gateway this is ok. So you can develop LoRa Nodes which connects to your own Nano-Gateway. It is OK, but the original subject of the topic is "LoPy as LoraWAN Basestation?" Using LoRa radio layer you can make great things with other protocols, see http://www.waziup.eu/ as an example building network with SX127x devices and gateways only. But not LoraWAN.

@Jurassic-Pork The good news is my DHT11 works fine with read(). However I think I bust my DHT22 at some point as reading no data from it. Will have to order another to test..!

@camdenkrupala You can already set an APN manually by doing lte.send_at_cmd('AT+CEREG=2') time.sleep(2) lte.send_at_cmd('AT+CFUN=1') time.sleep(1) lte.send_at_cmd('AT+CGDCONT=1,"IP","YOUR_APN_HERE"') time.sleep(2) while lte.isattached() == False: time.sleep(1) lte.connect() while not lte.isconnected(): time.sleep(1) print("connected")

@monersss At the moment, with my example, that happens when you get a timeout. But again, that would require some "out-of-band" signaling, meaning: in addition to the "payload", the jpg file, some control information must be exchanged. And that is part of a protocol. That could be pretty simple. If I grab one out of the air, it could be: Define record types, where the first letter defines the type of the record, followed by 3 bytes record length, followed by the payload, like: 'fnnn': filename (of length nnn) 'd128': data 'x000': done You would first receive 4 bytes, decode type and length, and then receive further 'length' bytes. And for every record received, your LoPy would send a confirmation, like the three bytes: "ok!" or "bad", in case of errors (or just a single byte). That would implement flow control and the EOF signal. It does not have other elements like check sums and sequence control. But you might not need that.