Rockbox

You may want to post what commands work, and under what conditions they might be expected to work, so that if/when people try the patch who can’t read source, they know what they can reasonably expect, and what they should report problems with (if anything at this point).

As well, a suggestion (for anyone interested in this patch) might be to add a means for logging the things that aren’t recognized yet for further development.

Sadly its not yet good enough for my car stereo to detect that my ipod video is connected, as it still just displays a message indicating that no ipod is connected.

Yes, it currently works on very few devices, namely those who use 19200 baud and only send Mode 2 commands. The more advanced devices use higher baud rates and also mode 4.

I have much more work to do before this gets usable.

I am not having any better luck with the official apple ipod radio remote under rockbox ether with my ipod video 5.5G.

Sound works and the volume up and down buttons do adjust the volume but the status bar volume indicator dos not change.

Does it work with the itrip that works with the headphone+remote port? I need rb to be able to do that.

I have no idea. Try it.

Linus: Perhaps you should commit this so that more people can try it? (And hopefully so that someone else takes an interest in working on it, either for the ipods or else the Sansas…)

At least I don’t see any reason not to include it.

I bought an unofficial Ipod Radio Remote for my 5.5G, and it does not work at all with rockbox, including this patch. Works fine in the OF, but on rockbox I can neither listen to radio (I assume radio is not supported at all on Ipods), nor use any of the controls, not even volume up/down.

I would love to see progress on this driver, but unfortunately i can’t code. I am happy to provide my testing though!

I’m trying to add Apple protocol support for my JVC car head unit. The serial port on my 5G Ipod is not working though. When I probe the output line of the JVC the signal is only 200mV, it is like the signal is in contention because the Ipod port is not set as an input. I have the latest source code. Original firmware works fine.

Any idea? Thanks!

I don’t have many ideas, sorry. One explanation may be that you need to send something to the JVC to make it enable the serial port. I have yet to find out how to enable the transmitter on the iPod. I have the same issue with the original Apple FM receiver, which need two-way communication to work.

Have you tried enabling the accessory power option? Buschel made it sound like it wasn’t needed for serial, only for adapter power, but perhaps it is?

Thanks guys, I did enable the accessory power option. With it disabled the JVC will say “no ipod.” With it enabled the JVC hangs and flashes “reading.” Looking at the signal with my oscilloscope the JVC is really trying to send data as I can see the serial signal. Every half second or so the JVC sends out a couple bytes but the amplitude is very low. When I load the Apple firmware the amplitude is 3.3V like it should be and everything works.

For some reason my ipod is not turning on the serial port. It’s like the serial port input is really set as an output.

In the source I see “/* Route the Tx/Rx pins. This probably applies to the PP502x only */” Maybe I need to route the pins a different way. I don’t have the documentation describing the 0×70000018 register, maybe you can point me in the right direction?

Ah well it seems a NDA is needed for docs. I’ve disassembled FW 13.6.2.1 in IDA Pro, any idea where to look?

Look for accesses to the registers that are used for the serial port. Hopefully, the port pin configuration is done at the same time as the serial port initialization.

It was quite hidden but I found and fixed the port problem, the GPIOs need to be setup:

  (*(volatile unsigned short *)(0x6000D950)) = 0x4000;
  (*(volatile unsigned short *)(0x6000D960)) = 0x4000;
  (*(volatile unsigned char *)(0x6000D970)) = 0x40;

  (*(volatile unsigned long *)(0x7000008C)) &= ~4;
  GPO32_ENABLE &= ~4;

I now get a solid 3.3V signal on the serial input pin.

I’m showing my ignorance of Rockbox here, but is there an easy way to output incoming bytes to screen or file?

The debug screens continuously poll hardware addresses (see /apps). You could probably slip your register into there, and maybe stuff them into a queue so that you can read the last few bytes worth.

I have it working now, my JVC will display the current track playing, with skip, pause, etc. There are still a few glitches to be worked out; it doesn’t always get the id3 data correctly when changing tracks. Also ffwd/frwd isn’t working yet.

I’ll post a patch of my changes when it’s a bit more solid.

Thanks for the help guys.

Hi Ryan,

Maybe post your work-in-progress anyway, people may be able to help out with stuff like the track transition…

