Firmware release 1.1.0.b1

[daniel]

@Frida nothing, it's just a warning message that will be removed in future releases. Is the scan returning results?

[drnordstedt]

@daniel I am able to scan and get the advertisement from my TI Sensor Tag, but not my Eddystone Beacon. Not sure why... Do the advertisements get queued up and we retrieve them one by one with get_adv() method? Any plans to set up a callback feature for receiving advertisements instead of polling with get_adv()?

[daniel]

@drnordstedt yes advertisements are queued and the FIFO behind has space for 8 advertisement messages.

Have you tried on a for loop?

while True:
    bt.get_adv()

Yes, we do have plans to also offer a callback feature.

[drnordstedt]

@daniel Thanks for the info. Yes, I tried it in a loop. I'll run some more tests with other devices and sniff out the packets. I can send you the advertising packet data if you'd like when I run my captures.

[jasonriedy]

@drnordstedt @daniel What may work "better" is if get_adv() returns an array of all currently known requests, resetting the queue. I can see too many race conditions otherwise.

[mohpor]

Hi @daniel
As I have mentioned in my email, there is no BLE Peripheral in the current implementation, nor anything is planned for the near future. Do you have any plans for it?
set_adv(), add_service(), add_characteristic()... would be a dream come true for me now. I have waited a few weeks, I'm losing hope.

[daniel]

@mohpor Hi, I have replied to your email a few minutes ago... we do have plans for supporting BLE in GATT server mode, we just chose to implement the client functionality first as this is what most people was requesting.

[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

[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!

[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.

[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

[Oneillsite]

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

nRF connect
from NordicSemiConductor

[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.

[daniel]

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

[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.

[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.

[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]

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?

[perfeco]

Tested with lora.frequency() == 868000000

[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