Search results for:

Confirmed, works as a charm with Chrome, not with Firefox, Brave as BLE is missing to them.

Sorry having disturbed you..

Ok, I used Web ide with Chrome, it works immediatly better... Apparently nothing is lost in transmission.
And, by the way, Brave doesn't connect as BLE is not available...

Hi,

I use the native ide on windows 11.

getData() reads the data stored in 4 arrays Uint16 or 32 bits.
This data is stored when a watch, initialised by initWatchs(), launches one, depending on the board used, of sALcd(d2,p2) for Pixljs or sALcd(d2,p2) for the original espruino.
The sensor is an LDR and data is: a counter, the date, the time between falling edges of LDR, and a computed power.
As a result I expect to upload data either with usb from the original espruino board or with ble advertising from Pixljs: This is yet to be added as I found a third project here.
Ble advertising is steep a learning curve for me so far: choosing a standard UUID in the table and setting up the formatted data value.

Basically, this is an extension of your puckjs ldr based tutorial wired just as you did and some other data logger tutorial...
Indeed, I am trying to catch the very same power meter diode flashes while my solar panels over produce energy and the apparent power gets down to 0.
In this case, there is a 0 apparent power provided but the power meter's serial link, while the led flashes at each Wh, so ...
This information is officially provided by a serial uart names TIC (teleinfo) here in France. It takes an opto isolation and 1,N,8 at 1200 bauds to get some data which would allow me to measure each reinjected Wh and the time between those pulses to know what power is beeing reinjected to the grid right in real time. This link is well known here and there are many schematics and ready made interfaces for USB devices. I have run it on a raspberry pi since 2014 "almost" uninterupted.
There is an equivallent serial link in Belgium and the Netherland as far as I know.

Hi, happy new year 2023 to every one!
Almost 10 years since this thread started and I have this very same problem:
Dropped characters in the terminal and at upload time via BLE.
This happens on a Pixljs with espruino 2v16, a pc on Windows 11, and I tried, with no luck, differents settings:
+Bluetooth smart (BTLE) via 'noble': on or off,
+Bluetooth smart (Web Bluetooth): on or off,
+Software Flow Control: on or off,

The screen below is a upload time or after a reboot, dump and reset...

I also, with no results:

• reflashed the Pixljs from Android and nrfConnect...
  

• cleared the Flash and just upload to RAM.

  >dump()
  =undefined
  >reset()
  =undefined
  _ _|_|___ ___        _
  |  __|_ -| . |
  |____|___|  _|_| |___|_|_|_|___pruino.com
  2v16 (c) 2021 G.Wil
  > 
  

and this one is a dump of data, all lines should have the same structures, they obviously don't.