Here is what I have so far. FF/RW is working and the track transition is ok but not really perfect. The problem I have is that the JVC will tell the iPod to change tracks and then immediately request the new track info. The track info did not have a chance to update so it sometimes gets the old data. What I’ve tried to do is to defer processing the next command until the last one is complete but it still does not work 100%, and I don’t know the best way to detect when the last command (track skip, pause, etc) is truly complete in RockBox. Right now my code will just indicate a track change to the JVC a little while after and then the JVC will request the info again. Not really ideal.

Another problem I have is that sometimes my build will cause the iPod to crash somewhere in thread.c on startup. None of my code should even be running yet. If I change the length of the code with asm(” nop”); then it will work! I haven’t tested if it is my code, my build tools, or what.

   iap.patch (28.9 KiB)

Your patch works quite nicely with my 80GB ipod video and the official Apple radio remote, Allow the key map could do with a little work and it would be nice if rockbox
could remember what volume was set on the remote instead of resetting it to full volume each time the remote is connected.

@ Ryan,
Your patch is working pretty well,
but I too am noticing some buttons mapping problems.
Maybe it is just the devices I’m using,
but the vol+ and vol- buttons do not work.

I am using a Nano, (just added the Define from the video config over)
and the iPod Radio Remote,
but I believe these would use the same protocols,
right?

I don’t have a remote so I’m actually surprised that the remote stuff still works. :)

I have no idea how the volume stuff is handled by RockBox as my JVC head unit does not use the volume commands. The remote and volume stuff was in Linus’ patch above and I just copied it over. I’ll try to have a peek and see if there is anything obvious that is wrong but I have no way to test it.

Ok it seems the radio remote has hardware volume. This would explain why it is full volume when it is first connected, but not why Justin’s volume does not work at all. Maybe Justin has his headphones plugged into the top connector.

http://forums.rockbox.org/index.php?topic=8937

The dock connector is line out (duh) so changing RockBox volume would have no effect on the sound out of the dock connector, and that is why the remote has a hardware volume control.

Yes I did,
lol.
Thank you.

applying this patch on the latest rev (17555) breaks playback.

Music gets played at twice the speed and a high pitch

I just updated to 17560 and it works fine, if you reverse the patch it sounds ok?

Here is the compiled rockbox.ipod for iPod Video 60 GB (64MB RAM) 5G

   rockbox.ipod (596 KiB)

