DSP für batteriebetriebenen RFID Reader

Hi,

Gibt schon was so gut wie fertiges:

http://www.analog.com/library/analogdialogue/archives/40-09/rfid.html

Laeuft auf uClinux, allerdings wuerde ich aus verśchiedenen Gruenden 
(auch des Stromsparens wegen) den BF527 nehmen. Damit kann man gleich 
per USB auch noch die Daten ueber diverse Sticks verschicken 
(WLAN/Bluetooth) oder speichern.

Gruss,

- Strubi

Über welches RFID sprechen wir? 125kHz? Da reicht ein AVR8 denke ich.

135kHz. Die analoge Version braucht zum Auslesen im Moment "ein paar 
Sekunden" laut Bericht. In fertig soll es dann allerdings nicht (viel) 
länger dauern als der Tag Hersteller für seine Tags angibt: 300ms.

Klar, gehen tut das bestimmt auch mit einem 8bit Mikroprozessor. 
Auftraggeber sagt aber: Okay wir haben digitale Filter drin, 
demodulation und so einen Käse mach das mal mit einem DSP.

Ich hab den Link mal durchflogen, so wie ich das sehe gibt es Blackfin 
Prozessoren für RFID? Wenn ja schau ich mir den mal genauer an.


Wie gesagt, wichtig ist
 - schnelle Signalverarbeitung
 - schnelle Demodulation (hab da schon was im Kopf aber das hat hier mit
   nur "indirekt" was zu tun)
 - günstig
 - Strom ist rar da wo das ganze in Einsatz kommt (bzw nicht vorhanden)
   sollte also auch Stromsparend sein. Man muss dann erorieren wie ein
   mehrpreis für den Proz im vergleich zu einer teureren Stromquelle
   aussieht ... Aber auch das gehört hier nicht her.

Blanvolet schrieb:
> Die analoge Version braucht zum Auslesen im Moment "ein paar
> Sekunden" laut Bericht.
Was heißt "die analoge Version"?

Filter um Träger- und Nutzsignal zu Trennen (wird durch einen Mixer 
ersetzt) und dann ein Komparator ums in ein Rechtecksignal umzuwandeln - 
die Highzeit wird dann entsprechend gemessen.

Das soll jetzt nach dem Mixer digitalisiert werden und gefiltert werden

Blanvolet schrieb:
> Ich hab den Link mal durchflogen, so wie ich das sehe gibt es Blackfin
> Prozessoren für RFID? Wenn ja schau ich mir den mal genauer an.

Nicht als SoC, aber du brauchst ja nur noch den MxFE chip, der geht ohne 
Extralogik direkt an den PPI ran, Treiber sind auch schon da. 
Schlimmstenfalls muss noch ein Verstärker her.

Allerdings sind die Blackfins (zumindest BF527) nicht mords-billig, aber 
da man mit uClinux eine Vielzahl an Referenzapplikationen gratis "mit 
dazu bekommt", ist die time to market sehr kurz, ergo kostensparend auf 
der Entwicklungsseite. Die paar Kroeten die man bei ein paar 1000 
Geraeten sparen wuerde, rechnen sich im Vergleich damit nie. Kannst dich 
also bei der Loesung im grossen Ganzen auf die Entwicklung der 
DSP-Algorithmen konzentrieren.

Gruss,

- Strubi

Hallo,

von den Blackfins würde ich die Finger lassen. Der JTAG-Programmer 
kostet allein 3000Euro. Was das Visual-DSP kostet weiß ich zwar nicht, 
aber ist bestimmt auch teuer.

Auch ist mir bei Deiner Problemstellung nicht klar, warum ausgerechnet 
ein DSP genommen werden soll. Hier würde ich eine schnelle ARM für die 
Auswertung nehmen. Es geht hier doch gar nicht um Signalverarbeitung, 
sondern um die Auswertung von einem Protokoll, oder ? SD-Karten auslesen 
kann man auch mit jedem uC oder einer ARM.

