REtali8 - lol - yeah hope you can make it to Austin someday, glad to meet ya if you do. Omega8 - ok great, good stuff, programming is cool. :-)

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.

 

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.

 

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.

 

I'm excited to see your final product and purchase one. Any idea when you might have the first ones available?

-Austin

 

Ozzten- Thanks for the inquiry. I'm hopeful for summer. We'll see how it goes. I'll keep everyone updated.

ADAPTER UPDATE

Picked up the latest batch of adapters from my machine shop buddy tonight. That said, the news wasn't all good. He informed me that he's gonna have to scale back his side work and so he won't be as available to work on my projects as he was in the past. He can still do some work for me, but not as much as we had discussed in the "worst/best case scenario." However he spoke with his manager and the machine shop where he is gainfully employed (his day job) is willing to take things over so-to-speak, but only in minimum quantities of 100 or more. I had wanted to avoid that but it appears that it won't be possible now. Oh well, not an insurmountable obstacle, just a big check for stuff that may go unused. TBD. But I digress.

Attaching pictures of my buddy's handiwork. The adapter on the right in these pictures was his first version. It was functional, but as you can see it didn't thread all of the way onto the transducer. As I mentioned that's an NPT thread, so technically this is correct and it would have provided a good seal. However I had a few problems with it. It just looks "funny" somehow because it doesn't mate to the body of the transducer, it increased the dead volume (albeit ever so slightly), and it would result in an overall larger extension out of the spark plug hole, which could have clearance issues in tight engine bays. Granted none of these reasons were huge concerns, kinda overkill type of worrying really, but that's what I do, so I told him to work out the timing such that the thread seal and the body seal coincided. As you can see in the adapter on the left, he got it right.

And it fits well into the rotor housing, as shown by the last two pictures.

Anyway, that's the status on the adapter. I'll take his final model to his place of employment some time during the next week to nail down a game plan with the owner.

Ok are ya sitting down? A buddy of mine has been giving me a hard time for a while because I have no smartphone/tablet interface to my device. I've told him that I am far too late in the process to add any new functionality. I also told him that I didn't address the issue back in the early design work because of the data lag/loss issue associated with broadcasting over a wireless connection. But he kept on and on. Wouldn't shuttup.

So I gave it a quick think a couple of weeks ago and decided that it might be worthwhile to pursue, considering that the slower rate would still likely exceed the rate that the human eye can keep up, and there might be a benefit in certain use case scenarios. And if I can help make someone's life a little easier/more fun then I'm all for it, despite the data lag/loss. The most intriguing use case scenario being that the end user tests all of his CUs simultaneously, and while doing it, the user simply leaves the device out under the hood somewhere (in a safe location obviously), then sits in the comfort of the throne that is the driver's seat, opens the app on the smartphone/tablet, and controls everything from there. The user then sees the numbers go by as they crank the engine and shuts everything down. Kinda cool, or so it seemed. Openly I don't know how much it would be used, so I decided that I'll offer it as another accessory, much like the hook. With that approach the device is kept to the minimum and the user can select the functionality they want in their quasi-custom version.

And having said all of that, I wouldn't allow it to impact the production design that I have already set in stone, nor the enclosure. That was the one requirement. So I formulated a strategy of how to go about getting it done. I decided to just run traces to a header and put the wireless stuff on a separate breakout that I'll design later on. That design choice won't impact the production board, save the new header, and thus the impact will be almost non-existent.

I went with it. Got the updated prod design stuff back to the board house and have my quote in-hand as of yesterday. Gonna start the process of getting a couple of prod-verification boards built this week.

Anyway that's where things are.

Thank you for reading.

 

Any word on when these will be available?

 

Hi Y'all-

Thank you for the interest Djwhitey123 ... I'm still hopeful for a late summer release. We'll see. I'll keep y'all updated.

And speaking of updates I must apologize for not updating the thread much during the past month or so. I've been going through some other-half issues as of late (runaway bride stuff) and it's had me kinda down.

That said, I have continued to make progress. The production boards are in and assembled. I'm running regression on them now. Once that is verified I'll ship one of them off to the enclosure designer for fitment verification. I'll use the other two in a mockup to run against real data from real cars (and trucks). Kinda cool really.

