Search results for:

Great! Sorry it wasn't in there from the start - I guess I should have checked more.

Thanks for finding it though - that's massive. Just a shame all the new batch of Pucks have 1v92 on them with the issue in :)

Well, that took longer than expected. I'd used a neopixel library from somewhere else, and it had some interesting issues - looks like the extra info being output to the neopixels was in fact the contents of the stack :/

In a few minutes you should find a binary here, which has it all fixed.

http://www.espruino.com/binaries/travis/­26bdea61c0b573299e3df981190359feb8da1379­

@benjaminbenben ^^^

but I think there's weird capacitance or grounding issues making the signals a bit unreliable.

It's not just you. I just tried it out here (I told @benjaminbenben I'd look at it a while back too) and there's definitely some extra stuff being sent right at the end of the data that'll be confusing some of the LEDs. Hopefully a little more digging around and I'll have a fix for it though.

Nope - I2c.find isn't a built-in method. The reference lists what's available here: http://www.espruino.com/Reference#I2C

If you have other questions related to ESP8266 please can you post them on the ESP8266 forum though? This post originally doesn't have much to do with your question at all, apart from having I2C in the title.

I've found it's a bit touch and go with the voltages - it depends on the type of pixel. Generally you can connect neopixels straight to a normal USB Espruino board because there's a diode from USB volts. That drops the voltage by 0.7v or so to 4.3v, which means they're fine off of 3.3v data.

However sometimes if you plug them into a USB wall supply, they often give out 5.5v which means the pixels get 4.8v - which is then too much for reliable data :)

Thanks for the screenshots... Looks like you've done the right stuff, but that inbuilt adaptor isn't supported by the native IDE build. If you've added it to bluetooth-hci-socket/lib/usb.js and it's still not working then you may be out of luck unless you get an external BLE dongle.

One other way to try (in case somehow it's still loading the old JS file from the archive) is to set the two environment variables:

BLUETOOTH_HCI_SOCKET_USB_VID=0x0a5c
BLUETOOTH_HCI_SOCKET_USB_PID=0x21e6

However it worries me that your USB adaptor still isn't supported by the latest upstream bluetooth-hci-socket - which may be because it just doesn't work with it: https://github.com/sandeepmistry/node-bl­uetooth-hci-socket/blob/master/lib/usb.j­s#L68

If you want to work around it without spending £5-10 on an external BLE dongle there's still the option of using your phone as a BLE adaptor: https://www.youtube.com/watch?v=H8L8ft83­0hI

Unfortunately I'm yet to update the documentation - it's got a lot easier recently :)

As of 1v92, you can use require("neopixel").write: http://www.espruino.com/Reference#l_neop­ixel_write

The Puck's current SPI.send4bit implementation isn't fast enough to send all the data without gaps (especially when the Bluetooth stack kicks in), so it was easier to use a specific function to handle it. I took the opportunity to make something that works the same across all devices.

Only gotcha is there's still some annoying bug where the first LED seems to be set to random colours. Other than that it all works great though.

In terms of voltages, an opto is probably great. You can connect it direct if you're running Neopixels off of 3.5-4v (so directly off a LiPo), but yeah - if you try and run them off 5v you'll hit problems, and the Puck's IO isn't 5v tolerant so you can't do the resistor + pulldown trick that you could on STM32 boards

Ok, fixed - looks like there's a bug in the chip's NFC hardware that needs a workaround. Rather than check for the specific chip model, Nordic checked whether you were using their development board when compiling.

