Knock sensing and Serial USB in software

[mobyfab]

Hi,

It seems most of the tasks are done on hardware, such as knock sensing and additional serial to USB.

Why don't you do these in software?

To me, knock sensing is simply calculating FFT on a buffer, and measuring the value of specific bins (frequency).
Of course there are a few other things to do but in the end it's not that complicated.
It does take some CPU power but the F4 is a beast and could handle that easily.

For the Serial to USB, you can make a composite device and have several serial ports over one cable. (up to 7 on the F4)

Another advantage of using the USB peripheral is that you can make a bootloader.

I have a few code examples if you are interested

Last thing, you should really move to github, it helps people to contribute code

[AndreyB]

I believe we have three questions here, hopefully I would not miss anything

1) knock detection: I do not have time to finish the relatively easy external hardware integration, so there is no chance that I would have time to look at the software implementation any day soon. This simply would not happen any time in 2014 Unfortunately there are not so many sw developers actively involved with this project. That's part of the reason why kickstarter

2) USB: there is a major usability issue in case of MCU reset - see http://sourceforge.net/p/rusefi/tickets/46/ http://forum.chibios.org/phpbb/viewtopic.php?f=16&t=1727

3) http://rusefi.com/forum/viewtopic.php?f=5&t=501

[mobyfab]

That was quick!

1) I could give a hand if you were using Git.

2) You probably need to play with the VBUS to force windows to reconnect. Also might need some delays.

3) Git is really as easy as SVN if you don't do crazy branching. It's just a mater of getting used to it.

Thanks

[AndreyB]

In all seriousness, please just do not mention Git for the next 30 days. I think you are really underestimating the time crunch I am in, so let's just avoid this subject for a bit. While I would appreciate any help possible, I'd rather not commit to anything in exchange.

I am well aware of this

concept but I hope that this is not the case here. I sure might be wrong

[kb1gtt]

I think the issue with GIT is it's poor support in Windows. For those that use a command line, GIT is gold. However most of the world doesn't do the command line. Feel free to do things in GIT, those of us with SVN can make it work. After all we have used GIT before, we just prefer an easy to use tool. GIT is good for very large projects with lots of developers and a very large code base. Any how, enough GIT, lets talk features and make some progress.

About Knock, much like how FFT is a stream lined version of DFT, things like the Goertzel algo are a stream lined version of FFT.

http://en.wikipedia.org/wiki/Goertzel_algorithm

Basically it stream lines things a bit more, making a kind of go / no go output signal. If we are looking for say 5kHz, with a Q of blah, the output from the algo would simply be a 1 if you have had a specified amount of energy for a specified amount of time. A great thing with these algo's are that they only use N and N-1, so minimal memory usage, and the math done each cycle is also minimal, so it typically executes fast and uses little memory.

[mobyfab]

Indeed, Git support in Windows sucks.
I only use command line which I feel is what works best. (Linux and Cygwin for windows)
TortoiseGit stopped working for me, so it's not an option. MsysGit works pretty well.

SVN is so limited for team work that I think sticking with it is will make you loose a lot of support and visibility.

For the Goertzel algorithm, I'll try to come with some implementation for the STM32F4 using DSP.

The FFT+Mag calculation of 3.82ms of data only takes 181us. (256 points at 67khz)
That's not even 5% CPU time.
So sticking with FFT might be a good option.

Thanks.

[kb1gtt]

My concern with 181uS is that the latency could add to other timing critical tasks, like crank capture, or spark / fuel delivery pulses. If you make the FFT lower priority, you run the risk of some odd issues, as the FFT could get out of sync. This is why the Goertzel algorithm are handy, as they can decrease that processing time to far less than 181uS. I once saw an implementation that used a look up table. This allowed the complicated math to be pre-processed such that the algo could be done on some very weak CPU's with a trade off of a small bit of memory.

[mobyfab]

Latency or being out of sync should not be an issue since we are running an RTOS.
Unless things are done really wrong.

This MCU has DSP instructions, it would be a shame not to use them

There is probably a way to implement the Goertzel algorithm using DSP as well.

[Sergey89]

TPIC8101/HIP9011 for example has a sampling frequency about 200 kHz. Who knows what is the reason of a choice this frequency ?

[kb1gtt]

I would think it was something like this. The higher the sample rate the more more math intensive it is, so the more expensive DSP you'll require. To keep costs low, you want to keep the sample rate low. As well more clock cycles often result in more energy consumed by the processor, so extra samples have some negative effects as well. Basically you want to sample at lower speeds instead of higher speeds. Then for sweat spot at about a 5kHz peak in the band pass filter, your Q will determine how much higher than the center frequency you need to go for the mine allowable sample rate. If you sample too low, you get fold back, which effects the in band signals. It would appear that the Q and the fold back forced them to push up to 200kHz.

I seem to recall that if you call and ask about the chip, you'll either find they don't have an engineering department, or you'll find they have an engineer that used to work for the other company. Seems someone bought someone or something like that, and they are really the same thing behind the scenes. I also seem to recall one has a more detailed datasheet, that happens to work with the other one. However that's mostly hearsay and horse shit, so take those comment with a deaf ear.

[mobyfab]

TPIC8101/HIP9011 for example has a sampling frequency about 200 kHz. Who knows what is the reason of a choice this frequency ?

With a higher frequency you get better precision, and you can take harmonics into account, to avoid false positive.