Und dann noch die der letzte Punkt: Energie sparen. Für eine 
Batterieapplikation sind die BFs respektive DSPs keine gute Wahl. Also 
auch hier würde ich zu einem ARM greifen.

Gruß,
H

Ein ARM (STM32) würde sicherlich mit einem guten ADC eine nguten Job tun 
- für 5$. Mein "Chef" will halt einen DSP haben. Ich hab die STM32 
version aber notiert und werde sie vortragen - dann muss ich zwar mein 
Thema ändern aber egal :D

die Blackfin sin mit sicherheit zu groß und tuer. Die C5000 sind 
eigentlich auch zu teuer... und die dSPICs sind mit 300mA max. nicht 
gerade Stromsparend ^^

Harald schrieb:
> von den Blackfins würde ich die Finger lassen. Der JTAG-Programmer
> kostet allein 3000Euro. Was das Visual-DSP kostet weiß ich zwar nicht,
> aber ist bestimmt auch teuer.

Das war mal vor 5 Jahren so. Inzwischen kostet die komplette Toolchain 
mit ICEbear JTAG keine 120 Euro mehr und ist - wenn man sowieso schon 
GNU spricht - mindestens so gut wie VDSP, wenn nicht besser, aber das 
ist oft auch Geschmackssache.

ARM-Entwicklung kann im Prinzip aehnlich guenstig sein, wenn da nicht 
das Problem mit zig Derivaten und unterschiedlich gut 
dokumentierten/supporteten Toolchains waere.

Was das Stromsparen angeht: Die neuen Blackfins sind mindestens so 
stromsparend wie aktuelle ARMs, teils sogar deutlich besser. Genau 
deswegen setzen wir den ja ein, das MIPS*Laufzeit-Produkt ist bei denen 
im Vergleich zu anderen DSP-Hybriden optimal.

Ja ich denke aber die Blackfin sind zu teuer - die C5000 schätzungsweiße 
auch... Deshaöb ja die Frage welchen dSPIC man nehmen könnte .D

Naja, bei der Hardware gilt meistens: You get what you pay for - solange 
du auch die versteckten Kosten (Tools/Lizenzen) im Auge behaeltst.
Wie gesagt, was die eigentlichen Kosten reisst, ist ja die 
Entwicklungszeit. Wenn ich da mit einer stabilen uClinux-Loesung ein 
halbes Mannjahr EWK sparen kann, jucken mich 5 Dollar Unterschied bei 
5000er-Stueckzahlen nicht mehr..

Gruss,

- Strubi

Wobei Linux in dem Fall oversized wäre und meine kompetenzen dann 
übersteigt - ich hab halt noch nie Software für Linux geschrieben (ok is 
auch nur C Code) der dann wie normaler Code auf einem Mikrocontroller 
was steuert. Sollte in dem Fall aber auch übertrieben sein :D

FreeRTOS auf dem STM32 wäre da Sinniger...


Warum sollte die Entwicklung mit dem dSPIC hässlich/aufwändiger werden?

Also, ich bin natuerlich stillschweigend davon ausgegangen, dass du die 
eingelesenen RFID-Daten irgendwie mit einem Server abgleichen willst, 
ergo irgend einen Protokoll-Stack brauchst, wenn nicht sogar einen 
simplen SQL-Client.
Wenn du natuerlich nur eine Zeichenkette per UART an einen 
Bluetooth-Adapter schickst, dann tut's natuerlich auch ein FreeTOS, oder 
du schreibst gleich alles "bare metal".
Mir war der dsPIC halt damals bei der Entscheidung zu schmalbruestig, 
PIC hatte wegen der Tools generell schon schlechte Karten (JTAG buggy, 
usw.).
Im Endeffekt finde ich, soll man das benutzen, wo man sich am besten 
auskennt, ergo am effektivsten debuggen und die Risiken am besten 
abschaetzen kann. Ich bin halt generell ein Fan von Code-Recycling bzw. 
bewaehrten "Lego-Bausteinen", auch wenn uClinux manchmal nach "Kanone 
auf Spatz" aussieht.

