After doing some research on both Linux and Empeg's IrDA capabilities, I would like to start a project to create a universal IrDA "daemon" for the Empeg. This would enable most IrDA compatible devices to transfer data to the Empeg, and then the Empeg could be set up to perform actions based upon the data transferred. The way that I am thinking about implementing this may be useful to recieving Bluetooth signals also.

Seeing the names suggested on this thread by wfaulk gave me the idea to name this server Empire, for EMPeg Infra REd.

Here is what I am suggesting: The server would listen for OBEX objects coming across the IrDA port via the IrOBEX protocol. OBEX is a standard way of encapsulating any kind of object, even a small string of text into a higher level protocol over IR. They make comparisons to HTTP all the time, but the important thing is that many comsumer products use IrOBEX as a IrDA protocol. Palm, WinCE, Linux, mobile phones, TheAmigo's pager, etc. all support OBEX as a method of communicating. This makes it ideal, especially since the OpenOBEX project for Linux supports recieving OBEX objects over Bluetooth as well as IR. This could possibly make the Empire server into a Bluetooth server as well (with some work and Bluetooth hardware).

I started out investigating IrCOMM as a solution to all of this, but reading through some of the mailing list posts for the linux-irda project, I learned that IrCOMM is kind of like the bastard child of the project, while IrOBEX is encouraged for use. I did write a small IrCOMM server for the Empeg, but as they were saying, it was unstable and would drop data occasionally.

We would have several types of objects that we would support, and these would be extensible. I see for the initial server having "control" objects that would map to the Empeg's control set that we send over the serial port. Examples are VolUp and VolDown. The OBEX header would indicate that these are control objects, then the data would be the command to send to the Serial port to make the Empeg respond. This will be my first goal when writing this server. Others would be "multi-controls" for having multiple commands per OBEX object for if you wanted to send "macros" to the Empeg. The server could possibly also handle remote file/record storage so you could store your PDA's calendar on the Empeg or beam your phone's address book.

TheAmigo already compiled up OpenOBEX for the Empeg and was able to transfer data from his pager to the Empeg, and he helped me get it cross-compiled myself. This package includes a program called obex_palm3 which will listen for a Palm beaming request, and recieve the file, copying it to the /tmp directory. This is a great place to start from, and I will most likely be wanting input along the way because I haven't created a daemon in Linux before. If anyone has suggestions about this project they will be gladly welcomed! Since this will probably interface quite a bit with other applications that I may not write, I would like to make this as much of a collaborative effort as possible when it comes to design. I plan to write this app anyway, but I may want input on "big picture how" along the way.

Possible scenarios with this project:

• Back up your PDA's records to the Empeg, then display them on-screen with a display application
• Bluetooth remote control with Palm/WinCE device/Zaurus
• Backup your Phone's address book to the Empeg via bluetooth or IR

and the one I want to develop for:

• Remote Empeg Playlist chooser for the Palm.

We would have several types of objects that we would support, and these would be extensible. I see for the initial server having "control" objects that would map to the Empeg's control set that we send over the serial port. Examples are VolUp and VolDown.

I noticed that the memo pad app on the Palm uses the first line of the memo as the file name. This is preserved on the recieving end and the obex_palm3 app uses that file name to save the memo to /tmp.

Presumably, you'd be able to write a Palm app that can specify the file name for each object it sent. Then Empire could use that file name to know which program to pass the data on to.

The simplest way I can think of to make it extensible is to just create a fifo for each app that wants to get data from Empire. For example, have a fifo called "command" and one called "playlist". From the Palm, you could have a page of buttons that send text to the "command" file and another daemon on the empeg reads from the command fifo that Empire writes to and passes those commands on to the player. The playlist fifo could pass the data on to a different daemon that would perhaps look at the first line and know whether you're asking to read the current list or if you're submitting a new one.

Yet another fifo could be the one that TTSd uses so you can beam a memo from your Palm titled "readme" (or "ttsd" or whatever) and Empire would pass that on to TTSd.