I simply compiled a plain build of 17555 and one applying the iap.patch file (”patch -p1 < iap.patch” from within the checkout folder. Only the patched build had the speed/pitch issue, I’ll retry wih a later one.

I still get the same weird behaviour on rev 17564 (I only have MP3s)

I’ll attach my rockbox.ipod file

   rockbox.ipod (595.6 KiB)

Yep your rockbox.ipod makes mine play too fast as well. It is smaller than mine for some reason too…

Does my rockbox.ipod work on your iPod?

What iPod do you have, size of hard drive, etc?

your rockbox.ipod works fine on my 5.5G 80GB ipod.

I just don’t understand what I am doing wrong. do I need to apply the pp-serial-6.patch as well as the iap.patch?

also, with your rockbox.ipod, my unofficial radio remote does not work. I can hear sound, but no controls work at all.

I’m not sure what is going on. Try this one; I removed the 4G init stuff. I’ve been having a weird problem when compiling as well that I never figured out.

My patch contains everything in pp-serial-6.patch so just use one or the other. Have you tried just the pp-serial-6.patch?

So what do you mean unofficial radio remote? Can you post a link to your device?

   rockbox.ipod (596 KiB)

And here is the new patch

   iap.patch (30.5 KiB)

the ppserial 6 patch works “fine”, as in no garbled audio, but no controls.

your latest iap.patch also works fine in regards to audio, but again lacking controls

this is my remote in question:

http://www.pearl.de/a-PX2069-1608.shtml

it’s basicaly a clone of the apple radio remote. It has a switch on the side to put the ipod into radio mode. It works fine in the OF. I bought it, because it is much cheaper than the official one. By looking at the dock connector, only the following pins have a connection: 3,4,12, 13, 15, 16 and 18 (left to right)

Well, glad to hear the latest patch doesn’t mess up the audio. My guess is that your remote uses some part of the iPod Accessory Protocol that has not been implemented yet in the patch. I used a serial port monitor cable I made to view the communication between the JVC and my iPod. I then implemented those commands. Some of them I didn’t even understand how they worked but I stuck them in anyway.

Serial Port Monitor?
Any chance of it being easily made?

You should just be able to splice in another connector to any serial port device and plug it into a PC serial port, though this may be easier said then done depending on how your accessory fits into the apple dock connector. Then you can record whatever commands are being sent over the interface using a serial port monitor program.

This device might prove useful.
http://www.rush2112.net/mkportal/modules/oscommerce/product_info.php?products_id=34

Forgot to mention - I am willing to buy and gift said product if it is useful to any dev.

Justin, the iPod serial is TTL, so you will need a MAX232 or similar chip to translate it to regular PC levels. I used an old PDA docking station that had that translator circuit inside it. The protocol is pretty much half duplex, so I just “or-ed” the in/out lines together with a diode and a resistor similar to this: http://www.lammertbies.nl/picture/en_db9_monitor.png and wired it into the docking station RX pin.

I tapped into the wires from the JVC, but a better way would be one of these from Ridax: http://home.swipnet.se/ridax/soldext.jpg

David, can that device be inserted between the iPod and an accessory? It looks like it makes the PC into an accessory, which would be useful in sending commands to the Apple firmware for testing. Do you know of anything that would work as a monitor, similar to my kludged together docking station?

That “device” is nothing but a breakout connector. It is perfect for this. I have one myself, for this very purpose. Unfortunately, I haven’t had time to hook up my RS232 analyzer yet, to analyze the radio remote protocol.

Ok,
way too technical for me.
Any chance of a software end to the problem?
(A capture patch for rockbox preferably?)

Something like this:
http://www.rockbox.org/tracker/task/6494

Problem is,
it hasn’t been updated in over a year.

A capture plugin would be useful, but you won’t be able to see the response that the Apple firmware sends back because the Apple firmware will not be running, Rockbox will be running.

Maybe something in the bootloader that hooks the serial interrupt, and then the Apple firmware will load on top of it. It might work but will be pretty complicated.

Here is a little patch that will display the first 8 bytes of the last RX’d packet in the “View I/O ports” of the debug menu.

Sascha, try that with your remote and tell me what it says. If the command is documented somewhere then I could implement it.

   debug_menu.patch (0.7 KiB)

Do I need to apply the serial driver patch as well?

Apply both iap.patch and debug_menu.patch

ok, now I can see the entry in the IO port menu.

staying in that menu, without pressin *any* button (neither on the ipod nor on the remote), the IAP PACKET changes every 10 seconds.

while pressing nothing, the values “cycling” are

45 08 1e 20 04 d8 45 08 and so forth, sometimes instead of 1E, it reads 1A, but the sequence stays the same

pressing any button does not change that sequence either, looks like the remote is “polling” or something.

Hmm, I’m not sure what that means. The first number should be the packet length, the second the mode, and the rest the command. Your data doesn’t match up. It’s quite possible your device is running at a different bit rate. The Apple firmware has auto rate detection; the Rockbox one doesn’t and runs at 19200. Everything I’ve seen so far runs at 19200 but it’s possible your remote runs at a different rate.

You can try changing the divisor on this line in serial.c:

SER0_DLL = 0x4c; /* 24000000/76/16 = 19736 baud */

It might be 9600, so change it to this and see what happens:

SER0_DLL = 0x9c; /* 24000000/156/16 = 9615 baud */

Interesting,
is seems my length bit isn’t including the mode bit.
It’s this way for both my Radio Remote,
and iHome.

Radio Remote:

Play:
 04 02 00 01 00 F9 21 E1
Left:
 04 02 00 10 00 EA 21 E1
Right:
 04 02 00 08 00 F2 21 E1

iHome:

Play:
 03 02 00 01 EA 55 03 02
Off:
 Unknown (Flashes some command multiple times)

Ryan, I tried changing the divisor as you said, but the behaviour hasn’t changed, just the values of the sequence. It’s now
44 80 92 46 80 92 46 88
as before, button presses do not change that sequence.

Oh never mind,
I thought the length bit included the checksum.

Sascha, here are some more values to try. Maybe I can figure out the auto rate detect in the future.

0×27 for 38400 bps
0x1A for 57600 bps
0x0D for 115200 bps

using 0x1A as divider gives some progress.

When not pressing anything, the Packets are: 06 02 00 00 00 00 00 F8

pressing play will yield this sequence, for the time play being held: 03 02 00 01 FA 00 00 F8

same with ffw: 03 02 00 08 F3 00 00 F8

rev: 03 02 00 10 EB 00 00 F8

switching to “radio” on the remote shows: 02 00 05 F9 00 00 F8

I also noticed, that with this divider, plugin in my remote seems to send the center-button event (select), and then lock the touchwheel on the ipod wont repsond anymore. Pressing play on the remote has the same effect, i.e. rockbox enters the currently higlighted entry and the only button that has any effect is the play button on the remote. I can’t get back.

Replace your apps/iap.c with this one and see if it fixes the locked out problem.

   iap.c (15.1 KiB)

yes indeed. this new iap.c file does no longer “lock” my ipod when connecting the remote, I can navigate using the touchwheel again.

The remote codes for pressing the buttons stay the same :)