Die Geräte werden in einem Wald hängen. Nix Bluetooth, Server, SQL oder 
sonst was. Die eingelesenen Tags werden entweder on chip oder externer 
Speicher (ich schlage eine SD Karte mit einer *.csv datei vor) 
gespeichert.

Dafür tuts mit sicherheit ein STM32 - die Aufgabe sieht aber eben 
eigentlich einen DSP vor.


Das mit der Toolchain von PIC hab ich schon gelesen ... das hab ich auch 
notiert. Also ich denke entweder die Aufgabe umschreiben auf normalen µP 
(STM32) oder einen C5000 nehmen.

PS: Wenn ich da bleibe wo ich bin muss ich Atmel nehmen :D

dig. Filter, demodulation, UI

Hallo Blanvolet.

ich arbeite seit einigen Monaten auf einer TI C2000 DSP Platform. Hat 
einen 60MHz 32bit core, ausreichend AD und Ports, auch für SD-Karte. Mit 
Flash und SRAM on board. Entwicklungswerkzeuge sind günstig (ca 50USD) 
und die Serienbausteine kosten etwa 2-3EUR. Platform ist einigermaßen 
skalierbar. Das Entwicklungswerkzeug ist für diese Platform frei 
erhältlich.

Des weiteren:
Batterie und DSP lässt sich aber m.E. schlecht vereinbaren. Ich mutmaße 
bei der Applikation "im Wald hängen" einen geforderten mehrtägigen 
Einsatz. Dann musst Du die einen intelligenten Sleep Mode überlegen denn 
die Prozessoren von denen ich hier gelesen habe dürften alle mehr als 
100mA (= 300mW) benötigen, heißt bei 24h und 3V etwa 2500mAh (grob 
überschlagen). Das ist eine dicke fette Lithiumzelle pro Tag.

Grüße

Dann schau ich mir den C2000 auch mal an.

Und ja - Strom ist ein Problem und ein Sleepmode aus dem man schnell 
rauskommt muss her. Ich mach mir vor dem Sleepmode und dem Fall "Zwei 
Tags in Antenne" mehr sorgen als vor dem rest.

Ich schlag jedenfalls noch Brennstoff- und Solarzelle als 
Stromversorgung vor. Ansonsten könnte das eng werden mit Strom, 
sleepmode hin oder her. Kann ja nicht angehen das man jeden Tag da hin 
muss um die Batterie zu kontrollieren ...

Nur so als Anmerkung, bei meinem Blackfin-System hab ich mal gemessen:

- uClinux Vollast, mit Ethernet-Traffic (160 mA), Core clock 500 MHz, 
Sysclk 133 MHz
- uClinux idle (Peripherie auf Standby): ~80mA

Das ist das komplette Board (mit Kamerasensor und Phy), also nicht nur 
Prozessor. Deep Sleep habe ich noch gar nicht getestet.

Im Standalone-Betrieb (ohne komplexes OS) kommt man mit reduzierten 
Clocks und ohne SDRAM-Betrieb auf ca. 45mA, Sleep Mode hab ich nur kurz 
mal getestet, da zieht wohl die Peripherie mehr als der Proz, kaum 
Aenderungen am Verbrauch, Unterschied von 3 mA (traf sich in etwa auch 
mit der theoretischen "power dissipation" bei 50MHz).
Sind also riesige Unterschiede zu aelteren Architekturen, bei neuen 
Blackfins soll laut Datenblatt 90mW bei Vollast (400 MHz Coreclock) 
drinliegen.

Weiss nicht mehr genau, wie's bei den TIs war, aber duerfte etwa 
ueberall dieselbe Strategie sein: PLL bypassen, in den IDLE state gehn, 
und die CPU so selten wie moeglich per RTC aufwecken, 
Aufwach-Bedingungen pollen und dann wieder ab in den IDLE.

