Rockbox

iPod Video, 5.5G, 30GB model. The Kensington FM Transmitter w/RDS model K33364US:
http://us.kensington.com/html/11206.html
The iPod can charge from the unit, but the audio is not transmitted to the car radio.
Otherwise, appears to function normally.

I suspect this may not be easy to remedy, if at all. The transmitter has software code built in to it, which allows it to display the FM station (it's transmitting on) on the iPod screen.

Contact me for help with testing.

Forgot. Rockbox v3.1

Dave: Please re-test with a current build - 3.1 doesn't have any support for the Ipod Accessory Protocol.

I tried hooking up an 80GB iPod Video to my AVIC-D3 car stereo. It could sucessfully charge, however playing audio didn't work. The stereo was also unable to get playlists or search by artist/genre.
I tried with r20074-090221. It should have been a daily last weekend or so.

Tested my Kensington transmitter with current 20102-090225. The iPod charges, and the audio does get transmitted. But the track title and track artist still doesn't get transmitted to the radio display, via the RDS protocol. Can this be implemented?
When I look in System - Debug - View I/O ports, the ACCESSORY number alternates, mainly on 867, then frequently to 866, and occasionally to 869, 864, 863, and once or twice I saw 865.

Status update with my stereo:
I changed the stereo to Video mode. This is for watching videos from the iPod where the stereo pretty much just acts like a TV. It displays whatever is on TV out and plays any audio coming out of the iPod port. When doing this, I can hear the music from the iPod. However, remote doesn't work (and it never was designed to) requiring control directly from the iPod. Music mode does not work at all. There it allows you to search by Album, Genre, Artist, etc. and control the iPod. In this mode nothing happens.

Forgot to mention, this was r20112-090226

Patch for 4G iPods:

http://www.rockbox.org/tracker/task/9920

Tested on two remote control devices using both an iPod Video 5.5G 80GB and a Nano. Each remote works OK, but not completely, with slight differences between the two different iPods. Codes read from the 5.5G as the Nano screen is too small to view full hex code.

Rockbox version r20200-090304. I'm not a programmer so can't contribute to the code, but if there is any other info I can provide to help this project, let me know.

1. Logitech PureFi Anywhere 2 http://www.logitech.com/index.cfm/speakers_audio/ipod_mp3_speakers/devices/4320&cl=us,en
These rechargeable portable speakers include a remote control. Volume on remote operates the speaker volume, not the ipod, so N/A here.
FF/RW and skip forward/back work, shuffle and random buttons work.
Play/Pause short press works, but reasonably long press activates menu mode, subsequent presses of play drill down in menus. Can't back out of menus from remote because Menu, Up, Down, and Select do not work. Works with accessory power on, doesn't work with accessory power off. In debug, Accessory: alternates between 0 and 1.
IAP packets: (?) indicates lack of confidence, some of these flashed so quickly, I can't be sure I read the changing characters correctly.
base state: 03 02 0D F1 00 00 1D 00
Logitech power on: flashes 05 02 00 00 00 02 F7 00 (?) then 03 02 00 00 FB 02 F7 00 ,
powering off again: flashes 05 02 00 00 00 02 F7 00 (?) then 03 02 00 00 FB 04 F5 00
Play/Pause: quick press: FF FF 00 01 FA F9 F7 F6 (?) press and hold: 03 02 00 01 FA F9 F7 F6
RW: 03 02 00 10 EB 02 F7 F6
FF: 03 02 00 00 F3 02 F7 00
Menu: flashes 05 02 00 00 0B 40 B9 00 (?) then stays 03 02 00 00 FB 40 B9 00
Select: flashes 05 02 00 00 0B 80 79 00 (?) then stays 03 02 00 00 FB 80 79 00
Up: 06 02 00 00 00 00 01 F7
Down: 06 02 00 00 00 00 02 F6
Shuffle: 04 02 00 00 80 7A F7 F6
Repeat: 05 02 00 00 00 01 F8 00


2. Monster iEZClick RF remote. http://www.monstercable.com/productdisplay.asp?pin=3714 This is a weather resistant RF remote for operating an iPod tucked away in a pocket, say while skiing or snowboarding.
Volume up/down works, FF/RW and skip forward/back work as expected.
Play/Pause short press works but an unreasonably short press and hold on the remote, which is designed originally to turn on/off the standard ipod firmware (this would really be sleep/unsleep?), I get two different results in Rockbox on the Nano vs. the 5.5G. On the Nano this pauses, then activates menu mode, further presses on Play/Pause drill down in the menu. No way to back out from or return to now playing from the remote. On the 5.5G the Play/Pause press and hold works like pressing the center select button on the iPod during playback: takes you to the location of the currently playing track in the file tree. Allso no way to back ou from the remote. On the remote pressing play/pause and FF or RW simultaneously is originally designed to go to next or previous playlist. Not sure how Rockbox might use the last two, currently seems to have no effect in Rockbox. Switching between playlists might be cool. I can imagine one playlist for on the ski lift and another for the run.

Importantly for this particular device, the delay allowed between a quick press and a press and hold is very small. It is too easy to accidently send the iPod into menu mode by pressing the play button for more than the shortest tap. Since menus are not useful for this device, perhaps this play and hold could be deactivated for this device in Rockbox?
ACCESSORY: 0, 1, 2, and 3 seen, mostly 0 and 1.
IAP packets again read from 5.5G:

base state: FF FF FF 00 00 00 00 00
Play/Pause: quick press: 03 02 00 00 FB FF FF FF press and hold: 03 02 00 01 FA FF FF FF
RW: 03 02 00 10 EB FF FF FF
FF: 03 02 00 08 F3 FF FF FF
Volume up: 03 02 00 02 F9 BA FF FF
Volume down: 03 02 00 04 F7 BA FF FF
Play/Pause + FF 04 02 00 00 20 DA FF FF
Play/Pause + RW 04 02 00 00 40 BA FF FF

Hope this is helpful.
Very happy that iPod Accessory support is advancing. One of the advantages of using these particular devices is the wide range of accessories available for them.
Many thanks to all you coders!

My headunit is sending a mode 4 "0x00 0x28" command. Meaning, according to the description of the AAP protocol, to execute playlist selected earlier in 0x00 0x17 command at the track position in parameter. The current code does not handle this command. Do you think it should actually be a "start playing current selected playlist" command ? I'm not sure I understand the "execute" playlist.

I added a log function to IAP. It's logging ingoing and outgoing IAP packets in "seriallog.txt" file, in the root folder. You can find it in the attached patch file (diff with 3.2 sources). I hope it can help finding problems. Header (FF 55) and checksum are removed from the log. Should look like this (example taken from the connection to my Alpine headunit, only the first few packets sent) :

--> 03 04 00 12
<-- 05 04 00 13 01 0B
--> 03 04 00 33
<-- 08 04 00 34 01 36 00 A8 01
--> 12 04 00 32 00 00 01 00 01 00 01 00 00 00 04 00 00 00 00
<-- 06 04 00 01 00 00 32
--> 03 04 00 1C
<-- 0C 04 00 1D 00 00 00 00 00 00 00 00 00

Hello

I have such a Dockingstation:
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=250406256466

But my iPod don't react or very bad by pushing buttons on ir-remote.

It works fine by runnin in Apple-Software.

What can i do, so it works?

bye

iPod Mini 1G, three accessories in use here. I also have access to a couple of Nanos (currently not running Rockbox - they belong to other family members) that I might be able to do some testing with.

1st, iHome with IR remote. Playback works, as does charging. Remote doesn't do anything significant to the iPod (the play button causes a momentary pause/resume, and the remote turns the volume up/down but that's handled in the iHome and not the iPod). Track switching and iPod menus non-functional.