And maybe even have something so that memos titled "lyrics" get passed on to the upcoming lyric scroller. Not necessarilly intended as a useful way to display lyrics, but just as a way to view text files on the empeg.

If the incoming OBEX object's file name doesn't have a matching fifo, maybe Empire could play a short beep or something to let you know it doesn't know what to do with that data. All in all, it sounds like a very doable project! New plugins don't need to register with Empire and Empire doesn't even need to be restarted to detect them.

Way too cool. I was thinking a lot about this recently, my latest cell phone has irda

While you at it, can you give some thought into insuring that the kernel or other 3rd party apps can beam regular serial information out as well?

My previous cell also had IrDA, but the only thing it could be used for was data calls. It would show up as a modem (both to Windows and to a Palm). I was hoping to be able to use the Ir port to sync the phone book, but that wasn't an option

As far as letting apps beam stuff out, that shouldn't be too hard either. The first thing that comes to mind would be a fifo that any app could write to and Empire would read input from there until the writing process closed the file. Then use the first line of input as the file name and beam the rest out as an IrOBEX object.

My pager allows routing of incoming IrOBEX objects. Based on the filename extension, it will pass it to the registered program for that type of file. I'd guess the Palm has something similar... can a Palm developer confirm? Cushman?

I suppose you could even write a "shell" module for Empire that would run any input as shell commands and beam back the results as a text file that would show up in your PDA's memopad.

What about also being able to use the phone as a remote. Half the time I can't find the remote but I always know where my cell is. I have a little nokia 8390 that would be cool to be able to controll the empeg from... if its possible.

-Greg

Yeah, the Palm accepts file inputs based upon their filenames, but it can also be specified in the OBEX header, too, I think. Anyway, I know that .txt is Memo Pad Records, .vcd's are for Address Book entries, etc. Empire could definately beam stuff out, but for now anyway it will probably be limited to OBEX stuff. Any IrCOMM utilities (terminal over IrCOMM or such) would have to be separate, and I'm not sure if two apps can use the IrDA port at the same time. The only IrCOMM stuff you would be using would be ppp or a terminal, but these are not going to be 100% reliable on the Empeg, especially with the 2.2.x kernel.

It depends on the phone. If you can program each button to send out individual OBEX objects, it would work.

Ok, after doing much research, I've found out some more about OBEX and how Palm apps handle data. Basically there are four headers that we can define to send out with an OBEX object (on PalmOS 3.x). Those headers are:

Value	Type	Name		Description

-----------------------------------------------------------------------------

0xC0	int	Count		Number of objects (used by Connect)

0x01	char*	Name		name of the object (often a file name)

0x05	char*	Description	text description of the object

0xCF	int	Creator ID	indicates the creator of an object

We can't really use the Count object, but we can set the Name, Description and Creator ID. I'm suggesting that we use the Name header to determine where the object will go, more specifically the extension. This would allow other apps to "attach" themselves to other extensions like .txt and .vcd to handle those objects when beamed, and custom applications could use custom filenames almost like mime types. The ending extension for empeg-releated files would be .empeg, and you would define what app to send them to by the "filename". Controls such as VolUp and VolDown would be sent as

control.empeg

I am calling for anyone who would wish to develop an application that would beam OBEX objects to the Empeg to run the attached empire program on the empeg and give me the results of your device's output. I'm interested to see if any other devices output any other headers that I do not know about (custom headers are allowed per the OBEX spec). Also if you could tell me if there are any other headers that you could define, that would be great, too.

To use the empire binary, untar the attached file and upload all the lib* to your /lib directory on the empeg. You will have to create a few symbolic links, make the files in there look like this:

lrwxrwxrwx    1 root     root           24 Feb  7 00:45 libopenobex-1.0.so.0 -> libopenobex-1.0.so.0.0.0

-rwxr-xr-x    1 root     root        28796 Feb  7 00:45 libopenobex-1.0.so.0.0.0

-rw-r--r--    1 root     root        40328 Feb  7 00:45 libopenobex.a

-rwxr-xr-x    1 root     root          744 Feb  7 00:45 libopenobex.la

