Close

Page 6 of 6 FirstFirst ... 456
Results 126 to 147 of 147
  1. #126
    Join Date
    Nov 2009
    Location
    Simi Valley, CA
    Posts
    8,129
    Rep Points
    9,106.3
    Mentioned
    644 Post(s)
    Rep Power
    92


    0 out of 1 members liked this post. Yes Reputation No
    Click here to enlarge Originally Posted by shiv@vishnu Click here to enlarge
    Terry-- You're a pioneer.
    Let's be honest here -- neither of us invented TMAP attenuation.

  2. #127
    Join Date
    Feb 2010
    Location
    Miami Beach
    Posts
    1,094
    Rep Points
    513.1
    Mentioned
    10 Post(s)
    Rep Power
    6



    Yes Reputation No
    Click here to enlarge Originally Posted by shiv@vishnu Click here to enlarge
    Yeah, but usually correcting involves giving correct info.

    Click here to enlarge Originally Posted by shiv@vishnu Click here to enlarge
    Terry-- You're a pioneer.
    Click here to enlarge
    Click here to enlarge

  3. #128
    Join Date
    Nov 2009
    Location
    Simi Valley, CA
    Posts
    8,129
    Rep Points
    9,106.3
    Mentioned
    644 Post(s)
    Rep Power
    92


    0 out of 1 members liked this post. Yes Reputation No
    Click here to enlarge Originally Posted by adrian@vishnu Click here to enlarge
    Hi Terry,

    Many years ago I did some project with little PICs including the 12F and 16F. I did an ignition expander which converted a distributor signal to direct fire. It worked, but added a variable 8-12us delay. This equated to a few degrees at high RPM. It did it with interrupts like you have done.

    More recently I originally tried to get get CPS working (with capability of advance and retard by more than a tooth) with an 8 bit freescale processor running at 8MHz with Input capture and output compare. It worked up to about 4500RPM at which time it could just not keep up. I would be beyond impressed for you to get it working satisfactorily on a PIC12 on interrupts... happy for you to show me!!

    I can't debate about the fact that you have a couple of years with good reliability. I just debate whether it was good luck or good management. As I said you only find out that the N54 is strong by pushing further that we expect and having it not break. Luckily it has not broken yet.

    Adrian
    Hi Adrian,

    Although I do the lions share of our programming in terms of lines of code I normally work within an environment that has been configured for me by an embedded specialist. The speed delimiter was my first attempt at a start to finish application and although I was tempted to go the 12F683 route and use a PWM as you suggested the 12F629 presented a better learning opportunity. I have been very impressed with what even a simple processor like this can do and plan to continue work with it. Our embedded guy is working on some of our heavier duty projects currently.

    I should add despite the differences in this application I've been very impressed with your hardware. Much more so than your competition such as AEM, Chip Torque, Unichip, etc. Clearly Shiv is very fortunate to have you. I hope he rewards you well. Click here to enlarge

    Best,
    T

  4. #129
    Join Date
    Nov 2009
    Location
    Simi Valley, CA
    Posts
    8,129
    Rep Points
    9,106.3
    Mentioned
    644 Post(s)
    Rep Power
    92


    0 out of 1 members liked this post. Yes Reputation No
    Had a few moments so added a small variable shift just to see if the 12F629 could keep up @ 4mhz. As Adrian pointed out advancing CPS is much more complicated than retarding. And no attempt has been made to advance. But @20mhz I think we'd be just a good algorithm away.


    Click here to enlarge
    Attached Images Attached Images  

  5. #130
    Join Date
    Mar 2010
    Posts
    32
    Rep Points
    0.4
    Mentioned
    1 Post(s)
    Rep Power
    0


    2 out of 2 members liked this post. Yes Reputation No
    Hi Terry,

    The speed delimitter application is a nice task for a interrupt based apprach without discrete timer IOs. This is because the phase and even a small variation in frequency is quite acceptable to the DME. The thing is, the crank sensor is the most impartant sensor to the DME. It is the sensor that is used for timing anything that is synchronised to engine position. It is also used for a bunch of engine diangostics (missfire detection). The DME watchs that signal very closely, and it must be very accurate and look like what the DME is expecting it to look like. This means that at high RPM, if you get caught for 1 microsecond somewhere in another interrupt, this can cause a delay of 0.5 degrees, and this is enough to cause the DME to flag a missfire fault.

    The CPS task is best handled by timer IOs (input capture/output compare). These outputs will do there thing regardless of what the main CPU is doing elsewhere, and the CPU has a much longer (but finite still) amount of time to setup the next edge.

    Anyway, adding a constant delay as you have demonstrated is quite feasible with the processor as you ahve deomonstrated. Not to this, you need the capbility of adding no delay when you want not delay (the interrupt latency could be significant if do the calcs), and then combining this capbility with the capability to do everything else you need to do (no doubt you are using interrupt for you boost control, so what happens if CPS and boost interrupt arrive at the same time... which is more important).

    Anyway... as you know, I do all hardware, firmware (embedded software) and PC software for the Procede. I have been doing this sort of thing for a long time, so I have done many automotive electrical tasks in my time, so have tried most things. Sometimes it is better for everyone to choose a more expensive processor (which is minimal cost in the scheme of things) to do thing properly and in a fraction of the time. The Procede hardware was designed to allow us room to move to get thing we anticipated at the beginning going, even though it has taken us some time to get everything we have going now. We still have things up our sleeve, but time is the issue. I do OK from Shiv, but it is a part time gig for me. Maybe one day I can do it full time.

    Cheers,

    Adrian

  6. #131
    Join Date
    Nov 2009
    Location
    Simi Valley, CA
    Posts
    8,129
    Rep Points
    9,106.3
    Mentioned
    644 Post(s)
    Rep Power
    92


    1 out of 2 members liked this post. Yes Reputation No
    Click here to enlarge Originally Posted by adrian@vishnu Click here to enlarge
    Hi Terry,

    The speed delimitter application is a nice task for a interrupt based apprach without discrete timer IOs. This is because the phase and even a small variation in frequency is quite acceptable to the DME. The thing is, the crank sensor is the most impartant sensor to the DME. It is the sensor that is used for timing anything that is synchronised to engine position. It is also used for a bunch of engine diangostics (missfire detection). The DME watchs that signal very closely, and it must be very accurate and look like what the DME is expecting it to look like. This means that at high RPM, if you get caught for 1 microsecond somewhere in another interrupt, this can cause a delay of 0.5 degrees, and this is enough to cause the DME to flag a missfire fault.

    The CPS task is best handled by timer IOs (input capture/output compare). These outputs will do there thing regardless of what the main CPU is doing elsewhere, and the CPU has a much longer (but finite still) amount of time to setup the next edge.

    Anyway, adding a constant delay as you have demonstrated is quite feasible with the processor as you ahve deomonstrated. Not to this, you need the capbility of adding no delay when you want not delay (the interrupt latency could be significant if do the calcs), and then combining this capbility with the capability to do everything else you need to do (no doubt you are using interrupt for you boost control, so what happens if CPS and boost interrupt arrive at the same time... which is more important).

    Anyway... as you know, I do all hardware, firmware (embedded software) and PC software for the Procede. I have been doing this sort of thing for a long time, so I have done many automotive electrical tasks in my time, so have tried most things. Sometimes it is better for everyone to choose a more expensive processor (which is minimal cost in the scheme of things) to do thing properly and in a fraction of the time. The Procede hardware was designed to allow us room to move to get thing we anticipated at the beginning going, even though it has taken us some time to get everything we have going now. We still have things up our sleeve, but time is the issue. I do OK from Shiv, but it is a part time gig for me. Maybe one day I can do it full time.

    Cheers,

    Adrian
    Hi Adrian,

    I wouldn't say the 12F is ideal for CPS but it is a fun academic exercise. As you pointed out in this example the $.90 processor is mostly sitting in a loop waiting for interrupts. If we were to try to layer on other tasks it would have no hope of keeping up. Regardless perhaps the experience will earn me a little more credibility with our embedded guys next time I question a missed deadline. Click here to enlarge

    On the 18F with CPS it was configured as a high priority interrupt with the UART as a low priority. No other interrupts used. The 18F2431 is a pretty slick little processor and one of the few we found that did everything we wanted to do in a DIP package. Also its worth keeping in mind we have a rather unique business model. It isn't often a company our size has in house expertize available for both hardware development and tuning development that is focused only on a single application. So it's worked out well for us. Also sometimes it's difficult to predict what you'll want a year from now, the Rev1/Rev2 being an example of this. But as we expand to other applications the universal board with application specific firmware approach might become more appealing.

    Best,
    T
    Last edited by Terry@BMS; 04-04-2010 at 01:17 AM.

  7. #132
    Join Date
    Mar 2010
    Posts
    32
    Rep Points
    0.4
    Mentioned
    1 Post(s)
    Rep Power
    0


    2 out of 2 members liked this post. Yes Reputation No
    The 18F is a good processor... I am using it (but I am not doing the firmware for it) for a completely different application implementing an IP stack for a modem. It is a nice processor. But it is not as well suited to automotive applications... particularly those requiring real time constraints like synching with engine position. But it can certainly do everything you are currently doing with JB3 well.

    With the Procede, we have only had two revisions of hardware. We have also had some changes to the patch harness which have been relatively minor. Even with the hardware revision from Rev 1 to Rev 2, this was mainly to reduce cost (changed from expensive Deutsch box to an extruded aluminium enclosure) to be able to be more competitive in the market. Since we were making changes already, we also took the oportunity to integrate some of our patch harness components in the main box, and externalise some of the features we did not have pins for with the Deutsch connector. No other changes were made (as evidenced by the fact Rev 1 and 2 ran the same firmware and maps for a long time until we became dependant on CAN), and the original Procede architecture has proven remarkably versatile. So we are now approaching 18 months with no changes to the hardware, and none planned... and we are still adding new things all the time.

    Two different approaches... both work.

    Cheers,

    Adrian

  8. #133
    Join Date
    Feb 2010
    Location
    Miami Beach
    Posts
    1,094
    Rep Points
    513.1
    Mentioned
    10 Post(s)
    Rep Power
    6



    Yes Reputation No
    Click here to enlarge Originally Posted by adrian@vishnu Click here to enlarge
    With the Procede, we have only had two revisions of hardware. We have also had some changes to the patch harness which have been relatively minor. Even with the hardware revision from Rev 1 to Rev 2, this was mainly to reduce cost (changed from expensive Deutsch box to an extruded aluminium enclosure) to be able to be more competitive in the market. Since we were making changes already, we also took the oportunity to integrate some of our patch harness components in the main box, and externalise some of the features we did not have pins for with the Deutsch connector. No other changes were made (as evidenced by the fact Rev 1 and 2 ran the same firmware and maps for a long time until we became dependant on CAN), and the original Procede architecture has proven remarkably versatile. So we are now approaching 18 months with no changes to the hardware, and none planned... and we are still adding new things all the time.
    that's pretty impressive that it does so much and still be able to do more.
    Click here to enlarge

  9. #134
    Join Date
    Feb 2010
    Location
    Long Island, NY
    Posts
    1,663
    Rep Points
    2,215.1
    Mentioned
    16 Post(s)
    Rep Power
    23


    Yes Reputation No
    this thread delivers Click here to enlarge
    2006 AW/Black ZCP 6MT


    Click here to enlarge


    E46 M3 Owners of the World <---- Join the FB group!!


    Instagram :: @NotSMG.M3

    Click here to enlarge

  10. #135
    Join Date
    Feb 2010
    Location
    Hanover, MD
    Posts
    1,247
    Rep Points
    697.1
    Mentioned
    4 Post(s)
    Rep Power
    7


    Yes Reputation No
    I have to say I learn something nearly every time Adrian posts. Also, thanks to both sides for keeping this discussion civil enough for the rest of us to get something out of it.
    Click here to enlarge

  11. #136
    Join Date
    Jan 2010
    Location
    SoCal
    Posts
    119,432
    Rep Points
    32,144.0
    Mentioned
    2107 Post(s)
    Rep Power
    322


    Yes Reputation No
    Click here to enlarge Originally Posted by adrian@vishnu Click here to enlarge
    The 18F is a good processor... I am using it (but I am not doing the firmware for it) for a completely different application implementing an IP stack for a modem. It is a nice processor. But it is not as well suited to automotive applications... particularly those requiring real time constraints like synching with engine position. But it can certainly do everything you are currently doing with JB3 well.

    With the Procede, we have only had two revisions of hardware. We have also had some changes to the patch harness which have been relatively minor. Even with the hardware revision from Rev 1 to Rev 2, this was mainly to reduce cost (changed from expensive Deutsch box to an extruded aluminium enclosure) to be able to be more competitive in the market. Since we were making changes already, we also took the oportunity to integrate some of our patch harness components in the main box, and externalise some of the features we did not have pins for with the Deutsch connector. No other changes were made (as evidenced by the fact Rev 1 and 2 ran the same firmware and maps for a long time until we became dependant on CAN), and the original Procede architecture has proven remarkably versatile. So we are now approaching 18 months with no changes to the hardware, and none planned... and we are still adding new things all the time.

    Two different approaches... both work.

    Cheers,

    Adrian
    What is pricing on these processors you are talking about?

  12. #137
    Join Date
    Mar 2010
    Location
    Ellicott City, MD
    Posts
    305
    Rep Points
    106.6
    Mentioned
    4 Post(s)
    Rep Power
    2


    Yes Reputation No
    Click here to enlarge Originally Posted by SSDD Click here to enlarge
    I have to say I learn something nearly every time Adrian posts. Also, thanks to both sides for keeping this discussion civil enough for the rest of us to get something out of it.
    agreed
    Click here to enlarge

  13. #138
    Join Date
    Mar 2010
    Posts
    32
    Rep Points
    0.4
    Mentioned
    1 Post(s)
    Rep Power
    0


    2 out of 2 members liked this post. Yes Reputation No
    Click here to enlarge Originally Posted by Sticky Click here to enlarge
    What is pricing on these processors you are talking about?
    Most of these processors will be well under $20. The thing is you can continue to just go for bigger and better processors, but once you get into high end 32 bit processors, the processor itself is only part of the equation and you need to run special supervisory chips and power supplies and the complete architecture can run up towards $80-100 just for all the parts to use a particular processor architecture.

    For the job we are doing here in a piggy back style tune, a 16 bit processor that can run off just a simple 5V regulator with on board Flash, RAM and preferrably some EEPROM (for storing user settings) is ideal. The best choice (IMHO) is one that has lots of automotive type peripherals like PWMs, Timer channels (Input capture, output compare), UART, CAN, ADC... etc. The basic architecture for this processor incluing power supply etc can be done for $20-30 easily (normally less) in parts. Then by the time you add all the other functions of the PCB (We do alot of protection and filtering in out product) and output drivers, you are up to around $50 in parts. Then buying PCBs, and having them assembled, enclosures etc, you are well over $100.... but in reality, it is the patch loom that costs much more than the unit itself. The patch loom takes some time in manual labour to make and expensive connectors/pins etc.

    But don't be tempted to say the products are overpriced. I am sure that many of you will be thinking we are profiteering to charge what we do. I would be happy to supply you all parts for a Procede at $300... but they will do nothing. We spend thousands of hours designing the PCBs, designing the software and firmware, doing the mapping etc. Given the amount of time we spend, the product is really quite a bargain.

    Adrian

  14. #139
    Join Date
    Nov 2009
    Location
    Simi Valley, CA
    Posts
    8,129
    Rep Points
    9,106.3
    Mentioned
    644 Post(s)
    Rep Power
    92


    Yes Reputation No
    Click here to enlarge Originally Posted by adrian@vishnu Click here to enlarge
    Most of these processors will be well under $20. The thing is you can continue to just go for bigger and better processors, but once you get into high end 32 bit processors, the processor itself is only part of the equation and you need to run special supervisory chips and power supplies and the complete architecture can run up towards $80-100 just for all the parts to use a particular processor architecture.

    For the job we are doing here in a piggy back style tune, a 16 bit processor that can run off just a simple 5V regulator with on board Flash, RAM and preferrably some EEPROM (for storing user settings) is ideal. The best choice (IMHO) is one that has lots of automotive type peripherals like PWMs, Timer channels (Input capture, output compare), UART, CAN, ADC... etc. The basic architecture for this processor incluing power supply etc can be done for $20-30 easily (normally less) in parts. Then by the time you add all the other functions of the PCB (We do alot of protection and filtering in out product) and output drivers, you are up to around $50 in parts. Then buying PCBs, and having them assembled, enclosures etc, you are well over $100.... but in reality, it is the patch loom that costs much more than the unit itself. The patch loom takes some time in manual labour to make and expensive connectors/pins etc.

    But don't be tempted to say the products are overpriced. I am sure that many of you will be thinking we are profiteering to charge what we do. I would be happy to supply you all parts for a Procede at $300... but they will do nothing. We spend thousands of hours designing the PCBs, designing the software and firmware, doing the mapping etc. Given the amount of time we spend, the product is really quite a bargain.

    Adrian
    That is something we can easily agree on. It's the firmware/software that makes the parts come together and do what they do. The development time/non-recurring costs are astronomical.

  15. #140
    Join Date
    Jan 2010
    Location
    Louisville, KY
    Posts
    206
    Rep Points
    91.1
    Mentioned
    0 Post(s)
    Rep Power
    0


    Yes Reputation No
    Click here to enlarge Originally Posted by shiv@vishnu Click here to enlarge
    Nope. It relies on the factory DME's knock control system to trim ignition advance.

    Shiv
    The n54 ecu must be very "adaptive" which is awesome, but it still seems scary.
    This is my signature... Click here to enlarge

  16. #141
    Join Date
    Jan 2010
    Location
    SoCal
    Posts
    119,432
    Rep Points
    32,144.0
    Mentioned
    2107 Post(s)
    Rep Power
    322


    Yes Reputation No
    Click here to enlarge Originally Posted by BadBoostedBmwM3 Click here to enlarge
    The n54 ecu must be very "adaptive" which is awesome, but it still seems scary.
    Eh.. nothing bad has happened thus far and the results have been gone. The factory DME is pretty good but no one is denying that direct control is not important.

    Stage 2 or 2.5 E9X M3 S65 V8 supercharger kit for sale
    : http://www.boostaddict.com/showthrea...r-kit-for-sale

  17. #142
    Join Date
    Nov 2009
    Location
    Simi Valley, CA
    Posts
    8,129
    Rep Points
    9,106.3
    Mentioned
    644 Post(s)
    Rep Power
    92


    Yes Reputation No
    Click here to enlarge Originally Posted by adrian@vishnu Click here to enlarge
    For the job we are doing here in a piggy back style tune, a 16 bit processor that can run off just a simple 5V regulator with on board Flash, RAM and preferrably some EEPROM (for storing user settings) is ideal. The best choice (IMHO) is one that has lots of automotive type peripherals like PWMs, Timer channels (Input capture, output compare), UART, CAN, ADC... etc. The basic architecture for this processor incluing power supply etc can be done for $20-30 easily (normally less) in parts. Then by the time you add all the other functions of the PCB (We do alot of protection and filtering in out product) and output drivers, you are up to around $50 in parts. Then buying PCBs, and having them assembled, enclosures etc, you are well over $100.... but in reality, it is the patch loom that costs much more than the unit itself. The patch loom takes some time in manual labour to make and expensive connectors/pins etc.
    Hi Adrian,

    We are doing a new layout for the N54 tuning cable and also the N55 platform and decided to take your advice on the 16 bit processor. In addition to having native CAN this little PIC has quite a few extra channels for whatever the future holds! Click here to enlarge
    Attached Images Attached Images  
    Last edited by Terry@BMS; 04-27-2010 at 05:42 PM.

  18. #143
    Join Date
    Mar 2010
    Posts
    32
    Rep Points
    0.4
    Mentioned
    1 Post(s)
    Rep Power
    0


    Yes Reputation No
    Nice.... do you research on the CAN. There is more to it than just selecting the right processor.

    You are not making your customers pay extra for features you do not intend to use later are you?? Click here to enlarge TIC!!

    Seriously... as we have worked out in the Procede, you do your best to accomadate any possible feature you may need. The extra cost of the feature is negligable compared to the cost of redesigninh and upgrading customers.

    Adrian

  19. #144
    Join Date
    Jan 2010
    Location
    SoCal
    Posts
    119,432
    Rep Points
    32,144.0
    Mentioned
    2107 Post(s)
    Rep Power
    322


    Yes Reputation No
    Click here to enlarge Originally Posted by adrian@vishnu Click here to enlarge
    The extra cost of the feature is negligable compared to the cost of redesigninh and upgrading customers.

    Adrian
    What does one consider negligible? Extra cost is extra cost.

    Stage 2 or 2.5 E9X M3 S65 V8 supercharger kit for sale
    : http://www.boostaddict.com/showthrea...r-kit-for-sale

  20. #145
    Join Date
    Nov 2009
    Location
    Simi Valley, CA
    Posts
    8,129
    Rep Points
    9,106.3
    Mentioned
    644 Post(s)
    Rep Power
    92


    Yes Reputation No
    Click here to enlarge Originally Posted by Sticky Click here to enlarge
    What does one consider negligible? Extra cost is extra cost.
    The things that Adrian is talking are relatively inexpensive. Extra inputs, outputs, etc, provided by a processor that can support them. It's hard to disagree as there is not much drawback to having extra I/O around. The real decision comes for pieces that add significantly to the cost of production that may or may not be used later. Like say blue tooth integration.

  21. #146
    Join Date
    Jan 2010
    Location
    SoCal
    Posts
    119,432
    Rep Points
    32,144.0
    Mentioned
    2107 Post(s)
    Rep Power
    322


    Yes Reputation No
    Click here to enlarge Originally Posted by Terry@BMS Click here to enlarge
    The things that Adrian is talking are relatively inexpensive. Extra inputs, outputs, etc, provided by a processor that can support them. It's hard to disagree as there is not much drawback to having extra I/O around. The real decision comes for pieces that add significantly to the cost of production that may or may not be used later. Like say blue tooth integration.
    Well then, if it does not shift the JB into some different price category sounds good.

    Why the hell would anyone need blue tooth integration?

    Stage 2 or 2.5 E9X M3 S65 V8 supercharger kit for sale
    : http://www.boostaddict.com/showthrea...r-kit-for-sale

  22. #147
    Join Date
    Mar 2010
    Posts
    32
    Rep Points
    0.4
    Mentioned
    1 Post(s)
    Rep Power
    0


    1 out of 1 members liked this post. Yes Reputation No
    As Terry said, I am talking about adding <$10 cost to the unit. It is a risk decision. We added CAN capability to the Procede many months before we ever connected to the BMW CAN bus. We were paying $1-2 more on every unit to make it to do this based on the assumption that we thought it would be beneficial for us to add it later, and wanted to have it available as a firmware upgrade rather than a hardware upgrade. The risk was that we would not be able to do anything useful with it and then just lose the $$. We have other items in the Procede that currently do nothing but add cost for us. We do intend to use them, and customers will get benefit from this by just doing a firmware upgrade. We also consider it very important that all hardware of a particular revision is identical. We are very much against have several versions of hardware that look the same but have difference inside. So you buy a Rev 2 Procede today, and it will be identical to the first one sold almost 2 years ago. Same applies to Rev 1 and actually there is less differences between Rev 1 and 2 than most people think.

    The difficult thing is working out what things will be beneficial to add now when doing a hardware upgrade. You want to have the capability to use the same hardware as long as possible while not limitting the features you can add to what outdated hardware is capable of.

    We currently have no further hardware upgrade plans including N55 and other applications we are working on (other than harness of course). This could change of course if something unexpected is discovered.

    So you are seeing a compromise between 2 approaches. One approach is to customise hardware to a particular applications as it stands at the current time, and therefore simplify and reduce cost. The other is to try to make the hardware capable of more than the current application and then be able to use a stable unchanging hardware platform to add new features as the applications progresses. Obviously previously BMS took a different approach to us, but then backed it up with their upgrade policy which reduced customer upgrade cost. Not sure currently but seems that BMS may be changing their approach in future atleast to some degree.

    Adrian

Page 6 of 6 FirstFirst ... 456

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may post replies
  • You may not post attachments
  • You may not edit your posts
  •