Avatar for Ron

Ron

Member since Dec 2016 • Last active May 2018
  • 4 conversations
  • 15 comments

Most recent activity

  • in Interfacing
    Avatar for Ron

    Thanks for the tips. Finally figured it out – turning off the WiFi module of the Raspberry Pi (putting dtoverlay=pi3-disable-wifi into /boot/config.txt) has helped big time, basically resolved the issue. I saw the advice somewhere else before, not sure where, but tried it only now.

    Now it works nicely most of the time. It just occasionally times out with:

    <Connect> de:vi:ce:ad:dr: Getting Service...
    <Connect> de:vi:ce:ad:dr: Disconnecting due to lack of use (after 10 secs)
    <Connect> de:vi:ce:ad:dr: Disconnecting.
    

    Is this expected? Do you see the same behaviour? Any ideas how to achieve more reliability, apart from maintaining a persistent connection?

  • in Interfacing
    Avatar for Ron

    I can't find a way to write to a custom service/characteristic exposed on the Puck from Node-RED through EspruinoHub.

    However:

    • Writing from Node-RED to /ble/write/puck/nus/nus_tx through EspruinoHub works
    • Writing to the custom service/characteristic using nRF Connect app on an Android phone works

    The problem only appears when writing to the custom characteristic through EspruinoHub.
    It seems it's not related to Node-RED since the same problem appears also when the MQTT message is published using mosquitto_pub.

    Following the guidance in https://www.espruino.com/Puck.js+Node-RE­D ...:

    The format is /ble/write/de:vi:ce:ad:dr/service/charac­teristic, so you don't have to write to the Nordic UART on Puck.js. You can define your own services and write directly to those.

    ...and the guidance in http://www.espruino.com/Reference#l_NRF_­setServices, this is the code I have on the Puck (first part unrelated (?), but adding for completeness):

    setInterval(() =>
        NRF.setAdvertising({
            0xFFFF: String(Math.round(Puck.light() * 1000) / 1000).split(""),
            0xFFFE: String(E.getTemperature()).split(""),
            0xFFFD: String(Puck.getBatteryPercentage()).spli­t("")
        }, { interval: 5000 }), 60000
    );
    
    NRF.setServices({
        0xAAAA: {
            0xAAA0: {
                writable: true,
                onWrite: function (evt) {
                    LED1.set();
                }
            }
        }
    });
    

    And publishing to /ble/write/puck/0000aaaa0000100080000080­5f9b34fb/0000aaa000001000800000805f9b34f­b yields:

    <Connect> de:vi:ce:ad:dr: Getting Service...
    <Connect> de:vi:ce:ad:dr: Disconnecting due to lack of use (after 30 secs)
    <Connect> de:vi:ce:ad:dr: Disconnecting.
    <Connect> de:vi:ce:ad:dr: Disconnected
    

    Even extending the CONNECTION_TIMEOUT to 30s and the "getting services" timeout to 15s didn't help.

    Any ideas?

    Is there some interplay between setAdvertising and setServices?
    Am I using the wrong format for specifying service/characteristic ID? (Tried short aaaa, long 0000aaaa00001000800000805f9b34fb, hex 0xaaaa, capitalized, non-capitalized, etc.).

    Environment:

    • Puck.js 1v90
    • EspruinoHub up to date
    • Node-RED 0.15.2
    • MQTT Broker is hbmqtt built into Home Assistant
    • All running on the same Raspberry Pi 3
  • Avatar for Ron

    I get the same error, but in slightly different conditions (which I haven't managed to pinpoint exactly) - mostly when I also have an expensive and fast interval running. I'll post code if I manage to reproduce it consistently.

  • Avatar for Ron

    @hansamann Great idea!

    There's no accelerometer though, only magnetometer. That could still be used for fall detection with lower reliability, through sudden changes in rotation. Perhaps a machine learning algorithm could distinguish a fall from noise.

    For location detection, maybe you could reverse the logic - have logic on the hub scan for Pucks, not the other way around. It would save the battery, and not add any extra hardware, since for your original scenario, you already need hubs spread around for the Pucks to connect to as proxies.
    See e.g.
    https://developers.redhat.com/blog/2015/­07/31/behind-the-internet-of-things-midd­leware-demo-at-red-hat-summit/
    https://github.com/starksm64/NativeRaspb­erryPiBeaconParser

    What sucks with NFC API now is that the only type of content that can be set is a URL, but that still works.

  • Avatar for Ron

    @Gordon
    I think it's not worth increasing base energy consumption just to handle this case.

    That snippet does indeed provide some reliability, but still - I think in that situation it's more appropriate to "restore reliability" rather by replacing the battery than repeatedly restarting the magnetometer.

    To clarify - I'm not looking for a hack around this particular problem, but rather trying to clarify (in documentation) expectations of reliability and/or make the API more reliable.

    If you agree, I'd try to make some PRs to add detail to Puck.mag, Puck.magOn, and Puck.light in https://www.espruino.com/Reference.

    Do you think such detail (the "unreliable" behaviour of mag, light) is appropriate for Reference and/or some other place? Or is this something you'd reckon most folks come expecting?

  • Avatar for Ron

    You're right that the battery level affects the readings, but I wouldn't call the situation better, just different. Fresh battery yields:

    Average light at 0.5 Hz: 0.61942668876
    Average light at 1 Hz: 0.61750315656
    Average light at 10 Hz: 0.63999368686
    Average light at 25 Hz: 0.69513494318
    Average light at 100 Hz: 0.74657709911
    

    The curve is quite different than at low battery, but there still is a curve - a side effect I didn't expect.

    The 1 kHz was just an experiment (there's a 200 Hz theoretical maximum anyway).

    Anyway, no big deal, just the same realization as in the magnetometer/battery post: the Espruino API is a very thin wrapper around low level calls, and doesn't provide much of a reliability layer.
    That is not a problem, just something that perhaps should be acknowledged.

    I'm perhaps in the minority, but I'm not too interested in tinkering with low level electronics, but rather using Puck as an HCI device. Use cases in that sphere are somewhat limited by the "unreliable" nature of electronics (unless handled and accounted for).

    One example use case: I intended to implement a variable-rate light detection as a power-saving measure for my Proximity module.

  • Avatar for Ron

    Thanks for the details. I'm looking for any way to make the behaviour more reliable.
    Currently, the magnetometer basically can't be depended on for continuous operation.

    When the spontaneous magnetometer reset happens, Puck.magOn says the magnetometer is on, even though it isn't. Can we detect in magOn that the reset has happened and warn about it?

    A battery level of 38% isn't something I would have guessed to be "low" or "critical". Having individual components fail at different battery/voltage/load levels is an unexpected behaviour in my opinion. Would be nice to mention this caveat somewhere.

    For newcomers like myself, it's easy to see Puck as a nice little "black box" with a nice deterministic dependable API, and forget that the API is just a very thin layer over low level electronics.

Actions