Search results for:

You can measure it very simply by looking at the change in light that passes through your finger. For example this was a quick hack I did a while ago that uses your webcam to measure your pulse. It's not great, but in the right conditions (light behind your finger) it does work!

https://gfwilliams.github.io/HeartRate/

So just a light on one side, and a light sensor on the other.

However you can buy more professional units which (I believe) have two lights and sensors at different wavelengths. One is a wavelength that is affected by blood, one isn't - and you can then just compare the two sensor readings over time to get a pulse.

Sure, probably the easiest way is to just store the times in a second array. Try something like this:

digitalWrite(B7, 0); // Set B7 to GND
digitalWrite(A8, 1); // Set A8 to 3.3V
// Because we're not using the module, we have to manually pull up the data pin
pinMode(B6,"input_pullup");
// Keep somewhere to put the signal times
var times = [];
var history = [];
// now watch the input
setWatch(function(e) {
  // work out how long the pulse was, in milliseconds
  var pulseLen = 1000 * (e.time - e.lastTime);
  // then save it, if it was less than 1 second
  if (pulseLen < 1000)
    times.push(pulseLen);
  else {
   history.push(new Float32Array(times));
    times = [];
  }
}, B6, {repeat:true});

That'll stick everything in history - it uses Float32Array to make sure it can fit a lot of IR recordings in if you need it.

It's worth checking though - most IR remotes just repeat the same pattern over and over (rather than different ones)

Ok, this is now done and will be in 1v92. You can do:

NRF.setServices({
  0x180D: { // heart_rate
    0x2A37: { // heart_rate_measurement
      notify: true,
      value : [0x06, hr],
    },
    0x2A38: {
      readable: true,
      value: [0x02]
    }
  }
}, {advertise:[0x180D]});

to start advertising the heart rate service.

The problem is actually with your node.js code :) If you look at what's in your buffer:

> var s = String.fromCharCode(0x00,0x2B,0x20,0xFC)­;
undefined
> var b = new Buffer(s);
undefined
> b
<Buffer 00 2b 20 c3 bc>
> b.length
5

You'll see that it's magically turned the string into a 5 byte buffer. Most likely it's because it is interpreting your string as a UTF8 string, when I guess you intended to use it just as a string of bytes.

Check out this post: http://forum.espruino.com/conversations/­301802/#comment13524797

I just changed the firmware to use high drive and to tweak the duty cycle, and I'm getting around 90cm out of a standard Puck.js now!

Nailed it :) There's a build for Puck.js in here (the zip file): http://www.espruino.com/binaries/travis/­db6c9ab777025acbc5a419b022023eab3ad7b9a1­

If you try uploading that firmware you should find that range has increased by almost 3 times. I can get almost 90cm out of it now (or 70cm with the case on).

Wow, nice use of array.shift() and the setTimeout argument there!

Yes, it's not great at long distances. It will be slightly better without the silicone top on, but perhaps only 50%.

The idea is that because Puck.js is wireless and battery powered, you stick it near the thing you want to control with IR, and then you either control Puck.js with another Puck.js or via a phone.

I have just found a potential software issue which means that Puck.js might not be driving the IR LED quite as hard as it could be, so I'll see what I can do to improve that now - however I can't promise much.

Another option mentioned in the post @navas linked is to wire up an external IR LED. You could even wire up multiple LEDs in different locations if you really needed to send signals in different directions (eg, one inside a cupboard)

Thanks! Is that the 0.50 firmware? I'll stick it on the main Espruino site.

It'd be interesting to see why the new firmware doesn't work though - it could just be a different baud rate I guess.

Thanks! That's great!

Yes, 3x 100Hz should work ok - it might glitch very occasionally, but it's usable.

The way it's implemented, 3x 100Hz has about the same load as 1x 300Hz - so it should be fine. If you need more PWM you could always try lowering the frequency.

15mA would seem to be fine (especially if sending short pulses of IR).

See the graph on http://infocenter.nordicsemi.com/index.j­sp?topic=%2Fcom.nordic.infocenter.nrf528­32.ps.v1.1%2Fgpio.html at the bottom