>getData()
{
  "time": Date: Thu Jan 1 0100,
  "pulseNumber": 1, "pul"power": 2510 }
{
  "time": D0 17:10:54 GMT+0100,
  "pulseNuration": 3, "power": 1220 }
{ Thu Jan 1 1970 17:10:57 GMT+0100": 3, "pulseDuration": 2.4, "pow "time": Date: Thu Jan 1 1970 17
  "pulseNumber": 4, "pulseDurat: 5190 }
{
  "time": Date: Th:34 GMT+0100,
  "pulseNumber":": 1, "power": 3620 }
{
  "ti 1 1970 17:18:38 GMT+0100,
  "pulseDuration": 2.1, "power": 17: Date: Thu Jan 1 1970 17:18:40 seNumber": 7, "pulseDuration": 2
=undefined
> 

It is reproductible: issueing the same command produces the very same dump.

Finally, It also happens if I paste some code on the right pane of the native editor: lost chars and randomly placed edit cursor on the edited line only while attempting to paste from elsewhere, say a web page.

The full code below is hill named but at the end I expect this to run on an old original espruino board.

So what could be the cause?
Maybe another BLE device?

Thanks for your attention...

Hi @Gordon, how about a new generation of Espruino boards based on NRF52840? More ram, flash and ultra low powerwith ble integrated... 😎

Hi all,

Just as an example, I am doing that sort of things with a ublox sam-m8q gps using their binary protocol.
The example below is for the paragraph 31.18.20 UBX-NAV-STATUS (0x01 0x03).
Their messages are pure packed c struct with properly aligned words, dwords and so on and most of those have a fixed length. That was designed for C, C++ definitely.

However, I am not using an array, just a buffer containing a single data packet.

I would store more than one in an Array (javascript standard) of ArrayBuffer(s) and then getters or setters with this kind of Dataview code, not pre splitted buffers with their contents separated. Thats may be slower but it's memory savy.

gps.Status = function() {
      if (this[0x0103]===undefined) return undefined;
      let d=new DataView(this[0x0103].buffer);
      return {
          iTOW: d.getUint32(6, true)/1000,
          gpsFix: d.getUint8(10, true), 
          flags: d.getUint8(5+6, true),
          fixStat: d.getUint8(6+6, true),
          flags2: d.getUint8(7+6, true),
          ttff: d.getUint32(8+6, true)/1000,
          msss: d.getUint32(12+6, true)/1000, 
          receivedAt : new Date(this.receivedAt[0x0103]*1000)
      };
};

Hi,

So I connected a Pico to an Original Espruino and tried to monitor the Original Espruino from the Pico.
So far, I ended up with results only for busy indicator as I am running the original espruino board from USB connection so there is no deep sleep available yet.

The code on the Originla Espruino just includes

  setBusyIndicator(LED1); // A13
  setSleepIndicator(LED2);  // A14

The code on the Pico is

/*
              Measure time spent on LED1/LED2 by an original Espuino board
              */

var onPin=B10; // Non deep sleep (1===running or simple sleep) led from Original Espruino Board
var onTime=0;
var busyPin=B13; // Busy (1=== running, neither simple sleep, nor deep sleep) led from Original Espruino Board
var busyTime=0;
var deepSleepTime=0;
var startedAt=getTime();

function log() {
  let runningFor=getTime()-startedAt;
  console.log("Running for",runningFor,"s");
  console.log("On time (Busy + Sleep)",onTime,"s",Math.floor(onTime*100­0/runningFor)/10,"%\tbusyTime (Busy)",busyTime,"s",Math.floor(busyTime­*1000/runningFor)/10,"%\tdeepSleepTime",­deepSleepTime,"s",Math.floor(deepSleepTi­me*1000/runningFor)/10,"%");
}

function resetChronos() {
  onPin=B10;
  onTime=0;
  OLED2=B13;
  busyTime=0;
  deepSleepTime=0;
  startedAt=getTime();
}

function onInit() {
  resetChronos();
  log();
}

var idOnTimeWatch=setWatch(function (e) {
  onTime+=e.time-e.lastTime;
}, onPin, { repeat:true, edge:'falling' });

var idBusyTimeWatch=setWatch(function (e) {
  busyTime+=e.time-e.lastTime;
  log();
}, busyPin, { repeat:true, edge:'falling' });

var idDeepSleepTimeWatch=setWatch(function (e) {
  deepSleepTime+=e.time-e.lastTime;
  log();
}, onPin, { repeat:true, edge:'rising' });

Hi,
Just to mention that the schematics show 100 ohms resistor in series with each led.
So, in your test 3, 20 ms on every 5000 ms should give us: 20 ms / 5000 ms*(3.3v-voltage drop of led) / 100 ohm.
If we assume a voltage drop of 0,7v we get 0.104 mA for lighting the sole led1 20'ms every 5000 ms.
That said, the way you connect your battery could keep usb drivers awaken and trying to detect some data connection. This is just an hypothesis 🤔

I am very interested with this kind of problem too... Keep us informed of your results 😓

Well, in some cases, at wake up some data can be lost due to the time it takes to re setup the peripherals links (usarts, spi...). That's from deep sleep.

Hi,

The title says it all: Is there any hope to get, at run time, the various instants at which all the run/sleep/deep sleep modes were entered by the interpreter? Cumulated times spents in each mode would be a way to quantify easily the power consumption...

Ok, (re) found setBusyIndicator which should show when running and not sleeping: I have to test that...

Aside of time measurements, it would also give an idea of the eventuals problems of lost data when getting out of deep sleep mode.

Thanks for your attention.

However, Espruino is designed to run on very low level mcu's and it doesn't claim any real compatibility with nodejs or other standards.
You should search this forum about that and read the reference rather than other sites.

Maybe the Tessel board would suit you better?

Hi,

Reading your question more carefully, your problem is the value of this in the setInterval, probably the global context which is not what you want.
This can be resolved by sending the right context object for this as an added last argument in setInterval or seTimeout as below.

...
var timeoutID = setTimeout(function (self) {
  console.log(self); 
}, 500, this);
...

So, your object, instance of class, will be called self in the setInterval/SetTimeout at execution time...

You should look at the reference of setInterval and this non Espruino thread or this other one

Yes, I agree that your solution .getTime() seems to be the sole safe solution...
Thank's again for your reactivity.

There is no such thing as an uncoherent choice: But that's javascript standards... :)

1. E.setTimezone takes hours,
   
2. new Date().getTimezoneOffset() gives signed minutes,
   
3. new Date().getTime() gives ms,
   
4. *monthes are 0 based*
   
   
   

I had dreamed, apparently, to just add the new Date().getTimezone() minutes to the minute parameter of new Date(..., minute, ...) rather than convert everything to ms since 1970, just for simple straight readability.

To explain a bit more what makes me wondering so much: I get the gps time as 6 bytes in UTC time from ublox M8 binary protocol UBX-NAV-PVT or UBX-NVA-TIMEUTC for instance.
Here is an excerpt of my code, (this[289].buffer is Uint8Array containing exactly the ublox binary packet (absolutly the all of it, header and checksum included) and d the DataView on it.
The hidden magic trick here, is that if E.setTimezone(1) is system wide used, the UTC time will be wrong as it is so biaised and you can't see that reading the code: You have to be aware.

  var posGps= {
...

get TIMEUTC() {
    if (this[289]===undefined) return undefined;
    let d=new DataView(this[289].buffer);
    return {
      iTOW: d.getUint32(6, true)/1000,
      tAcc: d.getUint32(6+4, true)/1e9,
      nano: d.getInt32(6+8, true)/1e9,
      dateUTC : new Date(d.getUint16(12+6, true), d.getUint8(14+6, true)-1, d.getUint8(15+6, true), d.getUint8(16+6, true), d.getUint8(17+6, true), d.getUint8(18+6, true)),
      valid: d.getUint8(6+19, true),
      receivedAt : new Date(this.receivedAt[289]*1000)
    };
  },
...
}

Hi @Gordon,
I am playing with time zones vs UTC & GMT those days and found this to be a problem:

new Date().getTimezoneOffset()
=-60
>new Date(2019,1,7,10,34-60,19,0)
=Date: Thu Feb 7 2019 09:34:19 GMT+0100
>new Date(2019,1,7,9,34+60,19,0)
=Date: Thu Feb 7 2019 09:34:19 GMT+0100
>new Date(2019,1,7,8,49+60,19,0)
=Date: Thu Feb 7 2019 08:49:19 GMT+0100
>new Date(2019,1,7,0,34-60,19,0)
=Date: Wed Feb 6 2019 23:34:19 GMT+0100
>new Date(2019,1,7,0,34+60,19,0)
=Date: Thu Feb 7 2019 00:34:19 GMT+0100

So, if I use a negative minute, the hour will be correctly handled while using an over 60 minutes minute parameter will not increment the hour....

This all about gps providing UTC time while I have to handle local day time and winter / summer changes. Beeing in continental Europe, I have an approximative approach (not world wide) which gave me the following functions to get summer / winter day light savings:

// https://www.calendrier-365.fr/heure-d-et­e-heure-d-hiver.html

function jourFinHiver(annee) { // last sunday of march
  return Math.floor(31.8 - ((((5 * annee) / 4) + 4) % 7));
}

function jourFinEte(annee) { // last sunday of october
  return Math.floor(31.8 - ((((5 * annee) / 4) + 1) % 7));
}

function hiver() {
  today= new Date();
  month=1+today.getMonth(); // so 1 based
  if ([1,2,11,12].indexOf(month)>=0) return true;
  if (month===3) return today.getDay() < jourFinHiver(today.getFullYear()); // TDB take care of first hours of day which is still in winter
  if (month===10) return today.getDay() >= jourFinEte(today.getFullYear()); // TDB take care of first hours of day which is still in summer
  return true;
}

// Set the system time zone in agreement with Uk & Europe day ligth savings (aka winter / summer time) UTCwinterToGMT = 0 for UK, 1 for France/Benelux/Germany...
function setTimeZone(UTCwinterToGMT) {
  E.setTimeZone(UTCwinterToGMT + (hiver() ? 0 : 1));
}

// Only valid in Europe (UTC winter to GMT=+1) and UK (UTC winter to GMT = 0)
function localDayTimeHour(UTCwinterToGMT) { // valid for UTC+1-UTC+2 in continental Europe
  setTimeZone(UTCwinterToGMT); // Handle time zone at system level
  return (new Date().getHours() ) % 24;
}

So references above are in french... Which is fine for me :)

Just to get a bit deeper: should the button beeing waited for be a pull-up or a pull-down? At this level of power consumption, any leakage is costly.

Hi,
You should be aware of:
this dedicated page about Arduino+Differences
and/or more MCU like functions as:
shiftOut
Waveform.startOutput

Those are not necesseraly the answer to your precise question. But If you have very short waits then they will be the beginning of an answer.

Just understood: That means one year on a CR2032 waiting for a button press...
Congratulations!

Nice..

So, the results are really promising with little or no more shift with:
E.setRTCPrescaler(320000.923(1+466.385/46190))
The pico is still ahead of gps time by -1.42972660064 s / 4215 s.

Note that those figures are now not really meaningfull: The time granularity on gps time and pico's time are 1 second each...

So now, more test, more or less at room's constant temperature with:
E.setRTCPrescaler(320000.923(1+466.385/46190)*(1+1.42972660064/4215)­)

Finally, there is the prescaler granularity too..

Hi again,
After a longer test I get the following results:
-466.385 s (the Pico is counting a bit faster than the Gps) on a gps duration of 46190 s: so -0.0101 % of error having used E.setRTCPrescaler(29536); before the sync of gps's time and pico's time.
So i expect no drift is I use E.setRTCPrescaler(29534); or more precisely E.setRTCPrescaler(320000.923(1+466.385/46190));

Let's get started again with this!

Ok,

So I flashed this frimware and restarted tests using my Gps provided time.
I guess there is more precise clock than a Gps available to me.

So apparently, if I do E.setPrescaler(32000) then it will drift (same value as usual), while with E.setRTCPrescaler(29536), it is only once (a time sync I think) and not later.
Longer tests are required...

Anyway, nice way to correct potential time shifts as it is now possible to measure the coefficient of shift and apply it automatically.

Just to ask more, E.getRTCPrescaler() would be usefull too. :)
Thank you.

Powered from USB connector I measured:
Vbat-Gnd = 4.27V
Vbat_in - Gnd = 4.27V also
3.3 - Gnd = 3.28V to 3.29V also.

B0 is shorted by a solder bridge which I intend to use powering the pico from Vbat_in while powering my gps receiver from vbat controlled through the mosfet and b0 one day.

My pico came from Kickstarter campaign...

Hi @Gordon,

Yes, this is quite far off.
I only have one Pico, an original and a NucleoF401RE which, I guess could be the other candidate although it is bulky and lacks the mosfet...

Unfortunately, I expect to use:

• deep sleep most of the time (one wake up every 4 hours).
  
• setTimeout for shorted durations (3-6 minutes).
  
  

Actually, I was testing the setTimeout when I found this problem.

So Here are the results of the test you proposed: 0.925 seems to be t a constant value.

process.memory();
={ free: 5076, usage: 24, total: 5100, history: 7,
  gc: 0, gctime: 5.15270233154, "stackEndAddress": 536958912, flash_start: 134217728, "flash_binary_end": 385848,
  "flash_code_start": 134234112, flash_length: 393216 }
>for (var i in global) print(i+" : "+E.getSizeOf(global[i]))
JSON : 1
process : 1
i : 1
E : 1
=undefined
>    analogWrite(B3,0.5,{freq:0.5});
=undefined
>    setWatch(function(e) {
:      print(e.time - e.lastTime);
:    }, B4, {repeat:true});
=1
NaN
0.92654609680
0.92720031738
0.92611026763
0.92719173431
0.92583274841
0.92541325092
0.92637145519
0.92529761791
0.92329704761
0.92374420166
0.92555725574
0.92385566234
0.92300796508
0.92220115661
0.92258453369
0.92306327819
0.92353439331
0.92302989959
0.92228221893
0.92291343212
0.92221176624
0.92150974273
0.92200851440
0.92271804809

Hi @Gordon,

I revive this old thread mainly because of its title.

On a Pico 1v3 with Espruino 2.01, I have a time shift of about 4.5 s per minutes: that is, I used new Date() on the console twice, separated by 4 minutes from my PC own time and got 18 s of difference. The pico was in late by that much.
This was also shown to me by a Gps time provided resynchronising the system time every 20 s or so each time there was more than 1 s of difference between system time and UTC time provided by the gps. Again the pico was always in late from gps time.

This resist to power on/off and getTime() gives the same results.
The pico is in a standard room, neither sunny place, nor cold one (22°C).

Any idea of why there is such a difference or could it be that a crystal is required?

Thanks for your reading anyway.

Hi again,
Well now github offers unlimited private projects for free, the restriction is on the number of developpers allowed to participate.
There is also gitlab which does more or less the same.
Their rate limits are probably high enough for me as I don't frenetically type on my keyboard :)
Still we would need some API on their side.
And finally, I'd prefer a save to a local storage.