Hi.

As far as i can remember, Rob said something about a serial line protocol being developed, that would allow (multiple?) extensions to be on the serial port. However, I was unable to find any details on this yet. What´s the status of this development?
Also, I gathered a few ideas from various posts on this BBS, that also handled the serial port and its protocol. While thinking about my baby (nav´em, see the navigation project thread), I realized that we might have a huge need for a serial bus protocol that allows multiple extensions on the serial port, like a GPS and an external control stick. so here is what I think might help.

1. each extension has to have a serial inside (empeg side) and a serial outside (open side) port, both driven at a given speed (I would prefer 115200bps, but I know this is difficult to do)


2. A packet on the serial port has the following format:
   <recipient ID><sender ID><length><data/command>


3. If an incoming packet (either on the inside or the outside port) is not addressed to the given extension, it is simply forwarded to the other port (from inside to outside and vice versa)

The sender/recipient ID would have to be predefined (I´m willing to maintain a central list for this). However, I can think of extensions to be attached in multiple instances, like a temperature sensor (one for inside temp., one for outside temp.), so we would have to develop a way to detect such situations and change the ID on the fly. Any ideas on this?


cu,
sven

I agree with this wholeheartedly. Having some way to connect a whole lot of boxes without having to swap them or build serial line splitters is a great thing. My idea for defeating the ID number problem is:

Modify the message format you give to be: [Prefix][Sender][Receiver][Length][Data...]

All commands give by the empeg firmware to receiver units have a prefix "!". These commands are the empeg unit directly commanding the receiver units to do something (rather than (possibly third-party) software in the empeg using functions of the receiver units. The first byte of the data is a command byte that tells the receiver unit what the empeg wants it to do.

When the empeg boots up in-car it sends a special init command outward, signified by the command byte being 0. In other words, this command is "!"[00][00][01][00] When a unit receives an init command, it takes the receiver ID, increments it, and learns this as its OIN (Operating Identification Number). It then passes this command outward with the new receiver number. This gives each unit a unique number at start-up which the empeg can use in communications. In other words, the empeg is always OIN 0, and each unit in turn outward is numbered sequentially.

The init command is the only command which is relayed outward in this fashion; all other commands are between the empeg and the receiver unit directly (i.e. using the correct sender and receiver).

Maybe the last device in the chain, recognising that there's no device attached to its outward side, can send back to the empeg a reverse-init command - "!"[OIN][00][01][00]. This tells the empeg the highest numbered device it has, which allows the creation of fixed-size memory arrays to deal with the devices and also allows troubleshooters to see how far along the chain the bad connector is.

The other important command at this stage is the Identify command. This takes the format "!"[00][OIN][01][01] and is sent by the empeg to each OIN in turn. The receiver unit sends back a message giving information about itself. My idea for this message is "!"[OIN][00][LL][01][Manufacturer ID][Model ID][Flags]

Manufacturer and Model are both 2 bytes; this allows a more heirarchial menu structure for those with many devices on their chain. The flags indicate the operational parameters of the receiver unit in question. I'm leaving these as a useful thing to fill out later, but I can think of things like "always on / must be switched on", "commercial / diagnostic" and other vague ideas.

Now it's someone else's turn.

Save the whales. Feed the hungry. Free the mallocs.

Overall, I think that looks like a really good plan! I'll offer this one suggestion that I thought of:
Rather than require a device to be smart enough to detect whether it's the last device in the chain or not, when the init command is sent out have the device do two steps:
1) Reply to the init with it's identifier (e.g. "!"[OIN][00][LL][01][Manufacturer ID][Model ID][Flags])
2) Forward the init command to the next device

This reduces the overall amount of traffic for detection of devices. If a device wants to know if it's last or not, it still has the option of watching for an inbound init reply.

--The Amigo

It has occured that the Q2000 (QZar) network protocol could be usefully employed here. It is designed to send broadcast and addressed data on a multidrop RS232-ish network, with polling to pick up data from clients.

I think it would be better to run multidrop than to require every peripheral to have two independent ports.

Rob

So, Rob, is this an indication of a past spent working with Laser Tag (laserforce, photon, etc) equipment? Or are you going to give us a handy link to a good set of protocol analysis pages?

Or both?

Save the whales. Feed the hungry. Free the mallocs.