Der eigentliche Stromfresser duerfte wohl eher die A/D section sein, 
bzw. die Frage, wie schnell sich das Gesamtsystem aufwecken laesst, wenn 
ein Waldtier vorbeirennt (oder was taggt ihr da, wenn man fragen darf?)

Gruesse,
- Strubi

Ich tagge Fledermäuse :D Ich denke das ist ok wenn ich das sage. Hab da 
keine Klausel oder so unterschrieben.

Ich bastel im laufe des Tages mal eine Tabelle wieviel Strom der 
Prozessor nach Tabelle wann verbraucht. So richtig abschätzen kann man 
das nicht, da geh ich einfach mal von best- und worst-case aus. Kann ja 
nur besser werden :D

Ich denke aber halt das die Blackfins bei dem /1000 Preis zu teuer sind 
... Und µLinux drauf laufen lassen, weiß nich. Ich glaub ein normales OS 
tuts da ganz gut. Nicht das ich was gegen Linux hätte, ich habs nur noch 
nie (auf einem µP) benutzt und ich hab keine Ahnung ob mir das Vor- oder 
Nachteile bringt. (Genauso muss ich noch eroieren ob mir ein Port für 
SD/MMC Karten Vor- oder Nachteile bringt).

Ich denke weiterhin das ein ARM ala STM32 fast die beste wahl ist: Sehr 
"kräftig", sehr günstig, sehr gut erreichbar.

Mal sehen was der Prof sagt

Sag doch gleich, dass es ein akademisches Projekt ist :-)
Da duerfte die Zeit-ist-Geld-Rechnung und time-to-market einen etwas 
anderen Stellenwert haben..
Wuerde aber trotzdem mal schauen, wenn ich du waere, ein Pflichtenheft 
zusammenzubekommen, bevor du dich mit neuen Architekturen in unbekanntes 
Terrain vorwagst. Manchmal haben Profs diesbezueglich zu hohe 
Erwartungen...

Gruesse,

- Strubi

Das passt schon, ich hab hier als "deutscher Ingenieur" relativ freie 
Hand :D

Also ich soll benutzen was ich möchte, Geld ist relativ wurscht ich kann 
jedes EVA Board haben das ich möchte :D Doch Blackfin? Nein!

Ich denke im Moment ernsthaft über den C5000 nach. Er hat definitiv 
zuviel Power, aber das macht ihn eher noch attraktiver. Ich muss das 
ganze am Mittwoch dem Team vorstellen was ich denke. und ich werde 
speziell auf den C5000 hinweisen, der kann einfach alles was wir 
brauchen und noch mehr.

Ich habe auch mal gerechnet:
Angenommen wir nehmen eine 2500mAh NiMh Batterie. Angenommen der 
Prozessor läuft, wenn ein Tag zu lesen ist, 2sec lang auf 130mA. Dann 
kommen wir mit der Batterie auf ~34000 Zyklen oder 19h Dauerbetrieb. Wir 
rechnen im Moment damit das wir in einer Woche 20 Fledermäuse "fangen" 
können (was mir bei einer Population von ~10000 pro Höhle wenig vorkommt 
aber ich bin kein Fledermaus-Experte).
Wie sich rausstellte wäre eine Brennstoffzelle perfekt, aber teuer. Ich 
werd mal schauen was ich so finde. Im Moment soll eine Auto Batterie 
benutzt werden - ich sag nur eins: Ich bin in den USA, die Batterie wird 
für gefühlte 2 Jahre dauerbetrieb reichen und die Winter hier wo ic hbin 
gehen auf -20°C bis -30°C :D


Eine Frage an die dSPIC User: Was für Fehler weißt die Toolchain auf? 
Was berichtet eure Erfahrung darüber?
Noch eine Frage: Gibt es Betriebssyteme für DSPs? Ich meine jetzt nicht 
Linux, sondern eher sowas wie FreeRTOS.

We can't stop here, this' bat county!