Anyway, I'll try to do better with updates. Again, sorry, just life stuff going on that's all. But JDACT RaPiD will be completed, no doubt. I'm attaching a picture of the comparison between the final devel board and the prod board. Kinda interesting. But at least y'all can see something real-life and tangible.

Thanks

 

Hey good to hear these will (hopefully) be available by late summer. If that holds true - I'm in!

 

Any new developments/news?

 

Omega8-

Hi, sorry for the delay in responding. Work (my real job) has been kicking my tail the past few months and last week was no exception.

Anyway, yes, I have been making progress with RaPiD. The tallest of the tall poles in the tent is still the enclosure, as it has been from day 1. I'm going back-n-forth with the enclosure designer folk and we're making progress, but they're swamped and are not as responsive as I'd like. But I'll stick with them, we've come this far. And I'll also stick with the notion of fabbing a custom enclosure; I just don't want to grab one of those project enclosures that I see at the local electronics store and adapt it to my project. Nah, I'd rather go the other way around and adapt the enclosure to meet my needs. Just need to be patient with the designers. Unfortunately.

So in the meantime I've been making progress in other areas. The biggest decision I've made is to go with a D-Sub connector for the cable input to the enclosure. This is the standard type of cable that we've all seen for years on various electronics, especially PCs. Think parallel port, etc. The most obvious one that most everyone is familiar with is the connector for the monitor. I'll have the same basic implementation: A female connector mounted inside the enclosure at the bottom (to include a covering tab when not in use), a male connector at the end of the input cabling and a clamshell (or backshell) that houses the male connector and that contains thumbscrews so that the user can easily screw the 2 bolts into the jack screws that are on the female connector in the enclosure. I made this decision because I wanted to provide a rugged, sturdy and reliable connector that included strain relief. I also wanted something that was relatively low profile. What I mean by that is that the D-Sub is relatively small in height (top to bottom) and I need that to keep my enclosure depth from increasing. I am doing my damnest to keep the enclosure at a hand-held device size. That too has been a challenge, as I have mentioned in the past. And the D-Sub has been around forever, almost everyone is familiar with it and how it works. Therefore it will be a feature with which the user can readily identify and feel comfortable with. In the end I'll have a connector that meets my requirements all the way around: low profile, rugged, sturdy, reliable and that provides strain relief. The icing on the cake will be that the clamshell/backshell that I've chosen is metal and provides extra EMI/RFI protection. Albeit this is overkill. But heck I've overkilled everything else, why not that.

And speaking of overkill and interference protection: I decided that while I am working with the designers that I should go back and revisit the transducer stuff. I'd been meaning to do that anyway, so now seemed like a good time. I dug around and found another supplier that offers a competing product for the same price. They also do a better job with the shipping costs, so that was an immediate plus. However the differences that I saw were intriguing. Specifically, their transducer uses a molecular sieve to provide a vent to the atmosphere, thereby making it a gauge transducer (PSIG), as opposed to the sealed transducer (PSIS) that I was using previously. Granted, the difference can be accounted for in software, but does anyone really know their pressure or density altitude on any given day (it varies). So you could come very close with a PSIS solution, and in reality that would serve our purposes. However this approach has simply been bugging me. I don't like coming real close, I'd like to be as exact as I can possibly be. And therefore I had always preferred the notion of using a gauge transducer (PSIG). This new product provides that capability. The supplier can meet all the other requirements that the manufacturer of the previous transducer was offering, so there is no loss there. And that was key. Finally, the new transducer offers considerably more interference protection than the PSIS transducer, which is to say that it provides it at all. The previous one didn't but seeing as how it isn't a *huge* deal, I had decided to let it go. But that too was nagging at me. So I decided to "fix it" by using a transducer that provides shielding. Furthermore this particular transducer provides both braided and foil shielding, along with the drain/shielding wire. So that's another plus. I'll buy cable that matches those capabilities to run from the connector to the male D-Sub and it's clamshell/backshell. Thus we'll have the best interference shielding capability that I can reasonably offer. To that end I've been tracking down deals on the cable I'll need to meet those requirements; and that is important to keep the unit cost for that component under a certain price point in order to keep the overall cost in the ballpark of my goal. That said, no skimping of cable/shielding quality will be tolerated, so if I go over a little, I go over a little. We'll see. And yes, I grant you that this shielding stuff is overkill too. But I prefer to go that route when considering engineering solutions, generally speaking. So that's that. I've ordered one of these new transducers and will do a side-by-side comparison test with the old one to see how it performs. The old one met my requirements otherwise, so if the new guy performs up to its datasheet, it'll be the one that I go with.

