New firmware release 1.0.0.b1

  • @brotherdust @RSK thanks for the feedback. We will release the source code to github over the weekend.

  • @pwest

    Will we get the ability to read BLE beacon advertisements w/that rev?

    Yes, you will be able to read the data from the advertisements.

  • @jasonriedy thanks for your feedback. Receiving and sending is the next feature that will be implemented. Regarding your application... how often are your BLE sensors sending data? Every 15 minutes as well or more frequently?


  • @jmarcelino
    Agreed 100%! BLE is not about transmitting data but more like advertising and patterns like publish/subscribe. I hope they'll implement true BLE stack the way it's supposed to be.

    I wish Pycom updates their marketing material and in their documentation suggest that not all functionalities are implemented at the moment (more like 30% is implemented now) to help firms like mine that are going to place orders for large quantities of their devices know better! It is ridiculous to buy these gorgeous boards and not be able to at least determine a release date for your product because of the firmware not being ready for prime time! Because right now when you see their marketing material it is based on promises that don't even have a definitive schedule of release! I can't believe it!

  • AVAST antivirus reports installer as malware and do not let it install. I can disable it, but it is imposing a security risk in my WIN10 desktop.

  • @daniel
    Can we have more details of the planned Bluetooth API? To be honest
    "open BLE sockets to send and receive data" doesn't sound very Bluetooth LE-like thing to do at all, a protocol focused on ultra short interactions/notifications around data attributes.

    Please don't just rush into an BLE API that'll be useless in a few weeks just to tick "BLE" feature box. It's easier/better to spend a bit of time and do a bit of planning now rather than changing an implemented mess later.

  • Thanks to Pycom team for hard work!

    It is good to start with basic functionality and provide the feedback and help in maturing the stack.

  • @daniel thank you and everyone at pycom for working so hard to get this release out the door! May I ask what the ETA is for updating the associated GitHub repos?

  • @daniel

    Will we get the ability to read BLE beacon advertisements w/that rev?

  • Hello,

    Next Friday release will introduce the functionality to connect, discover services, and open BLE sockets to send and receive data.
    We will also add options to specify timeouts and make the scan non-blocking.


  • @livius I've just made an upgrade and sadly all BLE functionality is scan. So disappointed. :/

  • @mohpor It's not hopeless, it's manpower. That is the crux of your message. I need to parse BLE advertisements and forward them over LoRaWAN. The LoPy seems to fit the budget once we include powering it and software development. That gives us an incentive to help with development. Free software makes that much easier.

    I'm balancing this against longer-term issues. The current RISC-V dev boards do not match our needs, but future ones will. The development path will be different. But I have to deploy soon (once bees are available in our area, which is kinda unpredictable in the current physical climate) and in an academic environment.

  • Wow! So much hype just for scan?! Is there any timeline for a fuller set of functionality? I mean it's almost end of the year, are we going to get anything further before this year is finished?!

    P.S.: It seems kind of hopeless to wait for you to provide us with better functionality. It really is. I wish you seriously consider even abandon this path and announce we might as well start programming with IDF, or, a better solution IMHO, use the power of open source community and you take the role of an administrator and let people who need the functionality, implement it themselves. And please stop with the Kickstarter alibi, I'm not buying it anymore, it's no excuse.

  • Perhaps I was suffering from an exuberance of hopefulness. The 10s BLE scan from the LoPy is occasionally returning one entry. The Raspberry Pi3 to which it's attached returns an almost continual output from "hcitool -i hci0 lescan --duplicates". There is only one peripheral within a meter of the LoPy (AFAIK), and wifi is active. I haven't decoded the MAC yet to check if it's the same device.

    (I do wish this were a mailing list available via gmane's NNTP interface, but I'm old.)

  • @livius I'll update my LoPys' later but I hope that "Add the Bluetooth network class with WiFi co-existence" statement covers more than just scan function.

  • @daniel Oh, and I should note that my students have been fairly happy with the bluepy library's interface. The timeout-based system may be simpler to manage for reduced duty cycles than canceling some scanning thread that's sending advertisements to a parsing thread, but the latter feels nicer to me. (Not the students, mind you.)

  • @livius It's a promising demonstration that it works. Dealing with the other packets and fixing the scan interface to be threaded is a simple matter of programming. ;)

  • we have added BLE support, it's very basic for now

    do you mean that we can only scan? No communication between devices?

    from network import Bluetooth
    bluetooth = Bluetooth()

  • @daniel said in New firmware release 1.0.0.b1:

    The most important feature here is that we have added BLE support, it's very basic for now, but we will now be able to start adding more features in the next releases.

    If it helps guiding, my use is gathering data sensors are sending through BLE advertisements every ~15 minutes and forwarding them over LoRaWAN. This will run on battery / solar, so power is crucial.

  • BLE peripheral functionality would be super cool next feature in the near future.

    In clear text: I want to read sensors with LoPy and send the data to a mobile phone using bluetooth. :)

Log in to reply

Pycom on Twitter