Avatar for Gordon

Gordon

Member since Sep 2013 • Last active Jul 2019

Most recent activity

  • in Puck.js, Pixl.js and MDBT42
    Avatar for Gordon

    Hi - is your firmware up to date?

    The code looks fine to me - I just ran it and I see the 0x181A service using nRF connect. It's possible that significantly older firmwares didn't have that code implemented and ignored the advertise field.

    However it may also be because I believe Espruino tends to put advertised services in the scan response packet - so if you're just looking at ADV_IND you may not see the service?

    • 216 comments
    • 22,292 views
  • in Projects
    Avatar for Gordon

    Hi! Quick question - while I've been working hard on the ID205 reverse engineering (and the nRF52840 is obviously nicer to have), I've had a lot of interest in watches with GPS and I'm coming back to the No.1 F5 and F7 watches as they're packed full of features.

    I just found a link to a firmware updater for it (which is actually just an APK file) and looked inside and found firmware that references SDK 7/8/9. That feels super old to me, but do you think it's a possibility that's what they're using?

    If so I guess OTA firmware updates could be a realistic option and I could just reflash the watches here?

  • in Puck.js, Pixl.js and MDBT42
    Avatar for Gordon

    Very odd - yeah, it'd be good to catch up at JSOxford. If I'm honest I'm not sure if I'd be able to be much help with the Puck apart from to test it on my devices here and check it really is properly clear.

    It does sound like something's gone a bit strange with the iMac's (or Chrome's?) bluetooth info.

    If you power off the Puck and then search using Web Bluetooth, are those 2 devices with the different Mac addresses still shown?

  • in General
    Avatar for Gordon

    What you're doing there looks fine to me... You could try:

    setWatch(HomeUp, BTN, {repeat: true, edge:'falling', debounce:50});
    

    instead of

    setWatch(HomeUp, BTN, {repeat: true, edge:'falling'});
    

    I thought debounce on the button should have been automatic but maybe it's not... What can happen is the button actually physically bounces - effectively making two presses. Too fast for a human to see but the microcontroller picks it up.

    Having debounce:50 adds code that checks to ensure the button's been in that state for at least 50ms before calling your code.

    Or... what may be happening is you have the code saved twice somehow (once direct to flash, and once from save()) so you've got two setWatches. Try writing reset(1) on the left-hand side of the IDE and re-uploading your code (and if you're using direct to flash you don't need to call save() since it happens when you upload).

    Hope that helps!

  • in Puck.js, Pixl.js and MDBT42
    Avatar for Gordon

    I would have imaginged a hard reset and a firmware update via DFU would get rid of any of that?

    It depends - updating the firmware and power cycling won't get rid of saved code (unless it was saved using save()) - however a full hard reset (holding down the button through the 5 red flashes) should definitely have done it.

    Did you try rebooting the iMac? I'm afraid I don't know how you reset pairing info, but I've had cases where a computer's bluetooth stack needed restarting before it'd work properly again.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for Gordon

    Wow, that's a strange one. Is it possible you'd been experimenting with the Puck before with some code that changed the MAC address? By default the 4 digits after Puck.js match the last 4 digits of the MAC address and neither of those two MAC addresses matches!

    Maybe try hard-resetting the Puck? So hold the button while flicking the battery back then keep holding until the red LED has finished flashing. That should get rid of any stored code and might make things work better with the iMac?

    Also, maybe try turning bluetooth off and back on in the iMac and maybe even try restarting it - just in case :)

  • in Projects
    Avatar for Gordon

    Thanks! Do you have an example of the code that's running slowly?

    Espruino itself doesn't execute particularly quickly, but if you're running a build without RELEASE=1 then loads of assertions get left in which really kill performance.

  • in Other Boards
    Avatar for Gordon

    Hi Lorenzo - maybe you could ask RAK themselves?

    Without anything running (eg. just after boot), Espruino should manage around 20uA from the nRF52832 chip (0.02mA), and with NRF.sleep(); Espruino should do 3uA.

    So the increased power draw will likely be from the circuitry around the nRF52832, but I don't know enough about RAK's design to be able to help you out properly.

  • in General
    Avatar for Gordon

    As @Ollie says the Espruino MDBT42Q board was designed for running Espruino, a JS interpreter. We don't support running other types of firmware on there - and honestly I think you'd find Espruino's JS easier if you plan to do any Bluetooth stuff.

    I'm not 100% sure about micropython support on nRF52832 but I know that Adafruit does support it (https://circuitpython.org/board/feather_­nrf52832/). While you may be able to run that firmware on the MDBT42 breakout (since it uses that module) you may find it easier just to buy their board instead as I believe it'll have it preinstalled.

Actions