Linux-Tracker Debian Quellpaket verfügbar

Hallo zusammen,

quasi als Abfallprodukt meiner eigenen Installation habe ich ein Debian-Quellpaket für die Tracker-Software erstellt, dass hier heruntergeladen werden kann. Ein Binärpaket kann dann lokal für die jeweilige Architektur erstellt werden. Ein automatisches Startskript für den Tracker ist mit dabei.

Einfach das Quellpaket herunterladen, die beiliegende README-Datei sollte alle erforderlichen Schritte erklären.

Wichtig ist nur, dass der Quellcode des eigentlichen Tracker-Programms nicht enthalten ist, der muss noch von der Blitzortung-Webseite dazugeladen werden.

Viel Spass beim Ausprobieren und natürlich freue ich mich auch über Rückmeldungen.

Viele Grüße,
Andreas

Dear Andreas,
It is a good idea to make a downloadable package from the tracker-toa program for linux, specially for Debian.
Your framework is a very nice job for this, seems you are successfull to generate a pkg for yur Debian distrib.
I use NSLU2 board, installed on it a Debian too, it uses the Debian packages compiled for armel architecture. To compile and run on this board the tracker program, it has some small tricks, but easy process. I decided to use your frame to make a "package" about it.
I use the 4.0 ver of the Tracker PCB, and run the LinuxTracker, version 10.3
Follow your step-by-stepp instructions, I installed some missing packages on the NSLU2 board, and after I run the script, started to build the package.
I dont have too much practice to use this "multi-level" control struture, with autoconf, configure, make, and so. It seem me, the core job will make in the source dir, on the tracker source prog.
But the generated Makefile has some missing references, and dont able to compile the file.

The source not a simple c file, but .cc, and we use this simple command line, to compile it with g++, as writen by Egon in the program comment:

g++ lWall -lm -o tracker_toa tracker_toa.cc

Seems me, to control some variables in this local, or source dir, can use the ./source/Makefile.am file. I modified this with the correct porg-name, and I can see the effects in the generated Makefile, here are some lines of it:
-----------

tracker_toa_SOURCES = tracker_toa.c
tracker_toa_OBJECTS = tracker_toa.$(OBJEXT)
tracker_toa_LDADD = $(LDADD)
DEFAULT_INCLUDES = -I. -I$(top_builddir)
depcomp = $(SHELL) $(top_srcdir)/depcomp
am__depfiles_maybe = depfiles
COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)

------------
Somehow, it dont accept, that the prog name is tracker_toa.cc and ofcourse it try to complie it with gcc, without too much success...
To modify manually the generated Makefile isnot a good idea, but for test can be, but I didnot find the right way to make this.

So:
for me it hasnot too much trouble to compile and run the tracker program on this small board, but to compile a debian package from it, hasnot success in the first round.

best:
Janos

Dear Janos,

thank you for your remarks. Unfortunately I could only test the procedure of building the package on Ubuntu 9.10, 10.4 and Debian Lenny on i386 architecture for the moment.

As I'm just waiting for an Arm-based Plug-Computer I will try to fix the package creation there, maybe we have to setup a cross-compiler there. Another approach would be to skip all the automake/autoconfig stuff and stay with manually generated makefiles. But this will be solved in some weeks.

Regards,
Andreas

Dear Andreas,