So does your remote work then? It looks like I do implement those remote codes that you mentioned so they should work. The radio is not supported however.

indeed, i didn’t think about testing that :D

they work now

Here is the newest version patch with autobaud. Can you guys try it and let me know if it works with your device? Apply just this patch to a clean SVN checkout.

   iap.patch (32.5 KiB)

Hi Guys,

I am trying to getting in this code. I tried to apply the patch
debug_menu.patch (0.7 KiB) to debug the status of the serial port with no success.
I get the error:

LD rockbox.elf
/home/luis/develop/rockbox/build/apps/debug_menu.o: In function `dbg_ports’:
debug_menu.c:(.text+0xe78): undefined reference to `serbuf’ collect2: ld returned 1 exit status
make[1]: * [/home/luis/develop/rockbox/build/apps/rockbox.elf] Error 1
make: * [build] Error 2

Any suggestions?

Just use the latest iap.patch and nothing else.

Anybody get a chance to try the latest iap.patch?

I applied the patch on May 24th and it worked perfect. I have an Ipod 30GB Gen. 5.5.

It’s working great for me,
only problem is the off button on the iHome doesn’t work properly,
but I believe it is sending the 4 bit off command.
Is this supported yet?
(I don’t think it is.)

Thanks guys.

Justin, what are the bytes displayed in the debug page for that off command? Is that button supposed to turn off the iPod completely?

I don’t know,
it flashes some command multiple times.
Most of the time the length bit changes,
but every once in a while the param bit does also.

It turns if off (or puts it in a deep sleep) in the Apple firmware,
then changes it to charging mode to charge.

Hi, I’ve encountered one problem, and one issue.

The problem is that on line 230 in iap.c the Mode 2 3-byte command size “serbuf[0]” should be 4 not 6.
The issue is that my logic3 clock dock communicates at 9600 baud and the autodetect doesn’t go that low yet. If its possible to make it, that would be great!

Other than changing the above, it works great and rockbox gets even better!

It seems there are variations to the remote commands. For example, my JVC sends this for ‘play’:
FF 55 06 02 00 00 01 00 00 F7

I’m guessing yours does not send the two extra 0×00 at the end… I will make the code work for both.

Yes the autobaud did not support 9600. I couldn’t figure out how to make it support 9600 as well as 38400. Maybe 38400 is not important so here is another version that supports 9600 instead.

   iap.patch (34.1 KiB)

Could we not add an IF statement to check if the bit we are processing equals 00?
If so,
try another bit?

The length still needs to be checked because if the packet it a 2 byte one, for example, and we check the 3rd byte then we are reading the checksum which is not valid data.

The buttons could be OR’d together I guess but I don’t have a remote to test to see if that works and I don’t think rockbox does anything with multiple button presses anyway.

Do those working on this patch want me to start making an “unsupported build” including this patch in an attempt to gain wider feedback on accessories it works on, as well as more command debug info?

Sounds great, and maybe some web page (wiki?) listing supported devices, something like that.

Thanks for the new patch - autobaud detects 9600bps fine.

Your right, my docks commands are missing your ending 00 bytes.
It also sends mode 2 3-byte repeat and 4-byte shuffle commands that I’ve ‘added’ from the mode 4 code, adding an if statement to check (serbuf[0] >= 5 && serbuf[4] == 0) before the 3-byte check.
Is there any plans to further extend the mode 2 support?

