|
 |
|
11-23-2006, 05:00 PM
|
#706
|
|
Constant Bitrate
Join Date: Sep 2005
Location: Belgium
Posts: 172
|
Quote: Originally Posted by triskel 
After multiple clicking on the LoadCD button, I received (of course) double entries which are ignored. And all of a sudden, sound came. And volume buttonbs reacted as they should.
Hi Triskel,
I also have an Update List HU and I experienced the same problems as you described. I saw some unknown commands coming from the HU when I made my first tests a few months ago. I suspect that the Update List unit sends a few 'still undocumented' commands to the CDC that are maybe not confirmed by the CDC emulator.
I can't remember correctly if the software sends a confirm after each received command, recognized or not. Perhaps this can solve our problem, does the software acknowledges unknown commands? I think Vicne knows the answer.
Unfortunatly I cannot do any tests for the moment, I need to fabricate my PCB first (used a breadboard for testing back then). And I'm already spending all my free time on HQCT software. However this SW is almost reaching a satisfying level so that I can pick up the CDC interface again.
Putput
|
|
|
|
Sponsored links
|
|
Advertisement
|
|
11-24-2006, 10:09 AM
|
#707
|
|
Newbie
Join Date: Nov 2006
Posts: 5
|
Hi PutPut,
Thanks!
I have started to find out a "start-up-Sequence".
until now I have a success rate of about 70%. ( 7 out of 10 times sound, after a specific sequence.) But keyboard is still needed.
Any idea how to automatically get the emu to playing mode immediately?
bedankt/merci/thx
Triskel
__________________
CarPC: Via EPIA MII10000, Hami 8001 (8"), 80Gb, M2 atx, navilock 202U, CES, NCK 5.0 en dat in een rijdend bouillon-blokje van Renault
|
|
|
11-24-2006, 04:47 PM
|
#708
|
|
Variable Bitrate
Join Date: Apr 2005
Location: Belgium
Posts: 325
|
Quote: Originally Posted by triskel 
Secondly I increased debuglevel to 6, didn't touch the stalk and there are no errors, everything seems fine.
Great ! That probably means your adapter is OK.
Quote:
Then I started to play around with the stalk.
Trackchange is now possible, but no sound.
Also cd change (= Load cd) is returning no errors.
But still no sound.
After multiple clicking on the LoadCD button, I received (of course) double entries which are ignored. And all of a sudden, sound came. And volume buttonbs reacted as they should.
I admit I can't understand why spdif isn't activated at first (and why it comes afterwards).
Quote:
I've then put the pc into hibernate mode, turned of the ignition, went to buy some food, returned, started ignition, pc booted, and the sound was immediately there. I could still change the volume with the stalk.
When shutting down, and restarting (not from hiberation)
Well, as you probably know, hibernation is, from a software point of view, an almost uninterrupted workflow. I mean, the software wakes up in the exact state where it was left asleep, and goes on as if nothing had happened.
Quote:
only an "uncontrolled" multiple usage of the cd change function, again results in getting sound.
I am getting more convinced that it really seems a SW issue.
Damn'
Yes, software, or more precisely probably a protocol issue. If you read the whole thread, you probably saw that I only own a Tuner List and no Update List HU, and protocol was reverse-engineered by spying on the Tuner List dialog.
As Putput says it had the same issue with his Update List, and as our softwares were written completely independently, there probably is some command (or sequence of commands) the HU sends and our emulators don't know what to reply, so they don't behave as the HU expects and the HU doesn't activate its SPDIF input.
Quote:
How can I proceed, is there something that I can show you, which could help me to trace the cause of my "random" sound?
First, here are a few tests you could do with the current software :
- try turning the Head Unit on and off multiple times to see if it changes something. Normally, once the HU is turned off, you should get errors on the console saying sent frames are not acknowledged, and once it is turned on, the emulator should restart its "boot emulation" procedure.
- if it doesn't change anything, try pressing and releasing pause multiple times. When I had problems with my adapter, it often restored the sound because each time "pause" is pressed, it causes a mute, and when it's pressed again, it causes a spdif re-activation...
- if you don't get any success, I'm afraid the only way would be to spy the protocol with your HU. The good news I think is that contrary to Putput, you do own a CD Changer, right ? The bad news is that spying means using a different adapter... :-(
a+, mvg, cu ;-)
|
|
|
11-24-2006, 05:05 PM
|
#709
|
|
Variable Bitrate
Join Date: Apr 2005
Location: Belgium
Posts: 325
|
Quote: Originally Posted by Putput 
I saw some unknown commands coming from the HU when I made my first tests a few months ago. I suspect that the Update List unit sends a few 'still undocumented' commands to the CDC that are maybe not confirmed by the CDC emulator.
That's my impression too. If you saw unknown commands, that can obviously be a reason...
Quote:
I can't remember correctly if the software sends a confirm after each received command, recognized or not. Perhaps this can solve our problem, does the software acknowledges unknown commands? I think Vicne knows the answer.
In my version, yes, all frames that are syntactically correct (I mean they comply to the format, with checksum ans such) are acknowledged first, before their contents is evaluated.
Then if the frame is unrecognized, debug should show a line beginning with "Received frame: Type ? ...", provided debug level is 5 or more...
But well, acknowledge is probably not sufficient. If the HU sends a certain frame, it is possible that it waits for a certain answer...
|
|
|
11-24-2006, 05:16 PM
|
#710
|
|
Variable Bitrate
Join Date: Apr 2005
Location: Belgium
Posts: 325
|
Quote: Originally Posted by triskel 
I have started to find out a "start-up-Sequence".
until now I have a success rate of about 70%. ( 7 out of 10 times sound, after a specific sequence.) But keyboard is still needed.
Could you please precisely describe this "70% success procedure" ?
Keyboard is a feature that dates back to the time the emulator did not react to anything. That was the "manual" emulation.
Technically, the emulator is always in a "state" from a list of predefined states. Once it is in a state, it sends certain frames to the HU. Transitions between states are normally made when receiving certain HU frames, but in the early versions when that didn't work, keyboard input was the only way to force change from one state to another.
Quote:
Any idea how to automatically get the emu to playing mode immediately?
Well, it would be possible to simulate the procedure you do manually, but it'd be a dirty hack, and if it's not 100% reliable, I don't think it's worth the effort, considering that it could break the working model with the Tuner List HU...
I'd be much more tempted to find the difference and fix it the clean way...
Kind regards,
|
|
|
11-25-2006, 03:11 AM
|
#711
|
|
Newbie
Join Date: Feb 2006
Location: Italy
Posts: 42
|
Quote: Originally Posted by triskel 
Hi PutPut,
Thanks!
I have started to find out a "start-up-Sequence".
until now I have a success rate of about 70%. ( 7 out of 10 times sound, after a specific sequence.) But keyboard is still needed.
Any idea how to automatically get the emu to playing mode immediately?
bedankt/merci/thx
Triskel
Hi Triskel,
I experienced a similar problem with tuner List and the PIC emulator.
When i press and release PAUSE the sound remain muted for 30-60sec and sometime never restart playing.
The same happened when the HU was switched off/on with the panel button.
I fixed this problem adding the frame TRAY_STS, RANDOM_STS in the boot sequence in response at the first ACK from HU,
before entering in standby status loop, as follow:
BOOT(11h), BOOT_OK(15h), STANDBY(20h), RANDOM_STS(25h), TRAY_STS(26h), RANDOM_STS(25h), STANDBY(20h).
I see this sequence in a old dump of Vicne, when the HU is turned ON.
It may seem that tray_sts/random_sts is the response at HU request HU_STS(93h),
but sending the above sequence inconditionally upon the first ACK is the solution of all problem i had.
Try to apply this patch on the booting frame (or Vicne can help you) so you can test it with your UpdateList.
Good luck!
Ale
|
|
|
11-25-2006, 04:00 PM
|
#712
|
|
Variable Bitrate
Join Date: Apr 2005
Location: Belgium
Posts: 325
|
Quote: Originally Posted by Ale 
I experienced a similar problem with tuner List and the PIC emulator.
Hi, Ale, Putput (it's been a long time, hope you're both alright :-))
Interesting information indeed. Obviously, if the problem occurs with Tuner List, it's not linked to a model difference and i'd be tempted to think of a timing issue then... but...
Quote:
I fixed this problem adding the frame TRAY_STS, RANDOM_STS in the boot sequence in response at the first ACK from HU,
before entering in standby status loop, as follow:
BOOT(11h), BOOT_OK(15h), STANDBY(20h), RANDOM_STS(25h), TRAY_STS(26h), RANDOM_STS(25h), STANDBY(20h).
I see this sequence in a old dump of Vicne, when the HU is turned ON.
It may seem that tray_sts/random_sts is the response at HU request HU_STS(93h), but sending the above sequence inconditionally upon the first ACK is the solution of all problem i had.
Try to apply this patch on the booting frame (or Vicne can help you) so you can test it with your UpdateList.
Well, I'd be glad if it was the explanation, but the java code already sends the above sequence and it does so since the very first version, on sourceforge at least. (See lines 119-121 of EmulatorMachine.java).
Or maybe I didn't understand what you meant...
That's the first time I'm disappointed not to have left a bug in my code... :-(
|
|
|
11-26-2006, 03:03 PM
|
#713
|
|
Newbie
Join Date: Nov 2006
Posts: 5
|
Sequence
Hi Vicne,
thanks supporting, I have now found out an almost 90% satisfying sequence:
That was the start of my message from yesterday.
Today, everything changes again.
I do not succeed anymore to get a sound following my sequence.
Sound is again only possible "by accident" , multiple [LOAD CD], [Track change] and [HU ON/OFF] actions....
damn'
==================
Hi PutPut
Thanks alot for your info, I think I will have to bring my portable hdd into the car to make a copy of my log. Maybe we can compare it one time.
But......I'm, curious about the HQCT though... please don't get too distracted by my issues.. ;-)
==================
Hi Ale,
Thanks, i will try to insert the "patch".
If it works I'll report it here.
If I can..........else, Vicne, could you...... *ashamed to ask*
I have the same issue, that if I finally have sound, sound is not automatically coming back, after i.e. Pause, or a traffic/news message, or a manual switch to Tuner or CD mode, and then back to CDCemu.. But switching to next track ( same as in step 5) helped until now.
Unfortunately, my playing around today left me with another issue.... an empty carbattery, will have to go for a ride now, to recharge.
Thanks and groeten
Triskel
__________________
CarPC: Via EPIA MII10000, Hami 8001 (8"), 80Gb, M2 atx, navilock 202U, CES, NCK 5.0 en dat in een rijdend bouillon-blokje van Renault
Last edited by triskel; 11-27-2006 at 04:59 AM.
|
|
|
11-27-2006, 01:07 PM
|
#714
|
|
Variable Bitrate
Join Date: Apr 2005
Location: Belgium
Posts: 325
|
Quote: Originally Posted by triskel 
thanks supporting, I have now found out an almost 90% satisfying sequence:
That was the start of my message from yesterday.
Today, everything changes again.
I do not succeed anymore to get a sound following my sequence.
Sound is again only possible "by accident" , multiple [LOAD CD], [Track change] and [HU ON/OFF] actions....
You shouldn't have edited your message because it contained very interesting information...
Hopefully, if I remember correctly (*), you wrote something like :
Quote:
You are right, that I do actually have the original CDC. and (typically) that is the cause of my problems with the sound. (my HU can remain in CDC mode, and remains in CDC mode when turning on again.)
Anyway, I'll explain it in my language (jip en janneke taal ;-) )
When HU is turned off in CDC mode, I definitely will have no sound, after booting the pc. The emu remains in STANDBY mode. Switching manually to PLAYING mode, does not bring the immediate success either.
So here are my findings:
1) Before booting the pc, the HU needs to be off (As I have the CDC, I need to be sure the HU is NOT in CDC mode when turning it off)
2) Switch on the PC, TLCDCemu starts, and gets into BOOTING mode,
3) Turn on the HU, in MW or FM, TLCDC switching to STANDBY
4) Now switch to CD 1-6 (CDC mode), and TLCDC switches to PLAYING mode. (display shows TR01 CD1)
5) Now I have to press "Load CD" on the stalk, and then perform one "track change" on the stalk (display first shows LOAD CD, and then switches from TR01 to TR02)
6) now Volume+ and - is available. Thus sound is there too.
If not, I have to switch HU to MW or FM again, and turn the HU off.
This brings the TLCDC to Booting mode, and repeat step 3,4,and 5.
Max repeat until now was 4 times.
It seems that I have to be very very patient..... (but I'm more in control)
Issue when leaving the HU in CDC mode.
When turning on ignition, and HU turns on too, the "real" CDC starts playing its cd's. (perfect!)
But it somehow "disturbs" the booting of the emulator. The display shows all of a sudden [LINK ERROR].
I now can turn of HU and need to repeat 3,4,and 5. several times, some times with, sometimes without success....... strange....
The most interesting thing is the LINK ERROR. Could it be that there is a mistake in the relay circuit ? Could it be that both the emulator and the CDC somehow are connected to the bus at the same time ? Of course, it could explain that randomly, frames are colliding each other resulting in unpredictable results.
My advice would be first to disconnect the original CDC from the adapter, turn the HU off, start the emulator (it should print 3 error messages every second, complaining that there is no reply from the HU), then start the HU.
-- Slightly off topic --
I also wanted to remind you that in your particular case, all this thread can be considered a "very-high-end" solution and there is a much simpler way to get PC sound through your HU.
Indeed, as you own a CD changer, you can do as I did for months : leave the CD changer control wires connected all the time and only switch the SPDIF line between PC and actual CDC, like this.
Well, it means you just built a circuit about 10 times more complicated than needed, but well, I'm sure you enjoyed it :-).
The 3 advantages of the emulator compared to this simple straightforward solution are :
- no need of an actual CD changer (very important, but not at all in your case).
- possibility to control the PC via the HU (looks cool, but only RoadRunner is supported until someones write others plugin - so it doesn't help in your case).
- no 1-second mute everytime the CD changer switches from one CD to another (not a big deal if you ask me)
-- end off topic --
Hope it helps,
Vicne
(*) My memory has nothing to do with that. That's a simple copy/paste of the forum's automatic alert e-mail :-)
|
|
|
11-28-2006, 05:40 PM
|
#715
|
|
Variable Bitrate
Join Date: Feb 2005
Location: Italy/Lecce
Posts: 230
|
HI,
excuse me for little OT, someone know how automatically launch tlcemu after RR run?
Thanks.
|
|
|
11-29-2006, 01:29 PM
|
#716
|
|
Variable Bitrate
Join Date: Apr 2005
Location: Belgium
Posts: 325
|
Quote: Originally Posted by slimmegane 
excuse me for little OT, someone know how automatically launch tlcemu after RR run?
I guess you mean make them run at the same time, not really start tlcdcemu after RR has exited.
Well, what I did was put them both in the Startup menu, but I guess you could write a simple batch file such as
--
start c:\roadrunner\rr.exe
start c:\tlcdcemu\TLCDCEmu.bat
--
Hope it helps.
|
|
|
12-01-2006, 02:54 AM
|
#717
|
|
Newbie
Join Date: Nov 2006
Posts: 5
|
Hi Vicne, putput and ale,
thanks alot for your help!
Yeah I did enjoy it very much to build the interface. (new brooms.... ;-) )
However, I now directly connected the pins 13,14,15,17
and left the 18 & 19 in their relayed position.
Secondly I attached a switch on the power of the interface, I can now immedately switch between cdc and pc.
That's ok.... for the beginning... ;-)
I will think of getting rid of the manual switch, and have it connected via an RS-Modul card, so I can switch from my car-pc software... ( gadget)
I now only have to see, why some songs have a "vibrato".
I think it will have sth to do with either unsupported bitrate of the HU or the VIA driver.
Apart6 from that everything works fine.
Thanks for the support all!!
Groetjes,
Triskel
__________________
CarPC: Via EPIA MII10000, Hami 8001 (8"), 80Gb, M2 atx, navilock 202U, CES, NCK 5.0 en dat in een rijdend bouillon-blokje van Renault
|
|
|
12-01-2006, 04:12 AM
|
#718
|
|
Variable Bitrate
Join Date: Apr 2005
Location: Belgium
Posts: 325
|
Quote: Originally Posted by triskel 
I will think of getting rid of the manual switch, and have it connected via an RS-Modul card, so I can switch from my car-pc software... ( gadget)
Well, you don't need any new hardware : the circuit you have built has such a feature and drives relays according to a signal change on the RS port (RTS pin). That's the upper right part of the circuit. You only need to change the value of RTS by software and there you go...
Quote:
I now only have to see, why some songs have a "vibrato".
I think it will have sth to do with either unsupported bitrate of the HU or the VIA driver.
This could be the driver issue indeed. Here's what's I wrote on my homepage regarding that :
Quote:
Don't forget to update the sound chip driver ! The one delivered on the CD accompanying some Mini-ITX boards is completely outdated and buggy : the SPDIF output is set to 48kHz and all 44.1 kHz sounds (e.g. most mp3s coming from CDs) are thus upsampled with an algorithm which generates noisy artifacts, to be heard on soft piano pieces for example. Up-to-date drivers don't exhibit this behaviour (either because they output SPDIF in 44.1 kHz or because their upsampling algorithm is much better).
What's weird is that the driver proposed on http://www.viatech.com is the same version 3.4b as the one on the CD, released three years ago. The new driver is available only on http://www.viaarena.com > Downloads > Drivers > Windows XP > Audio > VIA Six-TRAC (VT1616 Codec)
Note : the M 10000 has a VT1616 audio chip, but you might have to follow another path if your card uses another chip.
In my case, it made a huge difference.
Good luck.
|
|
|
12-01-2006, 08:53 AM
|
#719
|
|
Newbie
Join Date: Nov 2006
Posts: 2
|
Hi everyone.
I have a problem with my HU and new CD-Changer. I have VDO CDC 601A/T (Digital output with Blue Mini ISO connector and HU RENAULT 22DC259/62T which has digital input.
Blue Mini ISO connector fits well. Although all connections are OK, I cannot play the CD.
CD Changer has digital (SPDIF) output. My HU (Cassetta Player) has digital input. So far everything is OK. Whenever I turn on the player, I see on the display No CD, and then ERR CD. I could not find the problem. The service says that my CD Changer VDO works well with their VDO Player. However with my player an error occurs. I hear that CD is really playing (I mean it is really turning). However the error "ERR CD" on the screen stays. And also I dont hear any sound.
Can anyone help me?
Thanks in advance...
Last edited by erentol; 12-01-2006 at 08:57 AM.
|
|
|
12-07-2006, 12:39 AM
|
#720
|
|
Newbie
Join Date: Dec 2006
Posts: 4
|
Help for PIC Emu, please!
Hello ton all participants in this fantastic thread!
I'm interested in the PIC Emu of hte CDC but I only have a very basic background in electronics. Looking at the schematic published in sourceforge ( http://tlcdcemu.sourceforge.net/pic.html), I have many doubts. I will appreciate your help to resolve them.
I have marked my doubts in red in the attached picture, and labeled them A through F.
Followin are my doubts:
A) "Do not mount C1 (pin 1-3)". I guess it refers to pins 1-3 of MAX232 according to MAX232 datasheet. Should I mount the remaining capacitors (C2, C2, C4 & C5)?
B) Which pin number of the MAX232 should I use here?
C) Which pin number of the MAX232 should I use here?
D) Which pin number of the MAX232 should I use here?
E) Which pin number of the MAX232 should I use here?
F) I don't understand GP23. What does it mean?
G) "MAX232, V+ connect to 12V battery when programmin PIC". Can I use a stabilized power supply (with and 78L12 voltage regulator) instead of a 12V battery?
Thanks in advance,
azarazaga
|
|
|
|
|
|
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:57 AM.
| |