Show Posts
Pages: [1] 2 3 ... 7
1  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
2  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

Quote
Screws to hold it closed?

Yup, 6 bolts hold the back cover on.

Quote
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.
3  Using Arduino / Project Guidance / Re: Automotive Compression Tester on: April 10, 2014, 06:33:01 pm
CONNECTOR UPDATE
 
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 it...an 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...
4  Using Arduino / Project Guidance / Re: Automotive Compression Tester on: April 10, 2014, 06:31:52 pm
KEYPAD UPDATE
 
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.
5  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.
6  Using Arduino / Project Guidance / Re: Automotive Compression Tester on: March 26, 2014, 06:47:12 pm
CONNECTORS

Connectors.  Aye-chemanga.  These little critters are developing into a real problem for me in this project, given my relative lack of experience with them.  Therefore I am asking openly for help/suggestions in this area; this is an open call.  Now for a little background.

Essentially there are two types of connectors in this project:

1) PCB connectors.  These will be used to connect the 3-wire analog inputs (of which there will be a minimum of 1, maximum of 4) to board, the LCD, pots, and ON/OFF pushbutton to the board, the 8-pin membrane keypad to the board and finally the serial interface to the board.  Thus there are 4 in total.  The number of pins varies from 3 to 21.  Originally I had planned on implementing this via ribbon cable and ribbon cable connectors.  But several of these are single-row headers and they don't make single-row ribbon cable connectors.  Saw a couple of ideas for friction headers with a matching female counterpart, so I'm looking into that now.  Basically what I need here is the ability to connect stuff to the board securely such that the electrical connections are solid and reliable.

2) Cable connectors.  I'll need one pair of these (male/female) to serve as the connector between the cable that extends from the enclosure to the transducer.  This connector is necessary because as you are screwing the transducer and its adapter into the spark plug hole, you don't want this long cable extending from the transducer that will become twisted and a real pain to deal with.  So you break the cable into two parts: one that is quite short and that connects the transducer to one connector, then the second that is much longer and that will extend into your enclosure.  Then after you finish running the adapter/transducer fully into the spark plug hole, you connect the two cables and now the analog values can be sent to the uC.  As I mentioned in the previous post, I need this to be able to be done with one hand and blind, so that if you have very little room to twist the adapter/transducer into place, you can do that reliably.  And you can do it reliably because you can feel how the connectors are supposed to go together, once you put them together they stay that way, and then when you want them to separate, they do.  Seems like a tall order somehow.

Anyway, any and all feedback is greatly appreciated.

Thanks!
7  Using Arduino / Project Guidance / Re: Automotive Compression Tester on: March 26, 2014, 06:26:50 pm
QUICK UPDATE

Apologies if this is TMI, but with the notion of sticking to my word to keep things updated, here is the latest.

I picked up the new devel boards from the assembly house this week. They look good, better than the previous outfit. Will test them over the weekend. Discussed ideas regarding the best approach to cabling. I'd like to have a way that would enable the end user to connect the cables with only one hand, while not being able to see what they're doing, to have it remain solidly connected, then to easily be disconnected with only one hand at the conclusion of the test. This was how my tester was broken in the first place, dontchaknow. lol So I'm working on that. See the next post.

Received the latest enclosure and keypad drawings back from the designers. Pictures are attached. Enclosure is getting there, keypad is almost done, but I would like more colors on the keys, just not sure what and where. Gotta think about it over the weekend too.

Somehow or another I completely spaced the fact that users will need some way of setting the real time clock, kind like your alarm or the clock in the dash of your car.  So I added yet another option in the config menu to enable users to set the clock's date and time. The drift of the RTC will vary depending on a few factors, but it won't be much. The battery I use will last many years. Still there does need to be a way to set it, and now that exists.

Also added even yet another option to enable the user to define an engine's data analysis metrics, such as rated CU pressure and max differential pressure between CUs. I have all of the numbers for the rotary engines pre-defined of course, this is more for the piston/diesel stuff. This option was added in support of my effort to polish off the diagnostic code.

Anyway that's where things are.

Thanks
8  Using Arduino / Project Guidance / Re: External power Changing my AnalogRead on: March 26, 2014, 02:16:17 pm
If the best accuracy possible is required there are several methods of obtaining a more stable reference voltage as some expense but then again if accuracy is a paramount importance then using an external higher quality I2C or SPI ADC chip is a better solution. The arduino 10 bit analog converter is a very handy and useful feature but should never be confused with instrumentation quality ADC capabilities.