lrwxrwxrwx    1 root     root           24 Feb  7 00:45 libopenobex.so -> libopenobex-1.0.so.0.0.0

then put the empire binary anywhere (maybe /bin) and execute empire. Send the data to the Empeg and copy the output and post it here. TheAmigo, I would be interested to see what headers your pager can send as well as what you could define when you write an app for it.

Edit: Oh, forgot to mention you need to have IrDA compiled into your kernel and irattach /dev/ttyS2 beforehand. If anyone needs the irattach binary, let me know.

Hi Mark,

do you have a copy of the OBEX spec, if not I think I can locate a copy for you.

If your question was a more generic "what headers do devices send?" then I may be able to help out a little as I used to be involved a little at one stage. Also if you need any specific info drop me a PM with your email address in and I will contact you off-list.

Yes, I do have the OBEX spec from irda.org, it can be found here in PDF form if anyone else needs it. My question really was a generic one, let me clarify a bit more. Basically what I want to know is:

What is the best OBEX header to use to determine which fifo to send the data to? The questions that I am really asking in order to determine this are:

1. Do other devices send headers that are user-defined (header id from 0x30 to 0x3f) that we will have to handle? This is what the small program I attached to my post will do, identify any headers that I am not handling already.

2. Can you program these other devices to send out a filename of your choosing? Basically if you have a pager and set up an object to beam in the programming language for that device, can you send out the file as yourfilename.yourext?

The reason I want to know is because I was surprised that the Palm API's for sending OBEX objects through the Exchange Manager did not allow you to specify any more headers in the object than the default ones in ExgSocketType, and some of those (most notably type, used to store the mime type) are not implemented in PalmOS versions < 4. This means that someone with a Palm III could not send a mime type along with the object, and I cannot rely on that to determine which fifo to send the data from that object to. Bah. The mime type would have been a perfect way to route objects. Of course I could roll my own OBEX api set for the Palm using Ir Sockets, but we don't want to be waiting for years for that

If you have any more insight on OBEX or the whole IR thing, I would love to have it! I have just learned about OBEX and IrDA protocols recently, and this is really my first project on the subject.

Hi Mark,

OK, here goes with a few answers:
1) I have not seen any devices use user defined headers to send generic information, this doesn't mean there are not any devices out there that do it to communicate in a non-standard way, just that I have never seen them.
2) Generally speaking most devices that you can program to send specific things can have the name field set pretty easily, and using the extention is a good way to do things (that is how a lot of the existing OBEX implementations work) and most devices that allow you to beam objects use the name.format option.

There are some new standards which I don't think are in the public domain yet, that do not use the name field at all, instead they use a targeted connection to let the server know how to route the data by adding the target header (0x46) and a known UUID, check out the section 'known target identifiers' in the spec if you need more information.

The correct way to route information would be to work through the headers in order (of importance, not the order in the packet) and once you find one with some information, use that to route the information you have.

If you have specific questions about IrDA or OBEX feel free to ask, and I can probably answer, although maybe not in a public forum, and as for just telling you what I know, when I handed off that work to its new maintainer it was a 2 month process, so it is not as easy as just tell me everything.

About all I am able to do via IR from my pager is:

SendIRText(String TextToSend, String FileName, String MIMEType)

In the sample code, the mime type is left blank so I'm not sure how it gets sent (I didn't use it either).

Running empire, I sent a variety of objects and they all look pretty normal (to my untrained eye). Here's the output from empire sans bodies.

A text file (memo):

In reply to:

---

Getting object..put_done() Skipped header 42
put_done() Skipped header c4
put_done() Skipped header 44

Object Name: textfile.txt
Object Description: (null)

---

An address book entry:

In reply to:

---

Getting object..put_done() Skipped header c4
put_done() Skipped header 44

Object Name: JoshHarding.vcf
Object Description: (null)

---

An SMS message:

In reply to:

---

Getting object..put_done() Skipped header 42
put_done() Skipped header c4
put_done() Skipped header 44

Object Name: message.txt
Object Description: (null)

---

An alert (song):

In reply to:

---

