av8or1

iTrader: (4)

Hi Y'all-

Hope all is well. I am creating a new thread tonight to announce that my endeavor to build a new rotary engine compression tester is in its final stages. I am calling my version/incantation/variant by the name of JDACT RaPiD, thus the title of the thread. I'd like to give a quick background of how I got here, then move on to where things currently find themselves and finally conclude with the particulars of how I hope this journey will end up. I'll try to keep it brief, but I 'fess up front that I have the gift of gab (or some deviation thereof), so...

HOW I GOT HERE

The short version is that a few years ago I bought a TR01 compression tester from John in Houston, perhaps many of you are familiar with it. I was using it to perform a compression test on a friend's car. I let him connect the unit to the rear rotor while I went back inside the workshop for ... something, don't remember now. Well he broke the tester when he attempted to get it configured. He didn't do it on purpose of course, but in the end it was broken nonetheless. But the TR01 wasn't being produced or supported (which I can understand actually), and so I had little choice but to repair it myself or go back to the old school way (conventional piston pressure gauge tester) of doing things. I don't mind using a conventional tester, but having and using a rotary-specific one is "just way better". So I wanted to keep that option available by owning one and having it in my toolbox, ready-to-go whenever I needed it. And I was glad to help other local rotary types by allowing them to use/borrow it, but at the same time I didn't want to go down this it's-broken road again. Therefore I decided not to repair my TR01 and since I wasn't going to settle for the conventional tester thing I decided to just develop one of my own. And that was the launching point of this oddysey - it was born of necessity. More virtual in this case, but I digress.

It seems worthy to note that I didn't begin this side project with the intention of making a profit from any sales that might follow. Such a notion seems kinda silly and self-serving to me, for whatever reason. No, for me, I wanted to work on this so that I could develop a device that I would want to have in my own toolbox. And if anything came after that, so be it, but whichever. I also wanted learn lotsa new stuff (which have I ever - whoa!) about microcontrollers, electronics design, etc. I am a software guy by day, so I don't have an opportunity to be involved in that type of technical arena, but I have been curious about it. Finally, I wanted to help others in the rotary community and give my buddies an alternative to breaking my unit. lol

WHERE I AM NOW

After several design changes (and accompanying "mind changes" - lol), seemingly-endless component R&D and an extended 3-month battle with an unexpected - but quite serious - health issue, I have finally completed the first prototype. Well, that is except for the enclosure, I couldn't find a commercial-off-the-shelf offering that looked "professional enough" and that would cleanly house the components that comprise the device. So I am working with an enclosure guy to develop a custom box. And that is the primary reason that I don't have any static pictures of the device at this point. No enclosure. I'll post pictures and perhaps a video as soon as I have something presentable to offer.

HOW I HOPE TO FINISH

First and foremost is that I am happy with the initial testing. More is to follow of course, but I'd like to have a production version ready by the end of the year. Obstacles remain, the biggest of which is a requirement that I have maintained since the outset and that is to develop a device for as low of a cost as I can. I'm trying to stay under the beverage-beer-spending-budget-so-I-don't-need-to-tell-the-other-half line in the sand. While producing an accurate instrumentation tool. And a tool that is reliable. And good quality. And that uses good materials and components. And that looks at least halfway "professional." And that meets the additional requirements that I decided to pursue. And that is something I want in my own toolbox. A monolithic challenge it has been, no doubt. Cost has made several design decisions for me, but that's been part of the fun really: working through the engineering, design and project management challenges that such an endeavor presents. Anyway, we'll see.

So there it is, my announcement. JDACT RaPiD. FYI, after coming through the health thing, I'm more determined to finish than I was in March or April or whenever it was that I started down this road. I can actually see the light at the end of the tunnel WRT this project, and being able to see that light is a wonderful thing! I haven't touched my cars in a while now and would like to get back to that instead of working on this "side project". Soon. Hopefully soon.

I may post more detailed information in a few minutes, for those who might be curious. Thank you for reading!

Best,

Jerry

Tom93R1

iTrader: (2)

Good project, interested to see what it looks like.

