Search results for:

I also tried the simulation. At first the PlayBulb app always crashed.
Then I also entered some (most) of the default values I found in the original PlayBulb (e. g. the version strings).
The app then worked, but I could not find/read any values in LightBlue that were changed.

However, I have just now started testing the puck against the real device.
Will give you an update in a few minutes.

Product overview:
https://mbientlab.com/sensors/

Looks almost like a puck:
https://store.mbientlab.com/product-category/metahealth/

Same basic platform?
Can this thing be reflashed to run Espruino? :-?

I just bought me a playbulb, too (because I was curious) and will have a look at it tonight.

What I'd try:
On iOS there is the LightBlue app that can create/clone and simulate any BLE device from service/characteristic perspective.
When I pretend to be a PlayBulb on device A (iOS running lightBlue) I can track what the PlayBulb app on Device B actually sends to do certain things.
(Kind of "man in the middle" debugging)

Thanks.
Consudered it at First, but the counterpart is no PC, Phone etc, but a HM 10 with an Arduino attached.
And I do not know if HM10 copes with HID devices or if it pairs at all...

@Gordon: Actually the first thing was a research if a BLE(!) (not the old standard) was readily available - but not much luck here. There are 5$ HID BT devices, but they won't talk to a puck because no LE there...
Also not sure if a HM-10 will work with a HID device at all. I just tried to keep the protocol simple instead of following a (maybe more complex) standard, but I may try soon.

Thanks for the warning about the pads. Because I don't like hot glue I may secure it with a zip tie.

PS: @Adam79 the puck with the joystick is powered for 2-3 weeks now and mainly sleeping because of the setWatch-function in Espruino.
Still shows 100% battery:

>NRF.getBattery()
=2.84150390624
>Puck.getBatteryPercentage()
=100

I would not worry right now about battery issues unless you do something battery-draining in your code.

@Gordon: See the pictures attached.

The project in a whole is a 12 x 20 LED matrix with 12 rows of 30 LEDs / meter RGB stripes in a 700 x 400 mm box.
It is currently run by an Arduino pico (sorry for that, already considering to migrate it to Espruino later because C/C++ is a different thing and Arduino has quite limited RAM...) with a HM-10 BLE module (the original one, not the clone).

The joystick can first navigate through a little menu (currently: Tetris, Fireplace, ...some other demo...). I am about 95% finished with Tetris now.

This is the puck code: https://gist.github.com/Whizzard/9ca5caeed42c0ce7659cd98231626289

I have also attached some videos from the menu, the tetris intro page (with highscore) and the fireplace simulation.

I am doing exactly that right now.
Hooked up an old arcade joystick mechanic to 4 pins on the puck.

There is not much drain apparently.

I also disconnect after some seconds of inactivity but not sure if that is actually necessary...

Mainly there is a setWatch() function for every direction (and later some buttons) - the rest is communication code for establishing, sending and disconnecting.

Thanks Gordon - totally missed your post.
Currently I was working on the next project already, but I feel like trying your suggestions out.

Good Idea to blank out during updates. And also the thing about array handling which may be the most time-critical aspect in the setup.

+1 for MDBT42 + breakout.

Are you sure that your Nexus actually supports peripheral mode?
http://stackoverflow.com/questions/26482611/chipsets-devices-supporting-android-5-ble-peripheral-mode

Can you see/connect the Nexus with other BLE devices?

battery level maybe?

BTW regarding 1:
a simple way to "power-cycle" the puck is to get your fingernail under the battery and lift it slightly from the PCB towards the springs of the metal clip.

A quick way to reboot a stuck puck or get into bootloader mode when pressing the button while doing this...

For suspending it longer just push in the little transparent plastic tab - but leave it sticking out wide enough so you can just grab it to get it out again.

I glanced over the code. I assume it writes out lines... that means, that the text has to be vertical, is it?

Sort of.
Actually the picture buffer stores 50 lines (should have named that "spokes" or "columns" to make it clearer).
The g Graphics object takes care of the mapping. From g's side the picture is drawn horizontally.
The point is to have each "spoke" ready to be pushed out to the LEDs as an array in function refresh() just after choosing which spoke it actually is at that point in time/revolution.

Next thing is to see this powered by a dynamo...

Would be nice, but I don't think so. It's not trivial to get the power from the fixed dynamo/fork to the rotating wheel. The batteries would last for hours anyway - and besides that it isn't even legal on German roads, so why push it any further?
It was just an experiment - a proof of concept for me.

PS: just found another picture of an old-fashioned digital camera with some longer shutter time.
It doesn't show the nice rainbow colours as nicely, but you get a better impression of the whole frame.

@allObjects thanks.
The dark spots are simply the interference of the rotation with the shutter speed of the iPhone cam.
As I said: with human eyes it looks nearly like closed circle.

The more strips you take (I had only two) the better it looks even for slow rotation speeds - but also needs more CPU power.
I doubt the Pico would be capable of much more strips and/or speed - however I never tried it out on a real bike (yet) to see where the maximum is.