If you were using their development board, they fixed it. The second you compiled something for a real device, they disabled it :( I've re-added the definition for the workaround for Puck.js, so it should now work fine - it may in fact fix a lot of this sort of issue.

Wow, yes. Just tested. In my case literally just using NFC on a completely clean device running 1v92 bumped the power consumption up to over 1mA. That's really bad news.

I had a quick check with setSleepIndicator and it doesn't seem to be increasing the amount of wakeups/second - so it's presumably some bit of NFC hardware being left on.

I've filed an issue for it on GitHub - not sure if I'll get to look into it today, but I'll see if using the NFC code from the newer SDK fixes it. If not, I guess it's time to see if I can reproduce it with the nRF52DK and see if Nordic can find a solution.

Thanks, no problem! Yes, unfortunately the devices ship with firmware that's quite old - even if I were to manually upgrade every device here before shipping it out, my distributors wouldn't be able to.

@Gordon what does BLE Connected, queueing BLE restart for later actually entail?

The bluetooth stack on Puck.js's chip was never designed for devices that modified their services on the fly, and as a result it can only ever add services to the end of the list of services.

So when you enable bluetooth HID, which requires a bunch of changes, Puck.js has to actually restart the bluetooth stack to wipe out all existing services so it can then start again and re-add them in the right order. If it did that when you were connected then the connection would drop - hence the message.

All you need to do is disconnect BLE from the IDE and the BLE stack will restart, then when you reconnect everything will be sorted.

So usually you'd do:

• Connect with the IDE
  
• Upload HID code (possibly save it if you want to so it'll work again at power-on)
  
• Disconnect
  
• Now Pair/connect using your operating system's Bluetooth menu
  
  

And you're sorted. I think that you can then also connect with the IDE while it's a bluetooth HID device, but I'm not sure if that works on all platforms yet.

The fact that it resets the Espruino board makes me think that something might be wrong with the wiring? Bad connections would usually make things like I2C functions fail with an error, but not make the board reboot.

Are there pins that can tighten to fit snug in the holes?

There are, but honestly they're pretty evil. You usually have to clamp them in with a vice, and when I looked at it (I originally wanted to ship Espruino boards like it) I felt it was much more likely folks would damage boards doing that than if they just soldered.

If you're going for it then buy a soldering iron (one with a reasonably thin tip), solder, and then some protoboard and whatever cheap pinned components you can find - you can then do a bit of practice first with stuff you won't care about. After the first few you'll be fine with it :)

Also I'd get a 'solder sucker' - it's dead easy to put too much solder on when you're starting off, and it'll be a pain trying to get it off. For a few dollars a solder sucker will easily take off extra solder if it all blobs together.

I have no idea what's up, but it'd appear not to be a Web IDE problem - can you ask on the ESP8266 section of the forum and see if there are any ideas there?

And yes - the 'compile' option only works for ARM-based micros, and I don't think it works on nRF51(perhaps not even nRF52) because of the way functions are linked in at the moment.

To be honest it uses significantly more memory compiling. I did some tests, and minified JS code is actually significantly more efficient than almost everything else, including Mozilla's bytecode.

As an aside, one interesting option is actually to ban the use of character codes 128 and up in normal (non-string) code (which I don't think is even an issue) and to then use those in a similar way to your JS packer to pre-tokenise reserved words. It could allow Espruino to store code in an amazingly compact way, while increasing execution speed quite a lot.

Of course it'd then blow away comments, formatting, etc - but on some platforms I guess that wouldn't be a problem.

Interesting - it might be the lack of with that causes problems when decompressing? Also it'll generate a huge sparse array before rejoining, which would use up all the available memory for much over 1kb. By rewriting the decompressor you could almost certainly still use it though.

Great - thanks for letting us know!

There's no better option than the BLE UART if you want to do it wirelessly. You could implement your own characteristics, but it'd be just as slow - if not more so.

The issues with writing while Puck.js is transmitting could just be a buffer overflow - if it's waiting to send data while also receiving stuff.

When you're writing code I'd definitely try doing what the IDE does though, which is to send character code 16 at the start of line for each new declaration (which disables echo for that line). You can get the espruino NPM package (the CLI tools) to output the exact characters it would have sent to a file, which might help you there.

Otherwise you can just send "echo(0)\n" before everything to totally turn echo off for all commands.

I'm afraid I'm not up to speed on the Android BLE APIs so I don't know if there's a faster way to do BLE - but I guess there must be if Web Bluetooth can do it. It might be worth looking at the sourcecode for the Nordic UART app and seeing if they do something different?

Great, thanks! I've just pulled that in - hopefully that'll fix some problems.

I didn't check, but I wonder if Nordic have made some improvements in the newer SDK that could be ported back.

Yes, _basic could work. Shame that it still had trouble even with a cut-down driver.

It is frustrating about the 16k/32k variant - instead of 3.6k for JS code you'd have had nearer 20k!
I guess Nordic were giving the chips away for free, but if they'd been purchased it wouldn't have made much difference to the BOM at all.

That's a shame - yes, I guess adding modules can suck up a lot of memory. Doing the 'save on send' and 'modules as functions' tricks in the IDE can free you up a lot of RAM though.

DS18B20 is interesting - the module itself could be insanely simple (just a few lines) but it's been added to over the years with features most people won't use. I guess it might make sense to add a DS18B20_minimal module? Same for a few others... any thoughts about naming?

The wires look fine to me - if you have a soldering iron, soldering the pins themselves into the board would probably be best. While it can work just pushing them in, you can get dodgy connections which can make it very unreliable.

With the same error message of 'not bonded'? Does it get very far with the upload or does it fail immediately?

I can't remember seeing the message before - do you have another phone or tablet you could try the upload with? and are you sure it's espruino_1v92_puckjs.zip you're using and not espruino_1v92.zip?

Wow, that's great. And it makes sense that the third-party app could be triggering problems.

Have you tried adding some checks and seeing if that fixes it?

Hi, Thanks!

I reckon you can use NRF.sleep() and NRF.wake() to stop advertisements. However that will make the device unconnectable when it's not advertising.

Also you really want to let it send quite a few advertisements (so leave make 2 seconds between wake and sleep). It's radio so there's absolutely no guarantee that a single message will get through to the Pi.

I wouldn't be too worried about the battery usage of advertising though - it's not that huge. You can always reduce the advertising interval to once a second or so, which will really reduce the battery usage without you having to do anything painful with wake and sleep.

Yes, that sounds like a good plan - just as easy to use, and at least it's not costing you anything :) I guess you could stick something on HttpToHttps.com asking if anyone uses it, so you see what the level of interest is?

Very cool that it's all being served off a local machine though - I never trusted my connection enough to do anything like that :)