Search results for:

Why can't you use the espruino npm module directly to send your code? Or is there some reason you need to get into the REPL afterwards?

Anyway, I'm actually making a Rollup plugin for Espruino. I hadn't thought of using Rollup for bundling Espruino projects before, but it makes perfect sense. It prefers ES modules (import … from, export default, etc), supports treeshaking, has a nice selection of plugins and produces no overhead as long as format is es (the default). For simple Espruino projects without any external dependencies it results in very nice code (before uglification of course). The result is a flattening of all your modules (treeshaken) into one file (one scope) without any wrappers/loaders.

https://github.com/joakimstai/rollup-plu­gin-espruino

Note: I haven't actually tested it with an Espruino device yet, as I haven't got one on me :)

Of course, I'm sure you have your hands full after the release of Puck.js. There's no hurry, we won't get bored with our Pucks any time soon :)

I hope the BME680 lives up to the expectations. It's already used by a few projects, like uRADMonitor model D, and Radu seemed impressed.

Thanks for explaining this so clearly, I really appreciate the time you take to answer questions and help solve issues!

I'll have to evaluate the alternatives here, they all sound doable. Although BLE is far from simple, I actually like the flexibility it provides, makes it possible to optimise for each use case.

Would be nice to be able to enable slow but power efficient continuous connections, especially for long-running sensors transmitting small chunks of data. But I'm perfectly fine with any of the other options for my button if they do the trick :)

Have you had a look at Rollup? It claims to produce smaller bundles than Webpack and Browserify, and it has an uglify plugin.

http://rollupjs.org/

I'm trying to figure out the same thing. See this comment for my thoughts on how it might be solved. I'm sure Gordon will be here soon with a helpful answer, as always :)

If you're comfortable with Node, you might try using noble and Espruino's UART service over BLE like I did (node code, espruino code). Though, as Gordon pointed out, a continuous BLE connection uses much more power, so I'm looking for a better solution.

1. I just use a good old match to pop out the battery. Maybe you could include a match with each Puck? :)
   
2. A setup script for the hub would be nice. I'm hestitant to try my luck on my OpenWrt router after seeing how hard it can be to set it up on a Raspberry Pi. Hope it won't be too difficult to run the hub software on OpenWrt routers with Bluetooth 4.0 dongle.
   
   

I'd definitely buy the uber-puck! Seems like we've been waiting for BME680 forever, maybe it's a vaporsensor after all :D

Edit: Just found out that it's coming out in 2nd half of 2017. @Gordon, if you haven't already got samples of BME680 you can contact this guy who made a BBQ sensor with it (he works at Bosch, his email address is in the comments):
https://www.youtube.com/watch?v=G0rcjygz­mwo

@Gordon Aha, I see. Good to know.

About your suggestion here, I didn't know that a constant BLE connection used so much power. I assumed that since it's no longer constantly advertising it would use less power, but one should never assume. Again, should've RTFM :)

As it is, my current code does keep a constant connection. The node script scans for the button and connects to it as soon as it's found, returning to scanning again if the connection is dropped. When connected, it listens for data sent over the UART BLE service. It's unfortunate if that drains the battery, I'd like it to last as long as possible, this being a button that gets pushed only once a day :)

I looked into having the Puck be the central and the node script the peripheral with bleno, but seems like that puts the heavy lifting on the Puck side? I read an article on making the most out of BLE's advertising mode, to create very low-powered sensors that transmit data using only advertisement packets – unidirectional broadcasting to any listeners.

Would it be a good idea to have the Puck listen for a button push, and only then advertise the button push event (for the Node script to pick up), before going back to idle? Or maybe add a confirmation step by waiting for the node script to connect after receiving the advertisement and then immediately disconnecting again (with a timeout on the Puck)?

In general, what's the best way to have a Puck send an event to a node script, with long irregular intervals between each event, if one wants long battery life? I don't mind having the node script continuously scanning/listening, I'll use forever to make sure it always runs.

(This was cross-posted from this comment)

My node version is done. noble worked great, although it's not the easiest of APIs. Maybe my code can be of use to someone looking to try something similar.

I've also cleaned up the web version, and maybe taken it a bit too far on the visuals..
https://qigong-button.netlify.com/

It's probably the strangest (yet beautiful) thing I've ever made. And I don't even practice qigong..

By the way, I can recommend Netlify for hosting Web Bluetooth Puck projects with HTTPS, as an alternative to GitHub Pages. It's free and easy to connect to git repositories on GitHub/GitLab/Bitbucket/etc. Just git push, wait a few seconds, and it's live. It also supports uploading of files.

