Firmware release 1.1.0.b1
-
@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.
-
@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
-
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!
-
Regarding my (Deleted) Comment, I have checked your forum and my eyes could handle the build number bump from
1.0.1.b1to1.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 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
-
-- infos ---
Interesting app (Android) to monitor BLE.
Gives Flags
Services UUIDs
Service DatanRF connect
from NordicSemiConductor -
@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. -
@gertjanvanhethof yes, we will make this available early next week.
-
@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.
-
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. -
@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 -
Test code for LORA MAC TX:
import machine
from network import LoRa, WLAN
import socket
from time import sleepwlan = 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?
-
Tested with lora.frequency() == 868000000
-
@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 -
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?
-
It only happens in LoRA MAC mode, not in LoRaWAN.
Can a LoPy be LoRaWAN gateway to a LoPy device?
-
@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.
-
@bmarkus Thanks for promt answers!
-
@the_ned bump
Need that too.
-
@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.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login