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.

@incognico Hi
The high current during deepsleep is due to the LTE module. LTE is started automatically during boot. You need to deinit LTE separately before calling deepsleep as LTE is not stopped automatically during deepsleep.
I had the same issue. My FiPy module was drawing 49mA during deepsleep. After I called LTE deinit, the current draw reduced by a lot at that time itself. After that deepsleep worked as expected. :)

from network import LTE
lte = LTE()
LTE.deinit()

Hope this helps.

@vicky_

Malaysia uses the AS923 plan:

https://www.thethingsnetwork.org/wiki/LoRaWAN/Frequencies/Frequency-Plans#lorawan-frequencies_as923

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

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

@archana-kadam

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

@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?

Did something change? Or did it just start working? Or maybe i'm not following the thread? Did you end up swapping antennas or was it something in the code?

I'm still at the same point with the lte.connect() function, but Jose said the LTE team is looking at that. I found out from my co-worker that it's possible to hook into the modem UART pins, so I might try throwing some other commands via that tomorrow.

@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..!

@benstr said in Set Cellular Access Point Name (APN):

if either have NB

Hi Ben, Trying to connect to Telstra's CAT-M1 and NB networks. No luck with that. Could you help? I am in a lab environment in band 28.

@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.

@seb Thanks, I found them and was able to start playing with the new calls.