Announcements regarding our community
Open source Licence

@livius good point, we'll start tagging it like this from now on. Thanks!

read more
New firmware release 1.4.0.b1

@livius the I2C implementation is still by software and noting around that has changed on the last releases.

read more
Downgrading firmware (advanced users)

@sakis I have tried with linux through VirtualBox and I don't get that error any more, althought the flashing process is not very stable. Took me 6 attempts to get the WiPy flashed, on the other 5 I got this error at ramdom completion percentages:

Writing at 0x0009400... (80%) Exception: Failed to write compressed data to flash after seq 33 (result was 0xc1, 0x0), on line 132

Maybe the problem is beacuse of flashing it through a virtual machine.

read more
A place to talk about whatever you want
Latest Firmware Free RAM @ 37K ?

Well, for LoPy it is only 32k. Be happy with 37k!

read more
BLE AdvertisedServiceUUID

I have found a good starting point for investigation on ESP32 forum:

read more
BLE Wifi Gateway possible ?

Thank you very much for your reply.
I am very flexibel in the BLE Protocol , because it is in my hand.
At first I want to "stream" the Advertising packet via Wifi to a server.
It should be possible.
Again congratulations for your product !

read more
Got a question? Ask away!
PyMate - deleting configuration names in list & LoPy setup failures


Unfortunately our latest firmware updates introduced some low memory issues that cause both Pymakr and Pymate to be unusable:

To answer your other question: Yes, Pymate has been tested on Android with a LoPy and it's working fine

We'll let you know about the status of this. In the meantime you can try downgrading to version 1.2.2.b1 or older:

read more
Time & Interrupts

Hi Marc,

I've also tried to measure a DHT22's pulse length using an interrupt callbacks. Even with the smallest (and hopefully fastest) interrupt routine I got the same results as you did; I never measured a pulse length below 100 us.

For what I did and the results see here:

In the end the only thing which worked for me was to use polling, and even then I had to temporarily disable interrupts to get a usable result.


read more
Blog posts from individual members
LoPy Nano-Gateway

@Roberto We setup a test bench with 3 LoPy following the idea of your code. We did the test with blocking socket and thread and non blocking sockets. The result is the same.

2 are the nodes configured as tx_iq and and one is the Gw (rx_iq).

The script is simple: each device (node and GW) is sending 29 bytes message size (_MSG_FORMAT = "!HHLBB%ds") each 2 seconds. In the msg data we are printing a counter (that varies from device). That counter is also in the header (see above)

We noticed that sometimes if you start the gw after the nodes... randomly some of the nodes are not receiving the data, despite the fact the GW is receiving the data from the nodes. And we observed also that sometimes when we start the node after the GW, the GW is not receiving the data from the nodes.

You need to reset the node or GW in order to get the broadcasted data from to the others... and this hazardous and not at all good in real deployment.

BUT THE MOST PROBLEMATIC is the fact that the 29bytes are partially received, sometimes you are getting 15bytes or whatever number less than 29bytes.

Have you experience this connection issue related with nodes/gw starting order?
Does LoPy stack is guarantee the receiving of msg in one chunk? ( if you send 29bytes you got 29bytes)

Here are some samples:
good msg receive

from: 800
to: 0
Id: 3058
Flags: 0
PayloadSize: 18
Payload: b'3058- 1234567890 '
<<< beat msgId 3066
bufferSize 29
pkgSize 28
data_size 18
remaining buffer 0

bad msg receive

from: 800
to: 0
Id: 3059
Flags: 0
PayloadSize: 18
Payload: b'3059- 1234567890 '
bufferSize 15
buffer too small <<< ustruct exception

read more
LoPy Nano-Gateway Extended (Timeout and Retry)

The following example is based on the one previously posted here:
LoPy Nano-Gateway

The original code shared messages over LoRa between several LoPys using one of them as a Nano-Gateway and the remaining ones as nodes.

Keep in mind that for this example the communication works as follows:

LoPy 1 -------> Nano-Gateway LoPy <------- LoPy 2

The nodes send messages to the Nano-Gateway for further processing, this might include sending the messages over WiFi to a server for example.

The following code its an extension of the original one. It includes a couple of new features:

Maximum waiting for acknowledge time:
After sending a message, each node waits for a response from the server with an acknowledge package.
In the original code this process took an infinite amount of time, meaning that if the package or the acknowledge where not delivered the node would stop sending further messages.
In this new version, a maximum waiting time is introduced and set to a default of 5 secs. This allows the node to stop listening for an acknowledge and continue with other tasks. Change the default time depending on your application, especially if you are using different data rates or your processing times of the package in the Nano-Gateway are too long

Message retry:
If the acknowledge of the message never arrives, or another message arrives for a different device or message_id, the device will re-send the current package up to a maximum of 3 times (default) before setting the package as not send. This will allow for a more robust communication and will fix issues when two devices send messages at the same time causing a collision. Keep in mid that without a proper LoRa Gateway there is no collision management and all devices can send at the same time on the same band.
To further avoid collisions, a random delay is added before trying to resend a message. If a collision occurred the involved devices will send their messages at different time intervals.

Note: If you are in an area where other LoRa devices are being used, check if the band you are using is free, is not try a different band.

Nano Gateway Files:

read more

Customer enquiries matched with developer skills

HOT Lead

@LoneTech sounds good... let me know if you are up for a chat and we can discuss. Best is to send me details on email. Cheers

read more

Looks like your connection to Pycom Forum was lost, please wait while we try to reconnect.