(I moved this from my comment to Please post what you're working on..)

My brother had the idea of giving our parents a Qigong button. He had that idea a few hours before our Christmas gathering, so I just had to go for it and try to make a working prototype as fast as I could. I couldn't get the espruino package to work at the time, so I had to use Web Bluetooth instead. I had never used the Puck.js web library before, so it took a bit of poking around to understand how it worked, plus some odd issues, but I got a prototype ready just in time. My parents loved it – the rest of the family had no clue what on earth Qigong was and what it had to do with that strange looking button…

Some issues I encountered:

• You can't connect to a Puck from a website without a user action, like pressing a <button> (I should've RTFM..)
  
• The Web Bluetooth example's onLine() function receives data with a trailing newline, because the Puck uses "\r\n" instead of "\n" which the code expected. It was an easy fix, but took some time to figure out as Chrome's dev tools didn't show the trailing newline.
  
• Just as I got it working, the Puck wouldn't show up anymore when trying to connect :/ Turning Bluetooth off and on again didn't help, but rebooting my laptop did. That is Bluetooth's biggest weakness if you ask me, pairing can be very shaky at times.. Edit: I've since learned that a BLE peripheral won't advertise itself when connected, and if it gets stuck in connected mode you can remove the pairing, thanks to this.
  
• The first time the button is pressed after connecting, the returned data (a string: "qigong") is prefixed by ">" when passed to onLine(). Not sure why that is – any ideas?
  
• It's impossible to paint on silicon! We ended up using black Tec7 paste, which actually worked pretty well.
  
  

You can check out the code here:
https://gitlab.com/joakimstai/qigong-but­ton

And if you want to practice Qigong, try it out with your Puck here:
http://qigong-button.netlify.com

When connected, your Puck will be reset() and my code written to it. I'm using a bit of a hack to write any function's body to the Puck when connecting, for rapid prototyping. That way I could quickly change the code on the website and Puck at the same time.

Now I just have to get it working in Node with noble.

@benddennis Hehe nice!

My node version is done. noble worked great, although it's not the easiest of APIs. Maybe my code can be of use to someone looking to try something similar.

@Fisu The reaction game was just as addictive as you said! Nice one :)

By the way, I can recommend Netlify for hosting Web Bluetooth Puck projects with HTTPS, as an alternative to GitHub Pages. It's free and easy to connect to git repositories on GitHub/GitLab/Bitbucket/etc. Just git push, wait a few seconds, and it's live. It also supports uploading of files.

@benddennis You should check out https://github.com/audiojs as well, looks like a nice set of audio utilities for Node.

I love how such a simple interface as a button can open up for so many interesting ideas. Must be really cool to use Puck.js if you're just getting started with programming, it's a magic button! It's of course just as much fun for those of us who like to create interesting stuff with code :)

(Edit: Moved the rest of my comment a new post in Projects as it got quite long..)

I'm giving my parents a Qigong button for Christmas. They perform Qigong every morning, by playing an MP3 file of an old Chinese sage offering instructions in Engrish with traditional Chinese music in the background. They just play the MP3 file on their mobile phones, which takes a while to get set up, and sounds horrible.

My gift will be a Puck with the Yin/Yang symbol painted on it. When they press the button, it will (hopefully) connect to my dad's Mac and play the MP3 file over our living room speakers. I'm thinking of using Node and noble on the Mac to receive the signal and play the MP3 file.

Should be a fun project and a nice gift :)

@Gordon Why would require()ing a module from SD and executing its handler/callback be a bad idea? My thinking was that loading code on-demand and unloading it when done would be better than having everything in memory at all times. One would be able to have a lot more dynamic pages than would otherwise fit in Espruino's memory. Each module would of course have to be small enough to fit in memory when loaded.

Or were you thinking of latency, energy consumption or some other factor?

I like the require() idea of @allObjects, to store dynamic pages as modules on the SD card, load them on demand and unload from memory when done. Could be made to be pretty flexible, with the modules exporting properties and methods to be used by the webserver.

One could even create a dynamic lightweight routing table in memory by loading each of the "route modules" one by one, storing its parameters + a reference to its file (not the callback itself) in the routing table and then unloading the module from memory. On lookup, the server would load the matching route's module, run its callback, and unload it.

The route modules could live in e.g. /routes for simple automatic retrieval. Their exports object could look something like hapi.js' routing definitions, even having the server support stuff like parameters in path definitions.

