I'm now trying to figure out how I'm going to remotely display the empegs VFD for my M3. I found this post where Hugo seemed to think extending the cable wouldn't be a problem (strangely enough it was for a 98 M3 also with the display in the same spot). I think extending the display is my best option with the empeg in the glovebox particularly since I'm already using the serial port (and need another). It means I keep all the button functions too.

I have the skills, tools and resources to build a buffered interface no problem if necessary but I need the pinout for the display cable to even attempt this. Can one of the empeg guys help out please? Perhaps RobS could scan just the connector part of the schematic?

And yes I have read the FAQ entry.

No, I can't post segments of the schematics as I am under an NDA which prevents me from doing this.

WIthout trying to sound too much of a grump, I am not sure I like the way I have suddenly become "The Source" of schematic material. I have not got permission to do this, and would prefer that people stop asking about it. It sounds rude saying it this way, but I simply can't - end of story.

If you wish to have information about the schematics that are not already public domain, then can I suggest you get in touch with Hugo instead as only he can authorise this sort of thing.

Fair enough. I think you are considered the source simply because we know you have them and are the most active here. I apologise for even asking then.

I don't actually want schematics, just the pinouts for the display cable. Is that sort of information considered in the "schematics". I was hoping someone would see the post and help me out rather than having to individually ask people.

I'll try and dig this out in the next couple of days. The issue with extending the cable is that 4 of the signals (pixel data, pixel clock, line clock, frame clock) are direct out of the StrongARM, at 3.3v levels, and some are pretty fast (>1MHz).

Just extending the cable may well not work, as the clock will get out of shape. You really need to buffer these. Patrick definitely did this in the past for a customer, I think he used some RS485 buffers but I could be wrong. Patrick?

Hugo

That would be fantastic if you could get me the pinouts Hugo. Thanks.

I accept that buffering the signals is going to need buffering and I was probably going to do that anyway. RS485 buffers is a good idea - I've never thought of that before. The drivers we use are slew rated limited for EMI (limited to something like 150kHz) from memory which is possibly why it didn't click. It's definitely a good idea but I'll see what else I have lying around.

Hopefully everything is unidirectional too.

I'll also see if I can get permission to release the pdf's of the schematics for mk1, mk2 and mk2a as these would be useful to the community as a whole. I'm impressed by those who have been buzzing some of this stuff through to work out the wiring (eg, in the IBUS thread!)

Hugo

It wasn't quite as simple as just RS485 buffers, but that's on the right track. All the lines MUST be buffered if they are to go outside the box, and also need filtering for both radiated and received EMI, as well as spike protection. A number of lines go directly to the SA1100, which doesn't cope well with spikes or signals over 3.3V.

The pinout of the connector on the motherboard is:

Pin 1: LCD bus bit 0 (unbuffered, 100R series resistor)
Pin 2: GND
Pin 3: Pixel clock (unbuffered, 100R series resistor)
Pin 4: GND
Pin 5: Line clock (unbuffered)
Pin 6: Control line to PIC
Pin 7: Frame clock ((unbuffered)
Pin 8: GND
Pin 9: LCD BIAS signal (used to generate heater voltage for VFD)
Pin 10: IR RX line from CIR unit
Pin 11: IRDA RX line
Pin 12: GND
Pin 13: IRDA TX line
Pin 14: VCC3 (fused 1A)
Pin 15: VCC3 (fused 1A)
Pin 16: VCC5 (fused 1A)
Pin 17: VCC5 (fused 1A)
Pin 18: GND
Pin 19: DC IN (fused 1A, pulled to GND via 12K)
Pin 20: DC IN (fused 1A, pulled to GND via 12K)

Note that if you get it wrong, ie 5V or DC IN shorted to any signal lines, you WILL kill the SA1100, and possibly nuke other components as well. The same may well apply if the power rails are shorted together.

It's certainly possible to extend the cable if it's done right. My board set was designed for a 3M extension, and has been tested with a 100M cable successfully

pca

Awesome, thanks Patrick. I assume everything is 3.3V (excluding VCC3, VCC5 and DC-IN of course).

I now have to ask questions

1) Is DC-IN just the raw supply from outside the empeg i.e. basically battery voltage input on the empeg?

2) Which of these are inputs/outputs/bidirectional?

Pin 1: LCD bus bit 0 (unbuffered, 100R series resistor)
Pin 3: Pixel clock (unbuffered, 100R series resistor)
Pin 5: Line clock (unbuffered)
Pin 6: Control line to PIC
Pin 7: Frame clock (unbuffered)

