-
Great job, it looks nice!
For such a display, it would be worth having a way of using it as a connected dashboard like some used in Home Assistant but in Bluetooth instead -
-
Thank you @fanoush for your help. I will definitely try to play with interval and window settings to see if I can increase the packet RX rate, however for my application, trying to synchronize with beacons's advertising interval will probably be too complicated for now.
For those who are interested, after some endurance tests (1 week) with continuous scan, the packet RX rate was around 47%, with a beacon advertising sequentially in all 3 channels every 2 seconds.
If I can increase this number thanks to interval and window settings, I will post result here.What I don't understand is that the raspberry Pi I am using for Home Assistant, achieves nearly 100% RX rate for Espruino devices advertising with BTHome. I guess the BLE advertising mechanism should be reliable enough to achieve 80%+ RX rate at least, maybe something is wrong with the way I am using setScan.
-
-
I actually managed to compile 2v21.84 for NRF52840DK, however I don't really know how to benefit from window/interval in
NRF.setScan
. Is there any way of consulting Espruino API reference (in a human readable manner) for a specific commit? As far as I understand, most of it is generated from comments in source code. -
I'm in the process of getting the first 1500 of https://www.espruino.com/Jolt.js ready
Is there any "TAKE MY MONEY" waiting list in which I can buy a seat?
-
-
-
but recently at least the scan window and interval became configurable if that helps a bit
Seems at least promising, I will have a try once available as a feature. As far as I understand it will be pushed in 2v22...
Well those three channels is how BLE Advertising works, there is a reason for advertising on multiple channels. You risk missing some packets when your selected channel becomes temporarily unusable due to noise.
Well that's for sure, it is generally not a good idea to limit advertising on a single channel only, however in our application we will use specific beacons in outdoor, countryside context, therefore 2.4GHz interference will probably be very limited.
Thank you for your response and also for the work you did at providing scan window and interval to Espruino (not mentioning coded phy, BTW)
-
For a beacon ranging application, we use function NRF.setScan() to scan for beacons (TX every 1 second), with some appropriate filtering.
We experienced some particular behaviour: Scanned packets are not equally spread over time. For some couple of seconds, every beacon advertising packet is beeing received, then nothing for the next few seconds, then again almost every packet received and so on. It seems like a stroboscopic effect, due to scanning window (https://academy.nordicsemi.com/wp-content/uploads/2023/03/blefund_less2_adv_process-1024x576.png).
We want to try scanning on only 1 channel, thus avoiding dead time switching between channels 37, 38 and 39, but it seems that setScan method doesn't allow for such parameter.
How complex would it be to modify setScan method to force receiving channel(s)? Would it make sense to add it as a feature to the official Espruino build? -
-
seems there is already something available, however I am not able to follow it up to the user space
https://github.com/espruino/Espruino/blob/55fbab3847975a40341dd2272d4693b341cc0ffe/targetlibs/nrf5x_12/components/softdevice/s130/headers/ble.h#L109 -
by the way, the idea behind using such an FEM module is to increase range to cover outdoor applications as well. More and more systems and sensors use BLE advertising to publish data and having the possibility to support the FEM would drastically help outdoor applications for environmental sensors or beacon tracking
-
I am trying to use Espruino on a NRF21540-DK board (NRF52840+nRF21540 Front End Module, FEM). The latter can be either in TX or RX mode but not both at the same time. It means that the BLE stack should manage the FEM state pins accordingly. Is there anything already built-in to do so?
-
Thank you for your detailed reply.
I had a look at built-in BLE and I am not sure it is that easy to integrate actuators, especially proprietary BLE profiles, when SIG-defined profiles are not sufficient.
I will probably have a try with ESPHome BLE relays, it seems that at least connection oriented communication would be possible. Not sure however how to deal with the application level.
I agree that it would be great at some stage to provide an integration into Home Assistant. As I am playing with it those days, I will try to get my hands on a custom integration and see where it takes me. I will post here progress, if any. -
I've just made some tests with BTHome and Home Assistant as covered by excellent videos from @Gordon:
Video1
, Video2
BTHome uses BLE advertising to send sensor data to Home Assistant (uplink). Now I would like to play with "actuators" which needs downlink. I was thinking of:- displaying data on a Pixl.js
- Toggling relays on Sonoff devices (running Espruino of course)
- doing PWM outputs
- ...
I suspect in this case the best bet is to integrate EspruinoHub into Home Assistant. So far so good, except I have installed a Raspberry PI with Home Assistant OS and I don't have access to the RPi system to install EspruinoHub. (HA OS is running into a Docker and you don't have access outside of it, AFAIK)
Any ideas out there?
- displaying data on a Pixl.js
-
Huge thanks for the work done in Espruino and the continuous Momentum you were able to keep until now.
Added I2C.readReg --> Yeah!
Added console.debug/info/warn/error --> More Yeahhhhh!!
A file called .bootPowerOn is now executed at power-on only --> Even more Yeahhhhhhh!!
Bangle.js 2 now supports two central connections at once --> Too many Yeah!And finally, even if I didn't really understand how it works and where it will show improvements, it is always cool to read about efficiency related, bold numbers as high as FORTY :-)
-
-
-
-
-
I used to set baudrate to 9600 Baud (maximum) for software UART, especially on NRF52 platforms. For hardware UART I thought 115200 baud was still fine, but never really tested on NRF52, because it only provides 1 HW uart and I prefer to keep it as a console interface when BLE is disconnected.
I would recommend not to go much higher than 9600 Baud on NRF52, unless flow control is implemented. -
I naively thought that BLE advertising was draining a not negligible current, which could be unnecessary when the watch is kept aside for long period of time, and thought that enabling/disabling BLE based on accelerometer motion events could save a bit of power but in the light of your explanation now it is clear that it is not a good idea and probably the accelerometer would consume more than the BLE advertising, overall.
-
some of them are available in 4G as well, even if, you are correct, then tend to disappear over time, at least the ones with analog audio
--> https://www.waveshare.com/wiki/A7670E_Cat-1_HAT