Mosconi UART Commands - wie saubere Erkennung?

P406

verifiziertes Mitglied
Registriert
25. Sep. 2003
Beiträge
4.894
Real Name
Martin
Hallo Mitfuzzis,

um den lieben Frank nicht endlos zuzuspammen :lolschild: , einfach mal hier rein: Es gibt ja doch diverse Fuzzis die fit in Programmierung (Arduino) sind. :hippi::thumbsup:
Hab ihr einen sinnvollen Ansatz, wie man die einzelnen Bytes sauber erkennen kann?

Der Message-Aufbau ist ja:

0x08 0x43 0x(Volume) 0x(Sub-Volume) 0x(Balance) 0x(Fader) 0x(Preset) 0x00

Also 8 Bytes. Meine erste Idee auf "0x08 0x43" zu warten geht so leider nicht, da je nach Einstellung auch die Kombination aus Sub-Volume und Balance die Konstellation "0x08 0x43" annehmen kann...... :kopfkratz::kopfkratz::kopfkratz:

Jemand einen Ansatz?!?!

Ich hab den DSP aktuell leider nicht hier, aber wird evtl ein <CR> oder sowas am Ende einer Message mitgesendet???
 
Hallo Martin, auch ich habe mich schon (theroretisch) mit einer DIY Remote befasst. Immerhin steht der Name schon - OMR (Open Mosconi Remote :ugly: )

Warum willst du denn auf eine Nachricht vom DSP warten? Auslesen der aktuellen Parameter?

Ich werde erstmal nur Daten über UART mit dem serial.print Befehl senden und mal sehen wie die Kommunikation klappt. Den Rest kann man dann drum herum stricken.

Die Frage die sich mir aktuell stellt ist die Länge der UART Verbindung, 5m sollten es ja schon sein, nur ob das auf die Länge funktioniert? Ich werde wohl mit der Praxis nach dem WoofAYA anfangen, also ab Februar. Bis dahin heisst es Ideen sammeln und Gedanken machen.
 
Hallo Mitfuzzis,

um den lieben Frank nicht endlos zuzuspammen :lolschild: , einfach mal hier rein: Es gibt ja doch diverse Fuzzis die fit in Programmierung (Arduino) sind. :hippi::thumbsup:
Hab ihr einen sinnvollen Ansatz, wie man die einzelnen Bytes sauber erkennen kann?

Der Message-Aufbau ist ja:

0x08 0x43 0x(Volume) 0x(Sub-Volume) 0x(Balance) 0x(Fader) 0x(Preset) 0x00

Also 8 Bytes. Meine erste Idee auf "0x08 0x43" zu warten geht so leider nicht, da je nach Einstellung auch die Kombination aus Sub-Volume und Balance die Konstellation "0x08 0x43" annehmen kann...... :kopfkratz::kopfkratz::kopfkratz:

Jemand einen Ansatz?!?!

Ich hab den DSP aktuell leider nicht hier, aber wird evtl ein <CR> oder sowas am Ende einer Message mitgesendet???


Ich kann dir helfen und deine Fragen alle beantworten aber bitte via Whatsapp/Telegram, du kannst dann ja die Ergebnisse hier posten das alle davon was haben.
Schreib mir einfach mal eine PN.
 
Kleiner Nachtrag : Meine Version ist aktuell im Funktionsumfang schlicht geplant, im Detail


  • Master Volume
  • Sub Volume
  • Preset Auswahl
  • Spannungsanzeige

Eingabe über Inkrementalgeber und ggf externen Taster für die Preset-Auswahl. Auch eine Oldschool-Variante mit analogen Potis (je eines für Master und Sub und via AD Wandler umgerechnet) finde ich charmant.
 
Hi Daniel,

ich will das Ganze über mein CANchecked-Display lösen, und dafür muss ich die Daten auslesen um die Werte auf dem Display visualisieren zu können.
Für den Anfang komme ich mit Sub-Volume und Preset aus, Balance/Fader nutze ich eh nicht, und Volume wird (hoffentlich) über Pilotton funktionieren. :)
Gibt der Mosconi auch Spannung aus oder machst du das extern?

@ Jens:
Bekommst eine PN!
 
Bei so einem einfachen Bus und ohne Flussteuerung, fixe Identifier und Checksumme gibt es eigentlich nur eine "saubere" Variante.
Ich würde immer auf den Idle vom Bus warten, darauf synchronisieren z.B. mit einem Timer, und dann stumpf mit einem Timeout anfangen mitzuzählen.
Wenn alle 8 bytes da sind, und das erste 0x08 sowie das letzte 0x00 sind, würde ich sagen gültig.

Wenn bei Ablauf des Timeouts 7 oder 9 Bytes da sind, verwerfen. Wenn das erste und das letzte nicht 0x08/0x00 sind, verwerfen, usw.

Edit: Bei unsauberer Implementierung gehts natürlich schief, ich hatte z.B. einen Fall in der Entwicklung wo zufällig alle paar Wochen plötzlich jeder Wert um eine Position versetzt im Display stand...Ein/aus, läuft wieder.
 
Gibt der Mosconi auch Spannung aus oder machst du das extern?

