-
Raspberry Pi 3.3V verified - new design parts on order
06/19/2017 at 03:22 • 0 commentsI verified the functionality of the RPi with the new board.
This is forked from Goran Lundberg's code for the original board at https://github.com/GoranLundberg/SonarI2C-RPi
Many thanks to him for this.
I've only tweaked the code, not the docs.
Components for the first batch of th OctoSonar 2.1 are in the mail, so I should be able to bake them up next weekend.
2.1 is 2.0 with
- input pins on grid
- full re-route
- silkscreen rework
- add i2c pullups
-
2.0 eagle files on github
06/08/2017 at 00:05 • 1 commentThe 2.0 board design is up on github
I'm working on 2.1 which has the following minor tweaks
- Input connectors moved to the 0.1" grid - this will make building an automated test jig easier.
- components moved over 0.1" to make room for
- locations added for thru-hole I2C pullups
- silk screen text adjustments (bigger fonts, moved around)
- full re-route
Suggestions on what color these should be? I'm bored with green, and purple is for OSHPark prototypes. Options are:
- green
- red
- yellow
- blue
- white
- black
- purple
- matt black
- matt green
-
OctoSonar 2.0 prototype works
05/31/2017 at 01:07 • 0 commentsI have a new prototype board undergoing testing and it comes with new code
I really don't like not being able to handle the sensors that lock up (see previous log) nor do I like that even the "good" ones make you wait 200ms when they get no echo. So I reworked the echo circuitry replacing the 8-way OR gate with 8 tri-state buffers. The trick is to ignore the spec sheet where it says the trigger pulse must be 10us and assume that that is a minimum - we're already doing 240us with the I2C flap. Instead we assume that the important thing to the HC-SR04 is the falling edge, and then hold the pin down for the duration. We then use that signal to enable the tri-state buffer attached to the matching Echo signal.
So far, it seems to work - both the "good" and "bad" sensors can by cycled through on a 50ms rotation - with or without echo returns.
The really good news is that the "bad" sensors come back to life after they get a good trig-echo cycle.
Bonus feature: it *should* work with 3.3V controllers e.g. Raspberry PI, with a 3.3V VCC and separate 5V feed to power the sensors. Untested as yet, but soon....
-
Code update - improved out-of-range handling
03/14/2017 at 06:36 • 0 commentsMany thanks to @jlmyra for spotting an odd behavior with handling out-of-range incidents with sensors that hold the echo high for longer than the datasheet 37ms. This seems to be common - some of the ones I have hold it up for 200ms. I wasn't able to test this originally as I did not have a logic analyzer.
The software now pauses the loop until the interrupt pin goes low and when an OOR occurs it will retain the previous value one time before dropping to zero on the next pass. You can increase the ignore count for noisy environments.
There is also a significant part of the HC-SR04 supply that actually locks up indefinitely in an OOR situation. I'm calling these the "not good" ones. There is a very old thread about this here, and I have some of these "not good" ones which are subtly different from some "good" ones out there.
Note the lower component count and thinner silk screen. I got my "not good" ones from Banggood. Because these "not good" ones will pull the echo pin high permanently this fault will interfere with all sensors on the Octosonar. My original development units are a different board layout altogether and do not have this problem.
A workaround seems to be to add an LED and resistor in series between echo and ground on each sensor. I'm still experimenting with this to find component values that provide a consistent result. When I do I'll work that into future versions of the board.