I've also been experimenting rather extensively with the connector that will be near the transducer. As I mentioned, it needs to be something that you can connect with one hand and without visual reference. That's turning out to be a real, real difficult task. Nothing I've come up with so far seems satisfactory. So I dunno. I'll have to either relax that requirement a bit or keep digging. So far I've chosen the latter option. So we'll see.

And I'm staying on top of the enclosure folk. Sorry that I'm not further along in that regard, but there isn't much I can do other than to poll them every few days to see where things are. I'll post when I have more info...hope this helps.

Thanks!

 

Omega8-

Another update. To speak openly I'm not certain how often nor how much detail to put into these build reports. I'm just kinda winging it really; so I'll post what seems relevant and important and leave it at that. Some of this is old news, some of it more recent.

The first item on my agenda has been the enclosure, as always. The designers tell me that their schedule will ease up in the next month. They plan on getting to my stuff soon, so that was good news. I need to send them the hardware for the hook so that they can verify it with their current design. I'll do that this week.

Now for some older news. In June I posted a picture of the new prod boards in comparison with the devel boards. As it turned out there was a slight problem with the new prod boards; it took a bit of detective work to find, but in the end it was a real V8 moment. I had somehow omitted the pullup for the new external ADC. This was causing an inability for the uC to boot and run because the SS line for that ADC was floating LOW. Sheesh! How did that happen? Dunno, musta missed it during one of the endless up-until-3-am-on-a-work-night design sessions that I've done while working on this project. Oh well, I found it and added it in the design, but I had to solder in a 10K on these three boards in the meantime so that they'd boot and run. After that the boards worked well. I was able to upload code via the ICSP and get the correct behavior from the boards as a whole.

That said I couldn't upload code nor see any data from the board via the serial header. Turns out that the FTDI breakout I was using had somehow, mysteriously and silently gone South. After some troubleshooting I determined that it was the likely culprit. I ordered a new one and waited for it to arrive. Sure enough that was the problem. I was then able to upload code and see serial data via the header. Note that this was not a problem with the boards themselves. It was the FTDI breakout, which is a completely separate animal that I use to communicate with the boards via the USB port on my laptop. The boards themselves were functioning correctly once the pullup was soldered in.

Having said that, the ability to do serial I/O is crucial in my development effort because this is how I run the regression library. This header is also how I will provide a user the ability do their own software updates in the future, if they're so inclined. So it's a must obviously in my usage scenario, though not technically so. I could upload via the ICSP and not even have a serial header, which has been suggested to me in the past. However I wanted the ability to run a fairly extensive regression suite even in the production scenario. I will run every board through regression prior to delivery. And as I mentioned users will be able to do their their own updates too. In order to do those two things the prod boards must have a serial header, and so it does. Finally, I was glad to see that these new boards fully pass regression! Therefore no new issues were introduced in the jump from devel to prod, which is a good thing obviously. I also added a couple of tests to the regression library.

So the prod boards are good to go. Nice.

The next item that is also somewhat old is the connector that will exist in the cabling between the transducer and the enclosure. I have struggled with this one mightily during this entire development process, all the way back to the beginning. I thought I had found a solution in the form of a cannon plug that met a MIL spec. Although rugged, solid, reliable durable and tough-as-hell, these two connectors were expensive WRT their component cost. It was going to push the final price closer to $400 than $350, which is where I'm trying to stay. (crossing fingers) But they were complete beasts so I was willing to try them. Unfortunately they were not as easy to put together as I was hoping they would be. With a single hand, blind and no solid end on one of the connectors, they just weren't that easy to connect. I could do it and with practice I could do it repeatedly. However given the cost factor, I decided to continue searching for a better solution. That was frustrating. Close to what I want, but just not quite there. So I'm still working on this component as I write this report. Unfortunately.

