Avatar for Jean-Philippe_Rey

Jean-Philippe_Rey

Member since Apr 2015 • Last active May 2022
  • 41 conversations
  • 303 comments

Developping IoT @ http://www.novaccess.ch , Switzerland

80% Hardware
15% Firmware
5%Software

Linkedin: linkedin.com/in/jprey
Twitter: https://twitter.com/yerpj

Most recent activity

  • Avatar for Jean-Philippe_Rey

    Thanks everyone for your inputs!

    I'd advise this too. It's just super easy, and Espruino handles this more efficiently than a custom BLE service. If you're looking at x/y/z every 500ms bandwidth isn't going to be much of an issue for you at all though :)

    For one Puck.js it seems definitely to be the best way to go, however I would like to have let's say 5 or more Pucks running simultaneously, and 500ms is a minimum. I did not explain well what I was trying to do: I would like to build a 3d motion sensing platform, a bit like what they use in film-making for motion capture. I am unsure of the precision I will get but it is worth a try.

    At first I was thinking of using a Raspberry Pi as a central device, able to establish several connections simultaneously, but I would also love to try and evaluate the performance of an Espruino device as a central device, if the feature is being added to the firmware at a given time ;-)
    Currently, I think that the EspruinoHub (MQTT) could help me implementing the central device.

  • Avatar for Jean-Philippe_Rey

    Hi @allObjects, thanks for your inputs.
    I am not sure BLE can transport HTTP yet, but the protocols you are suggesting are inspiring me and I start to think that a custom protocol, based on a custom profile, could be an answer to my problem. At least it could help me challenge the BLE stack to reach the bandwidth limit

  • in Puck.js, Pixl.js and MDBT42
    Avatar for Jean-Philippe_Rey

    Hi there,

    For a project, I would like to use several Puck.js devices acting as wireless sensors. A computer would serve as the BLE central device, collecting the data.

    So far so good, anyone would advise me to use broadcasting, and it would be fine as long as data quantity to be sent is kept low. But I would like to send as much datapoints as possible, like x,y and z acceleration for each Puck.js every 500ms or more if possible.

    For such a use-case which BLE profile would you advise me to use? I originally thought of HID profile with binary data encoded in base64, but I also need downlink to send command to the Pucks.js.

    If anyone has a clue about which BLE profile would best address my needs, I would love to hear about!
    In the meantime, I wish you all a happy Easter.

  • in ESP8266
    Avatar for Jean-Philippe_Rey

    Thank you, it helped me flashing Espruino to a Sonoff RF R2 POWER V1.3!

  • in Bangle.js
    Avatar for Jean-Philippe_Rey

    Hi.
    First to do is read the doc here to know what it is all about, what is inside and what can be done with: http://www.espruino.com/Bangle.js2

    Then, you can connect your Bangle.js 2 and customize it with the apps you want: https://banglejs.com/apps/

    As is, it already provides a lot of possibilities, but remember, it is meant to run you own apps. To know how to do that, you can follow this very good example:
    https://www.espruino.com/Bangle.js+FirstĀ­+App

  • in Bangle.js
    Avatar for Jean-Philippe_Rey

    Hi Gordon,

    I just tried the updated Settings app (with very latest FW build). The bip seems fine now but, at least on mine, it seems that we cannot set it to OFF anymore.
    It is not important nor urgent but I wanted to let you know.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for Jean-Philippe_Rey

    Well it appears that method 1. works well.
    Puck.capSense()returns around 8000 when the probe is in the air, and between 17000 and 23000 into water.
    To conclude, Puck.capSense() works well and the problem came from probe itself

  • in Puck.js, Pixl.js and MDBT42
    Avatar for Jean-Philippe_Rey

    I slightly misunderstood the root cause. Given that my probe is made out of 2 pads, one for D11, the other one for GND, putting it into water doesn't increase the capacitance but instead lower the impedance. I suspect that the latter is low enough to prevent the capSense timer to reach the compare threshold, thus generating a timeout on the function nrf_utils_cap_sense().

    Now I will try 2 things:

    1. removing the GND pin and see if the water detection is reliable,
    2. trying to measure the DC voltage on CAPSENSE_RXpin (CAPSENSE_TX put to logic HIGH), given the water impedance could be equal to or lower than the 1Meg resistor of the capSense feature.
Actions