Avatar for Gordon

Gordon

Member since Sep 2013 • Last active Jul 2018

Most recent activity

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

    interval is the the number of milliseconds between the advertising packets getting sent. The default is 375ms.

    Basically in order to do anything with a Bluetooth LE device, you have to get an advertising packet. The device sends a packet and the listens for a very short time after that - and if there's a connection attempt it needs to be sent during that time.

    The advertising packets are sent on 3 different frequencies in rotation. If a device is listening for connection then in usually only listens on 1 frequency - so even at 375ms the advertisement will probably only be received once a second. Most computers will only wait around 2 seconds to get a connection, so higher intervals get progressively more hit and miss for establishing connections.

    If I could have set it any lower and got reliable connections, I would have (in fact early Pucks shipped advertising slightly less often and I had to change it).

    Basically:

    • minimum: I wouldn't ever use - but more advertising packets means a higher chance that one will get through = higher range (unless there are loads of devices doing it)
    • maximum: You'll never be able to connect with this, however if you have something that is reporting a value that doesn't change often (eg. room temperature) and have no need to connect then it's a great way to save battery.
    • If you want to connect reliably, use the default of 375. You might get away with 1000 on some hardware, but I wouldn't bank on it.

    If you really want to save battery more then you can lower the advertising interval and then have code that raises it back up to 375 when there's a button press.

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

    Puck.js firmware can be built for SDK14 which does support Bluetooth 5, but it hasn't been tested enough so far, and in this case I don't think it will help you.

    The longer range is achieved just by slowing down the transmission speed, not by boosting the power in any way - but then I believe the slower transmission is only readable by bluetooth 5 devices, and not any older ones.

    What device are you using to read the advertising data? It may be that something with a better aerial will give you significantly better range.

    Also, have you tried NRF.setTxPower(4) - which will increase the transmission power.

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

    Hi - please can you post in a new thread and I'll try and help out there? @tbd's connection problems don't seem related at all other than that he used 1v99?

  • in Pico / Wifi / Original Espruino
    Avatar for Gordon

    On the Pico and WiFi boards, the actual VBat pin in the STM32F4 is connected straight to VDD - I'm afraid there is no easy way to power just that and not VDD as well.

    There are schematics available (linked from the Pico/WiFi pages) so you could potentially cut the track and wire up VBAT separately - but it would be very difficult

    However you might find that entering the proper standby mode of STM32 gives you the power requirements you need. It's probably around 2 uA vs 1 uA for vbat mode - by comparison the MCP1703T voltage regulator on board draws 2 uA, so you're not going to see a massive difference in overall consumption between the two modes.

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

    This would actually be a really neat use for a Pixl.js (or just a Puck/MDBT42 with a display attached). You could actually display some historical data to give you some idea how things were going, and could then just leave it by the side.

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

    The self-test does come up green though?

    If you did end up connecting a high voltage to D29 I guess that could have caused problems. You could try shorting D29 to GND, which would ensure that if it was working at all it wouldn't auto-initialise the serial port. That should help with battery usage.

    However the bad connection may be related to the corrosion. If you search for the device with your laptop (or the Web Bluetooth screen) do you see a high signal strength - or is it quite low compared to the other Puck.js?

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

    So the Pucks would be static and transmitting advertisements, and the smartphone would receive them to find out its location?

    You'd definitely get some usable location information - but honestly you'd have to try. The accuracy would depend on what distance it is over and whether there are obstacles in the way. It definitely won't be accurate down to the centimeter though!

  • in General
    Avatar for Gordon

    What you're doing looks ok - but you're doing this from an interrupt?

    It's likely that what is happening is Espruino does something like a garbage collection pass outside of an interrupt (very occasionally), but then if your interrupt happens while that is running, it may not be able to get data reliably and so might break.

    Usually that's ok (apart from lost data), but if you're printing data at a high IRQ level and then the output buffer gets full, you can get deadlocked.

    If you're on the Nucleo then I guess you could run a debugger and find out what/where the error occurred.

    However when implementing Bluetooth I decided a while back that allocating JS variables in interrupts just wasn't working reliably. Especially as it looks like you're only sending chunks of 11 bytes I'd just define a static buffer, write the data to that in an IRQ, and then handle that in an 'idle' handler.

    ... or Bluetooth support actually writes data into the input buffer (eg. https://github.com/espruino/Espruino/blo­b/master/targets/nrf5x/bluetooth.c#L211) but I think that's overkill for what you want here.

  • in Other Boards
    Avatar for Gordon

    You're not really supposed to re-use UUIDs for different things, so the Bluetooth SIG suggests you should use a totally random 128 bit UUID (the chances of duplicates and then basically nothing).

    So, go to a site like this and get a random UUID - for instance:

    123fd926-40c3-4cf3-9797-9a8703e32795
    

    Then just change the second group of 4 for all your services and characteristics, eg:

    123f0001-40c3-4cf3-9797-9a8703e32795
    123f0002-40c3-4cf3-9797-9a8703e32795
    123f0003-40c3-4cf3-9797-9a8703e32795
    123f0004-40c3-4cf3-9797-9a8703e32795
    

    So then you have:

    NRF.setServices({
      "123f0001-40c3-4cf3-9797-9a8703e32795": {
        "123f0002-40c3-4cf3-9797-9a8703e32795": {
          notify: true,
          value : [Math.round(E.getTemperature())],
        }
      }
    });
    setInterval(function () {
      NRF.updateServices({
        "123f0001-40c3-4cf3-9797-9a8703e32795": {
          "123f0002-40c3-4cf3-9797-9a8703e32795": {
            value : [Math.round(E.getTemperature())],
            notify: true
          }
        }
      });
    }, 1000);
    

    And you're sorted.

    The only gotcha is advertising 128bit UUIDs is hard since they use up a lot of your available space for advertising - so honestly I'd avoid that and would instead try to find your device based on its name (which you can easily change).

  • in Other Boards
    Avatar for Gordon

    Just to add, the docs for setServices are here: http://www.espruino.com/Reference#l_NRF_­setServices

    Neither read nor write in your example above are valid, so that probably explains why at least 0x2902 isn't readable.

Actions