My Miata has (until I've found an amp to install the Empeg with) the speed-sensitive audio system. Is there a way to have the Empeg use the speed input for something? I have no idea how the speed signal is coded (probably just proportional voltage). It'd be cool to have the Empeg adjust the volume to the speed I'm driving at, or change some visuals with the speed or whatever.

There is not currently any way to do that, however, people have talked about the idea a lot, often focusing on how to determine the speed. It's interesting to note that your car has such a signal built-in, and it might inspire some hackers to do something about this.

Speed-controlled volume has been talked about before... Some have proposed using GPS or OBD-II interfaces for the speed input. Since your Miata has its own speed signal, I guess you'd have to do some homework to either look up the specs or reverse-engineer them and interface them to your empeg... Haven't seen anyone doing this already around here.

OBDII is really easy to do, there's a lot of knowledge and software out there to access that connector to tap into the vehicle speed sensor.
When I install my Empeg (have had it for many months, but haven't found the right amp yet), I'll check out the speed wire to see what input the radio gets. I'll post my results here!

Cool, a guy who wants to be part of the solution rather than just bringing up problems. Good to have you aboard.

I checked with miata.net and found the following:
The Miata's speedometer pulsed signal is generated by an internal switch to ground (if I recall correctly, 4 grounding pulses per revolution of the speedometer cable).
Is there a way to use that?
BTW, here's an interesting thread about the same topic from about a year ago.
Is there any news on microphone use for either volume control via ambient noise or voice recognition? I found some discussions on the board, but nothing definitive...

Is there a way to use that?

Yes. One way to do it would be to create an electronic module that interprets this data and then sends ASCII speed information to an RS-232 serial cable. Then you would write a piece of software on the empeg to read the RS-232 serial cable and do the appropriate things depending on the information it received.

As you can see, this is not a simple project, but it can be done. No one has done it yet.

As I said in another thread, though, I'm wondering if that would be overkill. Since the empeg is just line-level output, wouldn't it be simpler to just make a generic speed-controlled or ambient-noise-controlled "attenuator box" with line level inputs and outputs? You could do the whole thing analog and wouldn't even need to write software for the empeg to do it.

You'd think someone would already have made something like this. Has anyone done an internet search to see if such an animal already exists?

Yes, that sort of thing has been discussed on other boards as well (e.g. here).
It makes sense, but with the Empeg you have more options. For example, you can have the user choose to have linear or exponential increase of volume with speed and at what proportion. With the Empeg being a computer, it's more flexible. The in-line attenuator is certainly easier to make, but also less sophisticated. Haven't looked for it, yet, but I will.

I went by my local car audio shop today and was talking about navigation systems... The person I usualy deal with is fairly knowledgeable, and said that for the Alpine nav unit ($2000+screen) they tap the spedometer wire, and it reads that... So, this would lead me to beleive that alpine has a rather surefire way to get the speed reading from most cars on the road today? Does anyone have access to the install manuals for their nav unit to see how they do it for most cars?

Matthew

Maybe I am missing something here but once the GPS signal is received, isn't speed automatically calculated as a function of the GPS? At least on my unit it is.

However, I have something called a HKS type-1 Turbo Timer on my car (http://www.hksusa.com/products/more.asp?id=845). Among other things, it calculates performance measuring metrics like 0-60 mph, 1/8 and 1/4 mile times (sorry, big performance metrics in the U.S.), etc. When I installed it, one of the connections was to the speedometer lead on the ECU so obvioiusly the signal is available and this unit can go on any car. I have not idea what the pulse looks like to it seems to be the same for most if not all cars. I'll try and put a scope on the signal and see if I can get a digital picture to post.

I believe on the more expensive nav systems they use extra inputs like the speedo signal or accelerometers to supplement the GPS data so they can keep following you even when you're not seeing the satellites for short periods.

Yep, thats how mine works. Dead reckoning allows it to be more accurate than just using the GPS signal.

The signals come in 2 flavours according to my nav manual, either pulsed or a voltage which increases with speed. If you only have a mechanical speedo you can fit a transducer which gives 4 or 8 pulses per revolution.

But the big problem is the input to the empeg, According to Hugo, if you use both the mute line and the light sense, there are no free GPIOs left to use.

Maybe the new tuner will resolve this.

Then, of course, someone still needs to write the code to make use of the signal

Yes, you are exactly right. I should have thought of that.

Most recent cars already have a speed sensor wire present in the connector for the radio (european cars anyway).
If not, it can usually be tapped into an ABS sensor or into the speedo itself (like old models miata and those without the special audio system).
On my '91 miata I hooked it up at the speedo. On the Mercedes, I tapped into the right front ABS sensor wire.
Even if you have an old car without ABS or with a mechanical speedo, there are little boxes available that you can connect the the speedo cable (at the gearbox).


Frank

Frank is right on the money here. Most cars post 1990 have speed signals (Vss) available all throughout the car.

Many cars have the Vss signal at the back of the OEM radio, at the ABS sensor, traction control, idle speed control, ECU, cruise control amplifier, etc. etc. The list goes on and on.

Virtually all cars generate a square wave Vss signal based on magnetic reactance sensors at the rear differential (for RWD cars anyway). Sometimes the raw signal is sent to the speedometer for processing and distribution to the res of the car.

It would be extremely easy to build hardware to decode the Vss signal and output it as an ASCII value for an RS-232 port. I could do the hardware in a few hours. But I have NO idea how you'd incorporate this into th Empeg.

In any case I would be interested in having this feature, as it is helpful to have speed sensitive volume.

-oktane

Oktane: "It would be extremely easy to build hardware to decode the Vss signal and output it as an ASCII value for an RS-232 port. I could do the hardware in a few hours."

That'd be fantastic! Maybe with a switch for 4 vs. 8 pulses per revolution? Well, that may better be implemented on the software side, of course. This would be such a cool feature with a lot of potential 'customers'. I'm sure we could find a nice coder to write a kernel hack for it, once the hardware is there! (With some help on how to do something like that, I may be able to do it - but I bet there'll be someone much better than me around).
Would you be willing to post instructions on how to build a little device like that?

What year Miata do you have? I have a 2001 and have not been able to figure out a way to get rid of the alternator whine I am getting through the speakers. It is very low, and most bothersome when I am listening to soft passages and/or talk radio. Have you encountered similar problems with your install?

Thanks!

What I'd like to see is a piece of hardware that tripped a small solid-state relay whenever the speed dropped below 30mph.

That way, I could silence my radar detector whenever I was driving in a store parking lot. It would then not give me the false alarms from the automatic door openers.

Wonder how tough that would be to do?

Admit it! You're trying to reenact Speed

- Trevor

Well, I do think Sandra Bullock is pretty cute.

Wouldn't be hard to do.

Best way would be to have the 'lower' limit settable so that the 30mph is not fixed.

Heh, Some folks might also want it cut out above a certain speed e.g. 90+ mph.

Once you get to those sorts of speeds, any distractions (like a Radar alarm) is the last thing you want to be bothered with!

I'd build such a device using a small micro-processor so that the features you want could be built in easily without resorting to soldering irons.

Hmm, Do I sense an add-on board for Patricks Tuner?

If there were a simple way to do it with as few parts as possible, I would implement it. But that's a different tangent than a serial data interface...

edsmiata: What year Miata do you have?

A 1996 M-Edition. I haven't found a good amp for it yet, though, so it isn't installed. What amp did you use and where did you install it? My problem is that I want a stealth install, where the amp is not in the trunk. At the same time the amp needs to be big enough to power the ten speakers I have in the little thing.

If there were a simple way to do it with as few parts as possible, I would implement it. But that's a different tangent than a serial data interface...

I think all the wishes expressed in this thread could be met by a cheap PIC microcontroller and a small handful of discrete components. The hardware could be implemented on stripboard with a total cost of about £10.

The downside is that someone has to write the PIC code and others will need to somehow program their own PIC.
On the upside, it would be simple & cheap, the wheel circumference & pulses per revolution (or most likely, some user calculated magic number) could be input over the serial IF using a laptop and stored in the PICs EEPROM thus avoiding the need for custom code or DIP switches etc. Spare pins on the PIC could be pre-programmed to change state at preset speeds e.g. 30mph, 50mph, 70mph and so on.

Is anyone going to design this? Well, I think Octane said above that he might. Failing that I will set about tackling the design in about a month's time (I am currently on about day 7 learning all things PIC). In any event, I suspect most seasoned PICers with an armoury of reuseable code could accomplish this in an afternoon.

I used an MTX 4244 4 channel with the two front channels powering the door separates and the two rear bridged to power my 8 inch JP audio sub. But like I said I get horrible alternator whine and was curious if it was particular to the Miata, given the rather cramped dash!

Hmm, Do I sense an add-on board for Patricks Tuner?

I doubt you need one. Bear in mind that the tuner kit has 4 12-v compatible inputs, which can be read from the empeg end, as well as a pair of 12-v outputs. If the speed sensor is outputting a speed-proportional pulse train, it may be as simple as polling the correct input fast enough and converting the vaules to a speed.

pca

Interesting point Patrick about the 12v inputs/outputs on your new tuner design.

I must admit I'd forgotten those extra features.

Questions:

1. Are the 12v compatible inputs ADC or normal inputs? Or are they switchable between ADC and normal inputs?

2 Has the PIC chip software in the Tuner been extended to allow reading/writing these inputs/outputs? [I'd assume so].

3. Is there any code space left in the PIC chip code space and Flash RAM area itself for a extra functionality?

My idea/suggestion is this [if possible/worthwhile to implement].

Extend the PIC software in the Tuner a little to allow one of the 4 inputs to be designated as the 'speedo input'

Have the Empeg/Tuner serial protocol extended to allow the input pin 'pulses per Unit of distance' to be settable from the Empeg [e.g. by user input in Hijack or in config.ini or similar].

These 2 values (speedo input pin and pulses per whatever) are saved in Flash RAM on the PIC - assuming there is room - and are reloaded at each restart of the Tuner module

Note:

In reply to:

---

Sidebar on easily calculating pulses per whatever for your car:

The correct pulses per whatever value for your car would have to be determined by each user for their type of vehicle as all speedos and cars are different.

It could be determined simply by having an [as yet unwritten] Speedo control/display Userland App, be able to show the reported pulse count when pulses per whatever is set to 1.

Then by driving to a safe, known & steady speed e.g. 50mph, you can determine the value for pulses per m p.h. by dividing the shown value by your current speed.

This value after the division will give you the number of pulses per mph for your cars speedo.

If you read the value at 50 kph (or 100 kph), then the value after division is pulses per kph for your cars speedo.

This could be a Hijack menu option to show this pulse count value similar to the Hijack Button Codes display (e.g. report each new value and scroll older values off the display) to allow quick and easy reporting of the pulse count from the Tuner.
[we want Hijack modified anyway so thats something else in the to-do list].

---

The Tuner PIC Chip meanwhile, using the [last set / remembered] 'pulses per whatever' value, continuously counts all pulses on the speedo input pin and reports (asyncronously, no more than once a second, or every n seconds - where n is possibly settable ala the Speedo input pin number and pulses per whatever values are) the "current speed" of the vehicle as a integer value over the serial wire using the Empeg/Tuner serial protocol.

Where the "current speed" value is the number of pulses received since the last measurement, divided by the number of seconds since the last measurement [or since the Tuner was powered on if no last measurement since power on], divided by the current pulse count to whatever 'conversion factor'.

Thus this would be giving an averaged speed value to the nearest mph or kph as appropriate [with the averaging time specified as the value of 'n' seconds or at least to 1 second].


We then extend Hijack to report the received speed value sent to the Empeg over the Tuner interface via a /proc/empeg_speed special file [which should be simple to do since Hijack already speaks the Empeg/Tuner serial protocol].

So that all and any Userland apps can read the current speed value and take whatever appropriate action to e.g. Ramp up/down the Volume according to your personal preferences or Turn the Radar detector on/off as specified by the user according the their rules.

the userland app could also calculate (average) acceleration using the change in velocity and could also calculate distances by summing the (current speed * time) values etc.

This would also allow the speedo input to be used for Dead Reckoning when your GPS is offline.

If the Pulses per whatever was set to zero [the initial/default 'out of the box' setting], then all this functionality would be disabled in the Tuner, and hijack should be able report this fact, so that UserLand apps can distringuish if needed between really being stopped (e.g. 0mph) and the feature not actually being enabled and/or Tuner not present.

I think this idea would be a useful addition to the new Tuner, and might be done with only a few additional lines of code in the PIC chip and some minor code in Hijack.

I'd suggest it might even be implemented as a optional 'add on' chip for those folks that want this feature.
i.e. chip your Tuner for more performance (info) :-)))

I figure this feature on its own might make those folks who want a Speed controlled Empeg even more likely to buy your new tuner.


Now I don't know if the current Tuner PIC chip could handle all this or not, but if it could it might \become the new Tuners killer feature [other than providing Radio and Stalk support of course].

If not then that was why I commented about a add-on board for the Tuner to do all this and report the speed back over the same Tuner/Empeg serial link.
This would be useful as it would not need to tie up your existing Serial port if you had a dedicated device, and all the power and other stuff like control and signal wires are all there in the tuner already so no need to reinvent most of the wheel.


Note this device/idea of using speedo pulses would onlybe able to measure/report "speed" and not "velocity".

"speed" in a strict technical/physics sense is a "one dimensional vector" value, velocity has both "speed" and "direction" - we don't/can't know the direction so we can only report the "speed".

So, If you drive your car backwards the pulses won't report this fact, so the speed value will always be 0 or a positive value - never a negative value.

I know I'm asking for features for something that doesn't exist yet, but I've always wanted to be able to input a number (ie 70mph) and have something beep at me when I go above that. I have a bad habit of going like 20-30 over the speed limit and not even realize it

Number6: that's a fantastic post! There's a host of possibilities in there now and I'm sure someone with the necessary abilities will find it interesting enough to help us out! I can code a little bit, but not good enough for kernel hacks :-(

Hi bjoern (Björn?)

My empeg is installed in a 1991 Miata. I use the left "tunnel" in front of the trunk for my amp, totaly stealth and I loose none of the precious usable Miata space. I had to look around alot before finding an amp small (actually narrow) enough to fit in there. Luckily, I only needed a two channel amp and I am very happy with the Genesis Stereo 60 that I finally decided on.

With ten speakers, a single Stereo 60 will not do it for you, right? But you can use both tunnels. Also check out the Memphis amps, they make a number of narrow models. I cound't find any source for Memphis in Sweden though so they where not an option for me.

Jo då, det är Björn :-)
At the moment I'm thinking about either a 6ch amp somewhere near the glove compartment (unsure if it'd fit) or two 4ch amps in both tunnels. I'll check out the amps you recommended! Thanks! If you have more tips (like pics of your install), I'd be happy if you'd email me ([email protected]) or make a new miata-thread so we can keep this thread speed specific. I'd love to have the speed signal doing something in my Empeg!! :-)