This is getting long. I'll stop here. There are other items I could report on, but not knowing what level of information is interesting to those who bother to read the thread, I'll just quit while I'm ahead.

Thank you for stopping by to take a look at the update.

 

UPDATE:

Two items to report on today: Bluetooth and wire-to-board connectors.

Bluetooth. As mentioned previously, I wanted to address the problem of I-work-on-my-cars-alone scenario. To that end, I decided to create the ability for the end user to leave the device in the engine bay somewhere, sit in the driver's seat, connect to and control the device via Bluetooth, crank, see the data, stop cranking, analyze the data (manual or automated), then get out, disconnect everything and be done. I added an additional header on the prod boards (that didn't exist on the devel boards) for this purpose. I can report that I have this up and running. I can control the board from my Android and see data come back to my phone from the device. Ok data rates to boot. The only downside to Bluetooth - that many of you are likely aware of - is that you can't develop an iOS app and distribute it legally. However that can be done with BLE (Bluetooth Low Energy), or at least it could a couple of months ago when I last visited this stuff. Assuming that hasn't changed, I plan on developing a BLE breakout that can be used with an iOS device. But having said all of that, I know little-to-nothing about developing an app. I'm a classically educated (which means old-school stuff) software/hardware guy (more software these days) and so apps aren't anything that I need to know about IRL. But I suspect it wouldn't be hard to cobble something together; there must be some example stuff out there...I learned about the official apple developer thing...interesting. The plan is to get something up and working for Android and then go to one of my Mac buddies for the iOS stuff. Anyway, that shouldn't take long I think.

Next is wire-to-board connectors. I switched from standard prototyping headers and housings on the devel boards to more production quality locking connectors for the prod boards. The problem has been finding crimping tools to assemble the friggin things. The factory crimpers run $500+ and only do one style of contact/connector. I use three differnet types of contacts/connectors on my board (out of necessity). So that means shelling out $1500+ for crimpers alone. I finally found a couple of non-factory generic crimpers that would work for my contacts/connectors and have been using those for the development stuff. However at the end of the day, both they *and* the factory crimpers are still manual, meaning that you'd need to create all of your connectors for each board by hand. On the prod boards there are a total 8 connectors and 58 contacts (pins) maximum, depending on configuration. So you'd have a considerably difficult task to assemble all of that with good quality for *each* board. Again, you would have to do it by hand. Oooouuch. Not a good way to go given this scenario. So a different solution was needed. After spending a lot of time researching, I found a small electronics company in MN who specialize in this type of connector (meaning this manufacturer) and who will procure and assemble your connectors for a reasonable cost. Their assembly isn't done by hand crimpers either, but is instead done by automated machines that produce a perfect crimp and installation into the housing every time, thousands of times per day. Thus the end result is a connector that is of better quality, which is what I like the most about that solution. So. Long story short version is that I found a good vendor to handle the wire-to-board connectors on a professional level, but who is willing to work with the little guy like me. And that is a refreshing experience, I can't tell you how many times I've been turned away from doing business because of projected production run quantities.

Anyway. Continuing to work on the in-line connector and will get to the transducer comparison ASAP. Though I fully expect to be using the transducer that I mentioned most recently.

Thanks

 

Any update on this?

 

G8rboy-

Hi, thank you for inquiring. I had kinda gone underground again with the project because of the overall lack of traction I've had during the past 3 months. I felt poorly for a while due to a case of bronchitis while simultaneously needing to maintain the crazy pace that work (my real job) has kept me under for the better part of a year now. Anyway, it's just been rather frustrating for me, so I haven't kept up with the updates. Sorry about that. Of course, the biggest problem I've had has simply been that I am one of those engineers who is rarely satisfied. So when I work on a project, especially in a team setting (which this is not), I am always the guy who is labelled "he can't keep his dam hands off of it." And so it goes with this too...

And saying that, yes, I have made some progress. I finally got some of the enclosure designer's time and we solidified several aspects of the project, to include the hanging mechanism and ventilation. Just to give you an idea of what I mean by saying that I obssess over stuff (when I arguably shouldn't), allow me to talk about other areas of progress that have occupied my work time on the project since the last update.

