Search results for:

Hi!
I've just tried to write an image to my famous clock :) and found a bug with transparent color.

var image={ width:9 , height:13 , bpp:24 ,
  buffer:Uint24Array(
[
  0x0,0x1,0x2,0x4,0x8,0x10,0x20,0x40,0x80,
  0x0,0x100,0x200,0x400,0x800,0x1000,0x2000,0x4000,0x8000,
  0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,
  0x0,0x10000,0x20000,0x40000,0x80000,0x100000,0x200000,0x400000,0x800000,
]),
  transparent: 0x1,
};
gt.drawImage(image, 5, 1);
neopixel.write(pin, gt.buffer);

I expect transparent point is in first image line (I can find it even if image is mirrored because there is second color line near) but it is actually in last one. If I set transparent to 0x10000 I see transparent point in first line while expect it in last one.

It works! Wonderful! Thank you, @Gordon!
I choose good time for upgrade :) I've used v1.92 without the timeout bug and now I am using pre-v2.06, again without the bug. SPI is now working with TLE94112, too.
Now I still have 2 problems only: temperature is readed not every time by OneWire (about 1 reading of 100 is unsuccessful, while it was very stable at v1.92, I've never seen that last 3 years, or about 1 500 000 x 4 reads) and EspruinoHub often does something strange (but I have another topic to discuss that). And, of course, unstable connection in EspruinoWebIDE: usually I should restart IDE server 2 or 3 times before I can connect to device, but the problem is development stage only, so it is not so significant.

I've got cutting edge v2.05.107 and it looks like working! Wow!
Tomorrow I'll check it in my greenhouse.

Yes. The stripped version works when I remove the setTimeout. But my full version is based on Timeouts from Timeouts from Timeouts etc... Usually I do not ever know if some function is called from timeout or not.
Is it possible to use timeouts from timeouts safely? Or the only way is to wait for update? I have only one setInterval in the program and it can be removed easily, if that is significant.

I'm not entirely sure about the reasoning for that anyway?

It's just to make an update of full BLE advertizing, while there are many calls of updateAdv in many functions. So I can call updateAdv in every place where I change some part of advertizing data but actually I have only one update where all these fields are changed. It is update aggregator.
I use similar code in many places. For example, in my big clock there may be few additional info, and it is resonable to update screen one time, after all data is redrawed to screenbuffer.
Ok, I'll try to turn it off and check.

I especially like the MQTT idea, but can this run also on a windows10 machine in case I have to use one?

I do not know. May be, but it is a question to somebody who have tried already. I use bananapi M64 board as a server, and both EspruinoHub and mosquitto (and BlueTooth) on the server. May be it may be started at Windows 10, too. And yes, EspruinoHub converts BLE messages to MQTT messages. What is good for me is that I can implement some tree.js controller in 10 minutes.

Any idea how to implement a good reliable distance measuring

May be it will be interesting for you to measure smaller distance (0.02-1 m) with better resolution? You can use VL53L0X in the case. I've used it and have found not bad. It may be used at longer distances, too. But conditions are not usual, as far as I remember.

Full code of my greenhouse controller can work at standalone Puck.js. I can add it here. But it is too complex, I think. So I've cropped it. Now it is small part of code but still has the effect in setTimeout. I've just test it and results are: 1266 seconds by getTime() while only 139 with setTimeout in dump(). So the code is here. Last setTimeout is for the test.
I've observed that it depends on setInterval (there is only one in my code) which is calles NRF.setAdvertizing(). If I remove setInterval, setTimeout looks like work correctly (I'm not sure). If I do not disconnect from device in EspruinoWebIDE It may be works correctly, too.

Upd: I can not upload file (do not know why) so code is below:

var Day = true;

// usage types: 0 - unused, 1 - watering, 2 - anti-overheat fog
// wateringTime is in minutes (after start), while startHour is in hours after dawn
var channels = [
  {wateringStartedAt: 0 },
  {wateringStartedAt: 0 },
  {wateringStartedAt: 0 },
  {wateringStartedAt: 0 },
  {wateringStartedAt: 0 },
  {wateringStartedAt: 0 },
];