I don't know if you have a Fry's close by, but I was in there the other day and saw they have extruded aluminum enclosures that might be professional enough looking for your needs.

av8or1

iTrader: (4)

It's raining outside, so I cannot go for my nightly run at the moment.

Here's a few of the technical notes that I made back in April or so regarding the development of a new tester. This is more of a "features list" if you will rather than a design or a schematic:

• R/C components for hardware ADC signal smoothing
• Momemtary pushbutton for ON/OFF
• Automatic device shutdown after X amount of time of inactivity
• 1000 Hz sample rate minimum
• Threaded data acquistion and data store functionality separation
• Different modes to support different device capabilities
• Keypad for user input, primary consisting of mode selection
• POT controls for both LCD contrast and backlight
• Low battery warning
• FRAM data storage, primarily for device options and data analysis
• External data storage mechanism for data logging (ended up being an SD card)
• Altitude (if using PSIS transducer), dead volume and normalization corrections
• Presentation of compression readings in different units (PSI, BAR, etc.)
• PIN access
• Rudimentary diagnostic information - GUIDANCE only
• Simultaneous processing of 1 - 4 compression units (CUs)

This list is rather old, so I may need to update it later. lol

Thanks!

av8or1

iTrader: (4)

Tom93R1-

Thanks. Yeah we have a Fry's in Austin. I looked into their enclosures when I began working on the project but didn't really see anything that would work. Enclosures has ended up being a much tougher nut to crack than I ever anticipated, which has been a good learning opportunity. Standoffs were one of the primary concerns with the off-the-shelf units, amongst other things. Any one and most certainly all of those concerns in summation would yield a rather considerable time sink during production.

Thus I decided to just go custom. With that approach I receive my enclosures in the mail, remove the back cover, screw the PCB into place, close the back cover, secure it into place and done. In addition you can incorporate silkscreening on your custom box, so that comes direct-from-the-manufacturer too, which is even more convenient.

Although I don't have any static pictures yet due to the enclosure issue (and that is the reason I've delayed posting until now) I do have some early drawings to offer. They should give you a rough idea of what it will look like. The end design will most closely resemble the split-diagram picture, but the internal design has changed from when I drew that. I consolidated the different PCBs into one, save for the LCD PCB. But I digress. I chose a portait layout instead of landscape and I decided to include a hook for under-hood hanging of the device for convenience.

Anyway. Thanks again.

Jerry

av8or1

iTrader: (4)

Y'all-

Just as an FYI, I got the new rev 1.1 board back from the assembly house yesterday and began unit testing. Looks good so far. Keypad verifies, as does FRAM, serial I/O, serial programming, ICSP programming and PB on/off via the power controller. Other things left to test, but that's a good start. I've begun work in earnest with the custom enclosure guy, so with any luck I can make the end-of-the-year goal. We'll see.

Anyway, thanks

av8or1

iTrader: (4)

QUICK UPDATE

Hi - hope everyone's holiday was good. Thought I'd give a quick report. I received the new boards late last week, they look good. Turned a couple over to the assembly guy today at lunch. It'll be ready on Monday. These new boards have the corrected shift registers, new tracing, reversed power controller output logic and a different set of LEDs for the system status stuff.

That said I have continued working on the final development of one of the aspects of the device that drew my attention way-o-way back in the beginning. That's been kinda fun to work on and I would welcome feedback from other rotary types/end users; but I suppose that is a little further down the road.

Finally, I received the new transducer that I will likely utilize as the base-model variant. It's a rugged, heavy-duty industrial transducer made of 316SS. The only thing I don't like about it is that it's a sealed gauge transducer (PSIS) and so the altitude variation will have to be compensated for in software. wcs (rx8 forum) posted that chart some time ago, unknown reference, but from my research on the matter it's accurate. I would have preferred to utilize a gauge transducer (PSIG) so that the pressure altitude is compensated for automatically (no need for the software to do anything), but I just couldn't find a gauge transducer that met my quality standards for a price that would allow the ultimate end product to be attractive to its intended audience. That said, I do plan to offer a gauge transducer option, though for a slightly higher cost. Ergo, let the end user make that decision. The reality is that the difference between the two options will be quite small, if existent, once the altitude deviation is accounted for in software. I plan to put some hard numbers to that assertion, probably over the weekend. We'll see.

