Happy Bubbles Firmware Update

[Colin Joseph]

Team:

I updated to Happy Bubbles firmware V12 here:  https://github.com/happy-bubbles/presence-firmware/releases/tag/12

The firmware page still reflects firmware 11, but now the LED is always Green.  Did I do it right?  Is there any way to check?

Thank you in advance for the update.

[Happy Bubbles Tech]

Colin,

I tested it on my units and it worked OK, did not get an LED stuck.

In the firmware package there are two files: "user1.bin" and "user2.bin" and you need to upload the correct one. In the config mode web interface it should tell you 
Make sure you upload the file called: user2.bin

So you need to make sure you upload the correct one. If you do the wrong one, I'm not sure what happens :(

Does it work otherwise if you restart it by either holding the main config button or the pressing the little 'reset' button on the big board in the middle?

--
You received this message because you are subscribed to the Google Groups "Happy Bubbles" group.
To unsubscribe from this group and stop receiving emails from it, send an email to happybubbles+unsubscribe@googlegroups.com.
To post to this group, send email to happyb...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/happybubbles/98e2416c-eb0f-4ddc-9564-e350d0a0dceb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alan Marion]

Hi nemik,

I think you have done a great job on this product!

Using Version 11, with a mix (total 10) iBeacon and EddyStone beacons on a single detector into a local mqtt mosquitto server appeared to be working well over several days.  I tried upgrading several times to Version 12 (using nodemcu-flasher) using both bin1 and bin2  at different times, but with no success.  Eventually went back to Version 11 with no problems.  For the Version 12 no success case, I could see the problem first after starting the go presence app on Windows laptop there seemed to be connection to server error -- although mqtt server is running normally.

Anyway happy to be working with Version 11.

One question I have is -- the maximum number of beacons that each detector can support?  I currently only have about 10 beacons running at one second rate and that seems fine. What could the max number be possibly with slower rate?

Thanks,

Alan

    
On Saturday, July 22, 2017 at 10:11:25 AM UTC-4, nemik wrote:

Colin,

I tested it on my units and it worked OK, did not get an LED stuck.

In the firmware package there are two files: "user1.bin" and "user2.bin" and you need to upload the correct one. In the config mode web interface it should tell you 
Make sure you upload the file called: user2.bin

So you need to make sure you upload the correct one. If you do the wrong one, I'm not sure what happens :(

Does it work otherwise if you restart it by either holding the main config button or the pressing the little 'reset' button on the big board in the middle?

On Sat, Jul 22, 2017 at 8:38 AM, Colin Joseph <holelat...@gmail.com> wrote:

Team:

I updated to Happy Bubbles firmware V12 here:  https://github.com/happy-bubbles/presence-firmware/releases/tag/12

The firmware page still reflects firmware 11, but now the LED is always Green.  Did I do it right?  Is there any way to check?

Thank you in advance for the update.

--
You received this message because you are subscribed to the Google Groups "Happy Bubbles" group.

To unsubscribe from this group and stop receiving emails from it, send an email to happybubbles...@googlegroups.com.

[nemik]

Thanks Alan. Sorry to hear you had trouble upgrading. What exactly was the issue? The units were not connecting to MQTT? I've upgraded my own both with a flasher as well as the config web interface, maybe give that a shot?

As for a limit, 10 beacons with 1-second interval is pretty light. I've tested about 7 beacons using 20ms advertising intervals, the smallest the BLE spec allows. They seemed to hold up over a decent wifi connection. You should be fine to add many more beacons even if you lower your advertising rate.

It is an interesting question though, what the absolute maximum would be. I hope to run more tests to find out and right now along with the wifi connection I suspect the 115200baud serial connection between the two chips might be the limit for now. Later if some customers really need this tuned up, I could switch to SPI and speed that up considerably. But for now it's not an issue.

[Alan Marion]

Hi again nemik,

I am currently running on Version 11 at my workplace and 16 beacons and all looks good.

(A meeting room may have say 50 people in close proximity OR there could be a 100 or more items on a warehouse shelf).

Previously I used my home setup which is older tech ...

I am thinking to try Version 12 again later on, but for now "if it ain't broke don't fix it"

I will try to provide more details if it is still problematic.

For now, I want to work with Eddystone TLM battery level alerts -- do you think I will need Version 12 for this?  