var VArr = new Uint8Array(4);

let updatePending = false;
function updateAdv() {
  if (!updatePending) {
    updatePending = true;
    setTimeout(function () {
      updatePending = false;
      let pack = 0;
      for (let i = 0; i < channels.length; i++)
        pack = (pack << 1) + (channels[channels.length - 1 - i].wateringStartedAt ? 1 : 0);
      VArr[2] = (Day << 7) + pack;
      VArr[3] = 255;
      NRF.setAdvertising({
        0x1813: VArr
      }, {
        name: "Green", // The name of the device
        showName: true, // include full name, or nothing
        interval: 600 // Advertising interval in msec
      });
    }, 0);
  }
}
NRF.setTxPower(4);
setInterval(function () {
  VArr[1] = Puck.light() * 255;
  updateAdv();
}, 120000);


setTimeout((s)=>console.log(s),7200000,"wwee11");

I've just made a tweak that should make your old code work fine though.

Great! I've changed EspruinoHub to my code can work, but it is good to use regular one. Because the problem may be not only my problem.

If you go to http://yourdevice:1888/status do you still see the device you're trying to connect to shown? Maybe for whatever reason it isn't seeing it in the advertising data?

It seems to me, device is in place and advertizes carefully :) But string 'Scanning stopped' and subsequent strings will not appears anymore before EspruinoHub restart. I'll try to mine additional info.

So the only actual change would be if packet size =20 it'd send a blank packet?

