work in progress hip9011 integration

It's all about the code!
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

hip9011 integration

Post by AndreyB »

All HIP9011 specific magic numbers tables are in https://sourceforge.net/p/rusefi/code/HEAD/tree/trunk/firmware/controllers/sensors/hip9011_lookup.cpp

There is some unit test in https://sourceforge.net/p/rusefi/code/HEAD/tree/trunk/unit_tests/test_sensors.cpp

update: something works!

As of April 2020 we have no idea if that's real knock data or weather on Mars. As of April 2020 a convincing experiment was not yet performed.

Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: hip9011 integration

Post by AndreyB »

I believe all the code for HIP9011 control is ready - https://sourceforge.net/p/rusefi/code/HEAD/tree/trunk/firmware/hw_layer/HIP9011.cpp

Will solder a wire to the output pin & see what it shows first thing in the morning.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: hip9011 integration

Post by AndreyB »

This time it's in Russian but it should not matter. HIP9011 integration works, in the end I am adjusting gain parameter using set_gain X command
[video][/video]
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: hip9011 integration

Post by AndreyB »

Question: real-life testing.

At some point I would probably want to get knock on my test mule Neon (cylinder bore: 87.5mm) so that I can verify that rusEfi in fact detects it. Question: how do I do that? :)

Separate question: for plan-B, would 16022621 or 16052401 or LXE6 or LXE7 or LXE9 work for my bore? This case I can at least test the knock reaction logic before we get out knock detection logic ready.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
34blazer
Posts: 13
Joined: Tue May 05, 2015 12:41 am

Re: hip9011 integration

Post by 34blazer »

russian wrote: there is an opinion that having knock detection react to RPM change and be aware of current shaft angle could or should improve the efficiency, There is hope that we are pretty close, but life is a bit in the way
Not sure what you meant by this? What is "shaft angle?"

There are two methods that I have read about;

The first being a amplifier/bandpass filter, and a conditioner to return a signal to the ECM(U), and probably the simplest method? The narrowband piezo sensor has a small range that is tuned to the natural frequency of the engine, AFAIK. A lot left to be desired with this method considering the sound of the engine changes drastically depending on RPM. I have to guess, but this could also be limited by the sample rate of the processor as well?

The second utilizes a wideband piezo, which would require more code writing to interpret the signals, and would require a faster processing speed?

This is the extent of my knowledge....LOL

I will share some of my observations and thoughts from tuning my own vehicles. False knock is a big issue, especially with an engine that is old and "loose" or has a lot of other noisy parts, such as lifters. Lots of spring pressure will make a lifter noisy, or roller rockers. An exhaust pipe barely touching the frame or body when the engine moves in the engine bay is a noise complaint to the knock sensor, even a noisy pump in the transmission has caused a lot of false knock headaches. The only solution I can fathom is to induce knock and record it, which if I had deep pockets to replace engines frequently then it could be useful data. I look at different types of pistons, whether its the metal composition, structure, or general size, as a bell, each one has its own voice. Figuring out what note the piston(bell) sings at could take a very long time to figure out. The only other way would to reverse engineer what is already out there, the thousands of engineers put a lot of research into developing an accurate way to detect true knock on the big automakers dimes. This brings the challenge of reading the code that is contained in the calibration, which is way, way, over my head. Or I'm just babbling..... :mrgreen:
34blazer
Posts: 13
Joined: Tue May 05, 2015 12:41 am

Re: hip9011 integration

Post by 34blazer »

russian wrote:Separate question: real-life testing.

At some point I would probably want to get knock on my test mule Neon (cylinder bore: 87.5mm) so that I can verify that rusEfi in fact detects it. Question: how do I do that? :)

Separate question: for plan-B, would 16022621 or 16052401 or LXE6 or LXE7 or LXE9 work for my bore? This case I can at least test the knock reaction logic before we get out knock detection logic ready.
The easiest way to induce knock would be to advance the timing until the detonation becomes audible to your ear, GM wrote this into the calibration on older vehicles to test the knock sensor and ESC circuit. Eventually it was phased out, AFAIK, in the late 80's. Be prepared to replace the engine sooner than later :D
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: hip9011 integration