Here is a nice ADC module that will give better results then the AVR's build in ADC ever will.

http://www.adafruit.com/products/1083

Lefty

Lefty,

I have been looking at this chip to use as an external ADC:

http://www.mouser.com/ProductDetail/Maxim-Integrated/MAX11628EEE+/?qs=sGAEpiMZZMvTvDTV69d2Qr5vlFElGnRqZFqdmXmkqiA%3d

In your opinion, would it be in the same ballpark as the ADS1105 that is found on that Adafruit breakout?

Thanks!
9  Using Arduino / Project Guidance / Re: Automotive Compression Tester on: March 07, 2014, 03:36:33 pm
PCB update:

The meeting went well this morning with the new assembly house. They're located in one of the old Dell buildings and seem to have a good operation. I've contracted with them to build the final development boards and we have a tenative agreement regarding deployment board production, but I am holding off just a bit on fully committing to that until I see how they do with the devel stuff. Anyway, it looks promising; and it includes a noticeable per-board price reduction. So we'll see. They'll have the final devel boards ready next week.

Thanks
10  Using Arduino / Project Guidance / Re: Automotive Compression Tester on: March 07, 2014, 03:36:02 pm
Ok I have an updated design from the custom enclosure folk. This one is better, but I don't like the knobs being so close together and the pushbutton for ON/OFF device power is on the left when I had requested that it be on the right. They're gonna correct that for the next design iteration.

Anyway, feedback is welcomed.

Thanks!
11  Using Arduino / Project Guidance / Re: Automotive Compression Tester on: March 05, 2014, 05:02:39 pm
Quick update:

I completed the config/menuing code last night, to include the calibration/reference/static test stuff as mentioned in my previous post. In the end there are 15 option displays that the user will be able to play with. These are those options. Unless something pressing arises, I am going to try to do a feature freeze on this stuff. That's the plan anyway. So. The following will go out in the first release:

Default mode - Mode to jump to at startup
Default log data - Whether or not data logging is enabled at startup
Units - Measurement unit in which to express the compression readings
Engine - Engine being tested
Pressure Altitude - PA at which test is conducted
Auto Shutdown - Whether or not to enable auto shutdown
Auto Shutdown Seconds - Number of seconds of inactivity to shutdown if enabled
Active CUs - Number of CUs being tested
CU Map - Analog channel to CU map
Pin Mode - Whether or not to enable PIN mode
Pin Data - Your PIN if enabled
Transducer Offset/Zero-point - The ADC value that is considered to be 0 PSI
Transducer Max PSI - The standard pressure limit of the transducer being used
Save Parameters - Save all of the above options to FRAM
Transducer/ADC Calibration - Test page to read the input of a given channel and display the result

Although there were/are a number of menuing systems available for character LCDs via the forum, none of them would work for my application for one reason or another, so I had to write mine from scratch.  No big deal, just took a little longer.  Arguably.

Now to polish off the diagnostic code...

Thanks
12  Using Arduino / Project Guidance / Re: Automotive Compression Tester on: February 20, 2014, 02:27:57 am
Y'all-
 
Had a conference with the custom enclosure folk today. Asked for a JPEG of the design as it currently exists. So in keeping with my word to post any decent amount of progress, I thought I'd give y'all a glimpse of what it will look like. Mind you, this is just a CAD drawing. The actual enclosure will be made of 4mil ABS plastic, black in color. It'll have silkscreening on it from-the-factory so that you'll know what everything means/is/does. Neither of those is shown in this picture. Also, there are a few features that the design engineer simply hadn't had time to get around to yet, such as side indentations for grip, front face decorative trim and correctly sizing/spacing the rheostat and ON/OFF pushbutton holes, to mention just a few. Overall this design isn't quite what I wanted but given the limitations of their manufacturing process (no injection molding) it's a pretty decent result really. Still a little ways to go, but we're on track to what I had come up with several months ago.
 
