DK firmware v1.1.47 is Available


#1

We have released a new version of firmware for bluz DK. The version will be bumped to 1.1.47, this is still based on the Particle 0.4.7 branch.

This release is mostly filled with bug fixes and enhancements. These include:

  • Fix an issue where the socket buffers could overrun, causing bluz to hang. This could happen in certain situations such as having a Particle.publish in the loop() with a delay().
  • Stop running user code during an OTA update. This will make updates faster in situations where there would be blocking code in the loop() function
  • Fix an issue where the millis() function would incorrectly roll over after only 36 hours. It will now roll over after the specified 49 days
  • Fix an issue in analogWrite where only the first call would work and subsequent calls would fail to change the setting
  • Time out and reset if an OTA update hangs
  • Enabled with WDT to reset the system in case of inadvertent hangs
  • Add a custom data service that can be used to send data directly to bluz from an app, no cloud needed

The release is currently available in the Web IDE as a pre-release, meaning that you need to click on the arrow next to the device and change it manually. Updating system firmware can take a few minutes, so we purposefully are leaving it as a manual update for now, we don’t want to force people to wait if they don’t want to.

Updates will be faster when using the apps as a gateway instead of the gateway shield, so it is recommended that you update system firmware using the app as a gateway.


BluzDK solid Green
#2

#3

Is it possible to downgrade back to 1.0.47 after upgrading to 1.1.47? I tried picking 1.0.47 and flashing my program and it remained at 1.1.47. I got the same results after manually resetting and flashing via the Web with 1.0.47 chosen. I’m getting version via System.version().c_str()

I don’t have an issue with 1.1.47, just wondering if it’s a one-way upgrade or if I have some odd problem.

On a related note, how do the stand-alone gateways get new firmware? Is there a way to see what firmware it’s currently using?


#4

Good question. It is possible to downgrade, but there isn’t a super easy way to do it from the Web IDE. I am not 100% sure if the Web IDE lets you do that, if it will let you build 1.0.47 when the system is on 1.1.47. Even if it does, I wouldn’t update the system firmware underneath. The only way to do that would be to force the build through by using the 1.0.47 system binary and sending it on the CLI.

The gateway is a fun, other story. Technically, the system is just another Particle powered device, you could program it via the Web IDE. There is on hurdle in the way for that right now, and that is the compiler version on the Particle build farm (currently 4.8). We need 4.9 on the gateway, otherwise we can’t fit the system part on flash. So right now, there is no way to compile for the gateway from the Web IDE.

Even if there was, I am leaning further away from doing this. In my mind, the gateway has become more like a standalone product, and I want to add features to it (like filtering Bluz DK based on name, claiming bluz DK connected to it, setting connection parameters, etc) and plan to use the user app to do this. That means if I let people change the user app from the Web IDE, I would lose that ability. Also, there is very little resources left on the gateway since the S120 SoftDevice (required for central mode) is much bigger.

In the end, you will be able to update your gateway to the latest version through the console. The production console doesn’t have this yet, but the staging one does. If you would like, you can login here to see how that works: http://staging-console.bluz.io/

Anyway, very long answer to your question! Let me know if that all makes sense, or you have questions or opinions on my positions.


#5

I don’t fully understand the issue with downgrading via Web IDE. On Particle that does work and has been useful in the past for example when a new bug was introduced I could chose to rebuild via prior firmware. So in this case it flashes both the prior system firmware as well as my user code built against that firmware version. If not working now is that due to configuration/limitation within the web IDE or perhaps with the Bluz Gateway that actually talks to the DK?

As for updating the Gateway I’ve seen cases where it takes a full 2 min to go from BLE_ADVERTISING to BLE_CONNECTED. So I was wondering if mine needs an upgrade and how it would be done. I have no desire to run user code, just interested in the fixes/features you just listed. Now that I think about it how would I restore my gateway if I did accidentally flash user code to it; use the Bluz console webpage?

I just tried the staging version to update my device, the console said the newest firmware version is 1.2.50; but I don’t know what I used to be on. It’s also not clear when the update is complete, the browser console said it successfully sent a tinker.bin file. So perhaps show a message on the webpage when the process is complete. From the javascript code on that page it looks like the gateway should have a version variable if successful but mine doesn’t. After waiting 15min I refreshed the page and the Update button was back. On the second try it worked, sending system-part1 after tinker. I could see the flash start and finish on the Particle dashboard but oddly the gateway never flashed magenta like most updates. The white LED did do some abnormal flashing during that time though. The version variable now exists and reports 1.2.50 and refreshing the page no longer shows the update button. Do you have a change log for this version?

I just realized there is essentially 2 devices on the Gateway, the “Bluz Gateway” part and the P1. I was only seeing the P1 on the Particle dashboard until I claimed the BG during the update. So my prior question about updating and/or accidentally flashing user code applies to both, though I now see how the BG update works.


#6

Thanks for the details!

The staging console is still very much in testing, we put it up there to test the new flow of updating the gateway firmware, so I appreciate the thoughts to improve it.

The screen should send you a notice when the update is completed, though we have reports of it getting stuck sometimes and are looking into that.

Correct, the P1 and the nrf51 on board both are Particle devices and both have separate updates. For now, all gateway updates will happen trough the console.

I will look a little further into how the Web IDE handles upgrade/downgrade, I may need to ask around a little as I am not entirely sure what it does in each scenario.


#7

Add a custom data service that can be used to send data directly to bluz from an app, no cloud needed
Is it both ways? can I send data directly from bluz to iOS?


#8

Yes you can! You need to use the sendData function from bluz: http://docs.bluz.io/reference/ble/#senddata

On the app side, we are working on an SDK (and are offering a bounty if you want to contribute to it!) but it isn’t ready yet. Still, you can use the iOS SDK easily and use our open source app as the roadmap. It is pretty straight forward.


#9

I need to spend more time on this, but it appears the Web IDE did the 1.1.47, even though the 1.0.47 was selected. Now, it appears my digital inputs either do not function or something else has gone awry. I’ll now have to figure out how to try to get them back on 1.0.47.

Perhaps I jumped into the Bluz too soon. I’ve had no issues with Photons, but continual surprises with the Bluz product. I guess I’m venting a bit, but really want this platform to be reliable so I can focus on applications, not simply getting it to work consistently and without problems.


#10

Is there a reason you cannot use 1.1.47?

Bluz is certainly still a new product and that can come with some hiccups. We are working hard to try and address any issues, and we are planning a new firmware release soon that we hope will tackle some known problems.

Rest assured, any possible reliability problems are software related and we will get to the bottom of them. We have been testing internally and seeing good results, but that can only go so far before we need real life people trying real life problems. I appreciate the feedback and we will do everything now we can to clean up any outstanding problems!


#11

The apparent problem I had was the digital inputs stopped working when I compiled my code via the web IDE inadvertently with 1.1.47. I posted a message in another topic about that issue. I was also not able to recompile and flash anything via the web IDE and became quite frustrated (there may have been a bit of Jameson involved, too, to be quite candid). However, after I recompiled and flashed via Particle Dev, it appears everything is working properly AND with 1.1.47. The only question that remains in my disorganized mind is why I experienced problems with the web IDE.