Post by kb1gtt »

Your Neon has a sensor, so i would suggest using it by connecting it to the TPIC / HIP chip.
Welcome to the friendlier side of internet crazy :)
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: hip9011 integration

Post by AndreyB »

34blazer wrote:The easiest way to induce knock would be to advance the timing until the detonation becomes audible to your ear,
Would this work on idle?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
DaWaN
Posts: 51
Joined: Sat Sep 20, 2014 6:54 pm
Location: Benschop, Netherlands

Re: hip9011 integration

Post by DaWaN »

russian wrote:Separate question: real-life testing.
At some point I would probably want to get knock on my test mule Neon (cylinder bore: 87.5mm) so that I can verify that rusEfi in fact detects it. Question: how do I do that? :)
Induce knock in a safe way. I did some reading on this some time ago and I think the safest/easiest way to introduce knock is in low RPM high load areas.
I think it would be a good idea to connect a second knock sensor and connect it to a microphone amplifier and use your laptop to record the sound.
These recordings can be very helpful to determine the knock frequency of your engine.
Personally I would slowly advance timing on the high load cells until knock gets audible.
My tuner used a det-can when tuning my Honda and he could hear knock on high load low RPM cells long before damage was done.
russian wrote: Separate question: for plan-B, would 16022621 or 16052401 or LXE6 or LXE7 or LXE9 work for my bore? This case I can at least test the knock reaction logic before we get out knock detection logic ready.
I cannot find what these Knock module for GM actually do, probably some amplification, band-pass filtering and a comparator stage.
Whatever these modules do they are not configurable.
The HIP9011 does everything for you: amplification, band-pass filtering, integration and comparing the integration results. Not only that: all parameters are configurable! So I see no use of these GM Knock modules.
34blazer wrote: Not sure what you meant by this? What is "shaft angle?"
The integration stage of the HIP9011 can be turned on and off. When using this feature you can listen to the knock sensor only during compression stages, i.e. during certain crank angle windows.
This way you avoid listening to other engine noises and you could detect knock specific to a single cylinder. I think this is meant by shaft angle (correct me when wrong).
34blazer wrote: There are two methods that I have read about;

The first being a amplifier/bandpass filter, and a conditioner to return a signal to the ECM(U), and probably the simplest method? The narrowband piezo sensor has a small range that is tuned to the natural frequency of the engine, AFAIK. A lot left to be desired with this method considering the sound of the engine changes drastically depending on RPM. I have to guess, but this could also be limited by the sample rate of the processor as well?

The second utilizes a wideband piezo, which would require more code writing to interpret the signals, and would require a faster processing speed?