I had the feeling, but now it become clear for me, it is not easy to "control manually" the package build procedure.
I substitute the generated Makefile in the ./source dir with my very simple Makefile, to compile the tracker prog, and if I use the "standard" commands, to build the progs:
./configure
make
it run without errors, and compile the prog. By the way, I use on NSLU2 "native" gcc chain, and not a cross compiler.
But it is celar, to build a debian package, involve more stepps, seems, the first is cean the dir tree all the previous files. If, after the ./configure I start the package maker
dpkg-buildpackage
I get this errors, ofcourse I didnot built into my simple Makefile rules, for example clean the dir tree:
===========================
dpkg-buildpackage: source package blitzortung-tracker
dpkg-buildpackage: source version 15.0
dpkg-buildpackage: source changed by Andreas
dpkg-buildpackage: host architecture armel
debian/rules clean
dh_testdir
dh_testroot
rm -f build-stamp
# Add here commands to clean up after the build process.
[ ! -f Makefile ] /usr/bin/make distclean
make[1]: Entering directory `/home/janos/toadebian/blitzortung-tracker'
Making distclean in source
make[2]: Entering directory `/home/janos/toadebian/blitzortung-tracker/source'
make[2]: *** No rule to make target `distclean'. Stop.
make[2]: Leaving directory `/home/janos/toadebian/blitzortung-tracker/source'
make[1]: *** [distclean-recursive] Error 1
make[1]: Leaving directory `/home/janos/toadebian/blitzortung-tracker'
make: *** [clean] Error 2
dpkg-buildpackage: failure: debian/rules clean gave error exit status 2
=======================
So:
this was my second "round" to produce a downloadable package for my NSLU2.
best: Janos

Dear Janos,

as we do not really need the autoconfig/automake stuff I modified the package to use static makefiles. Just download the package source from the given link, extract it, copy the tracker source into the source folder and run dpkg-buildpackage.

Hope this is helpful and simple now!

Regards,
Andreas

Hi,
lets start talk more about alternative platforms for TOA Trackers. I use NSLU2 as Janos. My another tips:

SheevaPlug
ARM 5 archtecture, 1.2 GHz, 512 RAM, 3 - 5 W, from 99 USD

BifferBoard
486 architecture, 150 MHz, 1 - 2 W, cost about 35 GPB + case

These platform are great for 24/7 aplication as TOA.

If You use another solution let know to us!

Mike

Hi, dear Mike,
here are my notes about your announcement:

1. It would be better to start a new thread for this topic.

2. To use "alternative platforms" sometimes can hear the argumentations, this is more "environmental friendly",
cut the household,s budget, and so.
This arguments earns more attentions for us, because we use our sensors, devices in continuous run, without any manual control.

3. But it seems me, to use devices with the possible low power consumptions, offeres the features, to install this sensors on the best place around us, for example on a place, where the usual electromagnetic noises have lower level, as we must tolerate in the city centers, or other "civilized" environments.
If we think about such small, low power sensors, we can concentrate two factors:
- how can solve the power consumptions
- how can solve the need for the permanent internet connections.
Maybe it would be a good idea to make an overview about the existing, known solutions around this, not only counts the possible small boards, need to solve the data transfer from the sensor part.
best:
Janos

(Basically this Forum flows in german language, and I have the idea, to try to use the accessible translate services on the internet, and because this, I try to use google translate now, to make a "more-or-less" acceptable translation of my sentences in german language, here follow this)

===================================================

Hallo, lieber Mike,
Hier sind meine Notizen über Ihre Mitteilung:

1. Es wäre besser, einen neuen Thread zu diesem Thema zu starten.

2. So verwenden Sie "alternativen Plattformen" Manchmal kann die Argumentationen zu hören, das ist mehr "environental freundlich",
Schneiden Sie den Haushalt, den Haushalt, und so.
Diese Argumente verdient mehr Aufmerksamkeit für uns, weil wir unsere Sensoren, Geräte im Dauerbetrieb nutzen, ohne manuelle Kontrolle.

3. Aber es scheint mir, für Geräte mit den möglichen niedrigen Energieverbrauch zu verwenden, offeres die Eigenschaften, auf diese Sensoren auf dem besten Platz um uns herum zu installieren, zum Beispiel auf einen Platz, wo die üblichen elektromagnetischen Geräusche haben eine niedrigere Ebene, wie wir es dulden müssen den Innenstädten oder anderen "zivilisierten"-Umgebungen.
Wenn wir über solche kleinen, Low-Power-Sensoren denke, wir können zwei Faktoren zu konzentrieren:
- Wie kann der Energieverbrauch lösen
- Wie kann die Notwendigkeit der permanenten Internet-Verbindungen zu lösen.
Vielleicht wäre es eine gute Idee, sich einen Überblick über die bestehenden, bekannten Lösungen, um dieses zu machen, zählt nicht nur die möglichen kleinen Bretter müssen, um die Datenübertragung vom Sensor zu lösen Teil.
am besten:
Janos

(Im Grunde Forum fließt in Deutsch, und ich habe die Idee, zu versuchen, den Zugang zu übersetzen Dienstleistungen über das Internet, und weil dieser versuche ich, Google Translate, verwenden, um ein "mehr oder weniger als" akzeptabel Übersetzung nutzen meiner Sätze in Deutsch, hier folgen)

Hi,

its a good idea to collect information about possible platforms and installation instructions, maybe as an addition to the FAQ wiki or at another place.

Wenn es anderen hilft, ist es sicher eine gute Idee Informationen über verfügbare Plattformen und Installationsanleitungen zentral abzulegen, vielleicht auch als Erweiterung des FAQ Wiki?

Grüße,
Andreas

Hello everyone
I write first and I would ask if anyone has used bifferboard for Blitzortung possibly can manage even a wifi usb pen?
Thanks
Gianni

Dear Gianni,
I dont understand clear your question:
do you want to use the bifferbord as an upload machine for TOA, and connected it with wifi to the lan/internet? or want to connect it to the TOA device wirelessly?
If you think to make an "independent", wireless device as a lightning sensor, I think, more possible platform to this a wifi access point, with "costum", OpenWrt system. Some of this have serial port, and a built in wireless interface with AP mode.
best: t.janos

hi JanosTol
I would use the bifferbord as an upload machine for TOA, and connected it with wifi to the lan/internet.
I wondered whether the characteristics of bifferboard, support the workload,
and if anyone has used this "bifferboard" for TOA.

Zitat von JanosTol

If you think to make an "independent", wireless device as a lightning sensor, I think, more possible platform to this a wifi access point, with "costum", OpenWrt system. Some of this have serial port, and a built in wireless interface with AP mode.

I prefer bifferboard for low power consumption 1W

thanks
Cignals

Hi, dear Gianni,
I know only, that in the Blitzortung community Mike (participant, as nr 39 in Blitzortung sites table) plan to use bifferboard as an upload machine, but now he use NSLU2.
I made some tries, to find "not too-power-hungry solutions", my notes are on this web page:

but some month ago finally I found the NSLU2, as a confortable "compromiss", and run on it a recent Debian with the Egon's TOA software, and many more:
, but this page is in hungarian, sry...

I have a look into the bifferboard wiki, based on my first impression, it is questionable, how can use the serial port, serve the data transfer from the TOA board, because it come up as "system console", and maybe, need some workaround with the usb wifi stick, if you want to connect it to a lan.
best:
janos

Hi JanosTol
Thanks for the link, the hardware, "NSLU" is very similar to "bifferboard"
I ordered bifferboard try to install the software, and you know

Bye
Gianni

Hi, dear Gianni,
I had some searches around, connected to your proposed problem, to use bifferboard (or other small embedded board) as a TOA upload machine, and all this system access the internet in a wireless channel.
It seems me, the more simple, and easy to realise version looks like:
- the TOA board
- some small embedded board (bifferos, NSLU2, and so)
- a wireless access pont with point-to-point mode.
You can connect the embedded board and the ap as a small, independent segment of your lan, use the same IP address range. After this need to connect in point-to-point mode this small, separate network part to another ap, which is part of the lan. Practically, with this solution you can "wirelessly extend" your lan to a remote place.
Maybe, if your main aim is to reduce the power consumtions of all the running devices, this isnot a good solution for you.

If I know well, on the linux systems there are 3-4 type of wireless chipsets only, which have "support" the AP mode, and you can use this devices, to realize the previously proposed method but whitout two additional acces spoint devices. (I have some practices with the Prism 2.5 based PCI cards, and access points, based on Atheros wifi chipsets). The problem is, that this devices can buy (if any) in PCI, PCMCIA card/device forms. In the access points there are this wireless interfaces as "built in unit", in the main controller chips.
There are some (new) usb dongle-like wifi devices, containing "usefull" chipsets, but I found only some Atheros based devices, accessible for me, here, but it has very high speed, and high price too...(D-Link, DWA160 )
Use this device, have two option with the software drivers:
- Need to compile the madwifi drivers for atheros chipsets. It seems easy, but not too easy, as some expert claims. I tried it on my regular CentOs machine, and on a new ubuntu and debian too, without any usefull results. I dont explain here the problems, it was only a trying, I havenot any "usefull" usb device now, to continue this tests.
- The second option to use the new linux driver to this high speed devices. This driver, as module is part of the standard distributions, but since the kernel version 2.6.30. It is sure, for example for the NSLU2 board arenot such recent version of kernel and system.
You can find this high speed wifi usb driver in more-or-less standard path in the file-system:

/lib/modules/2.6.31-14-generic/kernel/drivers/net/wireless/ath/ar9170

The name of the module is:
ar9170usb.ko

By the way, on the NSLU2 there is another, small limit: it has only 2 usb slots, and if you use it as TOA upload machine, you need one of it as serial connection to the TOA board, and the second need for the pen drive, holdig/containing the system. If you want to use a third usb device, you need, min an external usb hub.

If I have some possibility to buy such high speed wifi device, I will continue this test and I will refer about it...

best: t.janos

Hi JanosTol
I have a DWL-G810, which works perfectly but is consuming enough
high approximately 600mA,
Regarding the use of wifi keys on bifferboard possible, reading of wiki bifferboard
.
As soon as I try the hardware I'll be more precise.
I use NSLU2 to other applications and editing I got 3 more ports by connecting two digital cameras, USB key (software), wifi key.

Thanks
Gianni

Hi, dear Gianni,

I red the bifferos notes about the use of usb wifi dongle with bifferboard.
He proposed the ZyDas ZD1211 chipset, the Prism2.5 chipset (Ralink RT2870) and Realtek devices, based on rtl818x and rtl8192 chipsets.
I have somewhere an usb dongle with ZyDas chipset, I used it with linux without problems, connecting a machine through an ap to the local lan. I will check the possible use it with NSLU2 machine.

By the way, yesterday I made a setup, what I proposed in my last post, with two old, small, nice ap:
They have similar age, as your, name is Micronet SP918 BK and based on Realtek rtl8180 chipset. They consumes similar amount of power, 500 mW, and they have the usefull AP-Bridge point-to-point mode.
With this setup I can access my NSLU2 upload machine wirelessly from my local, wired lan based on this schema:

TOA--NSLU2--AP1 .. . . . (wireless p-to-p link) .. ... AP2--router---internet

I dont know exactly the power consumptions of the TOA board, but the NSLU2 need around 2 A on 5 volt, and the Micronet AP need 0.5 A, and this is working as a wireless sensor station.

The NSLU2 usb port modification is nice, but do you use the connected devices with external power source?

best: t.janos

hi JanosTol
I connected the power of the usb directly in parallel with the original USB power Maximum 500mA total

I'm still waiting for bifferboard, hopefully arriving soon
Bye Gianni