END OF THE YEAR STATUS

Well hell. That's what I've been giving this project during the past few months but I just won't make the goal of a production-ready unit by the end of the month/year. The majority of the delay has been associated with materials acquistion and 3rd party service providers, but that's part of it I'm afraid so no excuses. There's both good news and bad news on that front, BTW. The custom enclosure guy finally freed up one of his engineers to begin working on my project. So that has been going smoothly thus far. However my PCB assembly guy seems to be flaking just a bit so I dunno. I may be looking for another assembly guy next month. Sheesh. Anyway.

Where things are:
- Software: 90% complete (I keep adding stuff, though I have begun drawing lines in the sand between that which will go out in v1.1 versus that which will wait until future releases)
- Hardware: 100% completed design, 90% completed prototype (only need to verify that the connectors I've selected will do what I expect them to do; everything will be done by ribbon cables and connectors)
- Regression test suite: 95% complete (only lack the final, full-blown test proc)
- Assembly: was 100%, now uncertain, but I'll find someone ASAP if need be
- Enclosure: 40% of the design is complete, 80% of physical materials provided to design engineer
- Transducer: pretty much 100% decided on the PSIS transducer mentioned in a previous post because it's the only one that will yield even a somewhat lower price point while retaining accuracy

I'll have some time to put more screws to finishing off the software during the holiday break, since I am in a bit of a holding pattern on the enclosure and assembly stuff. But I won't return until the second week of January, so not much "real work" will commence until then.

Thanks elysium19 and all of the others who have read the thread. Funny, but there seems to be more interest in the project in the RX8 forum than back home in the RX7 club. No big deal, just a curious side observation.

Anyway, happy holiday season to everyone!

Jerry

 

Ok so I was playing around with the keypad stuff tonight trying to finalize some of the analysis code. And I got to thinking (uh-oh!) about this keypad I have been using to-date. Specifically I started wondering about its long term viability in a production unit. Thus far I have been thinking that I'd use a membrane keypad like the one shown in the first attachment, possibly adding a cell-phone style clear plastic covering to help protect it.

I was thinking that I would have the keys printed with custom text that tells you what the keys do, though it would be considerably more expensive to go that route WRT setup and design fees in the beginning. Leaving the keys as they are could be ok, I mean once you learn what each key does, then the text on those keys becomes redundant in a way, but I digress.

That said, the primary issue that has me a bit concerned at the moment is how such a membrane keypad would wear over time, given the environment that it'll be subjected to. I am considering jumping ship to a more rugged keypad such as the second attachment because I am more confident in its long term durability. However this keypad would be much more difficult to customize with project-specific text/silkscreening. So it would likely be left as-is and the end user would need to know what the keys mean via the user manual.

So in the end, both options have advantages and disadvantages. I'm leaning towards the second in favor of durability over pretty-fied-ness. However I wanted to see if I could get some feedback from the community prior to moving in one direction or another.

Thanks!

 

So, any new developments on this? I'm in the market for a compression tester in the near future

 

FYI we recently tested and compared all available testers against each-other, share to shed some light on how you think your version will compare and why?

 

Omega8-

Thank you for the inquiry. I apologize for not posting more frequently. Development on RaPiD has been continuing, yes. The holidays slowed me down a bit, but that's true for all of us so no big deal there. That said, I simply wasn't sure if anyone was still interested in what I was working on, so I opted to go underground for a while. I'll post more often in the future. And yes, I do plan on producing a product in the near future. However my theme throughout this "build" has been "don't produce cr@p" so if you need a tester in the very short term, I think John is selling his TR variant again and there's also the Rotary Diagnostics guy. You're most likely aware of that, but hey...

Anyway, a synopsis of the progress since my last post:

1) Software development. The configuration/menuing and diagnostic subsystems are near feature complete. I'm closing out the last of the testing of the config code. All of the "hard stuff" in the diagnostics code is done, it's just a matter of fleshing out the fluff. I tend to tackle all of the more difficult tasks and leave the lesser ones until the end. And that's where I find myself now. Long story short I should finish this within the next week or two.