Good plan - makes sense using the reply to mean something. In that case we might as well give that reply command number 0 (i.e. "!"[OIN][00][LL][00][Manufacturer...). Perhaps "Broadcast" messages can be sent using a Receiver ID of FF or something. I'm a little hesitant to suggest this, since some commands may make no sense as a broadcast, but let's keep it in the back of our minds for now.

Incidentally, most commands that treat the unit as a specific piece of equipment would have a different prefix - for example, a "Sense temperature on probe 1" sent to the thermometer device with OID 4 might look like "*"[00][04][02][00][01]. The difference here is that it's not the empeg firmware that's sending the request, but another piece of software. I don't know whether this means that empeg commands get priority over device commands, because it's a fairly simple link and I can't see there ever being a priority issue that would really matter to the user. But it's there.

Another thought is that one of two things should happen to the current set of empeg commands, which are all single characters and not at all like this multi-byte mainly-nonprintable-ASCII-characters protocol. One, perhaps rather drastic, option is for them to be deprecated and moved into this protocol. Perhaps a more sensible option is to keep them, supply working "ESLP" commands as well, and advise that we'd prefer that devices directly wanting to control the empeg's playback use the more modern commands.

A thought on the 'multidrop single-connector vs single-drop in-out-connector' problem. To my mind the firmware necessary to drive what is essentially a CSMA/CD network, even over these relatively small distances, is quite complex. It seems simpler to me to implement two buffers and just stuff irrelevant commands from one port to the other via the buffer.

Hmmmm.

Save the whales. Feed the hungry. Free the mallocs.

So, Rob, is this an indication of a past spent working with Laser Tag (laserforce, photon, etc) equipment?

You didn't know this already, Paul?

A significant percentage of the founding members of empeg are from that background. I get the impression that's how they all met: working on those projects together. I thought some of that information was up at the geek site.

___________
Tony Fabris

Looking at this thread, it occurs to me: Isn't there already some kind of a standard being developed for in-car devices to communicate? Some sort of in-car command/control protocol? And wasn't it mentioned the last time this subject was brought up? What was that called?

___________
Tony Fabris

A few years ago I had a website up with all of the QZar protocol specs, but I don't think it's online anymore.

I have a vague understanding of the network specs for Q2000 (since I wrote them) and a simplified version of these should deal nicely with the car player. I'd have to check with Patrick exactly what will be needed for the multidrop side of things, but it'll probably be quite easy. I doubt we need the optoisolators and so forth that QZar energisers use.

I'll knock up a suggested spec later and see how many people hate it. Even if we agree on something I doubt the development team will have time to rework the empeg end of things for a while. I know Hugo was muttering about moving to a more convenient binary protocol at some point, though.

Rob

It has occured that the Q2000 (QZar) network protocol could be usefully employed here. It is designed to send broadcast and addressed data on a multidrop RS232-ish network, with polling to pick up data from clients.
I think it would be better to run multidrop than to require every peripheral to have two independent ports.

I have no idea how that might work. Do you have any references where I could find more about that protocol? Also, I have no problem understanding how one unit might send to multiple units, but the other way (many possible senders, one recipient) is not that easy to do, I guess. Furthermore, though multiple ports are not that easy to handle, my idea would allow different external units to communicate with each other, which I can´t see a RS232-like multidrop link being able to do. Hmmm, it would require each unit to listen to its own output (as it is on the same line as anybody else´s output). Another problem is collision detection, a problem one does not have with multiport, store and forward protocols. Each approach would have its specific advantages and disadvantages. We just have to decide what to do. My approach would mean however, that we do not need any converter box on the outside of the empeg unit, which is likely to be a requirement for the Q2000 (QZAR) approach (along with the software upgrade). On the other hand, the Q2000 approach is likely to be easier to implement on the (external box´s) hardware side.
Anyway, electronics is not my primary business, so I don´t have much knowledge which approach is cheaper and/or easier to implement (regards to hardware). I´m pretty sure that my primary application (attaching a GPS as well as some car monitoring) is hard to implement using my approach, because the GPS itself sends data with 4800bps, which is exactly the default speed of the empeg, leaving no room for other applications. Second problem: the link box to connect the GPS with the empeg would have to have 3 RS232 ports: empeg side, other extensions, GPS. Not too much of a problem using a 16C554 or something like that, except for the cost and size of it.
I guess this thread is going to be long and going in depth on both hard- and software. To get something going, I think we should try to split it up into two major parts:

1. Link level communication (hard- and software)


2. application level communication (software only)

Skipping most of the link level communication for now (I don´t have enough background on that), here are my thoughts:
The link level communication should simply deliver a packet from one unit (empeg or not) to another, specified unit (empeg or not), regardless of the packet´s contents. So we would basically have something like this:
<LL sender><LL recipient><application level packet>
I currently have no idea how one can find out where to send it (the application has to know where to send the packet), especially on a multidrop bus. But for the moment, let´s assume the app has a way to know. Now the application level packet would be something like this:
<sender id><receipient id><packetnr><command><length><data><CRC>
where "answer" (resp. its numerical representation) is a special command to reply to other commands. This whole protocol is pretty generic so far, and not really thought about that much, I just wrote down what came to mind. Hopefully at least someone else is able to make sense of it, and develop something working from it. I´m going to bed now (1:10am here).


cu,
sven

Well, anything that empeg comes up with is bound to be backed by years of experience. Presumably your near-infinite knowledge of semiconductors would also choose a solution that had a readily available implementation. While all I might be able to do is contribute design and implementation ideas, I am thinking of working on an external box to do 3D sound processing. More on that on another thread, I think.

I'd like a little more explanation of how you think a multidrop network would be implemented on the empeg. While I wouldn't want a proprietary solution (i.e. I'd like to be able to make my own twelve-port cable if it came down to it) it shouldn't be something that only an experience cable-wielder could put together.

Thinks - with such a short distance to travel maybe token ring would work?

Save the whales. Feed the hungry. Free the mallocs.

Just a thought regarding "convenient binary protocol":

Part of the reason I suggested the message format begin with a "!" is so people can still control their players using a terminal program. The "!" tells them that the following text is a command output and is not some bizarre diagnostic message following their request to play the next song.

Norton Utilities used to encode its non-human-readable data files with a prefix which was basically a line of text, a carriage return and line feed, and an "end of file" character. The programs could just read past that, but if you read the contents via "type filename.dat" you'd get a succinct message telling you the file's meaning.

Perhaps the carriage return character as a command prefix might be useful, as any control characters the empeg might send out in its binary messages would be prefixed by a 'go to start of line' command and thus would overwrite themselves rather than filling the screen with text. Or, perhaps, we just increment all numbers in the command stream by 32, and limit the largest number in the stream to 224, thus meaning all characters (with the possible exception of 127) would be printable even if not typeable.

Ultimately, while I'd like to see the command output as a vaguely human readable output for easy debugging, it'd probably make things more difficult for the receiver units. Especially for things like CRCs.

Save the whales. Feed the hungry. Free the mallocs.