This is the extent of my knowledge....LOL
Yes, this is in line with my knowledge of knock sensors too.
Piezo sensors would require less filtering compared to wide band sensors.
However; the HIP9011 has a digital band-pass filter, so both sensors should work fine with the HIP9011.
There might be some more advantages/disadvantages along with each sensor type, but my knowledge is lacking here (needs some more reading :P )
34blazer wrote: I will share some of my observations and thoughts from tuning my own vehicles. False knock is a big issue, especially with an engine that is old and "loose" or has a lot of other noisy parts, such as lifters. Lots of spring pressure will make a lifter noisy, or roller rockers. An exhaust pipe barely touching the frame or body when the engine moves in the engine bay is a noise complaint to the knock sensor, even a noisy pump in the transmission has caused a lot of false knock headaches. The only solution I can fathom is to induce knock and record it, which if I had deep pockets to replace engines frequently then it could be useful data. I look at different types of pistons, whether its the metal composition, structure, or general size, as a bell, each one has its own voice. Figuring out what note the piston(bell) sings at could take a very long time to figure out. The only other way would to reverse engineer what is already out there, the thousands of engineers put a lot of research into developing an accurate way to detect true knock on the big automakers dimes. This brings the challenge of reading the code that is contained in the calibration, which is way, way, over my head. Or I'm just babbling..... :mrgreen:
Depends on the solution used for knock detection I think. We should get some decent sound recordings from knock sensors and knocking engines.
With the HIP9011 you have proper band-pass filtering and proper windowing (i.e. only listen during certain crank windows or even listen to the engine noise when not compressing and using it as a baseline!).
These are powerful tools against noise from other sources than knock. If the knock has distinct frequency it should not be too difficult to filter it out.
However: I do not know the 'signature' of knock and neither do I know how much it differs from engine to engine.
From what I have read and understand of it, the natural knock frequency gets determined by cylinder bore and shock wave propagation speed. If this is the case it should not be too difficult to determine the knock frequency.
If someone has hands-on experience with determining knock frequency I would be all ears, as I do not have such experience :(
kb1gtt wrote:Your Neon has a sensor, so i would suggest using it by connecting it to the TPIC / HIP chip.
Yes! That should be all you need.
For testing it might also be useful to wire in an additional sensor and/or listen/record the sound of the knock sensor too.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: hip9011 integration

Post by kb1gtt »

About the angle, I believe russian was commenting about windowing.

Most knock sensor chips that I've seen, have some kind of band-pass filter, followed by an energy detector. Such that you listen to a certain range of frequencies and you then measure how much energy you have detected for those frequencies. These band-pass filters are relatively sloppy, and you'll be sensing a wide range of noise. Pretty much anything you can hear, so will the knock sensor. However the knock sensor can have some additional sensitivity to a particular set of frequency(s). You will need to measure the normal noise, of the engine, then you'll compare this typical noise to the noise measured in a windowed area around the spark event. If you see an increase in noise, you know that you have had a knock event. The typical noise floor will vary with RPM load and such.

I have not seen narrow or wide band knock sensors, just a microphone that's very similar to your PC's microphone. This microphone catches audio frequencies below about 20kHz. I understand the knock or ping frequency is based on the natural frequency of your block. AKA hit a nail with a hammer, both lightly and harder. You should see the same pitch or frequency, but at a different amplitude. I understand the ping frequency does not change with RPM, just the amplitude. I understand the ping frequency will be around 5kHz to 7kHz-ish.

I'm not sure if you can generate a ping at idle. I'd say you have to try. I suspect it would be hit or miss if you can. You'll have to try and see what happens. You should minimize the chances of damage at idle. Just advance the timing until you either hear a ping, or it stalls. Also a warm engine is easier to get a ping. As well you can probably hear it better when at idle, as the engine will be quieter. For initial testing you can simply tap the engine with a screw driver, small hammer, really any small hard object will allow you to mimic a ping.

Long term I can suggest you adjust the TPIC's gain to keep the average energy at a certain level, then after that you can simply detect when ever the energy is above a threshold. For now you first need to get a ping going.
Welcome to the friendlier side of internet crazy :)
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: hip9011 integration

Post by AndreyB »

Made some progress but the whole thing does not look right. Hopefully once the assembled boards arrive somebody would be available to look into this...

Image
Image

new commands http://rusefi.com/wiki/index.php?title=Manual:Software:dev_console_commands#Knock_Detection
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Spilly
contributor
contributor
Posts: 64
Joined: Thu Jul 31, 2014 11:30 pm

Re: hip9011 integration

Post by Spilly »

My lack of computer science knowledge has hindered me but I have finally managed to get a grasp on this project. I'm used to configuring I/O in source code for the microcontroller. The requirement to set the I/O in Tuner Studio took me a while to figure out.

This is the first time I have worked on a project of this scale, so I apologize in advance if this not the correct way for submitting code.

Here are a few changes for the HIP/TPIC driver.

Added command bits and added real time prescaler update.