First, I built a prototype of the enclosure as it sits now and I dunno...just not quite happy with how it feels when I hold it. It's ok and would work, sure, but the narrowing width from the "shoulder" downto the "feet" doesn't have the feel to it that I thought it would and that I'd like. It feels like you can't get a good grip on it and like it's gonna squirt out of your hands in the direction of the wider width at the top. I must have picked up that prototype 100 times now, just playing around with ideas for grip and possibly going back to a hershey bar (rectangular) shape WRT the width dimension; crazy I know. In this aspect I literally can't keep my hands off of it.

I am also not too happy with the rather vanilla choice I made WRT a power source. So I looked into changing to an alternative approach. While I like the new solution that I developed better from an engineering perspective, the cost-to-benefit ratio didn't justify the change, and so I shelved the idea for now.

I've also never liked the idea of the adapter on the end of the transducer. You know, the machined adapter that converts the 1/4 NPT thread of the transducer to the 14 mm needed to fit into the threaded spark plug hole on the side of the rotor housing. Those need to be custom made, they add to the device component cost, they introduce extra dead volume and they lengthen the pressure-measuring mechanism as a whole, when it should be smaller, not bigger, at least in the context of measuring the compression of a rotary engine. In fact, that has always been something I've insisted on since the beginning: keeping the size of the transducer as small as possible while not sacrificing functionality and capability. So I've been working with my transducer supplier on a different approach. I've got an incantation of my latest idea on the way from them now. I'll test that out and see how it goes. If it works like I think it will, then I plan to abandon the adapter entirely WRT the rotary solution (you'd still need some type of adapter for the piston/diesel application, depending on the engine in question). So we'll see how it goes.

Next, in the true spirit of not being able to leave well-enough alone, I've also been developing an optional capability for the device. Unfortunately that design and implementation has proven to be more difficult than I anticipated, and so it's requiring more time than I planned for or want. I thought about releasing a version without this capability, but it has serious implications WRT the enclosure, so if I did that there would be some pretty expensive redesign costs later on down the road. I also considered foregoing the capability altogether, but decided against it. Quite frankly if I'm gonna work on something like this then I'd prefer to do stuff that I'd want to see in a device that I had in my own toolbox; and so I felt compelled to press ahead. That said, I believe I have a solution now, it's just a matter of getting in the parts, assembling them and testing them. Those parts are on the way too, so we'll see.

Finally, like any new venture I've spent a fair amount of time investigating the legal stuff. It's an unfortunate thing that we must deal with, but it is what it is. I have a basic game plan together for that now. But you always worry when doing something like this; I could just see some twit attempting to measure the compression coming out his own tail pipe and injuring himself somehow...sheesh. Anyway......

So. That's probably not the answer you were looking for, I realize. Know that I haven't given up on the project nor will I. And I have already begun to reign myself in a bit WRT the obsession stuff. I'm really not liking not being able to work on my cars because of this project, so I do need to draw things to a close. As I've said previously, if you need something ASAP, I'm assuming that John and Larry (if I recall their names correctly) are still in the business...

Anyway thanks again for checking in with me, I appreciate that. I'll let you know how the upcoming testing goes.

 

So is there any word on this being available? as new to me rx-8 owner this seems like a must have kinda tool a update would be really nice.....

 

Hi Pax-

First, congratulations WRT getting your first 8. I hope you enjoy it!

Regarding the RaPiD project, yeah things are progressing still, believe it or not. However I've been running up against legal issues over the past year. Specifically in regard to the notion of implementing a BLE component. The first design I had would have required over $10K in FCC certification testing. So naturally I balked on that. I've since gone through 3 new designs, all of which have reduced that cost, but it's still a tad high. So I'm working to bring it down further.

Also, I have been debating on whether or not to forego a display on the box itself such that the only "display" as it were would be the smart phone/device that is connected to it. That would simplify the design and reduce costs, but in the turning-wrenches world it doesn't seem like the best idea. So during one of the redesigns this was the type of thing that I was grappling with. And there were others. Complicating the picture for me has been that my wife and I welcomed a son into the world last year, so that's been a factor.

Anyway, work is continuing, yes. In the meantime, I suspect that John with TR in Houston might still be selling, as might be the RD guy up in the midwest somewhere (I forget where now). So you might look into those for a solution too.

Thank you for the inquiry,

Jerry