Having said that, it depends what I've set the 'drive mode' to. And looking at the code it seems I have set the drive move to 'standard', so the max you could use is 5mA.

I should probably set the drive modes to high for everything, but I wonder whether anyone can think of a reason why this would be bad

:) thanks! It's the APT1608F3C - so also Kingbright, although not one of the low power variants.

If there was one I could stick in, that'd be amazing! That really would be a nice easy improvement for this next production run.

edit: given the recent firmware change that's pushed the range up to almost a meter, this might not be needed now :)

Yes, it should work. Going through the README_* files in GitHub might help.

But basically you just make your own boards/BOARD.py file - and base it in something with a similar chip. IIRC there is already this one: https://github.com/espruino/Espruino/blo­b/master/boards/OLIMEXINO_STM32_RE.py

I heard there is a way to use IRQ and make it work on esp8266. Is there any work in progress?

Not as far as I know. I'm trying to use the patreon page to get some funds to look into ESP8266 a bit more, so I guess at some point that might happen.

However I think at some point WiFi takes priority over everything, so it might never be reliable.

since it lacks PWM support

Soft PWM does work ok. It seems to be ok-ish for ~100Hz or so, which might work for your lighting?

Thanks for letting me know! Perhaps version 1.3 was doing something strange

I haven't made any changes to the WebIDE settings for any of the examples. (for minification - left factory defaults as is - yes?)
This caused the error: Uncaught SyntaxError: Got UNFINISHED STRING expected EOF at line 1 col 8640

I'd be almost certain you've definitely changed the Web IDE settings, since the file you gave me doesn't have any 8600 character long lines. 'minification' in settings (the first item) is supposed to say 'No Minification' and I bet it doesn't.

Just to follow up with what you sent in the PM, as this is probably useful for everyone:

I said that this was because minification was turned on, and the Web IDE had rammed everything into one giant line of text, which overflowed the available memory and got cropped, not finishing the second string.

I'm not in agreement that there isn't any managing to finish the second part

It's not the second string, the line that's printed in the error actually starts thousands of characters from the start of the file . If you take a look under settings->console you should see the code that's actually uploaded.

It should look a lot like this - I won't post the whole thing in the forum because it's huge:

"\u0010reset();\n\u0010\u001b[1dfunction­ pageHandler(b,a){u=url.parse(b.url,!0),c­onsole.log('[074] inside MaBe pageHandler u [ '+b.url.toString()+' ]'),console.log('[075] inside MaBe pageHandler u.method [ '+u.method+' ]'),console.log('[076] inside MaBe pageHandler u.host [ '+u.host+' ]'),console.log('[077] inside MaBe pageHandler u.path [ '+u.path+' ]'),console.log('[078] inside MaBe pageHandler u.pathname [ '+u.pathname+' ]'),console.log('[079] inside MaBe pageHandler u.search [ '+u.search+' ]'),console.log('[080] inside MaBe pageHandler u.port [ '+u.port+' ]'),console.log('[081] inside MaBe pageHandler u.query [ '+u.query+' ]'),b.method=='POST'&&
...
'+a.ssid),console.log('[L905] details.mac '+a.mac),console.log('[L906] details.channel '+a.channel);}),setTimeout(onInit,1500);­\n\n"

But DOCTYPE is buried in there towards the end. So when you get this:

>ERROR: Out of Memory!
Uncaught SyntaxError: Got UNFINISHED STRING expected EOF
 at line 1 col 8640
...Wifi');var C={SSID:'',PAGE:"<!DOCTYPE html><html lang=\"en\"...
                              ^

You'll notice that the pointer is pointing to the second string on the line, but actually that string starts at nearer column 7700!

So the fact that the error is at column 8640 means it's at character 940 of your string, when you say your string is about 1k long - so it's cropped.

Despite the displayed error, the code executes as expected.

I believe it will have executed everything up until that point. Everything after the declaration of C will have been lost, but presumably that's not used in your code.

If you were getting the out of memory error all along, that probably explains everything

When you reduce the code size enough that you get no error, everything executes fine and all functions get added. When you get the error uploading because the code is too big, some functions don't get added and so the final code looks smaller.

