Zegarek z B7 w B6 LIN 2.0 - video

[mysiek10]

Witam

Chcę założyć zegarek analogowy w B6 ale bez wymiany gateway-a itd, wykombinowałem że albo zrobię przejściówkę CAN->LIN albo odczytam czas z CAN i zrobię własne sterowanie zegarka.

Wydaje mi się że przejściówka będzie prostszym rozwiązaniem. Udało mi się już odczytywać prawidłowo czas i jasność podświetlenia z CAN, ale ponieważ nie posiadam gateway-a z LIN który wysyła informacje do zegara po LIN nie mogę odczytać źródłowych danych do zegarka po LIN.

I teraz pytanie, czy ktoś wie pod jakim adresem w których bajtach i w jakiej formie (kodowane tak jak po CAN, czy "czysta" godzina) jest to wysyłane po LIN-ie.

 

Mysiek10

[mysiek10]

Czyżby nikt nie wiedział albo tego nie robił ??

Z braku informacji zrobiłem własne sterowanie zegarkiem na Arduino po CAN, efekt działania poniżej. Jeśli ktoś by posiadał info na temat LIN bardzo proszę o pomoc.

Wolałbym zrobić przejściówkę zamiast całego modułu sterowania zegarkiem

 

Edytowane 22 Października 2017 przez mysiek10

[nTomek]

No fajnie sobie to wymyśliłeś, ale tu na forum bardzo mało jest takich oryginalnych modyfikacji.

Ale skoro już rozpracowałeś temat od strony CAN'a to postaram się "podsłuchać" zegarek w moim B7 - może na podstawie logów da się rozkminić protokół na magistrali LIN.

Skoro jeszcze nikt tego nie robił to ty będziesz pierwszy. Będziemy w kontakcie.

Pozdrawiam.

[mysiek10]

OKI, czekam na jakieś info

[nTomek]

Cześć,

Po lekkich perypetiach udało mi się dokopać do zegarka i podsłuchać magistralę.

Na wstępie kilka szczegółów technicznych.

Magistrala zegarkowa LIN pracuje w standardzie 2.0. W czasie gdy zapłon jest włączony, Gateway "naparza" do zegarka cały czas. Po wyłączeniu zapłonu magistrala cichnie i budzi się tylko na chwilę gdy wystąpi jakiś "event" np. włączenie świateł postojowych, otwarcie drzwi itp.

Po wstępnej analizie protokołu doszedłem, że informację o aktualnym czasie zawiera ramka z o numerze F5, natomiast info o podświetleniu (Terminal 58d) jest w ramce 73.

Przykładowa ramka F5:

B 55 F5 00 50 A3 F9 FF FF FF FF 1C gdzie:

B - break
55 - sync
F5 - id
00 50 A3 F9 FF FF FF FF - data [1..8]
1C - checksum

Czas jest zapisany na bajtach 2..4 (sekundy - 6 bitów, minuty - 6 bitów, godziny - 5 bitów) które należy czytać od końca (little endian), czyli:

F9 A3 50 zamieniamy na bity: 1111 1001 1010 0011 0101 0000 i dalej:

1111 1 - jakieś wypełnienie - bez znaczenia
001 101 - sekundy - zamieniając na liczbę dziesiętną mamy 13
0 0011 0 - minuty - 6
101 00  - godziny - 20
00 - ogonek

 

Przykładowa ramka 73:

B 55 73 62 C2 8C 2B FF FF FF FF AF

Tu się nie będę już rozpisywał - bajt 1 (62) zawiera wartość podświetlenia wyrażoną w % (w tym przykładzie to 98%). Czasami pojawia się tam wartość FE a podświetlenie jest wyłączone - nie wiem co to jest bo chyba nie -2 a może?

Co do reszty bajtów to póki co nie mam pojęcia co znaczą, ale też się zmieniają w czasie.

Załączam logi:

 

LIN_log_201710282002032195_3_01_na_20_02.rtf

LIN_log_201710281949377709_zmiania_ilu_od_MIN_do_MAX.rtf

[mysiek10]

Wow, super profesjonalna robota

Biorę się w takim razie do roboty, wielkie dzięki.

 

Mysiek10

[nTomek]

Analizy protokołu ciąg dalszy...