I just received my module from Embedded Adventures, unfortunately I won't have time to get started on it until May. Want to borrow mine, @alexanderbrevig?

Nice board! I'm getting jealous, hope to get started with custom PCB designs myself this summer. Maybe it's foolish, but I'd like to go straight to SMT, because that's where the most exciting parts seem to be. Too ambitious?

Have any of you tried OSH Stencils? They write that their polyimide stencils last for 75-100 uses, up to 300+ with proper care. US based, but cheap shipping.

By the way, what methods do you use for SMD soldering? I've been eyeing the Kickstarter funded Reflowster, which makes the DIY skillet/toaster reflow soldering station method easy to use and reasonably accurate. It's pretty cheap, at least compared to reflow ovens!

@alexanderbrevig Apropos lasers, I know that BitRaf in Oslo just got a laser. They're a very friendly and helpful bunch of geeks, maybe an option :)

Assuming DASH7 is used, wouldn't OSS-7 on a CC430 be just that?

@alexanderbrevig Btw, are you using OSS-7 on the CC430?

No need to stop, this is great stuff! :)

Your POC code looks very promising, I'd definitely be interested in contributing in whatever way I can. Looking forward to talking more about this over a beer some time after easter!

Yup, the MKW01Z128CHN (most difficult name I've ever seen) got more and more interesting as I read the datasheet, looks like a nice design to my untrained eye.

You're absolutely right that there are cheaper and easier ways to do low-powered RF, I was really trying to find the ideal solution for a tiny low-powered wireless sensor. That's a long way off, but I like checking out the territory in advance.

STM32F030 with 256 KB doesn't seem to be out yet, at least not in lower volumes, but it looks like a good option in combination with an external transceiver. Very good point about no extra software effort required!

I've been thinking about the possibility of using external memory. Good to know it's not too difficult, should the need for that arise some day.

Good luck with the firefighting and shipping! I'm very grateful that you're making Espruino at all, it has opened up the world of microcontrollers for me :)

€15.66 is much cheaper than the WizziMote's €40 though. It lacks an antenna connector, but has an accelerometer and a thermistor.

To continue my train of thought on Cortex-M4 MCUs with sub-1GHz RF, this one comes close:
http://www.freescale.com/webapp/sps/site­/prod_summary.jsp?code=KW0x#MKW01Z128CHN­

Costs from €5.39 to €3.21 at Farnell (£4.30-2.57), about the same as CC430F5137.

It's got a Cortex-M0+ with 48 MHz, 128 KB flash and 16 KB RAM, which Espruino should be able to run on. But how handicapped would Espruino be? How much would have to be stripped away? I know one doesn't need all of Espruino's features on a simple IoT sensor device, but would it be able to remain a good platform to run simple IoT sensors? Or would it be too limited for even that?

Am I right in thinking it's mainly a question of time and effort that is needed to make Espruino run on the chip, including porting it to the MCU and stripping it down?

It does look interesting, the price isn't too bad either, and it's open source. Too bad CC430 doesn't run Espruino (yet?)…

Hm, what ARM Cortex-M4 based MCUs are out there that have a built-in sub-1GHz RF transceiver? Something like the nRF51822, only for sub-1GHz. That would make Espruino based low-power IoT devices/modules easier to build, and cheaper to produce.

@alexanderbrevig Hah, awesome! We definitely need to grab a beer and talk Espruino soon (and DASH7). As a quick teaser, I'm planning to use DASH7 with Espruino for small low-powered sensors that push data online via a gateway. Not so different from what you're doing. I'm currently abroad but will be back in Norway after easter, I'll send you a message then.

Btw, OSS-7 also supports M4 (Pico), I just noticed.

Just to complicate things, the value of this actually depends on how the function is called.

A function's this keyword behaves a little differently in JavaScript compared to other languages. (…) In most cases, the value of this is determined by how a function is called. It can't be set by assignment during execution, and it may be different each time the function is called.

https://developer.mozilla.org/en-US/docs­/Web/JavaScript/Reference/Operators/this­

Which is why we have .bind(), .apply() and .call(). Learn to love those, while they feel a bit like a hack they're also very powerful :)

Also worth reading to understand the flexibility of functions/objects:
https://developer.mozilla.org/en-US/docs­/Web/JavaScript/Reference/Functions

Really cool project!

Curiously, the guy behind OpenTag wrote this blog post just yesterday:
LoRa as a PHY for DASH7