2nd, Belkin auto kit. If I boot into the Apple firmware and plug the device into the Belkin RF transmitter, it'll tune the station; I can then reboot and use Rockbox as long as I don't lose power (ie, accidentally unplug the Belkin from the lighter socket in the car) and leave the iPod plugged in. Can't retune to another frequency without a reboot - buttons on the device are completely non-functional.

3rd, JBL "On Time" docking station. I don't use this a lot myself, but I can test with it if that is of use.

Sorry, should add that I've tested with several daily builds, tested with 21183 most recently, just updated to 21476 this afternoon. I am set up to patch and build if needed.

60GB iPod Photo (r21884-090715) with Ten naviPlay (NIA-S10-M) BT adapter and Motorola S9-HD headphones

Audio works great, no FF/RW or Play/Pause controls.

Full control of my iPod 5.5G was working with two simple accessories previously with the former IAP build before it was commited to SVN, it still works :)

***Altec Lansing IM600 docking station (http://www.alteclansing.com/index.php?file=north_product_detail&iproduct_id=inmotion_im600)
-Play/Pause works as expected.
-Prev/Next skip (short press) works as expected.
-Forward/Rewind (long press) works as expected.
-Long press on Play/Pause switches between "Now plating" and previous menu called (menu control is impossible with only two buttons).
-Charging works too.
-Volume control is totally indepedent: it goes from 0 to 30 on the dock. It doesn't have any effect on Rockbox (even visual). Rockbox volume control has no effect on output volume too.

***Griffin AutoPilot (http://www.griffintechnology.com/products/autopilot):
-Play/Pause works as expected.
-Prev/Next skip (short press) works as expected.
-Forward/Rewind (long press) works as expected.
-Long press on Play/Pause switches between "Now plating" and previous menu called (menu control is impossible with only two buttons).
-Charging works too: a 2-LED combination tells you about battery charging status.
-Track info through RDS was partially working, sometimes late or stuck on previous track (I need to restest it)

Tested with unsuppoted IAP build until latest Rockbox build, with "Accessory power supply" both on and off (no effect on compatibility) and "Serial bitrate" set to "Auto".
I don't know how to add those results on the TWiki :)


Currently I can't manage to establish communication between my 5.5G iPod and my Kenwood car headunit (a KDC-W6541U wih built-in iPod control) under Rockbox.
It works fine with Apple firmware, the Kenwood logo shows up on screen and everything is under control through the headunit.

***Kenwood KDC-6541U headunit (http://www.kenwood-electronics.co.uk/products/car/cd_receivers/KDC-W6541U/)
-Until 3.2 release: All different options and combinations tested (i.e. Accessory Power Supply, Car Adapter mode...) but once it's plugged to the headunit, Rockbox goes into disk mode, then the headunit displays "iPod error", then disk mode says "OK to disconnect".
I tried to turn "iPod mode" off into the headunit options -> same result.
I can't go any further... The headunit is stuck with its "iPod error".

-After 3.2 release with new USB mode, behaviour is the same except Rockbox doesn't reboot into disk mode, but USB mode.

Pressing "Menu" while inserting the cable to prevent Rockbox from going into disk mode/USB mode unfortunately doesn't help -> same "iPod error" on the headunit.

Too bad because this headunit won't even recognize the iPod as a standard USB storage device ("iPod mode" off)...
Any help appreciated to help this work!

Alex :(

Some additionnal info for the Kenwood KDC-W6541U headunit:
Values taken from the "View I/O ports" screen.

-Normal status, Kenwood headunit off/unplugged:

GPIO STATES:
A: 28 E: 21 I: 58
B: F9 F:02 J: E3
C: F0 G: 00 K:1E
D: A0 H:00 L: A8

GPO32_VAL: 40004000
GPO32_EN: FE80FEF2
DEV_EN: C0011966
DEV_EN2: 00000000
DEV_EN3: 0000003F
DEV_INIT1: 00040000
DEV_INIT2: 40000000
ACCESSORY: (VARIES BETWEEN ~910 AND 1023)
IAP PACKET: 00 00 00 00 00 00 00 00

-Kenwood headunit plugged:

GPIO STATES:
A: 28 E: 20 I: 58
B: F8 F: 02 J: E3
C: F0 G: 00 K: 1E
D: A0 H: 00 L: B8

GPO32_VAL: 40004000
GPO32_EN: FE80FEF2
DEV_EN: C041196E
DEV_EN2: 00000000
DEV_EN3: 0000003F
DEV_INIT1: 00040000
DEV_INIT2: C0000000
ACCESSORY: (VARIES BETWEEN ~910 AND 1023)
IAP PACKET: 00 00 00 00 00 00 00 00

Disconnecting the headunit, return to "normal" values.

Test was made inside the debug menu, or with "Menu" key pressed while plugging in order to access the debug. Both and also all options show same result ("Accessory power supply", "Serial bitrate", etc...).

Pressing keys on the headunit don't send IAP packets (always 00 00 00 00 00 00 00 00). The headunit says always "iPod error".

Hope this helps!

Update: after having using latest build (22166) patched with Cédric Maire's IAP logging, the test shows that IAP communications between Rockboxed iPod and the headunit are completely silent...

On my iPod Video 30gb, when connected to a Monster iCarPlay200 Wireless 200, on the 3.3 release. The iPod will randomly pause itself, turn on shuffling (no matter what the actual setting is), unpause itself, play for a few seconds, turn off shuffing, pause itself, then play again. It will continue this as long as it is plugged into the iCarPlay. The iCarPlay did work on a previous build of rockbox (one of the rXXXX versions).

slightly better logging, only in works though (or at least for me....)
logs to a buffer and flushes to disk when the disk is spinning already.... I might just make this a setting and get it commited soonish

You may test a fresh build with FS 10494 (ipod remote patch): it features a better accessory identification and should help to detect the accessories like docks,etc.

Donpipo: about your Kenwood KDC-6541U, it looks that it is connected with USB, and iap over usb isn't coded yet.

I have a mini2g and the wired remote don't work. Does any patch out there make the remote work? I'm new to rockbox and i'm still trying to patch :S.

Serial is not enabled on mini2G, so there's no chance to make it work right now.

Is this remote connected to the dock port or is it something like an extra ring on the headphone plug?

Oh, I see :( You can see the remote in this page (generation 3): http://www.maushammer.com/systems/ipod-remote/ipod-remote.html

Mini2G has the same hardware as the Color, that is supported.

So, it is possible to activate it on Mini2G, the only thing is I really don't know if the UART activated would be connected to that port.

@Laurent/Creposucre:
Is what you call "IAP over USB" what Kenwood (and other headunit manufacturers) "iPod 1-Wire Connectivity"? Some info here: http://www.kenwood-electronics.co.uk/technologies/ipod_solutions/
Just out of curiosity...
Thanks for clues!

Yes, it is.

That "one wire" features the accessory protocol over usb plus digital usb audio ("Simple connections plus enhanced audio quality" as they say)

I have an ipod mini 2nd gen that works well with the the maxell ipod remote control (this one: http://www.target.com/gp/detail.html/192-6469050-8947107?asin=B0007XFGC2&AFID=Froogle_df&LNM=|B0007XFGC2&CPNG=&ref=tgt_adv_XSG10001), but rockbox doesn't recognize it. I have the rockbox version r24803-100221 installed. Is there anything I can do to see if rockbox is recognizing the accessory? What are these hex codes that folks are referring to?

As said before, rockbox doesn't recognize any accessory on ipod mini 2n gen since serial is not enabled on it...

If you have any C skills, you could try to enable serial on it to find out what's happening

I have a 5.5G iPod 80GB and have just tried connecting to a Hitachi AX-M136i Micro HiFi using build r24889M-100224.
The following keys on the Hitachi remote appear to work OK,.
Pause/Play, Random, Next Track, Previous Track, Volume +/-.

The FF and Rewind keys sometimes appear to function as FF (+ 5 seconds) and Rewind (-5 seconds) but at other times they act as Next Track and Previous Track.

The following keys do not work in the same manner as the Apple software.
Album + (Next Album), Album - (Previous Album), Stop, Power Off.

I will try again with the FS10623 IAP Remote V4.0 patch when I get some time and see if there is anything different to report.

Is there anything else I can try and report back on ?

Tried again with r24889M-100224 with FS10623 patch on my 5.5G 80GB with the Hitachi AX-M136i and found the following.

Accessory Value 869/870

Remote Key Action Code
Power On - Plays 'Resume Playback' Code 06020000 0002
Pause/Play - Pauses Code 06020000 0200
- Plays Code 06020000 0100
Stop - No Effect Code 06020080 0000
>>| - Next Track Code 06020000 0000
>> - Next Track if short Press Code 06020000 1000
- Fast Forwards if long press
|<< - Start Of Track if short press Code 06020000 0000
- Previous Track if long press
<< - Rewind seconds if long press Code 06020000 0020
Random - Random next track Code 06020000 8000
Alb + - Nothing Code 06020020 0000
Alb - - Nothing Code 06020040 0000
Standby - Displays Charging Code 06020000 0004

How can serial be activated on mini 2nd gen ?

iPod 5G 32MB build of anything after Rockbox 3.4 (so 3.5 and 3.6 do not work) with <a href="http://www.amazon.com/Sony-Bluetooth-Wireless-Transmitter-Black/dp/B000XRW09Y/ref=sr_1_3?ie=UTF8&s=electronics&qid=1282353671&sr=8-3">Sony Bluetooth adapter for iPod</a>. No joy. Tried stable 3.6, and current build (r27850 at time of writing)

Normal operation in 3.4 is: Turn on, plug in, iPod is discoverable. Would love the newer features and stability of 3.6, but this is definitely stopping me from upgrading this particular iPod

Also, iPod 4G Grayscale screen has same issue, only in 3.4

Iaplogging updated on rev.27860

Testing the Macally iVoiceIII Microphone with an iPod Video 60g, rockbox version r27773-100811.

This is a mono microphone which plugs into the dock port and also provides a stereo line-in port:
http://www.macally-europe.com/productpage.php?product=1341

In the iPod firmware, it is detected automatically: the iPod switches to Voice Memo. When recording, a blue LED lights up inside in the microphone. Nothing happens when connected to Rockbox, although the following accessory and IAP packet values appear on the debug screen:

Accessory values: 0, 1 and 2.
IAP Packet: 0E 00 13 00 00 00 03 00

The line-in feature is working with Rockbox's recording screen, but the microphone isn't.

Do you have a dev environnement set up?
Could you try to patch iap_logging_v1.1.patch on latest svn and post the log?
It would help me a lot

Yep. Here is a log of inserting and removing the iVoiceIII. The contents repeat exactly if you insert and remove it again.

Inserting a jack into the bottom of the microphone (the only other thing you can do with it) does not affect in the log.

Using an iPod Video 30GB, Rockbox 3.6, SVN r28099, patched with the v1.1 Patch. Accessory is the Sony Bluetooth dongle. Nothing happens at all when plugged in, but the IAP section in the I/O ports moves around a bit in the 90s.

Using an iPod Video 30GB, Rockbox 3.4, SVN r24500, patched with the v1.1 Patch. Accessory is the Sony Bluetooth dongle. Nothing happens at all when plugged in, but the IAP section in the I/O ports moves around a bit in the 90s.

Attached patch cleans up apps/iap.c a bit.

Changes:
* separated the functionality for the various modes into their own static functions (one function per mode), making the code more manageable
* added a single function to send a mode 4 OK response and avoid code duplication.

This patch actually makes the binary about 500 bytes smaller, source size is about the same :)

Please try, I can't test this myself because I don't have and ipod + accessory.

Using an iPod Video 30GB, Rockbox 3.7.1 iHome iP90. Audio out only works when I the play/pause button first then put it in; the audio only comes out at half the volume it should be at. None of the buttons work or interact with the iPod when its in the rockbox firmware. Charging is also intermittent.

Hi,

I am trying to use my iPod 5.5G 80GB with an Alpine CDE-103BT Head Unit.fitted with a KCE-433iV cable. The unit works perfectly with the Apple Firmware but with Rockbox build 28831 the Head Unit only ever displays SEARCHING or ERROR-01. I have done a bit of digging with the iaplogging patch as well as using a breakout cable to capture the commands used by the Apple firmware and it appears that the Head Unit sends an Apple Computer Certificate Authority file to the iPod using Mode 0 command 15 and expects and a response back from the iPod using Mode 0 command 17 which I assume contains an encrypted response. Without the correct response, the Head Unit keeps sending a reset and then requesting the correct response again. Is there anyone out there who can assist me in trying to get this Head Unit to work with Rockbox ? I have a development environment using VMWare and willing to try anything to get this to work. I did notice that Ryan Press (rpress) managed to dissemble the Apple firmware. ( FS#8624 ) and I wonder if the dissembled output from the firmware would help in the IAP commands used by Apple.

Thanks

AndyP

Hallo,

I really like Rockbox and I use it for over one year now.
Have got an "iPod radio remote" cable for my iPod Video 30GB which you can plug into the dock connector.
When I start to hear radio it works just fine, but after ~ 10 seconds or so I hear a clicking sound in the right channel, than it fades to the left like you would turn a balance control to the left and from then on I only hear on the left side of my headphones (regardless of whether plugging the phones directly into the iPod or into the radio remote). Also the volume from radio remote and from iPods click wheel is not synchronous and the buttons of the remote control act with latency.

I switched to the apple firmware while booting...radio works in stereo and volume is synchronous all the time, all buttons work instantly ("iPod radio remote" requires iPod Software v1.1 or newer, I have v1.3).

Seems 2be some latency bug in the radio plugin from rockbox?!

Hope this report helps a bit making rockbox even better.
Thanks for this great jukebox system!!!

btw: Is there a functioning remote that have the exact buttons from the ipod with menu button on top and pause button at bottom instead of volume control like the radio remote has so you can use/make a kind of gamepad for playing with "zxbox"?

Andy,

in iap.c->mode0->case 15, could you remove the lines "iap_send_pkt(data0, sizeof(data0))" and "iap_send_pkt(data1, sizeof(data1));" and recheck if it passes the authentication challenge?

On the ipod fm radio, if you answer to a command 15 with a command 19 instead of 16+17, it acknowledges the authentication process without even dealing with the certificate commands( 17 and 18)

It's exactly what case 15 is doing, but maybe the commands order confuses your head unit.

If it does not work, you can try to send a command 16 before the 19.

Hi Creposucre,
Thanks for the suggestion. Removed the two lines but still doesn't pass authentication.
I have attached the log file that was generated with these changes (seriallog.033.28837) as well as the log file from the Apple OS (seriallog.apple.001).
I did change iap.c->mode0->case 05 by removing the last data[] byte (0x28) so as to reply the same data as the Apple firmware to the Alpine.
I'm willing to try anything to get this to work.

the ipod answer is a bit strange... with the fm remote, it sends only one time command 15...

You should try to acknowledge command 15 (00020015) and at the 8th sent, send the command 19.

if it doesn't work, send command 16 and 27 to mimic the ipod firmware dialog, then try to send command19.

HI,
When sending command 19 on the 8th sent, the comms stalls after the command 19 is sent. See attached seriallog.037.201012219130-19.
When sending command 19 after 16 and 27 on the 8th sent, the comms stall after replying to a mode 0 command 28. See attached seriallog.038.201012230650-19. This is futher than before but different to what the Apple firmware does.
Does anyone know what a mode 0 command 28 should respond with?

I think it's because you answer with command 15 on the 8th sent, instead of replacing it by command 16.

One thing that is interesting is that it looks like it's lways the same challenge; so the key that the ipod send back should be always the same.

so, replace command 15 by command 16 on the 8th sent, then send:
002700
0017C2A57791488416CC5875DC04ADEB4E3F1007A40001

the accessory should send:
IN FF5503000F00EE
so send 0010000106

the accessory send
IN FF55020024DA
and send 00250000000000000001

Done the above, now gets a bit further before stopping.
It now appears to be the same responses as the Apple firmware until it stops after the Mode 04 code 34 response to a code 33.
Any thoughts as to why it stops here ?

I have noticed that the Apple firmware doesn't always send the same challenge., but it does appear to always send the same challenge when first powered up.

AndyP

Could you try to send command 19 instead of 16?

And another test:

remove the send of command 14 at the beginning, and try to send a mode 4 command, e.g 03040012
The mode 4 commands request the authentication, but if the ipod doesn't ask for it, you may be able to access them freely.

Device: Logic3 i-Station TimeCube
Status: partially working
What does work: ipod charging, pressing the "power" button on the clock sends "play" to the ipod, if set to "continue playback" the ipod will continue playback and the TimeCube will output the sound just fine.
What does not work: using the alarm function. When the alarm sets off, you can see on the clock that it starts in ipod mode, then shortly after (1 second) it'll fallback to "annoying buzz" mode. Works fine in OFW 1.3

my uneducated guess: Either the clock can not identify the ipod properly or it hits some sort of timeout.

Ipod: 5.5G 80Gb (64Mb)
Rockbox: r28935

Thanks for all the help so far,

Tried sending command 19 instead of command 16. See attached seriallog.192717. Comms stopped after sending the command 17 response.
Tried sending 04001D (Time/Status info) instead of command 14. See attached seriallog.04001D. Comms stopped after sending the 04001D.

Cars now in the shop being fixed. Will try sending 040012 to the Alpine when I get it back. Will report back the result.

AndyP

Car back from shop and have tried sending 040012 instead of 04001D. Gets a bit further, responses are

IN 0E0013000000110000000600000200
OUT 0400020013
OUT 03040012
IN 0304001C
OUT 0C04001D00048546000154BE01
IN 0404002901
OUT 06040001000029

Now appears to stop after sending a cmd OK in mode 4.

Any thoughts ?

Thanks

AndyP

hi -

long-time RB user, first time car-with-ipod-connection owner. i'd love to be able to help at the level of detail of andyp but not sure how.

here's my situation:

iPod: 5G Video (80GB)
Vehicle: 2011 Honda Odyssey Touring Elite (w/Nav)
RB Version tested: latest build as of yesterday
Result: flashing "unsupported" on the stereo.

It plays files from flash drives fine, so I figured it would see it as just another hard drive - nope. Booting to iPod GUI and it works fine.

Please let me know how I can help test.

Thanks,
C

Hi,
I had a problem with my iPod dock (a logitech Pure-Fi Elite): when I turned it off, the iPod didn't stop playing music, and so the dock was immediately turning back on.
So I wrote a little patch that does the work correctly, and I join it.

But the code the dock is sending is not documented, at least when a searched this web page http://nuxx.net/wiki/Apple_Accessory_Protocol , as I was advised in IRC.
So would you be kind enough to test this patch, and tell me if it doesn't work as expected ? (The worst this patch can do is stopping music playback inappropriately...)

And I want to thank you all rockbox developers for having made a so nice and commented code, that I could hack very easily...

Lovasoa

What do you want us to test? if the patch works? Or if the code looks OK (according to coding style, etc.)

Both!
But mainly, I would like that you ensure that the patch doesn't stop music playback when you are using another function of your iPod accessory...
So you can apply the patch, then connect the iPod to your accessory, start music, and try all the functions of your accessory (just press every buttons) ...

Hi, Still working on getting my iPod 5 5 to work with the Alpine.
Have managed to get a bit further but now have an issue with the Alpine sending a code that Rockbox discards.
I have attached the log (seriallog.apple) created with the Apple firmware by capturing the serial port in/out commands.
The Alpine sends the following command (line 35), FF550001F704003200000100C000420000003000000..................000009F which according the iPod Extended Interface Specification Release R21 is a SetDisplayImage command which writes a bitmap to the iPod in a 'large telegram format'. Rockbox rejects this because it uses a value of 00 in byte 2 to denote the large telegram format but this byte is normally the length of packet and Rockbox rejects it because it is 00, so I need to do some work to get it accepted. Any thoughts on the best way to implement this change ?

As the Alpine does not get an ACK for this command, it times out and eventually reports an ERROR-01.

But still making headway, 1 line at a time

AndyP

Apparently, no one cares about my previous patch..
But I wrote a new patch to support different features related to playlists.
As this is my first consequent patch, it may not be in Rockbox code guidelines. So please review it...

Hum, I posted iap.c instead of the patch

lovasoa, I think your logitech_shutdown patch can be quickly accepted, but we first need your real name for that.
I can't really comment on your iap_playlists patch, I'm no playlist expert (and I don't even own any ipod or ipod accessory to test it with).

AndyP, I think you're right, we don't seem to have any handling at all for large packets indeed. I think the proper way to handle this, is:
* teach the function that handles packet framing and checksumming (iap_getc) how to handle large packets, its output should be a length word and a buffer pointer
* modify the handle_pkt functions to take the length word and buffer pointer and operate using that, instead of trying to extract the length by itself from the receive buffer.

My real name is Ophir LOJKINE.
For my playlist patch, there is only one playlist-related function that I call. I think you can review it: the main problem may be the coding style...

Attched is a patch that updates the iap_getc function to also handle large packets. The patch introduces a state machine for that, which (IMO) makes the de-framing code much easier to follow.

This patch completely freezes my iPod (black screen) when I use the "get playlist" lingo from my accessory...

Lovasoa, sorry to hear that. I don't know yet what causes this exactly, I'm suspecting a race condition.
I'll continue with the large packet patch in a FS#12135 : http://www.rockbox.org/tracker/task/12135

iPod Video, 5.5G, 80GB model. Motorola D670 Bluetooth transmitter, Rockbox SVN r30212.

When plugged directly power the light on for 2 or 3 seconds but does not connect or register with a bluetooth headset. If plugged in the "View PCF Register" Debug Item, the dongle is correctly initialised and seek for a bluetooth headset (first to register then to connect).

The remote control only work for fast rewind and partially for fast forward with my bluetooth headset (Sennheiser PXC310BT)

Hey all,

Back again in Rockbox 3.9, iPod Video 30GB. Same Sony BT accessory, same Sony BT headphones. Haven't used either in a while, so obviously the >3.4 thing exits. Does the patch from October last year still work, and is the recommended way to get this working again? Or should I load up VMWare Player and find the variable I changed?

-Josh

Back again. Added normal IAP patch, came up with an iap.c.rej. Went to make, and all seemed to build fine. Attached the .rej file. I could have sworn someone in this thread told me to manually change a serbuf == value, but I can't seem to find it. Will post back if/when it works/breaks!

Using Rockbox version 3.9.1 (latest stable as of today) on iPod Video 5th gen 80GB, although I've already noticed the problem on earlier versions.

Controls on the iPod work fine when docked to JBL On Stage II external speakers. However, the some of the remote control's buttons don't work.

What buttons work as expected:
VolumeUp and VolumeUp long press- increases the volume on the speakers (iPod volume untouched)
VolumeDown and VolumeDown long press - decreases the volume on the speakers (iPod volume untouched)
FastForward long press - forwards playback within the currently playing song
Rewind long press - rewinds playback within the currently playing song

What doesn't:
FastForward - rockbox treats the button as a long press instead of skipping to the next track
Rewind - rockbox treats the button as a long press instead of replaying the song from the beginning
Pause/Play - stops the currently playing song and returns to the main menu instead of staying on the playback screen; slow/no response when resuming playback while at the main menu

There is probably something wrong with the button mappings or perhaps some unimplemented features? I'd be glad to help if you need more data on the problem.

Thank you.

iPod Video 5G, 30GB. Trying RB 3.10 with Sony Stereo Transmitter TMR-BT8IP Bluetooth dongle, and Sony DR-BT101 Bluetooth headphones. No joy still. Tried with Accessory Power on/off, Line Out on/off.

I blew away the dev environment a while back, so I didn't try the patch up above, from 23 October, 2010. Is there no work being done upon this wonderful aspect of Rockbox anymore? Is this related to 10623 at all? Should I look at both when trying this? At a loss, and the battery life in 3.4 is abysmal compare to the newer versions. Any ideas? Any feedback on my previous posts?

Hi Josh,

Things have moved a bit with IAP.
From my point of view, I have manged to get my iPod Video 5.5G to function with an Alpine Head Unit using some code from a git tree based on inputs from FS#12135 (IAP Large Packet Support). I don't know if this will help on your issue.
Would you be willing to risk a build that I made from this git tree at http://git.camperquake.de/rockbox.git ? This build includes a patch that will dump a max of 64K's worth of IAP commands to disk wheh selected via System->Debug Menu->Dump Log File.

It certainly wouldn't hurt, as I have the iPod Video in front of me, and a clean backup of the 3.4 that was running.

Though, I don't see a place to click 'download' for a pre-compiled binary. I take it that tree needs to be compiled for it to run on anything? Which means I'd have to re-setup the dev environment, huh?

I've just copied it to http://andyp.dyndns.info/rockbox.zip

Andy, thanks. Though, for my 5G iPod, isn't it 32MB for the 30GB and 64MB for the 60/80GB?

And just to be sure, this does not allow the dongle to do anything other than blink twice when pressed (after plugging in, nothing happens). The headphones don't seem to respond at all, either.

Again, tried Accessory Power Supply on/off, Line Out on/off. Rebooted between tries, as well. Nothing. :(

The latest code should work on both 32MB and 64MB iPods.

When you have tried everything, go into System->Debug Menu and select Dump Log File. You should then have a file in the root dir of the iPod that should contain the last 64KB's worth of IAP commands. It would be good to get a copy of this file and see if its actually doing anything.

Here is the log of me starting up, looking at the Line Out and Accessory Power settings, plugging in, waiting, pressing dongle button (headphones were already discoverable), LED blinks twice, waiting, removing dongle. Rebooting (hold select + Menu), turning Accessory Power off (nothing happened), then Line Out off, and Accessory Power on, got the blinking twice, but nothing else.

I don't believe it is your problem, but why are you rebooting with Menu+Select? That's not a clean shutdown and should only be used to escape from hanging crashes. It's akin to pressing the reset button on your PC.

Hm....I never thought of it that way, though you are right, now that you mention it. I will run the tests again using the 'clean' shutdown method, and then reboot.

A quick look in the log file suggests that the ipod is not getting the proper information in the IdentifyDeviceLingoes (0x13) command.

Can you ensure you save the log file before rebooting/shutting down the unit. I can't remember if the log appends or overwrites if you do multiple dumps to disk so it might be worth renaming the file before yo write to disk again.

Just retried the tests using the clean shutdown. Also, before I did, I read your comment here, and looked at the log via 'view log', and it seemed to continue incrementing the timestamp. Here is the new log.

Unfortunately, I did not rename the log, I though it would auto-increment the name to the date/time. Hope this helps with this 0x13 command!

Here be another log for your log-viewing pleasure. Deleted and started anew! Still the same filename, though!

The log name is created at compile time so will always be the same for this build. It is also set to overwrite if it already exists.

I have created another build that appends instead of overwriting.
I have copied this to http://andyp.dyndns.info/rockbox.ipod Nothing else has changed within the build.

There is also another build that automatically creates a log file of the serial commands in a different manner but it sometimes causes the ipod to hang.
If you could run this one as well. I have copied this to http://andyp.dyndns.info/rockbox.ipod1

Have looked at the latest logs and it still appears as though the IdentifyDeviceLingoes command does not appear to contain the correct amount of data.
Will see what these later ones show.

Tried your second build with appending log, here you go. About to try the third build with the different serial logging.

Tried your crash-prone build, and could successfully do one run-through of testing before it froze. So that is, plug-in, press button, blink twice, then it usually froze if I tried anything else other than pull the dongle out.

I see it produces TWO logs.....Well, here they are for your debugging pleasure!

Hi Josh,
Sorry its been so long to get back to you.
Rockbox is returning an error that lingo5 is not supported as it has been disabled in the latest git/svn versions.
I have copied a new version of rockbox as http://andyp.dyndns.info/rockbox.ipod2 where I have re-enabled support for lingo5.
Can you see if this performs any better. It should not hang up as I removed the extra logging to seriallog.txt.......

Just tried out the new version you posted. For fun, I tried a brand new build (r31646-120109 for reference), and it seems the codecs etc in it don't work.

Also of note; IT WORKS. Well, it seems to find and pair with the BT headphones, though, since I can't play anything (not sure if version incompatible or what) I can't tell if they actually pass data other than heartbeat type stuff.

Should I be using your specifically modified build? Is it possible to repeat the steps for each new version? If it's reasonable, I can do it myself; I used to add patches (the patch here, in fact) to Rockbox source to make it work.

Thanks for all your help! Will try with your original build. Ah, and here is your log!

Back again. Looks like your original modified build, and your newest rockbox.ipod works! Also, going by build number, this is just before 3.10 was released. Pretty sure there weren't any major changes between then and 3.10 and now, but I'd still like to update it a bit, at least to 3.10 :)

Hi Josh, Have just received a TMR-BT8iP from eBay, just waiting for the headphones so I can see whats happening and what its really doing. Will see if the Sony will pair with my notebook.

I will try to patch my copy of the latest svn source with the iap changes from git.camperquake.de and upload a full build. Might take a few days to get it all done.
Will post when completed.

Hi Josh,
Finally managed to build a version of Rockbox from git (wondered why svn did not seem to update) with the iap bits from camperquake and lingo5 support for BT transmitters.
I have tried it with the Sony TMR-BT8iP and a set of BT headphones SX-910A. Can hear music and can ff/rewind.
The new version is available from http://andyp.dyndns.info/rockbox-full.zip
Do you want to give it a try?

Andy,

Awesome, someone else with my BT adapter! So, is there a write-up somewhere on how to enable the lingo5 stuff? I don't mind getting my hands dirty in the dev environment. And what is in camperquake?

Thanks a lot for you help! The GF is really really happy she can use her BT headphones again! Well, with an updated, better-battery-life version of Rockbox!

To my limited testing, the build you posted works, though I don't recall if I tested the FF/RW buttons. I just backed-up your previous (pre-3.10) build, and put this newer one in.