2) Enclosure. The custom enclosure folk finally came up with a design that didn't look like total cr@p. So I told them to run with it and get me the next iteration ASAP. As soon as I have something reasonable to post, I'll do so. This is the tallest pole in the tallest of the tents in this project as a whole. Has been from the start really.

3) Hardware. I have decided on exactly which components I'll use in this product, with the exception of the hook attachment base and the strain reliefs. The latter has been a real pain. It's the same story as the rest of the hardware has been in this project: few suppliers, very few, are willing to work with "the little guy." If you don't buy in the thousands, they don't wanna deal with you. But I have a few good options I'm chasing down. Should close these last two items out within the next week.

And that's where I find myself at the moment. Finally, in the interest of "full disclosure" if you will, I'd like to address an earlier post in this thread regarding product cost. IIRC, as a response to the general notion that I was/am producing another testing variant, the club member mentioned that he was looking forward to having a cheaper compression tester alternative. As it turns out, by pure luck and happen-stance AND by the fact that I never got into this project with the intention of generating any real profit, my end result will come in at a lesser cost than the other options as they currently exist. However, I won't be able to replicate John's initial cost of low-$200s. I could go into the why-and-how but will choose to opt out of that right now. In the end, my product offering will be a bit cheaper than the current stuff, but not as cheap as John's initial TR variant.

Hope that helps in y'alls compression-tester-purchase-planning efforts.

Anyway, thanks again. As I mentioned, I'll do better with posting updates.

Jerry

ps-When I get to that point, I would like to get a couple of rotary engine owners to be beta-testers. If anyone would be interested, we could discuss the details, but I think it would be a good idea to get some feedback prior to releasing the unit on the open market, so...

 

Carbon8-

Thank you for the inquiry too. Hmmmmm...I don't really know how to respond to you at this point. Lots of things come to mind, but to make a post right now, eh I dunno, it might come across as a bit haphazard. Therefore I'll opt to wait and form my responses a bit better before addressing your central concern.

Having said that, I would be interested to see more details of this test that you referred to. Exactly *why* did they conclude that the RD stuff was cr@p? That is, just how far off were the numbers? I'm actually suprised to learn that those two variants were off by that much. I wouldn't have expected that.

And having said *that* what I will tell you in regard to accuracy is that it has been paramount in my design from the beginning. To that end, I have a buddy at a local Mazda dealership. At the very outset he agreed to the proposal of me bringing in my tester and doing a side-by-side comparison. He and I are both of the mindset that no tester will produce the exact same results even when run consecutively on the same vehicle without being removed in-between tests. There is an acceptable margin of error however that they use at the dealership (so he has told me) and so one of my goals has always been to fall within those specs. Else I won't release the product. That's right, you heard me, I won't sell it if I can't meet those numbers. Period. As I have already stated this was never about profit but rather to produce something that I would want in my own toolbox and if that's all I ever make and I don't sell a single unit, so be it. I'm fine with that.

Anyway, I'll get back to this, but it seems more important that I proceed with making "the BIG post", which I have been dreading doing. I'll be back in a few minutes with that ... gonna use an offline editor so that I don't get logged out and lose everything. lol

Thanks again for posing the question of accuracy. It is an important one and it's an issue that has always been at the forefront of my effort to-date.

 

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

 

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.

 

Carbon8-

Hmmmmm. Well I read the relevant section of that thread that you quoted. There were operator errors that the conductor of the tests admitted to making (which happens, I understand). Once those errors were corrected, the numbers from the non-Mazda factory testers seemed to be better. However there was a lack of detailed information so I couldn't really know how much of an improvement was made. Nor was there enough data such that I could understand the justification behind the complaints. A subsequent poster (TeamRX8) in that thread drew these same conclusions, so I'll go along with that.

