@livius good point, we'll start tagging it like this from now on. Thanks!
@livius the I2C implementation is still by software and noting around that has changed on the last releases.
@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.
I have found a good starting point for investigation on ESP32 forum:
Comments & Feedback
Unfortunately our latest firmware updates introduced some low memory issues that cause both Pymakr and Pymate to be unusable: https://forum.pycom.io/topic/516/pymate-memory-allocation-error
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: https://forum.pycom.io/topic/517/downgrading-firmware-advanced-users/4
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: https://github.com/erikdelange/WiPy-2.0-DHT22
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.
@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)
good msg receive
Payload: b'3058- 1234567890 '
<<< beat msgId 3066
remaining buffer 0
Payload: b'3059- 1234567890 '
buffer too small <<< ustruct exception
The following example is based on the one previously posted here:
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
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:node_1.py nano_gateway.py
Tutorials for your Pycom stuff