Jump to content
43oh

Ultrasonic sensor backpack


Recommended Posts

Would anybody be interested in a "backpack" for the cheap ultrasonic sensors?  I've got several of the HC-SR04 sensors from ebay, as well as a couple other kids.  They're not too difficult to use - but they require timers to figure out rise time.  Having an external backpack would allow that processing to be offloaded to another chip.

 

My first idea was a serial backpack - distance would be sent on regular intervals.  Another option would be to add a trigger pin that would be pulled high under certain circumstances (object too close, etc).  I2C and SPI would be another option - similar to an LCD backpack.  

 

Figured I'd ask for some input before starting to put the design together!

post-1690-0-05948100-1365959916_thumb.jpg

Link to post
Share on other sites
  • Replies 43
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

I'd say go for it as a one off design. If there is a breakout out there,people will use it if if means easing design time and being neat.

The keywork is "flipchip". You can get LEDs in this form, but it's also used in those resin blob el-cheapo calculators 'n stuff.

Fixed a couple of issues with unconnected pins - sent this of to OSH this morning.  Excited to give the QFN a try - but I managed to get a couple of BGA TMP006's reflowed - this shouldn't be too bad.

Posted Images

Would anybody be interested in a "backpack" for the cheap ultrasonic sensors?  I've got several of the HC-SR04 sensors from ebay, as well as a couple other kids.  They're not too difficult to use - but they require timers to figure out rise time.  Having an external backpack would allow that processing to be offloaded to another chip.

 

My first idea was a serial backpack - distance would be sent on regular intervals.  Another option would be to add a trigger pin that would be pulled high under certain circumstances (object too close, etc).  I2C and SPI would be another option - similar to an LCD backpack.  

 

Figured I'd ask for some input before starting to put the design together!

I'd say go for it as a one off design. If there is a breakout out there,people will use it if if means easing design time and being neat.

Link to post
Share on other sites

What are you thinking for external circuitry?

 

It would be great if it had support for multiple channels, which would make it handy for proximity detection with robots or quadcopters.  I also think it would be nice to have it output both the raw distance as well as have trigger channels with an adjustable trigger.  I suppose if you wanted it to be truly universal, you could output a digital trigger signal, an analog "distance" signal and have an I2C/SPI bus.  That would cover just about every use-case I can think of

Link to post
Share on other sites

Here's a first run.  It uses a QFN 2553.  I know - overkill - but I have some samples, and it has UART and comparators I'd need.  I've been itching to use them for something.

Voltage divider for converting the 5v -> 3.6v or below (10k and 20k resistors should do the trick).  Components are all SMD

 

Programming header, two LEDs (visual indicator), a trigger pin, serial output.  Should I add a second trigger pin?

 Components aren't labeled unfortunately - I was trying to keep the footprint small for a first test.

Output pin labels are on both sides - depending on how the board is oriented.

 

Cost is $2.70 from oshpark right now.  

 

@@mbeals - I like the multiple-device idea.  It would be pretty easy to set up a bank of sensors.  I'll probably do a board with a DIP chip that I'll send through Elecrow or Seeed.  I wanted to use the chip that comes extra with the LP - but it doesn't support UART.  I know RobG did jumpers on his LCD backpack to switch between modes - sounds like a good idea.

post-1690-0-35789300-1365970584_thumb.png

Eaglev1.0.zip

Link to post
Share on other sites

holy overkill mcu batman....looks good though.

 

If you have room on the backside of the board, it might be worth breaking out the rest (or at least some) of the unused pins to an SMD header.  It might also be worth adding a small 3 to 5V boost converter onboard and eliminating the external 5V connection.  I really like the REG711 for this type of thing.

 

The update rate on these sensors isn't all that high....I don't think there would be much issue requiring a timer-based serial interface.  If you did design it around a PDIP package, you could easily make it work with the 2553 as well.

Link to post
Share on other sites

