Okay.. This thread is mostly for my reference (because I suck at making notes), for anyone's comments, and, most importantly, everyone else to point out anything I'm forgetting. Heh.
After looking at Hugo's Display Thread, it's something that I want to do, mostly cauze I have too much freetime. Nono, mostly 'cauze I figure it's simple enough that I can handle it all the way thru (with some help when the need arises) and give something back to the community.

Okay, first, details at when *I* want to do with it..
1. Final Concept: Making a small HUD for my Mini. No real-time visuals needed, I'm looking for just info - Track Info, Volume, Menus (possibly. That may be tricky.)

2. Parts: The VFD display, a converter board, and the Empeg.
2a. The VFD display. From Nortake Itron, part number GW128x32C-K610A.
2b. The Converter Board. My creation, with lotsa PCB designing help from pca (Yeah, the tuner guy. Sorry guys, I'm trying NOT to slow down tuner production. Honest!) It will be a one-shot. DB9 connector for the serial, some kind of connection for 12v power, and a ribbon cable header to feed power/data to the VFD.
2c. Empeg. Pretty self-explanatory.

3. Software. My idea (which I will worry about more when I finish hardware) was simple - a little TSR program (TSR? In Linux? Sorry. ) that will sit and loop.. or something, and watch the empeg_notify file in /proc, and, when updated, send the correct commands to send to the serial port.

Of course, advantages to the converter board is that it can be used for most any of the Noritake Itron VFD modules, since it can supply the 5V. (See my next post about the board itself.) If anyone wants these boards, let me know. I don't plan on making any money, and the more PCB's I order, the cheaper they get.. in theory. I'll have all part #s and such in the post, so you could go out and get everything yourself, if you really want.

Thanks!
Me.

Okay, what I got so far:

It's a pretty simple board. Will consist of connectors:
1. DB9 for the serial cable.
2. 10-pin header for the ribbon cable, and
3. An as-of-yet-unchosen power connector.

Parts it will contain, will be:
1. The MAX233 (or MAX233A). This is the RS232-TTL converter chip, used after recommendation from the display thread.
2. The power regulator - uA7805. In theory, this can pump as much as 1.5Amp thru it, and take up to +40V.
3. Assorted caps and a diode - the caps for the power reg, and the diode to protect the reg. against any negative spikes. (recommended in spec sheet, adds insignificant amount to board.)
4. A DPDT switch. Why? Well, it will flip the TX/RX lines going to the DB9 connector. In case someone wants to connect the board straight up to the Empeg, or use it in their car, connected to the cable out of the sled.

That's about it. It can be pretty darn small, honest.Forget anything? Me? Probably.

I have some of the parts on order, right now I'm in a crash-course learning a PCB layout and designing software, (and that's where my thanks to PCA comes in.).
Next step, once I get parts, will be to make a little prototye circuit, and connect it up, see if I break anything.

Me.

How about allowing for the +12 volts to come down the Serial cable into the DB9 connector [with maybe a simple on/off jumper to allow this option to be disabled on the PCB], as an easy way of getting the necessary voltage into the PCB to run it.

Recall the Empeg has +12 volts already available on the DTR line (pin 4) of the external Serial port on the sled, so this would make a "single cable" solution, with no cutting of wires or splicing into harnesses to be done in most cases - juts plug the DB9 connector to the Empeg's sled and away you go.

If anyone wants these boards, let me know

I'd be interested. I do like Number6's idea about the power wire.

I am interested also. I don't know what I would do with it yet, but I would find something...

In reply to:

---

How about allowing for the +12 volts to come down the Serial cable into the DB9 connector [with maybe a simple on/off jumper to allow this option to be disabled on the PCB], as an easy way of getting the necessary voltage into the PCB to run it.

---

