Implement single pin mode.

[RobertPHeller]

I added code to implement single pin mode, as described in http://www.robot-electronics.co.uk/htm/srf05tech.htm.

I modified the constructor to take one argument (second argument defaulting to 0). Added a private bool variable to flag single pin mode and modified the _read() function to use the trigger pin as the echo pin when in single pin mode. It all compiles. I have not yet tested it with actual hardware yet.

[RobTillaart]

Thanks for the PR, This one was in the top of my todo list. Quite curious if it performs better or ... I wil dive into it later this week to review

Thanks again

[RobTillaart]

A quick look makes it seem to be straightforward. In my mind I had a plan to use Trigger ==echo as Singlepin condition. (Saves 1 byre wow)

Could you add an example (copy & modify) how to use the single pin interface? Would be appreciated

[RobTillaart]

If you set Trigger = echo then you could make the code around line245 a bit nicer. Trigger with triggerpin and do pulsein with echo pin.

Think the code could be made independent of single/double pin there. (Two extra pin mode calls).

[RobertPHeller]

Sure saving bytes is always good.

There is an example available at https://github.com/RobertPHeller/LibraryCourses/tree/main/ArduinoAndRoboticsForKids/UltraSonic/

There is a Fritzing file and a test program (.ino),

At Wed, 07 Feb 2024 12:05:52 -0800 RobTillaart/SRF05 @.***> wrote:

A quick look makes it seem to be straightforward. In my mind I had a plan to use Trigger ==echo as Singlepin condition. (Saves 1 byre wow)

Could you add an example (copy & modify) how to use the single pin interface? Would be appreciated

-- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services @.*** -- Webhosting Services

[RobertPHeller]

I am designing a robot for a class and started running out of I/O pins and looking for ways to optimize pin usage,,,

At Wed, 07 Feb 2024 12:02:06 -0800 RobTillaart/SRF05 @.***> wrote:

Thanks for the PR, This one was in the top of my todo list. Quite curious if it performs better or ... I wil dive into it later this week to review

Thanks again

-- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services @.*** -- Webhosting Services

[RobTillaart]

Looks good to me, I wait for "green light" of your hardware tests to merge.

[RobTillaart]

Reviewed it again and the changes seem perfect, so I will merge. Will update the readme.md and create a new release.

Again thanks for improving this library!

[RobTillaart]

@RobertPHeller

Question, the underlying pulseIn() function has a hard coded timeout of 300 milliseconds. Would it add value to make this configurable? Should definitely be smaller as 0.3 second == 100 meters so 50 meter forth and back for sensors that do max 15 meter? imho it can be reduced to at 200000 us without problem.

In the case of robots, I can imagine that when you expect small distances the timeout could be smaller and when you expect larger distances (or have no expectation) you use larger timeouts .

1 millisecond timeout would imply max 15 cm (0.5 feet) 5 ms TO ==> max 75 cm (2.5 feet) 10 ms TO => max 150 cm (1.6 yard) 20 ms TO ==> max 300 cm (3.3 yard) 30 ms TO ==> max 450 cm 40 ms TO ==> max 600 cm (6.6 yard) 50 ms TO ==> max 750 cm (8.2 yard) 60 ms TO ==> max 900 cm (10 yard) 100 ms TO ==> max 15 meter (17 yard)

Opinion?

[RobertPHeller]

According to the specification of the SRF05 (www.robot-electronics.co.uk/htm/srf05tech.htm) the sensor times out after 30ms and has a max range of 4 meters, so the max pulse width is 30ms. I don't think messing with pulseIn's timeout will make any difference, unless the sensor is broken or missing (broken connection).

At Thu, 08 Feb 2024 08:37:16 -0800 RobTillaart/SRF05 @.***> wrote:

@RobertPHeller

Question, the underlying pulseIn() function has a hard coded timeout of 300 milliseconds. Would it add value to make this configurable? Should definitely be smaller as 0.3 second == 100 meters so 50 meter forth and back for sensors that do max 15 meter? imho it can be reduced to at 200000 us without problem.

In the case of robots, I can imagine that when you expect small distances the timeout could be smaller and when you expect larger distances (or have no expectation) you use larger timeouts .

1 millisecond timeout would imply max 15 cm (0.5 feet) 5 ms TO ==> max 75 cm (2.5 feet) 10 ms TO => max 150 cm (1.6 yard) 20 ms TO ==> max 300 cm (3.3 yard) 30 ms TO ==> max 450 cm 40 ms TO ==> max 600 cm (6.6 yard) 50 ms TO ==> max 750 cm (8.2 yard) 60 ms TO ==> max 900 cm (10 yard) 100 ms TO ==> max 15 meter (17 yard)

Opinion?

-- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services @.*** -- Webhosting Services

[RobTillaart]

OK, thanks for your remarks, Given it is 30 ms means that the current 300 ms is overkill, 100 ms should be sufficient.

why I ask is that the timeout is typically needed when there is no echo at all.

• send pulse error (hardware failure)
• receive pulse error (hardware failure)
• absorbing wall
• wall under angle ==> sideways reflection
• unexpected medium, has other speed of sound

PS, a new develop branch + PR for version 0.3.0 is in progress

[RobTillaart]

@RobertPHeller Just released the 0.3.0 version including your single pin code, Thanks again

[RobertPHeller]

Do you know how long it will take to become available from the Arduino IDE Library manager?

At Sat, 10 Feb 2024 04:16:42 -0800 RobTillaart/SRF05 @.***> wrote:

@RobertPHeller Just released the 0.3.0 version including your single pin code, Thanks again

-- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services @.*** -- Webhosting Services

[RobTillaart]

@RobertPHeller Normally in less than six hours, longest I can remember was a weekend due to maintenance.

[RobTillaart]

In fact I cannot see when a new version of one of my libraries is available as I have the latest or am ahead of the library manager.