Show Posts
Pages: [1] 2 3 ... 8
1  Using Arduino / Sensors / Re: Board air pressure sensor identification on: May 14, 2014, 01:12:10 am
Thanks John.  I had intended on having these boards assembled by a professional, so I suspect that they'd be able to put together whatever I needed.  However, since I cannot find any information regarding which parts were being used in this implementation, I decided to go for an "easier" solution; specifically one that compensation and gain have already been done for you and you can thus just plug-n-play the sensor with your uC.  To that end I found this little guy:

And it seems like it would do what I need.  I ordered one to play around with; we'll see what happens.

Thanks again for the feedback.
2  Using Arduino / Project Guidance / Re: Can it be done... Arduino-based full Digital Auto Instrument Cluster on: May 14, 2014, 12:10:41 am
Ok thank you for the feedback.  I'm interested in this project, so if I can ever finish my current one I'll look into it.  But if you make any progress, please post and let us know how it's going.

I'm currently trying to find a cost effective solution to measure air pressures via smaller sensors.  Not so easy to do.  Unfortunately.
3  Using Arduino / Sensors / Board air pressure sensor identification on: May 13, 2014, 09:13:44 pm

I have a need in a custom board design to include a small but accurate air pressure gauge.  So I bought an inexpensive variant from a big box store and tore it apart to take a look.  Here is the product:

It is advertised as having a pressure range from 1 - 150 PSI.  Attached are the pictures after I took it apart.  I couldn't find any part number data on it anywhere.  There was a rubber o-ring on the underside and a glob of some kind of tacky substance, don't know what it was.  I looked through Mouser but couldn't find this sensor.  Anyone have familiarity with these?  Or anything similar?

4  Using Arduino / Project Guidance / Re: Can it be done... Arduino-based full Digital Auto Instrument Cluster on: May 11, 2014, 11:16:03 pm

How did this project end up?  Have any additional information to share?  I'm interested in this!

5  Using Arduino / Project Guidance / Re: Arduino digital pressure gauge on: May 11, 2014, 10:57:17 pm

What is the latest with this project?  Did you get something to work?  What was your design?

6  Using Arduino / Sensors / Re: hacked air pressure sesor on: May 11, 2014, 10:56:41 pm

Did you end up getting this to work?  What was the design and result?

7  Using Arduino / Project Guidance / Re: Digital Gauges on: May 11, 2014, 10:48:45 pm
What ended up happening with this project?

8  Using Arduino / Networking, Protocols, and Devices / Re: Bluetooth confusion on: May 09, 2014, 11:50:12 am
Hi Nick,

Well no, I have a reason why I am investigating how to send data to the BC417 through the SPI bus as opposed to the serial option of TX/RX.  That reason why is because I am making custom breakout already and I'd like to add this functionality to that breakout.  If I use an off-the-shelf product like the one shown above I'd need yet another header to interface with that second breakout, and I just don't have space on my board for it.  Said another way, I have room to add one header for one breakout.  So I'd like to combine functionality into that breakout.

So if anyone has any answers to the questions I posed, I'd be grateful for the feedback.

9  Using Arduino / Networking, Protocols, and Devices / Bluetooth confusion on: May 09, 2014, 12:24:21 am

I have a need to provide a BT capability on a custom breakout.  This breakout will connect to my custom Arduino board through a standard header.  I have been doing some research on the subject for a few days now.  During the past day or so that work has led me to more confusion than anything else.  So I thought I'd ask the forum for some clarity.  I need to get a game plan together asap.

I have customers with older smartphones who will want to use those devices to communicate with my Arduino board.  Thus from what I have learned either an HC-05 or HC-06 would be a good approach.  That would involve a simple 4-pin connector with TX, RX, +5V and GND (plus some circuitry).  This is an example:

However as I mentioned I'm developing a custom breakout and so I thought of utilizing this instead:

Either way the CSR BC417 chip is being used.  I noted that communication occurs over serial (TX/RX), even though the BC417 has SPI pins.  I read a few websites that stated something along the lines of needing a custom driver (whatever that meant) to communicate with the BC417 via SPI.  Also that an expensive license is involved.  However I couldn't seem to find any information that would allow me to understand anything further than that.

