After some experimentation for other things I had the idea that the Treo 300 combined with an unlimited Vision plan from Sprint might be useful as a source of network for the empeg while in the car.

There are a few gotchas, though:
-it would need the serial port, or it would need to take over the IR port so you could run ppp on it. (or you'd need another computer)
-you'd need pppd running

But most importantly...
-what would you do with it?

If you look around the board you'll find a great hack that someone (kim salo maybe?) did of hooking up a bluetooth chip to their empeg and using it to update where they were on a web page and I think get traffic reports.

Matthew

It was Kim Salo.

I'm loathe to modify one empeg as then to be useful I have to modify my wife's empeg, also.

Besides, do I really want to nuke the irda?

Is it enough bandwidth to stream audio from shoutcast?

If not, maybe it could send map data for gps?

You could have a simple read-only imap email client running.

GPS combined with a thin web client for movie listings/restaurants in your area.

You could probably use GPS and this to send your coordinates to a web server somewhere, and retrieve a map periodically for display.

Use it as a poorman's lojack, ala Kim Salo.

Text streaming of the unofficial BBS, of course.

Greg

s it enough bandwidth to stream audio from shoutcast?

Probably not reliably, or reliably enough for it to sound good.

If not, maybe it could send map data for gps?
Which I can't use while I'm eating its serial port

You could have a simple read-only imap email client running.
I could just do it on the treo.

You could probably use GPS and this to send your coordinates to a web server somewhere, and retrieve a map periodically for display.
I considered this, see above though. Also, realize for me, I'd just use APRS, but if you don't have an amateur radio license this doesn't help.

In reply to:

---

If not, maybe it could send map data for gps?
Which I can't use while I'm eating its serial port

---

Do we really need the serial port for the GPS? Assuming we don't need to send any custom programming to the gps all we need is a receive pin. Could we use the mute or headline sense wires instead and leave the serial port free for other uses? I was wondering about this the other day while contemplating ways to hook a second device up to my empeg.

-Mike

Who knows what may happen....

Anybody a PIC expert?

Assuming we don't need to send any custom programming to the gps all we need is a receive pin.

That's a big assumption. There are some neat tricks you can do if you can send to some GPS receivers, too, which I don't want to preclude myself from:
-switching map datums. i can think of a small number of cases where I'd want NAD27 instead of NAD83 or WGS84 (which are effectively the same unless...)
-RTCM correction data so you can do DGPS. This is effectively how the dgpsip support in gpsd works. I'd have to set up a beacon to make it work usefully for me but I can think of cases where being able to make precise measurements would be useful with what this would make possible. Want to know if your odometer is properly calibrated?
-and more simply, some receivers support turning some sentences on and off. if you can figure out what receiver you have (and the ones that send proprietary sentences will help you guess; the proprietary protocols will often just tell you) you could for instance turn off the satellite information if you weren't on the satellite screen, so you would only need to read the information you needed.

Jack of all trades, master of none...

clue me in on the diagram?

It's a UART hooked up to a TTL<->RS232 converter.
You'd need something to control the UART however which is where the PIC chip would come in.

It shouldn't be too hard as most of the work in decoding the serial data is done by the UART. You'd just need to grab the data out of the UART FIFO and pump it back out to the empeg.

I don't have the time to do it myself but if anybody else wants to have a go, I'll be more than willing to give a hand.

- Trevor

Yep, that's part of the evolving design...the other parts involve an 18F452 PIC, under-pcb mounting for Oncore GT or Trimble Sv6/AceII/AceIII GPS receivers, interfacing and battery backup for said receives, inclusion of a modified version of Bev Roadman's OBDII interface design (freediag compatible - although freediag will require ARM porting, and some modifications to make it suitable for the empeg display), and (this part is still to be 'evolved') support for some DACs/ADCs, and Dallas One-Wire support.

I was really hoping to put this all together as a kit for around $50 (not including the OBDII PIC/ connector that Bev sells), but at the moment I'm having assembly and volume issues. The main problem is that the most convenient technologies to do this stuff in are all SMD, which is not the easiest to solder by hand...eg the 3 big chips in this design (Quad UART, PIC, and RS232 driver) are best suited to either PLCC or TQFP packages. PLCC can be socketed, but SOT PLCC sockets aren't the easiest thing to solder either - basically they require reflow soldering. PTH PLCC sockets would be solderable by hand, but there'd be a lot of pins, 156 pins for those 3 chips alone, which I think is rather off-putting. Now if I knew that the volume would support it, then I'd consider getting either the sockets, or the chips themselves assembled onto the board commercially (pushing the price up obviously), and if I knew that this was only going to interest <20 people then I'd invest in a toaster oven and reflow the parts myself. The problem is the middle ground...

If anyone has any input to this, then please help! It will go much faster with multiple brains attacking the issues

For those electronics people out there, I'm using the free version of Eagle from www.cadsoft.de to create the schematic/board. I've had to create some library parts to support the design, and these should be sanity-checked. Let me know if you want to help with the circuit, although I'm going to be *very* busy until Monday, and I don't want to post the eagle files until I've cleaned them up a bit.

In the mean time, really useful specs for any would be PIC code writers out there will be the PIC18F452 (www.microchip.com), TI16C554 (www.ti.com).

In reply to:

---

Yep, that's part of the evolving design

---

Cool. So basically we are talking about a serial multiplexer with support for a GPS, ODBII, DACs and one-wire right? That is cool and I would definitely be interested in one or two if you can get a kit together for $50ish.

The problem that I see is that a lot of the people who are interested would probably want variations. For example, I wouldn't need the Oncore/Trimble support since I have a nice Garmin GPS16 so I would really just want a loose serial port. Bluetooth would be a sweet option as well.

-Mike

The problem that I see is that a lot of the people who are interested would probably want variations. For example, I wouldn't need the Oncore/Trimble support since I have a nice Garmin GPS16 so I would really just want a loose serial port.


Yeah, that is accounted for...
1 UART on the PIC - 2 wire only...so I *think* that'll be put to the empeg, since the empeg doesn't have any hardware handshaking lines.
4 UARTs in the 16C554.. 1 labelled as PC, for attaching a laptop or other PC to...this will basically be equivalent to the existing empeg port. 1 for the OBDII. 1 labelled as GPS that is connected to the internal headers. There's no major reason why these connections couldn't also be brought out via the MAX chip to an external connection, it'd probably involve a couple of hardware jumpers. (or solderpad jumpers). That still leaves one that will be labelled as 'external' that can be used for whatever purpose, radar detector, or G-Force meter.....this will probably have the full RS232 hardware capability for flexibility.

Bluetooth is really a non-starter for this project... at least as an integrated device. I don't want to have to deal with any RF issues, I have very little knowledge of the technical details, and the technology itself is still immature. But if there's a serial<->bluetooth adapter available, then maybe that could be used on the external port.

Bluetooth is immature? I've got a mobile phone, headset, PDA, PCMCIA card and a printer that all use Bluetooth and they work nicely together thank you

How are you intending to demultiplex this at the Empeg end? In theory I guess you could write a kernel device which does the demultiplexing and presents it as a pseudo TTY.

Assuming we can run this at 230400 baud, we should be able to get around 57600 on each port. That should be good enough for most applications.

- Trevor

AFAIC, yes it's still immature. The current specs are v1.1, and everyone knows that everything matures at v2. I still don't want to have to deal with any RF issues though..

Yeah hijack would implement kernel devices to multiplex/demultiplex the connections. In order to maintain compatibility with the player software, it will need to move the physical serial port to a new device and pass /dev/ttyS0 through the new driver. We'll also use some challenge/response scheme to initialise this so that we don't affect anyone without the box. WRT to speed, given that most GPS receivers typcially run at 4800, raw OBDII ports at typically 10400, and player's DC speed is set via config.ini, there shouldn't be any issues, even at 115200. But with a fast PIC, we should be able to hit 230400 anyway.

In reply to:

---

But if there's a serial<->bluetooth adapter available, then maybe that could be used on the external port.

---

Brain Boxes has announced a Class 1 Bluetooth <> RS-232 adaptor. There's no mention of Linux support, however.
BlueUnplugged even claims they're currently available (for a mere $229).