I don’t have any remotes to test with, and I’m not excited about writing code that I can’t test. Why don’t you upload your diff and I will add it to my patch at the least.

My builds seem to have broken after updating recently,
I can no longer get my Radio Remote to work properly.
What happened?

I just did SVN update 17674 and it works fine for me. Did you try an older version of the iap.patch?

Yes,
it works with the old autodetect iap.patch,
but the current one breaks support for it.

Heh, fix one remote and break another. I think this version will be more robust and work for all. Please test it and tell me if it works as I have no way to test it.

   iap.patch (33.9 KiB)

Here is the above patch with mode 2 shuffle and repeat commands added. This covers all the functionality my dock has.
I’m getting problems with held key repeat though on the shuffle and repeat commands - I’m wondering if it would be an idea to implement a skip until the mode 2 button release command has been issued? I think rockbox deals with the held key repeat for the play and stop commands.

Thanks again for working on this patch

   iap2.patch (34.7 KiB)

Nope,
still doesn’t work.
I get randomly placed FC’s, 1C’s, and E0’s after each button click.

Justin, try this one and see what happens. I can’t see a reason why the old autobaud would work and the new one won’t; however I disabled a double check in the code and that may allow it to work.

Craig, I implemented something for key repeat for the shuffle and repeat commands, let me know if it works ok. Rockbox has WPS actions for stop and play but not for repeat and shuffle. Without implementing it as a WPS action it won’t go through the key repeat stuff. It could be implemented that way but there aren’t many bits left for additional buttons so I think implementing it in iap.c is a better choice.

   iap.patch (35.2 KiB)

It is still broken,
receiving the same FC’s, 1C’s, and E0’s.

The attached are the only differences between an original autobaud patch,
and a slightly modified autobaud (With the differences copied from the current.)
that produces a broken build.
(Modified patch on the left, original on the right,
Pink lines mark differences,
Red symbols mark the differences.)

   rock1.JPG (46 KiB)
   rock2.JPG (89.7 KiB)
   rock3.JPG (77.3 KiB)
   rock4.JPG (89.2 KiB)

Justin, in the serial_setup() function (in serial.c) change this
SER0_DLL = 0x1A; /* 24000000/26/16 = 57692 baud */

to this
SER0_DLL = 0x4E; /* 24000000/78/16 = 19230 baud */

That should get it to work until we figure out what is going on.

Dang,
still not working,
it just has new bits this time.
I’ve got CC’s FF’s 4B’s 0A’s C0’s 10’s D4’s 11’s,
and all other random bits on held buttons,
no change on button press.

Well, I refined the autobaud some more, not sure what else to do. It works with my JVC at 19200, and I’m pretty sure your remote is the same rate.

Give it a shot and let me know what happens.

   iap.patch (33.1 KiB)

After bringing the above patch up to r17684 by replacing CPU_HI_INT_CLR with CPU_HI_INT_DIS, I’m getting weird issues where rockbox stops responding to the keypad but clickwheel works, and remote keys appear to be stuck (such as a press on skip track resulting in stuck fast forwards).

Hmm, sounds like the autobaud is being too aggressive and resetting the baud rate, thereby losing the key up command. If the rx function receives any invalid characters between packets it will reset the baud rate.

I think at this point autobaud is not good enough and the best option is to use a configurable baud rate.

New patch, now with configurable bitrate in the system settings menu.

   iap.patch (40.1 KiB)

Ok,
it will not work when I first put in the Radio Remote,
but it will when I select 19200 from the menu.

But,
it works again when I hit Auto,
which leads me to think this option isn’t working right?
(Wouldn’t it stop working again, since it couldn’t find the right bitrate in the first place?)

Ok,
it will not work when I first put in the Radio Remote,
but it will when I select 19200 from the menu.

But,
it works when I hit Auto afterwards,
which leads me to think this option isn’t working right?
(Wouldn’t it stop working again, since it couldn’t find the right bitrate in the first place?)

Here is my experiment at combining the high and low rate autobauds - it detects my 9600bps successfully after one packet has been received. This might be rubbish for the higher bauds, I can’t test them, but it was just an idea.

   iap2.patch (39.6 KiB)

