You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@allObjects
I was reading up what happened with Puck.js since I received mines as Kickstarter reward. At that time I did some basic stuff, but since then I was busy with other (and other Espruino) things.
Reading through what BLE offers for multi-connection and conversation and the timing that is involved with it, I have to revise the communication concept. Main reason is that connecting and disconnecting is not fast enough (1..2 seconds) to actually do what you @Jonathan_Mallinson want to do. I assume things can happen very very fast - on land, in water it would be a bit slower and the slow way would work.
In general, Bluetooth has a limitation of a Master/Central device having max. 7 connections to Slave/Peripheral devices. I though read somewhere that the BLE Espruino implementation would allow more - it is just a question of memory... But I guess 7 works for you too. Therefore, lets look in a first step into what can be done with 7, and may be later how this number can be increased.
As base to start with is this documentation about Controlling Other Pucks.
What we see in the example is that the master/central puck
NRF.requestDevice(...). This may take up a few seconds, because there may be a lot of BLE devices out there that advertise...ble_simple_uartconnection (simple universal asynchronous receive and transmit communication over BLE). This takes some time too.So there is not much new or different from what I initially started with: the peripheral pucks are in advertising mode advertising their (customized) id. But the major difference is caused by the fact that a puck can be in either advertisement mode or connected mode, and switching between that take the time you cannot afford.
The first example in referenced documentation is also not better in performance, since the connection is established for each command and torn down afterwards. But this is not the last thing... The whole process can be made much faster - for a price which we explain and deal with later on.
The second example establishes the connection once - in a slightly different way with
device.gatt.connect()and keeps the connection... Some application code has now to be built around the code of the second example that:The 'other guys' will also need some software smartness:
Before doing a deep dive in the application we have now - as promised - to deal with the reason why we have to build it that way and what the corollary cost of it is:
The *LE in BLE does literally WALK THE TALK OF LOW ENERGY. And the proof of that is that Puck can advertise for months and months and months and... even years while living just of a CR2032 button cell/battery of average 200mAh. How can it do that? Advertising costs about 20uA that is averaging to 4uA with suitable duty cycle and transmit power level of advertising - just one (1) uA more than doing really really nothing (see section Power Consumption at espruino.com/puck.js). Math then tells us that 200mA / 4uA = 50'000 h (hours) = 5.7 years. And with a (space) quality battery - that would be even longer... just limited by shelf life / self-discharge of the the battery (Smoke/COx detectors do such things up to 10 years on a fat battery). Of course, life is not just advertising, and 'decent' transmit power level as used for the longevity test may not be good enough.
As seen in Power Consumption section of espruino.com/puck.js, being connected, uses about 200uA - 50 times more than just advertising - gives us still 1000 hrs (40+ days) - and with JavaScript running 4mA - 10'000 times more than advertising - gives us still 50 hours. Now 50 hours is not really the number, since JavaScript in Espruino runs only when there is something to do... because Espruino is Event Driven.
Said so we are totally on the safe side for the intended application... and even more so, because for running lights, we have to have anyway an extra power pack that has to source peaks up to 500mA (25LEDs 20mA each). Some Alkaline AA (800mAH) 'can' do that, Ni-HM (~2500AH) do even better, and best do LiPOs... LiPO do the best not necessarily from a capacity point of view, but because they can supply highest current draw vs. capacity compared to any other readily available technology. Furthermore, with Alkalines 3 cells are required to run some type of LEDs, and even then the voltage falls below the required voltage way before the cells' capacity is exhausted (old NiCads fair even better in that respect). With LiPOs only one cell is required. To drive a puck though, a voltage regulator is required because a fully charged LiPO yields up to 4.2 Volts and will kill the puck. For driving the LEDs with equal - or ambient adjusted - brightness, evenly simple circuitry is required - current limiting resistor(s) - and the rest PWM can do. If individual LED control is required - for example to communicate with numbers of lit LCDs, a little bit more hardware is required.
If going down the path of individually controlled LEDs, additional information can be communicated to the hitter by running LEDs - clock and counter clock wise, jumping LEDs, different speed of running and jumping to indicate time frame, etc. (different speed of behavior would be useful for, for example, to light multiple devices and communicate hit priority/on time/etc... which could even vary... there is no limit to what can be thought of to increase appeal and excitement of the game and avoid 'predictability'... left and right to indicate to hit or not hit, or hit first all running one direction and then the other... a careful analysis system has though then to be developed...)
With the power pack that is required for running the lights, we can very very easily also run the Pico... the additional power draw by puck will barely barely noticeable. The button cell can be replaced by a dummy that is powered thru wire by the power pack - or even much easier - directly through pins we have anyway to connect. Puck could be not in its regular case, but rather plugged in... It still could stay in its case but pins or connector with at least three (3) connections have to be available: GND, 3.3V, light control (output)).
Being done with the options and power consumption rap sheet, we can say that sustaining connection for fast communication is not an issue (minor point to discuss is: how can we reasonably protect 'the other guys' from 'denial-of-service' attacks before they are asked for connection form master...)
And the icing(s) on the cake:
Let's get coding...
PS: this is my fifteenhundredandfirst post... started out a bit more than 3 years ago - June/July 2014- with Espruino version 1v64 on The Original Espruino Board.