I took a look at some of the USCI devices - the same timer would have to be used for the serial interface as the time for the echo, right?  I could easily swap for a 16 pin QFN if sharing the timer wouldn't be an issue.

 

I did take a look - the MSP430G2153 is pin-compatible - $1.57 @ digikey instead of $2.25 for the 2553.  I'll take a look at doing a pin-breakout - that's a good idea.  

Link to post
Share on other sites

Unless I'm mistaken, the USCI doesn't use the timer perhip, so it shouldn't interfere with capture compare.   Now...that is my impression from reading the data sheets...I haven't performed thorough testing to verify, but I have run (and adjusted) PWM on both timers of the 2553 while using the USCI UART without issue.

Link to post
Share on other sites

Unless I'm mistaken, the USCI doesn't use the timer perhip, so it shouldn't interfere with capture compare.   Now...that is my impression from reading the data sheets...I haven't performed thorough testing to verify, but I have run (and adjusted) PWM on both timers of the 2553 while using the USCI UART without issue.

Hm - can you point me towards a code sample?  The ones I downloaded from TI that use UART all use timer features, not USCI for TX/RX.  

 

Should I make the programming header SMD pads instead of PTH?  I managed to get some inexpensive pogo pins that fit into female headers nicely - it would certainly free up some board space.  

In fact - I could switch the in/out headers to alternating SMD female headers (easy enough to do with a regular header)

Link to post
Share on other sites

I don't have my code on this computer, but look in this document: http://www.glitovsky.com/Tutorialv0_3.pdf  There is a UART chapter...it is what I used to set up my code.  The example assumes the MSP430F2274, but it's still using USCI_A0.

 

I personally don't mind all SMD parts....the board is already using QFN....if you can solder that, then some alternating headers should be no problem.  I'm considering switching to TAG connect, but it really isn't all that much smaller than a 4 pin header.

Link to post
Share on other sites

I don't have my code on this computer, but look in this document: http://www.glitovsky.com/Tutorialv0_3.pdf  There is a UART chapter...it is what I used to set up my code.  The example assumes the MSP430F2274, but it's still using USCI_A0.

 

I personally don't mind all SMD parts....the board is already using QFN....if you can solder that, then some alternating headers should be no problem.  I'm considering switching to TAG connect, but it really isn't all that much smaller than a 4 pin header.

Hm - the book only covers USCI - all of the value line devices that support USCI (HW uart) are 32-pin QFN.  All of the 16-pin QFN's use USI.  This is about the only reference I found about doing UART with a USI peripheral - http://www.msp430launchpad.com/2010/08/using-usi-as-uart.html

 

I'm going to go ahead and plan on using one of the 32-pin QFNs since they're not much more than the 16-pin (about $0.40 difference at Mouser).  I'm working on routing SMD prototyping pads for P3 on the device - having some routing problems - but that'll free up once I switch all the headers to SMD.

Link to post
Share on other sites

Okay....I think I'm following you now.  The 32 pin 2553 you are using now does have USCI, but you could not swap it out to the 16 pin QFN without using a timer for the UART.  I was just reading your intentions wrong.  You could still use USI to transmit, requiring only a single CCR for RX.

 

The LED bar graph idea is pretty cool.  If board space on top is a premium, you can always use reverse mount LED's on the back.  You would just need to squeeze in a row of drills.

Link to post
Share on other sites

The LED bar graph idea is pretty cool.  If board space on top is a premium, you can always use reverse mount LED's on the back.  You would just need to squeeze in a row of drills.

I like the reverse-mount idea :)  Special LEDs or just flipped-over standard LEDs?  I have a couple of boards from OSHPark sitting around with drills for testing out reversing a regular 0805 LED - just haven't populated them.  The holes are probably too small - but it'll still give me a good idea of how it'd work out.

Link to post
Share on other sites

I know they make special reversed packages...I accidentally found them while looking for normal LEDs...but I haven't used them.  I have often wondered if you could just solder a chip LED upside down and get the same result though....so if you try it I'll be curious to see how it works out.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...