I installed my amp in the left tunnel too. Pics are on my site: http://come.to/miata

Frank

Great pictures! I just got a Memphis amp off Ebay to go right there! Thanks guys!
Now as for the speed input, that would almost be too good (hint, hint :-)

Good luck with the install!

The metal panel that has to be removed to get to the tunnels can be a royal pain in the butt. I didn't have the needed torx tool to remove the hardtop fittings and had to bend the panel to get it out. If I have to do it again, I would get the tools first, :-/.

Anyway, let us know how it turns out!

If the speed sensor is outputting a speed-proportional pulse train, it may be as simple as polling the correct input fast enough and converting the vaules to a speed.

I wasn't paying attention to this thread, but then it dawned on me that the sensor issues are the same as with a rally computer. Earlier this yeat I installed a sense wire (tapped into the VSS wire going to speedo) and in the research for that it seemed like most everything out there now was a pulse, switch-to-ground. These aren't consistent b/w different cars, so our rally computer uses a base pulse rate and has a calibration feature (you input a car-specific factor based on indicated versus true mileage).

This page has a few examples of VSS inputs

A local gent who wrote his own rally calculator software also put this example of a very simple VSS-to-serial input on his page. Not sure if it would be of any help to anyone, but there it is.

With the rally computer we've been using, we've found the VSS to be a little fickle, so we are going to add a switched sensor like this and use VSS as a backup. Same switch-to-ground principle, same need to calibrate.

Hmmm with all these new input possibilities, will I need to get a tuner even though I won't use it for radio???

Those are totally sweet links! Now soldering the necessary hardware shouldn't be a problem - anyone volunteer to port the software to our needs?