Hallo zusammen, ich habe eine kleine Frage. Ich bin noch ein wenig unerfahren in der Programmierung von MCUs. Nun habe ich ein Projekt bei dem ich Daten die von einem ADS-B Empfänger kommen, per UDP an den PC weiterleiten muss. Sprich ich muss das Signal mit einer Bitrate von 2Mbit/s erst mal AD wandeln, danach den Bitstrom analysieren (verschiedene Infos auswerten wie Längen- und Breitengrad des Flugzeugs, Höhe usw)und abschließend die ausgewerteten Daten per UDP an den PC schicken. Nun stellt sich die Frage welchen MCU ich dafür am besten verwende. Da ich mit dem AVR Studio schon programmiert habe, würde ich gerne wieder einen Controller von Atmel benutzen. Denkt ihr mit einem Controller der UC3 Flash Serie ist das machbar? Laut Homepage kann er 80 MIPS. Das Problem ist, dass ich nicht wirklich einschätzen kann, ob der UC3 Controller für die Anwendung ausreicht. Wäre euch echt sehr dankbar, wenn ihr mir eure Einschätzung sagen könntet. Vielen Dank im Voraus! Stefan
Das ADS-B Signal wird nur einmal pro Sekunde gesendet, da kommen also keine hohen Datenraten raus, das schafft spielend ein 8-Bitter. Um mehr zu sagen, müßte man wissen, in welchem Format Dein ADS-B Empfänger die Daten ausgibt. Das die Daten analog übertragen werden, erscheint mir äußerst unwarscheinlich. Peter
Hm, also ich glaube zum einen dass es 2 mal pro sekunde gesendet wird. Aber das ist ja auch nicht das kritische. Wo ich probleme sehe ist, ist das Signal an sich zu erfasssen. Eigentlich hat es eine Bitrate von 1Mbit/s, aber dadurch dass es mit PPM moduliert ist, ergibt sich eigentlich eine Bitrate von 2Mbit/s. Die Idee von meinem Prof und mir war, dass wir keine PLL benötigen einfach jedes Bit 5 mal abzutasten, und dann anhand der Werte zu erkennen, falls mir der Clock davonlaufen würde und je nachdem Gegenmaßnahmen zu ergreifen. Das alles macht der MCU und der interne AD wandler auch noch mühelos mit. Nur stelle ich mir die Frage, ob ich noch genügend Reserven für meine ganzen Berechnungen habe. Die Daten wollte ich dann per SPI an den ENC28J60 weitergeben, der die daten dann an den rechner weiterleitet. Ich hoffe ihr versteht mein Problem. Ist irgendwie schwer zu beschreiben.
Die Frage ist, willst Du Dir den Empfänger komplett selber basteln oder was fertiges nehmen? Ein fertiger Empfänger für ein bestimmtes Protokoll hat üblicher Weise einen digitalen Ausgang. Sich was selber zu basteln, benötigt schon fundierte Kenntnisse in der HF-Technik. Falls die Bandbreite wirklich 1MHz betragen sollte, ist das auch nicht einfach 0815. Um zum Selbstbau mehr sagen zu können, müßtest Du schon einen Link posten, wo das ADS-B Signal und das darauf liegende Protokoll beschrieben ist. Peter
> Sprich ich muss das Signal mit einer Bitrate von 2Mbit/s erst mal AD > wandeln > Denkt ihr mit einem Controller der UC3 Flash Serie ist das machbar? Dem DAtenblatt "AT32UC3A" entnehme ich eine maximale Samplingrate des AD-Wandlers von 533 kSPS. Damit hätte es sich erübrigt, ein Signal mit einer Bitrate von 2Mbit/s per ADC zu erfassen. > einfach jedes Bit 5 mal abzutasten Das macht es noch "schlimmer". Muß man das Signal unbedingt analog verarbeiten? Wäre dafür nicht ein ein Input Capture prädestiniert? D.h. statt abzutasten mißt man die Zeit zwischen den Flanken. Gruß Martin
Danke für eure schnellen Antworten! @Peter: hm einen fertigen Empfänger scheidet leider aus, da ich aus den verschiedenen Telegrammen immer nur Teile benutzten muss. Ja das Problem mit HF ist mir auch bekannt. Aber da ich schon ne Vorlesung in HF Technik gehört habe, hoffe ich dass ich damit klar komme beim Aufbau der Platine. @Martin: Ja das wäre dann die zweite Möglichkeit gewesen. Aber da ich über den Pegel auch noch kontrollieren will, ob sich meinem eigentlich Nutzsignal nicht irgendwelche Störungen überlagern, sollte das mehrmalige Messen eigetnlich schon sein. Aber zurück zum Thema AD wandlung. Im Datenblatt des AT32UC3B steht: 28.6.1 Analog-to-digital Conversion The ADC uses the ADC Clock to perform conversions. Converting a single analog value to a 10-bit digital data requires Sample and Hold Clock cycles as defined in the field SHTIM of the ”ADC Mode Register” on page 558 and 10 ADC Clock cycles. The ADC Clock frequency is selected in the PRESCAL field of the Mode Register (ADC_MR). The ADC clock range is between MCK/2, if PRESCAL is 0, and MCK/128, if PRESCAL is set to 63 (0x3F). PRESCAL must be programmed in order to provide an ADC clock frequency according to the parameters given in the Product definition section. Sprich wenn ich mit maximaler Clock von 80MHZ fahre und PRESCAL auf 0 setzte komme ich auf eine Sampling Rate von 4MHZ (80MHz/(2*10 clock cylces)) was ja gerade noch so okay wäre. Oder habe ich da was falsch verstanden?
Nur weil sich der Wandler so schnell konfigurieren lässt heißt das nicht unbedingt dass er dann noch etwas sinnvolles tut. Spezifiziert ist eine so hohe Abtastrate nicht mehr, vielleicht funktioniert es trotzdem.
Hm okay danke. In dem Fall wohl lieber einen externen AD Wandler benutzen oder?
Stefan Frick wrote: > Danke für eure schnellen Antworten! > > @Peter: hm einen fertigen Empfänger scheidet leider aus, da ich aus den > verschiedenen Telegrammen immer nur Teile benutzten muss. ??? Das mußt Du mal näher erklären. Wo soll darin ein Problem bestehen, nicht benötigte Daten zu ignorieren und nur die benötigten weiter zu leiten? Wenn Du das Protokoll kennst, weißt Du genau, was Deine interessanten Daten sind. Und das Protokoll mußt Du ja kennen, sonst sind die Daten nutzlos. > Ja das Problem > mit HF ist mir auch bekannt. Aber da ich schon ne Vorlesung in HF > Technik gehört habe, hoffe ich dass ich damit klar komme beim Aufbau der > Platine. Ich will Dir ja nicht die Hoffnung nehmen, aber ich bezweifle mal, daß man HF-tüchtiges Layouten in Vorlesungen lernen kann. Peter
Hallo Peter, ich glaube ich verstehe schon was du meinst. Du meinst ich solle einen Chip benutzen, der die ADS-B Daten aufbereitet, und mir diese an einem digitalen Ausgang bereitstellt oder? Ja wenn es so etwas gäbe, wäre natürlich nicht schlecht. Habe gerade auch mal gegoogelt, aber leider nichts passendes gefunden. Und klar, das Telegramm kenn ich schon. Wenn ich es selber aufbereite, muss ich ja auch wissen wo was im Telegramm steht um es dann entsprechend weiterzuleiten. Falls es dich interessiert, das Protokoll ist in dem folgenden Dokument beschrieben: adsb.tc.faa.gov/WG3_Meetings/Meeting13/1090-WP-13-06.pdf Genauer gesagt auf Seite 37. Gruß Stefan
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.