Justin, my guess is that the autobaud is getting stuck in some mode by the commands sent by the remote when you first plug it in, and that is why when you reset autobaud (after the remote is plugged in) that it then works.

Craig, I tried your patch and it works fine with my JVC @ 19200, thanks for your work!

I added some packet handling to mode 0 in iap.c, now it works with my FM transmitter (if I connect the FM transmitter to the dock connector, it turns on and transmits). No picture blocks (yet?)

   iap+transmitter.patch (41.1 KiB)

@ztr
I get the following error when I try to build with your patch:

iap.c: In function ‘iap_handlepkt’:
iap.c:664: error: syntax error at end of input
make[1]: * [/home/user/rockbox/build_nano/apps/iap.o] Error 1
make: * [build] Error 2

I’ve combined the mode 0 packet handling from ztr with the updated autobaud patch, this builds ok with r17713

   iap.patch (40.8 KiB)

Looks promising. I have one key issue that I would like to adress, and that is accessory detection.

The accessory has a resistor between pin 21 and ground. The iPod measures the resistance to find out what type of accessory is attached. It is done using the ADC_ACCESSORY A/D channel, but we need to find out how to apply a voltage to the resistor to be able to measure. I guess it is done either via a port pin or the PCF chip. We can probably find that out by disassembling the Apple firmware.

I tried last patch and it appears to work with Sony ICF-C1iP (play/pause, prev/next/rewind) and its remote (only menu, up, down, enter buttons don’t work).
Other device that I have is iHome iH9BR – no luck with it because it doesn’t support iPod Nano that less than 3rd generation.

The latest version of the patch is the first version work with my factory fitted stereo’s ipod connector in my Volkswagen Golf.

But the patch is not yet perfect as I have to go into the settings menu and reselect auto each time I boot rockbox to make the patch work with my official
Apple radio remote.

I just wanted to add that I have tried the patch on an ipod video 64Mb in a Bose sounddock. Previously I had playback but only the volume control buttons were functional (as they control the dock not the ipod). However with the patch applied the fwd/rev buttons work for skipping tracks, and fast forwarding and rewinding within tracks. The play/pause button works as intended. Congratulations on this patch, this was the last area where rockbox lacked compared to the apple firmware.

This patch should add support for the DICE stereo addon, although only track mode is supported, not tested. It also will build in IAP support for 4G greyscale and color; this has not been tested at all but I think it might work, so somebody try it!

   iap.patch (43.5 KiB)

Modified mode 2 handling to allow for incorrect length parameter

   iap.patch (43.5 KiB)

This patch is almost perfect! thank you, not being able to use my S9 (bluetooth headset) on my ipod nano with the D650 Motorola bluetooth adapter to skip songs was the only thing in rockbox that i didnt like.. One thing though, for you on you jukebox, do you have 2 press the forwards,backwards, play or pause button a few times before it responds with the action? This is the only downfall but its no big deal… Thak you for making such a useful patch :)

I have an Alpine headunit with a KCA-420i adapter for my iPod (4G with CF mod). I applied the patch on the latest svn version yesterday. It builds, installs and boots with no problem, the headunit detects the iPod, but fails while “searching”. I guess it’s requesting status from the iPod, asking for playlists, or something else not implemented currently.

I’m thinking of implementing what’s missing. I have no idea howto, though. I thought I’d let you know, if anyone worked on the issue, maybe I can get some pointers :).

Some while ago i was playing with a custom dock connector, then i found out that changing the volume of the ipod did not affect the LineOut Volume.
So my question is, Rockbox disabled LineOut Volume control by default. How would this affect the iPod accessories ?

Is a compiled build of the latest patched rockbox.ipod version available for download?
I am presently not able to build it myself. Thank you for this nice development!
I am using my Ipod with an Dension interface for Audi.

There is a forum thread for this build, with a link to a site providing daily builds : http://forums.rockbox.org/index.php?topic=17841.0

Is there any reason the current version of this patch cannot be committed?