So does anyone know?  Can I communicate with the BC417 via SPI simply by connecting it to the SPI bus from my primary Ardunio board?  What's the story with this special driver and IDE and licensing?

10  Using Arduino / Project Guidance / Re: Automotive Compression Tester on: April 22, 2014, 05:16:28 pm

Connectors: resolved the board connectors, have sent the prod board data to the manufacturer/assembly house for quoting. Can't find any smaller panel mount connectors, so I am investigating a squid-type solution, though I don't know how well that would hold up over time. Still working on the inline connector.

Met with my machinist buddy who makes the adapters for me. It's been a while since I have been to his shop. So we reviewed everything Friday after work. The transducers I use terminate in a cable on one end and a 1/4" NPT male thread on the other. So the adapter needs to be 1/4" NPT female and 14mm male. The first few he made worked correctly, but I wanted a little modification. The threading of the adapter onto the transducer didn't allow the top of the adapter to mate up against the bottom of the housing of the transducer. Ergo, it didn't "thread itself all the way on." While technically correct in the sense that NPT threads seal on the thread and not the mating of the respective housings against each other, I need to do exactly that in order to reduce dead volume (even if only by a small amount) and also it just looks weird if the adapter doesn't screw onto the transducer fully - even if it is technically correct and will make a good seal. Therefore I requested that he modify the design such that the thread seal and the o-ring seal of the two housings occur simultaneously. It'll be tricky to get right, but with some experiementation on his part, he'll make it happen. Finally, I left a spare rotor housing with him for verification purposes against the go/no-go gauge that we bought for the project.

As a side note, I also spoke with him regarding another feature of the tester that I've had in mind almost since the beginning. So he is off working up a sample of that too. Anyway, the point is that the machinist aspect of the project is still where it needs to be to go into production with the device as a whole. He is capable of manufacturing lots of these critters.

BTW, does anyone know much about suction cups?

Thank you for reading.
11  Using Arduino / Project Guidance / Re: Automotive Compression Tester on: April 11, 2014, 12:57:46 am
PCB update:
The meeting went well this morning with the new assembly house.

Are they programming the processor or is that something you will do?

