Von Linux Tracker V17 auf V22 - HowTo?

    Servus werte Foris,
    ich würde gerne meinen Linux Tracker von V17 auf die aktuelle V22 updaten bzw. hatte ich das soeben versucht. Leider
    ohne Erfolg. Hatte dann gesehen, dass wohl auch das Startskript angepasst werden muss und das neue Skript auf
    den Server geladen, Berechtigungen korrekt gesetzt, nun ja, wieder nix.

    daher konkrete frage: gibt es hinweise darauf, ob gewisse stolpersteine beim upgrade von v17 auf v22 zu beachten sind?
    besten dank und schöne grüsse
    michael

    Hi Michael,
    I put my notes about this to the end of this page:

    It works for me, hope, it will usefull for you too.
    best:
    t.janos

    hi janos,

    thx for your link and your blog. your work and documentation is awesome.

    i´ll give the lt22 a second chance tomorrow. if there are any queries, i´ll be back ;)

    thx again and best to you,

    73, oe3maa

    servus,
    sometimes it takes some time to get the machine running ;)
    i´ve forgotten to adjust the new startscript and to make a symbolic link.
    linux-noob i am ;)
    thx for your help janos,

    noch eine frage bezüglich der fortuna u2 maus. soweit ich weiss, hat die ja eine sirf2 chipsatz, derzeit läuft die
    verbindung mit 4800 baud, ist es sinnvoll (oder überhaupt machbar) 19200 bd einzustellen?
    schöne grüße
    michael

    Hi, Michael,
    Egon described in much details in the TOA_Blitzortung.pdf the use of the Fortune U2 gps. After this description he said:
    ---------------
    The initialization by the tracker program switches off the data sentences GPGLL,
    GPGSA, GPGSV, GPMSS, GPDTM, and PGZDA. The data sentence GPRMC and
    GPGGA will be switched on for an output by every second. The communication speed of
    the serial interface is 4800 Baud by default, but the initialization switches the communi-
    cation speed to 19200 Baud.
    ----------------
    I dont know, which version of the board do you use, you dindot filled up the data on your user page. On the different version of the board there are different jumper combinations to setup the serial line speed.
    For example I have an earlier version 4 of board, and I havenot any jumper block on it. But following the circuit diagram, you can modify the setup speed with a small pice of wire to the higher (19200 b/s) on this old board too.
    best:
    t.janos

    Hallo,

    ich habe das Startscript noch einmal angepasst, bitte noch einmal den Tracker (zur Sicherheit) und das Startscript neu laden, falls es immer noch nicht läuft bei euch.


    Die Fortuna U2 läuft auch mit 4800, 9600, 19200, und 38400, Das Problem ist jedoch, dass die alten Mäuse wegen der schwachen Backup-Batterien die Einstellungen nicht speichern. Es muss also nach jedem Spannungsabfall die Maus neu initialisiert werden.

    Grüße,

    Hi again,
    @Janos, i really appreciate your support thx! I don´t know the exakt version of my hardware or board, but i believe it´s one of the early ones 4.x

    @Egon: In respect to Janos i want to answer in english. Today i experienced a problem after the daily reboot of my server.
    In the startup-sequence S20_blitzortung works and i can see a task running. But the controller in the hardware seems to hang up.
    Maybe i can fix this with your adapted startscript?

    Und noch auf deutsch :)
    Nach dem täglichen Reboot des Servers wird in der Startsequenz zwar die S20_blitzortung korrekt abgearbeitet, und der entsprechende Task läuft.
    Aber die Hardware dürfte sich aufhängen, sprich der Microcontroller. Könnte dein verändertes Startscript hier Abhilfe schaffen?

    schönen gruß, 73
    michael

    Dear Michael,

    When I started first time the LT vers 22, Egone noted, better to run the serial port speed not on 4800, as the default, but on 19200 b/s.
    If you have newer version of board, there are jumper blocks on the board, to make with this jumpers the setup, documentated in the appropriate version of our basic documents, the TOA_Blitzortung.pdf
    On the first some version of the board, there arenot such jumpers. Your success will dependent from the firmware version, running on the board too.
    I havenot deap informations about the differences of the firmware versions, maybe Egon will correct me, the newer version has the features, to check this jumper blocks, and dependent from the used setup, inicializes the speed on the serial line communication. It is shure, the 22, 23, 24 firmware versions have this features. (maybe, you know, the last are the 27a and 27b.) I reprogrammed my board at the end of last year, with the firmware version of 23. Here need a small attention, because on this old board version - if I know well, - this is the last supported version of firmware! And - if I know well, - you canot find "officially" this firmware on the Miscellaneus (download) page.

    So: If your board version is 4.x, and your running firmware version allow it (it is greater than 20 ???) you need a small hardware modification, substitute the later jumper setups. The modification is very simple, you need to grounded the 21-th pin of the Atmega644 controller. I put a picture about this on my "blog" page:

    If your firmware version accept this modification, it will run on 19200 b/sec. You can check this on your debug terminal.
    If all are OK, you can make a Reset on your running board, to accept the firmware version field by the Linux Tracker program. It will capture this version information from the init string of your board, and will upload it to the Participants page. You (and we) can check this (the firmware version and the serial line speed info) on the inner Participants page.
    Hope, this will help you.

    This special instructions are interesting only a few people, because the majority of the used board version are newer, and dont need any hw modifications.


    I looked into the S20_blitzortung_tracker init script. Hope, you filled all the necessery variable modifications well (PROGDIR, PROGNAME, GPSTYPE, and so.. It seems me, your problem comes from the serial line init. If your boad run on the original state (without the small modification, I described here), it need to use the 4800 baud setup:
    BAUDRATE="4800"
    Some more notes:
    I dont know in this moment, what is the priority between this script and the parameters you give to the Linux Tracker, when it start...
    I dont use this init script, because I like to play a little every time, when I started the board.
    best: t.janos

    He Michael,
    I extended this notes a little more, but I dont put it here, because it usefull only a small minority in our community, and it comes from my linux practices. I put this new notes to my "blog" page, about the different log practices, I use to follow the working of my gps device.
    best:
    t.janos

    hi janos,
    i think i got it now. grounded pin 21 and tried to start manually:

    2011-02-19 10:55:48, PID: 23398, tracker started
    2011-02-19 10:55:48, PID: 23398, initialize GPS with SiRF, 19200 baud, using 4800 baud
    2011-02-19 10:55:49, PID: 23398, initialize GPS with SiRF, 19200 baud, using 9600 baud
    2011-02-19 10:55:49, PID: 23398, initialize GPS with SiRF, 19200 baud, using 19200 baud
    2011-02-19 10:55:49, PID: 23398, initialize GPS with SiRF, 19200 baud, using 38400 baud
    2011-02-19 10:56:03, PID: 23398, unknown sentence:
    2011-02-19 10:56:03, PID: 23398, Firmware Version: 23


    so i stopped again, switched of the hardware and started hardware again.
    again manually started the process and:

    now the device runs at 19200bd, everything seems fine so far,
    thanks to your support janos. one issue from last night is interessting. in the log i found a list of entries like these:

    seems like the reception of gps signal worsend beetween 1 and 2am. early in the morning there were some stoped and running lines too.
    but for now, i´ll watch closely the log. the key is, when the server restarts, if the S20_ startup sequence starts normal. so we´ll see.

    again janos, i appreciate your help and your advise. thx so much,
    best to you, 73 de oe3maa
    michael

    Hello Michael,
    Congratulations to you, your update from ver. 17 of LT to the latest is successfull!

    I see in your debug log file the "garbadge-like" binary data.
    I think, its happens sometimes during the init process. My idea from where comes this is:
    1. We dont use handshake lines at the serial port communications, this garbadge-like transport happens, when changed the speed, and lost the synchronous state of the two end of the line.
    2. After the init, there are some unsended puffer contents at the board side, and it dumps it, but it will be receive not with the correct speed...
    But this are only my tipps.
    I checked in my recorded similar debug log files, and I found only one time period, when similar binary-like data arrived, and was reject by the LT, and recorded in the log file. I think, my case is different from your, because on my station this wrong transfer conditons keep on 27 second long time period! It happened at 08.02.2011. It started at 13:22:27 and finished automatically at 13:49:07.
    I put here some lines from the log file, from the beginning of this process, and some lines, when this was finished...

    2011-02-08 13:07:37, PID: 16276, 1PPS signal accuracy ok, counter: 83812E A9A847, +60 nsec
    2011-02-08 13:21:01, PID: 16276, start interference mode, 16 strikes per seconds, 2 seconds nonzero
    2011-02-08 13:21:01, PID: 16276, stop interferences mode
    2011-02-08 13:22:27, PID: 16276, start interference mode, 17 strikes per seconds, 1 seconds nonzero
    2011-02-08 13:22:27, PID: 16276, stop interferences mode
    2011-02-08 13:48:03, PID: 16276, unknown sentence: ÝYZm*,ZKJIJZ*{ZIj*-ZJ+zµHÊÊ
    2011-02-08 13:48:05, PID: 16276, unknown sentence: ÿÝym{,,ZKJIJZ*{ZIj*-ZJ+zj¹YziJ*-jx:øÝIk|*,ZKJIJZ^1
    2011-02-08 13:48:05, PID: 16276, unknown sentence: ÌN
    ----
    Here follow many lines.....
    ---
    2011-02-08 13:49:01, PID: 16276, unknown sentence: ÊÄÿÝ©¬Z*­HJÌHÌN
    2011-02-08 13:49:05, PID: 16276, unknown sentence: ÈÊJÄÿÝIJ-,Z[ZIJZ*{ZI[*-ZJ+z{¹Y[IJ*-zx:øÝIj+,Z[JIJZ*{ZIJ*-ZJ+zk¹Y[iJ*-zH<øÝim­-,Z[ZIJZ*{ZIJ+-ZJ+z[¹Y[YJ*ÊÄÿÝy[«+,Z[jIJZJÌHÌN
    2011-02-08 13:49:07, PID: 16276, unknown sentence: ÈÊJÿÝYM-,Z[zIJZ*{ZIZ©)¢rbj±ÁÝ©Õ5)ÿ$BLSEC,C1E425,A,134906,080211,4729.2806,N,01904.2740,E,141.8000,M,07*5B

    2011-02-08 13:49:08, PID: 16276, GPS seconds stoped, 1 7
    2011-02-08 13:49:08, PID: 16276, 1PPS signal inaccurate, counter: 11F72B E80B3D, accuracy: -3559808650 nsec
    2011-02-08 13:49:09, PID: 16276, GPS seconds running, 7 8
    2011-02-08 13:49:28, PID: 16276, 1PPS signal accuracy ok, counter: BCF1FD E31915, -160 nsec

    After the line, was logged at 13:22:27, seems, the transmission stopped, or hang up the communication (?) and 24 seconds later started to receive the "garbadge", and finaly a little later corrected the transmission.

    Notes about another things in your reffered log file:
    It is an interesting phenomen to follow the changes of the gps working state.
    In your log file you can see:

    2011-02-18 22:13:17, PID: 1992, GPS status changed from '-' to 'A'

    If this happens in the revers direction, and the gps send this signs more than a short time intervals, you will see on the Partitions Table to change the A letter to a red V, means, your gps has problems to working well. I have some idea, what happens in this circumstances, but I dont explain it here.
    With the new LT version we have another good indicator about our gps conditions, this is the actual numbers of the received satellietes. And we have a nice table all about our networks, thanks to Egon-,s new developments!

    Maybe you know from your radio amateur practices, that in this year started the increased activity of our sun, and this have much signiphicant effects and influences to the radio transmission practices too, ofcourse to the VLF frenquency band, we use in our detectors.
    And on the microwave fraquency, where the gps recive the satellite signals.
    Need to note, that the previous such time, 11 years ago, where was last time the sun so "active", werenot so popular the use of the gps, as we can see nowedays.
    Sometimes I check the actual conditions and activity of the sun here:

    best:
    t.janos (hg5apz)