So that's where things are. Unfortunately the custom enclosure guy is flaking on me at present. Dunno if he's just swamped or what, but I am investigating other custom enclosure options as I write this post.

Thanks,

Jerry

av8or1

iTrader: (4)

I am picking up the newest board from the assembler guy today. Kinda exciting because barring any unforseen and substantial issue that I encounter during the upcoming testing, I think this will be the final design for version 1.1.

I've been excited to work on this stuff for the past few days because I am finally getting to one aspect of the project that interested me the most from the outset: the diagnostic/heuristic stuff. Yeah, that's right, you heard me. One feature of my tester is that it will provide diagnostic information, to be used as guidance ONLY and such information will ONLY be displayed if you ask to see that information (by pressing the DIAG button), based on the data collected during a given run.

The aforementioned data from a given run is first corrected for dead volume and altitude variance. It is then normalized. So no more need to go to other websites or apps to correct your data. I didn't understand one aspect of that anyway, but I digress. Finally, conclusions are then drawn regarding the max/min peaks observed, the difference between those peaks (chamber-to-chamber variance), seal integrity and finally rotor-to-rotor variance, should multiple sensors be used simultaneously or if you elect to save-off the data from one run for comparison against a subsequent run; ergo you are only using one transducer. Again, this information is only available if you request it via a button press, so don't sweat the issue of extraneous information being unwillingly piped down your throat. Because it isn't and won't be.

The RX8 stuff is actually easier because the chart offers a minimum and a standard. Therfore developing a grading scheme off of that is easier than my RX7 stuff, which only offers a minimum on its chart. Fortunately I have a fair amount of experience with the RX7 engines, so I have a roughly-good idea of what should be considered an 'A' engine versus 'B' and on down the line. I am open to feedback from all rotary owners who've messed with that stuff in the past however, so if you have something you'd like to offer, please speak up. I will offer free software updates for the life of the product (you'd have to send me your unit to get the upgrade, but might offer a way to upgrade the software on your own if you are tech-savvy and brave enough to try it - lol) but this is the time to get your feedback included in the initial version. :-)

So there it is. One of the aspects/features of my device that I didn't see in others and that I wanted to include from the outset. And that is only one of the features that I have been holding back mention of to-date. Now that one cat is out of the bag, let 'er loose...I'm expecting the beginning of the avalanche of criticism, but that's ok, bring it on. lol :-)

And the new enclosure folk seem promising, but we'll see. Keeping fingers crossed on that one. Who could have predicted that would be such a pain in the tail? lol

Anyway, thanks.

av8or1

iTrader: (4)

Ok so here is the post I've been dreading: a somewhat full description of my product. I've been avoiding it to-date simply because of the avalanche of criticism that I anticipate receiving. No big deal really, so if you have something to contribute, let 'er rip.

And with that caveat I won't delay any further. To make the announcement rather bluntly and to-the-point, my tester is designed to perform tests on all internal combustion engines, not just rotary. This is the reason you don't see the word "rotary" in JDACT RaPiD like you do in the names of the other compression testers. It is also the reason for the additional complexity and thus longer development time. And yes, you heard that correctly, my tool will work for non-rotary engines too. To put it in even simpler terms: my tester will display, log and analyze data from the compression tests of all internal-combustion engine variants, rotary, piston and diesel. Thus the name "RaPiD" - Rotary-Piston-Diesel. With an a and an i inserted to make a somewhat relevantly named title RaPiD.

Whew. There it is. I've said it. Feels like a tremendously heavy weight has been lifted off of my shoulders - lol! Before you ask, yes, I do have a plan on how the "mechanics" of all that will work. It isn't that hard to imagine when you think about it really but I'll save those details for another time. It's lunch and I've got to get back to work. Three consecutive posts is enough for now.