As of now I will do that plus run my regression suite (21 distinct programs/tests to verify 15 feature set elements).  I discussed the idea of programming the uC after assembly so that if something wasn't working properly they could correct it prior to me taking delivery.  Their response was "sure, for an hourly rate and you provide us all of the materials."  While reasonable in the general sense, I thought that in the beginning at least I'd just perform that function, if only to keep costs down for the time being.  The idea then is that if the product "takes off" (which I'm not expecting) and I can't keep up with demand (hah!) then I could always farm that out at that point.  So....we'll see.

But in a way I'm glad I'm doing it, that way I know it's done right.  Oh there I go again...don't get me started.  Yes, I do realize that with a proper checklist and the right tools, they could do an adequate job.

I digress.  Big time. lol
12  Using Arduino / Project Guidance / Re: Automotive Compression Tester on: April 11, 2014, 12:52:05 am
What's the light blue rectangle?  It's gone from the latest image.  Never mind.

Not sure which rectangle you're referring to; I went back and took a look at the 2/20 picture; the large blue rectangle is the LCD, the small outline rectangle is some leftover from the CAD program; the designer took a snapshot and that was in there for whatever reason.  But it's not a part of the enclosure. smiley

Screws to hold it closed?

Yup, 6 bolts hold the back cover on.

Is the enclosure vented?

Yup, if you look at the enclosure as shown on 3/26, the "black lines" (for lack of a better term) on the side (on both sides actually) are vent holes.  The designer came up with the varying line length idea to create an overall shape to the vent holes (if you will).  My plan was/is to simply glue a filter of some sort on the inside of the enclosure to keep dust/debris out.

Thanks for taking a look at my project again CB, I appreciate it.
13  Using Arduino / Project Guidance / Re: Automotive Compression Tester on: April 10, 2014, 06:33:01 pm
Ok I got the batch of connectors in yesterday. Generally speaking they weren't quite what I was hoping for. The Molex on-the-PCB connectors were kinda ok, but the fit didn't seem right. I have some Molex pins coming, and I'm hoping that once I have those pins in-hand it'll make the fit of the connectors better. We'll see.
Panel mount connectors. These were good, but the male connector would be a real pain to assemble every time you needed one. Quite fiddly and would require a steady hand. Also, they were bigger than I had anticipated (they were described as being smaller) so I dunno. I will need to get back with the enclosure designer and see what can be done there. Another we'll see.
In-line cable connector. This male-female pair worked pretty well. They were smaller than I was thinking they were and that's a good thing in this context. But in the end the plastic handle felt a bit cheap, as did the fitment, for reasons that I can't quite put a finger on just yet. There is a metal handle option, but with greasy-ish fingers that could add difficulty not reduce it. The real problem though was the "blind with one hand test." I think that with practice this would be do-able, but it wasn't as good as I was wanting originally. So I dunno, gonna have to explore other options I think; to include designing my own. Yet another we'll see.
Anyway that's where the connectors are. Working on electronics buddy is coming out tonight and we're gonna review some possibles...
Thank you for reading.

ps-CrossRoads has advised me to take a look at JST connectors, so I'm off to have a look-see at those.  The most applicable seem to the be wire-to-board crimp style connectors...
14  Using Arduino / Project Guidance / Re: Automotive Compression Tester on: April 10, 2014, 06:31:52 pm
Ok I received the latest design rev from the keypad folk. I had noticed that words were able to be about 6-7 characters long and still be readily visible/readable on each key, so I requested that a couple of the previously-abbreviated words be spelled out. Also, all of the keys in the rightmost column and the two keys that surround the '0' key were red. Red typically means alert/alarm/you-gotta-problem and that intrinsic meaning doesn't fit any of these keys. Therefore I requested a color change. I thought I'd try grouping-by-color and see how that went.
The keys in the right column are ordered/arranged in a specific manner to facilitate ease-of-use to the consumer. The idea is that if you start in the rightmost upper corner key and work your way down while remaining in that rightmost column, you will progress through the natural order of a compression test. That is, you first select the mode (rotary, piston, diesel), then select whether or not you want to log data to the SD card, then you press the test button to launch the worker threads that capture data from the transducer(s). You then crank for ~5 seconds, stop cranking, and then press the test button again to conclude the test. This stops the data-capture stuff. You then move to the final key in that rightmost column, which is the diagnostic key. If you press that (optional), that's when you can receive an automated 'analysis' if you will of the data stored in memory for a given engine. So it's mode-log-test-diagnose. I grouped those one color. I choose green because it indicates normal operations.
The two keys surrounding the '0' key are for menu navigation, error handling and option selection. So I chose blue for those, pretty much at random really, just not-red and not-green. Blue is also a primary color, obviously.
Anyway, attached is the result. And I dunno. If I can just speak openly and plainly without anyone getting offended, this keypad just "feels lame" somehow. Again, I dunno. Maybe it'll grow on me with time, as the phrase goes.
I thought I'd post and see if anyone has any feedback. If not that's ok, just throwin' it out there. Gotta go off and give this some cycles...
Not easy to find time for that now cause I have other things to think about, namely connectors.
15  Using Arduino / Project Guidance / Re: External power Changing my AnalogRead on: March 27, 2014, 12:27:27 pm
Ok thanks Lefty.  I appreciate the feedback.

In my case this is a custom board, so I don't want/need a breakout.  And I'm a software type, so writing my own stuff is no biggie.  If I get time I'll create a library for this chip that others can use too.

A rather extensive Google search didn't yield an Eagle library that contained this Maxim 11628 unfortunately.  I finally found something that seemed workable via the Maxim website, ran that through UltraLibrarian, which generated an unusable file to import into Eagle.  Therefore I hand edited the file to correct the issue and finally got what I needed.  Then once into Eagle, I edited the imported symbol to make it more real estate friendly on the schematic.  Anyway, the point being that those types of searches for Eagle libraries can be frustrating.  So in the interest of sharing, I am attaching the library that I created for the Max11628.

Thanks again Lefty.
Pages: [1] 2 3 ... 8