Just off the top of my head how much would I have to spend to con one of your Tech-No Gods to Remote the 4 buttons and dial on an empeg and add some sort of video out Even if it is Mono-chrome. Seeing I am Not William Gates III could I afford it ?


HUmm after reading this Post maybe It can be done

http://empeg.comms.net/php/showflat.php?Cat=&Board=empeg_tech&Number=180046&page=0&view=collapsed&sb=5&o=0&fpart=

While that post might seen promising, this one seems more promising:

http://empeg.comms.net/php/showthreaded.php?Cat=&Board=prodject&Number=159611&page=0&view=collapsed&sb=5&o=0&vc=1

Matthew

By remote the buttons I mean a wired shallow 1/2 Din face with the four buttons and a knob the face plate isn't needed if it has video out put

Remote buttons are doable.. I did it with a little joystick that has all 7 empeg actions (up/down/left/right, knob cw/ccw/push) on one stick, but you just need 7 things that act as switches and a way to convert that into a serial signal. I could possibly put something together for you if you want to email me, [email protected]

I think there was someone else who had component video out working, don't see the thread after a quick search though. Displaying over serial to a VFD like I have and foxtrot is working on is also doable.

This is what I've done (the cig lighter knob is the joystick, the other buttons are for garage doors, display power, and 6 software buttons sent to the Empeg to do whatever with; Display software is set to only use 1/4 of the 256x64 VFD right now):

Whoot half way there now where is that Video out Person
{Looks around)
I could just wait for tony he normally posts the links about 2 seconds after someone tells me about them.\

V99... that is... amazing!

Just need to find a Empeg with a busted VFD and I am 2/3 of the way there,

So did you just use the switch and plug it into the serial connections with a few hacks or did you wire it to the buttons on the front of the unit /

Where did you find the joy stick ??

As far as video out, here Tony FAQ'ed someone else with these links:

Link 1

Link2

So the short answer for video out, no. Go with the serial output like V99 and foxtrot_xray.

There's lots more info in the VFD thread in Projects, and more pictures here...

The short version is that I have a Basic Stamp that reads inputs from the joystick and buttons on its I/O pins and sends out serial characters to the Empeg.. Some simple software runs on the player to read the commands coming in on the serial and send the appropriate button code to Hijack for it to inject to the Player.

There's a bunch of components on the board to convert the joystick's interface into 7 separate signals, and the rest of the board is a switching power supply to regulate car voltage to +5 for the display and circuitry.

The display is just connected to the serial out of the player, a different app sends drawing commands to replicate the Empeg's bitmap. The display I chose is relatively slow (38.4kbps) so some software optimization (beyond "send whatever pixels have changed") is needed to get it to run fast, but it hasn't really bothered me using it in the current state for a several weeks.

