Telemetrie via Audiokanal - Programmierer und Tester gesucht
- Themenstarter QuadMax
- Beginndatum
- Status
Nur fuer mein Verstaendnis, was sind denn diese besagten Funktionen?
So viel anders ist avr-gcc auch nicht, hinter arduino steckt was fuer ein compiler?
Dreimal duerft ihr raten
Ja okay, avr-g++ fuer die Haarspalter
Aber stellt euch ein Arduino ohne Klassen vor, die die meissten sowieso nicht nutzen weil alles in die main programmiert wird
Beim arduino ist vieles in libs gekapselt (gibts beim gcc auch im Netz, heissen nur meisst etwas anders) bzw. ist gibt z.B. diesen millis kram. Aber das kann man auch nach programmieren. Frage ist nur, will man das? So wie ich das sehe, ist der Timer code ziemlich zeitkritisch, wollt ihr euch da wirklich die fette Arduino Infrastruktur ins Boot holen? Da laeuft z.B. fuer die millis Funktion ein timer im Hintergrund der dem afsk timer dazwischen schiessen kann, das gleiche gilt fuer die Serial Funktion die ueber interrupts laeuft.
Ich wuerde da eh was eigenes mit polling machen, aber das hat er ja auch schon bei sich drinnen
Source Code gibts bei ihm in github. Da sind die afsk.[ch] / hardware.[ch] Dateien mit der ganzen Magie drinnen. Dann gibts noch eine main.c mit ner init funktion, dass muesste man nach setup auf arduino kopieren und den serial kram ersetzen.
Oben drueber ist noch der message_callback, den brauchst aber nur auf der receiver seite um die Daten vom audio modem zu holen.
Der Teil aus der while kaeme in die loop beim arduino und auch hier wieder serial ersetzen. Rest ist vorbildlich dokumentiert.
Ohne mich jetzt zu weit aus dem Fenster zu lehnen, ein 15min Job
Und ja du hast richtig gelesen, wollte/will erstmal ein Audiomodem verwenden, aber nicht auf arduino Basis, ausser ihr schafft da mehr als 3800 baud
Habe mir zwei von diesen gebaut http://www.aeroquadstore.com/FPV_Modem_p/mdm-001.htm
So viel anders ist avr-gcc auch nicht, hinter arduino steckt was fuer ein compiler?
Dreimal duerft ihr raten
Ja okay, avr-g++ fuer die Haarspalter Aber stellt euch ein Arduino ohne Klassen vor, die die meissten sowieso nicht nutzen weil alles in die main programmiert wird
Beim arduino ist vieles in libs gekapselt (gibts beim gcc auch im Netz, heissen nur meisst etwas anders) bzw. ist gibt z.B. diesen millis kram. Aber das kann man auch nach programmieren. Frage ist nur, will man das? So wie ich das sehe, ist der Timer code ziemlich zeitkritisch, wollt ihr euch da wirklich die fette Arduino Infrastruktur ins Boot holen? Da laeuft z.B. fuer die millis Funktion ein timer im Hintergrund der dem afsk timer dazwischen schiessen kann, das gleiche gilt fuer die Serial Funktion die ueber interrupts laeuft.
Ich wuerde da eh was eigenes mit polling machen, aber das hat er ja auch schon bei sich drinnen
Source Code gibts bei ihm in github. Da sind die afsk.[ch] / hardware.[ch] Dateien mit der ganzen Magie drinnen. Dann gibts noch eine main.c mit ner init funktion, dass muesste man nach setup auf arduino kopieren und den serial kram ersetzen.
Oben drueber ist noch der message_callback, den brauchst aber nur auf der receiver seite um die Daten vom audio modem zu holen.
Der Teil aus der while kaeme in die loop beim arduino und auch hier wieder serial ersetzen. Rest ist vorbildlich dokumentiert.
Ohne mich jetzt zu weit aus dem Fenster zu lehnen, ein 15min Job
Und ja du hast richtig gelesen, wollte/will erstmal ein Audiomodem verwenden, aber nicht auf arduino Basis, ausser ihr schafft da mehr als 3800 baud
Habe mir zwei von diesen gebaut http://www.aeroquadstore.com/FPV_Modem_p/mdm-001.htm
Zuletzt bearbeitet:
Wenn du das in 15 min schaffst, fände ich das super, ich würde da Stunden lang dran sitzen und wahrscheinlich doch nicht fertig werden .
Habe Microcontroller immer nur mit der Arduino IDE programiert( und bin jetzt noch nicht lange aktiv dabei).
Wenn du 15 min opfern würdest wäre ich dir echt sehr dankbar.
Mir würden im Prinzip eine send() und eine recieve() reichen.
.Habe Microcontroller immer nur mit der Arduino IDE programiert( und bin jetzt noch nicht lange aktiv dabei).
Wenn du 15 min opfern würdest wäre ich dir echt sehr dankbar.
Mir würden im Prinzip eine send() und eine recieve() reichen.
Ich habe mir den Code eben angeschaut und er ist erstklassig geschrieben und Dokumentiert.
Da kann man wirklich was draus machen.
Grundzätzlich mag ich Arduino eigentlich nicht, eben weil es so ein großes virtualisiertes konstrukt ist. Ich habe auf dem Atmega8 in Assembler gelernt zu programmieren und das ist wehsentlich angenehmer.
Aber das Modem was du hier vorgeschlagen hast ist ja eigentlich perfekt. Da lohnt es sich nicht wirklich nen arduino für herzurichten.
Da kann man wirklich was draus machen.
Grundzätzlich mag ich Arduino eigentlich nicht, eben weil es so ein großes virtualisiertes konstrukt ist. Ich habe auf dem Atmega8 in Assembler gelernt zu programmieren und das ist wehsentlich angenehmer.
Aber das Modem was du hier vorgeschlagen hast ist ja eigentlich perfekt. Da lohnt es sich nicht wirklich nen arduino für herzurichten.
Das Problem sind nicht die 15min, sondern das ich nicht abschaetzen kann, ob die arduino ide einem dazwischen funkt.
Daraus resultieren dann eventuell wieder weitere Fragen, dann ist es mit den 15min nicht getan.
Du auesserst ja jetzt auch schon Aenderungswuensche an der Lib, moechtest ja 'nur' eine send/receive methode haben
Im Source Code steht das die eine ISR 9600x die Sekunde gerufen wird. Bei 16Mhz ergibt das ein Interval von 1666 Takten in der die ISR gerufen wird. Ich denke nicht das da noch Platz fuer Arduino Timer/Serial ist, die einem eventuell die afsk ISR genau dann blocken.
Und solche Kommentare in der main loop machen mir erst richtig stutzig ob das der richtige Ansatz ist
// Notice that we use "_nowait" since we can't
// have this blocking execution until a byte
// comes in.
Aber ich Frage gerne noch mal, was sind denn das fuer besagte Funktionen/Aenderungen die ihr euch da wuenscht?
Wenn ihr Probleme bei der Umsetzung habt, kann ich auch gerne das hexfile kompilieren und euch einen Gui Loader senden wenn euch avrdude abschreckt
Daraus resultieren dann eventuell wieder weitere Fragen, dann ist es mit den 15min nicht getan.
Du auesserst ja jetzt auch schon Aenderungswuensche an der Lib, moechtest ja 'nur' eine send/receive methode haben
Im Source Code steht das die eine ISR 9600x die Sekunde gerufen wird. Bei 16Mhz ergibt das ein Interval von 1666 Takten in der die ISR gerufen wird. Ich denke nicht das da noch Platz fuer Arduino Timer/Serial ist, die einem eventuell die afsk ISR genau dann blocken.
Und solche Kommentare in der main loop machen mir erst richtig stutzig ob das der richtige Ansatz ist
// Notice that we use "_nowait" since we can't
// have this blocking execution until a byte
// comes in.
Aber ich Frage gerne noch mal, was sind denn das fuer besagte Funktionen/Aenderungen die ihr euch da wuenscht?
Wenn ihr Probleme bei der Umsetzung habt, kann ich auch gerne das hexfile kompilieren und euch einen Gui Loader senden wenn euch avrdude abschreckt
Danke das du deine Hilfe anbietest .
Mir ging es in erster Linie um den Platz, den ich zur Verfügung habe, daher wollte ich nur einen pro mini nehmen.
Wenn das aber nicht möglich ist wegen der begrenzten Leistung des ardus, würde ich für meinen Zweg einfach zwei mal das Teil von deinem Link kaufen.
Das scheint das Beste zu sein.
Was schafft eigentlich das Modem an Bandbreite? 1.2kbit oder 2.4kbit? Da habe ich gerade verschiedenes gelesen und bin verwirrt.
.Mir ging es in erster Linie um den Platz, den ich zur Verfügung habe, daher wollte ich nur einen pro mini nehmen.
Wenn das aber nicht möglich ist wegen der begrenzten Leistung des ardus, würde ich für meinen Zweg einfach zwei mal das Teil von deinem Link kaufen
.Das scheint das Beste zu sein.
Was schafft eigentlich das Modem an Bandbreite? 1.2kbit oder 2.4kbit? Da habe ich gerade verschiedenes gelesen und bin verwirrt.
Danke das du deine Hilfe anbietest .
Mir ging es in erster Linie um den Platz, den ich zur Verfügung habe, daher wollte ich nur einen pro mini nehmen.
.Mir ging es in erster Linie um den Platz, den ich zur Verfügung habe, daher wollte ich nur einen pro mini nehmen.
Das FSK Modem laeuft auf 8Mhz und macht max. 2400baud.
Falls du das modem von aeroquadstore mit dem TCM3105 chip meinst, nein. Der TCM3105 ist outdated, schwierig zu beschaffen (weil nicht mehr hergestellt) und macht max 1200baud AFSK. Für 2400 bd brauchts nen hack (übertakten) und dann sinds 1800hz / 3600 hz audiotäger (schafft das der videosender?).
Der läuft normalerweise mit 4.4336 MHz quarz, nicht mit 8mhz. Schau seite 8 hier:
http://www.tcm3105.com/tcm3105.pdf
Der läuft normalerweise mit 4.4336 MHz quarz, nicht mit 8mhz. Schau seite 8 hier:
http://www.tcm3105.com/tcm3105.pdf
Zuletzt bearbeitet:
Uebertackten ...
Brauchts eigentlich mehr als 1200 baud? Für eine tracker nachführung sollte 1200 doch allemal reichen. Frsky telemetrie bringt auch nicht mehr. Wie sind da die verhältnisse / erfahrungen?
Die audiotelemetrie mit arduino ist einfach interessant WEIL es nicht ganz einfach ist. Der sender arduino müsste direkten zugang zum gps haben (phantom2, feiyutech, etc) oder mavlink / mwii protokoll können? Wie sind da die verhältnisse / erfahrungen?
Brauchts eigentlich mehr als 1200 baud? Für eine tracker nachführung sollte 1200 doch allemal reichen. Frsky telemetrie bringt auch nicht mehr. Wie sind da die verhältnisse / erfahrungen?
Die audiotelemetrie mit arduino ist einfach interessant WEIL es nicht ganz einfach ist. Der sender arduino müsste direkten zugang zum gps haben (phantom2, feiyutech, etc) oder mavlink / mwii protokoll können? Wie sind da die verhältnisse / erfahrungen?
Zuletzt bearbeitet:
Hello everybody!
Wow, there's been alot of activity in this thread since I last checked! Sorry for not getting back here so quickly, but I've had a lot of work, and also wanted to finish another (APRS oriented) firmware I was writing for the modem before continuing on the Arduino library, so things dragged out a bit. Either way, just wanted to give a quick heads up on the progress, and the library is now actually working and functional, although very early and featureless. But I thought I'd rather throw it out here now anyway to give anyone interested a chance to play with it. There is no forward error correction, or even checksumming on the data packets for now, just raw framed packets. But it works I'll probably add these over the next few days, but first I really want to test it out through an actual FPV transmitter
Small video:
https://www.youtube.com/watch?v=CuIlGhhpTRw
GitHub repo:
https://github.com/markqvist/TelemetryKit/
Wow, there's been alot of activity in this thread since I last checked! Sorry for not getting back here so quickly, but I've had a lot of work, and also wanted to finish another (APRS oriented) firmware I was writing for the modem before continuing on the Arduino library, so things dragged out a bit. Either way, just wanted to give a quick heads up on the progress, and the library is now actually working and functional, although very early and featureless. But I thought I'd rather throw it out here now anyway to give anyone interested a chance to play with it. There is no forward error correction, or even checksumming on the data packets for now, just raw framed packets. But it works
I'll probably add these over the next few days, but first I really want to test it out through an actual FPV transmitter Small video:
https://www.youtube.com/watch?v=CuIlGhhpTRw
GitHub repo:
https://github.com/markqvist/TelemetryKit/
You're welcome It's all just great fun!
It's quite slim at the moment. The compiled examples uses 4kb of flash, and 694 bytes of RAM, but 256 of those are a packet buffer, so if you can get away with smaller packets than 256 bytes, you can go lower if you need to. The library itself is 438 bytes of RAM usage + size of max packet size for a full RX and TX. If you go TX only you do not need the packet buffer, so that's only 438 bytes in total.
And sure, no problem reading a GPS. I can cook you up a small example tomorrow, I have a ublox GPS module laying around somewhere. Basically this would be as easy as connecting the serial output of the GPS to the serial input of the Arduino, write a small loop reading it and calling the transmit function, and voila, you have NMEA GPS data coming out in the other end Of course, you could also go a bit more advanced and parse the GPS output first and send only the data you care about, either way, it's really simple. I'll post an example tomorrow
It's all just great fun!It's quite slim at the moment. The compiled examples uses 4kb of flash, and 694 bytes of RAM, but 256 of those are a packet buffer, so if you can get away with smaller packets than 256 bytes, you can go lower if you need to. The library itself is 438 bytes of RAM usage + size of max packet size for a full RX and TX. If you go TX only you do not need the packet buffer, so that's only 438 bytes in total.
And sure, no problem reading a GPS. I can cook you up a small example tomorrow, I have a ublox GPS module laying around somewhere. Basically this would be as easy as connecting the serial output of the GPS to the serial input of the Arduino, write a small loop reading it and calling the transmit function, and voila, you have NMEA GPS data coming out in the other end
Of course, you could also go a bit more advanced and parse the GPS output first and send only the data you care about, either way, it's really simple. I'll post an example tomorrow Also in terms of processor usage, it's not too heavy. It's all integer math, and no fancy stuff really. The interrupts "only" run at 9600hz, so you have plenty of cycles left for other stuff. I haven't profiled it exactly though, which I probably should at some point Would be interesting to see how many percent of the cycles it is actually using.
Would be interesting to see how many percent of the cycles it is actually using.Okay, so as promised here's a short sketch reading data from a GPS module and transmitting it to another modem, which then prints it out. Here's the transmitting sketch:
#include <TelemetryKit.h>
#define BUFFER_SIZE 256
#define TX_EVERY_N 2
int count = 0;
size_t readLength = 0;
unsigned long time = 0;
char buffer[BUFFER_SIZE];
void telemetryKitCallback(char *packet, size_t length) { }
void setup() {
Serial.begin(38400); // Set this to baudrate of GPS
TelemetryKitInit();
}
void loop() {
while (Serial.available() && readLength < BUFFER_SIZE) {
buffer[readLength++] = Serial.read();
time = millis();
}
if (millis() - time > 4 && readLength > 0) {
if (count+1 == TX_EVERY_N) {
Serial.print("Transmitting "); Serial.print(readLength); Serial.println(" bytes");
TelemetryKitTransmit(buffer, readLength);
readLength = 0;
count = 0;
} else {
count++;
readLength = 0;
}
}
}
Obviously, you would want to parse the contents of "buffer" first, and only transmit what you really need in a more compact format, but this was just quick and dirty
Short video:
https://www.youtube.com/watch?v=XQBIHZpHNGw
I have updated the GitHub repo at https://github.com/markqvist/TelemetryKit to include this as an example. There's also the simple transmit and receive examples (which had a little bug that is fixed now).
I'm going to test this one of the next days on an actual FPV transmitter, and then add some basic CRC checksumming so only valid packets will be sent to the callback function. Depending on how well it performs over the air, I will probably not include forward error correction and interleaving for now, since I'd think that keeping the library as small as possible outweighs missing a packet every now and then.
I will keep you updated
#include <TelemetryKit.h>
#define BUFFER_SIZE 256
#define TX_EVERY_N 2
int count = 0;
size_t readLength = 0;
unsigned long time = 0;
char buffer[BUFFER_SIZE];
void telemetryKitCallback(char *packet, size_t length) { }
void setup() {
Serial.begin(38400); // Set this to baudrate of GPS
TelemetryKitInit();
}
void loop() {
while (Serial.available() && readLength < BUFFER_SIZE) {
buffer[readLength++] = Serial.read();
time = millis();
}
if (millis() - time > 4 && readLength > 0) {
if (count+1 == TX_EVERY_N) {
Serial.print("Transmitting "); Serial.print(readLength); Serial.println(" bytes");
TelemetryKitTransmit(buffer, readLength);
readLength = 0;
count = 0;
} else {
count++;
readLength = 0;
}
}
}
Obviously, you would want to parse the contents of "buffer" first, and only transmit what you really need in a more compact format, but this was just quick and dirty
Short video:
https://www.youtube.com/watch?v=XQBIHZpHNGw
I have updated the GitHub repo at https://github.com/markqvist/TelemetryKit to include this as an example. There's also the simple transmit and receive examples (which had a little bug that is fixed now).
I'm going to test this one of the next days on an actual FPV transmitter, and then add some basic CRC checksumming so only valid packets will be sent to the callback function. Depending on how well it performs over the air, I will probably not include forward error correction and interleaving for now, since I'd think that keeping the library as small as possible outweighs missing a packet every now and then.
I will keep you updated
Zuletzt bearbeitet:
- Status
