-
-
I'm reading chunks of data using Waveform, which returns UInt values.
There are accompanying single measurements via analogRead. Unfortunately analogRead values need to be converted from Float to Integer to be comparable with the Waveform data. Is there a way to make analogRead return integers (may be a flag)?
Any other reliable, though probably hacky way to get ADC data fast and as int? -
I've started to do 2 things:
1) use Waveforms to read the data, this seems to be exactly what I fancied
2) use a special handler to read and transfer data through TCP instead of attaching the console.Thanks for all the suggestions and the valuable feedback. Espruino Forum is an invaluable source of inspiration and help!
-
In a TCP connection with console piping, LoopbackB.setconsole() throws an error:
Uncaught InternalError: setDeviceClockCmd: Unknown Device 720 at line 1 col 101
If the error is caught (the lines are commented out in the code below) LoopbackB.setconsole() does what it's expected to do.
The code is:net.createServer(function(conn) { conn.on('close', USB.setConsole); conn.pipe(LoopbackA); LoopbackA.pipe(conn); // try { LoopbackB.setConsole(); // setDeviceClockCmd: Unknown Device 720 // } catch(e) {}; }).listen(23);
The device is Espruino WiFI on 1.99.
-
The TCP connection is created and closed for each single request.
The main code is here, modules ar attached:
TSw=require("TSwitch"); tsw1=TSw.create(B9, {duration: 180000}); TSns=require("TSensor"); rdr1=TSns.create(A4, {iv: 400, iv2: 50, offset: 76, thr: 9, both: true}); rdr1.start(tsw1.getcbsnsr()); drk1=TSns.create(A0, {iv: 10000, thr: 72}); drk1.start(tsw1.getcbenbl());
B9 switches the MOSFET (digitalWrite),
A4 is the the presence sensor (analogRead of a radar module, cf. https://shop.weidmann-elektronik.de/index.php?page=product&info=8),
A0 is the 'darkness sensor' with a photo resistor.
TSensor is meant to be a universal threashold sensor, all the parameters basically control how the raw signal is prepared such that the threshold makes sense. Both sensors call into the tsw1 switch instance passing 1 or 0.
The system is self contained. The switch tsw1 additionally reports actions via HTTP, which seems to be of no relevance, I've checked it.I'll look deeper into setWatch(...irq: true). It might well be overkill, but it would be fun to get it working!
After all, in the end, it might be not too hard, and it would be a nice 'backdoor' in case it's really needed (e.g. if I wanted to check the presence sensor every 50 ms).
@allObjects: Fully agree. Not breaking the really great Espruino concept while beeing able to unleash the close to infinite speed of the great processor - that's the goal. It feels wrong to know that my little light switch would run perfectly if implemented in C. And my VIP customer - my wife - needs to be content ;) -
Not sure about delays over USB anymore.
The 'production system' is out of reach, I can't watch the busy indicator.
Espruino WiFi's IO and TX BUFFERMASKS are both 127, which is enough for the response.From my current understanding of what happens on a server call of getValue(), all these things happen at once (before anything else like setInterval's execution can happen):
parse the command string, execute the command, send the response
Is this correct?
If I created a mini-repl within the TCP connection to do the 'swch.getValue()' call and return the result upon receipt of a magic word, without the LoopBack pipes, the duration of the disturbation might be significantly shorter.I'm wondering if there is a way to have a function interrupt currently running console code without changing the Espruino src code. I know about the implications of interrupts, still seeing this as a good option if it's possible at all.
-
Thanks for the responses. I'll definitely look into the output buffer limitations. How can I find out about the size?
The device is an Espruino WiFi on 1.99.
Here is the part of the code that matters:// measures and counts, counter reset ff below threshold meas() { const v = Math.round(analogRead(this.pin) * this.rng - this.offs) if (this.vals.length === this.nmax) this.vals.shift() this.vals.push(v) if (this.both === true) v = Math.abs(v) // zero based, both too low and too high considered if (v < this.thr) { return this.cnt = 0 } else { if (++this.cnt > this.tcnt) this.cnt = this.tcnt return this.cnt } } // call meas, evaluate and call back cfrm() { const c = this.meas() if (c === 0) return this.cb(this.val = 0) if (c === this.tcnt) return this.cb(this.val = 1) if (this.tcfm === 0) { // this.cb(this.val = 0) // not yet confirmed, do nothing (?) } else { setTimeout(this.meas.bind(this), this.tcfm) } } start(cb) { if (cb === undefined) cb = this.cb || print this.cb = cb this.iv = setInterval(this.cfrm.bind(this), this.tupd) this.cfrm() }
There are 2 sensor instances running, one with an interval (this.tupd) of 400 ms, the other one 2 s.
'this.cb' is a callback to little instance that keeps track of the 0/1 values sent and eventually switches a light through a MOSFET, along with a TPC notification to the controlling server:// called by switching (presence) sensor cbsnsr(v) { this.snsr = v // just for information if (this.ovrd === 1 || this.toff !== undefined) return // act if all conditions are met if (v === 1 && this.enbl === 1) this.act() } act() { this.tend = Date.now() + this.drtn // just for information if (this.toon) clearTimeout(this.toon) // to re-set timeout while already running const self = this this.toon = setTimeout(function() { self.toon = undefined // if (self.toff) clearTimeout(self.toff) // self.toff = setTimeout(function() {self.toff = undefined}, self.dblk) self.actr(0) }, this.drtn) if (this.val !== 1) this.actr(1) // switch on } actr(v) { digitalWrite(this.pin, this.val = v) this.report('') // report enbl, snsr, val in an object } report(d) { if (this.rurl === undefined) return var req = http.get(this.rurl + JSON.stringify(this.getValue(d))) // req.on('error', function(){}) return req // for debug } getValue(d) { if (d === undefined) return this.val return { ovrd: this.ovrd, trest: this.trest(), enbl: this.enbl, snsr: this.snsr, value: this.val } }
The getValue() method is the one that gets called every 5 minutes via USB or TCP. The call is
\necho(0)\nprint({r: JSON.stringify(swch.getValue()) }, '@@\n')\n
The TCP console is attached like this:
wifi.connect('XXX',{password:'YYY'}, function(err) { // console.log(err); if (err) return; wifi.turbo(true, function(err) { net.createServer(function(conn) { global.conn = conn; conn.on('close', function() {USB.setConsole()}); conn.pipe(LoopbackA); LoopbackA.pipe(conn); try { LoopbackB.setConsole(); // setDeviceClockCmd: Unknown Device 720 } catch(e) {}; }).listen(23); }); });
-
I've got a function wrapped in a setInterval that does analogRead every 400 ms (as a presence detector). Sometimes it seams to stall for a couple of 100 ms. Because the time periods involved are very short it is hard to get to the root cause by experimenting.
Now I'm wondering if setInterval execution is blocked while
a) console data is received (programmatically, ~200 bytes at once)
b) the received string is evaluated
c) the result string (~200 bytes) is printed out
Where exactly can I read up about the timing of code execution? -
-
It doesn't make any difference for me, but the device is only 5 m away from the access point.
This command is definitely useful, but there seems to be a little more investigation desirable.
The inquiry (AT+RFPOWER?) returns with an error. The ESP docs say something about disabling a pin (which I didn't know how to do). Also there is an acompanying command AT+RFVDD which seems to do the same thing or is even more powerful .While RFPOWER takes numbers as argument, there seems to be a direct conversion to dbm, which might be more desirable? If RFVDD works, it seems to be a voltage.
In summary: quite a few people might like a new setRfPower(x), a complementary
getRfPower() would be even better. -
-
-
-
Good idea, and here are the results:
Puck 2018-07-25T16:35:15.258Z { temp: 25, bat: 2.998 } ... Puck 2018-07-25T17:25:02.873Z { temp: -19.75, bat: 2.668 } Puck 2018-07-25T17:26:02.885Z { temp: -19.75, bat: 2.674 } Puck 2018-07-25T17:27:02.946Z { temp: -20, bat: 2.663 } Puck 2018-07-25T17:28:02.996Z { temp: -20, bat: 2.665 } Puck 2018-07-25T17:29:03.024Z { temp: -20, bat: 2.664 }
First conclusions, that are actually observations:
- Puck.js works down to -20 °C
- a fresh CR2032 (noname, cheap purchase) also works down to this temperature
Indeed, my problem from last winter seems to be related to low cell voltage instead of low temperature!
First of all, I changed the code from sending GATT service data to sending the data as ManufacurerData during advertising. Hoping that this change makes the battery last much longer.Another question (mainly for myself but input is welcome) is whether there are cells out with a slighly higher voltage (like 3.3 V - and well above 2.6 V at -20°C) that can be used through Puck's external connector, getting me close to 1+ year endurance without maintenance.
- Puck.js works down to -20 °C
-
-
I've got a Puck with an Automation Serice, sending E.temperature and some other builtin peripherals' data. It sits well protected on my balkony, acting as small outdoor weather station. It work well down to temperatures of about -5 °C.
Nordic's datasheet states that the chip should work even at -25 .. -40 °C. Now I'm wondering what actually limits the working temperature to -5 °C. Would the MDBT42Q board also have this limitation?
I'm fancying a weather station with MDBT42Q and a BME280 sensor, maybe a little display, and a battery lasting +1 year, replacing my current LCD thermomter (without BLE :) -
-
I've got an Espruino WiFi with a telnet connection but no USB (unless I do things I'd rather avoid).
It's got onInit set with code I want to get rid of and rather replace by an E.setBootCode string.
The goal is to clean up over wifi and then do an E.reboot.
I'm not aware of a way to get rid of onInit and all the other objects created at runtime that would put the Espruino in a kind of clean state that would be worth a save().
Can this be achieved at all? -
-
The Wifi module builtin since 1.96 (many thanks, Gordon) connects as expected.
However, it seems to do an extra callback when it connects.
The code below is supposed to pulse the green LED on success and the red one on wifi timeout.
On connect both LEDs go on, at the same time.var addr=null; function cbwi(err) { if (err) { digitalPulse(LED1, 1, 1000); cowi(); } else { digitalPulse(LED2, 1, 1000); wifi.getIP(function(a) {addr=a;}); net.createServer((conn) => { conn.on('close', USB.setConsole); conn.pipe(LoopbackA); LoopbackA.pipe(conn); LoopbackB.setConsole(); }).listen(23); } } function cowi() { wifi.connect('HXNET1',{password:'xxx'}, function(err) {cbwi(err)}); } cowi();
While the connection definitely succeeds (ping replies are sent), the value of the variable addr is 'Timeout'. And the telnet server doesn't get startet.
What's going on here? -
-
In case it doesn't work it writes 'WiFi connect failed: FAIL'.
Actually, the line
conn.on('close',function() {USB.setConsole();})
made the Wifi connect work reliably (!).
The lineUSB.setConsole()
at the end causes Wifi connect to fail.Regarding the LEDs, I'd expect the green one to go on once the Wifi connection is established. It doesn't, even when I can telnet to Espruino. Doing LED2.set() from the console works.
-
Requiring works. However, connect() succeeds only 1 out of 3 times (power off and on again). Here is my code:
// clean up before: E.setBootCode(); function onInit() { setTimeout(function() { require('Wifi').connect('SSID',{password:'mypassword'}, function(err) { console.log(err); if (err) return; require('net').createServer((conn) => { conn.pipe(LoopbackA); LoopbackA.pipe(conn); LoopbackB.setConsole(); }).listen(23); }); },3000); } // wait a few seconds, then: save();
With the 1v95 build connect() always succeeds.
-
The InternalError is gone, but LoopbackB.setconsole() itself doesn't work. There is no output.