Anyway this is where it is at the moment. Feedback is welcomed.
13  Using Arduino / Project Guidance / Re: Automotive Compression Tester on: January 16, 2014, 02:00:49 am
Well hmmmm....I'm not concerned so much with cloning as I am with warranty claims that arise from what I call stupid-use.  I agree that the cloning thing is likely a non-issue because it wouldn't be worth the time required to go down that road.  But the ease with which a buddy of mine trashed my first board worries me a bit.  So I'll protect myself in a reasonable way against that.  Sure, I could use something other than male pin headers.  I have thought of using female headers, but you can insert a wire into those rather easily and do the same type of damage.  I had also thought of deleting the unused headers entirely from the production version of the PCB, but then I wouldn't have the test points to use in future diagnostics.  However, realistically, I don't know how likely that will be.  So I dunno.  I'll look for the food grade labels and tamper resistant stickers when the time comes.

I'm not quite there yet, unfortunately.  I'm still working with the custom enclosure folk to finalize the design.  It's coming along, but I'm running up against a height issue.  It just seems out of proportion somehow.  It's about 9.5 inches in height, which seems a bit large for a hand held device.  But I took the dimensions of the device and searched through the Hammond website.  I found a comparably sized hand held and the numbers were actually quite similar.  The link:

http://www.hammondmfg.com/dwg7.htm

I also have a few odds and ends to finish up in the software, mostly dealing with the options processing stuff.

Ok so I ran the Integer versus Floating point math profile.  I found a newer version of the same thing that I ran back in the day and loaded that onto my 1284.  I don't know how much I trust the results however.  They seemed reasonable upon first blush, so maybe they are ok.  'Not familiar enough with these boards.  But the numbers showed that add, subtract and multiply were 5 times faster for a short versus a float, but the float divide was completed in half the time of a short.  That said, I think I can afford the expense, but can't say that for certain just yet.  I have a need to report pressure values down to a tenth of a PSI, so I'll go in that direction unless it's just prohibitively expensive to do so.  We'll see.

Thanks!
14  Using Arduino / Project Guidance / Re: Automotive Compression Tester on: January 03, 2014, 12:59:46 pm
Standard tamper-evident seals would seem like a sensible solution then - to make it clear to the consumer that they're expected not to fiddle with the insides, and if they do so it's at their risk.

Yeah those were my first thought, just not sure how easy or difficult they'd be to replicate.  I also couldn't find any "small ones" but only spent about 5 minutes or so Googl'ing it, so with a little more effort, I think they'd be in hand without too much of a problem, should I go that route.  Thanks for the tip.

And it may not be a problem.  I am just trying to help you make valid comparisons so you don't find yourself in a bind.

I appreciate all of the help and expertise CB, thanks!  I went back and drudged up and old profile that I used back-in-the-day when working on a new platform; I'll run that and see what happens.

Quote
Serial numbers can be a poor choice.  It is extremely easy for a person to guess the previous, next, and potentially all of the valid values.  (I speak from experience.  In a previous life I caught people stealing from my employer by guessing serial numbers.)  A "hash" value works much better.  You can even use an Arduino to generate the values...
http://forum.arduino.cc/index.php?topic=205339.0

Hmmmm....interesting, thanks.  Well, in my case I had planned on assigning non-sequential, randomly-generated serial numbers to each unit, much like license keys.  In a way.  So you'd be hard pressed to guess a serial number.  And heck, being the peaceful, conservative, law-obiding type that I am I don't even know what you would do with a guessed serial number to try to steal something, as you mentioned.  But I digress...

Quote
However, we were just selling software.  Other than someone cloning your physical device I can't think of a way to cheat you using serial numbers.

I cannot imagine it either and hadn't even given it a thought, as I alluded to above.  Perhaps it is *very* good that we're having this discussion!  smiley-grin

Quote
How do you picture the serial numbers being used?  Customer calls you for help then you ask for a serial number?  Customer sends the device to you and you download the serial number for verification?

No calls, but will answer email.  Your third question was more along the lines of what I was thinking.  The serial number would be used to uniquely identify each device and thereby which version of hardware/software was installed on it when it left the "factory".  If that couldn't be verified, then the warranty could be voided if any type of tampering was evident.  And when I install software updates, I'd modify the DB accordingly.  Versioning is a key issue when dealing with customer complaints and I don't know of a better way of knowing exactly what the user/customer has - or *should* have - than to use serial numbers.

Quote
It's going to get worse.  There are even more questions floating in my head.   smiley-evil

That's a good thing, I welcome your expertise and feedback as well as anyone else's.  I'll have a better product in the end as a result.

