New firmware release 1.6.13.b1
A new firmware version has been released. This release is mostly about fixing a problem with the SiPy operating in RCZ2 and RCZ4 were only the first 2 packets of a round of 18 will be transmitted properly. This has been documented in: https://docs.pycom.io/pycom_esp32/library/network.Sigfox.html
Here's the change log:
- esp32/sigfox: Store the last tx timestamp in the RTC memory.
- esp32/sigfox: Add sigfox.rssi() method.
- esp32/sigfox: On RCZ2 and RCZ4 always go back to the default channel after the second Tx.
- esp32: Correct incorrect ordering of ADC1 channel pins.
- esp32: Add more reset causes and make the RTC persistent during deep sleep.
@markj use ubinascii.hexlify(string) to covert it to hex-ASCII.
Not sure if this is the right place to ask, but..
When I try to get the mac address of my Wipy it gives me this:
b'$\n\xc4\x00\xad\xc4'Why does it look look this and how could I get output like a normal mac string?
Apparently it is raw bytes in Python 3.
The code, running on the firmware version mentioned here.
import network wlan = network.WLAN() print(wlan.mac())
@daniel Hello Daniel, may I kindly ask you to update the firmware repository? There is a substantial lag now.
PiAir last edited by
Re: New firmware release 1.6.13.b1
Just for the record since I see a lot of complaining online about using the Windows upgrade tool: on my LoPy it worked without a problem. Upgrading was 2 minutes work, all scripts were still there.
livius last edited by livius
In the meantime i have moved i2c display from breadboard (really short connections side by side) and solder it on my custom board. All other devices was soldered previously.
But i have also found accidental indentation
gc.collectwhich run really rare.
Now whole code work since 26 hours - i must test more to see what caused problems.
And i must restart board to see if it still be working that way.
P.S. 100 nF nice gift from china for i2c ;-)
In this thread:
you mentioned that you plan to introduce following modification:
Do not start-up WiFi by default on boot. This will speed up boot times dramatically and reduce power consumption.
Can we expect this modification to be implemented anytime soon?
@livius Then it may be the opposite. Do you use the bare chips or modules with the chips embedded. In the latter case they may have already pull-up resistors on-board. In that case, the pull-up value may get too low.
As an anecdote: I ordered recently a pair of ADS1115 modules from china, which did not work. Looking closely at the module I saw, that instead of the pull-up resistors the vendor had assembled capacitors on the board (100 nF), which definitely did not help. I complained at the vendor, and they apologized a lot, and promised to send new modules, but better packed this time!
livius last edited by
Yes, i have. But when i wrote
it was ony generality - it happen for me e.g. 3 times per day.
I have on i2c:
- 2x16 blue LCD
@livius Did you add external pull-up resistors? The internal weak pull-up may be not strong enough to drive several units. Typically 4k7 Ohm is recommended.
jmarcelino last edited by jmarcelino
Bluetooth Classic depends on the chip supplier, Espressif, which hasn't supported it officially yet - first they need to support it in ESP-IDF and only then can Pycom think of adding it in.
As far as I know there is no strict schedule on new features from Espressif but they very recently supported Bluetooth A2DP audio sink so SPP may come for ESP-IDF version 3 - but that's many months away, v2 was released less than a month ago.
Also I think that will eat up a lot of RAM, so maybe unwise to even enable it on current hardware until the modules with greatly expanded external RAM are available.
Could you please mention planned features for next releases?
When can we expect support of Bluetooth Classic profiles (e.g. SPP)?
livius last edited by livius
When I2C as hardware implementation?
I many times got random errors - especially when more devices are connected:
OSError: I2C bus error
and this is not capacity problem..