http://www.pctestinstruments.com/

Only downside is that it does not run under directly under Ubuntu / Linux. However, it does just fine inside a VMWare virtual WinXP machine on top of Ubuntu.

So that’s my trick, old Windows hardware can be run (mostly) inside a virtual machine on top of Ubuntu. For sure, the Logicport seem very happy to run this way.

Jim

Yes, whatever the sensor “hears” is directly applied to the comm. pin. This is both good and bad. Makes the response from the sensor harder to deal with since it’s not a direct encoded distance. The upside is, the sensor provides a whole lot more information. It’s possible to “see” multiple return echos with this setup. I always wondered if Bosch took advantage of the extra information returning from each sensor. Probably not is my guess.

2)

No. The sensors are pinged with a large 150 to 160 volt square wave. Any more voltage will damage the sensor. Have you felt the surface of the sensor as it’s pinging. Brush the surface lightly with your finger tip and you should be able to feel it. Or, with the sensor pointed upward, rest one end of a pencil on the surface while you lightly hold the other end. You should hear a clicking sound on each pinging event. You can hold a pinging sensor up to your ear and hear a distinctive click. However, I don’t recommend that considering how much sound energy is coming out of the sensor. So, to generate the sound waves, the sensor face is actually deforming much like a loud speaker. Crazy to think that the piezo element is actually flexing the aluminum surface of the sensor.

The return echo is a millivolt signal coming off the sensor that is run through an analog filter & gain. The result is then applied to an analog to digital converter in the micro. The micro then applies thresholds to the values coming out of the analog to digital converter based on time. Close objects have a high threshold than far away objects. This is all done to try and eliminate noise.

By hotter all I mean is that the thresholds are lowered to allow more detection. The downside is, of course, you get more detection of junk you don’t want like pot holes and curbs. It’s a balancing act between noise and detection.

The corner sensors are basically de-tuned and the bulk of the detection is done with the center two sensors. In fact, I’m now noticing Ford has some cars on the road that only have two sensors.

I ask GM if they were interested in us investigating a two-sensor solution as a cost reduction. Nope, too much work for the poor GM engineers to think about. I regress.

Anyway, hope that helps. Sounds like your making progress.

Good luck,
Jim

Also, do you have any Logic Analyzers you would recommend?

Thanks!

1) By “actual echoes” do you mean simply an instantaneous pulse where the sensor pulls the comm line low?

Also, you mention there is a different init string for the outside/inside pair of sensors where you theorize it is to establish a hotter gain on one versus the other.

2) Would the “higher gain” be a larger voltage across the transducer?

Between each burst of pulses there is a big dwell / dead-time. This is easy to see by looking at the last picture above.

If your using a micro to receive the pulses just use a timer to measure the dead-time. Once the timer hits a threshold you’ll know your in the dead-time area. Reset your pulse counter and your now synced and ready for the next burst.

In fact, after processing a set of pulses, I would call a micro function to wait for, and re-sync to, the dead-time again. That way, even if there is a glitch that goofs your pulse decode logic it won’t matter because between each set of pulses the decode logic in the micro will re-sync.

Well, to be a 100% bullet proof, I guess you might want to also have a pulse violation logic. So, if the decode logic misses a transition the whole burst of pulses should be ignored. Any singe pulse, by definition, should be in the range of 1 to 2ms. On any pulse outside the 1 to 2ms window, invalidate the whole group and call the re-sync logic.

With this approach, the decode logic can detect pulses too short and too long. The micro can keep a log of these timing violations to help with debug. On any timing violation, just jump to re-sync logic.

Luckily, on any decode problem, another set of pulses is just 20ms away which we can re-sync to.

Hope that helps,
Jim

I suspect the problem may be with your Atollic installation of v3.0. My original work was done with v2.0.1.

I know Atollic made a lot of changes going to v3.0. The big change was, Atollic introduced a code-size limit (32k I think). That makes me crazy given how large the code space is on the F4 chip! I sent an email to Atollic pointing out how bad this idea is. I sent that email at least a month ago and I’ve gotten zero response. Makes me sad. The Atollic Lite package was perfect for folks to get started with Discovery board. OK, I’m getting into a rant here. I’ll stop.

I was going to suggest installing v2.x but now I comment #6 above from sjwilks who indicated he got it working with v3.0 “First Time”.

Does your installation work completely with an Atollic example program? In other words, use the Atollic wizard to build a skeleton / example program. If I remember right, there is an Atollic example that blinks an LED on the Discovery board. Can you get that to work? That would prove out the basic install of all the Atollic pieces and parts.

Once your sure Atollic is working at a 100% then make sure you extract my zip file into your Atollic workspace directory. Atollic should automatically show the new project in the project panel. If you don’t put my code in your “workspace” your just going to have problems.

If the Atollic examples are compiling and working and you dump my code into your Atollic workspace area everything should work. If not, let me know and maybe we can brainstorm some other ideas to try. Seems it’s always something silly that keeps things from working.

Good luck,
Jim

I downloaded Atollic TrueSTUDIO V3.0.0 Lite and your sample code and tried to compile it. I get a compilation error:

..\stm32f4xx_it.c:1:0: error: target CPU does not support ARM mode

If I run the compiler again this error moves to a different file, such as debug.c or heap_1.c. I have followed all the steps that you described but this error has stymied my efforts.

Are you aware of any obvious error I might be making?

Cheers,

Peter