Search results for:

The SunLED XZTNI53W-8 may be a drop-in replacement.

• 60° angle, vs 120° (Kingbright)
  

• 2.8 mW/sr, vs 2mW/sr (Kingbright) (CIE127-2007) (both at 20mA)

• USD 0.23/ea in qty 100.

Something like the SunLED XZTNI55W-3 might be interesting down the road. The footprint is 3.2 x 1.6mm (vs 1.6 x 0.8, for the Kingbright APT1608F3C).

• 40° angle, vs 120° (Kingbright)
  

• 4.8 mW/sr, vs 2mW/sr (Kingbright) (CIE127-2007) (both at 20mA)

• USD 0.22/ea in qty 100.

Supposedly, these are “Ideal for indication light on hand held products.” 🤔

This might also be able to run Espruino. It's ESP32-based.

PyCom LoPy 1.0 - LoRa + WiFi + BLE
https://www.adafruit.com/product/3339

Hey, @hansamann. One thing that occurred to me was leaving the IR Puck nearest your receivers, then using BLE to talk to that Puck from either

• a Web Bluetooth app on your phone
  
• a second Puck
  
  

But adding a 5mm IR LED is probably a better bet. @Gordon, what's the recommended maximum mA draw for such an LED?

@gordon, which model of IR LED are you using on the current Puck hardware? I'd love to help track down one that extends the range.

Off the the top of my head, I'd say it's doable on nRF52. Other questions would that would guide one in selecting hardware:

Do you want to forward packets from LoRA, BLE, or both?
Are you connecting the gateway to the internet via Wi-Fi or Ethernet?
Do you want single-channel, or multi-channel forwarding?
Where is the gateway to be installed?

Yes! Maybe map Puck.mag() to HSB colors. Thanks for the motion detection code the other day. Didn't realize the magnetometer was so versatile. Sorta overlooked it at first, having only played with accelerometers and gyros.

Will have to fork something like https://learn.adafruit.com/tv-b-gone-kit.

Just posted a video to YouTube of a work in progress:

Hello, Puck! – Puck.js in 30 seconds.
https://youtu.be/EZPnjGKtMAk

Added this description:

Hello, Puck! demonstrates many of the built-in features of Puck.js.
Like Arduino, you can use Puck.js to build IoT devices. While you code
Arduino in C++, Puck.js runs JavaScript. Like the Amazon Dash, you can
program behaviors accessible with a single button click.

• Web Bluetooth IDE and console • Button • RGB LEDs • Temperature
sensor • Battery sensor • Magnetometer: movement, orientation,
magnetism • Nearby BLE devices • Light sensor • NFC URL broadcasting
and field detection

Visit http://puck-js.com to learn more.

I'm cleaning up the code and will share it here.

Thanks for all you do, @Gordon. Subscribed and tweeted!
https://twitter.com/erico/status/840333951109545984

Thanks!

By array, I assume you mean object? Otherwise, that works!

>xxx = [];
=[  ]
>xxx["abc"] = "def";
="def"
>xxx
=[  ]
>xxx
=[  ]
>xxx.abc
="def"
>nnn = {}
={  }
>nnn["abc"] = "def";
="def"
>nnn
={
  "abc": "def"
 }
> 

Sample code for NRF.setScan(xxx) hangs during scanning. Where you see the block cursor in the attachment is the last character that was sent to the console. Typing reset() doesn't do anything. Cycling power on Puck works though to reset.

Also, calling NRF.setScan() with no argument (in order to stop scanning) isn't working. packets variable continues to decrement, and scanning proceeds.

Reproduced on 2 Pucks, both running 1v91.

Edit: I added console.log(process.memory());, and I can see free blocks dropping by about 500 as each packet is processed.

That sounds like an elegant solution – especially as it requires no user attention.

I called it exactly as above, not with the forceSoft option.

I tried different timeouts; 50ms seemed the minimum in my code to get consistency. I'm fine with a 1/20 second reading in my use case. You also mention not taking more than 5 readings/second, so that's a gating factor, anyway.

You could also have a highAccuracy option (or simple Boolean) in Puck.light(), that when present, adds a bit more delay.

I'm using this, BTW, in a kitchen-sink app that exercises all the sensors, incl NFC, and the RGB LEDs. I'll share that here soon.

@Gordon, process.version = "1v91".

I'm also doing analogWrite(LED1, xxx) elsewhere in my code, if that makes a difference.

@Gordon, Puck.light() is returning lower values than expected after the first call. Probably because I'm lighting up LED1.

Short story: I think this can be fixed by extending the settling time delay in jswrap_puck_light().

I type this in the console, and I get:

>LED1.write(1);
=undefined
>LED1.write(0);
=undefined
>Puck.light()
=0.15357589721
>Puck.light()
=0.55925130844
>

The last 0.559 reading is the most accurate.

Here's my workaround that gives consistent light readings:

var checkLight = function(){
  digitalWrite(LED1,0);
  analogRead(LED1);
  delay(50);
  light = analogRead(LED1) * NRF.getBattery() / (3 * 0.45);
  light = Math.round(light * 100);
  if (light < 20){
    console.log("  Seems pretty dark in here: " + light + "% brightness");
  } else {
    console.log("  Seems light in here: " + light + "% brightness");
  }
};

var delay = function(milliseconds){
  // Always try to use setTimeout or setInterval instead
  // of this function. This function, used for long periods
  // uses battery power!
  
  var timeout = new Date().ms + milliseconds;
  while(new Date().ms < timeout);
};