Let me leave you with a quick background of how I came to this idea. As I mentioned in the early posts of this thread, some time ago I ran into a problem with the TR-01 (as described in my first post). And so I decided to make my own. Way, way, way, way early on when I sat down in my workshop to think about what I'd wanna make, I immediately decided that I didn't wanna produce "just another rotary engine compression tester." I wanted to do more. I wanted to do some original, distinctive work. I wanted to do something that appealed to me and it had to be a tool that would produce accurate information/results. It couldn't just be "a toy." I wanted to learn and explore, to push the envelope a bit. And if I couldn't do all of those things then I wouldn't do anything at all. There was another tester already out there at the time (Rotary Diagnostics or RD as I'll refer to it) and John was promising to offer an updated version of his TR product. So it had to be something different. Something more.

At that point I knew I wanted to produce a tester that could be used on all of my vehicles regardless of engine type. Thus I'd only need one product to meet all of my "compression testing" needs, if you will. Sure, this type of electronically-based product didn't (and doesn't) make much sense in the context of an entirely exclusive piston and/or diesel application, but hell if you're gonna purchase one for your rotary anyway, then why not be able to use it on your other hardware too? That was the general notion with which I launched my development efforts. And it is this notion that drove many of the various decisions that I made during the overall project's planning, development and execution. And yes, I have tested this on one of my piston engines and on a friend's diesel (I hadn't yet bought my F350 at the time). It works just fine, though clearly you need a transducer with a higher pressure rating for the diesel application.

But I digress.

Y'all I could talk all day about this project. It has consumed a large part of my life and kept me from working on my cars, which I have not been liking as of late. Therefore I am the most motivated than I've ever been to finish the thing and get back to what I want to do with my free time, which is working on my project cars.

I digress again.

Hack away if you will/must. I will close by stating - yet again - that this was never about profit but rather about the engineering and technical challenge of producing a "really cool tool." If it wasn't for that aspect of the project, to include the diagnostic software, I would never have ventured down the long and thorny path that has lead me to where I am today.

Gotta go. Y'all take care.

Jerry

av8or1

iTrader: (4)

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.

av8or1

iTrader: (4)

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

Now to polish off the diagnostic code...

Thanks

av8or1

iTrader: (4)

Ok I have an updated design from the custom enclosure folk. This one is better, but I don't like the ***** 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!

av8or1

iTrader: (4)

I got a few questions regarding accuracy on the RX8club forum, so I thought I'd post my response here too. Thanks
---------------------------------
Omega8-

Eh no problem, I'm just keeping my word of posting more updates. And I understand the work thing. Gotta do that myself. :yesnod: It slows me down on my side stuff sometimes, but that's life. lol

Yeah I agree with your concern regarding accuracy. I am doing everything I can think of to maximize the accuracy of my device. But in the end I'll let the testing prove things out one way or another. As I mentioned, I have designed the thing from the ground-up with a few critical factors in mind. Accuracy was at the top of my list. Cost came a close second. I suspect that the other guys who've produced their own versions tried for good accuracy as well. But I won't speak for them; I'm just concentrating on my own stuff.

Anyway, my test plan includes a test against the Mazda factory tester via my buddy at the dealership. *And* I just happened across a guy in San Antonio who has the RD tester. For a fee he's willing to come up and run a test with that. So I've included that and my old TR-01 the test plan as well.

Ok WTH. Here are my abbreviated notes regarding the issue of accuracy. And by abbreviated I mean that I am intentionally omitting all discussion of accuracy errors WRT 1) ADC error, and 2) Storage error. And I'll only touch on 3) representation error. With that said, there seem to be two other central issues at work:

