New firmware release, version 1.6.0.b1

[livius]

@Neo

Looking to your posts, somehow you are a defender, or probably working/part of pycom team... but this actually doesn't matter.

no i am not from pycom team if you look at history you can find much more criticize post by me ;-)
https://forum.pycom.io/post/2245
but i try to change attitude ;-)
Because much more working now then previously was even possible...
UPDATE
I change also attitude because @daniel describe how situation looks like - that they are affected by ESP-IDF development

about onewire i use this:
https://github.com/pycom/pycom-libraries/tree/master/examples/onewire
and it work for me on version 1.5.0 and it write data to direcly connected sdcard (without expansion board) many days
it is stable. On version 1.6.0.b1 it was broken but day after @daniel fix it and release 1.6.1
which work continously for me since yesterday and write data throught wifi to my server throught tcp/ip socket

I can not test on Lopy because i have only 2x Wipy2.0
First is with 1.5.0 firmware second with 1.6.1

Have you performed stress tests on your pyboard? Running complex scripts for hours in lab and outside at bad conditions (eq temperature), in transmission mode (frequently Wifi up then down, Lora up then down) loading modules progressively, gc collect, running with free memory around 8-10k ?

now memory is to limited to me to write main concept.
and until more memory will be avaiable i only play with sensers
Current working scenario is lilke this
first Wipy retrive data from sensors store it to sdcard and connect to second Wipy (master) and send data packet
Second Wipy have same sensors and store data but is as master and get data from first.
After whole packet retrive it change from AP to STA mode and connect to server and send whole data.
After sended all data it go back to AP.
And this work for me.
I try playing with STA+AP mode but without success
but not played much ..

[Neo]

@daniel Hello.

1. Yes. The code was taken from micropython. You can download from here: https://drive.google.com/open?id=0B2FyGVkp3y9ZZ2plTHNFUFF2WW8
2. This we tried.We compiled mpy-cross and generated binary... but that is not working.
3. Yes. 1.6.1b1 LoPy.
4. Most probably requires fast clock... same fast clock issue we believe is also with DHT22 (not I2C). On the terminal we "I2C bus error" message comming from pycom framework.
5. I need to check this with our management.

[livius]

@Neo
"I2C bus error"

@livius BM180 work also for me (but i have some problems previously and do not test if i still must read first something from i2c e.g. light sensor)

I suppose than that problem presists
i fix this by first read light sensor (it fix something for me) i do not dig enaught because @daniel say that I2C is still software not hardware.

@daniel is this still true I2C still software?

[Neo]

@livius Thanks. I am also a peaceful guy... but the level of frustration starting to go out from me. My apologies.

Than you for your feedback.

Onewire libray that we are using IS THE SAME... LOOL. Check it here: https://drive.google.com/file/d/0B2FyGVkp3y9ZZ2plTHNFUFF2WW8/view?usp=sharing

WiPy for us is not interesting - We are working only with LoPy that has also what Wipy offers.
On LopY we have almost 20 modules and more than 20 sensors implementation. The problem is that an IOT node has at least 8 sensors on it. So if you load that modules one by one, the memory is going to be fast drained... so you need to call gc.collect... an amazing this is not freeing the memory accordingly. SO after data acquisition we start the transmission and we stop it after that. And this doing for hours /days.

With 1.6.x the system is HANGING on gc.collect and sometimes on gc.mem_free This was not happen on previous 1.5.0b1.
We noticed also that with 1.6.x, if you start and stop WLAN many times, at one moment the OS is rebooted, most probably due to memory management.

[livius]

@Neo
Maybe this is some lopy releated problem
Did you tried clear Lopy with only onewire.py and one sensor DS18B20?

I have log on every boot of Wipy
I have checked in the morning there was no log
i also do not see any gaps in data in Firebird database on the server

[Neo]

@livius Thanks. This solution is definitely not for real deployed systems. I mean we are forced to deploy a light sensor in order to read the temperature. Waste of energy and money.

What I2C light sensor are you using for this workarround? We would like to investigate it.

[livius]

@Neo
yes, definitely not for real deployed systems but if I2C is still software than maybe still required
i use BH1750.

[Neo]

@livius Yes. One LoPy and one DS1b20... and empty output. As far as I remember this was happen also on Wipy 1.5.1b1 but I will check again

[Colateral]

@Pete said in New firmware release, version 1.6.0.b1:
Which different brand of WiFi IoT module are you using?

[Pete]

@Colateral I ordered some of these: LinkIt Smart 7688 at the same time as my WiPys. Similar form factor, but runs OpenWrt, a Linux distro originally developed for customising Linksys routers. They arrived at the start of this week. I haven't even opened the box yet, as I'd like to get the WiPy working if I can - my use case is pretty simple and I'd rather not have to admin a whole Linux if I can just write one Python script instead. From the point of view of attack surface if nothing else. But it's a second basket for my eggs if required.

Pete

[livius]

@daniel

i still have problem of corruption of files stored throught ftp :(

[daniel]

Hello,

We just released new firmware, version 1.6.2.b1. These are the changes:

• Fix issue when trying to send empty strings via sockets.
• Update the ESP-IDF.
• Correct RCZ3 uplink frequency and integers overflow.
• Implement ntp_sync for RTC. Add simple support for timezones. See: https://docs.pycom.io/pycom_esp32/library/machine.RTC.html#machine.rtc.ntp_sync
• Correctly set the DNS server. Also disable and enable the right TCP adapter interface.

Cheers,
Daniel

[daniel]

I still have problem of corruption of files stored throught ftp :(

@livius Really? We have been testing a lot during the last 2 weeks with large files and the issue seem resolved. Does it happen when you perform file operations in your script while at the same time the FTP server is busy with a transfer?

[livius]

@daniel
it is by copy file throught e.g. filezilla and without while true: loop

[daniel]

@livius what's the size of the file?

[daniel]

@livius could it be that your file system is corrupted from previous firmware versions? Could you try:

import os
os.mkfs('/flash')

to format the file system and start from scratch...

Cheers,
Daniel

[livius]

@daniel
3905 bytes

I will test with 1.6.2 and will see if something changed

could it be that your file system is corrupted from previous firmware versions? Could you try:

I can erase all data - but i can back tomorrow with review

[JF002]

@daniel With 1.6.1, I encountered some instabilities : the lopy hangs when trying to sync the project from Pymakr, and when I call gc.collect(). Are you aware of these issues? Is it possible that they are fixed in 1.6.2?

Thanks

[daniel]

@livius can you show me an example of the gc.collect() crash?

[JF002]

@daniel

import gc
gc.collect()

Just freeze my lopy. I noticed it when trying to fix another issue with ds1820 and mqtt : https://forum.pycom.io/topic/670/onewire-wifi-mqtt-crash/7