Pastebin link: http://pastebin.com/hTsD5rdv
void hipAdcCallback(adcsample_t value) {
if (state == WAITING_FOR_ADC_TO_SKIP) {
state = WAITING_FOR_RESULT_ADC;
} else if (state == WAITING_FOR_RESULT_ADC) {
if (adcToVoltsDivided(value) > engineConfiguration->hipThreshold) {
totalKnockEventsCount++;
timeOfLastKnockEvent = getTimeNowUs();
}

int integratorIndex = getIntegrationIndexByRpm(engine->rpmCalculator.rpmValue);
int gainIndex = getHip9011GainIndex(boardConfiguration->hip9011Gain);
int bandIndex = getBandIndex();
int prescalerIndex = engineConfiguration->hip9011PrescalerAndSDO;

if (currentGainIndex != gainIndex) {
currentGainIndex = gainIndex;

//added CMD bits
tx_buff[0] = SET_GAIN_CMD + gainIndex;

state = IS_SENDING_SPI_COMMAND;
spiSelectI(driver);
spiStartExchangeI(driver, 1, tx_buff, rx_buff);
} else if (currentIntergratorIndex != integratorIndex) {
currentIntergratorIndex = integratorIndex;

//added CMD bits
tx_buff[0] = SET_INTEGRATOR_CMD + integratorIndex;

state = IS_SENDING_SPI_COMMAND;
spiSelectI(driver);
spiStartExchangeI(driver, 1, tx_buff, rx_buff);
} else if (currentBandIndex != bandIndex) {
currentBandIndex = bandIndex;

//added CMD bits
tx_buff[0] = SET_BAND_PASS_CMD + bandIndex;

state = IS_SENDING_SPI_COMMAND;
spiSelectI(driver);
spiStartExchangeI(driver, 1, tx_buff, rx_buff);
} else if (currentPrescaler != prescalerIndex) {
currentPrescaler = prescalerIndex;
tx_buff[0] = SET_PRESCALER_CMD + prescalerIndex;

state = IS_SENDING_SPI_COMMAND;
spiSelectI(driver);
spiStartExchangeI(driver, 1, tx_buff, rx_buff);
} else {
state = READY_TO_INTEGRATE;
}
}
}
static void setPrescalerAndSDO(int value) {
engineConfiguration->hip9011PrescalerAndSDO = value;
//this can be changed real time
//scheduleMsg(logger, "Reboot to apply %d", value);
showHipInfo();
}
With a constant input from a function generator, the TPIC's output is consistent from a simulated 1000 rpm up to 7000 rpm. The output does vary with rpm, but the output only differs by 100's if not 10's of millivolts.

I have not had any luck with Chibios SPI full-duplex drivers yet. I am currently working on eliminating the need for an ADC pin by receiving the digital integrator output in advanced mode. I will be digging further in the next few days.

I will also be taking a look at windowing.

Please let me know if there are any other functionality requirements/wants.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: hip9011 integration

Post by kb1gtt »

Great and thanks, as well keep up the good work.

I need to install a knock sensor on my test mule to try and debugging knock sensor stuff with live hardware. Have you been able to do live testing of this code?

About the IO thing, many engine setups have a hard coded pin out, but you can change it via TS. So it kind of has both configurable and hard coded IO.
Welcome to the friendlier side of internet crazy :)
Spilly
contributor
contributor
Posts: 64
Joined: Thu Jul 31, 2014 11:30 pm

Re: hip9011 integration

Post by Spilly »

kb1gtt wrote: I need to install a knock sensor on my test mule to try and debugging knock sensor stuff with live hardware. Have you been able to do live testing of this code?
That's another project for my summer break. My poor project car and shop have been neglected for about 8 months now.

The current driver appears to be listening only once per cycle. I will take a look at that next. Ideally the number of configured cylinders will determine the number of listening windows per cycle.
kb1gtt wrote: About the IO thing, many engine setups have a hard coded pin out, but you can change it via TS. So it kind of has both configurable and hard coded IO.
I wasted lots of hours trying to figure why the changes I made in TS and/or in the code would show up intermittently. I just discovered (no pun intended) an hour or so ago that my stm32 board seems to require two full power cycles for all the registers to update. I'm not sure if my cat has caused some ESD damage to the Discovery board or if something else weird is going on.
Spilly
contributor
contributor
Posts: 64
Joined: Thu Jul 31, 2014 11:30 pm

