|
 |
|
03-14-2006, 04:45 AM
|
#406
|
|
Variable Bitrate
Join Date: Apr 2005
Location: Belgium
Posts: 325
|
Quote: Originally Posted by pippolippi
Though I didn't perform extensive testing, I didn't notice any problem upon cd change. But then I'm just sending the "I'm playing" frame, I don't try to simulate the cd changer real sequence.
If you don't forward the "PLAY" command to Winamp, all is well indeed.
The problem is only that the HU issues a "PLAY" command after CD change, and if it's already playing, Winamp interprets a PLAY as a PAUSE 
I asked Guino if he could implement a "FORCEPLAY" command. That would be much cleaner.
Edit : Guino said it was already implemented of course. It's the RESUME command.
And for the "hung HU", I'll have to do more tests, but you're right "simpler is better" and maybe I'll remove a few messages in the end
Last edited by Vicne; 03-21-2006 at 05:58 PM.
|
|
|
|
Sponsored links
|
|
Advertisement
|
|
03-14-2006, 05:45 AM
|
#407
|
|
Constant Bitrate
Join Date: Feb 2006
Posts: 113
|
Quote: Originally Posted by Vicne
The problem is only that the HU issues a "PLAY" command after CD change
Not here (since I don't send the "correct" reply from the cdc).
|
|
|
03-14-2006, 05:54 AM
|
#408
|
|
Variable Bitrate
Join Date: Apr 2005
Location: Belgium
Posts: 325
|
Quote: Originally Posted by pippolippi
Not here (since I don't send the "correct" reply from the cdc).
I see. But still, you acknowledge it, right ?
And can you confirm it mutes the SPDIF in anyway ? If not, it would be a huge plus...
|
|
|
03-14-2006, 06:10 AM
|
#409
|
|
Constant Bitrate
Join Date: Feb 2006
Posts: 113
|
Quote: Originally Posted by Vicne
I see. But still, you acknowledge it, right ?
Yes, I send the customary C5, but then I go on sending the "I'm playing" frame as if nothing happened (well, actually I reset the track number to 1, but that's another issue).
Quote:
And can you confirm it mutes the SPDIF in anyway ? If not, it would be a huge plus...
I cannot, I still don't have an spdif adapter.
|
|
|
03-14-2006, 06:18 AM
|
#410
|
|
Variable Bitrate
Join Date: Apr 2005
Location: Belgium
Posts: 325
|
Quote: Originally Posted by pippolippi
I cannot, I still don't have an spdif adapter.
Ow, yes.
Sorry, I forgot...
|
|
|
03-14-2006, 07:21 AM
|
#411
|
|
Constant Bitrate
Join Date: Feb 2006
Posts: 113
|
Quote: Originally Posted by Vicne
Ow, yes.
Sorry, I forgot...
Yes, but you can
|
|
|
03-14-2006, 12:41 PM
|
#412
|
|
Constant Bitrate
Join Date: Feb 2006
Posts: 113
|
Quote: Originally Posted by pippolippi
Well, that wasn't a good idea, since not only it doesn't work, but while rewiring the circuit to revert it the previous, working, one, I made a mistake and blew the transistor. I hope it's just the transistor and not the hu 
Fortunately it was just the transistor
Everything is working fine now.
The only problem now (didn't see it before) is that sometimes either I'm not acknowledging fast enough or I'm too happily flushing the input buffer when I shouldn't, so I get the same message twice, and if I push keys too fast I'll get a link error (an interesting detail is that when I restart the program the link error clears and I get the queued up commands, so the hu has a fifo to send commands until they're acknowedged, and the link error is probably caused by this fifo filling-up, it was happily acknowledging my continuous "I'm playing" packet though).
Anyway, now that I have a working serial adapter and a working interface, I'll go and seek an spdif adapter to go on hacking. Probably not this week (I'm really busy).
|
|
|
03-14-2006, 02:04 PM
|
#413
|
|
Variable Bitrate
Join Date: Apr 2005
Location: Belgium
Posts: 325
|
Quote: Originally Posted by pippolippi
Fortunately it was just the transistor
Glad to hear that.
Quote:
The only problem now (didn't see it before) is that sometimes either I'm not acknowledging fast enough or I'm too happily flushing the input buffer when I shouldn't, so I get the same message twice
Oh I'm "happy" to hear that, because I see that too since I'm using the RxTx library and I didn't know if it was a bug in the library (sending two calls for the same data) or a performance problem. I've optimized as far as I could (*) - well it's still Java, no assembly :-) - but it still happens. I worked around that by storing the ID of the last processed frame and discarding frames received twice...
(*) plugins are now called asynchronously so multiple frames can be processed by plugins in parallel while the program continues listening to HU commands...
Quote:
and if I push keys too fast I'll get a link error (an interesting detail is that when I restart the program the link error clears and I get the queued up commands, so the hu has a fifo to send commands until they're acknowedged, and the link error is probably caused by this fifo filling-up
I never had that until now, but that still can happen, maybe I didn't saturate the HU enough :-)...
Quote:
it was happily acknowledging my continuous "I'm playing" packet though).
Anyway, now that I have a working serial adapter and a working interface, I'll go and seek an spdif adapter to go on hacking. Probably not this week (I'm really busy)
OK let us know how it goes...
|
|
|
03-14-2006, 02:43 PM
|
#414
|
|
Constant Bitrate
Join Date: Feb 2006
Posts: 113
|
Quote: Originally Posted by Vicne
Glad to hear that.
Oh I'm "happy" to hear that, because I see that too since I'm using the RxTx library and I didn't know if it was a bug in the library (sending two calls for the same data) or a performance problem. I've optimized as far as I could (*) - well it's still Java, no assembly :-) - but it still happens.
I don't think it's a performance problem (it's just 9600bps), but because in the last revision I'm discarding the input buffer each time I start a transmission, and, since I also lowered the delay between transmissions from 0.5s to 0.2s (just to push the envelope, so to speak), this creates more probabilities to lose a packet.
Quote:
I worked around that by storing the ID of the last processed frame and discarding frames received twice...
I don't consider it a workaround but good practice, after all the sequence number is there for a reason.
Quote:
I never had that until now, but that still can happen, maybe I didn't saturate the HU enough :-)...
Yes today has been the first time I saw this. Probably related to the same flushInput() where it doesn't belong. OTOH is interesting to know (that the HU uses a send fifo I mean).
Quote:
OK let us know how it goes...
Sure.
|
|
|
03-15-2006, 05:06 AM
|
#415
|
|
Variable Bitrate
Join Date: Apr 2005
Location: Belgium
Posts: 325
|
Pippolippi,
Just a question about your opto-coupled circuit :
Is the transistor on the HU Tx only used as an inverter, or did you put it there to bufferize the input. In other words, do you think is it dangerous to power the opto-coupler directly (through a resistor) from the HU Tx ?
If it's just an inversion problem, I think we can get the same effect by inverting on the other side, connecting the PC's Rx to pin4 and placing the resistor as a pull down between pin 4 and DTR instead of a pull up between pin5 and RTS...
All this to pursue the goal "simpler is better" of course :-)
|
|
|
03-15-2006, 06:33 AM
|
#416
|
|
Constant Bitrate
Join Date: Feb 2006
Posts: 113
|
Quote: Originally Posted by Vicne
Pippolippi,
Just a question about your opto-coupled circuit :
Is the transistor on the HU Tx only used as an inverter, or did you put it there to bufferize the input. In other words, do you think is it dangerous to power the opto-coupler directly (through a resistor) from the HU Tx ?
It's not dangerous but it doesn't work.
In my first try I didn't use any transistor at all and it didn't work. Since I don't know which direction wasn't working (it did work in my loopback test outside the car), I added a transistor in both directions. When I saw that it worked, I tried to remove the transitor you mention (i.e. using the original circuit for the HU->TX connection, with the resistor and output taken from the collector instead of from the emitter) since I thought it wasn't necessary but I coulnd't establish a connection. I rewired the circuit on the breadboard in a hurry and that's when I blew the transistor 
Now I won't touch the circuit anymore: I just removed the optocoupler that detects the HU on (I don't need it anymore) and lowered the remaining 3k3 pull-up resistor (on the right side) to 1650 (actually put the two 3k3 resistors in parallel): it works with 3k3 but the levels are better with a lower resistor (but I wouldn't lower it if it still had to supply two optocouplers instead of one).
|
|
|
03-15-2006, 11:11 AM
|
#417
|
|
Newbie
Join Date: Mar 2006
Posts: 23
|
Any Idea about CDText and Ipod interface ?
Hi,
I'm sensing this is the forum I've been waiting for since I got this twingo car two years ago. I want to plug an Ipod and I'm sure I can use your info to do so, just not sure how yet 
But Ipods have more information to give to the HU, like titles, and I suspect CD changers that support CDText also give more info than just CD index and title, do you have any idea wether it is possible to send the HU a track title ?
Also, do you have any idea about cheap SPDIF converters ?
Thanks a lot for all the info in any case, I would never plug an Ipod without being able to mute it from the handy remote the HU comes with !
|
|
|
03-15-2006, 11:39 AM
|
#418
|
|
Variable Bitrate
Join Date: Apr 2005
Location: Belgium
Posts: 325
|
Quote: Originally Posted by FroMage
Hi,
I'm sensing this is the forum I've been waiting for since I got this twingo car two years ago. I want to plug an Ipod and I'm sure I can use your info to do so, just not sure how yet 
But Ipods have more information to give to the HU, like titles, and I suspect CD changers that support CDText also give more info than just CD index and title, do you have any idea wether it is possible to send the HU a track title ?
Also, do you have any idea about cheap SPDIF converters ?
Thanks a lot for all the info in any case, I would never plug an Ipod without being able to mute it from the handy remote the HU comes with !
Well, in brief, unfortunately, the answers are "not yet", "no" and "sort of" :-)
- Not yet : currently, the only implementations we achieved imply the use of a PC to send serial commands. The hardware part currently is a simple pass-through with level conversion. Several people here have indicated interest in developing a pic-based version of the emulator though, which means a PC wouldn't be needed anymore.
- No : Nothing more than "track number / cd number" can be displayed as far as we know. This seems to be a limitation of the head unit, because even with CDText-capable CD changers or mp3-compatible CD changers, nothing more than track #/cd # is displayed... (Well, we could bypass the head unit and try to connect directly to the display, but this is a completely different project)
- Sort of : AFAIK (but I might be wrong) Analog to SPDIF converters can be found easily, but they are often targeted at pros, and are neither cheap not easy to power and connect in the dashboard, so not really suitable here...
Well, in brief, you have 3 choices :
- you sell you Ipod and go the carPC way :-) Via Epia motherboards have both the Serial port and SPDIF out...
- you are very good in electronics and want to design and build a hardware interface(*)
- you are looking for the easy solution : an existing Adapter such as the one from Connects2. It should be checked if it forwards commands to the Ipod though...
Hope this helps
Vicne.
(*) The hardware part involves the PIC emulator, the SPDIF converter (info can be found in the description of the Connects2 here )and (as it seems to be your desire) conversion of HU and stalk commands to IPod ones.
Last edited by Vicne; 03-15-2006 at 11:41 AM.
|
|
|
03-16-2006, 03:50 AM
|
#419
|
|
Newbie
Join Date: Feb 2006
Posts: 28
|
Quote: Originally Posted by Vicne
- Not yet : currently, the only implementations we achieved imply the use of a PC to send serial commands. The hardware part currently is a simple pass-through with level conversion. Several people here have indicated interest in developing a pic-based version of the emulator though, which means a PC wouldn't be needed anymore.
You have reason I not have pubblished my work, but I have implemented a dummy interface with 16f84 (with only max232) that enable the CDC emulator and after the success I have asked my self now?the SPDIF audio?then I'm searching
new way to encoding/converting/emulating the SPDIF audio, for example using old standalone mp3 player but for now no good news.
Also work with Yampp3/USB ( www.yampp.com) but the same problem SPDIF Source?
Quote: Originally Posted by Vicne
changers, nothing more than track #/cd # is displayed... (Well, we could bypass the head unit and try to connect directly to the display, but this is a completely different project)
I'm interessed too.
New thread discussion?
Anyway other solution in my mind is the follow (any suggestions are aprreciated):
MP3 Player based on:
ATMEL128L,MAX3587S(mp3 decoder with spdif output), USB Controller (MASTER mode ) and some LCD (like Nokia color/grayscale).
The decoder that I'm using now doesn't support the Digital output (VS10XX more info www.vlsi.fi).
So you can put your usb key in the mp3 player and listen the music in a car.
best regards
pep
Regard
|
|
|
03-16-2006, 03:56 AM
|
#420
|
|
Newbie
Join Date: Feb 2006
Posts: 28
|
dummy question...
one question:
What do you think about a frame that when sent to HU switch,it changes the audio input signal from the SPDIF to Analog?
pep
|
|
|
|
|
|
Advertisement
|
Sponsored links
|
| Thread Tools |
|
|
| Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -5. The time now is 05:00 AM.
| |