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?
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
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?