What actually doesn't work flawlessly: using a second timer to update the text in the graphic buffer dynamically. Every time you operate the buffer takes some CPU cycles from the update timer and you have a big gap in the picture for a fraction of a second.

I have attached the sourcecode of this demo in case anyone is interested.

Actually what I did successfully (with an Espruino pico - not a puck) was this:

• have two LED strips with about 20 LEDs each on two separate pins
  
• have a hall effect sensor to a third pin
  
• Pico + Strips powered by 4 x AAA rechargable batteries (so about 4,8V)
  
• built into a bicycle wheel
  
  

The software:

• the time between two passings of the magnet are measured.
  
• the whole time is divided into about 30-40 slices
  
• for each slice a different color pattern is pushed to the two LED stripes
  
  

-> POV effect with JS interpreted Espruino!
Call that too slow... ;-)

(just uploaded a picture and video; the flickering is mainly from the phones camera. Looks quite steady with your eyes)

@goliatone you are right.
Gordon said in post #7:

Ok, it's fixed now. Updated firmware should be attached.

With how busy I am at the moment it's unlikely there will be a 1v91 release until the new year, but at least you can use this firmware until that point.

So this is no official build. You only find it uploaded further up in this thread.

From which side - central or peripheral?
If you're the central you are the one who initiates the connection, so you should be able to increment a counter when this happens.

EDIT:
From peripheral side there are events for connect and disconnect:
https://www.espruino.com/Reference#l_NRF_connect
https://www.espruino.com/Reference#l_NRF_disconnect

This example will flash the green LED on connect and the red on disconnect:

NRF.on('connect',()=>{
  digitalPulse(LED2,1,200);
});
NRF.on('disconnect',()=>{
  digitalPulse(LED1,1,200);
});

It's easy to try with just the WebIDE as connecting central.

I had some similar issues here http://forum.espruino.com/conversations/297205/

Have looked at it again and have a 100% reproduction procedure:

1. Setup WebIDE:

• Reset before send [x] enabled
  
• Save on send [yes, even after reset]
  
  

2. copy into code pane (RHS) and click [^Send]

setInterval(()=>{
  digitalPulse(LED1, 1, 100);
}, 500 );

Left console shows:

[LOGO]
1v90.5 Copyright 2016 G.Williams
>Erasing Flash.....
Writing...
Compressed 32000 bytes to 66
Checking...
Done!
=undefined
Loading 66 bytes from flash...

Result: red LED is flashing, dump shows this:

>dump()
setInterval(function (undefined) {digitalPulse(LED1, 1, 100);}, 500);
// Code saved with E.setBootCode
setInterval(()=>{
  digitalPulse(LED1, 1, 100);
}, 500 );
=undefined

3. try reset(), but no effect: code is still there, LED is flashing

>reset()
=undefined
[LOGO]
 1v90.5 Copyright 2016 G.Williams
>dump()
setInterval(function (undefined) {digitalPulse(LED1, 1, 100);}, 500);
digitalWrite(D5, 1);
// Code saved with E.setBootCode
setInterval(()=>{
  digitalPulse(LED1, 1, 100);
}, 500 );
=undefined

4. change code on the RHS pane to something trivial and click [^Send] again

var x;

Result some death-loop with corrupt data:

>Erasing Flash.....
Writing...
Compressed 32000 bytes to 15
Checking...
Done!
Loading 15 bytes from flash...
Uncaught SyntaxError: Got ?[255] expected EOF
 at line 1 col 1
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
^
in function called from system
>
=undefined
Uncaught SyntaxError: Got ?[255] expected EOF
 at line 1 col 1
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

(tried on two different pucks now)
Maybe someone else can test and confirm this.

@Gordon: Just updated and tested: espruino_1v90.5_puckjs.zip is confirmed to work and catch the promise.
Thanks a lot.

@stevie4711 thanks for sharing the pip command.

However, I had to install gcc-arm to do the build (OS X Sierra here, using homebrew):
brew install Caskroom/cask/gcc-arm-embedded

Will still have to test the compiled ZIP though to verify that it works...

Actually I did look at that thread (OS X here too) and was able to get a first build (untested):

$ git show
commit f795885490e38b0947f322dee1c9fc600101273a
Merge: 5135ed5 8b0f789
Author: Gordon Williams <gw@pur3.co.uk>
Date:   Mon Dec 19 07:59:17 2016 +0000

    Merge pull request #992 from MaBecker/patch-3
    
    update pinStateToString() and dependencies

$ ls -l *.zip
-rw-r--r--  1 user  staff  342147 20 Dez 08:09 espruino_1v90.2075_puckjs.zip

;-)

Wow. That was quick. Thank you very much.
Will test it when I'm home tonight. (Forgot to bring the pucks to work :)

I just got into setting up the build process and had a look into the source as well.
So I should be able to run build myself from now and maybe getting a bit involved too.

Actually I believe that iOS is doing the caching here.
So turning BLE off/on (or rebooting the whole device if things get worse) is the only thing you can do.
I have done a BLE app a few years ago and it's astounding what's happening under the hood in iOS.
I assume most if it is done to preserve battery...