Therefore I will pass on commenting much further regarding accuracy, though I'd like to offer a few higher-level notes/responses. It seems to me that both the RD and TR testers do a pretty good job WRT accuracy. But I've never used the RD tester and have only sparingly used the first version of TR, so I don't have a lot of experience with them. And as I have outlined in my previous post I am going in a different direction with my tester. As I stated, accuracy is paramount to me, so I will be diligent to ensure that I produce the most accurate results possible. And I have a plan to do that, also as mentioned previously. Well I mentioned one part of one part of the plan anyway. That was in reference to how I will go about testing the prototype. The remainder of that testing plan is to simply test a number of cars and compare the results to a benchmark. And then there's the initial test which is to compare static pressure from a known source to that shown by the tester. I'll do that with every transducer before earmarking them as acceptable. And I've considered making this a standard part of the tester such that end users can reasonably verify accuracy on their own. But that's another feature, and I'm trying to draw a line in the sand and stick to it. Maybe it'll make the cut, not sure yet.

I didn't mention much about the other aspect of my "accuracy plan" (for lack of a better term) other than to say that this attribute/aspect of the tool has been a part of my design from the beginning. What that really means is that accuracy has been the driving factor behind several of my decisions during the design and development process/phase. One example that leaps to mind is notification of battery charge. If your battery runs low, it will affect your PCB's performance and as a result your pressure numbers could be off. To help eliminate the concern of the end user ("are my batteries ok?" and/or "why isn't this stupid thing working?"), I included a voltage divider in my input circuit and wrote software to monitor that value. If it drops below a predetermined threshold, then I illuminate a "battery low" warning light (LED). This is just one example.

Had another thought. Let me return to the notion of that static test thing. It seems worthy to mention that if I do include the ability for a user to verify a static pressure that this design feature is also an example of my committment to accuracy. In fact now that I have written this I've pretty much talked myself into including this in version 1.1. It shouldn't be that bad to implement it really. Ok. It seems like an important feature to me, so I'll do it. I mean what the hell, it'll take a little more time but not much. And if it can give the end user a little more confidence in the numbers I produce then that is all to the good. I'll add it to the config mode stuff (where you set your parms) as a calibration test of sorts. I think it would be best to display the raw number along with the altitude-dead-volume-and-normalized number beside it. Kinda help you get a feel for the amount of correction that is necessary given the parms that you have stored in memory. The numbers displayed during an actual compression test will always be the raw numbers. Normally, conversion will only occur during the diagnostic/analyzation post-processing stuff.

Heh. Nothing like designing-on-the-fly-late-on-a-Sunday-night-while-I-write-a-post! lol

Anyway, all of this stuff is pretty straightforward when you think about it. Pressure is pressure, and you're either on-the-money-accurate or you're not. I plan to be the former, as I think both the RD and TR testers have endeavored to be too.

Thanks for raising the subject though, it helps to get feedback.

 

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,

Thanks for the updates. I was literally living and breathing only work the last few weeks (even skipped some workouts, ugh) and have had no real time to read your posts until now.

Ultimately, I am interested in precision ACCURACY coming from a tester more than anything else. I am aware of the other testers out there, and came very close to getting one of those. And haven't ruled them out. I was leaning toward the TwistedRotors TR-01, but the website states sold out".

As far as the aesthetics go, your design kinda reminds me a little of a multimeter. Not bad - but, no OLED display? .... kidding To get an idea of the size, what dimensions are you talking about with that?

And when do you believe you'd have a finished product?

 

Have you seen this compression tester Equus - Products - 5612 Digital Compression Tester - Diagnostics Made Easy ?
It doesn't fit rotary engines because doesn't have rpm display, but looks similar to your project.

 

Omega8-

Eh no problem, I'm just keeping my word of posting more updates. And I understand the work thing. Gotta do that myself. 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.

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 overall 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. So it's a good thing I didn't do it for the $$$ because I'll be lucky to break even.

Anyway, I'm working on it.

Thanks

 

Hi YuppY-

Wow, pretty cool tool. I see a few holes with that design, but the graphical representation of the data is nice. I had that in mind originally, but costs prevented me from going with that type of LCD. I suspect that in their large-scale manufacturing arrangement they can source parts and put them together in a very cost-effective manner, which enables them to produce a tool with that higher LCD cost for about the same price. But I'm just a guy-in-a-garage, so I can't match that type of manufacturing cost-absorption. And won't try. But I will produce a good, accurate tool.

Funny, but those diagnostic features are a part of what I am doing. Heh! lol