Advanced More Digital Integrator Output (Full-Duplex SPI)

Post by Spilly »

I have successfully configured the driver to receive the digital integrator output from the TPIC when operating in advanced mode.

Primary changes were here:
static void endOfSpiExchange(SPIDriver *spip) {
spiUnselectI(driver);
float knockVolts = 0;
switch (spiCount){
case 0:
state = GET_SPI_DATA_TWO;
spiCount ++;
break;
case 1:
state = GET_SPI_DATA_THREE;
//D7-D0 of digital integrator output
firstBits = rx_buff[0];
spiCount ++;
break;
case 2:
state = GET_SPI_DATA_FOUR;
spiCount ++;
break;
case 3:
state = ALL_SPI_DATA_REC;
spiCount = 0;
//D9 to D8 of digital integrator output followed by six zeros
lastBits = rx_buff[0];

knockLevel = lastBits<<2;
knockLevel |= firstBits;

if(knockDebug){
scheduleMsg(logger, "first = %d", firstBits);
scheduleMsg(logger, "last = %d", lastBits);
scheduleMsg(logger, "total = %d", knockLevel);
}
//convert 12-bit digital integrator output to voltage
knockVolts = knockLevel * KNOCK_VREF / 1024.0f;

if (knockVolts > engineConfiguration->hipThreshold) {
totalKnockEventsCount++;
timeOfLastKnockEvent = getTimeNowUs();
}
break;
case 9:
state = READY_TO_INTEGRATE;
spiCount = 0;
break;
}
}
Primary changes also here:
void hipAdcCallback(adcsample_t value) {
//if (state == WAITING_FOR_ADC_TO_SKIP) {
//state = GET_SPI_DATA_ONE;
//}
/**
* In advanced mode each control/response pair of commands
* requires two full 8-bit shift cycles to complete a transmission.
*/
if(state == GET_SPI_DATA_ONE){
tx_buff[0] = SET_PRESCALER_CMD + engineConfiguration->hip9011PrescalerAndSDO;
state = IS_SENDING_SPI_COMMAND;
spiSelectI(driver);
spiStartExchangeI(driver, 1, tx_buff, rx_buff);
} else if(state == GET_SPI_DATA_TWO){
tx_buff[0] = SET_PRESCALER_CMD + engineConfiguration->hip9011PrescalerAndSDO;
state = IS_SENDING_SPI_COMMAND;
spiSelectI(driver);
spiStartExchangeI(driver, 1, tx_buff, rx_buff);
} else if(state == GET_SPI_DATA_THREE){
tx_buff[0] = SET_CHANNEL_CMD + 0;
state = IS_SENDING_SPI_COMMAND;
spiSelectI(driver);
spiStartExchangeI(driver, 1, tx_buff, rx_buff);
} else if(state == GET_SPI_DATA_FOUR){
tx_buff[0] = SET_CHANNEL_CMD + 0;
state = IS_SENDING_SPI_COMMAND;
spiSelectI(driver);
spiStartExchangeI(driver, 1, tx_buff, rx_buff);
} else if (state == ALL_SPI_DATA_REC) {
//if (adcToVoltsDivided(value) > engineConfiguration->hipThreshold) {
//totalKnockEventsCount++;
//timeOfLastKnockEvent = getTimeNowUs();
//}

int integratorIndex = getIntegrationIndexByRpm(engine->rpmCalculator.rpmValue);
int gainIndex = getHip9011GainIndex(boardConfiguration->hip9011Gain);
int bandIndex = getBandIndex();
int prescalerIndex = engineConfiguration->hip9011PrescalerAndSDO;

if (currentGainIndex != gainIndex) {
spiCount = 9;
currentGainIndex = gainIndex;

//added CMD bits
tx_buff[0] = SET_GAIN_CMD + gainIndex;

state = IS_SENDING_SPI_COMMAND;
spiSelectI(driver);
spiStartExchangeI(driver, 1, tx_buff, rx_buff);
} else if (currentIntergratorIndex != integratorIndex) {
spiCount = 9;
currentIntergratorIndex = integratorIndex;

//added CMD bits
tx_buff[0] = SET_INTEGRATOR_CMD + integratorIndex;

state = IS_SENDING_SPI_COMMAND;
spiSelectI(driver);
spiStartExchangeI(driver, 1, tx_buff, rx_buff);
} else if (currentBandIndex != bandIndex) {
spiCount = 9;
currentBandIndex = bandIndex;

//added CMD bits
tx_buff[0] = SET_BAND_PASS_CMD + bandIndex;

state = IS_SENDING_SPI_COMMAND;
spiSelectI(driver);
spiStartExchangeI(driver, 1, tx_buff, rx_buff);
} else if (currentPrescaler != prescalerIndex) {
spiCount = 9;
currentPrescaler = prescalerIndex;
tx_buff[0] = SET_PRESCALER_CMD + prescalerIndex;

state = IS_SENDING_SPI_COMMAND;
spiSelectI(driver);
spiStartExchangeI(driver, 1, tx_buff, rx_buff);
} else {
state = READY_TO_INTEGRATE;
}
}
}
HIP9011.cpp