Ryan: Just purchased a JBL Onstage Micro (v2) last week just to use as speakers (IT ROCKS, by the way) but was thrilled when I compiled with your patch and actually got good use of my remote control. Skip back, forward, and play/pause buttons all usually work normally from the WPS with or without accessory power supply turned on. Occasionally the play button has caused shuffle to be turned on. Sometimes prev/next stay stuck until I press the button again. Also, I get weirdness if I try to use play in the menus or filebrowser (it’s interpreted as “select” most of the time) ..a few minutes ago it seems got stuck actually–none of the keys on the ipod were registered except for the scroll wheel rolling, while the play (on remote) button still selected it’s way through menus (eventually after some fiddling things came back).
Had a look at the source and I’m definitely intrigued with playing around with this. I was gonna post what I found for the iap packet values, but they seem to be different quite often, ESPECIALLY play, next, prev. There seems to be some pattern to what’s changing…anyway. For now I’ll just post what the ones that never do anything–anything in straight brackets being different observed values for that character.

00 02 00 00 fb 40 b9 f[f76] menu
00 02 00 00 fb 80 79 f[f76] select
00 02 00 00 fb 00 01 f7 scroll up
00 02 00 00 fb 00 02 f6 scroll down

So any thoughts on what I am seeing with all these changing values? Couldn’t pin next and previous down at all… Also, how come I the leading 00 ends up as a 03 if I do commands from while in the debug menu?

There is limited support for any IAP commands outside of the while-playing-screen. It sounds like sometimes the iPod is receiving the keydown command but not the keyup command. Not sure why that is happening, the best way to diagnose is to insert a hardware serial logger in between the devices; that’s how I do it.

In your above commands the first command is really 03 02 00 00. The first 03 is being overwritten by 00; this occurs when the Onstage receives an ack to the command, which is does not receive while in the debug menu. The rest of the bytes are really just junk from the previous command, so the FB 40 B9 FF are not part of the 03 02 00 00 command, they are part of a previous command.

The best way is to get a hardware serial logger; I realize this isn’t easy for most people.

Attached is the patch slightly modified to work with the current build 19053. I tested it with my JVC head unit and it worked the same as always.

   iap.patch (43.9 KiB)

Wow. I see. Well that’s a bit disappointing about the whole “rest of the bytes are really just junk from the previous command” thing. I wasn’t expecting to use the remote when I bought this anyway though–pretty cool that it already mostly works… From one Ryan to another, thanks for taking the time to shed some light on those things for me. :)

“evilny0” mentioned making a logger patch that would log the IAP data to a file. Maybe you could convince him/her to upload that patch.

The debug menu interface is just a hack that dumps the contents of the packet buffer.

we should start discussing getting this committed.

Just has a quick look at the patch and it looks OK except for the english.lang part of the diff (has some .mine »» ««< lines)
One thing though, why is there the SYS_IAP_ events? why arn’t they in tick tasks? or possibly using the newer event api instead of being in misc.c

Running the routines in the tick task and serial interrupt would mean it would run in the interrupt context and not allow anything else to run. I’ll look into this newer event API to see how to implement it.

hmm yeah fair enough, the newer event api will run in the same context so wont really make it better.

dumb question. How do I apply these patches?
I’m running build 19053 on a 3g ipod. I’d like to try it out with a Dension connector in my car.
Presently, the ipod plays but I was hoping to control it via the car deck or the steering wheel buttons rather than the ipod directly since the connection, and hence the ipod, is in the glove box.
thanks!
Mitch

Go here and use Soap’s build:

http://forums.rockbox.org/index.php?topic=17841.0

By the way, I found this link just a few comments above this one.

The patch as it stands now only is for the 4G Gray, 4G Color, Nano, and Video. Manoutoftime has a 3G. Should this work on the 3G if I #define IPOD_ACCESSORY_PROTOCOL
on the 3G?

Oh, Sorry! Well there is some init stuff in there, it looks like it’s not for 4G based on the response of “evilny0”. Perhaps it will work for 3G but it’s a long shot. The ifdef stuff in serial.c init would have to be changed as well.

Can anyone else confirm that this patch does or does NOT work on a 4G iPod?

I can confirm it does not work with a 4G Greyscale. Music plays through speakers, but no tag info or steering wheel control on DICE unit.

Doesn’t seem to work with a Mini 1G either - I tested in an iHome (one of the newer ones) and if the player is paused, pressing the play button starts it playing, but the play button is all that works, and when pausing, it pauses for about 0.5 seconds and then resumes.

I do get sound from the speakers, but I get that without the patch applied as well.