1) Accuracy relative to a known source pressure. I call this transducer error and it has a few wrinkles involved with it, but you could summarize them by saying that this error represents the pressure difference that the transducer produces relative to a known static pressure source. My plan to alleviate this error is three-fold actually. The first aspect is to use high-quality, "heavy-duty", stainless steel, "rugged industrial" transducers with the lowest internal accuracy error possible. And it's that last item that is key. For most applications the low internal accuracy attribute really isn't necessary. And I'm not convinced that it'll make much of a difference in this application either, but again, I'll let the numbers tell the story in the end. The second aspect of my plan to combat accuracy issues involves the calibration page that I mentioned in my last post. This page will allow the end user to connect to a known static source, see if the tester reflects the given pressure and if not adjust the ADC zero point to compensate for the difference. That only goes so far though; if the transducer is way-out-of-whack due to abuse/whatever then the calibration won't help much, but at least the end user will know the difference and they could take that difference into account when conducting their tests. Best bet would be to just get a replacement transducer in that scenario, but I digress. Finally, the third aspect of my attack-on-accuracy plan involves the standard pressure of the transducer, which has relevance to transducer resolution. There will be two approaches available: 1) Generic and 2) Engine variant specific. So let's dig into that just a bit. By default, unless the end user specifies otherwise, the transducer that will come with the unit will have a standard pressure (max normal) of 200 PSI. This is the "generic" approach if you will. I chose this number for a specific reason. That reason is that 200 PSI makes for a reasonable lowest-common-denominator, considering that my device will read and represent pressures from all engine variants. Specifically, that value (200 PSI) covers all rotary applications and most piston applications too. Of course, the problem with that in the context of the rotary application is that you lose some precision/resolution because 200 PSI is considerably higher than the max pressure that a rotary engine will produce. The tradeoff being, again, that in addition to your rotary, you can cover most all piston engines with a single transducer. By contrast to this kind-of one-size-fits-all approach, there is the engine-variant-specific concept. That is, my supplier can produce a transducer with any standard pressure (max normal pressure, not burst pressure, etc.) that I request. Therefore in the context of a rotary application I can provide a more rotary-applicable transducer with a lower standard pressure, say 140 or even 150 PSI. By so doing, you gain resolution/precision and therefore accuracy. Sure, the tradeoff is that you cannot do a lot of piston engines with that transducer, but if accuracy for your rotary is that important to you, then that might be an acceptable tradeoff. And in the end it would come down to a simple matter of cost. I plan to offer different transducers to meet different needs. The end user can buy whatever they want, then enter that number as an option in the CONFIG menu prior to conducting a compression test with that particular transducer. Then pull out a different transducer with a higher/lower standard pressure for your different engine type, plug that number into the option in the CONFIG menu and off you go, no problem. The software uses that option on-the-fly to calculate the displayed pressure. For example, my F350 PSD tops out at just over 400 PSI, so the transducer I'll use for my diesel will be around 450 (just for safe-keeping, I'll go a bit above the max). So to conclude: if to-the-nuts accuracy is monumentally paramount, then I'll provide a means for the end user to mitigate accuracy errors significantly, though perhaps at a small cost. The end user can then decide how they wanna tackle the problem.

Ok enough about that.

2) Resolution/representation error. First, does anyone have some experience with the Mazda tester? I've never laid hands on one or even seen one, but I have seen pictures. And WRT resolution, I have noticed that it represents the pressures it reads in hundreds of kPa. Therefore a 6.1 for example on that tester means 610 kPa. The next resolution step would either be 6.0 or 6.2, which is 600 and 620 kPa respectively. So the resolution appears to be 10 kPa. Well 10 kPa = 1.4503773801 PSI. While not a huge thing, there is some resolution lost there. My guess is that this type of small resolution loss wasn't considered to be significant/important by Mazda, or else they would have produced a tester with more precise resolution. As it stands it appears that their tester is able to represent pressure differences at a minimum of 1.45 PSI. I don't know what the other testers do, but I will generate pressure readings down to the nearest 10th of a PSI, which is a 14.5 times finer resolution than the Mazda tester. But again I dunno just how important that is; I mean obviously Mazda didn't think it was all that big of a deal, as I mentioned, right?

But anyway, I digress.

So that's the nickel tour. Thanks for coming. :yelrotflm

Glad that you are familiar with the other testers that are available out there. I can't help ya much though; I know nothing whatever about the RD tester and only have worked with the first version of the TR-01 product. Never even seen the second version. Good luck with it. Keep me posted, I'm interested in any and all feedback.

As for my enclosure looking like a multimeter, well that is kinda by design and kinda not. I wanted familiarity with the old (hand-held DVMM type of approach), but with new bells and whistles that the end user would need to become familiar. Standard stuff really.