HIP9011.h


I also added a command to the dev console which, when enabled, prints the digital integrator information.
Image
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: hip9011 integration

Post by AndreyB »

Spilly wrote:Added command bits and added real time prescaler update.
Wow, this bug with missing command bits was breaking changing values on the fly! Thank you for the fix!!!

I've just commited this change.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: hip9011 integration

Post by AndreyB »

Spilly wrote:I'm used to configuring I/O in source code for the microcontroller. The requirement to set the I/O in Tuner Studio took me a while to figure out.
Technically you can define everything via the source code - see dodge_neon.cpp for example, see http://rusefi.com/wiki/index.php?title=Manual:Engine_Type

I will commit your second change later today or tomorrow. Once again, thank you very much - it's an amazingly nice surprise to get help, especially with this place I am struggling with. I also need to shoot a video of how I test this on a bench so that you maybe would clarify what I do wrong, because I do not understand part of what's going on.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Spilly
contributor
contributor
Posts: 64
Joined: Thu Jul 31, 2014 11:30 pm

Re: hip9011 integration

Post by Spilly »

russian wrote:
Spilly wrote:I'm used to configuring I/O in source code for the microcontroller. The requirement to set the I/O in Tuner Studio took me a while to figure out.
Technically you can define everything via the source code - see dodge_neon.cpp for example, see http://rusefi.com/wiki/index.php?title=Manual:Engine_Type
Yet again my lack of experience with projects of this scale and using eclipse was the issue. I wasn't digging deep enough into the code to figure out how to set I/O in the source code.
russian wrote:I also need to shoot a video of how I test this on a bench so that you maybe would clarify what I do wrong, because I do not understand part of what's going on.
I would be happy to take a look. You can imitate your knock sensor with a function generator. Just set the function generator to output a sine wave at the same frequency as your engine's resonant knock frequency.

If you don't have a function generator, you can use your computer as a function generator with audacity (http://web.audacityteam.org/). Audacity will let you create a tone at a specific frequency. You will need to cut up a headphone cable in order to wire your computer's audio output jack to the TPIC/HIP input.

I made a few changes so that once the knock output level is greater than a user configurable threshold level ignition advance is decreased. Also, the user can configure a maximum amount of ignition advance that can be subtracted while knocking.

My current implementation is a fairly crude way of doing this but it's a start.

advance_map.cpp


engine.h


hardware.cpp


HIP9011.cpp


HIP9011.h


I will update this thread with more information later. My eyeballs are turning to mush from staring at this screen all day.
Spilly
contributor
contributor
Posts: 64
Joined: Thu Jul 31, 2014 11:30 pm

Re: hip9011 integration

Post by Spilly »

Here is a patch for today. I will be updating this post with information on the changes later tonight.

Patch


Edit:
External knock sensor adc calculated voltage, TPIC8101 digital integrator, and HIP9011 adc calculated voltage are all referenced against the same configurable threshold.