and performing the calculation: 1700 * 12 = 20400 which exceeds the physical capacity of 12284 actual bytes allotted. On to 12288 / 12 = 1024 a rough approximation on the number of 'jsvars' that will fit in the available memory.

12288 is the amount of bytes in flash - after compression. But yes, 1024 is a reasonable minimum.

However depending on what code you upload, Espruino can't get 100% usage - see http://www.espruino.com/Performance

Q: Author note: Still would like to know why 1700 is the magic limit and not around 1024 a calculated value

It's because 12288 is the amount of Flash, but you have more RAM available. At >1024 vars it's 16 bytes a var, so 1700 * 16 = 27200 bytes.

Q: Despite indicated remaining memory, has this 8K file reached a perceived capacity limit for this ESP to handle?

It's because you're trying to upload 8K bytes in one giant line. When Espruino has a string that it has to append to a few characters at a time, it's not as efficient at storage, which explains why it runs out more quickly.

Q: Is there a suggested limit. e.g. has a known reasonable physical limit been determined?

It depends on the board, and even on the firmware version. I don't know for sure.

---

But just to sum up:

It looks like there's a 'bug' in minification which causes everything to be put on a single line, but only when 'Minification' is set to 'Esprima (offline)'. It's not the default. Set minification to Closure(online) - Whitespace Only and I bet it'll work perfectly, but the default is actually 'off'.

I filed a bug for this here: https://github.com/espruino/EspruinoTool­s/issues/61

But yeah, if you get errors, always look at the very first error, and don't always take subsequent ones at face value :)

Or you could use Espruino WiFi, which would work perfectly :)

That's an interesting little device! And it would run Espruino :)

Doesn't say which nRF51 it is - there may be very little memory available for code - made even more difficult by the way the LoRaWan protocol would need implementing in it too.

I wonder if they're releasing an nRF52-based one - that could be a really useful module.

Yes, ints and strings are fine. If it was being spec compliant, JSON.stringify should really replace it with undefined I believe.

:) Glad you found it!

If you powered the device from an external supply (not USB) then I imagine the Espruino console would move back to serial and you'd be able to use the IDE as you were doing (at 9600 baud)

Wow, very nice!

If you don't want the click, you could put Puck.js in one sock, and a magnet in the other - then you could use the magnetometer to detect roughly where one foot was in relation to the other :)

Yeah, other Patreon folks do votes on what to work on next. To a certain extent I already do that with GitHub and what gets requested on the forum - I think it's going to be hard to get right - I don't want to suddenly start ignoring everyone that's made Espruino what it is in favour of Patreon :)

We'll see how it goes - I may well do something later, but I think for the moment it's more simple.

Great, glad you got it sorted!

Yes, that'll be fine.

If your iron has a relatively fine end on it then it should be fine.

For the best finish, I'd:

• use solder wick to get any existing solder blobs off the pads
  
• put fresh solder on one pad, and while it's molten push the crystal into the solder with a pair of tweezers
  
• heat up the other pad and add solder to make contact
  
  

It might be hard to get the soldering iron on to the pad, so i'd consider shifting the crystal over a little so you can be sure you have a bit more space to get the tip in

And first try it without the capacitors, because they can be a pain to do with a soldering iron as they're so small :)

It depends on the size of the array I guess, and whether you want it human readable or not.

Text

// write
fs.writeFileSync("foo.txt", array.toString());
// read
array = new Float32Array(JSON.parse(fs.readFileSync(­"foo.txt")));

Binary

// write
fs.writeFileSync("foo.bin", E.toString(array.buffer));
// read
array = new Float32Array(E.toArrayBuffer(fs.readFile­Sync("foo.txt")));

For bigger arrays binary would be better, and for very big arrays you'd be looking at multiple save calls.

Yes, that's odd - it seems like JSON.parse should really produce an exception. Could you file a bug for it on GitHub?

The whole parsing thing is annoying. It did work, and then someone raised a bug because it worked when it should have failed, and that could have been a security bug - maybe. So I had to disable it :(

So if you care about stuff like that, now you have to use eval - but if you do that then you need to be sure you trust your source of data :)