Ramka 73 też zawiera info o czasie zapisane w ten sam sposób jak w ramce F5 tylko z innym przesunięciem bitowym, a więc...

Dla przykładowej ramki: B 55 73 62 C2 8C 2B FF FF FF FF AF czytamy bajty 2..4 a raczej 4..2:
2B 8C C2, zamieniając na bity mamy: 0010 1011 1000 1100 1100 0010 i dalej:

0 - jakieś zero
010 101 - sekundy - 21
1 1000 1 - minuty - 49
100 11  - godziny - 19
00 0010 - coś co zależy od statusu zapłonu/oświetlenia:

Licząc od prawej (LSB) do lewej (MSB) - bity 0..5:

0 - status zapłonu (1 gdy jest zapłon)
1 - podświetlenie aktywne (przynajmniej światła pozycyjne)
2 - zawsze 0
3 - przełącznik świateł w pozycji AUTO

[mysiek10]

Trochę opóźniły się prace nad projektem z powodu braku czasu, ale .....

Temat ogarnięty, na razie wersja alfa, bo jak widać na poniższym wideo wszystko na pająku, ale to nie ważne, ważne że działa

Jakość filmików słaba ale widać że czas i podświetlenia działa prawidłowo, pozostaje uporządkować kod, zrobić pcb i gotowe.

Dziękuję serdecznie za pomoc, szczególnie dwóm Tomkom

Film 1

 

Film 2

 

 

Edytowane 25 Listopada 2017 przez mysiek10

[Albercik]

Heja,

 

Udało mi się narysować płytkę pod gotowe rozwiązanie. Po wykonaniu - będzie faza beta-testów.

 

Pytanie do Was - czy ktoś tu na forum był by takim urządzeniem zainteresowany? Bo szczerze mówiąc - jeśli beta-testy zakończą się pomyślnie, a będzie zapotrzebowanie na trzy sztuki to raczej nie będzie się opłacało uruchamiać większej produkcji. Jeśli będzie więcej chętnych - wtedy wyprodukujemy porządne urządzenia w ładnych pudełkach

[radekrp90]

Pytanie tylko tu na forum to słaby pomysł - spróbuj zrobić zapytanie na "motor-talk", bo do tamtego forum dostęp ma większa ilość potencjalnych użytkowników.

[Jankus]

Ja jestem chętny. Strzelam ze trzeba się wpiąć pod jakieś kable w bordzie, polecieć z zasilaniem i tyle w temacie. Oczywiście poza zmianą dekorów.

[Wolfe]

Can I zasilanie stale mozna z radia wziac.

[nTomek]

@mysiek10 a jak tam pobór prądu w stanie spoczynku (przy wyłączonej stacyjce)? Normy mówią, że nie powinno ono przekraczać 1mA.

[Albercik]

2 godziny temu, Jankus napisał:

Strzelam ze trzeba się wpiąć pod jakieś kable w bordzie, polecieć z zasilaniem i tyle w temacie

W mojej wersji - podpinasz wyprowadzone przewody pod CAN + stałe zasilanie, a z drugiej strony masz wiązkę z wtyczką, którą wpinasz normalnie zegarek.

Michał początkowo wpinał się w zegarek, ale to było sterowanie całkowicie 'na ślepo' i teraz też robi tak, jak ja. Różnica tylko taka, że jego testowa 'druciarnia' jest jak na foto wyżej - moja trochę lepiej wygląda:

@nTomek - IMO za wcześnie jest by mówić tutaj o poborze prądu, bo to są płytki testowe poskładane z kilkudziesięciu elementów, z których połowa jest niepotrzebna (choćby komunikacja serial->usb). Pomiary będziemy mogli robić dopiero jak już zostanie opracowane rozwiązanie docelowe. Aktualnie wyjdzie na pewno sporo więcej, niż 1mA. Pamiętaj, że to urządzenie nie może się w pełni uśpić, bo musi słuchać CAN'a. Pewnie łatwiej by to było podłączyć pod terminal 15, albo nawet 15b, ale nie o to chodziło. Na pewno sam translator bierze mniej, niż zegarek w trybie spoczynku.

 

Dnia 26.11.2017 o 17:06, radekrp90 napisał:

spróbuj zrobić zapytanie na "motor-talk",