Getting object..put_done() Skipped header c4
put_done() Skipped header 44

Object Name: Anchors Aweigh.imy
Object Description: (null)

---

A todo list item:

In reply to:

---

Getting object..put_done() Skipped header 42
put_done() Skipped header c4
put_done() Skipped header 44

Object Name: Tasks.vcs
Object Description: (null)

---

A calculator forumula:

In reply to:

---

Getting object..put_done() Skipped header c4
put_done() Skipped header 44

Object Name: formula.for
Object Description: (null)

---

An application:

In reply to:

---

Getting object..put_done() Skipped header 42
put_done() Skipped header c4
put_done() Skipped header 44

Object Name: newapp.air
Object Description: (null)

---

A calendar entry:

In reply to:

---

Getting object..put_done() Skipped header c4
put_done() Skipped header 44

Object Name: calendar.vcs
Object Description: (null)

---

Looks like about half of those have a "42" header... without seeing what that is, I can only guess, but those seem to correlate to things that have a category field on the pager (with the exception of an application). Whatever it is, I don't think I really care... it seems to be sending correct file extensions so your plan of routing based on file extension sounds good to me.

Awesome. The 44 and c4 headers are both date/time fields (44 is ISO8601 and c4 is 4-byte) and 42 is the type field, so your device has the capability to set mime type. At least your function lets you specify the filename, so that is the plan I am going with.

Thanks!!

Where should we put the fifos? More generically, is the /programs0 partition still a standard? If I was using Linux on a desktop, I would be using /usr/local/empire, but it seems like /programs0 and /programs1 is the place where everything else was stored.

With EXEC and EXEC_ONCE should we still be using that structure?

Also, are named pipes the best way for us to simply exchange data between processes, or should I be investing the time to learn IPC and message queues?

This binary appears to not actually write to the files... would it be a pain for you to enable it? The default irobex_palm3 writes, but it doesn't loop and I'd like to avoid having a shell taking up more RAM.

Actually it would be easier to enable looping in the iroblex_palm3.c file. Just do this:

	while(1) {

		IrOBEX_ServerRegister(handle, "OBEX");

		while (!finished) OBEX_HandleInput(handle, 1);

		finished = 0;

	}

Instead of just the one time they move through in irobex_palm3.c

That should do it!

I'll have to play with it more later. Seems like something isn't getting reset. I patched it like that:

--- irobex_palm3.c.orig Tue Feb 18 10:05:06 2003

+++ irobex_palm3.c      Tue Feb 18 23:15:09 2003

