OK, revisiting the idea of detecting the presence of a tuner and getting its id from with in the kernel, I have got this far in trying to work out how to code it. Can someone who knows a bit more than I about talking to ttys from within the kernel check what I have so far is right and tell me how I read characters from the tty...?

My guess is that I would call this from within hijack_init() to set a static tuner_id variable and then do interesting stuff with it based on some new flags in config.ini... Would this be too early to call some of these methods on IRQ_ports[15] ...? and should I be writing the init_data byte by byte instead of all at once with driver.write...? (maybe some other function?)

Cheers

Kim

#include <linux/tty.h>
static int // detect the presence of a tuner module and return its id
tuner_detect ()
{
   int ret;
   char buf[5];
   char init_data[3] = { 0x01, 0x00, 0x01 };
   struct async_struct *info = IRQ_ports[15]; // tuner on ttyS0
   struct tty_struct *tty = info->tty;
   tty->termios->c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP |INLCR|IGNCR|ICRNL|IXON);
   tty->termios->c_oflag &= ~OPOST;
   tty->termios->c_lflag &= ~(ECHO|ECHONL|ICANON|ISIG|IEXTEN);
   tty->termios->c_cflag &= ~(CSIZE|PARENB);
   tty->termios->c_cflag |= CS8;
   tty->termios->c_iflag |= B19200;
   tty->termios->c_oflag |= B19200;

   if ( tty->driver.write(tty, 0, init_data, 3) < 3 ) {
      // failed to send data to the tuner
      return -1;
   }


   // here's where I want to read 3 bytes from the tty... 
   // with a timeout in case the tuner doesn't exist and therefore doesn't reply


   return ret;
}

Okay, I'll see about adding tuner-id detection into Hijack today. One quick question (to save me some experimentation):

Is the tuner-id simply the second byte of the packets from the tuner?

Or is a specific packet required to obtain it?

Thanks.

3rd byte in response to that init sequence according to what Hugo told me here. If it is just a matter of using the right functions let me know and I will nut it out from there, but things are a little more complex in the kernel than in userspace where I can get access to /dev/ttyS0 and the termios functions.