Also do you have a suggestion for email alerts -- used node-red, but problems with gmail & yahoo security.

One more thought -- ESP32 version ??

Thanks again,

Alan

[nemik]

Alan,

Version 12 firmware doesn't add support for Eddystone TLM, it only auto-detects Eddystone UID. I'm still thinking about how to approach this but think it may be best to auto-detect only presence stuff in firmware, since space there is limited. Reading other things like sensors, TLM metrics, could be better done on other applications that subscribe to and process those topics from MQTT. Node-red is a fantastic platform for this and I use it for my own automation uses. I use email alerts with a gmail account's SMTP and it's working very well.

I've wanted to do an ESP32 version, but thus far ESP32's support for both Wifi and BLE at once is not good nor reliable. My experiments with it saw it not picking up even 10% of the beacon advertisements that the Happy Bubbles detector does. Because the ESP32 has to share a single antenna for both BLE and Wifi and switch between them, I don't think it'll ever be as reliable as having BLE separate from Wifi and using two antennas at once instead of sharing them.

So for the time being, I'm going to stick with separate chips and keep the system as-is.

[Alan Marion]

Hi nemik,

Thanks for the good background info...

Just to let you know that on doing some load/traffic testing I have 16 iBeacons running OK with presence detection at the 1 second beacon rate and still OK at 0.5 seconds.   However, when I decreased the rate to 100 msec, the presence detector hardware seemed to lock up and seemingly no reset was possible and functionality only returned after reinstalling firmware (Version 11) with nodemcu.  Your comment on this appreciated.  

Alan

[nemik]

Alan,

That's quite a test, so you had 16 iBeacons at 100ms intervals and saw lockups? Thanks for this info. It'll take me a while to replicate such a test but I'll get to it and try to sort out where the problem is. Thanks for this info.

[Alan Marion]

Hi again nemik,

I repeated the same test and seemed like detector operation OK for a couple of hours -- then all LED activity stopped --  used CONFIG button to get AP mode and see config (noticed now on Version 12 !) -- depressing CONFIG button again to get back to STA mode results in LED solid green -- I think I will have to reload the firmware as before to get proper operation.

Do you think this a memory leak issue?

Alan

[Alan Marion]

Hello nemik,

Just continuing my load testing troubleshooting ...

With a light load, the detector will run for some time (several days at least) with no problem so far as I can tell.

As load is increased the green LED gets to the point of being almost solid and then turns off -- detector appears to stop working.

If load is then gradually reduced the green LED comes back flashing and normal operation seems to resume.

So it seems that for heavy loads the detector is just kind of overwhelmed and "waits" for reasonable loading it can "cope" with.

My heavy load is 15 iBeacons @100 msec rate running on detector Version 12 although it might a but less than 15 beacons and a bit more than 100 msec.

So I am thinking that this heavy load might be equivalent to 150 beacons @ 1 second rate.  If this is the case -- hard to prove right now -- then probably having 100 beacons or so in a room should be OK.  Not sure if this doesn't strain the time performance of the detector whether it exceeds the available memory. 

[nemik]

Alan,

Sorry for not responding for a while, I was looking into this. There is definitely no memory corruption issue, you just need unplug power to the unit and plug it back in for what you were seeing.

Good news and bad news. Good news is I think I've found the issue and it appears solved no matter how many beacons I have advertising how often. The root cause is the firmware in the BLE chip sometimes acting up and crashing when it gets too many packets and can't send them over the UART/serial to the Wifi chip. I issued a new release of that which should fix it.

The bad news is that this firmware can't be upgraded remotely or through USB. That little connector with the 6 pads below the BLE chip is for a Tag-Connect connector that I use to flash that BLE firmware with. It can be flashed without it too but would need soldering or holding pads to certain pins on the BLE chip. I'll work on writing some documentation on how you can do this yourself if you want. I really regret not adding extra headers to make this easier though so for that I apologize and will change the hardware to add those for future batches.

Luckily this issue only impacts relatively few people who deal with industrial-quantities of beacons. If you're uncomfortable upgrading it yourself, you could ship your detectors back to me and I could upgrade the BLE chip and send them back. But I will also document a way to try it yourself. 

Sorry about this but thank you very much for your help in making me aware of this issue and all the work you did to try to identify it.