I can't see how data (i.e. button presses) come back from the PIC unless "Pin 6: Control line to PIC" is actually a line coming back or some are bidirectional.

3) So pin 10 is simply one way async serial coming back from the display 38kHz receiver?

4) Pin 9: LCD BIAS signal. Should I just pass that straight through or should it be "analogue" buffered?

5)
Pin 11: IRDA RX line
Pin 13: IRDA TX line

So RX is heading towards the StrongArm?

All the LCD lines are output only. The PIC comms line is, I think, unidirectional. Button presses are actually encoded as IR signals, and sent down the CIR RX line. The IRDA RX line is an input, the TX is an output. The LCD Bias line is a digital signal, basically a square wave drive. The DCIN line is fed straight from the conditioned external DC power. All signals are 3V.

pca

Thanks again. That should get me going on a design at least.

Quote:
The PIC comms line is, I think, unidirectional.

That could be a bit more of a hassle to buffer then. Are you sure?

Quote:
All signals are 3V.

I assume you mean 3.3V?

Note that you almost certainly don't need the two IRDA lines, unless you're using Palantir

Yeah thanks. I had initially excluded those but it comes down to whether I have spare buffers and how I do the connecters/cabling.

If it's possible with minimal work I'd put them in but otherwise you're right it's not worth it. I only ever used the IrDA transceiver once while playing with my Nokia phone.

I think we may try an extension board as well. Christian, did you ever get something going with this?

Stu

I'd definitely be interested. I've said several times that if one was determined enough, an empeg could be installed in just about any dash. Now that I've been tossing around the idea of buying a Jeep Wrangler, I'm not sure I would want it there. It would be used for a fair amount of trail driving, possibly in very wet conditions with the top down. There's also the risk of theft with having a ragtop. I was thinking it'd be nice to install it in a waterproof steel lockbox (would have to figure out ventilation) with a display extension.

Except for personal challenge do you guys think this is worth pursuing? How many of you would like a display extender?

Stu

I personally don't need a display extender, but I just love the idea of replacing this FAQ entry with a link to Eutronix.

I would get one depending on price. Maybe $100-150 for assembled board with ribbon cable and maybe $200-250 for board + lcd? Can it be done at that price?

I can forsee future demand being much higher than for digital sound cards, what with cars becoming more and more integrated.

The real killer app would be composite video or VGA output. So that I could run GPS without losing my empeg.

I don't think we would go the video route, but maybe if only for fun we would take a crack at a board extender. This would just be a buffer and interface board with neccessary termination resistors, and EMI/surge elements, etc.

Stu

If the price was right I would buy one just to put away for a rainy day, when I wanted to install in a car that didn't have room in the dash.

I'd be interested in one.

I'd buy one for my GF's install and one for me for a future install. This could solve a lot of install problems in cars without DIN. Combined with a steering-wheel controller interface, you could put the empeg in the trunk. A small display that could go by the instrument panel would be ideal. Leave the factory head-unit in and run the empeg output to the factory aux-in or CD in.

Jim

Anothing interesting concept, similar to the extended display, would be to create a small black box that could wirelessly send signals to a remote display unit. This way, you could install the player out of sight (trunk / boot / glove box / under a seat / etc.) and still have the display and controls available as a small "velcro attached" removable object, similar to a removable face radio.

Possible??? I would certainly be interested in a device like that for future installs!

I did some googling and people have made very small bluetooth displays like this one.

Can someone point me in the right direction to start learning how to do something similar? Is there some kind of "bluetooth on a chip" that gets a person started? I imagine the "rendering the display information" is the tough part. Is an entire computer needed for this kind of thing?

It would be really cool if one could make a remote display and control so that the PDA would not be necessary. The project I linked to above suggests that this could be pretty small. Doing the same thing but adding 4 buttons and a knob is what I'm thinking.

FWIW,

Jim

Interesting. You can get a very small PCB that is a bluetooth serial terminal.

You can also get a VFD with a built-in serial controller.

It seems to me that hooking these together would give a person a remote bluetooth display which could be controlled via the empeg's serial port (which was connected to a bluetooth adapter).

That doesn't solve the problem of sending button presses and knob turns back to the empeg though.

I'm going to bed. Interesting stuff. Sometimes I wish I'd been an EE instead of an ME.

Jim