Each consecutive engine cycle that knock occurs, one degree of ignition advance is removed. Ignition advance is decreased until the configured maximum value is reached. If knock previously occurred, and the engine goes one cycle with no knock, one degree of ignition advance is added. Ignition advance is added when not knocking until the initial (before knocking) ignition advance is reached.

If a HIP9011 is being used, the set_knock_ic dev console command must be used. By default the TPIC8101 is enabled.
set_knock_ic 0 = HIP9011 (looks at adc for knock control)
set_knock_ic 1 = TPIC8101 (looks at digital integrator value)

To set the minimum voltage threshold for a knock event, the set_knock_threshold dev console command must be used. The default value is 4.0 volts.

To set the maximum number of degrees of ignition advance that can be removed while knocking, the set_max_knock_sub_deg dev console command must be used. The default value is 20.0 degrees

In the next few days I plan to make the knock control a PI (proportional and integral) control loop. The information used in this control loop will most likely be based the amplitude of the knock signal and the number of engine cycles.

I need to learn how the offsets in the tunerstudio files work, so can make these additions accessible through TS.

If anyone has any suggestions, please let me know.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: hip9011 integration

Post by AndreyB »

That's some cool progress :)

I've moved some of the fields into the configuration & explained what I did @ http://rusefi.com/forum/viewtopic.php?f=5&t=10&p=15698#p15698 and commited the knock logic.

Did not merge the digital output yet, need some sleep and then I will read it,

Thank you a _lot_!
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: hip9011 integration

Post by kb1gtt »

Some suggestions,

Decrease the angle by the 1 degree rate as you are doing, but increase at .1 or some smaller amount. This helps minimize the knocking.

Also I understand the ambient noise will vary with engine RPM, which means if you tuned your knock at say 2kRPM, you may be backing off the timing erroneously at 5kRPM, as it will be noisier as the lifters and such are making more noise. I suggest creating an ambient noise floor table based on at least RPM, perhaps based on load, as well. Then decrease if you are blah above that noise floor.

I understand flat tappet cam's will look very much like a ping. Windowing can help with this, but you might also need to change the window as you increase RPM. The valves with springs can add a specific time delay from when the CAM releases the valve, which can stretch out the angle when the noise happens. Especially if they start to do that high rev vibration thing. So it would probably be cool if the window could be varied based on RPM and perhaps load.

Keep up the good work, and thanks for the contributions.
Welcome to the friendlier side of internet crazy :)
Spilly
contributor
contributor
Posts: 64
Joined: Thu Jul 31, 2014 11:30 pm

Re: hip9011 integration

Post by Spilly »

kb1gtt wrote:Some suggestions,

Decrease the angle by the 1 degree rate as you are doing, but increase at .1 or some smaller amount. This helps minimize the knocking.

Also I understand the ambient noise will vary with engine RPM, which means if you tuned your knock at say 2kRPM, you may be backing off the timing erroneously at 5kRPM, as it will be noisier as the lifters and such are making more noise. I suggest creating an ambient noise floor table based on at least RPM, perhaps based on load, as well. Then decrease if you are blah above that noise floor.

I understand flat tappet cam's will look very much like a ping. Windowing can help with this, but you might also need to change the window as you increase RPM. The valves with springs can add a specific time delay from when the CAM releases the valve, which can stretch out the angle when the noise happens. Especially if they start to do that high rev vibration thing. So it would probably be cool if the window could be varied based on RPM and perhaps load.

Keep up the good work, and thanks for the contributions.
Do you think it would be overkill to implement two configurable multipliers, one for decreasing timing while knocking and the other for increasing while not knocking.

The noise floor is something I have been pondering. I have seen the lookup table solution before and if the engine's ambient noise is consistent for a given RPM, that should work fine. Constantly normalizing the noise floor should take care of inconsistencies.