OLED? Heh, no. Mine is a simple 20x4 (columnsxrows) character LCD. I chose that solely because of cost. As I mentioned several posts ago, keeping the end cost to the user as low as I could possibly make it was the second-highest goal that I had when I began designing the thing. Choosing the LCD based on cost is just one example of that. I will have a number of color variants that can come with the device though; the LCD supplier produces a number of color choices that all provide the same functionality and come with the same interface, so I will just pass that onto the end user to choose. Default will likely be black-on-green.

I don't recall the dimensions as they stand now. I was having a serious issue with height because of the size of my PCB, but IIRC I was able to reduce the total height including enclosure wall thickness to about 9.3".

Timeframe is ASAP. Know that doesn't help much, but again, if you need one right away, I'll just have to refer you to the other guys for now. I wanna finish like-tomorrow so that I can do what I really wanna do with my free time, which is to work on my cars, so believe me I am motivated. The tall pole in the let's-finish tent right now is the enclosure designers and PCB assembly house (my components are all SMT/SMD with the exception of the headers, and there's no WAY I'm gonna sit around and assemble boards like that! lol). I had to let the previous assembler guy go and am meeting with another local assembly house tomorrow at 10 am to discuss a business arrangement. The good news there is that they claim to be able to be a one-stop shopping type of outfit for my project, from board manufacturing to parts procurement to final assembly. Ultimately that would lower the overal dollars-per-board cost, which would enable me to provide an even-lower final cost to the end user. All of that is TBD right now, we'll see. But as I've already stated multiple times (forgive the repeat), this is not about profit for me. Hell I have so much in R&D costs at this point, *not* including my own time, that it's becoming obscene. But I didn't do it for $$$, which is a good thing because I'll be lucky to break even.

Anyway, I'm working on it.

Thanks

av8or1

iTrader: (4)

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. If anyone out there has any suggestions, I'm open.

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 7. Or 8, I dunno much about what is on the dash of an 8 though. lol 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

av8or1

iTrader: (4)

UPDATE

Hi y'all. Hope everyone is doing well. Just another progress installment for the thread. I've been quite busy since the last update. There's a fair amount to talk about, but once I put it into summary form it isn't really all that lengthy.

The first and foremost important thing is that the final two development boards passed all of my regression testing. That is, of course, great news! I have 15 separate feature set elements that I evaluate during each full regression test. Those 15 elements are verified via 21 distinct regression programs. Therefore I feel confident that both the design and the board layout are ready for production.

And to that end I have spent a fair amount of the past two weeks modifying the design to remove the debugging components such as test points, test headers, etc. Doing so has no effect on the design nor functionality of the board, naturally. That said, this removal has yielded a most welcomed side effect. That effect is a reduction of the board's overall height. I knew that the elimination of the debugging components would enable me to reduce the height a little bit, but the amount is greater than I had imagined. As mentioned in a previous post, the overall height of my enclosure from the tippy-top to the grave-bottom was 9.3", well 9.39" to be exact, so really 9.4". Removing the debug stuff enabled me to reduce the height by 0.6" so that the total height of the enclosure is now 8.8". This is a monumental victory for me because the size of the enclosure has been a serious concern for me for a long time now. It's kept me up at night to speak openly. My goal, based on what I had seen for similar off-the-shelf enclosures, has always been to have a height of about 8.5". There was one point where I was at 10", I kid you not. Far, far too much. Therefore to get down to 8.8" is, again, a welcome relief!

Equally important to the height reduction is that I have completed the aforementioned modifications to the board and therefore the production design is ready for manufacture. I will submit the files to the local guy next week to get a quote. The reduced board size and fewer number of components should yield a lower production cost-per-board versus design cost-per-board, though it's unclear at this point by how much. I have learned that such cost reductions are not linear, so it's TBD at this point. Whatever it is, I'll pass it onto the user.

