Avatar for fanoush

fanoush

Member since Jul 2018 • Last active Apr 2024

Most recent activity

  • in Bangle.js
    Avatar for fanoush

    For ear buds - I just wonder what features Espruino could add in an ear bud?

    In theory what we could add is hacking some way of streaming audio into the ear buds from other BLE espruino devices. However the chances of nrf52 being in earbuds is probably zero, maybe newer (nrf53 and up) are a bit more likely with BLE audio coming.

    Or when linking some text to speech engine into the ear buds firmware the data transfers could be pretty low (just sending text). Or MIDI over BLE could work. Also it could act as a HID device.

  • in Bangle.js
    Avatar for fanoush

    Will i be able to recharge the battery if i attach VDD?

    you mean 3.3V? no, the battery is 3.7-4.2V but you can attach 5V like it was meant to be used when the device is closed. You could even do it with Pico - take 5V feeding the Pico and connect it to 5V charger input pins on the watch. Just ignore the 3.3V

  • in Bangle.js
    Avatar for fanoush

    Device has AP lock engaged". So i'll have to use a real segger programmer anyway

    No need for segger for that, Pico with CMSIS-DAP and OpenOCD could do it too, newer OpenOCD versions even print helpful message how to do that.

    nRF52 device has AP lock engaged (see UICR APPROTECT register).
    Debug access is denied.
    Use 'nrf52_recover' to erase and unlock the device.
    

    So just use 'nrf52_recover' command.

    And BTW you could also unlock it from the device via software by erasing and rewriting UICR from javascript.

  • in Projects
    Avatar for fanoush

    it is safer to schedule it again via setTimeout after println returns.

    actually I did not check how setInterval is done, but I always had issues when code in setInterval run longer than the interval. Since the interpreter is single threaded it won't run the code again if it did not finish but maybe it runs again right after previous one ends not giving chance to any other code or idle loop to run? So maybe GC is not done or other intervals may not run (pinging watchdog in this case) etc?

  • in Projects
    Avatar for fanoush

    I'd replace setInterval by scheduled setTimeout, it is fixed to 100ms here
    https://github.com/espruino/EspruinoDocs­/blob/master/tutorials/Web%20Bluetooth%2­0Dashboard.md?plain=1#L214
    so if sending (the Bluetooth.println(..)) takes longer than 100ms it may overflow and reboot(?). it is safer to schedule it again via setTimeout after println returns.

  • in Projects
    Avatar for fanoush

    just have a led blink on every loop on the device, and force a bad signal on the phone running the web page.

    which loop do you mean is there some specific looping code you can link (your code or that puck.js)? One idea is watchdog - if you have watchdog kicking in setInterval then any busy loop or delay in native code preventing intervals from running could trigger such reboot. Another issue causing this may be be overflowing the stack or memory - generating data faster than it could be sent filling memory or call stack (by somehow nesting calls when error happens?)

  • in ESP32
    Avatar for fanoush

    ...fixed it ;)

    Actually you was probably right before. C3 does not have USB OTG. It only has fixed function USB CDC Serial + JTAG. So no generic purpose USB that could do HID or mass storage or anything. So USB is there just for flashing and console so you don't need to have usb to serial chip on devboard. S3 has same fixed serial/jtag interface + USB OTG on same pins so you need to select at runtime one or another (you can't have both) but C3 only has that fixed function one.

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

    Are you using active or passive scan (options.active = 1)? With active scan for every device found it tries to request scan response from it. So when doing this I am guessing it may miss other device advertising at the same time? The scan response request/response is done on same channel as the advertising packet received. And I think it is done immediately after receiving the packet since the advertising device waits only short window for scan response request after sending advertising packet. Anyway, changing scan to passive could IMO help to just listen for the whole window instead of transmitting into the same channel for every device that is found possibly increasing noise and missing something.

    BTW just found interesting document about active scanning and its issues "Anti-Collision Adaptations of BLE Active Scanning for Dense IoT Tracking Applications" https://zaguan.unizar.es/record/75799/fi­les/texto_completo.pdf?version=1

  • in Bangle.js
    Avatar for fanoush

    In general there is no reason to disconnect the battery (as long as you use just GND,DIO,CLK), it is even better too keep it connected as the device may check battery voltage and shut down when it is 'low'. Also when you don't mess with power you can attach and detach SWD without affecting the device at all. If you need to reset the device it can be done over SWD without disconnecting the power.

    BTW at least with openocd when you end the session it keeps the nrf5x debugging bits powered on so battery will drain fast. With CMSIS-DAP debugger it is possible to detach it in more sensible way via nrf52.dap dpreg 4 0 ; shutdown, this will power off debug interface before detaching so power draw is back to normal. Maybe J-Link does it automatically, I don't know.

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

    don't know about specific commit but
    https://www.espruino.com/Reference#l_NRF­_setScan is the documentation,for options it points to
    https://www.espruino.com/Reference#l_NRF­_requestDevice

    So like there is "phy" or "extended" option there is new "window" and "interval" options with value in miliseconds
    https://github.com/espruino/Espruino/blo­b/master/targets/nrf5x/bluetooth.c#L3008­
    so something like

    NRF.setScan(function(d) {
      console.log(d.manufacturerData);
    }, { "interval":1000, "window":1000});
    

    should probably scan one channel for 1 second. Once you find the device in the callback you may record current time, stop the scanning NRF.setScan(); and start it again somehow synchronized to expected advertising interval. like if that is 1 second then start after 900ms and scan e.g with window of 200 for interval 1000 if that improves things and packets will hit the 200ms window every second. I did not actually try this idea yet.

Actions