Most recent activity
-
I've adjusted a promise module for Espruino a while ago, you can have look at it here:
https://github.com/ifavo/espruino-modules/blob/master/org.favo.promise.jsThis is how it works:
https://github.com/ifavo/espruino-modules/blob/master/org.favo.promise-Examples.jsIt's maybe not be perfectly optimized for Espruino for now, but I'm using it in different JS based projects for a while now and its doing what its meant to do :)
-
Yes, I am working on 1v71 – thanks a lot for pointing to the right page! :)
I'm now going to post the collected data to a nodejs processing server which will create some nice stats in the future and serves as the first step in my improved home automation project :))
-
I've seen that in the code, Gordon, but I can not find a reference list of the codes ( looked at https://www.sparkfun.com/datasheets/RF/nRF2401rev1_1.pdf ).
But I also got it stable with a small trick last night.
I've put both sensors power inputs on an analog output which provides 3.3V and I turn them on just 500ms and initialize the connections again before I am going to read from them, then I turn the signal off, when I'm done.Suddenly I am still receiving data (with sometimes a little noise). yay!
Btw. they are currently 4 meters apart with one wall in between, this is the maximum I've managed. This is where I will want to use a pico in the future as a repeating node :-)Thanks a lot for your time and input!
I can't put my finger on it, but I think its a performance issue that comes up after a while which makes the sending part choke on its data. The issues must be within the TSL module or the I2C connection because just reading from it influences the NRF sending and also freezes the terminal eventually.
Thanks again and have a great weekend,
Mario -
Hi Charles,
The ESP8266 drivers are not available as javascript modules. They are meant to be available as internal modules. At the moment they are not compiled into the current firmware. You will need to compile it yourself.
To compile it yourself, there is a nice step by step tutorial for building it on github where you will also find the source code:
https://github.com/espruino/Espruino
To add the ESP8266 drivers you will need to edit the
Makefileand change two lines:Change:
USE_CC3000=1
#USE_ESP8266=1to:
#USE_CC3000=1
USE_ESP8266=1To include the drivers and remove the drivers for CC3000 (another wifi module).
After that is done, you will need to flash your espruino from within the IDE with the advanced option and the new firmware.
I've done this just a few days ago to test a few things, you can use this link to get my binary:
http://sammelsurium.hpm12.de/espruino_1v72_espruino_1r3.bin for flashingI did not get them to work yet, but its also currently stated that development for the ESP is in progress and not yet fully working.
Cheers,
Mario -
I did some long running sending tests with different situations:
- Sending just from within the DHT callback > package loss wasn't too big and was still sending data after 12hrs
- Sending data just from within the TSL callbacks > package loss starts very fast and moved to sending nearly 100% junk after a few hours
- Sending data with an interval, separate from the callbacks > some package loss and was still sending after 12hrs
- Just sending "Hello World" without using doing any sensor readings in an interval > some package loss and still sending after while
- Sending in shorter/longer intervals (every 5seconds vs. every minute) > less package loss on smaller intervals and nearly no "noise" in the received data packages, over time the noise did not increase while using longer intervals resulted in an increased loss of data/more noise in the data packages over time
What I learned from these tests, is that I should send data not within callbacks but rather in an independent scope/interval outside of all the callbacks.
I tried to fine tune the sending process by:
- using different data rates, which didn't change a lot
- using
.setTXPower(3)to maybe send a stronger signal, which didn't change anything as far as I can tell (while setting it to 0 resulted in no data sent anymore) - re-sending the data if
.sendString()fails for some reason, which helps a lot but results in strange results. Failed sendings produce the error messageTX not received 30but still send some part of the data.
What I've seen in the very beginning, became very strange and repeatable when I re-sent data that was not successfully sent. Data packages arrived combined at the target node.
For example:
Sending
Hello Worldsometimes arrived asHelloSªorldHello WorldorWorSªiQ¦llo WorldorWorSªiQ¦llo WorldrS¶‘=Q¦llo World.
Which looks like sent data is combined at the recipients end and the data packages are not correctly differentiated when received. It's maybe the NULL or EOT Byte thats not correctly received sometimes, leading to merged data packages.I am using a slightly modified version of the example code from the website at the recipients side which seems to be very stable:
var dataLine = ""; setInterval(function() { while (nrf.getDataPipe() !== undefined) { var data = nrf.getData(); for (var i in data) { var ch = data[i]; if ((ch===0 || ch===4) && dataLine!=="") { status.lastNrfLine = dataLine; // remove noise in the beginning of the line if ( dataLine.indexOf('{') > 0 ) { dataLine = dataLine.substr(dataLine.indexOf('{')); } // remove noise at the end of the line if ( (dataLine.lastIndexOf('}')+1) != dataLine.length ) { dataLine = dataLine.substr(0, dataLine.lastIndexOf('}') + 1); } if ( dataLine.substr(0,1) == "{" && dataLine.substr(-1) == "}" ) { status.lastNrfPacket = dataLine; try { // replace -1 values because JSON.parse fails on them // https://github.com/espruino/Espruino/issues/456 while ( dataLine.indexOf(":-1") >= 0 ) { dataLine = dataLine.replace(':-1', ':\"-1\"'); } handleNrfInput(JSON.parse(dataLine)); } catch (e) { // ignore failed packets... } } dataLine = ""; } else if (ch!==0 && ch!==4 && ch >= 32) { // 0 = NULL, 4 = EOT, <32 = all command codes dataLine += String.fromCharCode(ch); } } } }, 50);So much from my NRF-adventures, I think, now I can get to a stable solution with an independent interval that sends the data in the global scope instead of sending data within the callback-scopes. I also think that I will find out more about the real problems with further testing and networking more nodes.
Is there anywhere I can lookup the error codes for the sending? What does
TX not received 30mean?Cheers,
Mario - Sending just from within the DHT callback > package loss wasn't too big and was still sending data after 12hrs
-
Thank you, Gordon!
I already added a capacitor on both, that didn't change much.
I kept testing last night with the transmissions and I think the problem is maybe in combination with the TSL readings. By reducing the package size I got it to send good data every now and then but whenever a reading from the TSL2561 was scheduled, the data package gets still messed up.
Its like trying to send data within callbacks after reading from the TSL does mess it up. After 30 or so more seconds it works again.
I am 100% sure that I am sending strings and I also convert all readings with
Math.round()to make it impossible to have junk in my values from using possibly faulty readouts.Tonight I will try to remove the TSL and maybe don't send data within the callbacks.
-
- 6 comments
- 4,597 views
@Gordon, you are welcome to use it.
It is based on https://github.com/iskugor/js-promise-simple/ and was not put under a specific license. There are a lot of adaptions of the simple promises out there.
I've put my modules in the default
modulesfolder so it behaves like every other of your modules.