I have some user space code that detects the presence of the tuner happily (and I think grabs the id properly but I haven't needed to check as I only have the one tuner) if that would be any help... though it is mostly userspace versions of the code I posted before using reads and writes over the filehandle of /dev/ttyS0 and using select for the read timeout.

Thanks for your help,

Kim

Mmm.. But my tuner always returns "ID=3", regardless of the setting of the rotary "ID" knob on it.

???

If you want to try this, btw, just use a Hijack kernel, and set "trace_tuner=1" in the [hijack] section.

Look at the serial port output on player startup, and the first message "in" from the tuner is "tuner: in=01000303", indicating "ID=3" regardless of what I set the knob to.

Due to a small flaw in "trace_tuner", the outgoing packets are not currently dumped.. that will get fixed in the next release. I have added code to dump them on my own player, and the "in=01000303" is a response to this from the player: "0100010000000000000000".

Cheers.

Note that Hijack already has a "empeg_tuner_present" variable, which when non-zero indicates that a Tuner is present. This is available only after player startup right now.

-ml

Okay, Hijack already had code to detect the tuner module, and now (thanks Hugo) it knows how to read the "twiddly thing" (tuner dial on back).

What do you want to do with it?

-ml

Well, the first thing would be to make the Tuner ID available in a /proc/ file somwhere so people like Kim can read this to find out the Tuner ID rather than futzing in kernel space.

A second thing would be to have tuner-id specific variable configuration(s) in config.ini based on the Tuner ID - like @work/@home does now.

That would mean folks with more than one Empeg could customise their settings of their player based on the 'docking station' its docked into e.g. when moving between vehicles or between home and car docking stations.

[I have both situations - multiple players in cars and a home docking station].

Thats my input on this.

What I need to do is be able to set force_dc based on the presence of the tuner before the player starts... as number6 said and I said before this would be easiest to use if it was available as a conditional in the config.ini...

Something like

;@ID=3 force_dc=1

which would change the dc variable in kernel on startup (before the player starts) so when the player reads /proc/empeg_power it thinks it is on DC.

Thanks for this... will help me not have to recompile a new kernel and rebuild the secondary partition every time a new release comes out to work around the hardware fault in my empeg.

Cheers

Kim

Sorry, but the reading of config.ini cannot happen until LONG after the ac/dc power source decision is made.

-ml

Oh well... at least it will save me having to rebuild a partition with each release of the player software... I will just have to keep patching and building my own hijack kernels so the dc is forced on my empeg...

If I can see where the tuner gets detected the patch to set empeg_on_dc_power and not load the setting from flash is small...

Cheers

Kim

This is the problem... I need to be able to know a tuner is present BEFORE the player starts as it needs to be early enough to set the empeg_on_dc_power variable.

Cheers

Kim

Mmm.. yes, you're the person with the broken AC/DC detect hardware.

When I get time, I'll see about doing it early enough to help you, using a bit or two from flash to enable/disable it. I guess it would be nice to do something where it's triggered on the knob-ID, but the whole knob-ID would use too many flash bits. Maybe we'll key off just the last bit or something, even / odd knob-ID.

Did you say you have working kernel code already for this?

Cheers

Any assistance would be great... even in the form of pointers as to where I should look to read bytes from the tuner (and checking whether my writing to the tuner code makes sense)

Currently I am running a 2.00beta3 distribution with a v62 hijack kernel patched to boot from /dev/hda5 instead of /dev/hda3 and with an added ioctl to set the dc_power flag from user space.

My hda5 partition is a copy of the 2.00beta hda3 partition with a modified init that checks for the presence of the tuner (from usespace talking to /dev/ttyS0) and calling the ioctl to force dc when in the car. This works fine however it means every time there is a new release of your hijack kernel I need to repatch and build my own version of the kernel to test it (not a problem but it means I don't stay as up to date like recently...) but more time consuming is when a new player dist comes out which requires me rebuilding my hda5 partition to match it... Hence I am still back at 2.00beta3 and hijack v62 as work has swamped me to the point I haven't managed to get time to build the kernels and partitions.

Moving the tuner detect to the kernel will save me having to use userspace code and ioctls to work around the hardware fault and mean I don't need to boot from a modified root partition and so can stay current with the player releases more easily... building new kernels is less of a hassle so if I still need to maintain my own patches that isn't a problem (though it will mean I will probably lag behind the bleeding edge hijack kernels a bit)

I am happy to try and work out the code myself if I can get some pointers, but so far have hit a brick wall hunting for example code on talking to serial devices from within the kernel as it is usually something that is done from userspace (unless it is an IR dongle or a suchlike... but then the code is obfuscated by the IR wrappers etc...)

As for not being able to put flags in config.ini, does that mean the player software reads the /proc/empeg_power stuff to work out whether it is in the car or not before it reads config.ini?

Anyway thanks for any help you might point my way... it would be nice to catch up to the hijack kernels that will give me easy ftp access to start playing with my GPS again...

Cheers

Kim

(Sorry for the long winded post *grin*)

Mmm. Here's what needs to be done for this:

1) insert new code into the kernel, invoked from hijack_init() in hijack.c. This routine is invoked when empeg_display.c starts up, where the AC/DC power mode setting is first used (to select the appropriate animation). Fortunately, this happens just after the serial driver gets initialized, so we can safely use it to talk to the tuner.

2) the new code has to set the correct bitrate/serialmode, and then send the tuner inquiry out, and wait for a response. The inquiry should be 0x01 0x09, and will result in a four byte reply of 0x01 0x09 0x0y 0x(9+y), where 'y' is the setting of the twiddly knob (or possibly it's inverse).

If you want to work on it, try to get those two things going for you, and once I get to it I'll take it from there. For now, just busy-wait inline for the reply; I'll make that more cpu-friendly later on.

Cheers

Mmm. Here's what needs to be done for this:

1) insert new code into the kernel, invoked from hijack_init() in hijack.c. This routine is invoked when empeg_display.c starts up, where the AC/DC power mode setting is first used (to select the appropriate animation). Fortunately, this happens just after the serial driver gets initialized, so we can safely use it to talk to the tuner.

2) the new code has to set the correct bitrate/serialmode, and then send the tuner inquiry out, and wait for a response. The inquiry should be 0x01 0x09, and will result in a four byte reply of 0x01 0x09 0x0y 0x(9+y), where 'y' is the setting of the twiddly knob (or possibly it's inverse).

If you want to work on it, try to get those two things going for you, and once I get to it I'll take it from there. For now, just busy-wait inline for the reply; I'll make that more cpu-friendly later on.

Cheers

OK I have managed to get some code that can detect the presence of a tuner... but it can't work out the ID as I am not getting the responses back I expect.

(I think) I am sending the bytes 0x01, 0x09 then when I read back 4 bytes I get 0x00, 0x02, 0x02, 0x37 (I think)

This only happens when I have the tuner connected so I can use this much to detect the presence of the tuner... but the response doesn't change at all if I change the tuner's ID...

I am about to go back and try sending the 3 byte init string Hugo originally sent me of 0x01, 0x00, 0x01 and see what I get back...

I am also pretty certain I am not dealing with the serial port registers correctly as when I plug it into the mains after having initially flashed a kernel the reading times out (as expected) but after taking it to the car and testing (and getting the 4 byte response) when I bring it back in and plug it into the mains it doesn't timeout and instead manages to "read" 4 bytes of 0x00...

Cheers

Kim

Responses from the Tuner always always always begin with 0x01, so what you are seeing is not correct. Something's wrong there (bitrate?).

-ml

OK... sending the different init string gave me exactly the same response... which would lead me to suspect I am not talking to the serial port properly...

As I have very little idea about talking to serial ports from within the kernel I am quite happy to admit defeat here and just stick with being able to detect the presence of the tuner at all...

I have attached the current patch to hijack 232 I am playing with if anyone feels like taking a look and pointing out all my glaring errors (there are a few I am sure)... The patch still has my debugging in it and fails to detect the tuner... also I was wrong reading what I was getting back from the tuner earlier... I am actually getting 0x00, 0x02, 0x00, 0xff back no matter what tuner ID I set (rather than 0x00, 0x02, 0x02, 0x37 as I originally though).

Cheers

Kim

*sigh*

I think I am going to have to try and resurrect one of my laptops to build empeg kernels on... tis a slow process having to walk out to the car each time I want to test another kernel build...

Cheers

Kim

Any news on this topic?

One thing I would like to have is to enable/disable the ftp/http server based on the tuner id. I have two sleeds, one in the car and one in my dooking cage at home. Both have tuner modules installed. So only detecting the tuner module doesn't help me.

At the moment I have no possibility to enable the severs only at home. No need for a http server in my car at the moment. :-)

