Avatar for oesterle


Member since Nov 2014 • Last active Jun 2017
  • 4 conversations

Creative Technologist, based in the San Francisco Bay Area, open to travel

Connect with me on LinkedIn
Follow me on Twitter

Most recent activity

  • Avatar for oesterle

    Hey, @al! I've been following, and love this thoughtful project.

    True that the cables give more freedom on where to place the board, in the Seeed Studio / CoolComponents EMG sensor. However, I'd also read the excellent tech notes/datasheets on both:

    Note that the MyoWare device has some good recommendations on placement of electrodes that should also apply to the Seeed Studio device. Additionally, the MyoWare device has an on-board gain potentiometer – Seeed Studio's does not.

  • in Other Boards
    Avatar for oesterle

    Good thing that things like the Puck object and Puck.light() aren't yet implemented on RuuviTag (right?), since they make assumptions about how on and off are mapped to 1 and 0. One way to mitigate these would be to abstract them:
    var buttonState = buttonPressed();

    … where ledOn, ledOff, and buttonPressed() are mapped to 1 or 0 in platform specific ways.

    But those don't solve the problem of running existing Espruino JS apps on RuuviTag. Maybe the IDE could spot things like LED1 and BTN, and in the case of RuuviTag, tag the line with an informational icon (not quite a warning).

    …… answer = 42;
    💡 btnOn = digitalRead(BTN);
    …… console.log(btnOn);

  • Avatar for oesterle

    Thank you for the link! Believe it or not, after 20+ years of JS I'm still learning new stuff.

    Didn't realize this, but you can also reformat/prettify JSON text by doing something like JSON.stringify(myJSON, null, 2). Very handy.

  • Avatar for oesterle

    @user75202, additionally, if you want to quickly prototype something like this and have a modern Android phone, you could alternatively use NRF.nfcURL().

    The user would bring the back of her phone right next to the Puck.JS on the fire extinguisher (closer than iBeacon or Eddystone), and the page opens. But, it requires only one line of code to work, and makes for a satisfying demo.

    You can see it in action in this 30-second tour of Puck.js.

  • Avatar for oesterle

    @jtq, I see in your code that you're using JSON.stringify() with text as a parameter. Doesn't this usually take a JavaScript object as input?

  • Avatar for oesterle

    Oooh… nice.

    Puck.js. Now available in Space Gray.

  • in JavaScript
    Avatar for oesterle

    That code looks a lot cleaner, @countxerox!

    Thanks for that advice @oesterle. I've had a go and I think it's improved but I can't close the wifi connection. wifi.disconnect() isn't recognized.

    Well, at least it's perfectly OK to call wifi.connect() even when already connected according to the docs. And, your callback is called.

    I wonder why wifi.disconnect() isn't working? @Gordon, any idea?

  • Avatar for oesterle

    @Gordon, can you show us some video of these, or at least the black one, and original white, with the LEDs on?

  • in JavaScript
    Avatar for oesterle

    Right now, everything lives inside onInit(). Can you reorganize your code into separate task-focused functions? That may relieve memory issues, and also make your code more reusable on other projects.

    I'd try to make onInit() focused on just the setup you need to do on power on.

    You also have a long-lived nest of multiple callback functions. I'd pull the connection and sending out into a separate function that's called every 2 minutes. In that function, I'd also turn off Wi-Fi when done sending. This is good practice for IoT sensors that you intend to battery power, also.

    Finally, you'll still probably have rare occasions where connection or sending fails, but these should be less frequent.

  • Avatar for oesterle

    Can you post your source?

    Serial defaults to 9600 baud. I'd first try setting up Serial at 57600 or 115200 baud, like Serial1.setup(57600, {rx:B7,tx:B6}); (where B7 and B6 are the pins you're using).

    Serial1.pipe() might be another option, but I haven't played with that.

    Next, sending chunks on an interval would probably work, but isn't the most efficient or robust, since you are depending on the receiving Pico always being ready on time for the next chunk. Which it might not always: sometimes it may have another task on its plate.

    A somewhat more robust, brute force method, is to do your own chunking. Instead of waiting a fixed interval between chunks, you send a chunk, then wait for the receiving device to send you an acknowledgment. Then you send the next chunk, etc. Before all this, you send something like sending 152\n, where 152 is the number of chunks you plan on sending. That way receiver knows when it's done. (Serial1.pipe() probably does exactly this, internally.)