PS: Ich als Atmel Fanat und mehrjähriger User darf eigntl kein dSPIC 
nehmen :P Danke für eure Hilfe. Ein Pflichten/Lasten/Dingsbumsheft muss 
ich für meinen Bericht eh anfertigen. Genauso wie zwei Präsentationen, 
und eine hier in den USA. Ich freu mich -.-

Blanvolet schrieb:
> Noch eine Frage: Gibt es Betriebssyteme für DSPs? Ich meine jetzt nicht
> Linux, sondern eher sowas wie FreeRTOS.

Ich habe mir mal eCos und RTEMS angesehen. Bin aber im Endeffekt auch 
bei uClinux gelandet und benutze die Adeos-Realtime-Erweiterungen. Das 
Zeug lief auf Anhieb sehr stabil auf dem STAMP BF537. Der eCos-Port kam 
auch von einem RFID-Projekt (rfidguardian).
Aber mal ganz ehrlich: Wenn Du ohne Vorkenntnisse betr. OS und 
Architektur loslegst, holst Du dir auf jeden Fall eine blutige Nase (so 
geschehen bei uns mit TMS320C5xx und 6xx, Code Composer fasst hier 
keiner mehr an).
Deswegen mein dringender Rat: Wenn ihr wirtschaftlich arbeiten wollt, 
nehmt eine funktionierende Referenzlösung, die sich bewährt hat, gerade 
wenn es um ein Produkt geht, was nicht alle paar Wochen vor Ort debuggt 
werden muss.

Moin,

Ano Nym schrieb:
> Wie gesagt, ein Linux und einen Blackfin möchte ich nicht - da hol ich
> mir auf jeden Fall eine blutige Nase.

Verstehe ich immer noch nicht. Warum solltest du dir mit einer 
Referenzloesung eine blutige Nase holen? Hoer dich doch mal in der 
Industrie um...

eCos und RTEMS sind v.a. Realtime-Systeme und von der 
Treiber-Entwicklung aehnlich komplex wie uClinux, mit dem Unterschied, 
dass uClinux fuer fast alles Treiber-Frameworks bereitstellt. Bei eCos 
musst du mindestens aehnlich OS-Knowhow haben wie fuer Linux.

Apropos: Wenn ich mich nicht taeusche, basiert die Firmware von 
www.rfidguardian.org auf einem eCos-Port fuer den BF548 (letzterer ist 
allerdings eine rechte Spatzenkanone).

Wenn Ihr das Rad neuerfinden wollt: Das kann mal locker 1-2 Jahre 
dauern. Kein Problem, wenn man eine Doktorarbeit draus macht. Wenn aber 
schon die Zeit fuer ein eigenes Evalboard nicht da ist, sehe ich etwas 
schwarz - nimm's mir nicht uebel, aber ich habe schon so einige 
akademische Ansaetze scheitern bzw in chaotischem Gebastel (was im 
Endeffekt mehr kostet) enden sehen. Ist nicht immer ein Problem, aber 
man muss sich eben genau ueberlegen, ob man ein skalierbares 
industrietaugliches Produkt haben will, oder eine Lernplattform.


Gruss,

- Strubi

@ Ano Nym (oorim)
1. Bei TI schimpft sich das Betriebssystem "DSP/BIOS".

2. Unter Linux kannst du mit Sicherheit auch so entwickeln, dass der 
Biologe/Waldarbeiter nichts von dem Linux mitbekommt. Bei nem DSL-Router 
oder nem SAT-Receiver siehst du ja auch nix davon.

Ich verstehe wirklich nicht warum da ein DSP verwendet werden muss. 
135KHz das ist garantiert Lastmoduliert. Da musst Du doch nur runter 
mischen und mit einem Interrupt-Eingang mit-Triggern. Ich habe ein 
Projekt gesehen, da wurde mit einem Mega8 und einem SA612 ein Reader 
gebaut. Das Protokoll hatte einen Datenrate von 26Kbit. Das sollte wohl 
auch schneller sein als bei dem 135KHz-System. Da kannst Du sogar 
redundant parallel lesen.

Zweimal lesen geht sowieso nicht. Prinzip-bedingt.