The easy solution is to use AC power in the home dock.

What do you mean with easy solution?

a.) Plug in the AC power at my home empeg docking station?
--> Not possible without additional mechanical work. It's a closed box with tuner inside and ethernet connection interface.

b.) via the hijack menu?
--> Not a good idea to switch every time.

At the moment I plug in an empty AC power plug, so that the empeg thinks it's on AC power, even if it isn't. (mechanical switch insite the player)

If I have time, I'll look at the code kimbotha posted to find a solution.

By "easy solution", I mean just fix the home dock so that it inserts the AC plug whenever the unit is docked. My is set up this way, very simple and easy to use. Just shove the player into the docking cage, car or home, and it just plain works. No manual fiddling with plugs or anything.

Cheers

Sorry,

I moved on to trying to get the kernel executing user space binaries once I got my code detecting that there was a tuner attached at all... I hadn't realised anyone else was interested... I will go back and see if I can fix the communication with the tuner and work out what I am doing wrong... tis a little time consuming to debug as it requires a trip to the car every time I want to test a new change...

If you feel up to coding you may have a better setup to develop on seeing as you have a tuner in your home sled...

Cheers

Kim

Don't know when I have time to look for a solution, because I have a lot of other things to do at the moment. So if someone else finds a solution it would be great.
And yes it's true, I have a better environment to develope and debug in house.

It's a while back since I last compiled my own kernel (with the rds fake hack in it, now included in hijack). Since then it is much easier and faster to just ftp the new kernel up, instead of using the serial connection.

Besides: I was the other person with the same empeg hardware fault. But in the meantime, mine was fixed. :-)

*nod*

well I will have another go when I get around to it... at the moment trying to work out pipes inside the kernel is a little more interesting and easier to play with here than trekking out the car continuously...

I may get around to getting the actual hardware fault on mine fixed one day... but then I am planning on heading to the UK to work later this year so I might just wait until I can drop in to the empeg guys themselves and ask them nicely...

Cheers

Kim

To bring up this thread once more.

I looked at kim's kernel patch to detect the id, but for me it seems it doesn't detect the tuner at all. I'll look at it once more maybe the next weekend.

But for now there seems to be another problem. As Mark already mentioned: The tuner always delivers ID 3. Maybe the ID isn't working at all. Any help from the empeg team?


Here is part of my serial output:
<4>tuner:out=00
<4>tuner:out=00
<4>tuner:out=00
<4>tuner:out=00
<4>tuner:out=00
<4>tuner:out=00
<4>tuner:out=00
<4>tuner:out=00
<4>tuner:out=00
<4>tuner:out=00
<4>tuner:out=01
<4>tuner:out=00
<4>tuner:out=01
<4>tuner:out=00
<4>tuner:out=00
<4>tuner:out=00
<4>tuner:out=00
<4>tuner:out=00
<4>tuner:out=00
<4>tuner:out=00
<4>tuner:out=00
<4>tuner: in=01000303
<4>tuner:out=01
<4>tuner:out=ff
<4>tuner: in=01ff2726
<4>tuner:out=01
<4>tuner:out=04
<4>tuner:out=0a
<4>tuner: in=0104070b
<4>tuner:out=01
<4>tuner:out=04
<4>tuner:out=0b
<4>tuner: in=01040004
...

I don't see a "read tuner dial" message in there anywhere.

To read the knob, send "0x01 0x09", and the Tuner will reply with "0x01 0x09 0x0y 0x(9+y)", where "y" is the dial setting.

-ml

OK perhaps I should rephrase what I said about where the patch is at... I always get the same response from the tuner with the patch as it stands... and currently the patch checks for that response which allows me to detect the presence of the tuner... the code that checks for the correct response is commented out in hijack_tuner_detect()

I would guess I have not set up the serial port correctly before sending the init string and trying to read it and am just getting lucky and sending a string which gives a consistent reply back from the tuner...

As far as I can gather the code in my patch (ripped and copied from elsewhere in the empeg serial setup code) disables interrupts before starting its workand then tries to talk to the port at a very low level so I doubt you will see the conversation in the serial debug lines... but I am not sure... I haven't tried it with a laptop hooked up in the car...

Please feel free to pull it apart and start again... I don't really know very much about how to talk to serial ports from within the kernel.

Cheers

Kim