Laut dem Foto von Frank gibt es an den Pins 3,3V und GND, ein Arduino sollte also "stand alone" problemlos damit laufen. Wie es aber inkl Display aussieht (2x16 oder OLED, da hab ich mich noch nicht festgelegt) kann ich so nicht sagen, evtl mag der Frank sich dazu mal äußern.

Arduino + Display über nen kleinen DC/DC mit +5V zu versorgen ist ja auch keine Hexerei, dann sollte mal halt mMn nur drauf achten, eine gute Masse zum DSP zu haben.
 
Achso, ich dachte du willst die Gerätespannung mit deiner OMR anzeigen lassen - vergiss was ich meinte .... :ugly:
 
Bei so einem einfachen Bus und ohne Flussteuerung, fixe Identifier und Checksumme gibt es eigentlich nur eine "saubere" Variante.
Ich würde immer auf den Idle vom Bus warten, darauf synchronisieren z.B. mit einem Timer, und dann stumpf mit einem Timeout anfangen mitzuzählen.
Wenn alle 8 bytes da sind, und das erste 0x08 sowie das letzte 0x00 sind, würde ich sagen gültig.

Wenn bei Ablauf des Timeouts 7 oder 9 Bytes da sind, verwerfen. Wenn das erste und das letzte nicht 0x08/0x00 sind, verwerfen, usw.

Edit: Bei unsauberer Implementierung gehts natürlich schief, ich hatte z.B. einen Fall in der Entwicklung wo zufällig alle paar Wochen plötzlich jeder Wert um eine Position versetzt im Display stand...Ein/aus, läuft wieder.

Puuuhhhh okay, ich weiß nicht ob das meine Fähigkeiten übersteigt..... :ugly::kopfkratz:
 
Da sollte es doch fertige Code-Snippets im INet geben, man muss ja nicht immer das Rad neu erfinden :D
 
Die Frage ist ja ob es wirklich ein Idle auf dem Bus gibt, im Video vom Frank sah das so aus als ob das ein durchrauschender Datenstream wäre.
Wenn der DSP natürlich nur auf Abfrage durch 0x08 0x43 antwortet, ohne selber rum zu plaudern, wäre es easy.
Muss den wohl doch aus der Halle holen fahren. :ugly:
 
Freut mich das er hier Interesse gibt.

Der Bus ist ruhig.
Es gibt nur traffic wenn Daten abgerufen werden (0x08 0x43) oder das Bedienteil Daten sendet.

Aufpassen: Unsere MCU hat nur eine UART, die wird auch von der GUI verwendet.
Während die GUI verbunden ist sollte das Bedienteil still sein auf dem Bus.

Das Video ist auch nicht ganz aktuell - zusätzlich gibt es noch ein neues Protokoll:

Extension Tone Control (FW 4.11 required)l:
0x08 0x44 <Treble> <Mid> <Bass> <reserve> <reserve> <reserve>
Tone control value range 0x01 to 0x0F / 0x08 is neutral
0xFF as Value will ignored by DSP – no changes

New readback FW4.11:
Send to DSP:
0x08 0xCF (0x08 – Android / 0x4 or Bit 7 – 0x3 or 0x4 -> All datas readback)
The DSP will answer 15 Bytes:
0x08 0xCF <Volume> <Subvolume> <Balance> <Fader> <Preset> <CAN-DAta> <In-Volume> <Treble> <Mid> <Bass> <reserve> <reserve> <reserve>

VG Frank
 
Ah sehr schön!!!
Also bei der Initialisierung einmal mit 08 CF alles abrufen, Werte weg speichern und bei Änderung senden, zurück gesendetes updaten…
Sehr schön, das erleichtert vieles! :)

NACHTRAG: „08 CF“ sollte wenn ich es recht überblicke auch das Problem lösen, dass die Kombi auch woanders im Stream auftauchen kann…. Geil! :liebe:
 
@Frank_GM: Ist der UART 5V-tolerant?
Sonst muss ich nen LevelShifter einsetzen.
 
Theoretisch ja. Würde ich aber nicht machen weil dann 1,7V über die Dioden im Atmega auf die 3.3V abgeleitet werden.
Zwar nur mA, aber unnötiger "Traffic" auf VDD.

Das ganze ist mit 38k aber so langsam, da geht auch gut ein Optokoppler dazwischen.....

VG Frank
 
Mal ne Frage zur Kabellänge. 5 Meter sind für das Senden/Empfangen von UART Kommandos problemlos? Mir fehlen da absolut Erfahrungswerte.
 
Die Pinbelegung am DSP habe ich mal hochgeladen, denke Frank hat nichts dagegen :hippi:
Anhang anzeigen 105316

Davon ausgehend, dass der Port so aufgebaut ist dass man den Dongle „egal wie rum“ stecken kann, sollte unten links eine Beschriftung falsch sein, oder?
(GND statt TXD) :kopfkratz:

Gut aufgepasst - hat noch keiner gemerkt in 2 Jahren ;-)
Soll natürlich TxD sein.

@Raffnix: 5m sind bei dem Tempo kein Problem.

VG Frank
 
Zurück
Oben Unten