That's what I was afraid of. Is it possible to send the controller a new image, then trigger the display, then refresh the image, etc.?

This one (see attachment) does most everything including keyscanning of a keypad.

Edit: to get back on topic. YES! I am desperate to get an empeg mounted in my truck. At a guess I might need 8-12ft of remotness.

PS if a custom housing is needed to house the remoted display. I can design it and get it made.

Well, as some of you may remember this is something I did about two years ago... and then got out of college, got a job, other priorities, and more or less disappeared. I'm probably never going to have time to improve this, but it's been good enough that I've used it in my car of all that time without being annoyed enough to change it. So if other people are still interested in it, you might as well start where I left off...

Source, and docs on the various VFDs that I have: http://applesolutions.com/Empeg/remote/

Pictures of it getting into my car: http://gallery.applesolutions.com/v/vincent/hardware/Empeg/Trunk+Mount/

The software was written over, oh, maybe a weekend; There's lots of room for optimization in the drawing. The main ugly bit is that the Empeg writes out the boot log to the serial during boot; Since my display doesn't run at 115.2k, it comes out as garbled junk. It's mainly for the 3900 (specifically the 256x64D one), but it looks like I started working on a 7100 too because the command set is almost the same. The k610a is rather different, and the 800 that you're linking too looks different too, but you can just change the implementations of the drawing calls to send the right commands.

For input, I found a neat Grayhill joystick that has the 7 empeg actions (up/down/left/right, knob+/-/push) all on one knob. A Basic stamp and a couple transistors and gates convert it's output into serial character presses that are sent to another app running on the empeg. It gets unresponsive when the player is particularly busy, kinda lame. The rest of the board in the pictures is a switching 12->5vdc transformer to power everything.. the display is just connected straight to the empeg's serial line.

I'll be glad to help wherever I can if you have any questions.. I'll try to check the forum, but probably best to email me: [my first name] at godaddy dot com

--
Vincent

Thanks! I'm going to look through this. Why is the serial connection so slow in your implementation? Is this a hardware limitation of your design? How could this be corrected/avoided?

Here's the question I have:

If the remote display is driven by the serial connection, how is it possible to also have buttons which send signals on the same serial connection? Why doesn't the display driver hardware monopolize the serial connection?

Thanks again. I'm definitely going to try to build one of these things. If anybody who knows how to hack the kernel is interested, maybe we can do this together.

Jim

The VFD I chose (GU256X64D-3900, because it's slightly under DIN-sized and -shaped, and has exactly twice the res of the Empeg in each direction) has a max speed of 38,400bps. If you want faster, pick a different display.. the 7000s are 115.2kbps, although as far as I remember it won't really work that fast because it starts reporting itself as busy and ignoring you if you're using the speed to do bitmap drawing. Some models (3900 included) have parallel input too, so you could theoretically use a parallel<->serial converter to drive it at 115.2 or 230.4. Drawing speed wasn't particularly important to me, aside from being an interesting optimization problem. I don't need visuals when I'm driving, and most of them look lousy in 1-bit 'color' anyway.

The display uses only the serial output, and the joystick uses only the input. There's no conflict. Some of the VFD models can send data back to you, but they don't tell you anything particularly useful.

You don't need to hack the kernel to make it work, although it would be helpful for a variety of reasons (suppress the serial output on boot, increased priority to update the display, etc).

I've decided to revisit this idea as I now have some spare time to do so. I was thinking perhaps of level shifting the signals at 12 volts and then back down to 3 volts at the other end for the display. I will see what I can come up with.

Stu

If I were to do something on this these days, I'd just buy a low-end Gumstix board and attach a cheap LCD to the Gumstix's built-in LCD interface.

This would allow a variety of possible connection methods, including serial at up to 800kb/s (the empeg would limit that to less), ethernet, and bluetooth.

And with a real Linux computer (the Gumstix) controlling the LCD, it could do grayscale/colour and should handle complex visuals just fine. Not to mention all of those extra I/O pins and interfaces for other empeg add-ons to take advantage of.

Cheers

Interesting...I've been looking at new cars, none of which will easily accept an empeg. I am at the point where I'll likely permanently or semi-permanently mount one of my spare empegs instead of hacking the dash apart. If I could extend the display to mount on the dash or a sun visor, that would be fantastic. Consider me very interested in seeing this happen.

I'm still gathering ideas. I believe it will employ video buffers for the high speed signals.

Stu