However, I'm interested to see if we even need to adjust triggering parameters with RPM. The other algorithms I have seen for the TPIC8101 and the HIP9011 use fixed time constants. To see why this is a bad idea, give TPIC/HIP a constant input from a function generator and then vary the RPM (varying the RPM changes the integration time). If the time constant from the TPIC/HIP is fixed, the output will vary dramatically with RPM. If the time constant is adjusted appropriately with RPM, the output from the TPIC/HIP will be fairly consistent. You can prevent the time constant from being changed by disconnecting the SCK, SDI, or CS lines or making changes to the source code.

Variable valve timing and and the situations you explained make a varying window a must.
Spilly
contributor
contributor
Posts: 64
Joined: Thu Jul 31, 2014 11:30 pm

Re: hip9011 integration

Post by Spilly »

russian wrote:That's some cool progress :)

I've moved some of the fields into the configuration & explained what I did @ http://rusefi.com/forum/viewtopic.php?f=5&t=10&p=15698#p15698 and commited the knock logic.

Did not merge the digital output yet, need some sleep and then I will read it,

Thank you a _lot_!
Thanks! I will try to get a better understanding of it in the morning.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: hip9011 integration

Post by AndreyB »

Spilly wrote:set_knock_ic 0 = HIP9011 (looks at adc for knock control)
set_knock_ic 1 = TPIC8101 (looks at digital integrator value)
I've changed this part a bit, the commands are
enable tpic_advanced_mode
disable tpic_advanced_mode
enable knockdebug
disable knockdebug

added to http://rusefi.com/wiki/index.php?title=Manual:Software:dev_console_commands#Knock_Detection
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
DaWaN
Posts: 51
Joined: Sat Sep 20, 2014 6:54 pm
Location: Benschop, Netherlands

Re: hip9011 integration

Post by DaWaN »

Spilly wrote: However, I'm interested to see if we even need to adjust triggering parameters with RPM. The other algorithms I have seen for the TPIC8101 and the HIP9011 use fixed time constants. To see why this is a bad idea, give TPIC/HIP a constant input from a function generator and then vary the RPM (varying the RPM changes the integration time). If the time constant from the TPIC/HIP is fixed, the output will vary dramatically with RPM. If the time constant is adjusted appropriately with RPM, the output from the TPIC/HIP will be fairly consistent. You can prevent the time constant from being changed by disconnecting the SCK, SDI, or CS lines or making changes to the source code.
The sound of knock has little to do with a function generator creating a constant tone during the knock watch window.
Of course this will yield different integration results as the window for higher RPM is much smaller compared to lower RPM.

I actually wonder whether there is actually so much of a difference in acoustic energy compared to RPM. I think it is more related to the amount of torque and in general that is kind of flat over RPM.
A knock event is one uncontrolled combustion and will not generate a constant tone during the knock window. Remember the knock frequency is already fixed over RPM!
I think you should base the implementation on either recorded engine knock sounds over a wide RPM range or some sort of paper showing actually measured data and not on a function generator generating a constant tone.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: hip9011 integration

Post by kb1gtt »

This page includes the audio signal captured from a knock sensor. http://home.netcom.com/~bsundahl/knock/sound/KnockSounds.htm#Knock
Welcome to the friendlier side of internet crazy :)
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: hip9011 integration

Post by AndreyB »

[video][/video]
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: hip9011 integration

Post by AndreyB »

[video][/video]
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: hip9011 integration

Post by AndreyB »

kb1gtt wrote:How do you have this wired? Is that a 2 wire sensor? I think you have a 3 wire. I wonder if we are getting buggered because we followed the TPIC datasheet. Perhaps we should remove R161 and R162.
I have KS return going to GND and KS SIG is my input
Image
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: hip9011 integration

Post by AndreyB »

Attached I believe a http://rusefi.com/wiki/index.php?title=Vehicle:Kia_Spectra_2005 OEM ECU picture, note that it uses TPIC8101

I believe ECU#54 is GND, same as TPIC#2 and TPIC#16. Resistors on top-left of TPIC are 100K, then 121K, then another 100K.
Attachments
tpic8101_on_OEM_ecu.jpg
tpic8101_on_OEM_ecu.jpg (1.42 MiB) Viewed 27415 times
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Post Reply