Quote
Three things to consider when shopping for anti-tamper solutions...
1. Anti-tamper tape may not adhere well / at all to plastic.
2. I have successfully replaced "void" tape.  It requires a steady cautious hand but it can be done.
3. I suspect a custom made (you could probably make it yourself) wax seal would work well.  It would not be worth the cost to replicate, it would be easy for you to apply, if you choose the melting point carefully / use solvent soluble wax, it may be easy to remove, and it would add an aura of quality and authenticity to the device.

Sounds like some experimenting is in order here.  I don't know anything about wax seals.  Have any examples?  I had thought of using hot glue to keep the headers on the pins and doing so would serve as an extra tampering-deterrent in that if I didn't see the hot glue then I could be reasonably assured that something was up.

BTW, I forgot to mention that the whole notion of tampering arose from a very real world experience.  Or at least in part it arose from it, but whichever.  A buddy was over and I had showed him my very first board.  I went to get something and heard him say "where do you connect the battery again?" only to turn my head and see that he had connected it up to one of my other male pin headers, ergo it was *not* the +9V header!  It only took about 2 seconds for smoke to begin emitting from the board.  Needless to say it was trashed at that point, heck I couldn't even load the blink sketch anymore.  So that made me think about protecting things a little bit better than to simply leave open/exposed male pin headers lying around.  I almost removed them from the final design altogether except for the required headers such as the analog inputs, but I wanted to retain them in case I needed to debug a reported problem later on.  The pins serve as what I have come to learn are called "test points" and as such they can be useful.

But anyway.

Thanks again!
15  Using Arduino / Project Guidance / Re: Automotive Compression Tester on: January 01, 2014, 01:38:22 am
FPM stuff ... ok I will do that when I get back.  I'm travelling for the holidays and didn't bring the board with me.  Coming from a different world where FPM versus IM isn't the big issue that it once was, and therefore the whole subject has somehow glossed itself into a "non-issue" for me over the years I guess. ;-)  But this performance issue varies rather wildly from platform to platform depending on several factors ... anyway.  I'll check it out.

As PeterH touched on, the whole idea behind my interest in serial numbers (unique identification) and establishing some type of tampering detection centers mostly around the warranty that I have stated I will offer with my units.  PeterH is also correct to say that the warranty won't have significant value.  However, keep in mind that I am just "a guy in a garage" with this deal and replacing a unit because someone damaged it and then insisted on replacement has real-world consequences for me.  At this point I hope to simply break even overall, and dealing with tampered units would compromise that hope.  And the break-even point is just in terms of the R&D costs that I've incurred to this point.  It does not factor in my time whatsoever.  This was never a profit-making product idea anyway.  It was mostly an opportunity to learn and to offer a product to a limited market to fill a void.  Ergo, I'm designing this for "me and my buddies" and hope that they'll buy enough units to cover my OOP expenses.  Heck, I would never have ventured into this IRL.  There is no appreciable ROI.  I wanted to learn about y'alls world because I had heard a fair amount about it; I was curious.  Offering a product with the intention of making a profit was not really on the radar.  And I accept responsibility for that decision, which means that this isn't a complaint.  It's simply a response as to why I am trying to CMA a bit.

Boy, this all seemed so simple when I thought about it a while back.  But now y'all are asking questions that have me scratching my head.  But that's good.

Anyway, the aforementioned "simple" concept/concern that I had was that I didn't want to get into the scenario where a user opened the unit, messed around with stuff, possibly shorting a component in the process or doing other type of "damage", then returning it to me wanting a replacement/repair under the warranty.  So the thought was/is, and I admit that this is my first rodeo with this stuff, to protect everything the best I can, thereby making it reasonably obvious if someone has indeed had a good root-around and screwed something up.  Then I can void the warranty and offer repair/replacement at a cost, with the ideal scenario being to simply have them purchase a new unit.

I also will offer free software updates for the life of the product, so having a serial number would help in knowing exactly which version of hardware/software was/is installed on each unit.  I planned on keeping that information in a database and maintaining the DB as time went by.

And just to make it clear, I've spent almost no time attempting to prevent others from copying my stuff and creating their own product based on mine.  That's laughable in this context.  Kid-sister type of attacks are about all you could really hope for with these devices (or so it would seem).  As I've mentioned, the market just isn't there to support such Tom-foolery.  And good luck replicating my work ... I've spent several months now in development, spent many-a-night reading this forum until the wee-hours of the morning and have developed a somewhat involved body of code.  And I'm still a bit of a ways-away from having a finished product.

But I digress.  Thanks for the feedback, I appreciate the input!

Happy New Year to all!
Pages: [1] 2 3 ... 7