stevie4711

Most recent activity

• BLE Connection problems + questions

  @stevie4711 started

  • 9 comments
  • 5,724 views

  @Gordon replied
• Building Espruino for Puck

  @stevie4711 started

  • 11 comments
  • 4,758 views

  @Gordon replied
• BLE Connection problems + questions

  in Puck.js, Pixl.js and MDBT42 • 7 years, 10 months

  

  Yes, that was the "Disconnect Alert" I mentioned. This is shown in a popup coming from LightBlue. Sorry for being unclear.

• BLE Connection problems + questions

  in Puck.js, Pixl.js and MDBT42 • 7 years, 10 months

  

  Yes, no problem from a PC. There was never a timeout when connecting from the Web IDE. And yes, as mentioned in the first post I am using 1v91. On both Pucks.

• BLE Connection problems + questions

  in Puck.js, Pixl.js and MDBT42 • 7 years, 10 months

  

  Hi @Gordon, thanks for your answers!

  I think the timeout is around 2 minutes. It happens whether I write from time to time or not.

  I am pretty sure that the problem is that the connection breaks down: I checked from the iPhone with LightBlue and saw the peripheral Puck listed there after a while. And I was also able to connect to it from LightBlue. I think that is evidence that the connection between the two Pucks is no longer existing.

  Another interesting observation is that when doing the connection from LightBlue as a central I see the same problem: After about 2 minutes I get a "Disconnected Alert" from LightBlue. So for whatever reason the connection is disconnected from the peripheral after 2 minutes (or so).

  I agree that it is necessary to handle the breakdown of connections. But on the other hand having a connection for more than 2 minutes is probably important for a lot of applications. Especially since the reconnect takes about 10-15 seconds.

  I like the idea of using gatt.connected to check upfront if the connection is still existing. However in my case it still returns true, although writing fails. Even with a regular timer it still returns true at a point where the connection is no longer existing (because LightBlue lists the peripheral Puck again as advertising).

• BLE Connection problems + questions

  in Puck.js, Pixl.js and MDBT42 • 7 years, 10 months

  

  Hi,

  I have a problem that when connecting two Pucks together using BLE, there seems to be some sort of timeout going on which I did not program. I am using 1v91.

  I have a central and a peripheral Puck. Here is the code for the peripheral, which is pretty vanilla:

  var g_value = 0;
  
  function onInit() {
    NRF.setServices({
      "A4AF09E7-5BC2-46F6-BA08-DA8E0982D84D" :
      {
        0x2A6E:
        {
          readable: true,
          writable: true,
          notify: true,
          value : g_value,
          onWrite : function(evt)
          {
            digitalPulse(LED2, true, 10);
            g_value = evt.data[0];
          }
      }}});
  }
  

  Here is the code for the central:

  var g_gatt = false;
  var g_characteristic = false;
  var g_counter = 0;
  
  function connect(nextStep) {
      console.log("Requesting device");
      NRF.requestDevice({
          filters: [{
              name: 'Puck.js 2061'
          }]
      }).then(function(device) {
          console.log("Connecting to GATT");
          return device.gatt.connect();
      }).then(function(gatt) {
          console.log("Connecting to service");
          g_gatt = gatt;
          return g_gatt.getPrimaryService("A4AF09E7-5BC2-­46F6-BA08-DA8E0982D84D");
      }).then(function(service) {
          console.log("Getting characteristic");
          return service.getCharacteristic("0x2A6E");
      }).then(function(characteristic) {
          console.log("Calling next step");
          g_characteristic = characteristic;
          nextStep();
      }).catch(function() {
          console.log("Error connecting");
      });
  }
  
  function write(value) {
      if (!g_characteristic)
          connect(function() {
              write(value);
          });
      else
      {
          console.log("Writing ", value);
          g_characteristic.writeValue(value).catch­(function() {
              g_characteristic = false;
              write(value);
          });
      }
  }
  
  function onInit() {
      setWatch(function() {
          write(g_counter++);
      }, BTN, {
          edge: "rising",
          debounce: 50,
          repeat: true
      });
  }
  

  Again, nothing special. So when I first press the button on the central, it will connect to the peripheral and write the value. The peripheral will shortly blink green. Connecting of course takes a while, but subsequent writes will be fast. So far so good.

  The problem is that after letting the Pucks rest for a while, the write will fail. Then the catch will come into play and reconnect. So there seems to be some kind of inactivity timeout somewhere. I did not find any documentation for that or any hint how I can avoid that. Any ideas?

  The question is if there is a better way to send integers (preferably not just 8 bits) than sending them as a character and reconverting to an integer? Also, the way I handle the !g_characteristic case feels pretty clumsy. Any better idea on how to handle that? Generally, any hint on how to program the central more elegant is welcome.

  Thanks!

• Error when saving to flash

  @stevie4711 started

  • 44 comments
  • 14,600 views

  @Gordon replied
• E.hwRand() crashing Puck

  in Puck.js, Pixl.js and MDBT42 • 7 years, 11 months

  

  Hi Gordon, just tested the fix, works perfectly now, thanks!

• E.hwRand() crashing Puck

  @stevie4711 started

  • 3 comments
  • 2,693 views

  @stevie4711 replied
• Espruino 1v91 released

  in News • 7 years, 11 months

  

  I just flashed on my Puck and it works very nicely, no problem. Uploaded from the same app.

  Very nice update, I like the NRF.setLowPowerConnection (note that the announcement above wrongly says E.setLowPowerConnection() ), and the hwRand fix especially! Thanks! Also the getAddress() is very nice, I needed that for some kind of self organization of a swarm of puck. So far I configured this in the boot code, but being able to ask for it is great!