Introduction to RaceCapture
Moderators: JeffC, rdoherty, stieg, brentp
Dean, for a special application the system could easily burst into RAM, then later write the data to the card at a slower rate. Of course, how long it can burst all depends on the amount of data per sample.Dean924s wrote:Hummmm For my application I need 1,000-1,500 per second. 100 per second just wont cut it 300 was the absolute minumum and it was really not acceptable.
Hummmmmm Brent can you shed some light on this?
Dean, what you're doing is not really at odds with RaceCapture's main goals. Also, as we discussed before, variation of the firmware might make RaceCapture suitable for your application, so it's fine to describe what you're doing to put your desired logging rates in context.
Thanks for asking first, and yes, we would naturally prefer the discussion to ultimately remain on topic for RaceCapture!
Thanks for asking first, and yes, we would naturally prefer the discussion to ultimately remain on topic for RaceCapture!
I also wanted to see how my RPM and boost was reacting to try and capture the hiccup in the engine not just analyze air/fuel.cng1 wrote:Sampling a wideband quicker than 10Hz would be a waste of time due to the response rate of the sensor. Selecting a 10Hz sample rate seems entirely appropriate for that purpose.
I have tried to find a specification on sensor response rate but could not find anything. I would be interested to know what the actual specification is for the maximum sample rate of a wideband sensor though. I have been told before that 100Hz is possible on wideband.
Cheers
In theory an LSU sensor may give data at sample rates at up to 50Hz. What you should remember is that there is a lag of around 100ms in the sensor and furthermore that there is a delay in the exhaust gas getting from the exhaust valve to the sensor. In reality you dial in a stabilisation delay of about 200ms as a rough approximation and sample at 10-20Hz and accept that it's the best compromise you can do without a whole load of complexity.
In a nut shell we have developed a hand held devise that will record the pressure variances in a motor. This then can be graphed generating a "profile for that particular cylinder / motor. The need for high rates of data are due to the events happening very quickly. You will litterly miss max and min readings with sample rates in the 300-500 samples per second range.cng1 wrote:1KHz really is an awful lot of data to be recording. I suspect that if you're just looking at a couple of channels you may be able to crank the data rates up but 100Hz is far more than most applications need. Do you mind explaining what your intended application is?
If you want to see more look here>>>> http://www.emotorsports.org/prod01.htm
Respectfully
Dean
Dean
-
alpine-jeff
- Posts: 8
- Joined: Wed Feb 11, 2009 3:58 am
- Location: Northern California
Where and When??
Hi all,
I'm quite new to the whole electronic ignition world and RaceCapture in specific, but I'm very intrigued and would like to get my hands on one. I have Spelunked throughout many, if not most, of your pages and can't seem to locate a 'buy' page. It appears that the Squirt products are sold through a channel, which is all good, but the Capture line appears to either be too new or using a different disty model. So please accept my apologies for being stupid and kinda new to web retail, but I'd love to learn more about the capture and how best to put my greenbacks to work. -- AJ
I'm quite new to the whole electronic ignition world and RaceCapture in specific, but I'm very intrigued and would like to get my hands on one. I have Spelunked throughout many, if not most, of your pages and can't seem to locate a 'buy' page. It appears that the Squirt products are sold through a channel, which is all good, but the Capture line appears to either be too new or using a different disty model. So please accept my apologies for being stupid and kinda new to web retail, but I'd love to learn more about the capture and how best to put my greenbacks to work. -- AJ
Hello Jeff,
RaceCapture is not yet available as it is currently in testing. We are accepting requests for Beta Testing. See the official info and announcement here: http://www.autosportlabs.net/RaceCapture
The Megajolt system is currently available, see our online store ("Store" link above or http://www.autosportlabs.com)
I've also followed up to your email inquiry- Thank you for your interest!
Regards,
RaceCapture is not yet available as it is currently in testing. We are accepting requests for Beta Testing. See the official info and announcement here: http://www.autosportlabs.net/RaceCapture
The Megajolt system is currently available, see our online store ("Store" link above or http://www.autosportlabs.com)
I've also followed up to your email inquiry- Thank you for your interest!
Regards,
more info 
Hi Matthew,
After a much needed yet brief vacation we're back at work. Here's a status on RaceCapture.
We're near 100% on hardware testing of the unit. So far, we are satisfied with the design. For an upcoming "Rev B' board, one area, the digital outputs, will be going under review- we may swap out the ULN2003 we are currently using with a different design, perhaps discrete transistors or mosfets.
Currently our accelerometer is designed to be tethered to allow flexible placement of the RaceCapture unit while allowing the accelerometer module to remain square with the vehicle. As an alternative, we're looking at providing the option to mount the module internally. While this makes for more convenient packaging and reduces costs a bit, it does restrict the placement of the unit. The tethered vs. internal poll is about 50/50. Another benefit of the internal module is it frees up the expansion port for other uses, such as I/O expansion.
We are also adding a 4th accelerometer axis, Yaw (Z-Axis theta), based on feedback, and discovering it would be an extremely simple addition to the hardware. Production design of the accelerometer module is underway- we're currently testing with a rather-ugly prototype board. On this front we're quite excited: after the dust settles we will have a class-leading acceleration sensing solution!
Finally, we're lining up our production supply of GPS modules. These will be nice, weatherproof units with magnetic bases, offering 32 channels and 5Hz update rate.
Firmware on the unit is 75%: we can log all sensor channels to SD at at least 100Hz. GPS and accelerometer interfaces are working nicely. We are focusing mostly on configuration capabilities, API, misc. utilities, and one really cool, yet-to-be announced feature.
For software, we will initially we will offer a basic PC Viewer/Analysis package, just to get people started, and expand from there. There are a few other cool things on the PC software side we're planning- more on that later.
We've lined up a good cross-section of rev-A beta testers, and we will be able to get units out in a few weeks. Following that testing we'll incorporate feedback, spin a Rev-B board and then decide to do a 2nd, expanded beta, or just go live.
Hope this helps bring some clarity.
Thanks,
After a much needed yet brief vacation we're back at work. Here's a status on RaceCapture.
We're near 100% on hardware testing of the unit. So far, we are satisfied with the design. For an upcoming "Rev B' board, one area, the digital outputs, will be going under review- we may swap out the ULN2003 we are currently using with a different design, perhaps discrete transistors or mosfets.
Currently our accelerometer is designed to be tethered to allow flexible placement of the RaceCapture unit while allowing the accelerometer module to remain square with the vehicle. As an alternative, we're looking at providing the option to mount the module internally. While this makes for more convenient packaging and reduces costs a bit, it does restrict the placement of the unit. The tethered vs. internal poll is about 50/50. Another benefit of the internal module is it frees up the expansion port for other uses, such as I/O expansion.
We are also adding a 4th accelerometer axis, Yaw (Z-Axis theta), based on feedback, and discovering it would be an extremely simple addition to the hardware. Production design of the accelerometer module is underway- we're currently testing with a rather-ugly prototype board. On this front we're quite excited: after the dust settles we will have a class-leading acceleration sensing solution!
Finally, we're lining up our production supply of GPS modules. These will be nice, weatherproof units with magnetic bases, offering 32 channels and 5Hz update rate.
Firmware on the unit is 75%: we can log all sensor channels to SD at at least 100Hz. GPS and accelerometer interfaces are working nicely. We are focusing mostly on configuration capabilities, API, misc. utilities, and one really cool, yet-to-be announced feature.
For software, we will initially we will offer a basic PC Viewer/Analysis package, just to get people started, and expand from there. There are a few other cool things on the PC software side we're planning- more on that later.
We've lined up a good cross-section of rev-A beta testers, and we will be able to get units out in a few weeks. Following that testing we'll incorporate feedback, spin a Rev-B board and then decide to do a 2nd, expanded beta, or just go live.
Hope this helps bring some clarity.
Thanks,
Oh Oh Oh 100 Hz Can you go faster? Have you tried? Can I try?
First off Welcome back!!!!!!
This "feature" would not be what we spoke of the other day would it?. If it is I would be really interested in making this work on my Porsche.
Can you go faster? Have you tried? Can I try?Brent,and one really cool, yet-to-be announced feature
First off Welcome back!!!!!!
This "feature" would not be what we spoke of the other day would it?. If it is I would be really interested in making this work on my Porsche.
Respectfully
Dean
Dean
You're funny.
Well, If I recall correctly (don't hold me to it, it was quite a while ago) I've tested logging a few data points at 1000 Hz to SD, but it would requiring disabling most things. I have 48MHz and 32 bits to work with, but there are limits! As before, for your application it could be designed to burst very quickly to RAM and then write more slowly to SD Memory.
The 'cool' features I'm alluding to haven't been discussed in this thread..
Well, If I recall correctly (don't hold me to it, it was quite a while ago) I've tested logging a few data points at 1000 Hz to SD, but it would requiring disabling most things. I have 48MHz and 32 bits to work with, but there are limits! As before, for your application it could be designed to burst very quickly to RAM and then write more slowly to SD Memory.
The 'cool' features I'm alluding to haven't been discussed in this thread..
I know but was it the thing that you eluded to me that it could do when we spoke on the phone? Cause that would be MORE THAN COOL!!!!!!!brentp wrote:The 'cool' features I'm alluding to haven't been discussed in this thread..
BTW I got the MJLJ all properly installed on my P car and lets just say it is now scary fast. I have to update my install thread with the specifics of the changes I made.
Respectfully
Dean
Dean