Exactly! If last packet chunk size =20, send a blank packet after. It is like USB works (I'm not sure that USB3.2 uses the same, but up to 3.0 it uses the method to reassemble data). I've implemented that in EspruinoHub (but my code is ugly while correct) and I'm happy. I think it may be useful not only for me.

At my greenhouse system it does not work. I see something like this:

>getTime()
=1282.59722900390
>dump()
setTimeout(function (s) {return console.log(s)}, 6869723.54125976562); // 3
.................. after a few minutes
>getTime()
=2236.14056396484
>dump()
setTimeout(function (s) {return console.log(s)}, 6712184.47875976562); // 3

SetTimeout is only a part of code in dump, of course. But I add the timeout manually from console, so other code do not interact with the timeout.

I have checked the same on cleaned Puck.js. And it works. So I will try to find when it happens.

I've just checked that getTime() works correctly at the same time.

@MaBe, could you add clk and, may be, cs? it is too hard to read SPI data without clk.

I still try to update my greenhouse controller. It worked at v1.92 and now it is with 2.04
I've found that it begins planned sequences at incorrect time. Fully incorrect. I've just made the check:
I've started a few setTimeouts, get dump(), then have disconnected, have waited about 10 or 12 minutes and get dump() again.
Here is the results of first dump()

setTimeout(function (s) {return console.log(s)}, 6880496.76513671875); // 3
setTimeout(startWatering, 3308897.216796875); // 4
setTimeout(startWatering, 3308899.169921875); // 5
setTimeout(startWatering, 3308901.18408203125); // 6

And second one

setTimeout(function (s) {return console.log(s)}, 6772275.60424804687); // 3
setTimeout(startWatering, 3200676.05590820312); // 4
setTimeout(startWatering, 3200678.00903320312); // 5
setTimeout(startWatering, 3200680.02319335937); // 6

As you can calculate, Puck.js thinks that I was away only about 1 or 2 minutes.
That is really problem for my greenhouse.
Is it a major bug or new feature (may be some kind of deepsleep which I should turn off)?

Usually I debug SPI using oscilloscope. Unfortunately now I have not one at home, and can not use one at work becouse of COVID-19.
By the way, OneWire looks to be not so stable at 2.04 as at 1.92. It returns zero or undefined time to time.

it looks like to be easy enough. But I did not use Web Bluetooth API, so I know only how to do that using MQTT and EspruinoHub. Puck.js can advertize sensors data in BLE, EspruinoHub converts it to MQTT messages, while your app connects to MQTT server using WebSockets (e.g. mqtt.js), receives the messages and process.

May it depends on long password, how do you think? I've never tested Espruino with so long passwords. Some old devices I had require password to be not more then 16 or even 8 symbols, I forget.

Hi!
I try to implement better BlueTooth control of my greenhouse and I have a few problems with EspruinoHub.
First of all, when I try to send stringifyed JSON from node-red I have a crash of EspruinoHub. It is because of the function in its code in mqttclient.js:

function convertMessage(data) {
  data = data.toString();
  try {
    data = JSON.parse(data);
  } catch (e) {
    // if it's not parseable, we just use the string as-is
  }
  return data;
}

The code converts string to string (nothing happens), then converts it back to JSON, and then the JSON can not be sent. My JSON is created from {c:{w:20,a:1},id:2}
My workaround is to comment JSON.parse().

Second problem is that EspruinoHub often stops to connect to device without any resonable log. I do not know why. Usually I can see that after device reprogramming. When I try to send something to device nothing happens. There is nothing like that:

Scanning stopped.
 dc:0f:df:1e:d4:72: Connecting...
 Connected.
 dc:0f:df:1e:d4:72: Getting Service...
 dc:0f:df:1e:d4:72: found service: fffe
 dc:0f:df:1e:d4:72: found characteristic: 1
 dc:0f:df:1e:d4:72: Written.
 dc:0f:df:1e:d4:72: Disconnecting due to lack of use (after 10 secs)
 dc:0f:df:1e:d4:72: Disconnecting.
 dc:0f:df:1e:d4:72: Disconnected
 Restarting scan
 Scanning started.

I've added logging to start of write processing (after 'if (path[1]=="write") {') and I can see that it is called with correct data. But there is nothing after that.
After it happens EspruinoHub come to state when it will not send anything to device.
After restart EspruinoHub returns to working state.

Third problem is packet reassembling at device. I'd want to propose some change in EspruinoHub logic. Now when EspruinoHub sends more then 20 bytes of data to BLE characteristic it split the data to 20 bytes chunks. And It is hard to check on device if everything is already sent. It will be quite easier if Espruinohub always sends last chunk of smaller size. It may be zero size if data size is multiple of 20.
The logic is similar to USB. I've implemented that. It makes packet reassembling very simple.

By the way, usual issue with DMA-controlled serial communications is that CS line is goes back to inactive state too early, when last byte is sent to DMA subsystem or to shift register, not waiting for it is fully goes out of system. I have seen that even in some hardware USARTs.

Greenhouse control works at v2.04!
By the way, OneWire ds18b20 works fine at 2.04 and breaks time-to-time (about one time of 20) at 2.05.27, too.

It looks like working on 2.04. At least, I see correct voltage transitions on pins.

I'm sure it worked at v1.92 more then 3 years 24h without any breaks. Great stability of your Espruino system!

I'll try to go to v2.04

Update: it does not work even at lower speed. I have not recognized still why. Some TLE registers may be written and some may be read but not full control sequence.

Thank you. I flashed v2.05.27 so my experiments were with the version, and I had 1.v92 before. code is just a modified TLE94112 example code:

SPI1.setup({sck:D28, miso:D30, mosi:D31, baud:integer=1000000, mode:integer=1, order:'lsb' });
var TLE = require("TLE94112").connect(SPI1, D27, D29);
TLE.enable();
TLE.logCtrlReg();
TLE.logSysDiag();
TLE.setDirection(1,1);
TLE.logCtrlReg();
TLE.logSysDiag();
TLE.disable();

Hi!
After long time I've started to update my greenhouse controller. It is based on Puck.js, whick is glued in center of the box.
First of all I upgraded Puck.js firmware from v1.92 to have working BLE characteristics (there were bugs with BLE at the old version). After the upgrade I've found that my greenhouse is dry, because TLE94112 is not response.
I made a few tests and discovered that maximal SPI speed to have it responsible is now 740000 baud (and 750000 is already too much) while at v1.92 it works at 1000000 baud and more. So, I think, something is wrong in SPI in new versions. Or, may be, somethink was wrong in old one. In any case, compatibility is broken.
I will change my soft, of course. But be aware because it may be invisible evil bug in the code ;)