max202 with only some ceramic caps (0.1uF)?it's the same?Originally Posted by Vicne
For those who have too much free time, here are a few remaining questions :
- a mystery remains about the 10th byte of the "PLAYING" frame. E.g. in the following frame :
3D 8B 0B 47 03 01 00 11 34 13 00 00 02 00 CC ?
Track=3, CD time=11m34s, Track time=0m02s, but what does the "13" mean ?
If it has to be consistant with the remaining information, then we *must* generate the correct value !
- what is needed to make the disc number change on the display ? Do we have to simulate a complete cd change (which probably mutes the sound ?)
- do we have to respond in a particular way if we receive a button press or can we just acknowledge it
And a few more tests I have to do :
- what if some places are empty in the tray ? What happens if I press on this CD number ? If nothing gets sent, it means the CDC has to declare the available CDs to the HU beforehand and the HU only transmit commands if they are "allowed". We must then analyse what exact frames are needed for such a declaration, so that all buttons are active...
- let the track change automatically at the end of the previous one and see what message gets sent
- let the CD change automatically at the end of the previous one and see what message gets sent
- let the track change automatically in random mode at the end of the previous one and see what message gets sent
- let the CD change automatically in random mode (does it do that ?) at the end of the previous one and see what message gets sent
max202 with only some ceramic caps (0.1uF)?it's the same?Originally Posted by Vicne
Err... maybe I have the answer actually :-).Originally Posted by Vicne
I took a sample of all values I had for this byte in one of the dumps and here are the different values (sorted, duplicates removed):
00 07 11 13 15 17 19 20 22 29 34 36 37 40 64 67 70 71
- numbers look random (they are not sorted in the actual logs)
- only numbers, no letters (hex), so strong probability of BCD
- maximum observed value : 71. Nothing in the range 72-99
- this byte is always 00 for the first track of each CD
And here's my explanation :
CDs are divided into elementary chunks referred to as sectors (or more frequently frames, but let's not use that term here to avoid confusion with frames of the protocol), each sector being 2352 bytes for CD audio (see wikipedia). Each second of sound corresponds to 75 sectors (44100 samples/sec x 2 (stereo) x 2 bytes (16bits) / 2352 bytes/sector = 75 sectors/second).
So my guess is that the time is not stored as hour:minute:second (BCD) as we thought but as hour:minute:second:sector (BCD) :
- As the CDC sends one frame every second, this "decimal" part is constant for the whole track (1:05:12:62 + 0:0:1:0 = 1:05:13:62)
- As the first track begins at 0:0:0:0, this "decimal" part is always 0 for the first track
- As tracks have arbitrary lengths (with decimal part), if the first track's length is 0:3:35:22, when we skip to the second track, it starts playing at 0:3:35:22 (cd time) or 0:0:0:0 (track time), and one second later, we get 0:3:36:22 (cd time) or 0:0:1:0 (track time)
- That would also explains the last 00h (14th byte) of the frame
So here we go for a potential decoding of the following PLAYING frame :
3D 8B 0B 47 03 01 00 11 34 13 00 00 02 00 CC
3D = header
8B = id
0B = data length
47 = payload_type (PLAYING)
03 = track number
01 = ?
00:11:34:13 = cd time (BCD encoded h:m:s:f)
00:00:02:00 = track time (BCD encoded h:m:s:f)
CC = frame control sequence
So that would leave us with only one unknown byte for this frame, but as it has the fixed value of "01h" in all frames I have analysed, I guess we can safely say it is constant...
Well, not the same, but after a look at the datasheet, I think you can use it as a drop in replacement indeed. The 3232 I used is of a newer generation (min power supply of 3.3V, higher data rate) but you don't need that if you use a 5V power supply (I'm using a 4.5V battery).Originally Posted by peppuz79
Although, maybe you should check the input thresholds to make sure they are siimilar.
Beware : on their typical operating circuit, they use some 6.3V caps, so if you have 6.3V rated caps too, be careful that wiring of pin 2 is different from the one in my schema.
Oh, yes, I also followed Ale's advice and put a 10uF capacitor in parallel with the 0.1uF one at the chip's power supply to minimize noise.
Yes, but at what level are you setting the threshold? Going from 232 to the HU is easy (we have the rs232 standard as a reference, so we can set it at 3v) but we don't know what value to use for the HU->rs232 transition. I don't have a (good enough) tester at home, but connecting directly the HU to the serial port I had the receiver led constantly lit, so either my rs232 adapter is more sensible (though it has worked well with all kinds of rs232 devices) or the level is already >3v.Originally Posted by Vicne
I'm also thinking that maybe the communication is based on current and not on voltage, the fact that you can capture a voltage is simply because you have closed the circuit with the standard cd changer, and this could also explain the differences in levels observerd by you and mox.
Edit: my adapter uses an hin213eca as an rs232 level translator, and that detects a low to high transition at 1.7v and gives (typical) +-9v of output.
This is certainly a possibility, I know that a few years ago in industrial environments (with lots of noise) current (Current Loop) was more frequently used because its less sensitive to noise compared to serial (RS232). These days its mostly RS422/485 with balanced differential drivers.Originally Posted by pippolippi
But then both current loop and rs422 would need 4 wires, so I was probably wrongOriginally Posted by Putput
Are we sure that HU pin 13 is TX and not RX? RX with a sort of pullup giving the strange level of 3V on the 5K input impedance of RS232?Originally Posted by pippolippi
Our measurement is always done with CDC connected...
If the HU comunication is based on current, not necessarily a industrial standard 20mA current loop, but an open collector interface for TX and a current sense at RX, i suggest the circuit in the attachments...Originally Posted by pippolippi
What do you think about?
Not sure what you mean in the last sentence.Originally Posted by pippolippi
Based on the specification, any input voltage between -3V and +3V is in the "no man's land", an undefined region. It means that a device that would consider:
- an input voltage between -3 and -25 as a logical 1
- an input voltage between +3 and +25 as a logical 0
- and anything in between as "not enough to toggle the output" (hysteresis of 6V)
... would be perfectly RS232-compliant in the strict sense. If this is the case of your adapter, well, it's a good adapter but it cannot be used as is.
That's be a possibility, but AFAIK, current loops are not used that much nowadays, mainly in hi-fi. Moreover, CristianC did decode bytes without anything attached to his HU.I'm also thinking that maybe the communication is based on current and not on voltage, the fact that you can capture a voltage is simply
because you have closed the circuit with the standard cd changer
To be sure, you could put a resistor to terminate the wire and measure the voltage if you want...
Regarding this difference, I could confirm that the oscilloscope introduced an offset when changing scale. I connected the probes together and adjusted the "signal" on the baseline at 10mV/div, then switched scale and the signal was around 2V when I reached to the 5V/div scale.and this could also explain the differences in levels observerd by you and mox.
I'm really sorry but that's the only 'scope I could find... Maybe I should buy one, one day :-)...
Low to high, you mean logical 0 (positive voltage) to logical 1 (negative voltage. In that case, it should work indeed, and for sure with a 10K/10K resistor. Can't you test your receiver by feeding it a variable voltage (100K potentiometer on a 9V battery) and see when the led toggles ?Edit: my adapter uses an hin213eca as an rs232 level translator, and that detects a low to high transition at 1.7v
It seems "rather good", but I have no idea if it's sufficient...and gives (typical) +-9v of output.
Finally, to answer your question... well, that's the goal of the variable resistors : adjusting till the led flashes :-)but at what level are you setting the threshold?
*Very interesting remark*. Ale is definitely the best to spot inverted things.Originally Posted by Ale
I just followed the wires backwards with paper and pen in hand and he's right. Bear with me :
- We are reading PLAYING frames coming from CDC on COM1. COM1 is linked with a black wire to pin7 of the MAX, this T2OUT comes from T2IN, pin 10, which is bridged to pin 9, R2OUT coming from R2IN, pin 8. This pin is linked via a 10K resistor to another black wire which comes from connector pin 14 labeled UART- or UART RxD.
- We are reading command frames coming from HU on COM2. COM2 is linked with a red wire to pin 14 of the MAX, this T1OUT comes from T1IN, pin 11, which is bridged to pin 12, R1OUT coming from R1IN, pin13. This pin is linked via a 10K resistor to another red wire which comes from connector pin 13 labeled UART+ or UART TxD.
You have to link pin 3 (Transmit Data) of the serial port to pin 14 (RxD) of the blue connector to send PLAYING frames.
You have to link pin 2 (Receive Data) of the serial port to pin 13 (TxD) of the blue connector to read HU commands.