I picked this display because it has 4 Empeg screens worth of pixels (to say run 4 apps at once in separate virtual displays), but there are several different size & resolution choices, all of which are faster or at least the same "speed" (baudrate/pixel count). foxtrot_xray chose the tiny one, I also have a medium sized (a little smaller than the Empeg's IIRC) fast (115.2kbps) 140x32 one around here somewhere. There's other ones too, and maybe LCDs.. any graphic module driven by serial can potentially be used.

The joystick is from Grayhill.. It's neat and perfect for this use, but quite expensive (something like $80, and you have to buy many, or annoy them into selling you a sample).

Regarding the second FAQ link above, at least my software is all userland (and gets starved for a couple seconds whenever the player feels like spinning up the drives... need to do something about that). There's still some software to be improved, but it all basically works at an acceptable level for my daily use right now, so I think I'm well beyond preliminary .

Some simple software runs on the player to read the commands coming in on the serial and send the appropriate button code to Hijack for it to inject to the Player.

V99 that's great!

Could you give us more info about the software you created? I'd like to try and adapt it to recognize button pushes from my stock stereo which is converted to serial output using an obd-2 to serial converter.

Could you give us more info about the software you created?

There's really almost nothing to it. I just open the serial port (you could borrow the serial code from gpsapp) and wait for data, then decide what to inject based on what letter I received. All the button code constants are defined in hijack.h. I wrote the basic stamp code to send capital letters for press and the same letter lowercase for release; If you don't handle presses and releases separately then you can't do long presses. U/D/L/R/K for the 5 fascia buttons, + - for knob rotation, and Z/X/C/V/B/N/M for the 7 (only ended up using 6) 'soft' buttons.

The only problem is that the app runs as just another application, so the Player can take all the CPU time and starve it whenever it wants. This usually happens when it spins up the disks, which is usually you're pushing buttons. Then keypresses get queued up in the serial buffer and when the app gets processor time again the actions all get blasted out. It should be possible to give it the same priority as the Player since the button listener app needs virtually no processor time to check for input every once in a long (to the CPU) while, but I don't know how to go about doing that in a way that doesn't stick it in the kernel.. anybody?

unsigned long buttons[2] = { 2, 0 };



serial_open();

displayFD = open("/dev/display",O_WRONLY);



while(1)

{

	got = serial_read(&buf,1);

	

	if ( got > 0 )

	{

		switch ( buf )

		{

		case 'U':	// Up

			buttons[1] = IR_TOP_BUTTON_PRESSED;

			break;

		case 'u':

			buttons[1] = IR_TOP_BUTTON_RELEASED;

			break;

		...

		}

			

		ioctl(displayFD, EMPEG_HIJACK_INJECTBUTTONS, &buttons);

	}



	usleep(10000);

}

Oh, and this doesn't work for bringing up the Hijack menu.. Haven't found a solution to that yet (or really looked...).

This might be a suitable joystick here.

Not the same as V99's but small and cheap.

BTW, V99, NICE job!

-Rex.

If you write the button codes to /proc/empeg_notify, then they will receive full Hijack processing.. menu and all.

The player sets itself to Real-Time priorirty at startup, which is why it runs and your app doesn't run when things are really busy. You may be able to use strace to see exactly how it accomplishes that.

Cheers

I am not a programmer or a electronics (truth be told when I took my electronics courses in school Nixon was still in office) so forgive me if I say something stupid.

Why does it have to be an app is it possible to remove the vfd/face plate and just attach to the same connection points the normal buttons and dial attach to ?

is it possible to remove the vfd/face plate and just attach to the same connection points the normal buttons and dial attach to ?

Please click here.

You could do that if you really wanted to... The display board PIC probably wouldn't like you having long wires though.
Also if you botch it and break the display board then it's going to be expensive to fix and nearly impossible to replace.

This should answer your question:

http://www.riocar.org/modules.php?op=modload&name=FAQ&file=index&myfaq=yes&id_cat=3&categories=Car+installation+questions&faqent=11#11

The pebble remains, Grasshopper.

This might be a suitable joystick here.
Not the same as V99's but small and cheap.

While small, nifty and quite useful for another project I have in mind (thank you for the link!), that one only provides the up/down/left/right buttons, while the $80 one also provides knob press and rotary encoder - all in the same package.

/Michael

SO in a nut shell what I want can't be done for less then the cost of buying a new SUV ?

Well, IIRC I believe PCA said something about presenting three different ways of doing the video out to the client. The one he implemented was the most expensive, but also best, option. No idea as to on what level the other two options would have landed.

/Michael

I also wonder how Hugo made out with his installment of a remote display into his gauge unit?

As was alluded to, it can't be done for less than the price of an SUV if you want it to be contained within the empeg. Buying a tiny pc with video out and having it run VNC to the empeg would be much cheaper, but would take up more room and take a bit more time to boot up.

Matthew

The pebble remains, Grasshopper

Yes, faqmaster, I am not yet worthy to travel the world alone.

The pebble was already gone!

This one time even I, a mortal, beat our amazing FAQ Master to the punch!

"As was alluded to, it can't be done for less than the price of an SUV if you want it to be contained within the empeg. Buying a tiny pc with video out and having it run VNC to the empeg would be much cheaper, but would take up more room and take a bit more time to boot up. "

As for this statement I would gladly Pay 500-1000 to get this done Plug parts I don't really care if it fits inside the empeg or not.



HUmmm if I had a Empeg with a broken Screen and NO sled I could use VNC and get the video out from this
http://www.ibuypower.com/product-pc/pocket-epc2.htm
or one of the other Micro_pc I have seen.
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3433281919&category=1244

Kind of defeats the purpose Maybe the best laid Plans of Mice and Men can not full in my order.. its just too spendy to add video out to a empeg and if you are going to the trouble of installing a PC you might as well just use the PC in the first Place.

Which Brings us to my next questions anyone got a (shivers at the thoought) a Empeg Like software that runs on MS platform or Redhat Suse I think everyone will agree the empge Player software is much better then Musicmatch or Winamp for ease of use.

Woohoo! He's back!

...And really, guys. I'm almost finished! I won't get into details (new house, trip cross country coming up), I've been way too freakin' busy..

In a nutshell, the (my project) display is powered BY the Empeg (or external PSU), and accepts serial (RS-232) input. No processing is done on the Empeg side (except for what to display) - the VFD accepts straight-forward commands to draw/erase/write to it.

No software's been written for it - I tried, and just don't have the knowledge.

Me.

No software's been written for it - I tried, and just don't have the knowledge.

I can put together something using one of the obvious drawing algorithms and playing tag back and forth with you testing it.. For anything more complicated I would definitely need one to work with.

Kind of defeats the purpose Maybe the best laid Plans of Mice and Men can not full in my order

Are you sure you can't use one of the VFDs? They're available in a wide range of sizes, from bigger than the Empeg's (the one I'm using) to really tiny (the one foxtrot's using).. you could put the tiny one almost anywhere (in your instrument cluster perhaps), it's something like the size of a pack of gum. Something like what I've done can easily be done for < $500.

SO are you saying for around 500 Ish plus parts I could have a remote face and remote buttons on an empeg ??

Keep in mind the empeg would be mounted under the passanger side seat and the wires would have to reach 6 to 8 feet (with routing) for the display and controlls ?

Would the remote display be fast enough to switch songs and see play lists ???

My thoughts so far:

Control is already handled by a remote or through the sony stalk.

Video. The fastest interface on the empeg is the ethernet interface. So, we're in need of an ethernet to composite video adapter. Amazingly enough, no one makes one. There are a few video-over-ethernet encoders/decoders, but they're not designed to receive video from a computer. Back to the drawing board (or google search box). What has an ethernet jack and a composite video interface? A videophone. Will it auto answer a call and full screen the video? It sure seems like it from the manual.

Now, the only problem is a H.323 implementation for the empeg that will dial a set IP address, and send the screen contents as the video. My limited perusal of sourceforge hasn't found the right open source project to canabalize yet, but this seems like a good start.

Matthew

The remote display is something I really would like to see. I'm definitely buying a kit with a VFD from Mike when he's ready to sell them. I'm more than willing to be a "beta tester" for any program Vincent writes. I'd also be willing to donate a few dollars so that Vincent can get a kit from Mike to help write/test the program. Any other takers?

SO are you saying for around 500 Ish plus parts I could have a remote face and remote buttons on an empeg ??

I was talking about the parts for someone to make it themselves, but if you're interested in me building a complete solution you can essentially drop in, you should email me and we'll work something out.. [email protected]. The money you're talking sounds reasonable to me for that kind of development.

Keep in mind the empeg would be mounted under the passanger side seat and the wires would have to reach 6 to 8 feet (with routing) for the display and controlls?

My Empeg is in my trunk (see the pics if you're interested).. the only thing connecting it to the display/controller is a long (maybe 12 foot, it's a small car) serial cable. The controller board gets it's power from the console area in my case.

Would the remote display be fast enough to switch songs and see play lists ???

With my current software it averages about 3 frames/second on my display, which is the slowest speed of any of the display choices. There's no problem using menus or text info modes. With better drawing methods I'm slowly working on the speed can be significantly improved and some visuals might work well too. Some of the faster displays can do 25+fps even with the current unoptimized software.

One thing you may not have seen (it's buried in the other thread in a couple places) is that these displays are 1-bit, each pixel is fully on or off. The Empeg display is 2 bit: fully on, dim, dimmer, and off. So the display doesn't look quite as pretty, but it's still perfectly usable.

Control is already handled by a remote or through the sony stalk.

Some (probably adequate) control.. the stalk doesn't provide full functional replication of the fascia controls. I don't think I'm conveying just how cool this joystick is I find it far easier to use than the 4 separate buttons on the Empeg and knob way over on the other side of the car, and I actually use the knob actions now because they're right there for menu navigation instead of reaching up in the air for other controls. If I ever put my Empeg back in the dash I'd still keep the knob.

Video. The fastest interface on the empeg is the ethernet interface. So, we're in need of an ethernet to composite video adapter.

Good luck with that (really), it's definitely an interesting idea but I don't see that being very practical. Speed on the serial connection is only a problem because I've made it one for myself by picking a big high-res display that's annoyingly low speed. There's a 140x32 module (7000-series) about the same size as the Empeg's that runs at 115.2kbps... 115200/(140*32) = ~25fps with the simplest (and least efficient) drawing method you could think of, "10: blast the entire 140x32px bitmap out to the display; 20: goto 10;". I picked a 256x64 that runs at 38.4.. 4x the pixels, 1/3rd the speed, 38400/(256*64) = ~2fps.

There's an old thread on the BBS somewhere about a single-chip ethernet-to-serial-and-pio processor module..

here

Ohh. The Dalsemi TINI is good but they've got supply problems. It's been listed as having a 12 week lead time for ages now. When they first came out, they couldn't even supply enough to fulfill the eval kits.

If you don't mind it not being Java based, the Rabbit modules are pretty good.

I don't know Java, and this thing seems to have a C compiler.
Bonus.

Of course it looks like the Rabbit boards cost a bit more, making it less of a throwaway (in the dash) device.

If you're comparing them based on RAM size then yeah, the Rabbit's are more expensive for what you get.
The RCM3710 or RCM2200 both have $49 modules which would do fine.

I found this ttl to ethernet interface. Don't know if it would be of any use. It's the NPort Express Module DE-311M. Don't know the cost however. It has TTL and supports LINUX drivers.

http://www.scientificdevices.com/moxa.htm

$129 here

The RCM3710 or RCM2200 both have $49 modules which would do fine.

The TINI SDK is free for e.g. me. It looks like I'd need Rabbit's dev kit, which is basically the additional cost of 5 modules. Unless I'm missing something, it's only affordable if I don't want to actually run any code on it.

Ahh okay. I wasn't including the price of the dev kit, just the modules themselves.
If you want to go for the cheapest startup route then you can use an AVR microprocessor, ISA NIC like the RTL8019, AVR GCC for the compiler and uIP for the TCP/IP stack. The programming cable is reasonably easy to make or you can buy them for about $50.

If all this sounds a hassle then you can buy the boards from EDTP. There is source code on there as well which will help you interface the NIC chip to the microcontroller.

I've been looking into this stuff recently as I'm designing an ethernet gateway for a company. It's using a Cypress PSoC CPU however so it's a bit of squeeze on RAM.

Ahh okay. I wasn't including the price of the dev kit, just the modules themselves.

I have 2 cars. Assuming I build 2x as many as I need, I haven't amortized the cost usefully.

It's probably all more work than I have time for now anyway.

Still seems like the cheapest overall solution and most practical is to find some old 486 Single-board computers with ethernet. Anybody have a pile of those somewhere or know where we could find some?

I'm sorry but I have absolutely no clue what you guys are working on here. Is this some way to extend the display using TTY -> ethernet converters?

They are trying to make a remote display so the empeg can be mounted in a glove box or under a seat and still be controlled.

Some (probably adequate) control.. the stalk doesn't provide full functional replication of the fascia controls. I don't think I'm conveying just how cool this joystick is I find it far easier to use than the 4 separate buttons on the Empeg...

I don't disagree. But it's a solved problem. Remote, stalk, custom rotary encoder...

Good luck with that (really), it's definitely an interesting idea but I don't see that being very practical. Speed on the serial connection is only a problem because I've made it one for myself by picking a big high-res display that's annoyingly low speed. There's a 140x32 module (7000-series) about the same size as the Empeg's that runs at 115.2kbps... 115200/(140*32) = ~25fps with the simplest (and least efficient) drawing method you could think of, "10: blast the entire 140x32px bitmap out to the display; 20: goto 10;". I picked a 256x64 that runs at 38.4.. 4x the pixels, 1/3rd the speed, 38400/(256*64) = ~2fps.

Well, I don't disagree. But he really asked for video out, not an external display. If there's some sort of serial -> composite video converter out there, I sure havn't found it. Seeing as an ethernet -> composite video adapter exists, it seems like a more likely option. I don't actually need video out, so this is all academic for me. Find a empeg compatible h.323 implemenation, and you've got video out.

Matthew

If you want a Serial to Composite Video convertor, such devices do exist and to find out more either:
do a search on this BBS looking for "Decade Engineering" or the "BOB II"
or visit This Link for details on their products.

With some software on the Empeg you could easily get a remote display of Track Info etc. You won't get the Video display e.g. visuals or Menu Overlays, but its a start.

The only problem is that the app runs as just another application, so the Player can take all the CPU time and starve it whenever it wants. This usually happens when it spins up the disks, which is usually you're pushing buttons. Then keypresses get queued up in the serial buffer and when the app gets processor time again the actions all get blasted out. It should be possible to give it the same priority as the Player since the button listener app needs virtually no processor time to check for input every once in a long (to the CPU) while, but I don't know how to go about doing that in a way that doesn't stick it in the kernel.. anybody?

Vincent, I was thinking about how you set up your control to empeg interface and how I'd like to set up mine. Is it possible to interface your basic stamp to the tuner serial port instead (inverted TTL) and have it feed this port psuedo-sony stalk packets instead of basic serial commands. This should prevent delayed controller commands and also completely free up the serial port for other uses. Since the empeg is remotely mounted anyway the tuner isn't needed (in most cases).

Is it possible to interface your basic stamp to the tuner serial port instead (inverted TTL) and have it feed this port psuedo-sony stalk packets instead of basic serial commands.

Sounds doable.. there's 2 +-12v pins on the basic stamp that are for normal serial, all the other 16 pins are 0-5 or possibly +-5. I'm not sure that it's entirely as flexible, I'm going to use some of the extra buttons I made to launch apps or toggle what's shown on the screen. Maybe stalk inputs could be ir_translated to fake codes that another application could intercept to do the same thing, that sounds reasonable enough.

This should prevent delayed controller commands and also completely free up the serial port for other uses.

I'm confident the delay can be solved by tweaking the priority, just haven't looked into it yet. I also have a display to drive, so it doesn't save a port unless you use the tuner's serial port for that too; that would be good for the k610a (it's TTL-level anyway), but I don't know if the 7000 or 9000-series (that use full +-12) will work.

Since the empeg is remotely mounted anyway the tuner isn't needed (in most cases).

If you had one before you probably still want it if you're moving the empeg to the trunk..