Avatar for tom.gidden

tom.gidden

Member since Jan 2014 • Last active Oct 2017
  • 9 conversations
  • 76 comments

Most recent activity

  • in The Place for Patreon Patrons
    Avatar for tom.gidden

    Yeah. The springy pin goes through a slot, then loops back and goes through-hole to solder on the other side. The kink in the pin just before it goes through the slot keeps the ESP32 board itself pulled against the base-board. It's 0.05" pitch as far as I can see, but obv. a different number of pins.

    It's silk-screened to hell and back, so I can't see what the connections to the other gubbins on the board are, but some Stanley-knifing with extreme prejudice should work. Anyway, it wasn't expensive. I seem to remember mine came over on the slow boat from Shenzen, though.

  • in The Place for Patreon Patrons
    Avatar for tom.gidden

    @Gordon Have you seen this ESP-WROOM-32 (ESP32) programming board with spring contacts? I know the nRF52-based MDBT42Q is smaller, but I'm wondering if something similar could be made from one of these boards. I've found this one very easy to work with.

    https://www.amazon.co.uk/Fixture-ESP-WRO­OM-32-Module-Minimum-Development/dp/B071­3PR4RZ

    (If you Google Image Search "ESP-WROOM-32 fixture" you'll see some better images. The ESP-WROOM-32 just clicks into place and stays there until you snap it out)

    Looking at mine, I think you might be able to hack the contacts off one of these and onto your own board, with a Dremel, a tiny iron, some tweezers and a lot of patience.

    Edit: or, come to think of it, if you don't need the short-edge contacts, you could probably just saw out the two rows of side contacts and move them closer together!

  • in Puck.js
    Avatar for tom.gidden

    250ms seems to work. I've also eliminated a lot of the problems by encapsulating the entire program within function init() { so variables are local and aren't preserved. Also, by NRF.removeAllListeners(), E.removeAllListeners(), clearWatch().

    When I use serial, it tends to behave a little differently on the BLE side, and since serial will suck the battery dry -- I've used up two CR2032s this afternoon alone! Thank IKEA and Lidl for cheap cells -- it's not much use for the original purpose of testing power consumption. Saying that, the new firmware has seemed to stop the 3mA current draw when sleeping.

    I'm having to unpair/pair the device on the iPad to get it to properly act, sometimes.

    I've updated the Gist above with my current code, if interested. I'm going to try it out properly tonight.

  • in Puck.js
    Avatar for tom.gidden

    After scrapping my FTDI232 for now and buying a new USB-to-Serial, I've finally got it talking via serial; Serial1.setConsole(true);, of course. Unfortunately, getting through the back-door just seems to confuse matters a bit :(

    I'm now getting a range of errors, including:

    Uncaught Error: Got BLE error NRF_ERROR_INVALID_STATE
     at line 1 col 11
    NRF.sleep();
    

    on disconnect; the dreaded 13313 appeared once or twice, as well as Uncaught Error: Got BLE error code 15, although I think those were both due to old code being stored and/or general connection weirdness.

    Anyway, I'm going to clear this down and start again. I really appreciate your patience. :)

  • in Puck.js
    Avatar for tom.gidden

    Ah, okay. I just tried your setTimeout(...,1000) hack (still on 1v92.103) and the LEDs went nuts: it disconnects (purple), sets a timeout for 1 second, reconnects before that timeout occurs (cyan), then sleeps per the timeout (disconnect, purple) and so on, until it happens to not connect before it sleeps! :)

    Thanks for the fix; I'm eager to try it. Have you got the most recent Puck binary, by any chance? I haven't got cross-compilation rigged up at the moment.

  • in Puck.js
    Avatar for tom.gidden

    Ah, crossed messages... I'll take a look, thanks.

  • in Puck.js
    Avatar for tom.gidden

    So any thoughts… problem with the firmware, or problem with my code? Or, my code is doing something legal but unexpected, perhaps? Hngh.

    Re: multimeter, good tip! I was thinking that, but was intending instead to hook it up to another Puck (or possibly a Pico or Original) to do voltage monitoring and graph it over time to get some idea of likely battery life. However, with the preliminary check with the multimeter being two or three levels of magnitude more than I was expecting, I figured I'd raise that before I went too far with it.

  • in Puck.js
    Avatar for tom.gidden

    @Gordon: it seems like a great idea, but I think I've hit a snag.

    I'm running my current code on 1v92.103 (the nightly the last time I DFU'ed) and rigged it up to my Lidl multimeter (only the best quality kit for me...)

    After startup but not connected, just advertising, it draws about 0.15mA.
    While connected but idle, it draws about 0.35mA.
    While sending data and flashing an LED, it draws about 5mA.

    All fine so far. However, if I force a disconnect with a triple-click which should trigger an NRF.sleep(), it'll draw around 3mA steadily!

    So, when it's purportedly "off" it seems to draw ten times the power of "on". Not good. Hmm. Any thoughts? Any chance you could give it a go? My equipment and skill level makes these figures somewhat less than conclusive.

    (Edit to include photo of my test setup: desoldering braid separated by Post-It note)

  • in Puck.js
    Avatar for tom.gidden

    If I remember correctly, Node-RED actually needs an old version of Node at the moment.. well, not older as such, but I think it only runs on Node 6.x (the long-term stable release), rather than the state-of-the-art Node 7.x. As a result, it doesn't support Promises and a host of other ES6 features.

    One option is to use nave, which lets you have several versions of Node installed and switch between them as needed. That way, you can have Node-RED and EspruinoHub running in Node 6.x, and use another version for other scripts. Or, as you say, just reinstall with Node 6.x: most code should work with it.

    My version of EspruinoHub.service is substantially different as I don't use standard Node either: I install the base server version of Raspbian and do a custom install of Node into its own user.

Actions