neljoe
Moderator
Como alguns sabem, tenho um RNS-E na B5 (e o MOBYS no 8L). Sabia em antemão que a única coisa que não iria funcionar correctamente era o Relógio e por sua vez o ETA, mas resolvi seguir em frente e "depois via-se". Há um user (BJarne@naviplus.com) que em tempos criou/vendeu uma "caixinha mágica" que resolveu este problema só que agora não irá fazer mais. Troquei vários e-mails com ele e conseguir sacar algum info que poderá ajudar na solução deste problema por algum "crânio" aqui no nosso Forum ("YES WE CAN"! )
- o quadrante manda as horas para o RNS-E. Elas entram bem porque no Eng. Mode vê-se... mas este não as mostra correctamente no "display normal"... e aparecem mal da seguinte forma:
Li este Tópico de 24 páginas onde foi tudo discutido e deu origem á solução do problema:
http://audiforum.us/rns-e/1301-rns-e-b5-c5-clock-problem-thread.html
Para não terem que ler tudo, retirei a seguinte info que julgo ser importante:
E neste Tópico http://audiforum.us/multimedia/3145-cangate.html retirei apenas o seguinte:
Muito básicamente, a solução é criar uma caixinha que ligará nos fios entre o Quadrante e o RNS-E. Pelo muito pouco que entendi, a função da caixinha é filtrar a info das horas e traduzi-la de forma a que o RNS-E a entenda e não faça aquilo dos "+6 minutos, horas" antes de entrar no RNS-E.
Haverá users aqui no Forum que percebem disto???
Veremos...
8)
- o quadrante manda as horas para o RNS-E. Elas entram bem porque no Eng. Mode vê-se... mas este não as mostra correctamente no "display normal"... e aparecem mal da seguinte forma:
the minute field will be correct every hour from 00 to 16, and then it will be off by
6,12 or 18 minutes.
the hour field will be correct until 16:00 and then it will be off by 6 hours.
Since the ETA is compute from this time, it will be off by the same amounts.
Li este Tópico de 24 páginas onde foi tudo discutido e deu origem á solução do problema:
http://audiforum.us/rns-e/1301-rns-e-b5-c5-clock-problem-thread.html
Para não terem que ler tudo, retirei a seguinte info que julgo ser importante:
In principle, the task is pretty simple. The CAN bus is a message based bus, where each node sends their specific message with a message identifier. Every other node on the bus recieves the message and decides if it is relevant to this node, and if so it is processed.
So the clock in the cluster is sending clock messages, which the RNS-E receives and processes. If.... we can decode the message and figure out the incompatibility and fix it before we send the message on. I am expecting to see some kind of bit reversal between what the clock sends and what the RNS-E expects. The jumping in fixed intervals (six minutes, hours, or days) usually is a result of bit reversals. But we will see.
If you are interested in more technical CAN information, google for "CAN 2.0B" and the spec shows up as the third or fourth entry.
I have been puzzling over what the offset in increments of 6 could mean, because I was sure there was a clue there. Yesterday it dawned on me that this is the difference between coding a digit in binary vs BCD, i.e. binary uses all 16 values of a 4-bit field, while BCD only uses 10 values, before they roll over the more significant digit.
I have been observing the error, and found the following for both the hour and minute fields:
Cluster __ RNS-E __ error
0 - 15 ___ 0 - 15 ___ 0
16-31 ___ 10-25 ___ -6
32-47 ___ 20-35 ___ -12
48-59 ___ 30-41 ___ -18
This is perfectly consistent with the cluster coding the data in binary, but the RNS-E expecting it in BCD. This also shows why it seems to be a lot closer in the morning than in the afternoon, since the hour field is correct untill 3 PM, and the minute field is correct in the first part of each hour.
This became a rather long post just to say, that I am convinced, that it will be possible to correct the clock message in a gateway. I should be able to say conclusively in a couple of weeks, if someones else does not confirm it before.
This does not explain why the cluster time in the engineering mode is correct, but I am not worried about that. I just want my display clock and ETA correct.
I have been doing a lot of tests of my CANGate prototype today, and the results prove that my theory about binary vs BCD must be correct. When I convert the clock messages from the cluster from binary to BCD before sending them on to the RNS-E, I get the correct time on the display, and it also shows the correct ETA.
As I expected, when you go into engineering mode and look at the cluster time, it now shows an incorrect time. Clearly the RNS-E is confused about the time in different places, but at least it is now correct, where it matters.
...the device draws about 50 mA operating, so I need to implement a sleep mode to make that significantly lower, when the car is off.
I was somewhat surprised to see the amount of traffic on the bus, when there were no apparent changes going on. This makes it more complicated to figure out what messages do what, and there are of course no public information available. It is mostly trial and error.
I am trying to make it as small as possible, probably about 2.5" x 2.5" x .75".
Currently the board has a MOLEX 10-pin Microfit connector, and I will stay with that unless someone sees a problem or has a better idea. Mind you, it has to be readily available. I will supply the mating connector with six 3 foot #22 AWG wires, as follows:
+12V unswitched
GND
CAN-H to instrument cluster
CAN-L to instrument cluster
CAN-H to RNSE and other aux (like BT)
CAN-L to RNSE and other aux (like BT)
The unit comes with a pigtail of wires as follows (each about 2 ft long):
BLK Pin 1 GND
RED Pin 6 Unswitched +12V
YEL Pin 9 CAN-H from cluster
GRN Pin 4 CAN-L from cluster
WHT Pin 10 Can-H from RNSE
OR Pin 5 CAN-L from RNSE
I picked up all the connections from my RNSE adapter. You of course have to cut the CAN-H and CAN-L wires to insert this box in the bus.
Let me just add, that the CANGate device will go into a low power mode after a certain time of no CAN bus activity. I can not give you the final numbers yet, as I am still fine tuning the low power mode and wake-up.
Since this device translate messages between the cluster and the RNSE, it is inserted in the CAN bus between them. This means that the adapter has to be modified, specifically the CAN bus wires have to be cut, and the CANGate inserted in series.
E neste Tópico http://audiforum.us/multimedia/3145-cangate.html retirei apenas o seguinte:
CANGate has an 8-pin connector for a special serial cable, which is used for updating the firmware, and for communicating with the firmware.
The serial cable has two push buttons on it: a black one is for resetting the device, and a red one is for putting the box in programming mode, if held during a reset. Putting the box in programming mode only means that it will communicate with the download program on the PC, no programming will happen until you tell it to download from the PC.
The serial cable is also used to communicate with the program in the CANGate, it needs to be connected to a PC serial port running at 115200 baud, 8 bits, no parity, 1 stop bit (pretty standard other than the baud rate). I communicate with it from a terminal program (Tera Term Pro).
The terminal commands are:
r - reboot the device
o - print options
o XXXXXXX - set options. Must be repeated for each option, which is changed, due to timing of the internal EEPROM.
n - print software version and serial number
dl hh - set low threshold for going into night mode
dh hh - set high threshold for going into day mode
p0 - show pushbutton ON message
p1 - show pushbutton OFF message
p0 SID dlc d0 d1 d2 d3 d4 d5 d6 d7 - set ON message. again must be repeated for each field changed
p1 SID dlc d0 d1 d2 d3 d4 d5 d6 d7 - set OFF message. again must be repeated for each field changed
f - clear message filter
f SID - set message filter. Will only log messages with this SID, this does NOT affect CAN traffic, only logging
b - clear blocks
b0 SID - set message block 0. All messages with this SID will be blocked from traversing the bridge
b1 SID - set message block 1. All messages with this SID will be blocked from traversing the bridge
tc SID dlc d0 d1 d2 d3 d4 d5 d6 d7 - send message to cluster side
tr SID dlc d0 d1 d2 d3 d4 d5 d6 d7 - send message to RNS-E side
tt - repeat last send with the last data byte incremented by one
l - turn logging off
lc - log messages from cluster side
lr - log messages from RNS-E
la - log all messages from either side
This is the command I use for logging traffic. I let TTPRO save the log to a file while it is acquiring data.
If you remove the lid of the box, you will see two green LEDs, they indicate the state of the box as
follows:
Both blinking: it is processing CAN messages
One or the other off: there is no CAN traffic on either bus (it wil go into the low power mode after 10 sec)
Both off: it is in low power mode (consumming less than 5 mA)
Both on: it is in programming mode ready to receive an update.
Muito básicamente, a solução é criar uma caixinha que ligará nos fios entre o Quadrante e o RNS-E. Pelo muito pouco que entendi, a função da caixinha é filtrar a info das horas e traduzi-la de forma a que o RNS-E a entenda e não faça aquilo dos "+6 minutos, horas" antes de entrar no RNS-E.
Haverá users aqui no Forum que percebem disto???
Veremos...
8)