-
-
Is your battery still alive? Check with a multimeter whether it still outputs 3-4V.
Is the polarity correct? The charger and the battery may have different pinout...It's possible, that your battery is dead. Btw, most likely you can get the battery locally (altho don't know where you live), or from a proper electronics parts supplier (digikey, farnell, mouser. Or one of the hobby electronics stores).
-
Thanks for the explanation, so it's expected and by design?
But that means, that a couple of libraries that support optional pins, just "accidentally" work? IIRC in most cases the check is usually
if(options.whateverPin){...}
For example in the CCS811, it'sif (ccs.options.int) { ...
Thinking back, I may have had an issue with A0 on the Pixl, but just moved to another pin without thinking too much. Or maybe not :)
Consistency with JS I think usually would be beneficial, for example setting the length of an array in a browser empties that array. But creates a
length
property with value of0
in Espruino :)Don't know how much work would be to add a special handling from
Pin
tobool
. -
I think the subject says all.
Here is the output I got testing couple of pins:>reset(1) Erasing saved code. Done! =undefined ____ _ | __|___ ___ ___ _ _|_|___ ___ | __|_ -| . | _| | | | | . | |____|___| _|_| |___|_|_|_|___| |_| espruino.com 2v02 (c) 2018 G.Williams >!!A0 =true >!!A1 =true >!!D0 =false >!!D1 =true // and here comes the fun part: >!! (D0.getMode) =true
-
-
Hi!
Recently ran into an issue with
clearWatch
in library code. (This cost me couple of hours, so possibly over exaggerating this...)clearWatch()
andclearWatch(undefined)
clears all pin-watches. You can accidentally call it with undefined, if you don't check whether you have an actual watch Id, for example line 31-32 in DHT22.js.Because of the "reliability" of the DHT11 & 22 sensors and the 10 default retries in the libraries, these are dangerous for almost 6 seconds (550 ms timeout * 10). If you don't read the docs, you can run into a race condition where you start a conversion before all possible timeouts of the previous
read
had finished.
If you usesetWatch
elsewhere, thatclearWatch(undefined)
just destroys you program without crash, and leads to some head scratching... Or leads to a memory leak, if you call.read()
too soon. It did leak slowly at 10 retries and 3 second read interval. At the end the setWatch 'count' was up to 50. But that's a different matter.Also
clearTimeout
andclearInterval
is the same.First, a suggestion:
What would be the preferred way to handleclear***()
? Seen several ways in devices / modules code: I think it shouldn't be without checks and should set the 'watch' property to falsey, if there is one.For example there is this nice, but nontrivial looking example from the TouchRD code (
_
is "this", and_.w
is the watch Id):_.w = _.w && clearWatch(_.w);
Or the more obvious
if (this.watch) { clearWatch(this.watch); this.watch = undefined; }
If there is a consensus, I'm willing to change the libraries, around dozen uses in JS files.
Does anyone think it would worth making
clearWatch(undefined)
invalid, and changing the clear-all call explicit (for example pass in-1
)? I know, it's a breaking change. Possibly write a warn to console?
Or better just improve the libraries & docs? -
-
-
-
One more thing:
Setting the watches again, numbering starts from 1 again. And both the button and CCS811 works just fine. For a minute or two. Kind of random.And all watches disappear at the same time. Stops responding to button presses, and no more data thru CCS811 interrupts.
E.getErrorFlags
returns empty array :/ -
Never mind, there is a bug in the DHT22 library code. PR on it's way :)
Hi, this will be strange, but feels like Espruino just forgot about pin-change watches set up with
setWatch
after some time.The setup:
Pixl.js + CCS811 air quality sensor + DHT22.- Reading data from the DHT22 every two seconds (setInterval)
- The CCS811 pulls it's interrupt pin when it has new data. ~every second (setWatch)
- And refresh the screen every second (setInterval)
But after a couple of minutes, no data coming from the CCS811. No crash, no restart, plenty of memory. DHT22 still refreshes (so the interval for reading the DHT and refreshing the screen is working) and can still query the CCS811, but the Pixl.JS does not respond to pin changes.
Also set up watches on BNT 1 - 3, and that too stopped working. BTN 1 and 2 not doing anything useful atm, but the BTN3 setWatch looks like this:
setWatch(function(e) { LED1.toggle(); }, BTN3, { repeat: true, edge: 'rising' });
The CCS811 js module stores it's watch id, and in my case that was "4". Makes sense, set up 3 buttons, and the CCS811 was the 4th.
But callingclearWatch(1)
(or 2, 3, 4) throws an error:Uncaught Error: Unknown Watch
. All pin watches gone!I do not use
clearWatch
anywhere in my code.Tested with 2v02 and 2v01, same behavior.
Any idea what might cause this?Edit: already tried just setWatch on BTN3 + pressing it like an idiot, but that worked without issues.
- Reading data from the DHT22 every two seconds (setInterval)
-
-
The random characters at the beginning is "normal", I think those are boot messages or something like that.
IIRC connecting with putty did not work for me either, but the Web Ide should be able to connect to it. Is your board working properly, did you try with something else? Does it have enough power, maybe try adding a bulk capacitor? -
Ooops, link to the photos is fixed now.
Mine is a different device that has LCD & Bluetooth. There is also a whole series of zigbee Xiaomi sensors, IIRC one of those has an NXP chip. So check before buying, if anyone is interested!Part number is lLYWSDCGQ/01ZM Aliexpress link or search for "Xiaomi Mijia bluetooth wireless temperature and humidity sensor". Funny thing is, it's available from the Hungarian Xiaomi shop for less than banggood's price. Aliexpress was cheaper, so check prices :)
Yeah, first couple of searches for nRF51802 resulted in nothing / older questions about this non-existent chip. Still there is no trivial direct link on Nordic's site, a search hit lead me there.
Yes yes, saw that, that's the fallback plan :)
-
Ok, that is a clickbait-y title, no real progress so far, but maybe there will be some :)
I must admit, this was kind of an impulse buy after finding out that Xiaomi's Bluetooth temperature & humidity sensor probably has an nRF chip, and Sensiron sensor.
Edit: Part no lLYWSDCGQ/01ZM, got from AliexpressMy original plan was to add a CCS811 (air quality sensor), and probably drop in an ISM radio because the walls in my house are thick (40-45cm), and 2.4Ghz just doesn't penetrate that thick walls well. At the time couldn't find more info about it, so just ordered.
Or just use 'em in the rooms close to the Pi (to collect data) if all fails...Got them today. First impression & teardown with unsorted photos :
The good:
- Ordered 3 of them, the measured values are <0.5°C and <1% RH apart. Those things react fast to temp or humidity changes.
- Nicely constructed, You can take it apart and reassemble no problems.
- Looks like they really have Sensiron SHT30, manufactured in 2018. The sensor sits in a small opening, connected with a flex pcb to the main PCB.
- It has test points! I think I have found power pins, SWD pins, and SDA, SCL to the SHT30.
- The LCD driver has is manufactured by Rohm, and has a datasheet
The bad:
- Turns out, some more googling could have revealed the exact parts before purchasing...
The ugly:
It does have an nRF chip: nRF51802
The nRF51802 is a low cost variant of the nRF51822, it has the same functionality, but has minor performance degradation in terms of:
- 2 dB less RX sensitivity
- Slightly higher RX and TX peak currents
That's like the MCU in the micro:bit with worse RF performance :/
Couldn't figure out the type of the DC-DC converter so far, so no idea how much current can it provide. Might not be enough for an ISM radio.
And of course I need some extra pins too...
So right now not so sure about Espruino. Maybe if I can strip out bluetooth from the nRF51 build to free up some memory? Or just try to do it in C? Or reassemble the unit, and place 'em in locations with good bluetooth reception? :)
- Ordered 3 of them, the measured values are <0.5°C and <1% RH apart. Those things react fast to temp or humidity changes.
-
-
Hi!
Looks like the
serial.setup()
on these boards requires the RX and the TX pin. On STM32 I could get away with only specifying the RX pin. For example on MDBT42Q:>Serial1.setup(9600, {rx:D8}) ERROR: Invalid RX or TX pins
Is this some Nordic-thing, that can't be changed easily? I have enough pins, so no problem, just curious...
Flashed the latest cutting-edge build to the MDBT, but sw serial is much worse than the Wifi. (PMS7003 and it's 32 byte packets) I guess bluetooth connection doesn't help :(
-
-
Hi @Gordon Looks like with the latest build, software serial is significantly worse than it was for the Espruino Wifi (haven't tested other boards).
Did some testing before updating, the software serial did lose / CRC error-ed about 15-20% of the 32 byte packets sent by the PMS sensor. But was working.
With the latest build, my previous PMS driver doesn't work at all with soft-serial. Still works with HW serial tho.Here is the simplest test code that shows the issue:
Serial1.setup(9600, {rx: B7, tx: B6}); Serial1.on('data', function(d){ print("H", d); }); s3 = new Serial(); s3.setup(9600, {rx: A5}); s3.on('data', function(d){ print("s", d); }); // send some data setInterval(function() { Serial1.println('abcd'); }, 500)
I use A5 as the software serial RX, I think there is nothing special about this pin. Right?
Connect B6 (hw tx) to either B7 or A5, or to both at the same time. I had to ground the A5 pin when not in use, as it was picking up some noise.
2v01 official build:
Everything (tx -> hw rx; tx -> sw rx; tx -> hw and sw rx) works if the "packet" is short, like'abcd'
.
If I send'PM1234567890ABCDEFGHIJKLMNOPQRST'
, hw serial is perfect. Software serial fails most of the time, I guess because the sample that prints each character to the USB console.Latest (33941e) build:
HW serial works as expected
SW serial is not reliable even for short messages :/ Some bytes are ok, but usually receives wrong character, occasionally receives more characters than sent. Even for short messages.Back to 2v01 official: SW serial back to "normal".
-
Slightly on topic: I tried to use an Espruino Wifi with two serial devices. Plantower PMS sensor continuously sending data at 9600bps.
One on hw serial, one on software serial, and the software serial was kind-of-random. Sometimes got data on the hw serial between receive from the software serial. I will try with the new build! -
If it works when connected to USB, but behaves differently when running without USB, maybe take a look at this section in Troubleshooting. And the next maybe.
Or it's a bug :) -
-
Just a note: all the "pixels" I got recently work flawlessly with 3.3v controllers. No diode to drop the supply voltage, no nothing
Tried running these with MDBT42Q module and ESPs. Powered the LEDs from USB -> 4.9V at the output of the LEDs. And a full strip with a proper 5V power supply that outputs ~5.0-5.1V, all worked without any problems.And all of them are GRB or GRBW.
Maybe someone on the far east created a "compatible" chip that works reliably with 3.3v? -
I think I got this issue on an ESP32 with 2v01 when trying to use MQTT / tinyMQTT.
reset(1)
, reset button, power cycling does not solve the problem. The board can connect to wifi, ping works.
What really puzzles me is that I have an ESP32 with tinyMQTT that works.With MQTT the error message is
ERROR: Connect failed (err 104)
With tinyMQTT the error message is:ERROR: Connect failed (err 104) Uncaught InternalError: Unable to create socket
at this call:
a.cl=require("net").connect({host:a.svr,port:a.prt},b)
Edit: A simple http get does work.
Edit2: A simple http server works:function onPageRequest(req, res) { print('page req', req); res.writeHead(200); res.end("Ok."); } require("http").createServer(onPageRequest).listen(80);
The second pin says "5v", but if you use it with a 3.3v micro, like the MDBT42, you should connect the "5V" pin to 3.3V!
I have something like yours, in center position it is about half of the input voltage (but not exactly, and not the same on X any Y axis...). As you move the joystick, the voltage should go between 0 and 3.3V. Mine goes to 0 and full voltage waaay before reaching the actual endpoints...