Urządzenie miało być opracowane w założeniu na potrzeby Michała, a że urosło zainteresowanie tematem - planujemy też coś wyprodukować dla Forum. Ale dla motor-talk to już musiał by być produkt w pełni komercyjny, z zastrzeżonym patentem UE i co najmniej CE, a najlepiej TUV... To już inna skala zabawy. To nie przejściówka 36->32 pin do zegarów

[nTomek]

Chodziło mi bardziej o implementację i obsługę trybu "power-save". Po wyłączeniu zapłonu translator może słuchać magistralę CAN, ale dużo rzadziej - np. co kilka sekund. W tym czasie spokojnie może pójść w jakiś "Sleep". Procesory AVR (jak prawie każde) mają taki tryb pracy, w którym "biorą" prąd rzędy naście uA. Poza tym są przerwania, które też mogą służyć do budzenia procka. Ale to oczywiście kosmetyka. Na pewno translator nie będzie powodował rozładowania aku.

Co do zegarka i jego poboru prądu to nie byłbym taki pewien. To jest urządzanie magistrali LIN i z definicji posiada tryb "sleep" - "power save", w który wchodzi obligatoryjnie jak przestajesz z nim gadać lub na polecenie - sam z resztą wiesz.

Reasumując cieszę się, że udało się to wam zrobić i liczę na nowe pomysły

[Albercik]

no właśnie rozkminialiśmy z Michałem jak działa zegarek i tam nie ma żadnego procka sterującego silniczkiem, czyli - wskazówki są przesuwane przez główny (i jedyny) procek tego urządzenia, a więc on na pewno nie jest usypiany. Ja procek będę usypiał w chwili, gdy rozgryzę jak można będzie usypiać CAN driver bez stosowania dodatkowego tranzystora...

[nTomek]

Dlaczego nie jest usypiany? Może wchodzić w "sleep" i tylko co parę sekund (a nawet co minutę ) budzić się na ruch wskazówek, a jak przyjdzie "wake-up" od strony LIN'a to staje się "zwarty i gotowy".

Jaki masz ten driver?

 

[mysiek10]

Co do poboru prądu, to pierwsza wersja wykorzystująca Arduino mini pobierała ok 40mA, wiem że to dużo ale nie było tam obsługi usypiania procka a nawet nie był usunięty stabilizator napięcia z płytki Arduino. Ale jeżdżę z tym już trochę czasu i na pewno nie powoduje to rozładowania akumulatora.

Myślałem o trybie sleep w procku ale brak czasu na razie zabił temat, jeśli chodzi o przerwania to można wykorzystać bo na module CAN jest wyjście INT więc gdy coś się pojawi na CAN da się obudzić procka. Jeśli chodzi o oryginalny układ zegarka to tam jest na pewno sleep bo jego pobór to właśnie ok 1mA.

Driver LIN to na tą chwilę MCP2025.

Edytowane 29 Listopada 2017 przez mysiek10

[Albercik]

Ale on nie jest usypiany na bank bo wskazówki przesuwają się co kilka sekund. On może mieć taki pobór normalnie, bo tam w sumie nie ma żadnej filozofii, a sam procek nie pobiera za dużo.

[nTomek]

3 godziny temu, mysiek10 napisał:

Driver LIN to na tą chwilę MCP2025.

Chodziło o driver CAN. Co do stabilizatora to fakt - takie zwykłe linowe mają małą efektywność i potrafią się grzać przy byle obciążeniu. Lepiej zastosować jakąś przetwornicę "step-down".

Przy prądzie 40mA nic się nie będzie działo jak będziesz przynajmniej co kilka/kilkanaście dni odpalał auto, ale... jak zostawisz go gdzieś na dłużej, to... 40mA * 24h = 0.96Ah na każdy dzień postoju. Przeciętny aku w dieslu to 68Ah więc po 35 dniach układ rozładuje go do połowy - teoretycznie, bo w praktyce rzadko który, kilkuletni trzyma takie parametry i jest zawsze 100% naładowany.

Patrząc na dane samego procesora ATMega32M1:

Jak widać, przy pracy z zegarem 16MHz @5V potrafi wziąć 15 do 30mA. Chcąc zejść ze średnim prądem poniżej 1mA trzeba wprowadzać go w tryb "Power-down".

Pozostaje jeszcze CAN driver (transceiver) - temat do dopieszczenia