times in events...

Right now, the times reported for things in events are... uh.... wrong.

On an Arduino, clocked off a crystal, I can constrain the 1 and 0 lengths like so:

// Version 2.1
int rxSyncMin = 1900; //minimum valid sync length
int  rxSyncMax = 2100; //maximum valid sync length
int  rxZeroMin = 120; //minimum length for a valid 0
int  rxZeroMax = 400; //maximum length for a valid 0
int  rxOneMin = 450; //minimum length for a valid 1
int  rxOneMax = 750; //maximum length for a valid 1
int  rxLowMax = 600; //longest low before packet discarded

int  txOneLength = 550; //length of a 1
int  txZeroLength = 300; //length of a 0
int txLowTime = 420; //length of the gap between bits
int txTrainRep = 30; //number of pulses in training burst
int txSyncTime = 2000; //length of sync
int txTrainLen = 200; //length of each pulse in training burst

The Arduino receiver happily takes the transmission and yields the correct result. With no interrupts or hardware timing more advanced than micros():

+1FE10001

Now, let's look at what lengths we get for those under Espruino:

>setTimeout("stopListen()",10000);startL­isten();
Listening started
=undefined
0.00003242492
0.00004386901
0.00006008148
0.00008010864
0.00002765655
0.00003337860
0.00003993511
0.00002574920
0.00002098083
0.00007808208
0.00006484985
0.00005233287
0.00005054473
0.00001811981
0.00001907348
0.00002002716
0.00005042552
0.00004482269
0.00004482269
0.00001525878
0.00013065338
0.00010776519
0.00004208087
0.00002861022
0.00008201599
0.00005435943
0.00035572052
0.00033950805
0.00032424926
0.00031471252
0.00030422210
0.00030517578
0.00029563903
0.00029087066
0.00028038024
0.00026702880
0.00028228759
0.00026607513
0.00026607513
0.00025939941
0.00025558471
0.00026226043
0.00024318695
0.00024127960
0.00023365020
0.00022792816
0.00022411346
0.00022411346
0.00022220611
0.00022125244
0.00021743774
0.00021457672
0.00021076202
0.00020217895
0.00019359588
0.00018119812
0.00029850006
0.00026321411
parserx
listening stopped
11111110000000000000000000000010
bad csc
Expected 1 got 2
Listening started
0.00022888183
0.00027191638
0.00002479553
0.00004196166
0.00016307830
0.00016307830
0.00012493133
0.00013923645
0.00019264221
0.00035572052
0.00035750865
0.00034701824
0.00033652782
0.00035667419
0.00037956237
0.00038337707
0.00013637542
0.00013637542
0.00014209747
0.00014209747
0.00039577484
0.00015640258
0.00015735626
0.00014400482
0.00015830993
0.00016498565
0.00015449523
0.00015735626
0.00042057037
0.00014889240
0.00016403198
0.00016498565
0.00040256977
0.00017833709
0.00015735626
0.00016307830
parserx
listening stopped
00000111111100001000000010001000
good csc

Note how the numbers are all WAY LOWER than they should be. Those decoding results are after I lowered the threshold for 0 vs 1 down to 0.000295, in an attempt to get everything out of the 0 range, and widened the threshold for accepting, ie:

function sigOff(e) {
	var d=e.time-e.lastTime;
  console.log(d);
  if (d>0.00012 && d<0.00075) {n+=d>0.000295?1:0;}
  else {n="";}
	if (n.length==z) parseRx(n);
}

This is with analog squelching, by the way - it works splendidly. I can still receive without it - and it doesn't change the fact that the times are all over the place and consistently way under what they should be.

Not sure I understand - what lengths should it be reporting back? What if you attach it to something like a PWM output that you know the frequency of?

Also, is this the Espruino Board, or the Pico?

Just tried this on the Pico:

// short B3 and B4
var d = 0;
analogWrite(B3,0.5,{freq:1000}); 
setWatch(function (e) {d=d*0.9+(e.time-e.lastTime)*0.1;}, "B4", { repeat:true, edge:'both' });

and d is 0.00043812713 on one board and 0.00047730952 on the other. I think it's because the board is using the internal RC oscillator, which is supposed to be 40kHz but seems to be pretty inaccurate on the F401 chips.

In fact you can check, because if you warm the chip up that number changes drastically.

I think the only solution is to actually 'trim' the internal RC oscillator based on the external high speed crystal (which is relatively accurate) - I just haven't got around to adding the code for that yet.

It's the Pico.

It should be reporting back lengths of around 0.00055 and 0.0003. So it's off by ~50%, plus a ton of jitter...

Instead, well, look at the values it's reporting - all those numbers above the two parserx outputs (where it gets a packet that doesn't match what was sent) are bits! Consistently smaller, and the longest reported lengths for zeros are longer than the shortest reported lengths of the ones.

(bitstream should be 1FE10018 - the last nybble is the checksum, which the arduino receiver filters out)

00011111 11101000 00000000 00011000

On arduino based receiver, I count 0.12-0.40 ms as 0, 0.45-0.75 as 1.

I wonder if this is responsible for the problem that guy recently had with HC-SR04 reading consistently low?

Hmm... That is particularly far out - I wouldn't have thought the oscillator would be that bad!

You're doing setWatch(... {repeat:true,edge:"falling"}) ? I just wonder if it's reporting back the gap length, or something dumb.

Depending on the signal, it could also be reporting differently because it'll be running with 3.3v logic levels, and Arduino with 5v ones.

Might be interesting to try the code I posted above though (or similar)? Just to get an idea of how far off the oscillator really is.