ultrasonic sensor node-red-node-pisrf

490 views
Skip to first unread message

David Caparrós

unread,
Jan 2, 2018, 12:02:23 AM1/2/18
to Node-RED
Good morning

I'm trying to run a ultrasonic sensor in order to get some distance reading, I don't need a high accuracy however I need some stable data reading.

I have several possibilities with a ESP module trough MQTT runing ESPEASY however this need a level shifter and  I have not being able to get a proper reading on some test I have done...

Some other option is trough the arduino board I have connected via USB flashed with standard firmdata which I already use to get some input/outputs but I have no found an easy way to make it run this way, I have tried jhony-five module but I had some troubles in order to get it running.

As last I have tried with module node-red-node-pisrf.  https://flows.nodered.org/node/node-red-node-pisrf

I have connected originally with the echo pin directly with the GPIO but I had a problem that measure read out oscillates more than 100 cm.

This instability on  the read make it unreliable for me and made some test to see if I was able to solve it without success...

- I tried to connect a voltage divider with a 10K and 4.7K as found on several tutorials.
- I tried to supply external 5VDC to ensure was not some unsuitability.
- I tried to increase the original reading period configuration from the PI SRF.
- Tested 2 different sensor just in case one was faulty.

As said no success as all in getting some stable reading.

Only point is that on node link is written to be made for sensor SRF04 or SRF05 while mine is SR04 however surfing on the need seems to have same functionality and the one I have is the most used on all tutorials I have found.

Does anybody have some experience with this?

For the moment in my flow I have it solved provisionally writing a function to filter and dismiss oscillation respect the previous reading higher or lower than 50 as follows:

if (msg.topic == "actual") {
context.actual = msg.payload;

}
if (msg.topic == "previo") {
context.previo = msg.payload;

}
temporal = context.previo - context.actual;
    
if ((temporal < 50) && (temporal >! 50)){
    msg.payload = context.actual;

  return msg;
}
else
  return null;


Thanks in advance


Dave C-J

unread,
Jan 2, 2018, 4:05:25 AM1/2/18
to node...@googlegroups.com
Hi,

I'm surprised the 04 is so bad as most indications seem to say they are very similar. 
Most of the hardwork in the pisrf node is done in the python file nrsrf.py - so you could have a poke around in there to see if it could be improved.
You could also look at the RBE node as that can also be used to filter out  "bad" readings, where things change by more than a set amount.

Julian Knight

unread,
Jan 2, 2018, 6:23:13 AM1/2/18
to Node-RED
I haven't played with one of these for a long time - back when I was building a robot with my son. No Node-RED on that, it was purely Arduino code & I can't really remember how accurate it was. I think that we used an Arduino library so it is probably worth having a look at that as well to see how they handle the issue. I don't remember it being that variable though it does have problems with some materials.

If you are using a serial connected Arduino, I personally wouldn't recommend Firmata for this. Use a library and create some custom code, it wouldn't be a lot of code to do the sensing as long as you use a library. Then you can pass the data to NR just as you need it.

AIOT MAKER

unread,
Jan 2, 2018, 8:42:55 AM1/2/18
to Node-RED
Hi,

Looks like there is a typo in the filter function, more specifically on the statement: 

if ((temporal < 50) && (temporal >! 50))

I guess your filter will not work as you expect for oscillations greater than 50.  





David Caparrós

unread,
Jan 2, 2018, 9:33:13 AM1/2/18
to Node-RED
The warning on the function is because of the ">!"  however it works perfectly as expected any single value peak high or low is not send as msg.payload.

My is question is regarding this specific node I used to see if someone had some experience with same results or someone uses one of those sensors somehow working well.

Regards

Colin Law

unread,
Jan 2, 2018, 9:39:52 AM1/2/18
to node...@googlegroups.com
On 2 January 2018 at 14:33, David Caparrós <davi...@gmail.com> wrote:
The warning on the function is because of the ">!"  however it works perfectly as expected any single value peak high or low is not send as msg.payload.

For the uninitiated in some of the subtleties of js, what does temporal >! 50 mean?

Colin

steve rickus

unread,
Jan 2, 2018, 10:00:52 AM1/2/18
to Node-RED
Afaics, that comparison syntax means nothing, since it always returns true...

> var tst = 40
> tst >! 50
true

> var tst = 60
> tst >! 50
true

> var tst = 50
> tst >! 50
true

David Caparrós

unread,
Jan 2, 2018, 10:03:55 AM1/2/18
to Node-RED
 More uninitiated than me is difficult.... hahahha

Obviously was not ok and should be:

temporal = context.previo - context.actual;
    
if ((temporal < 50) && (temporal > 0)){
    msg.payload = context.actual;

However for the function I need my main issue is when the values jump from 260 to 100 not to a higher values.

Regards

Colin Law

unread,
Jan 2, 2018, 10:10:33 AM1/2/18
to node...@googlegroups.com
Interestingly I think
temporal >! 50
is interpreted as
temporal > !50
and since !50 is false or 0 in a mathematical comparison then it is the same as
temporal > 0
which is exactly what you wanted.  So nothing wrong with it at all :)

Colin

--
http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+unsubscribe@googlegroups.com.
To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.
To view this discussion on the web, visit https://groups.google.com/d/msgid/node-red/12922595-dcc3-47c3-a8e2-492b5297b8d7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

AIOT MAKER

unread,
Jan 2, 2018, 11:16:52 AM1/2/18
to Node-RED
David,

As for your question about the accuracy of this sensor I found this interesting post. The author provides a link to an awesome testing report.


link to jump directly to the PDF report:  test report: https://app.box.com/s/4nafz9scusuk4kq1628u


David Caparrós

unread,
Jan 2, 2018, 3:47:46 PM1/2/18
to Node-RED
Thanks guys

respect the function I was trying the good one should be:

temporal = context.previo - context.actual;
    
if ((context.previo > context.actual) && (temporal < 50)){
    msg.payload = context.actual;

  return msg;


However the important is to make work properly the sensor and don't require any odd filter... hahaha

I'm going to investigate some more on the .py code and on the sensor specification  and will be back once I get some conclusion.

Regards

Bart Butenaers

unread,
Jan 2, 2018, 6:11:23 PM1/2/18
to Node-RED
Hey David,

I have been experimenting with SR04 some time ago, and I had the same issue as you have: the measurement was 'very' unstable (indeed more than 100 cm).  Thought at that moment it happened because I bought the SR04 on Aliexpress...

However the problem was (in my case) that I used following diagram from the internet:

Seemed that the 5V pin on my Raspberry wasn't sufficient: was only about 4,8 Volt and not stable.

After replacing it by a decent stable 5V lab power supply, it became very accurate (about 1 cm tolerance).

Have been testing it at the time being on about 5 different SR04 sensors, and they were all stable afterwards.


But I see that you are already using an external power supply...

A collegue of mine also had similar issues, and he solved it by adding an extra 470 nF ceramic capacitor between Vcc and ground.


At the time I had the problems, I also have been looking at the RPI-GPIO Python code.  

However I didn't find anything useful.  

The only thing I found: when the Raspberry is heavily loaded, it might take too long before NodeJs handles the events, so the timing between the trigger and echo pulses is being messed up.


Good luck with it !

Bart

David Caparrós

unread,
Jan 3, 2018, 10:11:49 AM1/3/18
to Node-RED
Thanks Bart

I will investigate some more, at least good to know I'm not the only one having troubles with those sensors.

Regards 
Reply all
Reply to author
Forward
0 new messages