Ok so enough about the board stuff. I have gotten back with the enclosure designers and they have made the modifications accordingly. As a side note, the designers came across a supplier issue with the light pipes. It seems that the ones I had planned on using are being discontinued. The good news is that they still have 4000 in stock and will retain the molds. Therefore they will accept custom orders in the future. So the plan is to continue ahead with the light pipes as per the original design. I bought all 4000 and will make a custom order if need be in the future. I'd need to produce a fair number of these to get to that point, so if I do then that would be one of those "happy problems" as one of my ex-girlfriends used to call them. So that's plan A. But I can't be comfortable with that. Of course. Gotta have a plan B. Plan B in this case will be to replace the rectangular light pipes (the current design) with round ones. These are still in production. My enclosure designer has said that the change to the enclosure in such a scenario would not incur any additional design modification costs because the change would be trivial to implement. And so that is a good plan B.

Anyway enough with the enclosure. Now onto connectors.

As I have already mentioned, I am trying to find a suitable connector for the in-line cable break near the transducer. To that end I met with the local Allied Electronics rep this week. He came up with a few options to solve the problem. One is a connector that supposedly self-aligns, while another has tactile points on the exterior of both ends. Therefore both seem to have promise to meet the requirement to be able to connect them blindly and with only one hand. We'll see.

I also inquired about panel mount connectors. Yup, I have 99% decided to go with panel mount connectors on the bottom of the enclosure. It'll solve a couple of problems associated with cabling, and it will enable me to offer cordsets of varying lengths that the user can specify at the time they order. Seems like the best way to go, so I am pursuing that.

I have made orders for samples of all of the above and will play with them this next week to decide which to use in the end product.

With all of the above work in consideration, it should come as no surprise that the final development of the diagnostic software has slowed to a crawl during the past couple of weeks. That said, now that this is mostly behind me I have resumed work on this aspect of the project. I may have said this already and forgive me if it is a repeat, but this work is what I have wanted to get to all along. It is what has always held the greatest interest for me, apart from finally finishing the project as a whole of course! Anyway, work has resumed on this.

That's where I am. Will keep you updated, thank you for reading!

av8or1

iTrader: (4)

Just a quick post to continue to address concerns regarding accuracy. One item that I intentionally avoiding addressing in a previous post was in regard to analog to digital converters (ADCs). I'd like to touch on this subject now if I may.

The microcontroller (uC) that I use on my board has an internal 10-bit ADC. Though adequate for most use-case scenarios, it is well known that it is more of a hobby-type ADC and definitely not of instrumentation quality. If my goal was to have a slightly more coarse level of display accuracy then this internal ADC would suit the project's requirements without much difficulty. However as I stated in a previous post, I'd like to display down to the nearest 10th of a PSI. And I have that type of display, depending on the number of CUs being tested simultaneously (I can test up to 4 at once). All recorded data to the SD card is of course down to the nearest 10th.

With the uC's internal 10-bit ADC that has an error of +/- 2LSB, reporting pressures to the nearest 10th just isn't possible. So like with most everything, I tend to overengineer/overkill and I did so in this case too. My board uses an external (to the uC) instrumentation quality 12-bit ADC. This ADC has a smaller error result and because of its resolution, it can offer accurate reports to the nearest 10th of a PSI, which was my initial goal. In addition, this external ADC has a faster conversion rate than the internal ADC. And since the external ADC communicates with the uC via the SPI bus, if I control the ADC directly then the values will arrive at the uC faster than if those same values had come from the internal ADC. Therefore in the final analysis the end user will get more accurate results in a shorter amount of time. Cool! Granted, this time difference isn't anything that will be noticeable by the naked eye (as the phrase goes), but from a purely technical POV it's a better design. This approach reduces the likelihood of overruns even further, even over a longer sample range. Therefore the end product to the user is better and that will be noticeable, at least from my perspective. And so I went with it.

Anyway. Hope this helps.

misterstyx69

iTrader: (142)

Let me know when these things are coming out.
I like to be number 1..(because my engine went #2..lol!)

av8or1

iTrader: (4)

misterstyx69 - Thanks, we'll do. Good luck with the engine situation.

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.

av8or1

iTrader: (4)

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...my electronics buddy is coming out tonight and we're gonna review some possibles...

Thank you for reading.

av8or1

iTrader: (4)

QUICK UPDATE

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.

Thank you for reading.