But I don't wanna see much more; I'm sticking with my own design and not allowing knowledge of other testers to influence that. I've purposely avoided looking at other testers for just that reason.

Anyway, thanks for the link. And kudos to whoever developed that tool.

 

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!

 

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

 

Just a quick minor update regarding the options. I decided to add one additional item, so there will be 16 options as of now. It was simple and I finished it over the weekend. That option will be

Compression Peak Type - Whether the displayed compression readings represent the maximum value for a given CU or just the last-read value

And I'm finishing up the diagnostic stuff, but have more than I think I need right now. So I'm trying to decide what is important and what is kinda extraneous.

And speaking of extraneous, I got some feedback yesterday regarding the hook assembly that I had designed into the enclosure since the very beginning. I told the guy it would only be about $10 - $15 extra for the hook, depending on what kind of deal I could get for the components. He told me that he wouldn't care about/want the hook and that he'd rather save the $10 - $15. Kinda made me think...perhaps I should offer that as an accessory and decrease the sales price a bit.

But I dunno, the hook was kinda something I wanted to do from the very outset. 'Guess it isn't that big of a deal. Hmmmmmm...any feedback on that y'all?

Thanks

 

A hook holds no interest for me either. That's not to say it couldn't, as you say, be offered as an accessory.

 

Omega8-

Ok thank you for the feedback, 'preciate it. I had already decided to accessorize the hook after the initial feedback that I received, so yours augments that decision. Funny, not having a means to hang my TR-01 on the lattice-work (IYW) of the inner hood was one of the features that I wanted to see in my tester, pretty much from day 1. That said, I didn't want the typical steel, solid hook that you see on an A/C manifold gauge set or on a caged work light. So instead I opted for a system where you can shape the hook to suit your particular point/area of intended hanging (ergo it fits wherever you wanna put it).

But hey, I digress, to each his own. It has always been my intention to satisfy every end user that I reasonably can. Therefore I'll continue that theme by accessorizing-most-everything-that-isn't-critical. Heck, one of the higher priority items that I have kept in mind all throughout this process, along with accuracy and cost, has been to eliminate the in-your-face stuff that we as consumers get a lot of the time. I guess you could arguably go too far with that, but so long as critical functionality isn't eliminated during the pruning, then no harm done.

For example, I separated the diagnostic stuff from the testing stuff with this very thought in mind. That is, if you don't wanna use the diagnostic features of my tester, then you don't have to. You can just prepare everything for the test, connect the tester to your engine, select your mode, whether or not you wanna log data (which is disabled by default from-the-factory, however you can change that default in the options menu such that every time you power up logging will be enabled by default), press the test button, crank, watch the numbers, stop cranking, turn the tester off, disconnect everything and be done. If that is all you wanna do, you can do that.

And it's that kind of approach that I'll carry forward WRT the hook. If you don't wanna use it, then you don't have to; I won't include it in the vanilla version. But if you do want it you can order it as an option. Either way the difference is only a few bucks, so no big deal. I can see that my ordering form will be rather complex though, and it will only become more so because there are other options that you'll be able to choose from as well, such as LCD colors.

Anyway.

Closing in on finishing the diagnostic code. Hope to have that done this week. I got caught up trying to find a cool way to apply some basic data analytics to the process. Although there was a definite correlation between those analytics and the sample data that I use, that type of analysis didn't provide much added value to just the basic math stuff in this context. So it'll probably have to be eliminated. We'll see.

Gonna head down to the old Dell campus tomorrow or Tuesday to pick up my last (I hope) devel boards. They also provide cabling services, so I plan to investigate how I could use that in this project too. I'd feel better about having their cable guy (who reportedly does all of the cable-related stuff in their shop) put everything together for my tester; seems like the quality would be better as well as the fit-n-finish of the end product. Yeah. That and I don't wanna fool with it every time I make a tester. lol

Anyway again.

Thanks!

 

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

 

Thanks for the update.

 

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 because the size of the enclosure has been a serious concern of mine 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!

 

Omega8-

Just a quick post to continue to address your 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.

 

So when should I pop down to pick it up? ;-)

 

It does help - I'm no engineer, but I am a programmer, so context matters. The details are everything.