@@ -73,11 +73,14 @@

        if (argc == 1)  {

                /* We are server*/

 

+               while(1) {

                printf("Waiting for files\n");

                IrOBEX_ServerRegister(handle, "OBEX");

 



                while (!finished)

                        OBEX_HandleInput(handle, 1);

+               finished = 0;

+               }

        }

        else {

                /* We are a client */

But it only works once:

sh-2.03# irobex_palm3
Send and receive files to Palm3
Waiting for files

..HEADER_LENGTH = 21
put_done() Skipped header 05
CREATORID = 0x6d656d6f
Filename = textfile.txt
Wrote /tmp/textfile.txt (21 bytes)


Waiting for files
Link broken (this does not have to be an error)!
Waiting for files

I tried to send another memo, but nothing happened, so I pressed ^C

Segmentation fault

I'll see if I can take a closer look later.

Oh yeah, that example doesn't take into account that you have to DISCONNECT the source! It relies on shutting down the program to do it. In the function server_done() in the file obex_put_common.c, add in the line:

OBEX_TransportDisconnect(handle);

that should fix it for ya.

I'm getting distracted by the palmpilot side of things for now, but I wanted to share what I've done so far with Empire. Not too much is the short of it, but basically I have a forked server listening for OBEX objects coming over the IrDA port (I hog the port for now) and taking any control.empeg filename and outputting the contents to /proc/empeg_notify. I wrote a short palm app to send one of these objects with the contents of #4EE0! and it inserts a Dandy Warhols song into the current playlist. I've attached the latest source.

Todo: Figure out a way to send /proc/empeg_notify chunks of commands if they go over a limit. Example: I send a obex object with 100 song fid's in it to insert. I think there is a limit on the amount of text you can send to empeg_notify, so we would have to split this up.

I have to say that I'm not 100% on linux daemons, and the server seems to shut down when using EXEC_ONCE in hijack. I'm not sure if I'm fork()ing correctly or if there is something else I have to do to make it so it doesn't die on startup. If I start it from the command line it works fine. Another bug is sometimes you will get the error IrLAP: no activity on Link!! or Unknown frame ef recieved. I haven't had a lot of time to look into those errors, but reading some of the Linux IrDA mailing list posts, it seems like the irda stack in 2.2 is vastly inferior to 2.4, and there have been a bajillion patches since 2.2. We may have to try to manually patch our 2.2 kernel up to where the 2.4 IrDA code is at in order to get a stable IrDA stack. I don't know how easy this would be.

Now that I have this portion, I am working on the Palm application which will allow you to select a list of songs and upload them via IR to the Empeg. I've got a java class making the .pdb file for the palmpilot and it should be able to integrate in with Jemplode pretty easily, you'll be able to do a Tools->Crate .pdb file and then Hotsync that with your Palmpilot. Any suggestions on what to call the Palm application?

After the Palm app is done I will continue work on Empire. What I would like to do is take all the output from the IrDA port and redirect it to a socket, then multiple clients can hook up to this socket and interpret the data coming in. This would basically be the Empire server. I haven't had much success in figuring out exactly where to grab the packets from, but that is next on my list to learn right after the Palm app is in good shape. I think that I have a decent handle on socket programming now, but I will no doubt have some more questions before this is over . I don't think I mentioned this before but everything I write will be GPL'd.

I was inspired by a post on the IrDA mailing list of one person who had a really cool idea. He is hacking into the IrDA portion of the kernel to make a LED blink when an IrDA device is present in front of the reciever, and the LED turn solid when the two devices are sending information. What a great use for the LED on the front! We could make this an option in Empire if we do the low-level shipping of data to a socket.

I put that in the if statement and it seems to have helped a little... now when I hit ^C, it doesn't segfault But I still can't beam a second file

I haven't looked to see exactly what EXEC_ONCE does, but you might want to try catching some signals, probably signal 1, and see if that's what's causing it to die.

Cool.. will do. I wrote the above code as a proof of concept, and just wrapped it in a fork() to turn it into a server, so there wasn't a lot of thought put into it running as a daemon.

Thanks for the suggestion! I'll add signal catching in if I get a chance this week.

Tutorial on daemonizing a process

Got a name for the Palm app.

Palantir

The seeing-stone from LOTR. My app will let you "see" the songs on your Empeg from long distances

It doesn't hurt that it has PALm and IR in it, too.

Edit: Grr, should have checked first. There is already an open-source project called Palantir. Should have figured with the Tolkien reference and all. I'll probably use it anyway, since this app is a very niche app, nobody will see it unless they are on this board or riocar.org.

I tried adding a section to your attached code to have it write to a file if the object wasn't named control.empeg. I added this segment:

        if(strcmp(name, "control.empeg") == 0)

                empeg_command(body);

        else {

                strcpy(filename, "/tmp/");

                strcat(filename, name);

                printf("Write it to a file.\n");

                if(tempfd = open(filename, O_WRONLY) > 0 ) {

                        printf("Writing to '%s' (%d)\n", filename, tempfd);

                        write(tempfd, body, strlen(body));

                        close(tempfd);

                }

        }

but I'm obviously doing something wrong... the call to open() returns an fd of 1 so I write to stdout instead of the file. Can you see what I did wrong?

Maybe it has to do with empire running in the background... I changed to using fopen() and now it works.

Sweet, I'm getting things ironed out now.

Now I can boot the player and without telnetting in, I can send multiple memos from my palm and ttsd reads each of them.

This is what I wanted! Thanks for the work on Empire! I know you've got much more to do for all the features you've got planned, but for now, I'll say I'm one happy customer!