Some Puck questions

Hi, hopefully this isn't question overload:

1. Is is permissible to use a puck/pico in a commercial product as long as I mention that it uses it?
   
2. Is it possible to change a Puck's bluetooth broadcasting name to an arbitrary string?
   
3. Is it possible to prevent the puck from broadcasting its name, but allow connections using its MAC/Name/ whatever?
   
4. What is the range on a Puck?
   
5. For question 1 + 2, if they can't be done on a puck, could the be done with a Pico using a bluetooth shim+MC?
   
6. Would a pico with bluetooth have a longer range?
   
   

I've got a project in mind that is slowly crystallising, but I want to understand limitations before I dive in.

Hi! No problem!

Is it permissible to use a puck/pico in a commercial product as long as I mention that it uses it?

Yes, absolutely! There's no need to mention you're using it either.

What I do ask is if you end up using our software but totally your own hardware (so you're not buying anything from us), then you give us credit, and don't use the Espruino/Puck.js names as a way of selling your product.

If you bought the thing from us then you're welcome to mention Espruino or not - whatever works best for you.

Is it possible to change a Puck's bluetooth broadcasting name to an arbitrary string?

Yes, it's easy - it's just done with NRF.setAdvertising

Is it possible to prevent the puck from broadcasting its name, but allow connections using its MAC/Name/ whatever?

Well, you can change the name, and can make it empty - but you have to advertise something (even if it's without a name) to be connectable - it's just the way BLE works.

What is the range on a Puck?

I haven't gone and done proper tests with the final Pucks... The manufacturer of the module we use has done tests with their module and says "over 80 meters in open space.". I'd expect the Puck to be a little less because of the casing though (and by default it's not set to use full power for transmission).

However: as with all the Bluetooth stuff, it hates brick walls - I reckon the range goes down by at least half for every brick wall.

For question 1 + 2, if they can't be done on a puck, could the be done with a Pico using a bluetooth shim+MC?

Yes, but not as easily. There isn't a nice library to interface the HM-10 Bluetooth LE module to Espruino, so you're stuck reading their manual and writing AT commands... It's a bit of a drag.

If you're just after something that's easier to embed in your product than the Puck, at some point I'm planning on offering MDBT42 modules (the ones used in Puck.js) pre-programmed with Espruino, and potentially offering them on a break-out board.

Would a pico with bluetooth have a longer range?

It totally depends on the Bluetooth module used - but probably not. For Puck.js I used the more expensive module that has a ceramic antenna and should get 30% more range - most of the modules you could get to stick on the Pico use printed antennas.

I'm planning on offering MDBT42 modules (the ones used in Puck.js)
pre-programmed with Espruino, and potentially offering them on a
break-out board.

Yes please @Gordon.

Are you interested in the breakout board, or just the bare modules?

Thanks you very much for your clearly well considered answers!

The MDBT42 module sounds great, what functionality might it have out of the box?

Setting the name to blank works perfectly well for my purposes.

Final question (I promise): From this answer I can see that it's possible to hook a wifi module into the puck, but it would have different power requirements. IRC, the highest sensible voltage for the puck would 3.7v. If I used something like this to power the puck + wifi module, would that be sufficient? Would the Puck still be able to sense its battery cap?

Apologies if I'm rambling. These questions are coming to me as I type.

Both !

I'd be interested in one breakout board to do my development on and a number of bare modules to use with custom PCBs.

I've used RN4020 modules before but they always felt limited.

The MDBT42 module sounds great, what functionality might it have out of the box?

It's basically everything the Puck does (without the magnetometer, lights or light sensor)

it's possible to hook a wifi module into the puck, but it would have different power requirements

Yes, WiFi is pretty brutal compared to BLE. Around 200mA max for the ESP8266 vs 4mA for the whole Puck. The coin cell isn't going to cut it!

Having said that I haven't personally tested WiFi on the Puck yet - i'd need to do that.

IRC, the highest sensible voltage for the puck would 3.7v

Yes - which, annoyingly, is just less than the LiPo as it'd come fully charged. I'd suggest adding a regulator of some kind - you can get quite nice 3.3v switching regulator boards, some of which even handle charging as well.

However, 'LiFe' cells are about the perfect voltage, so you could use one of those directly.

Would the Puck still be able to sense its battery cap?

Not sure I understand? It could sense battery voltage, but getBatteryPercentage would be off - you'd have to make your own :)

@Adam79 interesting idea - maybe I could offer kits with a breakout and pre-programmed modules.

What did you program the RN4020 in?

Definitely want/would buy MDBT42 + breakout.

Out of the box they have a small scripting language, but limited as I said. I created a proximtiy/alert project and then gave up.

Having javascript and BLE in such a small module would be great, my temp sensor in every room project might finally get started.

I have a similar question:

• Is it possible to require pressing the button to complete pairing? I don't want anyone in the world to be able to pair with my puck. Or is there some other BLE solution to preventing anonymous pairing access?
  

+1 for the modules and breakout. Sweeter if the breakout were in the format of the original Espruino board or if Pico footprint.

@maxogden I've been meaning to write something up about locking it down. Right now you can't stop pairing, but you can:

• Hook onto the 'connect' event and disconnect immediately if you don't like the address
  
• Stop advertising completely so nobody can connect
  
• Don't expose the UART service, so even if people can connect they can't access the JS interpreter
  
  

I'm planning on adding support for bonding (the encrypted comms) as that's needed for HID on Windows, and I'll see if I can do something about blocking at the same time - there is this idea of a 'whitelist' of devices that connections will be allowed to.

@CanyonCasa I was wondering about that - the Pico format wouldn't be able to expose all the pins, but I guess that'd be ok - it's still a lot.