-
I just posted a workaround for setting a static IP address here:
https://github.com/espruino/EspruinoDocs/issues/363Assuming that works for you it could easily be rolled into the EspruinoWiFi library.
I'm not sure why you're not getting a response from
.get('http://192.168.0.5:3000'
though - did it just happen the once, or does it happen multiple times? Do you see the request appearing on your server at all? -
Q1: Was this distinction VBUS vs VUSB made for schematic software reasons and not a typo?
There's no specific reason for that - it's because the design started off as the Pico design and had power supply components removed.
Q2: What/Where is the connector showing VUSB/DM/DP or is this the input to the WiFi module?
They're test points on the rear of the board
Q3: Under the assumption the micro USB connector is feeding the power, is it true that VBUS [ J2-2 ] is available as an output and that it is electrically connected to the input (after Fuse F1 perhaps) of the regulator as 5v (the source a USB port supplies), and therefore also supplying 3.3v as VDD [ J2-3 ] as an output?
VUSB is connected directly to the USB power supply, with no fuse. This was probably a bit of a mistake, but was done because people had complained in the past that there was no way to get the full power output from a USB wall supply/phone charger when using something like the Pico.
The regulator supplies 3.3v, but there won't be any problem supplying 3.3v from elsewhere - unless for example you're using a battery that is less than 3.3v (in which case it will be charged up to 3.3v when USB is connected).
Q4: Under the assumption that supplemental power from a 3.3v battery is supplied, and that no micro USB connector is attached, that is could be applied as an input VDD at [ J2-3 ] bypassing the onboard regulator?
yes. as I'd said in the last post - supplying regulated 3.3v to the 3.3v pin would be the most sensible way to power the device.
Note: This would mean there is no fuse protection and that input voltage would not be detectable at PA9/P30
Yes. If no input volatge is detected, the USB hardware won't be powered up, so the current draw will be less.
Q5: Similarly as above, upto 5v could be supplied by a regulated supply to VBUS [ J2-2 ], thus using the onboard voltage regulator, producing the 3.3v to the rest of the circuitry, and at VDD [ J2-3 ] as an output?
Yes, you could do this - again as I said in my last post. However there are some issues:
- The USB peripheral on the chip will stay powered, so will draw more power in sleep mode
- If you do that you cannot use the USB, since plugging it in will start to supply power into whatever power source you used (you'd need to connect the power source with a diode, and ensure it's always less than 5v)
- The USB peripheral on the chip will stay powered, so will draw more power in sleep mode
-
It worries me that none of the icons are blue for you.
I'm pretty sure that means that your computer isn't actually seeing any of those devices? If you run
nRF Connect
on your phone, do you actually see the device advertising during that time?Are you sure that Puck.js is not still connected to your Mac in some way, or to some other device?
-
Hi - I'm afraid I can't see that image. It looks like you need to be signed in to dropbox to see it. You should just be able to upload images straight to the forum though.
I don't have my windows 10 PC to hand to take a picture, but I found the image below on the net. The Keyboard icon should be showing where the blue icons are in the picture.
It really should work fine - I've had plenty of people using this without trouble.
And yes, you can communicate directly with your own app using the standard windows 10 Bluetooth APIs. There's some example code for doing that here: https://github.com/espruino/winnus/blob/master/cpp/winnus.cpp
The code above communicates with Puck.js's Bluetooth UART interface, which is enabled by default. If you wanted to make your own services and characteristics and modify the UUIDs in that file then you could do that too though.
-
The battery I pictured above has that same (JST PHR2) connector, and says 3.6v. Would that one work then?
Yes, it'd be fine.
If the battery is fully charged (and is above 3.6v), could that break (burn) the espruino? Should I get a voltmeter to check before wiring it up?
Only if you are going to wire it up as @allObjects had suggested - if you do as in my post then you don't need to worry about the voltages (as long as the battery isn't much over 5v!).
If I get that battery, would the white JST PHR2 connector fit onto the GND/VUSB pins directly?
Unfortunately not - the pin spacing is different. You might be able to bend pins and force it but I'd suggest a separate connector if possible (you can always buy the socket quite cheaply and then solder that direct to the pins).
Battery Black -> Espruino GND -> LM3671 GND
Would I need to fork the black wire to two wires (like a snake tongue) and connect to both pins, one on each board?Yes - it doesn't matter how you do it though - you could use one long bit of wire and strip the insulation in the middle if you wanted.
LM3671 3V -> Espruino 3.3v
Just to confirm, this is to the 3.3v pin (which the schematic calls "3.3v output"), NOT the VUSB pin?Yes, that's the one!
Just to add though - the USB power pack idea is easy, cheap, and tidy, and it'll easily run the Espruino WiFi for far more than a day, which would probably be enough for you?
-
-
-
Wow, ok - that's the first time I've come across that. Had you been on one of the 'cutting edge' firmwares before, like
1v91.xyz
?Please can you try downgrading to 1v91 and then running the code linked here? http://forum.espruino.com/conversations/303637/#13590078
That should fix it for you - I'd be pretty sure it's related to the new 'bonding' feature. I imagine that somehow the flash memory that's used for bonding information has got corrupted. I have no idea how it happened though - was there anything in particular you remember doing that might have kicked it off?
-
-
@allObjects I'm not sure you're considering the ESP8266 that's also on the Espruino WiFi? That accepts a maximum of 3.6v, and as you noted when fully charged the 3.6v NiMh battery could be a little over 3.6v.
@trusktr you've got 3 main options.
USB power bank
If you're at all worried about wiring up, I'd say just using a USB power bank is by far the best/easiest option.
Wiring direct
ONLY DO THIS IF YOU'RE SURE YOU ARE NOT GOING TO PLUG INTO USB WHEN THE BATTERY IS CONNECTED
Get a LiPo battery - any single cell battery (3.6/3.7v) will do fine, and using http://www.espruino.com/WiFi#pinout as a guide, wire:
- Battery black -> Espruino GND
- Battery red -> Espruino VUSB
Some stuff you could use:
Battery: https://www.adafruit.com/product/328
Battery charger: https://www.adafruit.com/product/1304
Socket for battery to plug into: https://www.adafruit.com/product/1862Pretty much any LiPo battery would work (I tend to use old mobile phone batteries), but you'll find it way easier to charge if you have one with the 'JST PHR2' connector that everyone uses on it.
Nicest solution - separate power supply
Use a special 3.3v power supply like this one: https://www.adafruit.com/product/2745
The supply is designed to produce a steady 3.3v from a LiPo battery regardless of what the battery voltage is. It'll get the most life out of the battery and will allow you to plug USB in as well if you want to.
Using http://www.espruino.com/WiFi#pinout as a guide, you'd need to connect:
- Battery Black -> Espruino GND -> LM3671 GND
- Battery Red -> LM3671 Vin
- LM3671 3V -> Espruino 3.3v
- LM3671 En (leave unconnected)
Hope that helps - I think that covers the best options you have...
- Battery black -> Espruino GND
-
You could wire an ESP32 to a Pico by serial, and it looks like you can install an AT command firmware on it.
As I understand it, BLE on ESP32 could still be a bit painful though. I don't think it's exposed by an AT command firmware, and the ESP32 Espruino build doesn't support it. You'd basically be programming your own C code on the ESP32 itself, which is probably not where you want to be.
If you really want Bluetooth and WiFi I think the best bet right now is to use a Puck.js wired up to an ESP8266. You get a decent JS BLE API, and the same WiFi library that works on the Pico.
-
-
Thanks - so:
'noble' module couldn't be loaded, no node.js Bluetooth Low Energy Error: No compatible USB Bluetooth 4.0 device found!
Is your issue, and would be related to that USB ID thing - I'm surprised it does that even when specifying the environment variables or tweaking
usb.js
though. Perhaps even after it connects it's unable to get it working.If you wanted to really dive in, I'd suggest trying the current
noble
NPM module with one of their examples: https://www.npmjs.com/package/nobleI doubt the new one would work (because your USB ID isn't mentioned in their list), but having some totally minimal bit of code would be a good place to get started, and you could then contact the maintainers of
noble
and see if they have any ideas. -
I'm sure others will chip in soon, but there seemed to be some kind of issue with the actual USB interface chip on the ESP32 (and other?) boards. Repeated connect/disconnect cycles close together could totally break it - I seem to recall there was a bug filed because there were prob;ems with it after using the esp32 flasher tool.
-
-
@AntiCat when was the last time you updated the firmware? I messed up with 1v92 release of the original Espruino board, but I'm pretty sure I fixed it a few days later and re-uploaded a different 1v92 binary. That should have been over 20 days ago now though... So updating firmware should fix it - and definitely updating to a cutting edge build would work fine.
@Wilberforce yes - it was this fun Python gotcha, but it got fixed a while ago: https://github.com/espruino/Espruino/commit/367507571324dae197aacaf34436bdd23e53aef5
Because it was after the release, I never got around to updating the JSON (not that those elements should get used at all)
-
Yes, that's my mistake. It should have been 0x21e6 as you say.
does your IDE report back if no compatible adaptors are found like node-Bluetooth-hci-socket code does?
Are you aware of any Live CDs that are likely to work with BLE with minimal config?
I was going to say last time but I forgot - can you go into settings and copy/paste the contents of the
console
tab? It might help me see if there's anything obvious.You could give a Ubuntu 17.04 Live CD a try? https://www.ubuntu.com/download/desktop
You could try the command:
sudo hcitool lescan
which will hopefully show bluetooth LE devices if some are available. You could also follow the instructions in the first part of this page to get Web Bluetooth working: http://www.espruino.com/Web+Bluetooth+On+Linux
-
-
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-bluetooth-hci-socket/blob/master/lib/usb.js#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=H8L8ft830hI
Nice - thanks for the post (it's a nice looking little module!).
I'd really have thought that 4k resistors would work - the STM32 shouldn't be that picky. Perhaps it was something wrong with the resistors that came on the board itself?