Firmware release 1.1.0.b1

[daniel]

Hello everyone,

Time for a new firmware release :-). We have done major changes to the Bluetooth API which we hope you will like. It's much more object oriented now.

The release notes are as follows:

• Add bluetooth.isscanning() method to check if a scan is still in progress.
• Add a method to get the characteristics of a service.
• Create the BluetoothConnection, BluetoothService and BluetoothCharacteristic classes.
• bluetooth.connect() now returns an object of the type BluetoothConnection

Please have a look at the docs in: https://docs.pycom.io/pycom_esp32/library/network.Bluetooth.html
for all the details.

Reading and writing characteristics is now possible and we will keep enhancing this functionality.

In the upcoming releases we will add a method for subscribing to notifications/indications, and non-blocking options to most of the API calls. All these features depend on the new interrupt mechanism that we plan to release next week and that's the reason why they are not available yet.

The firmware update tool is available here: https://www.pycom.io/support/supportdownloads/

Looking forward to receive your feedback.

Cheers,
Daniel

[Fred]

@bmarkus It can be a LoRaWAN nano gateway listening to one channel at a time. Be mindful that this is not LoRaWAN compliant but is very useful in certain conditions. We will release the full firmware with this functionality early Feb.

[maku]

@the_ned bump

Need that too.

[perfeco]

@bmarkus Thanks for promt answers!

[bmarkus]

@perfeco said in Firmware release 1.1.0.b1:

It only happens in LoRA MAC mode, not in LoRaWAN.

Can a LoPy be LoRaWAN gateway to a LoPy device?

No, due to hardware. LoPy is a device with SX127x while a LoRaWAN GW requires SX130x chipset.

[perfeco]

It only happens in LoRA MAC mode, not in LoRaWAN.

Can a LoPy be LoRaWAN gateway to a LoPy device?

[perfeco]

Lowest current consumption so far: 106 mA during time.sleep().

Is machine.idle() a low-power mode where all CPUs are supposed to be idle and execution stopped until next IRQ?

[daniel]

@perfeco thanks. I can confirm the issue is there. It crashes a few seconds after sending. We are investigating it... Will report shortly.

It only happens in LoRA MAC mode, not in LoRaWAN.

Cheers,
Daniel

[perfeco]

Tested with lora.frequency() == 868000000

[perfeco]

Test code for LORA MAC TX:

import machine
from network import LoRa, WLAN
import socket
from time import sleep

wlan = WLAN(mode=WLAN.STA) # Switch off WLAN AP
lora = LoRa(mode=LoRa.LORA) # Switch on LoRa
s = socket.socket(socket.AF_LORA, socket.SOCK_RAW)
s.setblocking(False)
lora.power_mode(LoRa.ALWAYS_ON)
sleep(.1)
s.send(">>> ")

• Crashes on os.uname() == (sysname='LoPy', nodename='LoPy', release='1.1.1.b1', version='v1.8.6-281-g75e2452 on 2017-01-03', machine='LoPy with ESP32')
• Works on os.uname() == (sysname='LoPy', nodename='LoPy', release='1.0.1.b1', version='v1.8.6-264-gadacebe on 2016-12-22', machine='LoPy with ESP32')

How do I check which frequency LoRa is using?

[daniel]

@perfeco is that with the 868 or the 915 MHz version? Can you provide a small piece of code that reproduces it? Thanks.

Cheers,
Daniel

[perfeco]

This release supports LoRa transmission.
Release 1.1.1.b1 crashes and reboots a few seconds after a LoRa transmission.
Tested on LORA (MAC) mode.

[stevie]

@mohpor, actually I am not angry with the Pycom guys. I think they are doing a great job. They are developing the firmware farther at a steady pace. While they may be behind their initial schedule (or our expectations of the schedule) this is in big parts due to the fact that they are on the leading edge of the ESP32 users. Others playing around with the ESP32 are also delayed by the late delivery of the BLE features. If the ESP32 manufacturers don't deliver certain features, the Pycom guys can hardly deliver them either. All in all the WiPy and LoPy are great modules and I am sure they will improve further with time. As it is now, the best strategy would be to accept the development status as it is and just wait and help prioritizing things.

[daniel]

@gertjanvanhethof yes, we will make this available early next week.

[gertjanvanhethof]

@daniel Is it possible that pycom makes it possible to download older firmware updates too?
I need this because the latest is not working fine for me (see AWS MQTT connection issues). But i don't have the older firmware anymore.

[Oneillsite]

-- infos ---
Interesting app (Android) to monitor BLE.
Gives Flags
Services UUIDs
Service Data

nRF connect
from NordicSemiConductor

[Fred]

@mohpor I suggest you take a balanced view of your opinions and reconsider 'empty promises'. I have emailed you separately. I believe you can also note that the Firmware release promised during the Christmas vacation was delivered by the team, contrary to your other comment.

You were invited to put any items required onto our roadmap, and since nothing was forthcoming, we built up the list inline with the majority of our customers requirements.

Thanks Fred

[mohpor]

@Fred

Regarding my (Deleted) Comment, I have checked your forum and my eyes could handle the build number bump from 1.0.1.b1 to 1.1.0.b1! forgive me for being pedantic, but that's not the way people pump their build numbers.

I KNOW you have submitted an update. No need to point that out AGAIN.

[mohpor]

@Fred

OK. Looks like you are angry with me which I can not understand for the life of me. If anyone here should be angry is us customers, not you guys with empty promises!

[Fred]

@mohpor In line with Daniel's message several weeks ago, we asked the community for input. We have now prioritised the firmware build and we will NOT be making changes at this point. Your request will be added after the firmware release mid January.

With regards to other comment you made, the team DID release the firmware through the Christmas period and will CONTINUE further development according to Daniel's build schedule.

Thanks Fred