That is a really cool idea. Didn't even think of that. I'm assuming that the +12V uses the GND pin on the connector as well, then?
Would there be a problem (I can't see any off-hand) if the GND on the serial is always connected to the power ground?
(i.e. I have it at home, with a 12V adapter plugged into it. The DTR line is disconnected from the external power via the jumper, but the GND would still be connected. (Just seeing if I need two jumpers, for the GND and +12V, or one would do.)

<Evil Laugh> I like this... </Evil Laugh>
Me.

In reply to:

---

I am interested also. I don't know what I would do with it yet, but I would find something...

---

That's the beauty of it, so far. There's not going to be any "VFD Only" components in it, other than the +5V output for power.. So, anything that uses a TTL serial format can use this to interface with the Empeg. Fun.
Although there was a link to a small product that did RS232 -> TTL conversion in a straight-cable configuration, which may work a little better.

Me.

I believe my Onstar GPS is TTL. I guess I have to choose remote VFD or GPS hmmm.... Anyway I leave that for another thread.

Question to anyone that may know, or have a datasheet..
On the MAX233 / MAX233A (20-pin DIP), is the chip the thinner kind, a-la the TI's MAX232, or is it the wider version, a-la an EEPROM?
The data sheet I have for the MAX* line of ships don't have any of the dimensions for the chip.. :/

Thanks,
Me.

The MAX233 I've used all came in a "skinny DIP" package,
i.e. its like the MAX232 only 4 pins longer [2 on each side].

re: Serial Ground, the Empeg Serial port ground wire is connected to the "Ground" wire in the sled harness so its perfectly ok to leave it connected all the time in your design.

One thing to note that sleds earlier than about serial# 1000 had a problem with the ground wire not being connected in the sled harness.
[my sleds have/had this problem].

So if you use the +12 and ground wires in the serial cable missing this ground wire then your VFD board won't work until you connect your PCB's ground to your cars "ground".


One other point about using the +12 volts on the DTR wire, it is turned off when the Empeg is, so you don't have to worry about it being powered up when your Empeg is off.

Just remember that the +12 volts on the serial line and the remote Amp control line share the same source, so can only sustain 1 amp between them.
For most "correctly done" installations this is never going to be a problem but it is something to watch for.

Since the VFD "receives" serial data from the Empeg and the Onstar "sends" data to the empeg you can have both connected at once - all you need is a TTL signal splitter cable - with one wire (plus ground) going from the onstar to accept incoming serial TTL from your Onstar and send it to the Empeg serial port via the MAX2*, and the TTL serial out is sent to the VFD unit.

You could even place a jumper switch on the board to allow you to "route" the TTL level GPS data to the VFD allowing you to display the GPS data (assuming its in NMEA format) on your VFD as a form of system "self test".
[I think the VFD will accept regular ASCII data and show it as it has onboard Character Generator logic].

In reply to:

---

You could even place a jumper switch on the board to allow you to "route" the TTL level GPS data to the VFD allowing you to display the GPS data (assuming its in NMEA format) on your VFD as a form of system "self test".
[I think the VFD will accept regular ASCII data and show it as it has onboard Character Generator logic].

---

It can - it has a limited set of the full ASCII character set -
erm, wait. My bad. Default power-on has the full set, starting with the hex 20, the space. Everything BEFORE that is custom programming commands and such.. :>

Me.

In reply to:

---

Just remember that the +12 volts on the serial line and the remote Amp control line share the same source, so can only sustain 1 amp between them.
For most "correctly done" installations this is never going to be a problem but it is something to watch for.

---

Ah, thanks. I'm actually closer to getting the board finished than I had thought. (Simple designs rock.) The screen does NOT suck that much power, so I will go ahead and use the serial DTR line, with a standard DC plug. When something is in the plug, the +12v/DTR is cutoff from the DB9 connector, and used from the plug. Otherwise, +12 comes from the DB9. Perfect.

Me.

Thanks for the info Number6. In that case I think I'll yank out the Onstar GPS and confirm that it is an M12 Encore (What it is rumoured to be)

Okay.. Final PCB parts list, for my notes. (Anyone else, paying attention..) Digikey partnumbers in {}'s.

uA7805: +5V Power Regulator {296-13996-5-ND}
MAX233CPP: Rs232/TTL converter IC {MAX233CPP-ND}
C&K DPDT Switch {CKN5003-ND}
10-pin Header {A26267-ND}
DB9 Connector {A2096-ND}
+12V Power Jack {CP-102A-ND}
Capacitor .33uf {1213PHCT-ND}
Capacitor .1uf {1210PHCT-ND}
Diode 1N4001 {1N4001GCT-ND}

(Note: I always get the serial connectons mixed up. I THINK I need a MALE connector on the PCB board. So, that's what I ordered. )
(Note2: The more I mess with this (^&*&#@ PCB software, the more I am impressed at PCA and others who can do this. It's currently winning our most recent argument.)

I'm just wondering if this display actually needs to be connected to both the empeg serial port RX and TX lines. From what I can tell you don't ever read anything back from the VFD. If so then a SPDT switch would do. Also wouldn't a three pin header and a jumper be cheaper than using a switch?

Have you thought about using Veroboard/stripboard actually? The circuit is very simple and wouldn't require much Veroboard and it would save you money on getting a proper PCB.

- Trevor

[edit]Blah. Removed bit about terminals on the DPDT switch because I misread the Digikey catalogue table... Doh...[/edit]

I'm just wondering if this display actually needs to be connected to both the empeg serial port RX and TX lines. From what I can tell you don't ever read anything back from the VFD. If so then a SPDT switch would do. Also wouldn't a three pin header and a jumper be cheaper than using a switch?

Good point, and one I considered.. The reasons I came up with including both was:
1. Upgrading - In case, sometime in the future, there's newer model that talks back (for whatever reason), wouldn't have to redesign the whole board.
2. If anyone wanted to use something else TTL related, they could make a cable and use the board.
3. I actually was going to use the input back from the VFD, at least for the "R" code it sends back.. (If my program initializes at startup, and the VFD's not there, it will try to reset the board until we get a responce, knowing it's there.) Althought this isn't as important as #1.

The price difference wasn't that great - the switch was $7.. Considering the VFD is $120, I can spend another $7. :>

Have you thought about using Veroboard/stripboard actually? The circuit is very simple and wouldn't require much Veroboard and it would save you money on getting a proper PCB.

Are these design software or makers? I've never heard the terms (looking up now..). I'm just arguing with the software I have now to agree on pin layouts.

Me.

Edit: Aaah, I see what the Veroboard is. It may be a good alternative. It certainly is for making a proto of the board and testing it all before sending it to a maker, at least. Thanks for the suggestion..!

Okay.. All parts are in for the PCB. So now I'll use that perfboard idea to put it all together and take a stab at it.
The VFD is here too, and that thing is TINY. I mean the visible display area is LESS than the width of my finger. Entire board, less than two fingers..
I can't do anything hardware wise until mid-next week, so I'm spending some time right now, looking into the programming side...

Having only done simple C programming before, I was rather pleased to have my first test program (all it did was print "Test!" to the screen) compile and run on the empeg. Whohoo.

Now I need to figure out how I'm going to obtain status of the player. (Playing status? (Play, Pause, Off?) Song Info? (Artist, Title, Source?) Other Info? (When do we hit a new song? Is the user in a menu?)

I'm starting to poke around other programs out there, mostly the lyrics viewer thing.. so all I gotta do now is trial and error.

I love this stuff.
Me.

Are you going to try and implement your own display? If it's not too distracting you could just use /proc/empeg_screen.[png!raw] and just update the display that way. The baud rate of the VFD serial protocol is too low for a high refresh rate but it should be okay enough to just see what's happening.

You could try and interpret /etc/empeg_notify like the lyrics viewer and attempt to work out when the player is seeking/playing/stopped etc...

- Trevor

Are you going to try and implement your own display? If it's not too distracting you could just use /proc/empeg_screen.[png!raw] and just update the display that way. The baud rate of the VFD serial protocol is too low for a high refresh rate but it should be okay enough to just see what's happening.

I would do this, and may still, but I'm not sure how the data format is in the PNG/RAW files. (If I COULD figure it out, then I could easily convert it to data that the VFD understands, and just 'loop'.

The empeg_screen.raw file is 2048 bits. Screen size is 4096 (128x32). Is there info somewhere on how to intreperet the file? (Going to do a search after this..)

I just finished writing a little program that loops every second, and scand empeg_notify, and if it changes, pipes out to screen. (I didn't realize that "Source" (or Album) isn't contained in that file.. Interesting.)

Just copying the display (like Hugo did) would be most beneficial for Menus and such - but refresh rate would look kinda crappy on visualizations. :>

Untimately, I want to have a hybrid. Simple text or graphics displaying song info, and then making own menus when user enters them. Biggest hurdle there is finding out WHEN the menu is accessed, and knowing WHAT is on the menu.

That's a ways off, as I learn more C. (Hey. I[m pretty friggin' happy that my first All-C program works as expected. So far.)

Me.

The Empeg VFD screen is 4bpp so every byte in /proc/empeg_screen.raw corresponds to two pixels.
You can get all the information about the currently playing FID by either parsing the empeg database or reading the *1 files.

- Trevor

empegVNC interprets the .raw file. You could steal the code from there.

And you could optimize what you send over the serial by stealing the VNC code that generates rectangles of data to update and only sending updates for them to the display instead of the whole 128x32.

I'm doing a similar thing but with different goals (visibility in the sun and keeping Empeg in the trunk so I don't have to take it out every time I leave my convertible). Noritake has a nice 140x32 display that's 115.2kbps, and a 256x64 that's unfortunately only 38.4 (by serial.. parallel is faster). Haven't decided which to use yet. With the extra space extra apps could be made to run and not cover up the Player display (or on the 256 one it could be pixel doubled to show the Player fullscreen).

This might also be of interest to you.. Grayhill makes a joystick that has an optical encoder and pushbutton all in one knob. I'm planning on using one and converting my cigarette lighter into all 7 functions on the Empeg face, except that I haven't found any place to buy one yet.

The Empeg VFD screen is 4bpp so every byte in /proc/empeg_screen.raw corresponds to two pixels.

This is the part I'm having issues with. (Okay, so I admit. I ain't the brightest.) :>

Reading thru the file, I see values that inclode x00, x03, xFF. If it's 4bpp, that give a total of 16 different shades for each pixel. If x00 (00000000) is off for both, and xFF (11111111) is on for both, then we aren't using some values there, since we only have 4 brightness levels.. I want to experiment, but can't until I get the hardware side done.

Thanks for the help, ya'll.
Me.

[Edit: Wait. Hold that thought. In my strupidity (read: insufficient C knowledge) I think I've been reading the file wrong, which would explain alot.]

And you could optimize what you send over the serial by stealing the VNC code that generates rectangles of data to update and only sending updates for them to the display instead of the whole 128x32.

Ooh, that sounds interesting. I'll have to look into that, then.. (Since I'm, like, new to C and all, if for nothing else than to learn..)

Me.

If x00 (00000000) is off for both, and xFF (11111111) is on for both, then we aren't using some values there, since we only have 4 brightness levels

Well, 4 brightness levels is 2bpp not 4bpp (which would be 16 levels). The static graphics files on the player (like the boot logos) store the values raw, inefficiently, using an entire nybble for storing only two bits worth of data.

The empeg VFD screen itself isn't even techincally 4bpp or 2bpp, it's actually 1bpp. But they do a 200hz time-dither to get multiple shades. Sure, they could do other values other than those four shades we already know about. But they are very flickery and they just aren't used for any of the static graphics on the player.

In reply to:

---

Grayhill makes a joystick that has an optical encoder and pushbutton all in one knob. I'm planning on using one and converting my cigarette lighter into all 7 functions on the Empeg face, except that I haven't found any place to buy one yet.

---

I have a earlier model [non-joystick] model of those Grayhill switches and they are very nice.
If you manage to locate a source of the joystick plus encoder plus pushbutton switch let me know as I could use a few of them.
[maybe a group buy might meet the minimum order qty required].

I suspect though that unless Grayhill have a large order they won't be making any for a while, so it may take some time to locate a source...

Anyway, drop me a PM when you find some, and I'll make arrangements from there.

If anyone wants these boards, let me know

I would be interested in this ; perhaps just the convertor board and cabling, so I can get the appropriate VFD display to siut ...

Sorry to interrupt the thread.

I found a local (Phoenix) distributor for Grayhill that claims to be able to get me one as a sample (my company has a project going that I'd like to use them on, which is how I found out about it).. if they deliver I'll talk to them about buying them individually or in small quantities and let you know.

so I can get the appropriate VFD display to siut

Various Noritake models have RS-232 interfaces built-in, so you would just need the 12v->5v part to run them if you used one of them.