Like your C code for jswrap_puck_light(), I reset the LED1 pin, take a reading, wait, and take another (better) reading. But I wait 50 milliseconds, rather than 5 milliseconds.

They're all Kingbright - APT1608LSECKJ3RV, APT1608LZGCK and APT1608LVBCD. The idea is they're better at low currents like ~2mA

Your LEDs are 100mcd, 50mcd, 24mcd for RGB, respectively.

This RGB LED, also Kingbright, might be interesting.

It's cheaper, brighter, and blended.

It's 60mcd, 180mcd, 30mcd (typical) at 2mA. Overall, that's 100mcd brighter than your current ones. (chart attached)

It's about USD 0.31 ea, qty 2000, vs about USD 0.46 for your current 3 LEDs. It's 2mm high (about 1mm taller than your current ones) but should have a more blended color output. It might end up with a smaller beam, but that would also be perceptively brighter. I think this would increase perceived quality.

One could still do the half dome mod (ping pong ball or 3D printed form).

I'm wondering now whether a thin disc of perspex with one side roughed up would solve both problems?

Edge-lit, laser-etched Perspex (acrylic) is a great way to do diffusion in small quantities; I do this frequently when prototyping products at the design firm where I work. But there isn't enough room in the Puck to do it properly. And that's fine.

They're all Kingbright - APT1608LSECKJ3RV, APT1608LZGCK and APT1608LVBCD. The idea is they're better at low currents like ~2mA - since you shouldn't be drawing loads of power out of the CR2032

Wow, those are very efficient! I'll see if I can find something comparable in RGB that's thin and diffused.

I've noticed the silicone picks up dust too - I'm not sure there's much that can be done about that. At least if I were to sell tinted black covers then it would be less obvious :)

I'd just try washing the silicone cover with some hand soap. Tinted covers might reduce LED brightness further, of course.

Tapping the device with an Android phone could redirect to puck-js.com/go

It does that already :)

Oh. I guess I could have tried that with an Android phone before posting. :-D

Light mixing: right now I'm using some special high-efficiency LEDs…

@Gordon: Can I ask which LEDs you're using? (Or what their levels of efficiency are?) I love hunting down components.

Also I'd found that putting a little blob of something like hot glue over the LEDs diffuses and mixes everything a lot

I thought about that. Now I'll def try that with one of my Pucks!

Puck.js hardware v1.0e is awesome. I'd suggest deferring any revision at all, if demand is increasing.

That said, here's a small list of tweaks to consider:

1. Preload with fun program: When BBC Micro:bit turns on, it runs through a set of interactive demos. Perhaps Puck.js could do something colorful for 10 seconds, and go to sleep. Pressing the button would stop, if it hasn't finished. Pressing the button while stopped would restart. Perhaps it's already also loaded with NFC, iBeacon, and Eddystone advertisements. Tapping the device with an Android phone could redirect to https://www.puck-js.com/go. Similarly, Eddystone (and maybe iBeacon) would be ready to test. I could take a shot at writing this.

2. Improve LED color blending: Replace 3 discrete R, G, B LEDs with a composite RGB LED. Probably save board space, too.

3. Keyed insertion: Add asymmetrical notches to PCB and ridges to case to orient board, and ensure right-side-up. HT @ChristianW

4. More visible battery insulator: Replace transparent battery insulator (for storage/shipping) with colored one, possibly with printed icon/message.

One of my Puck.js's got into a state where I couldn't save(); without the Puck crashing (and the IDE disconnecting). I tried reloading the current firmware (1v91, via DFU on nRF Toolbox for iOS), but the problem persisted.

Finally, I tried E.setBootCode("");, and that seemed to make save(); possible again.

process.version will tell you the version of the firmware installed on your device.

@Gordon, I was thinking about several similar frameworks with a lot of traction, large communities, and big name sponsorship.

Have you checked out GitHub's Electron? It's used in building the popular, multi-language Atom editor.

Also, there is Adobe PhoneGap, which targets iOS and Android devices, wrapping your HTML/JS/CSS in a mobile native app. (Disclosure: I helped create PhoneGap at the iOSDevCamp hackathon in 2008.)

Additionally, Facebook's React Native might be interesting. Logic is in JavaScript, and UI elements are native to mobile. Adaptations are emerging for desktop macOS & Windows.

The docs for NRF.setServices() (for Puck.js) contain an example of creating a characteristic for the onboard LEDs.

@Gordon also posted an example of having the button change a characteristic.

For simple projects, where you don't require anything beyond 0.1" pin spacing, one might consider the Adafruit Flex Perma-Proto - Half-sized Breadboard Flex-PCB. I really like that you can easily cut this to your required size with regular scissors.

It’s USD $7.50 as of this writing.

However, what if there was a flexible protoboard that also includes SOIC/SMC-compatible footprints, and that you could still trim to just the area needed by your required components?

There’s an opportunity to create an advanced revision of this, while continuing to allow gentle folding, so as to support development of most any tiny, embedded consumer product.

It could be Espruino-branded, yet also useful to – and compatible with – Arduino & Raspberry pi, while still promoting the Espruino platform to both professional and hobbyist embedded developers.

Creative Technologist, based in the San Francisco Bay Area, open to travel

Connect with me on LinkedIn
Follow me on Twitter